phase2 / outrigger-examples Goto Github PK

Aiming to create an example Outrigger project for Laravel. I can take this on if no one else wants to take it. It should use much of the same toolset that Drupal 8 requires (PHP 7.1+, MySQL, etc.). Also, delete this issue if I created it in the wrong place.

This issue is a bit of a meta-issue to catch up the examples to the changes in docker and outrigger practices over the last months.

Fixes

• Upgrade all docker-compose files to v2.1 at least, and v3.2 preferred. This includes removing cases of volumes_from and other properties that are deprecated in the v2 format.
• Update the build.yml configs to better alignment with what is produced by generator-outrigger-drupal. It should be a simpler subset of the generator configuration.
• Review if docker-compose.yml configs need a similar refactor.
• Review if jenkins.yml configs need a similar refactor.

Improvements

• Add rig project example (sans Unison)
• Add rig project + unison example
• Add Tips & Tricks examples here or in the formal docs for BASH History, Overridable SSH Key, etc.
• Add the output of rig project create as an example?

Once the 2.x branch of the outrigger/jenkins-docker image lands, we need to update this example to use config for the 2.x version of jobs as well as an example using a Jenkinsfile.

In docker-compose 2+ the preference is to used a named volume to persist data, rather than data containers. In schema v3+, volumes_from is removed.

This means replacing volumes_from with a normal volume statement:

      - search-data:/var/lib/solr

Next, the docker-compose manifest will need a simple volume declaration such as:

volumes:
  # This data volume persists Solr storage.
  # The search service is using a customized Docker image to facilitate write
  # access to this volume.
  # An empty value indicates all settings are default.
  search-data:

Lastly, since we are no longer using a data container, we need to instead customize our docker image to have a place to store the data. In examining the upstream solr image, it appears we could simply locate the data within /opt/solr. Since we are not, we will need a Dockerfile such as:

FROM solr:5.5.4-alpine

USER root

# Create and permission the data directory.
RUN mkdir -pv /var/lib/solr && chown $SOLR_USER:$SOLR_USER /var/lib/solr

# Restore use of the Solr user for container operations.
USER $SOLR_USER

Now, we could conceivably follow the existing data container configuration to add s6 and confd to the solr container, but when I tried that I got some errors so I stepped back to this simpler approach.

Note that our current example uses solr:5.5, but in my current project implementation I decided to specify a specific patch-level, and use the alpine variant because I'm optimizing for local development access to the Solr service. I believe those could be switched back without otherwise changing what I'm demonstrating.