Implementation note: this uses an init file for the python app, which will depend upon what OS and init system you're running it under. Also missing handlers for restarting services when config files change.
Re:Docker orchestration
by falcolas on Monday February 09, 2015 @01:39PM
(#9022801)
No, though to my mind the separation is not really required for this trivial of an install.
I would want the separation if I was running untrusted code, or if I was running custom software which required non-standard library dependencies. Then I'd want to split off that code, not necessarily every process.
Nginx and PostgreSQL in particular written well enough to compartmentalize themselves within their own processes, and don't typically require additional isolation.
Re:Docker orchestration
by kylek on Monday February 09, 2015 @10:55AM
(#9021776)
The post mentions losing database data when doing a "rm". Couldn't you set a volume parameter on the postgres container (to /var/lib/postgres or wherever data is stored) to prevent that? Or am I missing something?
Re:Docker orchestration
by berbc on Monday February 09, 2015 @12:16PM
(#9022285)
It's a bit of a basic overview of docker-compose. I would have liked to see how to handle more sophisticated patterns such as the data volume container, and how to manage database initialization, both in development and in production.
well ideally you would have a script to create the DB and possibly migrate it. IE this will create a PG database from `DATABASE_URL`
then it's simply a matter of `fig up` + `fig run web python manage.py createdb`> The best solution probably is to create a new database during image creation, but in the official Postgres image this option is still not available.
The official image's README (https://registry.hub.docker.com/_/postgres/) says otherwise - both a user and a database will be created with name $POSTGRES_USER (if set).
Furthermore, one can run postgres in single-user mode to prepare any initial db image on top of the official one.
I would want the separation if I was running untrusted code, or if I was running custom software which required non-standard library dependencies. Then I'd want to split off that code, not necessarily every process.
Nginx and PostgreSQL in particular written well enough to compartmentalize themselves within their own processes, and don't typically require additional isolation.