[译]如何在六个月或更短的时间内成为 DevOps 工程师，第四部分：打包

• 原文地址：How To Become a DevOps Engineer In Six Months or Less, Part 4: Package
• 原文做者：Igor Kantor
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Raoul1996
• 校对者：7Ethan

如何在六个月或更短的时间内成为 DevOps 工程师，第四部分：打包

“Packages” 由 chuttersnap 拍摄并发表在 Unsplash 上

快速回顾

在第 1 部分，咱们聊了聊 DevOps 的文化和所须要的基础：

• [译] 如何在六个月或更短的时间内成为 DevOps 工程师（系列文章第一篇）

在第 2 部分，咱们讨论了如何为部署未来的代码奠基基础：

• [译] 如何在六个月或更短的时间内成为 DevOps 工程师，第二部分：配置

在第 3 部分，咱们探讨了如何组织部署代码：

• [译] 如何在六个月或更短的时间内成为 DevOps 工程师，第三部分：版本控制

这个部分，咱们将说一说怎么打包你的代码以便于部署和后续执行。

做为参考，这里是咱们的旅程：

打包

注意：你能够看到每一部分如何前一部分之上，并为后续部分奠基基础。这很重要而且是有目的的。

缘由是，不管你与如今的老板仍是之后的老板交谈，你都得能清楚表达出什么是 DevOps 而且为什么它这么重要。

你经过讲述一个连贯的故事来作到这一点 —— 这个故事讲述了如何既好又快地把代码从开发者的笔记本电脑上发送到能赚钱的生产环境（prod）部署。

所以，咱们正在学习的并非一堆割裂的、时髦的 DevOps 工具，咱们正在学习的是是一系列受业务需求驱动，由技术工具支持的技能。

好了，哔哔够了，让咱们开始吧！

虚拟化入门

还记得物理服务器吗？你必须等待几周才能得到 PO 批准，发货，数据中心接收，上架，联网，安装操做系统以及打补丁。

是的，那些都是之前的方式。

设想一下，假如得到住所的惟一方式是建造一座全新的房子。当咱们须要一个住的地方的时候，那不是要等很长时间么？有点意思。然而每一个人都有房子，但也不是真的由于建造房子须要很长时间。在这个类比中，物理服务器就像一个房子。

而后人们对花了这么长的时间去作这堆事情感到恼火，有些很是聪明的人提出了 虚拟化 的想法：如何在一台单独的物理机上运行一堆假装的“机器”，并让每台假机器假装成一台真机。天才！

因此，若是你真的想要一套房子，你能够建造你本身的并等待 6 周。或者你能够住在公寓楼里和其余租户共享资源。或许不是很棒可是足够好了。可是更重要的是，不须要等待！

这种状况持续了一段时间，而且 VMWare 公司在这方面拥有了霸主地位。

直到其余聪明的人认为将一堆虚拟机填充到物理机还不够好：咱们须要压缩更多的程序以更紧凑的方式打包到更少的资源中。

在这一点上，房子太贵了，公寓也太贵了。若是咱们只须要暂时租用一间屋子呢？这太棒了，我能够随时出入！

因而，Docker 应运而生。

Docker 的诞生

Dokcer 是新的可是 Docker 背后的思想是很古老的。一个叫 FreeBSD 的系统有一个 jails 的概念，其可回溯到 2000 年！诚然一切新的都是旧的。

当时和如今的想法都是在同一个操做系统中隔离单个进程，即所谓的“操做系统级虚拟化”。

注意：这和“彻底虚拟化”不一样，后者是在同一物理主机上并行运行虚拟机。

这实际上意味着什么？

实际上，这意味着 Docker 的兴起巧妙地反映着微服务的兴起 —— 一种软件工程的方法，其中软件被分解成多个独立的组件。

而且这些组件须要一个家。单独部署他们，部署独立的 Java 应用程序或者二进制可执行文件很是痛苦：你管理 Java 应用程序的方式和管理 C++ 应用程序的方式不一样，这和管理 Golang 应用程序的方式也是不一样的。

相反，Docker 提供单一的管理界面，让软件工程师以一致的方式打包（！）、部署、运行各类各样的应用程序。

这是一个里程碑！

OK，咱们一块儿来聊聊 Docker 更多的好处。

Docker 的好处

进程隔离

Docker 容许每一个服务有彻底的进程隔离。服务 A 和本身全部的依赖一块儿存在于本身的小容器之中，服务 B 也和本身的依赖存在于本身的容器中，并且两者没有冲突！

此外，若是一个容器挂了，只有该容器会被影响。其他的（应该）将会继续愉快地运行着。

这对于安全的好处也是显而易见的。若是容器被泄露，那么离开容器并破解宿主系统是很是困难的（并不是不可能！）。

最后，若是容器发生了故障（占用了太多的 CPU 或者内存），则能够仅仅将爆炸半径”包含“到该容器，而不会影响系统其它部分。

部署

想一想实际上如何构建不一样的应用程序。

若是它是一个 Python 应用程序，它会有各类各样的 Python 包。一些做为 pip 模块安装，另外一些是 rpm 或者 deb 包，其它则是简单的 git clone 安装。或者使用 virtualenv，它将是 virtualenv 目录中全部的 zip 文件。

另外一方面，若是它是一个 Java 应用程序，他将用 gradle 构建，其全部依赖关系被拉取并放到适当的位置。

你抓住了关键点。在将这些应用程序部署到 prod 环境中时，各类应用程序，使用不一样语言和不一样运行时（runtime）构建都是一项挑战。

咱们怎么样才能保持全部的依赖关系都知足呢？

另外，若是存在冲突，问题会更加严重。若是服务 A 依赖于 Python 库 v1，可是服务 B 依赖 Python 库 v2 怎么办？如今存在冲突，由于 v1 和 v2 不能再同一台机器上共存。

选择 Docker。

Docker 不只容许彻底进程隔离，还容许彻底的依赖隔离。在同一个操做系统上并排运行多个容器是彻底可行并常见的，每一个容器都有本身冲突着的库和包。

运行时管理

一样，咱们管理不一样应用程序的方式因应用程序而异。Java 代码的日志记录方式不一样，启动方式不一样，监控方式和 Python 不一样，Python 和 GoLang 等也不一样。

经过 Docker，咱们获得了一个统一的管理界面，容许咱们启动、监控、收集日志、中止和重启多种不一样类型的应用程序。

这是一个里程碑，并大大下降了运行生产系统的运营开销。

选择 Lambda

伴随着 Docker 的伟大，它也有缺点。

首先，Docker 仍在运行服务器上。服务器很脆弱，必须对它们进行管理，修补和其余方面的保护。

其次，没有人按照原样运行 Docker（译者注：这里的意思应该指的是并无彻底像前面提到的彻底进程隔离，不相互影响之意）。相反，它几乎老是做为复杂容器编排结构的一部分进行部署。例如 Kubernetes、ECS、docker-swarm 或者 Nomad。这些是至关复杂的平台，须要专门的人员来操做（稍后将详细介绍这些解决方案）。

可是，若是我是开发人员，我只想编写代码并让其余人为我运行它。Docker、Kubernetes 和全部的这些”爵士乐“都不是简单易学的东西 —— 我真的须要吗？

简而言之，这取决于！

对于那些只是想让其余人运行他们的代码的人，AWS Lambda（或者相似的解决方案）是问题的答案：

AWS Lambda 容许你在不配置或者管理服务器的状况下运行代码。你只须要为你消耗的计算时间付费 —— 当你的代码未运行时不收取任何费用。

若是你据说过整个 ”serverless“ 运动，那就是它。再也不须要运行着的服务器或者要管理的容器。只须要编写代码，将其打包成 zip 文件，上传到 Amazon 而且让他们处理头痛（的运维）！

此外，因为 Lambda 很是短暂，没有什么能够破解的 —— Lambda 在设计上很是安全。

太棒了，不是吗？

可是（惊不惊喜！）有警告。

首先，Lambda 最多只能运行 15 分钟（截止 2018 年 11 月）。这意味着长时间运行的进程，如 Kafka consumers 或者数字运算应用程序没法在 Lambda 中运行。

其次，Lambda 是功能即服务（Function-as-a-Service），这意味着你的应用程序必须彻底分解成微服务，而且和其余复杂的 PaaS 服务协调，如 AWS Step Functions。并不是每一个企业都处于这种微服务架构的水平。

第三，对于 Lambda 进行故障排除很困难。他们是在云原生（cloud-native）运行时，全部的错误修复都发生在 Amazon 生态系统中。这一般具备挑战性且不直观。

简言之，没有免费的午饭。

注意：如今还有 ”serverless“ 的云容器解决方案。AWS Fargate 就是这样的方法。可是，我忽略了这一点。由于这些每每至关昂贵而且使用要当心。

总结

Docker 和 Lambda 是打包、运行和管理生产应用程序的两种最流行的现代云原生方法。

他们一般是互补的，每种都适用于略有不一样的场景和应用程序。

不管如何，现代 DevOps 工程师必须精通二者。所以，学习 Docker 和 Lambda 是很好的短时间和中期目标。

注意：到目前为止，在咱们的系列中，咱们已经涉及了初级到中级 DevOps 工程师都应该知道的主题。在后续章节中，咱们将讨论更适合中级到高级 DevOps 工程师的技术。可是，和往常同样，没有捷径可言！

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。