Using Wodby https://wodby.com to create a Drupal local development environment using docker.
I have used the official Drupal docker image to create a local dev environment, it certainly does work but does not really tie in with how we currently use and develop on Drupal.
I have checked Wodby drupal4docker and it seems to do what I expect and want the local dev environment.
How to set this up
Obviously there is a documentation on how to set this up https://wodby.com/docs/stacks/drupal/local/ even though the documentation is quite thorough I still struggled a bit so wanted to create a documentation for myself and anyone who happens to stumble on this link.
My setup will consist of a local Drupal 8 code base with custom modules and themes, I save my code base in git including the Drupal code, this may not be really needed in the future as we are moving to using composer but for now I am sticking to keeping the Drupal codebase in my repository.
I also have a separate docker image that I build from this code base which is used for CI and eventually becomes a package which is deployed to production.
If starting a new project use the recommended way to install Drupal with composer like so
composer create-project drupal-composer/drupal-project:8.x-dev drupal8 --stability dev --no-interaction
This will download the Drupal code base, and install dependencies and configure a web root the directory structure looks like this. In the above command “drupal8” is our project root but now where your would traditionally expect the Drupal code base to be, this is under web. For rest of the purpose of this document the project root is “drupal8” and we will use this interchangeably.
Now we will download the latest stable release of docker4drupal which is a collection of files, most importantly the .env file with the parameters which you can define and change to your hearts content and the docker-compose.yml file that defines how these services interact with each other. After copying the files in the project root the folder structure looks like this.
Now we need to delete the docker-compose.override.yml as this is not needed if you use your own codebase and not the Vanilla as it is known. We will also need to create a .env file that allows us to conveniently change the properties without changing the docker compose file, this is much cleaner in my opinion, also the properties may be reused and duplicated hence hence it makes sense to have them in a .env file rather than hardcode in the compose file.
I have created a .env file from https://github.com/wodby/docker4drupal/blob/master/.env we can then remove the properties that we will not use.
I struggled a bit earlier till I realised this would work only If you used the docker for Mac and not docker toolbox, so thats what I did installed docker for Mac enabled the nfs volume section and use the user guided caching to get a better performance for Mac users. So my final docker compose file with things I did not need, removed is as follows (note I have kept portioner and traefik but just don’t show in the docker compose file below for berevity if we decide not to use traefik later we we will to expose the appropriate ports in the compose file.:
We also need to create a docker volume like so:
docker volume create --name=docker-sync
And a host entry for the Drupal site which is 127.0.0.1 drupal.docker.localhost
Also ensure you have docker-sync installed and are running it. If you are just checking the docker4drupal and performance is not that bad, you can just skip the docker-sync parts. The docker-sync uses the docker-sync.yml which is also in the archive we downloaded from docker4drupal earlier. The first time sync will take a little longer but then it should give you a good performance boost. If not using docker-sync the performance will be quite shockingly bad though.
Now we can run docker-compose up -d to create the containers, first time it will be slower as it downloads all the images but following this the Drupal site will be available as http://drupal.docker.localhost:8000, run through the installer, once the site is installed the database files are inside the data folder, docker storage is not persistent unless external volumes are used in this case we have used data folder to store the files. We can also take a dump of the database and keep in our codebase which we can place in the marinade-init folder to pre-populate the site content and configuration.