What OS are you using on your host machine? I’ve heard of issues with volumes on Windows boxes and volumes not mounting properly after a restart, so may be related.
CentOS7
After the restart all was fine but the lost edits. Small stuff really. Interesting twist, the DB records were not touched. Postgress also via docker, also restarted.
So if I understand your post right, restarting a volume should not roll back the changes, it’s not like I deleted it and started anew. Right?
Strange.
That’s correct, at least to my knowledge. Changes made to the files either through the container or on the host itself should persist after restarting the container.
Just my bad luck then…
What’s your advice for production.
Should I use the docker version of the App? or install it directly in CentOS7?
My main concerns;
- Stability
- Managing Backups
- Updatint the App
Different methods for different needs. Have a persistent volume by specifying a folder (or go crazy like I did, using a driver to connect a network remote storage at one point). Some people prefer to not use persistent volumes, but to have a stack that can rebuild it’s data from source material as needed, which makes the docker containers truly portable and disposable.
Treat this as your new religious text: GitHub - wsargent/docker-cheat-sheet: Docker Cheat Sheet
3 Likes
I’d honestly just say to do what you’re most comfortable with. If you’re having concerns and issues running the Docker version, then perhaps just stick to a native install. Or if you’re feeling adventurous and want to learn something new then go for Docker.
As far as stability is concerned, the app is likely to be just as stable in either environment. Debugging is a bit more challenging with Docker containers, but it’s not too bad once you get the hang of what to do. Backups are likely to be just as easy with Docker containers since you can backup the entire container, or copy individual files out of the container onto the host (via docker cp). As long as the app devs put a convenient way for updating the app, you should be fine with the container – but do note this can vary widely from app to app and you’ll likely want to do some test runs now to make sure it’s straightforward before committing.
1 Like
Quite honestly, I only tried the docker version because going native went badly for me.
The app was munching the CPU and getting unresponsive in the process.
As far as I know the difference was that I installed it with MySQL and the docker version uses PostgreSQL.
I religiously followed the instructions but I guess I fked up something probably because they omit something assuming its common sense…
1 Like
Yeah, Docker is certainly useful in that aspect because (when done right) your dependencies are installed, configured, and ready to go right out of the box.
I feel you there. If you know where your data is in the container, you can map it to a local folder like this:
-v /path/on/host:/path/on/container
That maps /path/on/container to /path/on/host and that data persists.
Yeah, I figured that out by searching for the favicon lol.
1 Like