如何在6个月或更短时间内成为DevOps工程师，第5部分:部署

【译文】原文地址

快速回顾

在第1部分中，我们讨论了DevOps文化和所需的基础。
在第2部分中，我们讨论了如何正确地为代码部署提供基础设施。
在第3部分中，我们讨论了如何保持代码管理。
在第4部分中，我们讨论了如何进行软件打包。
根据计划我们今天要介绍的是部署：

因此，如果你在每个部分上花了一个月的时间，现在是第4个月了。

我们已经知道如何提供运行我们的软件的基础设施，我们知道如何对其进行适当的版本控制，我们知道如何将其打包以便部署。

最后，我们将讨论如何部署代码!

代码部署

你是否注意到我在上面并没有说“如何轻松地部署你的代码”?这是有原因的。

不幸的是，从开发环境到生产环境正确地部署代码仍然是一个痛苦的过程，错误和失败在所难免。

为什么呢？

原因有很多，当然，但在我看来，主要归结为差异。具体来说，就是代码创建环境和代码实际运行环境之间的差异。

事实上，我认为最小化这些差异是您所能做的最大的改进，不仅是在整体代码部署中，而且包括部署后运行时。

那么，我们如何减少或消除我们的生产环境和非生产环境之间的差异呢?

在自己的机器上正常工作

如果你的开发基础设施是下面的样子：

但你的生产环境看起来是下面的样子：

那你就有问题了。

如果您使用的是基础设施即代码，而不是手工配置，那么您已经完成了90%的工作。 如果是手工配置的话，也不要绝望——你并不孤单。花一个下午的时间，找出存在的差距(培训、文化、人员、流程等)，然后一个一个地有条不紊地消除它们。

底线是，如果您仍然手工配置东西，那么您将无法成功管理现代技术栈。就这么简单。

所以，你第一件要做的事是确保所有要部署在生产环境服务器的代码都是版本控制的。

假设你就是按照这个要求来做的，我将讨论部署代码的最佳方法是根本不部署它（直接将代码和运行时搬运到需要执行的环境，容器和虚拟机镜像就是实现这个目的）。

如今的代码部署方式

没错，把代码部署到产品机器上是九十年代的事。

将代码部署到一组固定的生产机器上的最大问题是，您的生产服务器(运行代码的地方)与开发服务器(编写代码的地方)是不同的。

所以，部署后会立即出现大量以前从未见过的问题是很正常的——因为环境都不同了!

因此，您需要尽一切努力确保您的部署组件包括整个运行时，而不是一段代码。

换句话说，将代码一次性部署到开发环境中，克隆代码运行的整个机器，然后将其复制到需要的任何地方。

这就是所谓的“不可变部署”，它是一种非常强大的模式，可以为您节省部署后几个小时的麻烦。

当然，如果运行容器，同样的想法也适用:在所有地方部署相同的容器。

但你可能说我的开发环境还是和生产环境不同的。数据库用户名/密码、连接字符串、S3桶位置等，这些配置都不同。

是的，它们确实不同。

解决这个问题的方法是使用12因素应用配置原则。您的所有配置都需要外部化，并作为环境变量传递到您的机器。

例如，如果您使用AWS，则使用SSM作为外部参数存储——它与CloudFormation很好地集成。直接从aws ssm cli命令设置环境变量也非常简单。当然，其他云提供商也有类似的机制。

此外，当出现问题时，要抑制住“修理”你的生产机器的冲动。机器是不可变的，这意味着您所做的任何修复都必须来自开发环境。

实际上，你的目标是完全不允许对生产环境机器的访问。任何人不应该在生产环节中执行SSH、SCP。这样黑客也就不能访问。

但是如果我需要查日志来解决问题该怎么办呢?

你猜对了——你的日志也应该外部化，理想情况下，可以在其他地方使用ElasticSearch/Logstash/Kibana (ELK)堆栈，或者像SumoLogic或Datadog这样的商业软件收集日志。

代码部署机制

ok，现在你知道要做什么了，但是你知道怎么做了吗？

不幸的是，这正是Jenkins的用武之地。如果您不知道，Jenkins是最流行的开源自动部署化服务器软件之一。

我说不幸，是因为Jenkins已经存在十来年了。它的设置很复杂，维护起来更复杂。它附带了数百万质量可疑的插件。这些插件往往会在最不合适的时候崩溃，导致整个系统崩溃。

事实上，真正具有弹性的、多主的Jenkins设置非常罕见，通常只有在大厂才能看到。

那为什么我还建议你们从Jenkins开始呢?因为尽管它有这么多缺点，它仍然非常流行，在我们的行业中被大量使用。

了解Jenkins，特别是Jenkinsfile是如何构建的，对你的就业是一个巨大的好处，不能被忽视。

也就是说，当你学习Jenkins时，一定要遵循新的Pipeline BlueOcean路径，而不是旧的“Jenkins工作”路径。这非常重要，因为您希望您的CI/CD pipeline正好位于GitHub/GitLab仓库。这样，pipeline本身就是一段版本化的代码!

事实上，这一点非常重要，需要反复强调。

一切皆代码

你的应用程序，如何部署，如何监控，如何配置，等等-所有的代码，都存储在GitHub/GitLab/其他，版本控制系统中。

这里的目标是为核心开发人员(编写特性代码的软件工程师)创建一个真正无摩擦的环境。

例如，我应该能够编写我的微服务，添加任何我认为必要的测试，添加Jenkinsfile，添加监视配置，在“env.yaml文件中指定我的参数，所有这一切存储在一个仓库中，Jenkins自动发现仓库，构建它，测试它，部署它(作为淡黄色或蓝色/绿色)，整个流程完成之后会邮件通知我!

这就是目标!事实上，这正是DevOps工程师的核心使命的本质。

除了Jenkins还有其他选择

就像我之前说的，Jenkins已经存在很久了，现在有其他的，在我看来更好，即使不那么受欢迎的替代品。

一个是AWS自己的CodeDeploy服务。它有局限性，但CodeDeploy背后的开发人员在过去一年中做出了显著的改进，如果你在AWS，我强烈建议你尝试一下。

另一个是GitLab CI。如果您的公司使用GitLab，您可能应该从它开始，因为它与GitLab的其他部分集成得很好。

最后，GitHub宣布了Actions，这应该是他们自己的自动化。

真的，我不认为工具在这里有那么重要。重要的是知道所有的东西，包括你的代码部署pipeline，都是版本控制的结果。

无论如何，如果您从Jenkins开始，请尝试将它设置为一个容器。这不是很困难，而且将是一个很棒的学习机会，来弄清楚如何使用弹性的、容器化的Jenkins工作节点部署一个容器化的Jenkins服务。

实际上，您可以简单地开始，不需要任何容器编排，这是下一篇文章的主题。请继续关注!