Files
devops-lib-gcp/resources/com/homelab/go-Dockerfile
T
Mukul SharmaandClaude Opus 5 3e09eecbfe GKE: point the pipeline at this cluster's registry, over TLS
The GCP counterpart of devops-lib. Registered in Jenkins under the same
name, so consuming repos need no change: the two-line Jenkinsfile is
identical on both clusters, and which library it resolves to is a property
of the Jenkins running it.

Substantive changes, all consequences of GKE being a real cloud:

- Harbor speaks TLS here, so dind no longer passes --insecure-registry.
  It mounts the private CA at
  /etc/docker/certs.d/harbor.35.238.248.203.nip.io/ca.crt instead, from the
  registry-ca ConfigMap. This is not redundant with the node pool's trust:
  that covers pulls, performed by containerd on the node, while the push
  comes from dockerd in the build pod with its own trust store. Without it,
  pushes fail TLS verification while pulls of the same image succeed —
  which reads like a broken registry rather than a missing trust anchor.

- The registry hostname changes in the push target and all five fallback
  Dockerfiles. It still must be spelled identically everywhere, because
  Docker matches credentials and trust by exact hostname.

- helm_repo_url moves to cluster DNS. That clone runs in a build pod, so
  sending it out through the ingress and back would make the pipeline
  depend on Contour for pod-to-pod traffic. syncArgoApp already addressed
  ArgoCD this way and needed no change.

- build-tools.Dockerfile is removed: devops-base-images-gcp owns it now,
  next to the mirrored base images, and the pod references the result by
  tag at base-images/build-tools:1. The base-images project is public, so
  the pod can pull it before it has any credentials.

Verified: no homelab addresses remain; the pod template parses with the CA
mount, the new image and no insecure-registry flag; and every fallback
template's base image, with the default version buildDocker would pick, is
present in the mirror manifest — an unmirrored tag now fails the build
rather than silently falling back to Docker Hub.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
2026-09-13 01:27:05 +05:30

27 lines
1.3 KiB
Plaintext

# Fallback only — used when the repo has no Dockerfile of its own (see
# buildDocker.groovy). Simplified from the real go-Dockerfile: no SSH-keyed
# private module auth (github.com/Homelab/*), no per-module builds, no
# kafka-specific CGO toggle. Assumes a standard single-binary repo layout
# (main package at the repo root) — a repo with a different structure
# should just bring its own Dockerfile, same as demo-go-app does.
# Both stages pulled from Harbor's base-images project (mirrored from
# Docker Hub via devops-base-images), not Docker Hub directly — see that
# repo's README for the one-off mirror setup and why (build-time
# dependency on an external registry, plus wanting to pick the leanest
# variant of each deliberately rather than accept whatever a public tag
# defaults to). Only versions actually mirrored there resolve — passing
# a dockerBuildVersion whose tag isn't in devops-base-images/images.txt
# yet needs that added and re-mirrored first, unlike pulling straight
# from Docker Hub where any tag "just worked".
FROM harbor.35.238.248.203.nip.io/base-images/golang:${version}-alpine AS build
WORKDIR /src
COPY go.mod go.sum* ./
RUN go mod download 2>/dev/null || true
COPY . .
RUN CGO_ENABLED=0 go build -o /app .
FROM harbor.35.238.248.203.nip.io/base-images/alpine:3.20
COPY --from=build /app /app
EXPOSE 8080
ENTRYPOINT ["/app"]