alpine 安装 redis_「容器架构」Debian和 Alpine作为基准Docker映像的对比

大多数官方Docker映像都提供基于Debian和Alpine的映像，但两者之间有一些令人惊讶的性能结果。自从Docker宣布他们开始在正式的Docker镜像中使用Alpine以来，我就跳槽并拥抱Alpine。

我的意思是，什么都不爱。它是Linux的最小发行版，攻击面非常小。将其作为容器中的基础映像运行似乎是完美的选择。

我写了一篇关于Alpine一年多以前的文章，并且一直以来一直在使用Alpine，而没有出现任何停止演出的问题。

为什么现在要比较这两个基本镜像？

我今天绝对没有醒来，想着“老兄，我想知道Debian在2018年如何成为Alpine作为基础Docker映像”。

真正发生的是，我整理了一篇文章，介绍了一个月前的一些Docker最佳实践，并将其引入了Reddit。

令我惊讶的是，它在Reddit社区获得了150多个投票，99％的投票评分和大量参与。

老实说，这就是我写这篇文章的原因。我使用Docker已经很长时间了，多年来，我选择了一些我认为很好的模式，但是我真的很想看看其他人在做什么，以便我可以改进。我一直在向别人学习。

发现关于Alpine的2种负面趋势

如果您通过Reddit评论，就会发现很多人评论DNS在Alpine中是如何随机失败的，而其他人则评论了某些类型的活动(例如连接到数据库的网络应用)的运行时性能不佳。

DNS查找问题：

我不是一个盲目听从一个人的评论的人，但是一旦有几个人开始提及同一件事，它就会变得很有趣。但是，如果没有某种类型的科学证据，我仍然无法相信一些评论。

幸运的是，有人链接到与Alpine相关的GitHub问题，其中包含更多信息。也许该错误会在适当的时候得到修复，但是在Alpine内部进行DNS查找似乎确实有些奇怪。

也可能与BusyBox中的9年错误有关(Alpine在后台使用此操作系统)。

我没有亲身经历过，但是我也没有运行过使用大规模Kubernetes集群的rofl规模的任何事情，因此也许我不受此问题的影响。

对我们来说幸运的是，Alpine拥有有关DNS查找为何可能失败的文档，并且还解释了为什么我从未遇到过此问题。很高兴知道。