As someone starting considering Docker (and possibly Swarm), these seem to be pretty serious criticisms. Any experiences to corroborate / counter these two posts? Going by what's written here it would be suicide to use Docker, but many people are...
At the container level, Docker containers are the basis for the container specification from the Open Container Institute. The kertuffle is over orchestration. Swarm is a feature from Docker-the-Company that trys to make 'Hello World' container orchestration Ruby-on-Rails easy. Right now the alternative orchestration layers are more toward the "Apache server man page" end of the spectrum.
Essentially, Docker-the-Company and the Docker critics are focused on different contexts. Docker-the-Company thinks container orchestration on a Raspberry Pi is worth pursuing. The Docker critics are coming from a world where CentOS 5 is still relevant (metaphorically).
When you have multiple containers, it is imperative that they are managed as a group, with clearly defined dependencies. This is why Docker requires an orchestration tool. And when the number of your production nodes is greater than one, Docker on its own becomes inadequate for that.
Can't the above be orchestrated via docker-compose?
(I've been using docker with docker-compose for my side projects but not been using it excessively in customer facing production)
For anything more than that, native Docker tooling is inadequate.
If you have multiple devs...how does docker-compose fall short? (I'm asking because I wanted to suggest using docker for my team and wanted to know it's short comings before I suggested it).
From my understanding: you can use compose to orchestrate databases, cache, app all on one machine quite easily (and pass environment variables, get them linked etc.)
- Secret distribution
- Managing persistent volumes
- Monitoring containers for failure, restarting according to policy
- Service discovery and DNS integration
- Integration with load balancers, setting up routes, etc.
- Managing affinity / non-affinity for containers
- Sharing resources on a cluster via namespaces
This alone warrants an orchestration solution, even on a single machine.
I would suggest starting off by stepping back from picking specific technologies and architecting your system properly first. Where do you need load balancing? What are the different parts of the system? How can you break those parts up so that different teams can work independantly from each other? What microservices do you really need? Do you actually need microservices? How will they communicate?
If you start off by having to design everything around Docker (or any other implementation detail) then you're going to have a very brittle system that's going to cause you pain in the long run. After designing things fully you may realise that you've managed to eliminate most of the initial perceived complexity and can actually work just fine with more boring tools.
Docker and swarm don't actually solve any of feature set X. You have to do that yourself, and while they may help facilitate a solution, they're not going to really do anything for you. Lots of people have jumped onto Docker without really understanding what it's doing for them, which is why it seems like everybodies using it.
If you don't know which problems you have the Docker is a good fit for solving, don't use it yet. If you can't fit it into your process at a later date, it probably wasn't a good solution for you in the first place, so you'll have saved yourself a headache.
> failover, load balancing, local integration testing, mixed language platforms,
Docker does none of that.
It's only a packaging and deployment system. You package the app as a docker image, then you can call a docker command on any system to grab that image and start it.
Without docker:
1) You'd make a zip/deb/rpm of your application.
2) Download the zip to some servers
3) Update the dependencies & systems stuff
4) Start the app
With docker:
1) You'd make a docker image [basically: run a script to install the app and the dependencies, as in the previous steps]
2) Save that image to the container registry
3) Deploy & Start the image on some systems
Jails (from bsd) and chroots are a great idea. But a way is needed to manage the file system of a) the chroot (the c libraries, the configuration files the application code). This is docker image; b) persistent data (database, images and binary user data etc). As far as I can tell docker doesn't really come with a compelling story here - something that's easier to manage and gives high performance (say something that competes with iscsi for database files, and a solid out-of-the-box clustered filsystem).
Now, docker gets (justified) hype for pushing the jail/chroot (aka "container") idea. But I think a lot of people (possibly including docker Inc) think that docker does much more (and do those things well) beyond being a nice-ish set of tools for building and managing self-contained chroot file systems for applications ("images").
Docker Inc certainly is working on "everything else" - but I think moat would be well-served to look at Lxd/lxc if what you want is "lightweight Linux vms", or kubernetes if what you want is to move towards a "container/chroot (micro) service paradigm".
Kubernetes might seem a bit complex, but that is because it tries to solve a complex set of problems.
Docker is more like "yo! Synchronise your /etc/passwd file across systems so you can log in to all your machines", while kubernetes is more like LDAP+dns+kerberos. More complex, but more sane. And built not just to get started, but continue to work as your system evolves.
And I've been quite happy playing with Ubuntu and Lxd + zfs on the other end - the simple light weight Linux vm end.