Add instructions for running Drupal VM inside Docker

[geerlingguy]

Issue Type

• Feature Idea

Your OS

• macOS (10.12.3)

Summary

While doing some debugging for a 4.2.2 release (see #1200), I was just thinking to myself... we already have test rigs set up for Travis CI that builds and runs Drupal VM inside Docker.

And someday there may be an official set of Docker Images for Drupal VM (though maintaining a similar architecture to the current incarnation of Drupal VM)... but in the interim, we could at least provide some instructions for how you could run Drupal VM on top of Docker, bypassing Vagrant entirely.

This would be fully experimental for now, and there are a bunch of conveniences Vagrant adds that Docker can't at this point (at least not without an insane amount of extra spaghetti work), but it's doable, and in some cases it's faster than Vagrant-based builds.

[geerlingguy]

Scenario 1: Just building a local Docker container to replicate what our tests do:

1. docker run --detach --add-host $(HOSTNAME):127.0.0.1 --volume=$(pw d):/var/www/drupalvm:rw --privileged --volume=/sys/fs/cgroup:/sys/fs/cgroup:ro geerlingguy/docker-centos7-ansible:latest "/usr/lib/systemd/systemd"
2. docker exec [container-id] mkdir -p /var/www/drupalvm/drupal
3. docker exec [container-id] env TERM=xterm ansible-playbook /var/www/drupalvm/ tests/test-setup.yml
4. docker exec [container-id] env TERM=xterm ansible-playbook /var/www/drupalvm/ provisioning/playbook.yml

[thom8]

@geerlingguy have found this incredibly very useful for CI - https://hub.docker.com/r/beet/box/

Can run docker run -v $(pwd):/var/beetbox -p 80:80 beet/box in a project dir to quickly test stuff out, as it's a full clone of the preprovisioned base box.

[thom8]

Also converted tests to run with docker & robo -- https://github.com/beetboxvm/beetbox/blob/master/RoboFile.php

loving robo :)

& composer scripts -- https://github.com/beetboxvm/beetbox/blob/master/composer.json#L29

composer test

[oxyc]

I would love it if I could run the tests locally with just a simple composer test.

[thom8]

@oxyc all my projects now have a composer test which is usually just an alias to a set of test suites for that particular project.

Makes it easy to remember how to run tests, like composer polymorphism.

[geerlingguy]

++ to all the above; right now I manually run a few docker commands when I want to run tests on a given role/project. I'd be happy to wrap things a little better to get the tests runnable with one command.

[oxyc]

Two thoughts:

1. One minor annoyance is that we currently allow config files and pre/post provision scripts to reside anywhere within the project and this makes it a requirement to sync both the codebase to /var/www/drupalvm and the entire project tree to /vagrant (or something similar in Docker's case). Would be nice if we could remove the /vagrant dependency by looking up the config files, the pre/post provision scripts and then copy them to the remote together with the playbook and the roles. With Vagrant the current setup doesn't bother me as I have /vagrant as an NFS mount, but as a macos user with docker I guess I would use rsync which would transfer the sites/default/files directory twice.
   Furthermore, users can also override template files for some roles, and if the files I mentioned before would be somewhat easily solvable by a few tasks that normalize the locations on the remote, this one makes it pretty much impossible to solve unless we somehow enforce a config/ directory.

2. I can live without most of Vagrant's convenience features but being able to configure the synced folders without hacking a Dockerfile would be my top priority. Is docker-compose.yml the solution here?

[thom8]

@oxyc could having a .drupalvm directory work? along with a config playbook

This means we can assume the config location -- https://github.com/beetboxvm/beetbox/blob/master/Dockerfile

[oxyc]

Yes that would work but would remove the convenience of being able to point pre/post provision scripts straight into to the examples directory (or another composer dependency).

Edit: Not sure if we should prioritize Vagrant and just live with the annoyance, or make docker more of a first class citizen.

[thom8]

This was one of the primary reasons behind moving to composer only support, we can now also assume that the project directory is at [vendor directory]/beet/box which would be available in the sync directory/volume.

Therefore, the config can be pulled directly from either location.
Still WIP on the composer side of things

[geerlingguy]

(And to reply to the question earlier, yes, I think it would be easiest to do what you want to do via a docker-compose.yml file rather than verbose commands.

Will either of you be present at DrupalCon Baltimore this week? Would be awesome to meet up!