容器和 DevOps 如何变革杜克大学的 IT 部门

即使在回顾时，也很难知道对我们来说哪个先出现：容器还是向 DevOps 文化的转变。

在杜克大学的信息技术办公室 (OIT)，我们开始研究容器，以此作为从用于托管网站的虚拟化基础设施中实现更高密度的一种方式。虚拟机 (VM) 蔓延已经开始成为一个问题。我们倾向于将每个客户的网站分隔到其自己的 VM 上，以实现隔离和组织，但稳步增长意味着我们管理的服务器超出了我们的处理能力。当我们寻找降低管理开销和更好地利用资源的方法时，Docker 登上了新闻，我们开始尝试使用容器化来处理我们的 Web 应用程序。

对我们来说，最初对容器的调查反映了向 DevOps 文化的转变。

我们从哪里开始

当我们最初研究容器技术时，OIT 是高度流程驱动的，由单体应用程序和单体组织结构组成。一些早期的自动化尝试开始引导部门内部向新的文化组织转变，但即便如此，我们绝大多数的基础设施仍然由“宠物”服务器组成（使用宠物与牲畜的比喻）。开发人员在旨在匹配生产托管环境的暂存服务器上创建他们的应用程序，并通过将代码从前者迁移到后者来部署。运维仍然像往常一样处理托管：为单个服务创建专用 VM，并为监控和备份提交手动工单。服务的生命周期以变更请求、审查委员会、标准维护窗口和大量的个人关注为标志。

文化转变

当我们开始拥抱容器时，这些长期以来对开发和托管的态度开始发生一些转变。两个更大的容器成功案例来自我们对云基础设施的调查。第一个项目是为了在 Microsoft Azure 主机上托管数百个用于学生课程的 R-Studio 容器而创建的，打破了我们现有的单独管理服务器的模式，转向旨在托管容器化应用程序的“牲畜”式基础设施。

另一个是在拒绝服务攻击期间，快速容器化并将杜克大学网站部署到 Amazon Web Services，动态创建基础设施并快速部署服务。

这两个非常规项目的成功帮助容器在部门内获得了合法性，更多的时间和精力被投入到进一步研究容器的好处以及按需和可抛弃的云基础设施的好处，无论是在本地还是通过公共云提供商。

很早就显而易见的是，容器的生命周期与传统基础设施不同。我们开始注意到一些案例，在这些案例中，短期的、单用途的服务被创建、部署、经历了整个生命周期，并在我们完成创建的工单以将其输入库存、监控或备份之前就被停用。我们的政策和程序无法跟上容器开发和部署的生命周期。

此外，人类无法跟上创建和管理主机上容器的自动化。作为回应，我们开始开发更多自动化来完成通常由人工控制的过程。例如，容器从一个主机到另一个主机的动态迁移需要改变我们的监控方法。将主机和服务监控联系在一起或手动提交工单已经不够了，因为容器会自动销毁并在其他主机上重新创建以响应事件。

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

随着容器越来越受欢迎，并且 OIT 开始开发用于容器编排的工具，我们试图进一步加强基础设施的“牲畜而非宠物”方法。我们限制只有运维人员才能登录主机（打破了传统），并为所有用于容器托管的主机指定通用名称。类似于被指导避免给流浪动物命名以防止产生依恋，具有通用名称的服务器实际上变得可以被遗忘。基础设施本身的管理成为自动化的责任，而不是人类，而人类则专注于容器内部的服务。

容器还有助于将持续集成引入我们的日常工作流程。OIT 的身份管理团队成员是早期采用者，并开始使用 Jenkins 在容器内部构建 Kerberos 密钥分发中心 (KDC)，定期构建以合并补丁并测试生成的镜像。这使团队能够在破坏性构建被推送到生产服务器之前捕获它们。在此之前，环境的复杂性和中断的广泛影响使修补系统成为一项艰巨的任务。

拥抱持续部署

自从最初的用例以来，我们也拥抱了持续部署。每个参与我们的持续集成/持续部署 (CI/CD) 系统的项目都有一个可靠的模式。许多团队最初对在测试通过时自动部署有很多犹豫，他们倾向于构建需要人工干预的检查点。但是，随着他们越来越适应系统并学习如何编写良好的测试，他们几乎总是删除这些检查点。

在我们的容器编排自动化中，我们使用 Jenkins 定期修补基础镜像，并在父镜像更改时重建所有子镜像。我们很早就决定，镜像可以随时通过自动化流程重建和重新部署。这意味着构建作业中使用的 git 存储库分支中包含的任何代码都将包含在镜像中，并可能在没有任何人工参与的情况下部署。虽然一些开发人员最初对此感到不舒服，但这最终导致了更好的开发实践：开发人员只将真正准备好部署的代码合并到生产分支中。

这种做法促进了在代码合并到生产分支后立即重建容器镜像，并允许我们在新镜像构建完成后自动部署它。目前，几乎每个使用自动重建的项目也都启用了自动部署。

展望未来

今天，容器和 DevOps 的采用对于 OIT 来说仍然是一个进行中的工作。

在内部，即使我们采用新的工具和文化，我们仍然必须与历史的熵作斗争。我们最大的挑战将是说服人们摆脱目前主导他们工作的重复性故障排除心态，并将更多精力放在自动化上。虽然时间总是很短，第一步总是令人生畏，但从长远来看，采用自动化来处理日常任务将使他们能够从事更有趣和复杂的项目。

值得庆幸的是，组织内部的人们开始接受在有组织的或临时的跨学科成员小组中工作，并共同开发自动化。随着我们拥抱自动化编排和复杂系统，这肯定会变得必要。需要一组拥有互补技能的才华横溢的人员来全面管理新环境。