By mrbagnall | 22 May 2017
When it comes to managing your cargo, it's hard go wrong with Docker. In fact when done properly, Docker and Drupal can be a formidable partnership for development and functionality. It can also bridge knowledge limitations presented by different technologies and your familiarity with them. Here I demonstrate a running log of how I implement Drupal with Docker containers for deployment. And provide a skeleton for you to do the same.
This article seeks to provide a basic introduction as to one way of implementing Drupal with Docker using a combination of custom Docker images and specialized Docker Compose scripts and file structures. This includes a basic MariaDB database but could also easily be expanded to include Memcached and SOLR if you want. We will cover those in a future article.
I have prepared a custom Docker image for Drupal 7 (and one for Drupal 8 we will discuss in a future article) as well as a Drupal skeleton git repository to serve as a model for building out your site with contributed and custom modules. You can find the drupal-skel repository by going to:
Once you have checked out the skeleton repository you should remove the .git folder inside the folder so you can add this as your own site repository later. Now you can issue:
docker-compose up -d
And have a fully installable instance of Drupal 7 ready to be installed and then modified and used.
There is a lean set of contributed modules which come with our Drupal 7 template Docker image. These include: admin_menu, token, entity, module_filter, devel, views, ctools, date, oauth, memcache, googleanalytics, smtp, and jquery_update. It is important to note that none of these contributed modules require a custom library. This is intentional due to the structure of our local folder system including a libraries folder for your custom and site-specific contributed modules.
Any other modules you wish to add to your site should be added in the "modules/contrib" folder in your local git/skeleton directory. The same holds true for themes and libraries in their respective locations.
Once we have our instance up, we can simply go to:
This will bring up the Drupal installation screen where you can run through the standard installation process. Once this is completed, your settings.php file will live inside your git repository. This is so that it can be committed with your project for safe keeping. Keep in mind this may contain sensitive data about your configuration, so I recommend using private repositories for your Drupal sites based off drupal-skel.
Lets take a look at the docker-compose.yml and the Dockerfile associated with this project. First we will look at docker-compose.yml to see how our database and web server are configured by default.
I find it useful to specify the container_name and to make it unique for each service and each site. Otherwise, Docker Compose will name your containers after the folder name that contains your docker-compose.yml file. You can change the ports configuration to another port. The first number represents the port exposed to the outside network and the port to which it maps on your container.
The volumes represent mounts where various file systems are held. These should be self explanatory. The database volume is design so that if you have a database you wish to import into your container, you can place it in that folder to have it accessible to your web service container. From there it can be easily imported into your MaridDB database.
This is the configuration for your Maria database server. It is in a separate container but is accessible via Docker's internal networking. They are connected automatically. Based on the "depends_on" configuration under the web service, it will wait for MariaDB to come up first before completing the web service container.
You can change your usernames, passwords and databases here as these are placeholders as well as set your other configuration options. There are additional environment variables available which can be found by going to:
You can also configure SOLR and Memcache here as well very easily, but that will be covered in a separate article.
Note that the image name contains a specific version of MariaDB. If you are looking to make your configuration stable and more Enterprise ready, it is best to specify versions and not rely on the "latest/greatest" release unless there are security reasons to do so.
It is worth noting that the mbagnall/linux:d7 Docker hub image is maintained for Drupal 7 and 8 and will be for the foreseeable future. You can also create your own image based off this and reference it in the image attribute under the web service. If you wish to create your own image, keep in mind there are pitfalls currently with third party libraries for some contributed modules and getting them installed by default as part of your Docker container. This is why I have avoided doing so in this demonstration.
In our next article (next week) we will look at the Dockerfile for this and go through not only how to install Drupal via Docker containers and images, but also how you can maintain the modules in your installations without having to rebuild your web service Docker container.
Future articles will include working with Apache SOLR and Memcached as well. We will also talk about how you can have manage multi-site installations of Drupal with Docker and still allow each site to live within its own git repository.