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.
#DRUPAL CONTAINERS CODE#
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.
#DRUPAL CONTAINERS INSTALL#
Now you can visit localhost in your browser to access the Drupal WxT install wizard.Docker is a new technology within the past few years, but many know that linux containers have been around longer than that. $ make docker_start View Drupal WxT in a browser Now we can start the Docker containers by running the following command. Next run a make command to build our Docker containers. $ composer install Build the Docker containers Now use composer to pull all of the dependencies into our project. We do this by cloning the drupalwxt/site-wxt repository. The first step is to setup the WxT composer template. Clone drupalwxt/site-wxt composer template
It automatically pulls in the docker scaffolding for us and uses docker-compose to build our docker containers with networking. In order to take advantage of the docker-scaffold setup, use the site-wxt composer template. The Drupal WxT distribution provides a good starting point for any GoC application, especially those that will be using the GCWeb ( Canada.ca) or GCIntranet themes.
0 kommentar(er)
