phase2/docker-build

The Outrigger Build image provides a command-line toolkit for PHP & Node development with Drupal support.

docker-build's Issues

Add phpredis module to build image

Add phpredis to the build container for use on Drupal 8 projects that use the Redis module

Add NPM 5 to the build container

In order to allow easy experimenting with Yarn on projects (in the name of performance and more consistent builds) let's add it to the image.

Here's a custom Dockerfile I created to allow projects to use Yarn locally.

FROM outrigger/build:php70

RUN curl https://dl.yarnpkg.com/rpm/yarn.repo -o /etc/yum.repos.d/yarn.repo && \
    yum -y install yarn && \
    yum clean all

I got these steps from https://yarnpkg.com/lang/en/docs/install/#linux-tab, where the Alternatives tab notes that they recommend against installing with npm.

In order to add this to the main build image Dockerfile, I would add the repository (in the first line) as part of or after the RUN block that adds the IUS repo. Then I would add Yarn near the bottom of the list of yum packages.

We do not currently have the yum clean all, we should add it to condense the image a bit.

Switch to Node 8 by default

Note: In order to do this, we would need to have something like a phpNN-node4 tag to at least mark the last phpNN release with node4 for projects, but that seems like we'd risk leaving those projects behind.

Drop Ruby from the build image

We originally added Ruby to the build container to support Compass, but have since switched to a pure-node based workflow. Other uses of Ruby seem few and far between of late. Let's remove it from the base image and document how projects can customize the image to add it... or use specialized Docker images as needed.

Port pv utility to other main branches

Need to cherry-pick the change in #2 to the other primary PHP version branches.

• php55
• php56
• php71

pv tool is installed twice in the Dockerfile

Update drupal console to latest RC release

We would like to support the latest 1.x RC release of drupal Console, as despite not having a stable release it is required in a lot of cases. This issue was originally for porting a solution, but that solution was found not to work.

Image Versioning & Deprecation Plan

Node 4 and Bower are both hurtling rapidly towards deprecation, but we have existing projects that will depend on them for awhile yet.

EDIT: We also have the potential to drop Ruby as a default dependency, as a significant majority of projects do not use it and if utilities come up as necessary they could perhaps be implemented as customizations instead.

Deprecation Plan

1. Introduce a versioning scheme.
2. Add an s6 script that warns users to update to a specifically tagged version with a recommendation to use if they need bower and/or node 4.
3. Tag the image with that version.
4. Make announcements about a B/C break
5. Cut a 1.x branch of the repo and update any autobuilds to point to that branch instead of master.
6. Move forward dropping the deprecated stuff.

Versioning Scheme

I propose a versioning scheme of ".-<lang.version>", with the result in projects of outrigger/build:2.0-php71. (Given this pattern, the version we recommend legacy projects switch to will be outrigger/build:1.0-php70 or the like.)

1. Since we have a flattened repository system, we tag git with "v2.0"
2. We configure builds by tag in Docker Hub to get the Docker tag 2.0-php71.
3. We keep in mind we'll have a long tail of projects where teams do not worry about shifting versions of docker images as long as they do not need to edit config, but now we are asking them to edit config.
4. We might choose to add support for a "dev" tag, which is basically explicitly declared latest but makes it easier to test merged changes ahead of a release.
5. If we want to support a legacy in addition to the 1.x branch, we would have breathing room to allow projects to disable the warning message with an env var, but only after they switch to deterministic versioning.

This is loosely the pattern I setup with outrigger/keel, without the language-specific extension.

Full Set of Tags

• php55
• php56
• php70
• php71
• 1.0-php56
• 1.0-php70
• 1.0-php71
• 2.0-php56
• 2.0-php71

In this set of tags, I am demonstrating officially unsupporting PHP 5.5 and deprecating PHP 7.0.

EDIT: Added example tags, added a bullet to the bottom of Versioning Scheme about making the warnings disable-able, since warning output on build container operations is maddening and if a project legitimately needs to keep on Node 4 or Bower for a while we should have some mercy.

Use anonymous volume for build cache instead of requiring projects to volume mount

Many tools use ~/.cache for caching, and many other tools can be configured to do so. Should we automatically support persisting build caches by making this an anonymous volume?

Should we add a 'base' build container so we have a technology agnostic foundation?

I've been thinking about how we present Outrigger as a technology-agnostic solution, but our build container isn't all that agnostic. It's a big pile of stuff which is aimed at the tools and tech stacks Phase2 tends to work with around PHP & Drupal.

What if we centralized the truly tech-agnostic stuff we want in a build container for any application into a "base", then extend that into others? I've put together a bit of a demonstration in the expando-matic sections below.

Base Dockerfile

FROM centos:7

# Install base packages.
RUN yum -y install epel-release yum-plugin-ovl deltarpm && \
  # Add the IUS repository. This is needed for git2.
  curl -L "https://centos7.iuscommunity.org/ius-release.rpm" > /usr/local/ius-release.rpm && \
  rpm -Uvh /usr/local/ius-release.rpm
  yum -y update && \
  yum -y install \
    bzip2 \
    curl \
    dnsutils \
    git2u-all \
    jq \
    less \
    make \
    openssl \
    patch \
    pv \
    rsync \
    sudo \
    ssh \
    sendmail \
    unzip \
    vim-minimal \
    # Necessary for drush and developer orientation.
    which \
  yum clean all

# Download & Install confd.
ENV CONFD_VERSION 0.11.0
RUN curl -L "https://github.com/kelseyhightower/confd/releases/download/v$CONFD_VERSION/confd-$CONFD_VERSION-linux-amd64" > /usr/bin/confd && \
    chmod +x /usr/bin/confd
ENV CONFD_OPTS '--backend=env --onetime'

# Ensure $HOME is set
ENV HOME /root

# Configure Git
# https://git-scm.com/docs/git-config#git-config-corepreloadIndex
RUN git config --global core.preloadindex true

# Run the s6-based init.
ENTRYPOINT ["/init"]

# Set up a standard volume for logs.
VOLUME ["/var/log/services"]

COPY root /

CMD [ "/versions.sh" ]

Extending php7.0 Dockerfile

FROM outrigger/build-base

RUN yum -y install centos-release-scl && \
  yum-config-manager --enable rhel-server-rhscl-7-rpms && \
  yum -y update && \
  yum -y install \
    https://rpms.remirepo.net/enterprise/remi-release-7.rpm \
    gcc-c++ \
    httpd-tools \
    mariadb \
    nmap-ncat \
    php70 \
    php70-php-devel \
    php70-php-gd \
    php70-php-xml \
    php70-php-pdo \
    php70-php-mysql \
    php70-php-mysqlnd \
    php70-php-mbstring \
    php70-php-fpm \
    php70-php-opcache \
    php70-php-pecl-memcache \
    php70-php-pecl-xdebug \
    php70-php-posix \
    php70-php-mcrypt \
    postgresql \
    ruby193 \
    ruby193-rubygems \
    ruby193-ruby-devel \
    # Necessary library for phantomjs per https://github.com/ariya/phantomjs/issues/10904
    fontconfig && \
    yum clean all

# Also the composer, ruby, node, and drush things.

Pros	Cons
Easy starting place for new build images	Another image to manage
Have leaner build image by application stack	Steer towards an explosive number of build images (Node app vs. PHP app have different build containers, instead of one build container with all for both)
Clarify our core definition of a build container	Confuse people whether a change belongs in base, all images for a given language, or a specific build image language version

Current repository for php5.6 is deprecated

https://www.softwarecollections.org/en/scls/remi/php56more/

There is a replacement at

https://www.softwarecollections.org/en/scls/remi/sclo-php56/

@see phase2/docker-apache-php#12

If outrigger.key is an empty directory, skip further key handling

An empty directory indicates the local key did not exist, if so let's treat that as though there is no key and not spew a number of confusing errors.

Errors from Broken outrigger.key volume mount

cat: /root/.ssh/outrigger.key: Is a directory
cp: missing destination file operand after '/root/.ssh/outrigger.key'
Try 'cp --help' for more information.
chown: missing operand after 'root:root'
Try 'chown --help' for more information.
chmod: missing operand after '600'
Try 'chmod --help' for more information.
# bitbucket.org SSH-2.0-conker_1.0.287-a1d21a7 app-128
# bitbucket.org SSH-2.0-conker_1.0.287-a1d21a7 app-126
no hostkey alg
# github.com SSH-2.0-libssh-0.7.0
# github.com SSH-2.0-libssh-0.7.0
no hostkey alg

Port PHPRedis support from PHP 7.0 to PHP 5.6

To support Drupal 7 projects that use Redis.

1. Find the section in the php70 Dockerfile that adds PHPRedis.
2. Copy that bit out, and put it in the similar spot of php56 Dockerfile
3. Locally test the build works.
4. Submit a PR

Move drush cache inside /root/.cache

In order to further consolidate our build caches, we want all tools to use /root/.cache as the base directory. Drush should use /root/.cache/drush instead of /root/.drush.

This can be done by setting the CACHE_PREFIX environment variable like so:

ENV CACHE_PREFIX /root/.cache/drush

However, Drush does not take care of automatically creating this directory. We would need to specify that the volume used for caching is pre-created.

This would be really hard to handle automatically, unless we were to pursue #31 first.

Enable apcu-autoloader composer setting

1. Investigate if this can be effectively used with our split container model.
2. Check out adding an env var to set that. https://getcomposer.org/doc/06-config.md#apcu-autoloader
3. This will need to be done in apache-php-base as well.

Use environmental config for npm compatibility to run as root

One of the things we sometimes need to do as part of running npm install is use the --unsafe-perm flag. This is most commonly needed when running npm as root where an npm script is called, such as a postinstall hook.

Per https://docs.npmjs.com/misc/config, this can be converted to an environment variable, which means we can bake the behavior into the Docker image instead of keeping it as an environment wrinkle in front of developers.

We may want to consider combining this with the composer environment variable for running as root, and have a single ENV layer for setting "it's okay to be root" vars.

Remove Bower

Not only do most PLS-based projects not use global bower as an official workflow, bower itself has declared it's own deprecation in favor of npm/yarn. We can remove it in v2.

Port git preloadindex behavior to all branches

#8

Remove Node v4 from the Build Image (v2.0)

While Node v4 is LTS supported for another year, it is shortly going to be 2 LTS releases behind. New projects should not use it as that runway is far too short for any reasonable benefit over porting or finding solutions for Node 6+. Let's save space by removing it from the 2.0 line of the build image.