[lambdacomplete]

Nice article but there is a fundamental thing missing: how to deploy and manage the fleet of containers to avoid downtime (e.g. having a systemd service that stops the container(s) and starts them with the new image is not optimal) and centralize logging.

From my experience "deploying" containers is pretty easy: build the image, push the image, pull the image, start container. The hard parts are: how to deal with persistency (I decided to let RDS manage my database), how to centralize logging and monitoring (just Cloudwatch? Swarm? Kubernetes?), how to make sure the cluster is healthy at all times (e.g. a container crashes, is it being replaced? How long does it take?) and how to make sure you have the correct number of containers running (e.g. I want 2 containers for the app server, 3 as workers, 1 as load-balancer).

If you really think about it, once you remove these advantages (from using containers, that is) the difference between running a container and having a script that provisions a virtualenv and adds a supervisor/systemd/initd service is negligible.

[StavrosK]

The post is about deploying a Django app on what would normally be a single server. What you describe can be done with various tools like Kubernetes, but it's outside the scope of the post. The difference is, indeed, not as big when you only have a single server, but it's still nice to not need to run a dozen commands to go from "blank server" to "running app".

If only it were easier to have seamless upgrades, it would be perfect.

[frewsxcv]

I used to be in this situation. Then I started using https://convox.com/ and all my problems went away.