A container image packages a service for running as a container. For a Go gRPC service, the image can contain the compiled executable, which becomes the container’s entry point. The same artifact can move through testing and deployment to Kubernetes. section 8.1 section 8.0
Build each service image from its own Dockerfile. A multistage build keeps compilation separate from runtime: a Go image runs `go build`, then a `scratch` stage receives the resulting executable. The runtime stage does not need the Go distribution. section 8.1.1
FROM golang:1.18 AS builder #1 WORKDIR /usr/src/app COPY . . #2 RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o order ./cmd/main.go #3 FROM scratch COPY --from=builder /usr/src/app/order ./order #4 CMD ["./order"] #5
The Order service Dockerfile compiles with `golang:1.18`, copies the executable into a `scratch` stage, and sets `./order` as the command. section 8.1.1
Build and distribute a service image
Place the Dockerfile in the Order service directory and run `docker build -t <image_name> .` there. A registry can store the tagged image for Kubernetes to pull; copying images directly to cluster nodes is an alternative for faster development feedback. section 8.1.1
In a CI/CD pipeline, generate and tag images after code checks, then deploy them to UAT and production. Rolling, canary, and blue-green deployments offer different release paths. Monitor error rates and user feedback so a problematic image can be rolled back or replaced with a hotfix. section 1.4.3
Database image for integration tests
A Docker Compose stack can run `mysql:8.0.30` for the Payment and Order services. Mount an initialization SQL file to create their databases, and use a MySQL ping health check before tests connect. section 7.4.4
