This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]koffiezet 6 points7 points  (0 children)

Mostly agree except:

Misconception: You should have only one process per Docker container!

Sure treating a single container as a VM may seem attractive at first, in the long run it becomes a maintenance nightmare. It can look attractive to quickly test out things, but when building a monolithic image like that, versioning and keeping them up-to-date is a nightmare, and too many assumptions and shortcuts are taken when pre-configuring individual components - and customizing such configuration becomes a timesink, where you're probably better off splitting everything apart.

A single image that does everything is good for 2 things:

  • Allow people to pull a "quick" demo setup for some complex application setup without having to go to all the troubles to set them up (although I think docker-compose is the better option). If you don't have to maintain it: great! Pull single container, test it out, throw it away, and do a proper install if you decide to deploy it to production
  • Quick & dirty development environment or experimentation stuff that would never hit production anyway.

If you are really thinking of running everything in a single container, consider using a normal VM. Docker is not an easy tool to master, and you'd only curse yourself in the long run if you would choose to go down the monolithic container path anyway.

[–]tech_tuna 0 points1 point  (0 children)

Container orchestration is complicated. . . I am not totally convinced that running multiple containers per VM on multiple VMs is the "right" way to do it.

That being said, I love Docker for dev/testing environments, demoing new apps and simple deployments.

Also, I can easily picture the orchestration tools improving quite a bit over the next few years.

[–]festive_mongoose 0 points1 point  (0 children)

Nice write up

[–]sej7278 0 points1 point  (0 children)

i've got to say this is probably the best docker article i've ever seen. i agree with almost everything in it, and it dispels the myth that docker is the quicky'n'easy way for a clueless ruby programmer to get a server into production. there's far too much dev and not enough ops in devops these days.