DevOps 工程师成长日记系列五：部署

原文地址： https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-5-deploy-83e790545c23
原文做者： Igor Kantor
翻译君：CODING 戴维奥普斯

让咱们简要回顾下咱们的 DevOps 之旅：
在第一篇，咱们介绍了 DevOps 文化以及相关的基础技能；
在第二篇，咱们讨论了如何为未来的代码部署奠基基础；
在第三篇，咱们讨论了如何有组织地管理代码；
在第四篇，咱们讨论如何简单地打包代码。
如下是咱们贯穿先后的路线图：

若是在上图每列的技术栈上花费一个月左右的话，那么咱们如今处于第 4 个月。基于前文的学习，咱们已经知道了如何配置将要运行代码的服务器基础架构、如何正确地对代码进行版本管理、如何将代码打包以备部署。今天咱们要讨论如何部署代码。

部署代码

注意到了吗？我没有说“如何轻松地部署代码”，由于代码从开发环境到正确部署仍然是一个充满了错误和失败的痛苦过程。

缘由不少，但在我看来，这主要归结为差别。具体而言，建立代码的环境与实际代码运行的环境之间存在差别。我认为减小这些差别意味着你不只能够在总体代码部署中实现最大的改进，还能够在代码部署后的运行时达到必定的优化。那么，咱们如何减小或消除生产和非生产环境之间的差别呢？

在个人机器上明明是能够跑的

若是你的开发基础设施是这样的：

用“温柔的爱和关怀”手工组装而成的开发基础设施

但你的生产环境基础设施看起来像这样：

那你就会遇到麻烦。

若是你使用基础设施即为代码的方式而不是手动配置，那么差别这事儿你已经搞定得七七八八了。若是不是，请不要绝望 —— 你并不孤单。花一个下午，找出你所碰到的全部差别（培训、文化、人员、流程等），并逐一消除它们。

最重要的是，若是你仍在手动配置，那你可能很难去管理现代技术栈。所以你须要作的第一件事是确保涉及产品的全部内容都是由部署服务器构建的版本化软件包。假设上述事情你已经完成，我会告诉你部署代码的最佳方法是不部署代码。

现代化的代码部署

将代码部署到生产环境机器是一件很是 90 年代的事情。

现有技术的“代码部署装置”

将代码部署到一组固定生产环境机器的最大问题是：你的生产环境服务器（代码运行的地方）与你的开发环境服务器（编写代码的地方）不一样。这就难怪在部署后会当即出现大量问题。

所以，你须要尽一切可能确保构建产物（而不是一小段代码）一直处在运行环境当中。换句话说，将代码一次性部署到开发环境，克隆运行代码的整个机器环境，而后将其复制到须要的任何位置。这被称为“不可变部署”，是一个很是强大的模式，能够避免你数小时部署后的头痛。固然，若是你运行容器，一样的想法也是适用的：在任何地方部署相同的容器便可。

“可是个人生产环境和开发环境就是不一样的！”你可能会说。数据库用户名密码，链接字符串，S3 存储桶位置等等，这些都是不一样的。解决这个问题的方法是使用 12 因子应用配置原则。全部配置都须要外部化并做为环境变量传递到服务器。

例如，若是在 AWS，可使用 SSM 做为外部参数存储，它很好地集成了 CloudFormation。直接经过 aws ssm cli 命令行工具设置环境变量也很是容易。固然，其它云厂商也提供了相似的机制。

当出现问题时，你须要压制“修理”生产环境机器的冲动。这些机器是不可变的，这意味着你所作的任何修复都必须来自开发环境。事实上，你的终极目标应该是根本不容许任何在生产环境服务器上的接入。没有 ssh、没有 scp、没有人有任何访问权限，不是你，更不是觊觎中的黑客。

但若是我须要日志来解决问题呢？因此日志也应该外部化。理想状况下能够经过ElasticSearch / Logstash / Kibana（ELK）技术栈或商业软件（如 SumoLogic 或Datadog）将日志转储到其它地方。

不管你作什么，你的产品都是“黄牛” —— 它们会在出现最轻微的不健康信号时就被替换。它们不是“宠物”，须要耗费数小时进行故障排除来恢复健康。我知道这个比喻被太多人使用了，而且我听到那些真正养牛的人说过实际上他们的工做原理和咱们刚所讨论的不一样，但重点事务确实如此。不要“修复”你的生产环境机器，而是修复你的开发环境并从新部署。

代码部署机制

因此你知道要作些啥了，但怎么作呢？

“不幸”的是，这就是 Jenkins 的用武之地，Jenkins 是最受欢迎的开源部署自动化服务器之一。我说“不幸”是由于 Jenkins（及其前任 Hudson）已经存在了近十年，而且在漫长的使用过程中咱们发现了：它的设置很复杂，维护起来更复杂。它带有数以百万计的可疑质量插件。这些插件每每会在最不合适的时候崩溃，把全部事情搞砸。实际上，真正具备弹性的分布式 Jenkins 设置不多见，一般只有最大的研发组织里才能看到。

那为何我还建议你从 Jenkins 开始呢？由于尽管存在各类缺陷，它仍然很是受欢迎，而且在咱们的行业中被大量使用。了解 Jenkins，特别是 Jenkinsfile 的结构，对就业前景会是一个巨大而且不容忽视的好处。当你学习 Jenkins 时，请确保你遵循较新的 Pipeline BlueOcean 技术路径，而不是更旧的“Jenkins jobs”。

参考阅读：
Jenkinsfile：https://jenkins.io/doc/book/pipeline/jenkinsfile/
Pipeline BlueOcean：https://jenkins.io/doc/book/blueocean/

当你但愿 CI/CD 流水线被直接包含在代码仓库当中后，持续集成工具会变得很是重要，这样的话流水线自己就是一段版本化的代码。

一切都是代码

你的应用程序如何被部署、监控、配置等等——说到底最终都化做为存储在代码仓库里被正确版本化的代码片断。

咱们的目标是为核心开发人员（编写功能代码的软件工程师）建立一个真正无摩擦的环境。例如，我应该可以编写我本身的微服务、添加我认为必要的测试、添加监控即代码的配置、在一些“env.yaml” 文件中指定个人参数、将它们所有存储在一个代码仓库中；经过 CI/CD 流水线自动触发构建、测试、部署（金丝雀发布或蓝绿发布），并在完成后给我发送电子邮件。事实上，这是 DevOps 工程师核心使命的本质。

Jenkins 的替代品

就像我以前说过的那样，Jenkins 已经被广大开发者使用很长一段时间了。如今还有其它的工具，在我看来更好，即便没有 Jenkins 那么为人所知。

• 一个是 AWS 本身的 CodeDeploy 服务。它有局限性，但 CodeDeploy 背后的开发人员在过去一年作了很大的改进，若是你在用 AWS，建议你试一试。
• 另外一个是 GitLab CI。若是你的研发组织运行在 GitLab 上，你能够考虑使用，由于它与 GitLab 的其它部分良好地集成在一块儿。
• 去年十月 GitHub 宣布了 Actions（目前仍处在公测中），用于 GitHub 用户的自动化工做流场景。

我认为这里的工具并非最重要的。重要的是要记住包括代码部署流水线在内的全部内容都是版本化的软件部件，它首先得来自于开发环境，而不是生产环境。

若是你从 Jenkins 开始学习持续集成，请尝试将其设置为容器模式。这并非一件很是困难的事情，反而会是一个很不错的学习机会，你能够找到弹性的、容器化的 Jenkins 机器节点来部署容器化的 Jenkins。

你也彻底能够从简单的、没有任何容器编排的方式开始，这是下一篇文章的主题，敬请关注。

写在最后

原文做者给咱们介绍了一个很是重要的实践：在部署环境遇到的问题要去调整和修改开发环境，让生产环境与开发环境保持一致，修改生产环境治标不治本。同时也给咱们介绍了一些他喜欢的国外持续集成工具。针对国内的工具，译者推荐你还能够考虑使用 CODING 持续集成，它是 CODING 提供的一站式 DevOps 解决方案中重要的一环。其构建脚本在语法上全面兼容 Jenkins，又免除开发者部署和维护持续集成环境的繁琐事务。

同时 CODING 支持包括 Docker 镜像、Jar、APK 等软件包的构建，预置了主流开发语言的构建环境：Java、PHP、Go、Python 等等；开启缓存加速功能能够平均提升 300% 的构建速度。对于包括 Maven，NPM 在内的主流镜像源有专用网络优化，保证拉取速度； 支持单项目并行构建，以知足重度持续集成用户的需求。对不太喜欢脚本的同窗还提供了完善的图形化编排能力，以下降使用门槛。

CODING 还对构建产物提供了统一的制品库管理，目前制品库已支持 Docker 镜像、NPM、Helm 等常见包类型的制品管理。后续 CODING 会逐步支持多种主流的软件包类型来进一步完善 DevOps 工做流，敬请期待。