Bitnami向基于容器的OPS转型的6个经验教训

【编者的话】容器正变得越来越“小”，虽道路坎坷却满含各种值得我们学习的经验教训。

Bitnami的软件开发人员Adnan Adulhussein在最近的Docker London Meetup大会上与会者分享了他在三年的容器化之路中学到的经验和教训。在此期间，Bitnami以可以在任何平台上进行云打包应用程序而闻名，从没有Docker容器转移到包含 70多个基于容器的应用程序的整个容器应用程序库。

他说，Bitnami已经实现了大部分构建>部署>维护容器、云、虚拟机或裸机的管道应用程序。但到了2014年中期，Adulhussein加入Bitnami的时候，“我们拥有这巨大的容器Docker镜像（我们在这个镜像中塞满了所有的东西）。这个镜像就像一个虚拟机。因此，我们还开发了一个管理这个巨大容器的内部工具。”

他表示，刚开始的时候，适应容器化的思维是困难的，而且当时的关于容器的文档也很少。这也是当ops小组意识到他们在做错误的容器时，他们仍然决定继续进行的原因，他们希望看看能不能尝试作出改进。

一年后，他们向公众发布了第一套包含八个运行时和基础设施的Bitnami镜像。详情如下：

• 已在Github上开源
• 可以在Docker Hub上自动构建
• 内容完善的文档（a strong focus on documentation）
• dogfooded（Bitnami团队正在使用这些镜像进行日常的工作）

不久，他们开始尝试使用像WordPress，Drupal和其他简单的PHP应用程序的所有功能于一身的镜像。

他们将敏捷迭代方法应用于容器化，根据需要制定策略，比如看看它是如何响应s6-Overlay进行多进程监督的。

以下是Bitnami团队这一路学到的一些经验教训：

1：每个容器一个任务

有时当你的工作开始逐渐进入容器化时，你会发现最终你的工作将被拆散揉碎。你将迷失在把所有事情都分解成小任务，这往往会造成更多的容器产生，而这些容器很可能是你无法掌控和确保安全的。另一方面，开发人员很容易养成将大量东西放入每个容器的习惯。你的应用程序只需要docker这个轻量级的，独立的，可执行的软件（详细可以参考Docker官网的代码，运行时间，系统工具，系统库和设置）。开发者提前发布的容器的自由度往往有时会被卡在老的发布习惯上（而实际上是非必须的）。

Adulhussein说，你需要寻找逻辑点来破解代码，经常聚焦在任务上，但是有时Docker文档的建议往往是动态变化的。这迫使开发人员以更全面的方式思考代码，然后分解成任务。

他说：“就像Unix如何做一件事情一样（而且它确实做得非常好） - 对于Docker容器来说也是一样的， ”他举例说：“如果分割容器是有意义的，当你有一个Web服务和一个数据库的时候，你可能想要分离应用和数据使其更具扩展性。”

而这些痛点Bitnami都可以很好的帮你解决。Bitnami帮你创建多容器应用程序，如从应用程序容器中分离数据库容器。

2：克服缺少开箱即用的操作

从2016年年中开始，Bitnami对它自己的容器做了优化，同时创建了开发容器，将像Rails和Eclipse这样的流行框架容器化了。Adulhussein表示，他们之所以走了这条路，因为他们使用的大部分应用程序不能从框架很好的扩展，因为：

• 大多数应用程序不是云原生的，也不是容器原生的;
• 他们使用的许多应用程序（例如WordPress）都将文件上载存储在文件系统中，尽管你可以重新配置插件，但不是开箱即用;
• 他们使用的许多应用程序，如Magento，都依赖于HTAccess规则

Adulhussein表示，这些开发容器允许其他团队执行诸如“在几秒钟内创建开发环境，引导一个新应用程序”等操作。如果本地目录是空的，它将挂载一个本地目录。“

3：关注容器入口点

通过Bitnami，你可以将容器入口点写在Dockerfile中。这将在容器启动时运行，并接收容器的命令（CMD）作为参数，通常用于启动一个交互式shell，如下：

• FROM bitnami / node：latest ENTRYPOINT [“node”]
• docker run mynonde -e “console.log（’hello！’）”

Adulhussein还说，你可以选择一个运行时二进制文件作为镜像入口：

Docker概述了关于入口点的更多最佳实践。

4：注意初始化系统的重要性

差不多已经两年了，容器社区已经意识到你可以运行轻量级的容器而不需要初始化或重置系统。但是，跳过初始化操作，这可能导致处理和信号的错误处理，进而可能导致容器泄漏或者无法停止的容器。综上，Bitnami的优势恰恰在于将Yelp’s dumb-init 很方便的应用于容器的简单初始化（系统）。

5：优化镜像使其更小巧

Adulhussein提供了更小的Docker镜像，这样做的好处如下：

• 更小的空间占用，
• 更快的传输，
• 更少的被攻击的概率。

他指出，“ 像Alpine和Busybox这样的东西真的是非常有用的容器，而且也是非常非常小的镜像”，它们的大小都是5MB左右。他还提供了Bitnami在2016年底发布的开源Minideb，用来作为更大的替代品（约50MB）。

他说：“如果你不能做到和Alpine很好的兼容，那么拥有一个类似于大型图书馆的管理软件将是一个不错的选择。”

6：权衡利用特权和非特权容器

参考颇受欢迎的我可以使用非特权容器吗？网站中提到的建议，Adulhussein提倡遵循OpenShift最佳实践（为了使用非特权容器）。他说，可以运行每个容器为随机的GID - GID默认为0，假设UID是未知的：

$ docker run -user  bitnami / minideb id 
uid =  gid = （root）
groups = （root）
           

他继续说，文件对root组的所有用户具有读写执行权限，并且这些服务可以绑定到非特权端口。不过，他警告说，如果执行时出错，你可能会得到一个奇怪的“无名”容器信息。

Bitnami开放源代码的目的是什么？

Bitnami正在通过向所有应用程序推出非特权和多阶段构建来优化Docker镜像。他们还增加了Bitnami的文档和教程，他们正在试验Bazel容器的构建，以及如何通过运行容器集群来使CI / CD平台受益（持续集成和持续交付）。最后，他说Bitnami也在为Kubernetes开发一些工具，包括Helm包管理器和Kubeless本地无服务器框架。

原文链接：6 Lessons from Bitnami’s Transition to Container-Based Ops（翻译：dssky2008）