[afandian]

Linked at the end is this article: https://thehftguy.wordpress.com/2016/11/01/docker-in-product...

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...

[brudgers]

The central themes of the recent criticisms of Docker are made from the perspective of enterprise. Rapid iteration by Docker-the-Company is a bigger concern when the use case is closer to the Cobol-in-a-Container end of the spectrum. The alternatives are coming from organizations like RedHat and CoreOS and the big cloud providers that are focused on selling into enterprise.

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).

[atemerev]

My advice — do not use Swarm. Start directly with Kubernetes or DCOS. You might think that those are overkill for smaller projects — well, I also thought this way, and got into similar issues as this article describes. When I started again with Kubernetes, life became much simpler.

[agmcleod]

Sorry I'm really confused and rather new to the devops world, aside from pushing an app to a single VPS. What problem does Kubernetes solve exactly? Is it to tie a single application spread among multiple servers?

[atemerev]

Docker way is structuring your apps in "one service per container" — Docker is designed around this. Even the simplest applications require multiple containers (one for front-end, one for back-end, one for the database etc) — even without clustering or high-availability, which complicate things even more.

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.

[ohstopitu]

Ignoring availability & mirroring (and all other cloud enabled features) for conversation's sake:

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)

[atemerev]

It can, if you have a single production host and only one development machine, i.e. if you are a solo developer.

For anything more than that, native Docker tooling is inadequate.

[ohstopitu]

I can understand the use of Kubernetes to spread over multiple hosts (but that's generally for scaling & availability).

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.)

[krakensden]

Kubernetes is an OODA loop- it schedules containers to run on servers, and reschedules in response to events. The hope is that it takes a lot of plumbing work off the table and handles it for you.

[swap32]

I would put it this way - how much value gain are you expecting integrating docker in your processes? Is it a pressing need right now? How badly would it affect you if it doesn't work out for you? The article is the summary of our small scale experimentation. You can definitely experiment and weigh the gains for yourself. But its good to have the issues listed in the articles here at the back of your mind.

[afandian]

Thanks! My position is, I'm starting from a blank slate with a new project. I want feature set X, and Docker and Swarm supports feature set X. (where X is something like running a number of little microservices with failover, load balancing, local integration testing, mixed language platforms, sharing development across organisations). I could get them another way, but I want to start on the right foot with a new project.

[user5994461]

Author of the quoted article here.

> 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

[e12e]

That's a very nice summary of Docker, and kind of highlights why the hype is somewhat... misplaced.

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.

[scaryclam]

I've used Docker in production environments and found that it was helpful on some projects, but a disaster on others. The article brings up many of the pain points that you'll find using Docker for anything more complex than toy projects. It also gives some really good advice (like not putting your DB into a container). I'm currently finding that docker-compose is great for local development, but we've learned to be very cautious about introducing it (Docker) for anything production based.

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.

[swap32]

I can assure you, you can do all that without getting yourself into the microservices mess and docker. As you said, please get them another way. If this is a serious project with deadlines and client money at stake, as you said please do it another way.

[pella]

see: https://news.ycombinator.com/item?id=12872304

[syaz1]

Honestly if you're new like you said (blank slate), I'd recommend using Docker for your development. Get comfortable with the idea of containers first. Start with one, then try using more (your app, redis, rabbit, etc all containerized... but personally I run DB locally).