编译后的Golang程序应该使用哪个Docker镜像

编译后的Golang程序应该使用哪个Docker镜像 我正在尝试使用Docker和Go，现在我在Docker镜像外部构建应用程序，然后复制构建好的应用程序。我尝试了busybox和alpine这些非常小的镜像，一切似乎都运行得很好。Go应用程序是一个静态构建的可执行文件，所以我认为它确实不需要太多运行时环境。

但我想知道这里是否有人使用过其他镜像，以及为什么选择它们？

此致，Johan

3 回复

非常感谢！

这看起来确实很不错。他们在页面末尾的两阶段构建中处理了证书问题。我通过基于scratch构建容器测试了域名解析是否正常工作，虽然resolv文件是空的，但程序执行了net.LookupHost()并且成功运行了 😊

更多关于编译后的Golang程序应该使用哪个Docker镜像的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


您基本上可以使用 FROM scratch，但需要注意几个细节。一个是用于名称解析的 resolv.conf，另一个是用于 HTTPS 的一系列 CA 证书。不过有人已经做过实验：

Medium – 1 Mar 18

基于 Scratch 创建最小且安全的 Golang Docker 镜像

缩略图

当我们构建 Docker 镜像时，第一个想法是使用默认的官方镜像。

阅读时间：4 分钟

（他们似乎跳过了我上面提到的几点，所以我认为这些通常不是必需的。）

对于静态编译的Go程序，使用轻量级基础镜像确实是最佳实践。除了busybox和alpine，以下是一些常用的选择及其理由：

1. scratch镜像 scratch是一个空镜像，完全不包含任何文件系统内容，是最小的选择：

FROM scratch
COPY myapp /myapp
CMD ["/myapp"]

2. distroless镜像 Google提供的distroless镜像只包含应用程序及其运行时依赖：

FROM gcr.io/distroless/static-debian12
COPY myapp /myapp
CMD ["/myapp"]

3. alpine镜像（你已经使用过） alpine提供了基本的shell和工具，便于调试：

FROM alpine:3.19
COPY myapp /myapp
CMD ["/myapp"]

4. busybox镜像（你已经使用过） busybox比alpine更小，但工具集有限：

FROM busybox:1.36
COPY myapp /myapp
CMD ["/myapp"]

选择依据：

  • 追求最小化：scratch（约0MB）
  • 需要基本调试工具：alpine（约5MB）
  • 安全性和最小化平衡：distroless（约2MB）

对于生产环境，如果不需要shell访问，推荐scratch或distroless，它们减少了攻击面。如果需要调试，alpine是较好的折中选择。

回到顶部