rays/ipx
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects Releases 20 Wiki Activity

Images build in a capped BuildKit builder

Browse Source 
A plain `docker buildx build` of ipx on 2026-11-04, its dependency layer
invalidated by a Cargo.toml change (#382), rebuilt everything in release
on all twelve threads with 5 GB free and no swap. Tower thrashed for
three hours with every core pegged and had to be rebooted.

scripts/build-image.sh now builds every image: it refuses under 9 GB
available or above load 12, and builds in the docker-container builder
ipx-capped, held to 6 GB and six threads by its cgroup, so a build that
outgrows that is killed instead of stalling production. The builder
pulls base images through mirror.gcr.io, which replaces tagging local
copies to dodge Docker Hub's 429s. CLAUDE.md deploys only through it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Ray Slakinski
2026-11-04 20:23:23 +00:00
parent 245fa79fbf
commit c8cbb3047a
3 changed files with 74 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
CLAUDE.md
View File

@@ -48,9 +48,18 @@ Labels: `bug` for something wrong, `enhancement` for something missing. A proble
for later stays open, and that is how it gets picked up again.
Deploying a change is: build and push the image, then pull it and recreate the container.
**Build only with `scripts/build-image.sh`, never a bare `docker buildx build`.** On 2026-11-04
a plain build of ipx, its dependency layer invalidated by a `Cargo.toml` change, rebuilt
everything in release on all twelve threads with 5 GB free; Tower thrashed for three hours with
every core pegged and had to be rebooted. The script refuses to start under 9 GB available or
above load 12, and builds in the BuildKit container `ipx-capped` (made on first use), held to 6
GB of memory and six threads by its cgroup: a build that outgrows that is killed, and production
keeps running. If one is killed, say so and wait for the user to decide; do not raise the caps or go
around the script. Run the build in the foreground on its own, never chained after a cargo
command, and look at `MemAvailable` and the load again when it ends.
```sh
docker buildx build --tag 192.168.1.130:5000/ipx:latest . --push
sh scripts/build-image.sh ipx
docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml pull ipx
docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml up -d ipx
docker logs --tail 20 iPX
@@ -59,7 +68,7 @@ docker logs --tail 20 iPX
The directory is the same, with its own image:
```sh
docker buildx build -f Dockerfile.directory --tag 192.168.1.130:5000/ipx-directory:latest . --push
sh scripts/build-image.sh directory
docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml pull ipx-directory
docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml up -d ipx-directory
```
@@ -67,7 +76,7 @@ docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml up -d ipx-directory
And the page, `ipx-web`, the same again; a change to `web/` alone needs only this one:
```sh
docker buildx build -f Dockerfile.web --tag 192.168.1.130:5000/ipx-web:latest . --push
sh scripts/build-image.sh web
docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml pull ipx-web
docker compose -f /mnt/fast/arcane/projects/ipx/compose.yaml up -d ipx-web
```
@@ -94,24 +103,11 @@ block page, and ipx then logged a feed as failing with `invalid peer certificate
**Name the service.** A bare `up -d` recreates every container in the project, which once the
split lands means the frontend and directory too. Run `pull` before `up`, because `up` reuses whatever `latest` the host already has.
**A build that fails with `429 Too Many Requests` on a base image** is Docker Hub rate-limiting
this host. There is no Docker Hub login here, and the build asks about its base images
(`debian:trixie-slim` and `rust:1-slim-trixie`; `node:22-slim` and `caddy:2` for ipx-web) every time unless they are already stored locally. Pull them from Google's
mirror and tag them; the build then uses the local copies without asking Docker Hub:
```sh
docker pull mirror.gcr.io/library/debian:trixie-slim
docker tag mirror.gcr.io/library/debian:trixie-slim debian:trixie-slim
docker pull mirror.gcr.io/library/rust:1-slim-trixie
docker tag mirror.gcr.io/library/rust:1-slim-trixie rust:1-slim-trixie
# ipx-web's, Dockerfile.web
docker pull mirror.gcr.io/library/node:22-slim
docker tag mirror.gcr.io/library/node:22-slim node:22-slim
docker pull mirror.gcr.io/library/caddy:2
docker tag mirror.gcr.io/library/caddy:2 caddy:2
```
Run those again now and then, or the local copies go stale.
**Base images come from Google's mirror** (`mirror.gcr.io`, set in `scripts/buildkitd.toml`),
not Docker Hub, which rate-limits this host with `429 Too Many Requests`. The capped builder
cannot see images the Docker daemon has stored, so pulling and tagging them locally does nothing
for it. If `buildkitd.toml` changes, remove the builder (`docker buildx rm ipx-capped`) so the
next build makes it again with the new config.
The containers have no Docker healthcheck (#218): Docker runs one with `exec`, which on Tower
fails whenever root is logged out, because elogind removes `/run/user/0`, where containerd puts