I’m new to docker (and a relative Linux novice). I’ve set up Docker on a Lubuntu 16.10 machine and installed a mediawiki container using info from here:
How can I automatically restart my mediawiki container whenever the machine is rebooted?
How can I persist any new data written to the container (e.g. new wiki articles written) between restarts? At the moment I lose everything (including my mediawiki config) every time the container is restarted.
Ok so presumably the database shouldn’t be run in a container for the same reason (i.e. that the container is ephemeral)? My instinct is that maybe I shouldn’t be using Docker for a permanent installation of this type (i.e. that it’s better suited to development or test uses where persistence isn’t required) - would you say that was correct?
no… just design it so that the data is stored on a host volume, the database should be a container, with its storage on a host volume… so that you can change the containers any time u need to…
rule: do not store volatile/important DATA inside a container…
easy to do.
there is no magic here with docker. you still have to do all the normal system design work. then using docker can help speed up the deployment, and reduce long term maintenance.
I see what you’re saying. At the moment I’m weighing up the complexity of setting this up in containers (I’ve been struggling with docker for a couple of days and found it hard to get to grips with). I originally chose this path because I liked the idea that the container encapsulated all of the resources required for the solution (app, database and file system), which would have made it really easy to deploy, and also to backup and migrate (if necessary).
It looks like if I continue with this approach then I will have 3 interdependent components (mediawiki container, database container, host database storage), which would not only take me an eternity to work out how to configure and link, but would also not be as simple to backup or migrate as I’d hoped.
Since this is all sitting on a VM my backup requirements are pretty simple (I’m just backup up the whole VM), so the primary benefit of ease of deployment doesn’t seem to apply to me in this case.
its the same work either way. you still have the same interdependent components, the same config, and the same issues…
deploying them all on the same system for production is a risky design.
docker solves some problems, but not all.
no software install
in many cases the container config is the developers best practices.
you can run different containers at different levels on the same host at the same time
you can move a component to a different network location, and even provider who supports docker, without worrying about host os level, fixes, patches, etc,etc,etc… with a tiny config change to the container startup.
As this is far from a mission critical app, and I’ve found it so hard to get to grips with managing docker containers, I think I might go with a Bitnami stack for deploying mediawiki. Backing up the whole VM is much simpler for me than separate backups for application/OS and database.
Maybe I’ll come back to Docker another time, perhaps for an application that doesn’t require permanent data storage.
Many thanks for your feedback - much appreciated.