4 ms·

For non-Paas use cases (for example, a development server with a bunch of projects) I find schroot (1) simpler and more productive. For example, you can use the

• fideloper 13y ago
  I've had the same issue with MySQL. It's an issue of timing - You install MySQL, and the MySQL data directory has its data/default databases. Then you share the directory with Docker, and the data lib directory is wiped out (the files don't exist on the host machine, after all). Getting it right in an automated way is a Hard Problem™. As of now, I'm keeping data persisted within the Container, which I don't necessarily like. I would love to hear a good solution on that.
  • izietto 13y ago
    Since I already use schroot and I'm happy with it since it is a mature project I'll continue to use it, keeping a look to next Docker developments.
  • kl4m 13y ago
    As a note, for Debian/Ubuntu, you can recreate the default DBs on a shell with mysql_install_db followed by mysql_secure_installation .
  • tonyhb 13y ago
    Here's a dockerfile setup I wrote for Postgres which uses a 'data container' for the entire Postgres database: https://github.com/codelittinc/dockerfiles/tree/master/postgres https://github.com/codelittinc/dockerfiles/tree/master/postg... The gist of it is that you explicitly tell your DB container that there will be a shared directory on the container at runtime. This allows you to chown the directory before the data container is added. Then, when you're running, use --volumes-from `$data-container-name` and it'll work. Want an article on it?
    • fideloper 13y ago
      Awesome, thanks. I can figure it out from that example most likely, but an article would never hurt :D
    • kevinschumacher 13y ago
      An article on that would be great!
  • cpuguy83 13y ago
    That's actually not true at this time. When you turn a directory into a volume, Docker will copy whatever the contents of that directory into the volume directory... But you need to make the volume after the directory is populated.
• vidarh 13y ago
  Here's one benefit you get with docker: Speed of rebuilds, and ensuring that your build instructions and list of dependencies accurately reflects your actual environment. I basically have a "basic dev setup" container for all my projects now, and each new project sits as sub-directories of a directory on the host that I bind mount into the docker containers. Each project then also has a Dockerfile which adds any project specific dependencies. Building a fresh container then takes a couple of seconds. And the projects run within those containers only. Ever time I restart the apps in my development environment, I rebuild the container, because it is so cheap. Which means I know at any time that the container can be rebuilt to a state the app will run in. I know when I want to deploy that the Dockerfile accurately reflects the dependencies, because otherwise my app wouldn't be running in the dev environment, as any and all changes to anything outside of the application repository are only applied through changes to the Dockerfile.
  • izietto 13y ago
    Sure, but speed of rebuilds is important when you rebuild often, which is not my case. In my case the Dockerfile is easily replaced with a bash set -e script, which has never gave problems to me: deboostrap, share volumes, aptitude install apache/nginx, mysql/postgresql, php/ruby, copy files, predeployment commands like f.e. bundle install, start services. And you have the advantage of starting services with `service start ...`, instead of reinventing init scripts.