feat(bird): add curl and jq for the peer-list init container

The per-node peer list is rendered from the Kubernetes API rather than written into the repo a second time, so the init container needs an HTTP client that can verify against the API server's CA bundle. busybox wget cannot, and the query is not going to run unverified. Using the same image for the init container and the daemon keeps one lifecycle instead of borrowing a CI image at runtime. Refs #576 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merge pull request 'feat(bird): image for the pod-network BGP mesh (1/3) (#576 )' (#846 ) from feat/bird-image into master
2026-09-16 10:10:09 +02:00 · 2026-09-16 07:50:27 +00:00 · 2026-09-16 09:38:46 +02:00 · 2026-09-16 09:29:17 +02:00
2 changed files with 48 additions and 0 deletions
@@ -376,3 +376,29 @@ steps:
          --dockerfile Containerfile \
          --destination gitea.renner.uno/gitea_admin/netbird-proxy-services:$TAG \
          --destination gitea.renner.uno/gitea_admin/netbird-proxy-services:latest
+
+  # bird: BGP daemon for the pod-network mesh over pod0 (#576). Runtime
+  # artifact like heating-can; same registry so the audit tracks it.
+  - name: build-bird
+    image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
+    directory: ci/images/bird
+    depends_on: []
+    when:
+      - event: deployment
+      - event: push
+        path: ["ci/images/bird/**", ".woodpecker/build-ci-images.yml"]
+    environment:
+      GITEA_USER: gitea_admin
+      GITEA_TOKEN:
+        from_secret: ci_images_token
+    commands:
+      - mkdir -p /kaniko/.docker
+      - AUTH=$(printf '%s:%s' "$GITEA_USER" "$GITEA_TOKEN" | base64 | tr -d '\n')
+      - printf '{"auths":{"gitea.renner.uno":{"auth":"%s"}}}' "$AUTH" > /kaniko/.docker/config.json
+      - TAG=$(date +%Y-%m-%d)
+      - |
+        /kaniko/executor \
+          --context . \
+          --dockerfile Containerfile \
+          --destination gitea.renner.uno/gitea_admin/bird:$TAG \
+          --destination gitea.renner.uno/gitea_admin/bird:latest
@@ -0,0 +1,22 @@
+FROM alpine:3.22@sha256:14358309a308569c32bdc37e2e0e9694be33a9d99e68afb0f5ff33cc1f695dce
+
+# bird: BGP daemon for the pod-network mesh over pod0. Distro package, no build
+# step — the image is the binary plus its runtime.
+#
+# 3.22 rather than the 3.21 the other images here pin: bird2 first appears in
+# 3.22/community.
+#
+# Config is read from /etc/bird/bird.conf, not the package default
+# /etc/bird.conf, so the mount cannot shadow what the package ships.
+#
+# curl and jq are for the init container, which renders the per-node peer list
+# from the Kubernetes API. busybox wget cannot verify against the API server's
+# CA bundle, and the query must not run unverified.
+RUN apk add --no-cache bird2 curl jq
+
+# Fails the build rather than the first pod if a binary or its path is wrong.
+RUN /usr/sbin/bird --version \
+ && curl --version > /dev/null \
+ && jq --version > /dev/null
+
+ENTRYPOINT ["/usr/sbin/bird", "-f", "-c", "/etc/bird/bird.conf"]
Author	SHA1	Message	Date
claude-botandClaude Opus 5	bb3987ce1c	feat(bird): add curl and jq for the peer-list init container ci/woodpecker/push/build-ci-images Pipeline was successful Details ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details The per-node peer list is rendered from the Kubernetes API rather than written into the repo a second time, so the init container needs an HTTP client that can verify against the API server's CA bundle. busybox wget cannot, and the query is not going to run unverified. Using the same image for the init container and the daemon keeps one lifecycle instead of borrowing a CI image at runtime. Refs #576 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 10:10:09 +02:00
k.renner	480b2b11e4	Merge pull request 'feat(bird): image for the pod-network BGP mesh (1/3) (#576 )' (#846 ) from feat/bird-image into master ci/woodpecker/push/build-ci-images Pipeline was successful Details ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#846	2026-09-16 07:50:27 +00:00
claude-botandClaude Opus 5	3302e2c5cd	fix(bird): pin the base image by digest and self-test the binary ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/push/build-ci-images Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details Every other Alpine image under ci/images/ pins alpine:3.21 by index digest, and alpine-jq states the reason in the file: the resolved version drifts between restarts of an otherwise pinned image. The first revision used a bare alpine:3.22 tag. 3.22 is still right — bird2 first appears in 3.22/community — so the tag stays and the index digest is added. heating-can runs --help checks before publishing so a wrong path fails the build rather than the first pod; bird documents --version, so it gets the same guarantee. Refs #576 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 09:38:46 +02:00
claude-botandClaude Opus 5	3792485c2f	feat(bird): image for the pod-network BGP mesh (1/3) (#576 ) ci/woodpecker/push/build-ci-images Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Pod east-west follows the peer's Kubernetes InternalIP on mgmt0, and Cilium offers no way to point it elsewhere — established by test in #838, and directRoutingDevice (#837) does not do it. Policy routing does: a rule on the pod source prefixes into a table whose routes carry pod0 next-hops, proven on k8s-1 by counting 4647 packets onto pod0. Those routes have to be generated, not written down: PodCIDRs are Kubernetes-assigned and do not survive a rebuild in place. BGP between the nodes over pod0 generates them, with the session source as the next-hop. BIRD rather than FRR. FRR's docs describe 'set table' only as setting a BGP table identifier, never a kernel table; binding bgpd to an address implies --no_kernel and would suppress the route installation the design exists for; and a gatewayless IPv6 device route has no next-hop for its route-maps to match, so the own-CIDR filter could not be uniform. BIRD documents 'kernel table', 'strict bind' without touching the kernel protocol, and an 'ifname' filter attribute that discriminates the local route from the learned ones in both families. No maintained standalone BIRD image exists: pierky/bird self-declares as lab-only and amd64-only, calico/bird is a Calico-internal artifact expecting confd, slipmesh/bird is five weeks old, srl-labs and ibhde are lab-scoped or on BIRD 1.6. A custom controller would have needed an image of its own anyway, so the build is common to both routes. Image only. The DaemonSet is 2/3 and the routing rules 3/3, so the table fills before anything reads it. Refs #576 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 09:29:17 +02:00