Let's take the opportunity of my first 2015 day off (yes. It's never too early to take a day off ) to try setting up a dockerized Drupal site. In a previous article, I described my own solution to create a Drupal container. As I was (and I am still) a Docker beginner, I was quite sure that my solution was not a nice one. Anyway, I wanted to understand a few bits of what is under the hood of a container. And trying to create and run some images is, for me, a good way...
But now, I want to set up a real, live web site. And I prefer to rely on an existing, proven solution.
I decided myself on two containers, one for MySQL code and Drupal database, and another one for Drupal. Accordingly, I selected following images on Docker Hub:
The rationale:
I would have prefered the same linux base images, but, well, nothing is perfect...
Available information explains how to use the image:
docker run -d --name drupaldb \
--env MYSQL_ROOT_PASSWORD=<rootPassword> \
--env MYSQL_DATABASE=<dbName> --env MYSQL_USER=<userName> \ --env MYSQL_PASSWORD=<userPassword> --restart=always \
mysql
For another container to access MySQL server, a link must be declared when running the image: --link drupaldb:<alias>. MySQL server is reachable on host <alias> and usual 3306 port.
When the MySQL container is stopped, the linking container must be stopped as well, and restarted after the MySQL container is restarted.
To get the Drupal container, run the image, linking resulting container to the MySQL container:
docker run -d --link drupaldb:db -p 80:80 \
--env DB_USER=<userName> \
--env DB_PASS=<userPassword> \
--env DB_HOST=db \
--env DB_NAME=<dbName> \
samos123/drupal
It seems redundant to specify db twice: once as the alias for the link and once as the value of DB_HOST environment variable. But I discovered that this was required, otherwise drush was not informed of MySQL server host name.
A Drupal administrator is declared (admin / changeme), and allows to tailor Drupal configuration.
That's it! Impressive!