-
Notifications
You must be signed in to change notification settings - Fork 261
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
Release TerriaMap using create-docker-context #681
base: main
Are you sure you want to change the base?
Changes from 11 commits
bdf304f
6afaf94
5c1f0e0
98c0b9d
09e528b
9279cee
b25a1c3
f975d57
bb02963
ce2b318
a7da33b
b49e225
3641a36
3123a7a
b64cdd2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,56 @@ | ||
# 2. Docker multi-architecture build using create-docker-context | ||
|
||
Date: 2024-07-18 | ||
|
||
## Status | ||
|
||
Proposed | ||
|
||
## Context | ||
|
||
I (crispy) consider a multi-stage dockerfile to be the gold standard of | ||
reproducible, mutli-architecture builds. Something like the following: | ||
|
||
- Build container copies workspace, installs development dependencies and builds | ||
the app. | ||
- Production container copies build artifacts and installs only production | ||
dependencies. | ||
|
||
is ideal. This ensures only production dependencies are present, and you can run | ||
this process on every architecture to create a multi-arch docker image. Binaries | ||
downloaded during dependency installation will fetch the correct architecture | ||
binary as depencies are installed separately on each architecture. But | ||
installing dependencies and building JS is extremely slow on emulated | ||
architectures, such as docker buildx on GitHub Actions (this can take 2.5 hours | ||
to build the image). | ||
|
||
If instead we can (on the build machine/VM): | ||
|
||
1. install all dependencies | ||
2. build the app | ||
3. copy build artifacts and only production dependencies to the multi-arch | ||
docker image | ||
|
||
then **as long as production dependencies are portable**, we have very little | ||
computation being run on emulated architectures. The `create-docker-context.js` | ||
script allows us to do this, copying build artifacts and only production | ||
dependencies to an intermediate "context" folder which is then used to create | ||
the | ||
|
||
Currently none of our production dependencies install non-portable binaries. | ||
|
||
## Decision | ||
|
||
While all production dependencies remain portable, we will build | ||
multi-architecture docker images by building TerriaMap on the VM and copying | ||
only production-necessary files and dependencies to the final docker image. | ||
|
||
## Consequences | ||
|
||
- We will replace current GitHub Actions release process with one using | ||
`create-docker-context.js`. | ||
- Our GitHub Actions TerriaMap release time will reduce from 2.5 hours to less | ||
than 10 minutes. | ||
- If in future TerriaMap uses a binary installed by side effect during JS | ||
dependency installation and this binary cannot be run on an architecture for | ||
which an image is created, that image will fail when run on that architecture. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# Docker image for the primary terria map application server | ||
FROM node:16 | ||
FROM node:16-slim | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This Dockerfile runs the node process as |
||
|
||
RUN mkdir -p /usr/src/app && mkdir -p /etc/config/client | ||
WORKDIR /usr/src/app/component | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not against the change per se, but there are a lot of things I find confusing. Is it the terriajs specified in package.json that gets installed, or does this pull from the TerriaJS repository? What creates the Why does this Dockerfile use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've added an ADR (architecture decision record) explaining why I'm proposing this. Please comment on that, or here if you are still confused or disagree. This dockerfile copies from a "context" that is created by I think it's more normal to use /usr/src/app than /app There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Based on the description, this seems like a great idea. Are the steps for how to build the docker image locally written down somewhere? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, ADR actually in this PR now. Sorry if you tried looking before, I forgot to push it. As for building the docker image locally, this would be a separate command There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I rebuild the release image to get security fixes and a few other local modifications, so I prefer a local build process that is as close to the release-image as possible so I don't have to re-do all the general quality assurance you have already done for the release. I don't use multi-arch builds personally so not sure how important that is in the grand scheme of things; if I suddenly get ARM machines I can do separate builds on ARM/X86 and then stitch together the two images with crane or some other tool. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The files inside this directory are owned by uid 1001 and gid 127. Is there a reason to not use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No reason. I'll apply the changes you made to our other dockerfile here too. |
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a big deal, Github provides ARM runners now so if this becomes a problem in the future it's "easy" to rectify.