3 ms·
I’m not the parent but I’ll pitch in on this as I have a few client projects using docker compose for production. No downtime deployments: I don’t bother for t
by vbsteven 5y ago
I’m not the parent but I’ll pitch in on this as I have a few client projects using docker compose for production.
No downtime deployments: I don’t bother for these projects. A minute of downtime in off-peak hours for a restart is fine.
Data backup: just like you would backup any other local data: cron, rsync, pg_dump. And there isn’t much local data anyway as most services are stateless, using S3 or a database for long term storage.
I choose docker compose for production when I want to keep complexity to a minimum: All I need is a cloud vm, an ansible playbook to install docker and configure backups. Typically in these scenarios I run the database as an OS service and only use docker for nginx/redis and application services.
- angrais 5y agoWhy do you use the database as an OS service and not in docker? Using it in docker would allow easier local development, and shorter setup time.
- vbsteven 5y agoFor local development I run the full environment including the database in docker compose. For production some of these projects run alongside each other on the same host and share the database service. Sometimes the database is on another host. A typical host like this would be a 50/month Hetzner dedicated machine with only docker daemon and postgres installed natively. And then multiple projects deployed with docker compose. Sometimes nginx is native as well with vhosts pointing to the docker projects. Edit: s/ghosts/vhosts/
- axlee 5y agoIt is really not recommended to run (production) databases in Docker, unless you know what you are doing. https://vsupalov.com/database-in-docker/ https://vsupalov.com/database-in-docker/