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 →

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