![]() ![]() Image: inveniem/drupal-apache:latest restart: "always " ports: MYSQL_RANDOM_ROOT_PASSWORD: "true " MYSQL_DATABASE: "drupal " MYSQL_USER: "drupal " MYSQL_PASSWORD: "changeit " volumes: Image: mysql:5.5 command: -max_allowed_packet=256M restart: always environment: Here's a slimmed-down version of the docker-compose.yml file for the above, which worked for us: Used YAML substitution to DRY-up the environment variables and volume bind path definitions.If we want to reinstall Drupal completely, we can run docker-compose down -volumes followed by docker-compose up -d.after pushing a change to the drupal-org.make file), we can explicitly remove that specific volume with docker volume rm drupal-docker-drupal_drupal_core (where drupal-docker-drupal is the name of the folder containing the docker-compose.yml file). If we need to reinitialize the install profile volume (e.g.Set-up explicit names for all volumes so that they are not destroyed automatically on docker-compose down, allowing us to have control over exactly when volumes are destroyed, as follows:.Set-up a shared volume for the sites/ folder, so that files and custom site settings are shared between the containers and aren't lost when containers are removed.The Drush container depends_on the Drupal container, so that the Drupal container initializes the volume first.The same volume is overlaid on top of /app inside the Drush container, so that it's running off of the same copy of code as the Drupal container.The volume is overlaid on top of /var/www/html inside the Drupal container, taking advantage of the fact that the volume will be automatically initialized by Docker with the contents of that folder from the container (so that the contents of the Drupal install can be shared). ![]() Set-up a shared volume between the Drupal and Drush containers for core, as follows:.Modified our custom, multi-stage Dockerfile to ensure that /var/is copied to /var/file even when using Pressflow with environment-supplied site settings.To satisfy these constraints, we did the following: Unfortunately, both of these characteristics complicated running Drush in a separate container because it needs to be running off the same Drupal codebase that the Drupal container is running off of AND it has to initialize the database the same way (from the environment). So, whenever we need to run a copy of Drupal with our profile, we can just specify the database connection settings via run-time environment variables, launch the image, and be up and running in seconds. In addition, our profile is based on Pressflow, so that gives us the ability to initialize Drupal just by populating PRESSFLOW_SETTINGS, just like Pantheon does. In our case, we have a multi-stage build that assembles a container image around a Drupal installation assembled using drush make. ![]() Could you give me a hint on how to achieve it ? Maybe I did not understand the purpose of this repo or maybe this is due to my short experience with docker and docker-compose but I have not found how to use the repo with several containers. I though the container would live as a normal container and would allow me to manage Drupal. ![]() When starting all the containers, I can see Drush's container working, displaying the list of commands and them exiting.ĭrush_1 | (wd-list) prompt will ask for a choice to show watchdog messages.ĭrush_1 | watchdog-show Show watchdog messages. In my docker-compose.yml file I have defined the following containers: nginx: In order to go deeper, I want to understand how to link a drush container with others containers but unfortunately I have not been able to make it working. I've downloaded the image and run drush as a standalone container like described on the Readme page and it worked well. This is a more a documentation issue than anything else. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |