Around Go: containers · 3 MIN READ

Publish an image: tags, digests and target platforms

Tag and push an image you own, inspect its digest and match its platform to the deployment.

A cluster pulls an image from a registry it can reach; a local Docker image does not appear there automatically. Tags are mutable names, while a digest identifies specific image content. Replace the example registry and owner with a namespace where you have permission to publish.

Authenticate without a password in the command line

Use the registry credential flow appropriate to the host; --password-stdin keeps the token out of process arguments. This example reads a token interactively in Bash, passes it through stdin and unsets the variable after login.

bash

registry=registry.example.com
read -r -s -p "Registry token: " registry_token
printf "\n"
printf "%s" "$registry_token" | docker login "$registry" \
  --username YOUR_USER --password-stdin
unset registry_token

Read the code

registry.example.com and YOUR_USER are placeholders. Do not run with shell tracing enabled or put tokens in a committed script. Docker stores credentials according to its configured credential helper; check that configuration on a shared host.

Publish an explicit version and record the result

Tagging gives the same local image another name; pushing uploads its referenced layers and manifest. Inspect the output digest and associate it with the source commit and tests. A tag called tested is still mutable unless the registry enforces otherwise.

bash

image=registry.example.com/YOUR_OWNER/go-api:0.1.0
docker tag go-api:dev "$image"
docker push "$image"
docker image inspect "$image" --format '{{json .RepoDigests}}'

Read the code

Replace owner and registry first and publish only your intended artifact. The digest from a successful push identifies the remote content. Referencing image@sha256:... in a deployment avoids relying on a mutable tag; use the full real digest, not an ellipsis.

Match the image platform to the target nodes

Buildx can build for a specified target when the builder supports it. A multi-platform image requires compatible toolchains, base images and code for each target. Setting GOOS alone does not ensure the native CPU architecture matches the Kubernetes node.

bash

docker buildx ls
docker buildx build --platform linux/amd64 \
  -t registry.example.com/YOUR_OWNER/go-api:0.1.0-amd64 --push .
docker buildx imagetools inspect registry.example.com/YOUR_OWNER/go-api:0.1.0-amd64

Read the code

This command publishes a separate amd64 tag. A compatible buildx builder may need emulation or native nodes. The earlier Dockerfile compiles inside its selected builder platform; custom cross-compilation needs explicit GOARCH/TARGETARCH handling.

TAKE THIS WITH YOU

Publish to an owned registry namespace, retain the pushed digest and verify the target platform. A local tag or a successful host build does not prove a cluster can pull and run that artifact.

Check your understanding

Why record a registry image digest for a release?

Go to the source

Progress stays in this browser. No account needed.