作为Alpine linux的超级粉丝,我在很多构建的Docker镜像中都使用了它。生成的镜像非常小,非常小,非常适合Dockers环境。
最近我想为一个过时的项目建立Docker图像。但是Alpine的包管理器apk失败了,原因让我吃惊。
Docker最大的好处之一是什么?清晰的再现性:无论你在哪里运行镜像·,或者什么时候运行图像,结果都是一样的。
不过,可重复性不仅在运行时很重要。这在构建图像时也非常重要:同样,无论何时何地构建镜像:同样的结果!
为了实现一致的构建,您所依赖的依赖项必须固定到特定版本。你不能只是去安装nodejs,你必须非常具体,比如安装nodejs@8.10.0。
为什么?如果不确定版本号,则镜像取决于生成时的时间点。当软件包维护人员决定发布一个新版本时,它将在您下次重建映像时自动安装。
Alpine Linux确实支持两种固定包的方法:存储库和包固定。
Alpine Linux本身带有一个版本号(编写时的当前版本是3.7)。每个Alpine Linux版本都有自己的包存储库(包档案存储的地方)。
使用repository pinning,您实际上可以将包固定到所选alpinlinux版本的最新可用包版本。例如,在Alpine 3.5中,包Node.js可能是2.0,而在Alpine 3.4中是1.9。通过将存储库固定到Alpine 3.4,您将始终保持Node.js 1.9,因为alpine3.4是一个旧版本,不再更新。
通过包固定,您可以将包固定到各自的版本。它允许您指定所需包的版本,如版本1.2.3中的Node.js。听起来很完美!
不幸的是,Alpine Linux没有保留旧的包。当我尝试构建过时的项目时,我得到了apk的回复:
ERROR: unsatisfiable constraints:
postgresql-dev-10.3-r0:
breaks: world[postgresql-dev=10.2-r0]
我以前使用的postgresql开发版本(10.2-r0)不再可用。相反,10.3-r0已经发布,旧的包已经从存储库中删除。
这是一个巨大的问题,因为它迫使您避免固定包版本,而使用存储库固定。
但是,在重建映像时,软件包可能安装在您不期望的版本中。这可能是一个真正的问题,这取决于更新包时相应包中的更改。
我希望它类似于PyPI和npm:不删除任何版本,所以版本固定工作得非常好,无论您何时构建或使用您的东西。
Alpine是一个伟大的分布,特别是对码头工人。当然,我会继续使用它,但你最好在以后的软件包版本上花很多心思,并安装单元测试来覆盖你!
原文:https://medium.com/@stschindler/the-problem-with-docker-and-alpines-package-pinning-18346593e891
本文:http://jiagoushi.pro/node/849
讨论:请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】