从微信云托管容器镜像的选择-alpine说起

微信云托管 使用目前主流的容器平台Docker以及容器编排技术Kubernetes（简称K8S），来管理你的项目。 使用微信云托管需要掌握对Docker的使用，但你无需掌握K8S的使用方法。微信云托管将K8S的运维配置完全接手，你不需要关心K8S和容器服务如何配置和相互作用，只需要操作微信云托管提供的简单操作面板，就可以轻松的部署服务，大大降低了容器化技术的使用门槛。当你使用微信生态下的客户端（小程序、公众号），向部署在微信云托管上的后端服务发送请求时，会自动经过微信接入层（内网），并附带微信校验的权威用户信息。非微信生态下的客户端（普通WEB网页、APP），向部署在微信云托管上的后端服务发送请求时，会经过微信云托管公网网关层（所有用户共用，由微信云托管团队维护），并根据域名转发到对应的用户服务。 微信云托管提供默认公网域名，也可以接入自己备案好的自定义域名。

在微信云托管提供的官方模板里(PHP,Python,NodeJS,Golang,Java,.NET) 唯独Java 用的不是alpine 镜像，具体代码参见 https://github.com/WeixinCloud。

在 容器崛起之前，Alpine 还是个无名之辈，可能是因为大家并不是很关心操作系统本身的大小，毕竟大家只关心业务数据和文档，程序、库文件和系统本身的大小通常可以忽略不计。

容器技术席卷整个软件产业之后，大家都注意到了一个问题，那就是容器的镜像太大了，浪费磁盘空间，拉取镜像的时间也很长。于是，人们开始寻求适用于容器的更小的镜像。对于那些耳熟能详的发行版（例如 Ubuntu、Debian、Fedora）来说，只能通过删除某些工具（例如 ifconfig 和 netstat）将镜像体积控制在 100M 以下。而对于 Alpine 而言，什么都不用删除，镜像大小也就只有 5M 而已。

Alpine 镜像的另一个优势是包管理工具的执行速度非常快，安装软件体验非常顺滑。诚然，在传统的虚拟机上不需要太关心软件包的安装速度，同一个包只需要装一次即可，无需不停重复安装。容器就不一样了，你可能会定期构建新镜像，也可能会在运行的容器中临时安装某些调试工具，如果软件包的安装速度很慢，会很快消磨掉我们的耐心。

Alpine操作系统是一个面向安全的轻型Linux发行版。它不同于通常的Linux发行版，Alpine采用了musl libc和BusyBox以减小系统的体积和运行时资源消耗，但功能上比BusyBox又完善得多。在保持瘦身的同时，Alpine还提供了自己的包管理工具apk，可以通过https://pkgs.alpinelinux.org/packages查询包信息，也可以通过apk命令直接查询和安装各种软件。

Alpine Docker镜像也继承了Alpine Linux发行版的这些优势。相比于其他Docker镜像，它的容量非常小，仅仅只有5MB左右（Ubuntu系列镜像接近200MB），且拥有非常友好的包管理机制。官方镜像来自docker-alpine项目。

在制作docker镜像时，使用 multi stage 构建各个不同阶段的命令文件，最终copy到busybox或alpilne中执行。这样做得好处有二：

1. 保持镜像最小，busybox，alpine 是最小的操作系统镜像

2. 有各种linux工具使用，busybox本身是一个linux工具集

3. 构建stage建议使用alpine和其它的官方包， 主要理由是此镜像比busybox稍大，但是比其他的系统镜像都小，有人就问了，为撒不用busybox呢，因为busybox没有包管理工具，这带来很多不便；这点也是busybox和alpine的主要区别

下面我们来看一看.NET 和 Java的 alpine 的镜像情况：

当前Java 没有针对Alpine的官方稳定的OpenJDK 11构建，虽然 https://adoptopenjdk.net/ 拥有Alpine对Java 11的官方支持：https://hub.docker.com/r/adoptopenjdk/openjdk11。

Alpine是为了响应客户请求更安全的容器发行版而添加的，从.NET Core 2.0开始 .NET 就有针对Alpine 的官方稳定的.NET 构建，对Alpine 有非常好的支持，因为它包含的软件包更少，并且由于其表面积的减少，似乎具有更有限的CVE暴露：https://hub.docker.com/_/microsoft-dotnet-runtime。

相关文章：

• 优化 ASP.NET Core Docker 镜像的大小

• https://github.com/dotnet/dotnet-docker/blob/main/documentation/guiding-principles.md 

• https://devblogs.microsoft.com/dotnet/staying-safe-with-dotnet-containers/