🍿 🐺 🧢 如何在六个月甚至更快的时间内成为一名DevOps工程师。第5部分。部署 🛀🏾 🚴🏿 🤶

如何在六个月甚至更快的时间内成为一名DevOps工程师。第1部分。简介
如何在六个月甚至更快的时间内成为一名DevOps工程师。第2部分。配置
如何在六个月甚至更快的时间内成为一名DevOps工程师。第3部分。版本
如何在六个月甚至更快的时间内成为一名DevOps工程师。第4部分。软件包装

刷新内存

上图显示了典型代码部署的外观。让我提醒您，根据路线图，我们现在所处的位置：

如果您花了一个月的时间研究每个部分，那么您现在只有4个月了。到此时，您应该已经知道如何提供将与您的软件一起使用的基础结构，如何正确管理软件版本以及如何将它们打包以供将来部署。在本文中，我们将讨论如何正确部署您的代码！

代码部署

您是否注意到我说的是“怎么做”而不是“多么容易”？不仅如此。不幸的是，将代码从开发环境正确部署到产品环境仍然是一个痛苦的过程，充满了错误和崩溃。造成这种情况的原因很多，但我认为，这主要归因于创建代码的环境与执行代码的环境之间的差异。

最小化这些差异是您不仅在部署过程中，而且在部署后执行过程中最好的做法。那么，我们如何减少和/或消除产品和非产品环境之间的差异？

它可以在我的车上工作！

如果您的开发基础结构看起来像这样：

生产的基础结构看起来像这样：

考虑您的问题。如果您以代码形式使用基础结构，并且不手动配置，则可以解决90％。如果不是，请不要绝望-您并不孤单。突出显示下午，确定您的差距（学习，文化，人员，流程等），并有条不紊地逐一填补。

最重要的是，如果您仍在手动配置事物，那么您将无法成功管理现代技术堆栈。这是一个公理。您需要做的第一件事是确保与prod相关的所有内容都是您的部署服务器所部署的版本控制的工件。

假设所有这些工作都已完成，那么我将断言，部署代码的最佳方法是根本不部署代码。

现代部署方法

的确，在计算机上部署代码是对1990年代的呼应。将代码部署到一组生产机器上时，最大的问题是，按照定义，您的prod服务器（在其上执行代码）与dev服务器（编写此代码的位置）不同。部署后立即出现许多以前从未注意到的问题也就不足为奇了，因为现在情况已经改变了！

因此，在部署之前，您需要确保部署工件是整个运行时，而不是代码的一部分。换句话说，在开发环境中部署代码一次，克隆运行代码的整个计算机，然后将其复制到任何应有的位置。

这称为“不变部署”，是一个非常强大的模板，可以在部署后为您节省许多时间。当然，如果运行容器，则适用相同的想法：将相同的容器部署到各处。您可以说：“停下来！我的产品与开发人员不同！“是的，因为数据库的用户名/密码，连接字符串，S3垃圾站位置都是不同的！是的，它们是完全不同的东西。

解决此问题的方法是使用12因子app config的原理。十二个因素的应用程序将配置存储在env vars或env环境变量中。可以在部署之间轻松更改环境变量，而无需更改代码。与配置文件不同，不太可能将它们意外保存到代码存储库中，并且与自定义配置文件或其他配置机制（例如Java系统属性）不同，它们是与语言和操作系统无关的标准。因此，必须将整个配置外部化并作为环境变量传输到计算机。

例如，如果您在AWS中，请使用SSM作为参数的外部存储库-它与CloudFormation完美集成。直接从AWS ssm cli命令设置环境变量也非常容易。当然，其他云提供商也有类似的机制。

另外，当出现问题时，请抵制“修复”产品机器的冲动。机器必须是不可变的，这意味着您所做的所有更正必须来自dev。您的目标应该是完全禁止使用生产机器。既不是ssh，scp也不是prod的访问权限-绝不对任何人，自己或新手黑客开放。

但是，如果我需要日志来解决问题怎么办？您猜对了-您的杂志也应该外在化，理想情况下是使用ElasticSearch / Logstash / Kibana（ELK）堆栈或使用SumoLogic或Datadog等商业软件发送到其他位置。

无论您做什么，生产的机器都是“工作中的牛”，一旦出现任何健康状况，便会被替换。它们不是“宠物”，需要花费大量时间进行故障排除才能治愈。

我知道这个比喻使用得太频繁了，我从真正关心牛的人那里听说这并不完全正确，但是本质是相同的-不要“修理”您的生产机器，只修复您的开发并重新部署它。

代码部署机制

因此，您知道该怎么办，但您不知道该怎么办。不幸的是，这就是詹金斯出现的地方。如果您不知道，那么Jenkins是最流行的开源部署自动化服务器之一。

我之所以说“不幸”，是因为詹金斯（及其前任哈德森）在我们身边已经快十年了，这一点很明显。设置起来很复杂，甚至维护起来也更加困难。它带有数百万质量可疑的插件。通常，这些插件会在最不合时宜的时间中断，将其他所有内容都抛在身后。实际上，詹金斯的讲习班真正稳定，很少见，通常只在最大的组织中看到。

为什么我建议您从詹金斯开始？因为尽管有很多缺点，它仍然非常流行并在IT领域中得到广泛使用。知道Jenkins，尤其是Jenkinsfile的结构，对于求职者来说是一个巨大的优势，而且不容忽视。探索Jenkins时，请确保您使用新的Pipeline BlueOcean插件，而不要使用过时的Jenkins作业管道。如果您希望您的CI / CD管道直接存在于GitHub / GitLab回购代码中，那么这至关重要。因此，管道本身就是一段代码版本！

实际上，它是如此重要，值得再次重复：一切都是代码！您的应用程序，部署方式，跟踪方式，配置方式等都是存储在GitHub / GitLab / Anywhere中的适当版本化的代码段。这样做的目的是为主要开发人员（编写功能代码的软件工程师）创建一个无矛盾的环境。

例如，我应该能够：

编写自己的小微服务；
添加我认为必要的任何测试；
添加Jenkinsfile
添加监视即代码配置；
在env.yaml文件中指定我的参数；
将所有这些保存在一个存储库中；
使Jenkins自动检测指定的存储库；
建立您的微服务；
测试；
展开（使用Canary或Blue-Green方法）；
完成后，安排向您的电子邮件发送消息！

这是目标，而这一目标的实现是DevOps工程师的核心使命的本质。

詹金斯的替代品

正如我之前所说的，詹金斯已经存在了很长一段时间，在我看来，今天有其他人是最好的，尽管不太受欢迎。其中之一是AWS CodeDeploy。它有局限性，但是开发人员在过去的一年中取得了重大进步，如果您在AWS上工作，我建议您尝试CodeDeploy。

第二种选择是GitLab CI持续集成模块。如果您的组织正在运行GitLab，则您可能应该开始使用它，因为它已与GitLab的其余部分很好地集成在一起。

最后，GitHub宣布了自己的工具来部署Actions应用程序，该工具由其自己的自动化技术支持。

实际上，我认为这里的工具并不重要。重要的是要知道，包括代码部署管道在内的所有内容都是版本化的工件，除非来自开发人员，否则一切都不会付诸实践。

无论如何，如果您从Jenkins开始，请尝试将其设置为容器。这不是很困难，并且是学习如何使用Jenkins可扩展的容器工作节点部署Jenkins容器服务器的绝佳机会。实际上，您无需任何容器编排就可以开始，这是下一篇文章的主题。

即将继续...

一点广告：）

感谢您与我们在一起。你喜欢我们的文章吗？想看更多有趣的资料吗？通过下订单或向您的朋友推荐给开发人员的基于云的VPS，最低价格为4.99美元，这是我们为您发明的入门级服务器 的独特类似物：关于VPS（KVM）E5-2697 v3（6核）的全部真相10GB DDR4 480GB SSD 1Gbps从$ 19还是如何划分服务器？（RAID1和RAID10提供选件，最多24个内核和最大40GB DDR4）。

阿姆斯特丹的Equinix Tier IV数据中心的戴尔R730xd便宜2倍吗？仅在荷兰有2台Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100电视！戴尔R420-2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB-$ 99起！阅读有关如何构建基础设施大厦的信息。使用Dell R730xd E5-2650 v4服务器花费一欧元9000欧元的c类？

如何在六个月甚至更快的时间内成为一名DevOps工程师。第5部分。部署