Compilações em várias etapas para imagens de produção enxutas

A single-stage build often ships compilers, dev dependencies, and source code into production. The result is a large, slower-to-pull, larger-attack-surface image.

A multi-stage build uses several FROM statements in one Dockerfile. Earlier stages build artifacts; a final lean stage copies only what it needs to run.

Compile in a Go image, then ship a tiny final image with just the binary.

The key line is COPY --from=build. It pulls the compiled app binary out of the build stage, leaving the Go toolchain behind.

Install and build with dev deps, then copy only the production output.

Final stages should use minimal bases like alpine, -slim, or distroless. Smaller bases mean fewer packages and fewer vulnerabilities.

Google distroless images contain only your app and its runtime, no shell or package manager. They are very small and hard to exploit interactively.

You can build only up to a named stage with --target, useful for running tests in CI.

Copy dependency manifests before the rest of the source. Then dependency installation is cached and only re-runs when the manifest changes.

Compare sizes before and after. Multi-stage builds commonly shrink images from hundreds of MB to tens of MB.

Add a .dockerignore so build context excludes node_modules, .git, and secrets, speeding builds and avoiding leaking files into images.

Test what you have learned.

You learned to split Dockerfiles into build and runtime stages, copy only artifacts with --from, pick slim or distroless bases, target stages, and combine with .dockerignore for lean production images.