Erich Blume 27d8f3cf1f Review gandi-operations doc and reorganize how-to guides (#200 )

## Summary
- **Doc review:** Reviewed `gandi-operations.md` — added `last-reviewed` frontmatter, verified all wiki-links, confirmed Pulumi state has no drift
- **Gandi reference fix:** Added missing `cv.eblu.me` CNAME row to `gandi.md` DNS records table (was present in Pulumi but undocumented)
- **Pulumi comment fix:** Updated stale `README.md` reference in `__main__.py` to point to `docs/how-to/gandi-operations.md`
- **How-to reorg:** Moved 14 how-to guides into 3 subdirectories (`deployment/`, `configuration/`, `operations/`), collapsed the Documentation and Database index sections into Configuration and Operations respectively

## Verification
- `docs-check-links` — all 180 wiki-links valid
- `docs-check-filenames` — all 90 filenames unique
- `dns-preview` — 5 resources unchanged, no drift
- All pre-commit hooks pass

## Test plan
- [ ] Verify docs site builds correctly with new paths
- [ ] Spot-check a few wiki-links from other pages to moved how-to guides

Reviewed-on: https://forge.ops.eblu.me/eblume/blumeops/pulls/200

2026-02-17 07:29:33 -08:00

3.1 KiB

Raw Blame History

title

modified

last-reviewed

Build a Container Image

How to create a custom container image in BlumeOps, build it locally, and release it to the zot registry via the Forgejo CI pipeline.

Prerequisites

Dagger CLI installed locally
A Dockerfile for the service you want to build

1. Create the container directory

Add a Dockerfile (and any supporting files) under containers/<name>/:

containers/<name>/
├── Dockerfile
└── (optional scripts, configs)

The directory name becomes the image name: registry.ops.eblu.me/blumeops/<name>.

2. Build locally

Test your image with Dagger:

dagger call build --src=. --container-name=<name>

This builds containers/<name>/Dockerfile using the Dagger docker_build() function. Fix any build errors before proceeding.

3. Release

Once the image builds cleanly, create a tagged release:

mise run container-tag-and-release <name> v1.0.0

This creates a git tag <name>-v1.0.0 and pushes it. The build-container Forgejo workflow triggers on the tag, builds the image via Dagger, and publishes it to the registry as registry.ops.eblu.me/blumeops/<name>:v1.0.0.

Check available images and tags with:

mise run container-list

4. Update k8s manifests

Change the image reference in argocd/manifests/<service>/deployment.yaml:

image: registry.ops.eblu.me/blumeops/<name>:v1.0.0

Then deploy per deploy-k8s-service.

Common Patterns

Existing containers demonstrate several build approaches:

Pattern	Example	Notes
Alpine package install	#transmission	Simplest — install from apk
Go from source	#miniflux	Clone upstream, `go build`
Multi-stage with Node + Go	#navidrome	Separate UI and backend build stages
Multi-stage Elixir	#teslamate	Elixir release with Node assets
Runtime tarball download	#kiwix-serve	Download pre-built binary with arch detection

transmission

containers/transmission/Dockerfile — Installs transmission-daemon directly from Alpine packages. Good starting point for services available in apk.

miniflux

containers/miniflux/Dockerfile — Two-stage Go build. Clones upstream at a pinned version tag, runs make, copies the binary into a minimal Alpine runtime.

navidrome

containers/navidrome/Dockerfile — Three-stage build with separate Node.js UI compilation, Go backend build with CGO (taglib), and a minimal Alpine runtime with ffmpeg.

teslamate

containers/teslamate/Dockerfile — Two-stage Elixir build with Node.js asset compilation. Uses Debian-based images due to Elixir/OTP dependencies.

kiwix-serve

containers/kiwix-serve/Dockerfile — Downloads a pre-built binary from upstream, with architecture detection for cross-platform support.

deploy-k8s-service — Deploying the service that uses the image
create-release-artifact-workflow — Alternative: release non-container artifacts
dagger — Dagger CI reference

3.1 KiB Raw Blame History