Docker & Containerization
Dockerfile, multi-stage builds, image optimization, docker-compose, container orchestration
1What is the main reason to use a multi-stage build for a Go application?
What is the main reason to use a multi-stage build for a Go application?
답변
Multi-stage build separates the compilation environment from the final image. The build stage contains the full Go SDK (several hundred MB), while the final image only contains the compiled binary. This drastically reduces image size (from ~800MB to a few MB) and minimizes attack surface by eliminating unnecessary build tools in production.
2Which base image is recommended for a Go application in production to minimize size and attack surface?
Which base image is recommended for a Go application in production to minimize size and attack surface?
답변
The scratch image is an empty image with no operating system. Go compiles to static binaries that don't need libc or other system dependencies, making scratch usable. This produces the smallest possible images (a few MB) and provides the best security as there are no exploitable tools or shell. Distroless and alpine are valid but less optimal alternatives.
3Which Go compilation flags are required to create a binary compatible with a scratch image?
Which Go compilation flags are required to create a binary compatible with a scratch image?
답변
CGO_ENABLED=0 disables cgo, forcing Go to use pure Go implementations for packages like net and os/user. Without this, the binary would have dynamic dependencies on libc. GOOS and GOARCH specify the target platform. These combined flags produce a fully static binary with no external dependencies, ideal for scratch.
How to optimize Docker layer caching when building a Go application?
What is the advantage of using Google Distroless images for Go compared to scratch?
+17 면접 질문