Refactor deployment #159
Refactor deployment #159
Conversation
When installing modules as part of local development, Composer adds the files for those modules. This commit updates .gitignore to exclude those files from the repository so we can manage those changes more efficiently.
This repository has essentially been based in an existing `/web/` directory. Moving most of its files to a new subdirectory will allow us to include the files that have been one level above this.
This is part of reorganizing these files within a `/web/` directory.
Drawn from github.com/18F/cf-ex-drupal/. h/t @pburkholder
| # Ignore configuration files that may contain sensitive information. | ||
| sites/*/settings*.php | ||
| sites/*/*settings*.php* |
There was a problem hiding this comment.
Something to keep an eye on: we may want to include these settings files in the future, but keep all the sensitive info in env vars (via user-provided services). File-based configs don't play too well with the 12-factor app design.
| @@ -0,0 +1,3 @@ | |||
| --- | |||
| packages: | |||
| - mysql-client | |||
There was a problem hiding this comment.
Looks like we're just using the PHP buildpack now -- is this file still needed?
bootstrap.sh
Outdated
| @@ -0,0 +1,38 @@ | |||
| #!/bin/bash | |||
| set -euxo pipefail | |||
There was a problem hiding this comment.
Something else to keep an eye on: we probably don't want to echo every command (notably, those that include sensitive env vars), lest they be caught in the CI logs.
There was a problem hiding this comment.
Good call, thank you!
| @@ -0,0 +1,29 @@ | |||
| # Ignore directories generated by Composer | |||
There was a problem hiding this comment.
For later: there's a deployment consideration here -- we could include these dirs in the cf deployment (i.e. vendor our dependencies). That'd ensure consistency and slightly speed up restages at the cost of high likelihood of error (e.g. sending up something compiled for OSX).
bootstrap.sh
Outdated
| drush --root=$HOME/web core-status bootstrap | grep -q "Successful" || bootstrap | ||
|
|
||
| drush --root=$HOME/web pm-info flysystem_s3 --fields=Status | grep -q enabled || | ||
| drush --root=$HOME/web pm-enable --yes flysystem_s3 |
There was a problem hiding this comment.
Neat! I think we'll need to insert the config-loading code around here.
I didn't see any of the ".bp-config" stuff which is what would pull this script in.
Drawn from github.com/18F/cf-ex-drupal/
Theoretically this precludes the addition of custom modules. May want to scale back to /contrib at some point.
Brightcove API credentials have been redacted.
This doesn't include multiple instances and only covers the demo app, but should be enough to get us started.
In an effort to closer align with the cloud.gov Drupal example, this adds a handful of dependencies. It looks like the previous code was also built with a generator, so this shouldn't be a big issue. All of the previous Drupal modules should still be present. Notably, however, this *does* declare that we're using PHP 7.1.
These are largely auto-generated, but we don't want to recreate them every time an instance restarts, so we'll commit them to the repository. The exception is the settings.cf.php file, which configures the database connection, flysystem, and the hash salt based on values injected by cloud.gov services. The values can be missing (e.g. if running locally), and a local settings file can be used instead.
This pulls in more configuration from the cloud.gov example. It uses their bootstrap.sh as a guide, but ends up rewriting it to leak less information and to make use of our settings files.
It's not used and now misleading.
The uuid isn't sensitive, so we're safe to include it (it might be referenced by other configs in the future). This also removes the nsf-brightcove module, which we don't have anymore.
These are needed for the current config import. We'll likely remove some of these in the future.
The "standard" install profile adds a "shortcut_set" that conflicts with our configs, so we need to remove it. Similarly, we need to indicate that our Drupal install is downstream from a set of configurations (by giving it the same UUID as those configs).
This will effectively duplicate the latest config changes. It also clears the cache, in case it'd have been affected by code/theme changes.
We'll fetch these from the "secrets" service and set them via drupal config:override. Note that this sends its output to /dev/null, lest the sensitive data become part of the app longs.
Edits for cloud.gov configuration
This pull request — incorporating excellent contributions from @cmc333333 — is ☁️.gov 🚀.