Prevent database from meeting it's maker after container has been destroyed.

[artursv]

Docker containers are super easy to get rid of. Which is nice unless you have a database container where your current work-in progress is stored. It's way too easy to hit wundertools down on the Friday afternoon and watch un-exported Drupal data disappear.

We could use Docker volumes to solve this. Mysql data will be stored in volume db-data which stays intact even after container is destroyed.

I'm not 100% sure for how long these volumes are stored. My guess - until the end of time because wundertools create some volumes that are used for storing some log files i think and those still haven't gone anywhere from my system since I started testing the tool.

[aleksijohansson]

@artursv I think this is a very welcome improvement. I was just thinking about the same issue. Testing this now.

[aleksijohansson]

@artursv This seems to work perfectly fine for me.

[james-nesbitt]

What we need to do is get some idea from users what good behaviours should be. I will cross-reference with Ilari and Janne about good behaviours on the server.

FYI: most other organizations are considering the volume route, as it allows easier upgrade of db servers, and keeps the db service generic (like our php and www services.) I am considering using distributed db images, but will not push the idea if it is only me.

[james-nesbitt]

@artursv volumes are persistant until you run "docker-compose down -v" or manually remove them using "docker volume"

[james-nesbitt]

Incidentally, the milestone to which this PR was attached is closed really. I will create a new one.