我写了一个中等篇幅的评论解释了我如何用常规的方式为我想要的软件进行 Docker 化的。
-- Tianon Gravi
编译自 | https://tianon.github.io/post/2017/12/26/dockerize-compiled-software.html
作者 | Tianon Gravi
译者 | geekpi
我最近在docker-library/php
[1]
仓库中关闭了大量问题,最老的(并且是最长的)讨论之一是关于安装编译扩展的依赖关系,我写了一个中等篇幅的评论
[2]
解释了我如何用常规的方式为我想要的软件进行 Docker 化的。
我要在这里复制大部分的评论内容,或许扩展一点点,以便有一个更好的/更干净的链接!
我第一步是编写 的原始版本:下载源码,运行 等,清理。然后我尝试构建我的原始版本,并希望在这过程中看到错误消息。(对,真的!)
错误信息通常以 或 的形式出现。
如果我在 Debian 中构建,我会输入 (用错误信息中头文件的名称替换 “xyz.h”),或者在谷歌中搜索像 “xyz.h debian” 这样的东西,找出我需要的包的名称。
如果我在 Alpine 中构建,我将使用https://pkgs.alpinelinux.org/contents进行类似的搜索。
“libxyz development headers” 在某种程度上也是一样的,但是根据我的经验,对于这些用 Google 对开发者来说效果更好,因为不同的发行版和项目会以不同的名字来调用这些开发包,所以有时候更难确切的知道哪一个是“正确”的。
当我得到包名后,我将这个包名称添加到我的 中,清理之后,然后重复操作。最终通常会构建成功。偶尔我发现某些库不在 Debian 或 Alpine 中,或者是不够新的,由此我必须从源码构建它,但这些情况在我的经验中很少见 —— 因人而异。
我还会经常查看 Debian(通过https://sources.debian.org)或 Alpine(通过https://git.alpinelinux.org/cgit/aports/tree)我要编译的软件包源码,特别关注 (如的 文件
[6]
)以及/或者 (如的 文件
[7]
)用于包名线索。
就我个人而言,我觉得这种侦探工作很有趣,也很有收获,但我意识到我可能是一个独特的生物。我偶尔使用的另一个技术是看是否有人已经 Docker 化了我想要的东西,这样我可以直接从他们的 中知道我需要安装的东西。
对于特定的 PHP 扩展,几乎总是有人已经想出对于这个或那个模块需要的依赖,而我所要做的就是做一些轻量的工作找出它们。
不管怎样,这就是我的方法!希望这个有帮助,玩得愉快!
via:https://tianon.github.io/post/2017/12/26/dockerize-compiled-software.html
作者:Tianon Gravi
[9]
译者:geekpi校对:wxy
本文由LCTT原创编译,Linux中国荣誉推出
LCTT 译者
geekpi
共计翻译:654篇
贡献时间:1569 天
领取专属 10元无门槛券
私享最新 技术干货