43 lines
3.3 KiB
Markdown
43 lines
3.3 KiB
Markdown
# mesh-build-image — the image build module
|
|
|
|
Design 47, release R4c-9 (novox/hq ADR 0487, ADR 0466 §1, ADR 0469; issue 1703). The module that builds a module's
|
|
`image` artifact from the Dockerfile in the module's own directory, on a build machine, as an account of its own
|
|
(`runs-as`, no login shell, home at mode 0700). It serves every module's image, whatever the base, so it is not a
|
|
build module for one module. It claims no seat: it is assigned to the build machines and runs dark until the builder
|
|
uses it.
|
|
|
|
## Rootless
|
|
|
|
The tool is `buildah`, which the `buildah` module installs and provides as `rootless-image-build` with the machine's
|
|
reach: a machine without it refuses this module at assignment, naming `buildah`. The build runs as the module's own
|
|
account in a user namespace (`--isolation oci`), with buildah's image store and runtime state in
|
|
`/var/lib/mesh-build-image-store` (outside the home), no mount of the host, no container runtime socket, no registry
|
|
credential and an environment built from scratch.
|
|
|
|
The account's subordinate user and group ranges are not declared anywhere: the node-engine makes every `user` account
|
|
with `useradd`, which allocates them. The module's health reads `/etc/subuid` and `/etc/subgid` and is unhealthy
|
|
without a range for the account, without buildah, or when a user namespace cannot be made.
|
|
|
|
The Dockerfile's steps may use the network (ADR 0487 §6); nothing a step can read holds a key.
|
|
|
|
## Steps
|
|
|
|
- `build_image_fetch` fetches a commit over SSH into a workspace (a base commit makes the merge preview, as the other
|
|
build modules' fetch). Long: answers a step id and ends on its key in `steps`.
|
|
- `build_image_build` builds one image artifact: `buildah bud` with the Dockerfile of the module's directory as file
|
|
and context, `--target`, and the images `build.on` pins as `--build-arg`. Answers the image's digest. With
|
|
`publish: true` (a merged trunk commit only) the module's own process then pushes it to the registry under
|
|
`<module>/<artifact>:<tag of its own>` (the first 12 hex digits of the digest unless the call gives one), waiting out
|
|
a registry held still, and the key carries the digest the registry serves and the reference pinned by it. Without
|
|
`publish` (a pull request) nothing is pushed.
|
|
- `build_image_copy` copies an upstream artifact (`module`, `artifact`, `from`) registry to registry into the artifact store
|
|
over the registry API, the whole index and every blob, by the digest the manifest pins (ADR 0498 §4), and verifies the
|
|
store serves that digest. Answers the digest and the reference `<registry>/<module>/<artifact>@sha256:<digest>`. A
|
|
`from` without a digest fails `not pinned:`. It needs no workspace and no buildah.
|
|
- It refuses, naming why, an image whose build context is a whole repository (`context`) or whose `build.on` names
|
|
another module's artifact (`unsupportedImage` in `build.go`): those forms belong to the images build-agent builds
|
|
until it is removed at R4g.
|
|
- `build_image_step`, `build_image_steps`, `build_image_status` and `build_image_health` read.
|
|
|
|
The registry's address is placed into `<home>/registry` as `${seat:mesh-artifact-store:reach}` (host:port): the provisioner's client fills a moved module's placement, and the artifact store has not moved, so a `${bound:artifact-store:...}` is refused at composition (issue 1703).
|