This document summarizes the use of Docker for a multisite Drupal development workflow. Key points include: - Using Docker images and containers to share database layers between similar sites, improving build speeds. - Implementing a "lazy" continuous integration workflow with a parent PR builder and child builders for specific sites/tasks, run in parallel. - Introducing scripts to pull the latest database from production into a Docker image, then reusing that image for reinstalls rather than importing the full database each time. - Describing how the Docker-based approach works on both the CI server and local developer environments. - Noting some potential issues with Docker stability and leaving garbage,

1. YMCA of FFW
internals of the project
Docker SQL development flow

2. Multisiting
● drupal.192.168.56.132.xip.io
○ -> ymca.ffwua.com/buildX
○ -> ymcamn.org
● openy.192.168.56.132.xip.io
○ -> openy.ffwua.com/buildX
○ -> openymca.org
● redwing.192.168.56.132.xip.io
○ -> redwing.ffwua.com/buildX
○ -> prod...

3. DevOps
● SQL Flow => Docker SQL Flow (Multiprocessing speed improved a
lot!!!)
● Lazy PR Builders
○ Parent(main) PR builder
○ Child OpenY builder (non blocking, lazy)
○ Child Redwing builder (non blocking, lazy)
○ Child Behat tests job (non blocking, lazy)
● Local dev - Reinstall with Docker container. Speedup for reinstall a
lot!!!

4. Docker images, containers, huh?
● Image - gzipped aufs(layered* filesystem) of the files (eats filesystem size
only)
● Container - running image (eats memory).
● Layers are gzipped aufs images that are shared between similar images
and containers in order to save filesystem space.
Same as Vagrant box and running virtual machine.

5. Multisiting CI DevOps - lazy builders

6. Multisiting CI DevOps - lazy builders

7. Multisiting CI DevOps - parent PR builder
Parent PR builder
1. Deploys code
/var/www/buildX
2. Runs sniffers
3. Runs reinstall.yml for YMCA
site
4. Posts comment to GitHub
5. Runs sub-projects builds
Child PR builders
1. Deploy code /var/www/prjY
&& /var/www/prjZ
2. Run reinstalls there

8. Multisiting CI DevOps - Docker DB tricks
Introduced script get_latest_db.sh (1-5 minutes for a run)
1. Pulls cibox/mysql Docker image locally
2. Runs it as a DBPROD container
3. Imports 3 databases from productions within
4. Commits DBPROD as dbprod Docker image locally
5. Cleanup everything
Reinstall process
1. Introduced docker_sql_flow.yml when docker_sql:
true
2. Instead of importing PROD db every reinstall(1 -5
minutes), pulls* a docker container from dbprod as
buildX named container (1 sec)
*pull means check if image changed on own hub on CI
server
Decoupling CIBox ^^^

9. How it works on CI side

10. How it works on local DEV and CI builds

11. Multisite GitHub comments && statuses. Behat.

13. Issues
● Docker %)
● Docker is not stable, tough versions dependency (1.12.0 should be used)
● Docker able to leave a lot of garbage within your system
○ Make sure docker images and docker ps -as commands make you happy enough in
terms of count and sizes.
● Overall CI complexity, can bring us some unexpected behaviours

14. Thanks for listening
Andrii Podanenko for FTT
andriy.podanenko@ffwagency.com
2016