Conclusion

Originally published in Japanese at https://zenn.dev/ymotongpoo/books/chainguard-image-toolchain/viewer/65-conclusion.

This book started from the reproducibility and SBOM problems in Dockerfile-based image builds (Chapter 2), then walked through the Chainguard stack — Wolfi (Chapter 3), melange (Chapters 4 and 5), apko (Chapters 6 and 7) — and Chainguard Images’ actual production use (Chapter 9).

Where to start

You don’t need to adopt everything covered in this book at once. If replacing your existing Dockerfiles right away is hard, you can start by trying just apko. Even simply switching your existing base image to a Chainguard Image already addresses the attack-surface problem raised in Chapter 2.

If you build your own software in-house and feel the pain of your build process’s reproducibility or SBOM accuracy, you can start by rewriting part of that build as a melange.yaml. Porting an existing Dockerfile’s RUN instructions into a melange pipeline isn’t difficult, and using the built-in actions makes it easier to share build steps across multiple projects.

If your team already builds container images through a pipeline like GitHub Actions, then as we saw in Chapter 9, simply wiring melange build and apko build (or apko publish) into your workflow gets you close to the same setup Chainguard itself uses.

Beyond the scope of this book

Beyond melange and apko, Chainguard also publishes surrounding OSS this book didn’t cover — Grype for tracking vulnerability information, and tools for generating and verifying SBOMs, among others. For teams managing their applications in a Bazel monorepo, there’s also the rules_apko Bazel rules mentioned in Chapter 9. Wolfi’s package definitions themselves are also public, at wolfi-dev/os, and reading how actual package definitions are written is a shortcut to a more practical understanding of melange’s pipeline. I hope this book has served as a useful entry point into that.