Docker · Containers in practice
How do you build and publish images in CI?
Short answer
Build with BuildKit or buildx, authenticate with short-lived credentials, push an immutable tag and digest, scan the image, and use a remote cache so builds stay fast.
A CI pipeline should produce one artifact, test that artifact, and promote the same digest through environments. Rebuilding separately for staging and production creates two artifacts that can differ even with the same source.
docker buildx create --use --name ci-builder
docker buildx build --push \
--cache-from type=registry,ref=registry.example.com/api:buildcache \
--cache-to type=registry,ref=registry.example.com/api:buildcache,mode=max \
--tag registry.example.com/api:sha-$GIT_SHA .
docker buildx imagetools inspect registry.example.com/api:sha-$GIT_SHAPipeline rules
- Use workload identity or short-lived tokens, not a personal password
- Tag with the commit SHA and a release version; push the digest forward
- Scan the pushed image and fail on critical findings with a documented policy
- Do not mount the host Docker socket into untrusted build steps
- Keep build secrets out of logs and image layers
- Run the image's tests against the built artifact, not a separate build
A common shortcut is docker:dind with privileged mode, which works but gives the build broad host access. Rootless BuildKit or a dedicated build service is safer for shared runners.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why promote a digest instead of rebuilding per environment?
- 2How do you speed up CI image builds?
- 3What is the risk of mounting the Docker socket in CI?
- 4How do you authenticate to a registry from a pipeline?
Say it in the interview
I build once in CI with buildx, push an immutable SHA tag, record the digest and promote that digest through environments. I use a registry cache to keep builds fast, short-lived credentials for the registry, and a scan gate before deployment. I avoid mounting the host Docker socket into untrusted steps and keep build secrets out of layers and logs.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Docker mock interview and get scored feedback on depth, clarity and confidence.