Whatever your standard environment setup, it is inevitable that each project brings some new wrinkle. Outrigger's Docker image library endeavors to make the most common variations of your environment configuration really easy to adjust. Without building a custom Docker image or overriding your configuration files, our images can be tweaked for your most typical needs.
You may be wondering, "Why do we need to discuss templating and container details as soon as something common needs to change. Are containers too much for my needs?" You are not alone in wondering that.
The short answer is that these extra steps ensure that:
Once configured, nobody else using the project will have any additional steps to take for this setup.
You continue to have the guarantee of consistent environment behaviors for every member of your project team.
Templating is for combining content and HTML markup, right? That's the standard use around web development, but the infrastructure automation world has been using templating for years, in many different ways, for the same reasons: capturing business logic in a testable, versionable manner separate from the specific ways that logic might be needed. It is a key mechanism for reuse.
There are many tools that can help us with environment templating; however, confd is our favorite as a lightweight tool that works well in the stripped-down space of a Docker container. It uses templates written in Golang's native templating language and can take environment variables to dynamically populate that template and position the resulting configuration file when your container is started.
This templating can be used to create or modify any file inside the Docker image, and the simple environment control mechanism makes it really simple to configure via docker run or docker-compose configurations.
Examples of Tunable Outrigger Configuration
If you are using Outrigger to facilitate Drupal development, you are very likely to be using Redis, MariaDB, and Apache w/ PHP-FPM from the Outrigger image library. Each of these has at least one configuration option via templated environment variables. They can be seen in each image README on Docker Hub or GitHub:
outrigger/redis allows configuring which IP address to bind to via REDIS_BIND
outrigger/mariadb allows configuration the mysql password and database name that is automatically created when the container is started without existing data, as well as various configuration values to tune logging, caching, and connections
outrigger/apache-php-base is the common foundation for all Outrigger's supported PHP versions, and it provides various configurations of memory usage, file upload size, Opcode Caching, and the ability to enable or disable key PHP extensions like Xdebug, XHProf, and YAML
outrigger/build is our developer workbench-in-a-box, and allows toggling the Node version, Xdebug settings, and manage other extensions
Other images also have these kinds of environment settings, they are documented in the image README when present.
How to Tune Configuration with Environment Variables
None of these tunable settings require you to take an explicit action. All of them have sane defaults that we have found are effective for most projects. However, if you need to override these settings, simply use the standard techniques for injecting environment variables into Docker containers.
Using docker run for a one-off container
Run the following command to open a BASH session in the outrigger/build container, with Xdebug active for CLI troubleshooting.
[bash]docker run --rm -it -e "PHP_XDEBUG='true'" outrigger/build bash[/bash]
Using docker-compose to manage the environment as project configuration
Use a docker-compose.yml configuration like the following to spin up a database for your project.
[yaml] version: '3.3' services: db: image: outrigger/mariadb:10.2 environment: # HERE ARE THE DATABASE CONFIGURATION PROPERTIES MYSQL_DATABASE: projectname_drupal MYSQL_SLOW_QUERY_LOG: 1 # For the sake of completeness, here's how to wire up this test database to Outrigger's DNS system. network_mode: bridge labels: com.dnsdock.name: db com.dnsdock.image: projectname [/yaml]
Once in place, you can spin up a new database with docker-compose up.
In future posts we will dive deeper into what you can do when these common customizations don't handle your needs, as well as how to build and contribute to Docker images using these tools.