最近，我写了关于 Docker 如何投资 Unikernel 以减小其容器大小的文章，但条条大路通罗马。Unikernel 是一项热门的新技术，但许多开发人员更喜欢稳定性和成熟度，而不是“新颖而闪亮”的东西。而这正是 Alpine Linux 的用武之地。

Docker 容器对于开发人员和运维人员来说是一项了不起的福音，并且是新兴的 DevOps 领域必不可少的工具。通过将应用程序与其运行时环境捆绑在一起，您可以避免潜在的痛苦世界。

对于任何曾经在一个环境中编写代码并在另一个环境中运行代码的人来说，这是一个熟悉的问题。应用程序在您的笔记本电脑上运行良好。它在测试服务器上运行良好。但是，当您尝试在生产服务器上上线时，它崩溃了。

如今，没有软件是孤立存在的。除非您正在编写底层固件，否则您的程序必须与其他软件协同工作。它在操作系统上运行，并依赖于库、模块和运行时。有时它会与其他应用程序、守护程序和服务通信。

在瞬息万变的现代计算世界中，任何这些软件组件都可能意外更改。守护程序或数据库服务器的新版本可能会发布，或者库可能会使用新功能和错误修复进行更新。

任何时候依赖项发生更改，都会为代码中的新错误打开大门。这甚至还不包括用户或系统管理员可以进行的更改。

使用 Docker，您只需担心一个环境。容器获取整个运行时生态系统，并将其放入一个盒子中，您可以在开发机器、测试服务器和生产服务器之间交换该盒子。

容器也是“按需扩展”云架构的福音。一个大型应用程序可以分解为许多相互连接的组件，这些组件协同工作。当其中一个组件过载时，可以启动一个新的实例。它可以分担压力，确保系统继续平稳运行。

但是，这种开发模型暴露了容器模型中的一个弱点。Docker 将整个操作系统（基于 Debian）捆绑到每个容器中。这被称为“镜像”。

Debian 是一个通用操作系统。它旨在支持非常广泛的应用程序和硬件，这意味着它相当大。Docker 容器中使用的镜像超过 100MB。

100MB 在桌面系统上并不是什么大问题，在传统的服务器环境中也不会引起太大的轰动。但在云计算世界中，新的容器实例被频繁地创建和销毁。在这种情况下，传输 100MB 并启动一个完整的操作系统会成为明显的资源消耗。

对于大多数软件组件来说，这是不必要的臃肿。Debian 支持的大多数服务和驱动程序对于这些模块化云应用程序来说是不需要的。需要的是更小的容器。解决这个问题的一个方案是 Unikernel。Unikernel 不是我们通常认为的完整操作系统。相反，它们仅包含支持云模块所需的底层软件。

Docker 正在投资 Unikernel，并且已经支持它们。但是，对于构成当今云应用程序的许多组件来说，它们并不是一个好的解决方案，并且将现有应用程序硬塞到 Unikernel 架构中可能很困难、容易出错且耗时。

另一种解决方案是使用更小的 GNU Linux 发行版。虽然 Debian 旨在在配置适中到高端的机器上运行，但对于非常老旧或配置有限的硬件，也有非常轻量级的发行版。这些发行版支持 GNU/Linux 规范的最低限度，这通常非常适合容器。

Alpine Linux 就是这样一个发行版。Alpine 是一个非常小的发行版，只有 4.8MB。虽然它很小，但它能够支持构成现代云应用程序的各种应用程序和服务。

Docker 正在切换到 Alpine 作为其默认操作系统镜像。尺寸的减小将大大减少其网络流量，并且意味着云应用程序的容器更小、更快。

Docker 的未来很可能在于 Unikernel 的方向，但它们是一项非常新的技术，并且需要开发人员改变视角。使用 Alpine 镜像，程序员仍然可以使用完整的（但最小的）Linux 系统。