commit | e52badfb6a2aa901a897cbae7b6a55d5138b6396 | [log] [tgz] |
---|---|---|
author | Scott French <[email protected]> | Mon Aug 19 16:39:32 2024 +0000 |
committer | Gerrit Code Review <[email protected]> | Mon Aug 19 16:39:32 2024 +0000 |
tree | 25623480bf9ff5d6b9bcb4250fc5e85a036f991c | |
parent | 9c8f27ef531d87dfbc3346e12d1b24e15d7613a0 [diff] | |
parent | fef7c84e63744bb1d0a07aaf7ef41f44b08cc173 [diff] |
Merge "php7.4-fpm-multiversion-base: Fix a couple of typos"
This repository includes:
Best practices for a service image depend on the language -- specifically, on the build.
We use vendoring, rather than Debian dependencies, to manage Go libraries. (That means the image-build process is hermetic, with no downloads from GitHub; we can version the dependencies and manage upgrades ourselves; and all the other usual advantages of vendoring. The downside is a bulkier repo, but disk is cheap.) If the upstream repo doesn't include a vendor directory, you'll need to manage it yourself.
Clone the upstream repository into a new repo on gitlab.wikimedia.org, then clone the Gitlab repo on your laptop. Check out the commit you want to deploy (at a version tag, for instance) and then start a new branch called "wikimedia" at that commit. Now run go mod vendor
to automatically create a vendor/ directory with all the dependencies. Commit the result into the wikimedia branch, and tag it; if the original tag was "1.2.3" you might call yours "1.2.3-wikimedia".
If the upstream repo does include a vendor directory, and you don't need to make any other changes to the code, you could skip GitLab -- below, when we refer to cloning the GitLab repo, you can instead clone the upstream. But consider that this could stop working unexpectedly if the upstream repo moves or disappears.
Here the production-images repo, start a new directory. (Copy and modify another image as a model.) You need three files:
Use docker-pkg update
as described below to update changelog
. * Initial release
is sufficient.
In control
, along with the Package
/Description
/Maintainer
headers found in all images, add a header like Build-Depends: golang1.21
, using whatever version of Go is needed for the software to build.
In Dockerfile.template
, outline a two-stage build. The first stage (FROM the same golang1.XX image) clones your GitLab repo and runs go build
; the second stage copies out the resulting binary and runs it. Use whatever build flags are provided upstream, adding -mod vendor
if it isn't present. For example:
FROM {{ "golang1.21" | image_tag }} as build USER nobody RUN mkdir -p /go/<PACKAGEPATH> \ && cd /go/<PACKAGEPATH> \ && git clone https://gitlab.wikimedia.org/<URL>.git \ && cd <WORKDIR> \ && git checkout tags/<VERSION> \ && go build <FLAGS> -mod vendor \ && cp <BINARY> /go/bin FROM {{ "bookworm" | image_tag }} COPY --from=build /go/bin/<BINARY> /usr/bin/ USER {{ "nobody" | uid }} ENTRYPOINT ["/usr/bin/<BINARY>"] CMD <ARGS>
Before building, make changes to the desired template in ./images
or ./istio
and update the changelog using docker-pkg
:
$ docker-pkg -c <config-file> update <name> --version <version> --reason '* <to be added to changelog>' ./images/<name>
For example (images directory):
$ docker-pkg -c config.yaml update golang --version 1.14-1 --reason '* Version bump.' ./images/golang
For example (istio directory):
$ docker-pkg -c config-istio.yaml update build --version 1.6.3 --reason '* Version bump.' ./istio/build
The contents of the ./images
, cert-manager
and ./istio
directories can be built using docker-pkg
as follows:
$ docker-pkg -c build
If your configuration includes the login credentials for docker, the generated images will be automatically pushed to the registry.
Images are rebuilt weekly making use of the weekly-update.sh script