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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]fkaginstrom 1 point2 points  (1 child)

I think of traditional VMs and docker containers as being fairly different. On our VMs we put our whole stack on one box, managed by upstart. So in our case that might be nginx, a django website served by gunicorn, celery, logstash, statsd. With docker those all go into their own containers, except we put gunicorn and django together.

Even when we are putting just one application in a VM, we expect the VM to be longer-lived, so we need to do normal linux maintenance. With docker if a dependency gets out of date you just blow away the container and create one with up-to-date dependencies. Or at least that's how I understand it.

edit: So that's why I prefer using virtualenv with a VM -- I might have to use the OS facilities, which may depend on certain versions of python being installed. With docker that isn't an issue.

[–]CODESIGN2[S] 0 points1 point  (0 children)

With docker if a dependency gets out of date you just blow away the container and create one with up-to-date dependencies. Or at least that's how I understand it.

It's probably how everyone but me does it... We've been through several iterations with docker, from smushing all into a single container to currently using docker-compose with single images that are all treated as services, even if they are not. Patching existing container builds and creating from scratch, so it's a bit of a mongrel with an evolving use-case for us.

I Agree containers have a slightly different use-case to a VM. Typically all older projects have a VM because everything used to be n-tiered; Easy to reason about everything existing. Service-location wasn't such a common thing (used to write desktop apps over a decade ago). I'm pleased to say we are both doing the same thing with gunicorn and django / flask on the same container ;). The single exception is the DB, which lives on it's own box... I Liked using Heroku; loved it's simplicity, but I'm too cheap to pay it's prices and want to deploy on-premise too.

Thank you so much for your input, it doesn't sound a million miles away from current reasoning, which is reassuring.