A list of published Red Hat containers can be found here. We use the rhel7 Docker image as a base for running Drupal. You might notice one important piece that is missing: the database! It is assumed that your database host exists outside this container and can be connected to from this application (it could even be another running container on the host).Īlso note, this is mostly an image used for testing and spinning up environments quickly right now, but as we vet our continuous delivery process the structure of this file would likely change. This is essentially how our Docker image was formed.īelow is the Dockerfile we use to deploy Drupal inside a container. Imagine drawing a circle around all the parts that existed on the host that define our Drupal app. The application developer can define the entirety of the Drupal application, all the way from installing Drupal core to supplying our custom code. The host that runs this container can have the tools it needs to run Drupal with the appropriate monitoring. Docker doesn't solve this simply by shoving all the code inside a container, but it does allow for an agreement to be established as to what our Drupal developers are responsible for delivering. Our Drupal team wanted to deliver one artifact that defined the entire release of our application. You can probably see how unwieldy juggling over one hundred modules with custom code can become. Developer environments were also different in that they didn't always have a packaged RPM for delivering code, but instead the custom code repository would need to be directly accessible to the developer. However, for our CI environment, in order to speed up the application delivery there, contributed Drupal module installs had to be done manually by the developer (mainly to support integration testing in case that module needed to be removed quickly). For our close-to-production and production environments, this centered around versioned RPM updates via puppet. Packaging a Drupal module inside of an RPM adds that extra abstraction layer of versioning as well, so our developers didn't always know exactly which version with patches of a module may be installed.Īlong with RPM packaging, there wasn't a unified way in which code was installed per environment. As our developers began to take over more of the operational aspects of Drupal releases, the process of the RPM packaging didn't flow well with the rest of coding that our developers were maintaining.

The issue with this process for Drupal is managing many RPMs (we use over 100 Drupal modules on the Customer Portal). This process of bundling Drupal modules inside of RPMs made sense for aligning ourselves with the release processes of other workstreams.

The method of defining our installed Drupal modules centered around RPM packaging. We hope to always iterate on how code gets released to our customers, and containers seemed like a logical step to speeding up our application delivery. With the excitement around containers and Docker, the Customer Portal team at Red Hat wanted to take a look at how we could leverage Docker to deploy our application. API // src/Controller/MailerController.Docker is a new technology within the past few years, but many know that linux containers have been around longer than that.

Drupal 9 docker