One of the biggest limitations of Docker that I haven’t seen solved yet is how to run databases. Do you mount a file system folder and store the database there? Then you have issues with multiple databases hosts and persistence. Does this mean that you are supposed to put the database on an ordinary host and just connect to it from the webapp containers? Now you have two different types of things to manage.
Mind you, I don’t have a ton of experience with Docker. I’ve just used it for some personal projects, but this seems like something that should be solved.
infact the normal way to manage databases is locating them on a different server from your app servers, and then connecting to them in that fashion.
it works out nicely, often, because they are in the same network as you; so access is fast, and they don’t need to be accessible externally (aside from management). so if you simply using docker for app deployment, it shouldn’t affect how you manage your dbs.
For small apps, you can mount a local filesystem within a container running, say, Postgres. You’re encouraged to do this because storing things in a container is a bad idea. See the guide for more details.
Docker also has mechanisms to provide DNS-like names to other containers in an easy fashion.
Why do you need working apt-get in an image that you’re deploying 10 times a day? If you need to upgrade something, can’t you just spin up another image?