puntonim / ansible-biostar

An Ansible playbook to automatize the deployment of a Biostar-based project using Docker containers
http://painl.es/ansible-biostar/
GNU General Public License v3.0
10 stars 3 forks source link

Best strategy to rebuild containers #20

Closed puntonim closed 10 years ago

puntonim commented 10 years ago

What's the best strategy to rebuild containers in production?

When we want to rebuild the webapp container we can simply stop it, delete it and build it again because the database and the media files are respectively stored in the postgresql container and the host file system. So we can write an Ansible role to do this.

When we want to rebuild the postgresql container things get more complicated. This container stores data in a volume shared with the host. Maybe we could just stop it, delete it and build it again and automatically PostgreSQL engine recognize those data. In case this does not work we must first export the database in a .sql file and then import it.

When we want to rebuild the entire machine (EC2 instance) we need to export the database, log files and Django media files from the old machine and import them in the new machine. Also, the new machine is going to have a new IP address, so we might want to start using an elastic IP.

brainstorm commented 10 years ago

The objective of the initial ansible-biostar was to create infrastructures from scratch. For the purposes of this GSoC, I wouldn't stretch this much more at the moment since I don't consider @ansible as a (reliable) data migration tool (yet).

As an exercise, I would try what you suggest, since that's what the whole idea of docker containers is about: packaged computation units.

But obviously I would try it first in a controlled environment, see if postgresql picks up the underlying data when recreating it, etc... but in a vagrant box, not in production ;)

Please remember though that this week is all about testing and Travis-CI though, do that only if you have time/bandwidth to do so ;)