Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiments in Assets, and bootstrapping Drupal #4

Closed
wants to merge 8 commits into from

Conversation

birkland
Copy link
Contributor

@birkland birkland commented Feb 13, 2020

Overview

Basically, this PR started as an approach to using an "assets" image for storing local state (drupal add-ons and config, mysql dbs, solr, etc). These experiments revealed a flaw in the recommended approach to "volumizing" local content in Drupal. I observed:

  • The recommended mount points for Drupal are /var/www/html/{modules,profiles,sites,themes}
  • Drupal presumes content in /var/www/html/sites, which using an assets image provides.
    • In other words, Drupal presumes there is stuff in /var/www/html/sites.
    • Unfortunately, that "stuff" can't be provided by the Drupal image, since /var/www/html/sites is a mounted volume
    • Using the assets image as present in this PR provides initial content for the volume, as provided by a tar file at build time.
      • Look at the contents of the tar file used in this PR: tar -tf build/assets/data/assets.tar.gz. This is the most basic assets content that makes "an empty Drupal work".
  • In order to create an initial Drupal site, it's necessary to (1) Create a mysql user with the appropriate permissions, (2) Use Drush to do a site install, (3) Add any necessary modules. I was intending to script this, then create an assets snapshot from the results in order to "bring a Drupal site up quickly with docker-compose up -d.
    • Right now, I have a script bootstrap.sh inside the assets image which can be manually run in order to do this: bootstrap.sh
  • Unfortunately, installing a theme and the solr module results in the addition and modification of php files outside of the recommended mount points of /var/www/html/{modules,profiles,sites,themes}. In fact, it looks like anything under /var/www/html is fair game for installation or modification using composer. Thus, I believe /var/www/html itself has to be a mounted volume, as it's all local state
    • I think implies that a Drupal installation itself is "local state" as far as volumes are concerned.
    • I think that also implies that there can be no such thing as a "Drupal image" that provides any initial content under /var/www/html, including Drupal itself

Try it out

This will illustrate the issues above. Check out this PR, and do the following:

  • Build the images: docker-compose.exe -f docker-compose.mvp1.yml build
  • Start the stack: docker-compose.exe -f docker-compose.mvp1.yml up -d
  • At this point, Drupal is running with the sites content in a volume, provided by the assets image. Hop into that container to verify
    • Get a shell in the Drupal container via docker exec -it isle-dc-drupal-idcp bash
    • Do ls -l /var/www/html/sites, you'll see it's a symlink: /var/www/html/sites -> /mnt/assets/sites
    • explore /mnt/assets. This is where the Drupal assets are mounted.
    • Do ls -l /var/www/html/sites/ (note trailing slash). You can see the site files provided by the assets image.
    • Exit out of the shell
  • Now, we're going to run a script that creates a mysql user, and installs a drupal site.
    • Run docker exec -i isle-dc-assets-idcp bootstrap.sh. It'll take a couple minutes to finish
  • Verify the site works, go to http://localhost:8080. Log in as admin:islandora if you want.
  • Ideally, nothing significant in any base image would change in this process. We want all state changes to be in mounted volumes. Unfortunately, that's not the case. Do a docker diff:
    • docker diff isle-dc-drupal-idcp | grep /var/www/html D'OH!
  • We can dump assets images into a tar. Unfortunately, because installing Drupal themes and modules added content outside our mount points, the resulting assets image wouldn't capture everything it needs. But we can do it anyway just to see it
    • docker exec -i isle-dc-assets-idcp dump.sh
    • Look at the resulting build/assets/data/assets.tar.gz file in your locak directory. It has a lot more in it, doesn't it
    • If you do a build, Docker will create a new assets image using that newly dumped assets file. These images can be pushed just like regular Docker images, but their distinguishing characteristic is that they seed volumes with whatever content has been baked in them during a docker build, originating from the tar file. This is where the magic lies, IF we get the mount points for Drupal right!

Assets tar contains files from a stock Drupal install, and nothing else
We mount drupal assets at /mnt/assets.  This symlinks the appropriate
/var/www directories to their equivalent in /mnt/assets
The bootstrap script will add the required Mysql accounts for Drupal,
and use drush to bootstrap a Drupal instance

The entrypoint keeps the assets container 'running' so that I can poke
at it and debug.
Attach it to the internal net, and expose the docker socket so it can
issue remote commands.
@birkland birkland closed this Mar 12, 2020
dannylamb pushed a commit that referenced this pull request Jun 18, 2020
Updating SOLR core back to ISLANDORA to match buildkit. Cleaning up R…
@birkland birkland deleted the add-assets branch November 17, 2020 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant