多亏了docker，当容器移动开始变得越来越有吸引力时，人们对轻量级的基础映像的需求是针对单个进程进行优化的，这与典型的操作系统不同。进入Alpine，一个小到3MB的轻量级linux发行版！它还提供了足够好的包存储库，这对采用它有很大帮助。不幸的是，我们已经停止采用Alpine在可能的时候，由于原因我将概述。

采用Alpine

在工作中，我们很早就开始采用Alpine进行开发、CI甚至生产。一切都很好，除了不好的时候。结果发现，要获得Alpine存储库中不易获得的包需要做很多工作。你看，Alpine使用musl libc而不是glibc，大多数流行的发行版使用后者。例如，在Alpine中编译的东西在Ubuntu上是不可用的，反之亦然。当你需要的所有软件包都存在于主要的社区alpine存储库中时，这是非常好的。如果不是这样的话，您必须自己构建它，并希望依赖项是可用的，或者至少易于构建（针对musl）。

丢失的包

有一天，在docker映像构建阶段，我们的CI开始出现故障。mysql包（这只是一个指向mariadb的兼容包）突然丢失了。我们发布了错误报告：bug#8030:在Alpine v3.3-Alpine Linux-Alpine Linux开发中缺少针对mysql和mysql客户端包的x86_64体系结构（https://bugs.alpinelinux.org/issues/8030）。值得Natanael称赞的是，这个问题在一天之内就解决了，但这个问题让我们开始质疑。

正在丢失版本

我在前一篇文章（https://ibnusani.com/article/php-curl-segfault/）中讨论过这个问题，基本上是关于在Alpine中固定包版本的困难。我会继续，但我想这家伙（https://medium.com/@stschindler/the-problem-with-docker-and-alpines-pac…）经历了同样的情况，有同样的想法。建议阅读。

当包不可用时

工作中的开发人员需要为我们的实验分支使用PHP V8js（http://php.net/manual/en/book.v8js.php），所以我不得不为我们基于alpine的图像获得扩展。有人帮我度过了大部分的麻烦，因为他在这个Github的要点中详细介绍了这些发现。基本上我们必须编译GN（https://gn.googlesource.com/gn/），下载v8源代码，然后针对musl构建它。即使有了这些步骤，这也不是一次顺利的经历。考虑到将来的更新和补丁，这种方法对我们来说是不可持续的。

系统日志限制

开发人员严重依赖通过syslog（mounted /dev/log）的应用程序日志，Alpine默认使用busybox syslog（https://wiki.alpinelinux.org/wiki/Syslog）。问题是，消息被截断为1024个字符的限制，这是非常小的。根本问题是musl有1024个syslog缓冲区的硬编码限制，这比最初的256（！）限制但仍然不够。这在默认情况下是没有意义的，我找不到一种方法来轻松配置它。

最后一根稻草

去年7月左右，Ubuntu正式发布了用于云/容器的最小Ubuntu图片。

这些映像的大小不到标准Ubuntu服务器映像的50%，启动速度快40%。

不仅基础镜像的大小只有29MB，而且您还可以使用所有的apt包！我们之前在Alpine上遇到的所有问题都使得我们很容易切换到ubuntu作为我们的基础映像，到目前为止我们对这个切换很满意。这在不说Alpine是不好的。只是不适合我们。

编辑：我需要澄清的是，这篇文章不是关于什么是更好的选择。更确切地说，这是关于抛弃Alpine。除了ubuntu minimal，几乎没有其他好的选择。:)

原文：https://dev.to/asyazwan/moving-away-from-alpine-30n4

本文：http://jiagoushi.pro/node/848

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】