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