容器与devops

即使回顾起来，也很难知道哪个对我们最先出现：容器或向DevOps文化的转变。

在杜克大学信息技术办公室（OIT），我们开始研究容器，以此作为一种用于承载网站的虚拟化基础架构来提高密度的方法。 虚拟机（VM）泛滥已开始成为一个问题。 我们倾向于将每个客户的网站都隔离到自己的VM上，以进行隔离和组织，但是稳定的增长意味着我们管理的服务器数量超出了我们的处理能力。 当我们寻找降低管理开销和更好地利用资源的方法时，Docker成为新闻，我们开始尝试对Web应用程序进行 。

对我们而言，对容器的初步调查反映了向DevOps文化的转变。

我们从哪里开始

当我们第一次研究容器技术时，OIT是高度过程驱动的，由整体应用程序和整体组织结构组成。 早期对自动化的一些尝试开始导致部门内部向新的文化组织的转变，但是即使如此，我们的绝大多数基础结构还是由“宠物”服务器组成的（使用类比）。 开发人员在临时服务器上创建了他们的应用程序，该临时服务器旨在匹配生产托管环境，并通过将代码从前者迁移到后者来进行部署。 运营仍然像往常一样接近托管：为单个服务创建专用的VM，并提交手动票证以进行监视和备份。 服务的生命周期以变更请求，复审委员会，标准维护时段和很多个人关注为标志。

文化的转变

当我们开始拥抱容器时，这些对开发和托管的长期态度开始有些转变。 较大的两个容器成功案例来自我们对云基础架构的调查。 创建第一个项目是在Microsoft Azure主机上托管数百个用于学生课程的R-Studio容器，这打破了我们现有的独立管理服务器模型，并朝着旨在托管容器化应用程序的“牛”式基础结构发展。

另一个是在遭受拒绝服务攻击的同时，将Duke网站快速容器化并部署到Amazon Web Services，动态创建基础架构并快速部署服务。

这两个非常不规范的项目的成功帮助使部门内的容器合法化，并且投入了更多的时间和精力来进一步研究它们在内部以及通过公共云提供商所获得的收益以及按需和一次性云基础架构所带来的收益。

早期很明显，容器与传统基础架构的生存时间不同。 我们开始注意到在创建票证以将其输入库存，监控或备份之前，短暂的，单一用途的服务已被创建，部署，使用了整个生命周期并已退役的情况。 我们的政策和程序无法跟上容器开发和部署所伴随的时间表。

此外，人类无法跟上在主机上创建和管理容器的自动化。 作为响应，我们开始开发更多的自动化功能来完成通常由人为操作的流程。 例如，将容器从一台主机动态迁移到另一台主机需要更改我们的监视方法。 将主机和服务监视捆绑在一起或手动提交票证已不再足够，因为容器会根据事件自动销毁并在其他主机上重新创建容器。

其中一些已经在我们的工作中了—自动化和容器的采用似乎相互平行。 在某些时候，它们变得密不可分。

随着容器的持续流行以及OIT开始开发用于容器编排的工具，我们试图进一步加强“牛而不是宠物”的基础架构方法。 我们将主机的登录仅限于操作人员（与传统不符），并为所有指定用于容器托管主机的主机提供通用名称。 类似于为了避免附件而被指导避免为流浪动物命名那样，具有通用名称的服务器实际上已经被遗忘了。 基础架构本身的管理成为自动化的责任，而不是人类的责任，人类将精力集中在容器内部的服务上。

容器还有助于将持续集成引入我们的日常工作流程。 OIT的身份管理团队成员是早期采用者，并开始使用Jenkins在容器内构建Kerberos密钥分发中心（KDC），并定期构建以合并补丁并测试生成的图像。 这样一来，团队就可以在将破坏性构建推向生产服务器之前对其进行捕捉。 在此之前，环境的复杂性和中断的广泛影响使修补系统成为一项艰巨的任务。

持续部署

从最初的用例开始，我们还接受了持续部署。 与我们的持续集成/持续部署（CI / CD）系统相关的每个项目都有一个可靠的模式。 很多团队最初对在测试通过时自动部署有很大的犹豫，他们倾向于建立需要人工干预的检查点。 但是，随着他们对系统更加熟悉并学习如何编写好的测试，他们几乎总是删除这些检查点。

在我们的容器编排自动化中，我们使用Jenkins定期修补基本映像，并在父级更改时重建所有子级映像。 我们尽早做出决定，可以通过自动化流程随时重建和重新部署图像。 这意味着在构建作业中使用的git信息库分支中包含的任何代码都将包含在映像中，并且可能在不涉及任何人员的情况下进行部署。 尽管有些开发人员最初对此感到不满意，但最终导致了更好的开发实践：开发人员仅将真正准备好部署的代码合并到生产分支中。

这种做法有助于在代码合并到生产分支后立即重建容器映像，并允许我们在构建新映像后自动部署新映像。 在这一点上，几乎每个使用自动重建的项目都已经启用了自动部署。

展望未来

如今，对于OIT而言，同时采用容器和DevOps仍在进行中。

在内部，即使采用新的工具和文化，我们仍然必须与历史的熵作斗争。 我们最大的挑战将是说服人们摆脱目前占据主导地位的重复性的“ 断点修补”思维，而将更多精力放在自动化上。 尽管时间总是很短，而且第一步总是很艰巨，但从长远来看，采用自动化来执行日常任务将使他们有更多的时间从事更有趣，更复杂的项目。

值得庆幸的是，组织内的人们开始拥抱在跨学科成员的有组织或特设小组中工作，并共同开发自动化。 当我们采用自动化编排和复杂的系统时，这绝对有必要。 将需要一群具有互补技能的才华横溢的人来全面管理新环境。

翻译自:

容器与devops