public Runway Docker image

[ITProKyle]

There has been some discussion around the creation of an official Runway docker image. We have had one in the past but, stoped maintaining with the release of Runway executable binaries. We also move away from an official image to encourage best practices around dependency management.

Reasons To Publish An Image

• being able to use FROM onica/runway:... in a Dockerfile

Reasons Not To Publish An Image

• being able to use RUN curl -i oni.ca/runway/... in a Dockerfile to install Runway without needing any other dependencies
• encourages bad practices around dependency management
  • big concern when considering packing all of Runway's dependencies into one image
  • could be slightly mitigated by including the bare minimum in the image (only python and Runway)
• the image would be large and overly bloated for most use cases if it included all potential dependencies of Runway
• an image with all possible Runway dependencies will be unmaintainable (e.g. python 2.7, python 3.7, python 3.8, ..., node 12, ..., node 14, ..., terraform 12, etc)

Potential Solution

This is a potential solution open for discussion. It has not been accepted as a feature and will not be implemented yet.

Create 4 top-level images containing the minimum requirements to use Runway (python and Runway).

• runway:alpine-py37-${RunwayVersion}
• runway:alpine-py38-${RunwayVersion}
• runway:ubuntu-py37-${RunwayVersion}
• runway:ubuntu-py38-${RunwayVersion}

When a new version of Runway is released, Docker Hub will build, test, and publish a new tagged release with the new version of Runway.

[troyready]

Thanks for writing this up. In the interest of committees ruining everything, I'd like to propose two images for each release:

• runway:${RunwayVersion}
• runway:alpine-${RunwayVersion} (not nearly as attached to any particular naming here)

Having a fat default (runway:${RunwayVersion}) based on the latest Ubuntu LTS w/ (the distro-provided) python3 & nodejs packages installed would mean that any supported Runway module (CDK, CFN, etc) would run (assuming .terraform-version files in the consuming repos). I presume Runway would just be pip3 install'd into the /usr/local/lib site-packages, so consuming images could override package versions as desired.

Alpine builds could swing the other way - just a apk add python3, so CFN & TF would work ootb and consumers could customize to their heart's content.

[ITProKyle]

@troyready - I could get behind the ubuntu image with apt install python3 nodejs npm but, that would expose python as python3 and node as nodejs which arn't exactly desirable. We could alias them to python and node. Another option would be to package pyenv and nvm with it to allow for different versions of each. We could include python 3.7 and/or 3.8 with runway installed along with a selection of versions (or the latest version) of node. This would provide a standardized tooling to select the appropriate version as well as support to easily install other versions.

As for the alpine based image, I would be more inclined to do FROM python:3-alpine or FROM python:3.x-alpine rather than apk add python3 but could be persuaded otherwise if the additional packages that are included would be undesirable.

[troyready]

As for the alpine based image, I would be more inclined to do FROM python:3-alpine or FROM python:3.x-alpine rather than apk add python3 but could be persuaded otherwise if the additional packages that are included would be undesirable.

You're almost certainly right. I threw out a quick suggestion deliberately avoiding specifying a version, but the way it tracks the absolutely latest release probably makes it untenable.

Another option would be to package pyenv and nvm with it to allow for different versions of each. We could include python 3.7 and/or 3.8 with runway installed along with a selection of versions (or the latest version) of node. This would provide a standardized tooling to select the appropriate version as well as support to easily install other versions.

I'm in favor of putting pyenv/nvm in the image too. I'd rather do that after the runway install, so specific pyenv environments only get used by deliberate choice (I'm not remotely anti-pyenv, just aiming to make the default execution as generic & long-lived as possible)

I could get behind the ubuntu image with apt install python3 nodejs npm but, that would expose python as python3 and node as nodejs which arn't exactly desirable. We could alias them to python and node.

I'd be in favor of the symlinks. python could be covered via the python-is-python3 package, but pip3 & nodejs would still need them.