DevOps 工程师成长日记系列四：打包

原文地址： https://medium.com/@devfire/h...
原文做者：Igor Kantor 
翻译君：CODING 戴维奥普斯

前情提要

在这个系列的第一篇文章中，咱们详细地介绍了 DevOps 相关的文化和基础技能；在第二篇文章中，咱们进入 DevOps 中各个模块并大体指明了如何为代码部署搭建基础；在第三篇文章中，咱们讨论了如何合理的整理已经部署的代码；本篇文章中，咱们将讨论如何打包代码以便于后续部署和执行。

如今咱们已经来到了 DevOps 周期中关于代码打包的环节。

注意：你能够看到每一个部件如何构建在前一部分上，并为后续部分奠基基础，这一点很重要。

由于不管你是在与如今仍是未来的雇主交谈，你都必须可以清楚地表达出 DevOps 是什么以及它为什么如此重要。而这就须要你经过讲述一个连贯的故事来达成——这个故事讲述了如何最好地、快速有效地将代码从开发人员的笔记本电脑发送到能赚钱的生产环境部署。

这也就是为何咱们不只仅是在学习一些比较流行的 DevOps 工具。咱们是在学习一整套被当前商业环境所需求的 DevOps 的理念和技术，以及在他们背后支持着的技术工具。

而后请记住，其实每一个部分都须要将近一个多月的学习，一整套内容学习下来应该须要将近六个月的时间。

在虚拟化出现以前

还记得那些物理服务器么？就是必须等待几周才能发货，数据中心收到，放在机架上，再花时间搞网络、安装操做系统和修补的那些？

没错，他们先来的。

举个例子，拥有居住地的惟一方法是建造一座全新的房子。须要一个住的地方？想一想盖个房子须要多久吧！虽然这个主意不错，是由于至少每一个人都有房子了，而不是由于建房子须要很长时间。在这个类比中，物理服务器就像一个房子。

不久人们就对这些事情花了太长时间而感到恼火，因而一些牛人就提出了虚拟化的想法：在一台物理机器上运行一堆假装的“假机器”，让每台假机器都像一台真机。这样若是你想要一栋房子，你能够创建本身的房子并等待六周；或者你能够直接住到公寓楼里与其余租户分享资源。这个想法也许不是完美的但已经足够，最重要的是开箱即用。

这种状况持续了一段时间，相关公司（像 VMware）也所以收割了不少利益。

直到又有人认为将一堆虚拟机填充到物理机器中还不够好：咱们须要将更多进程更紧凑地打包到更少的资源中。

就像你以为，房子太贵了，公寓也太贵了。若是只想暂时租一个房间怎么办？还想要那种能随时搬进搬出的。

因而 Docker 出现了。

Docker 的诞生

Docker 是一个新的东西，但其实 Docker 的理念很早就出现了。在 2000 年的时候，有一个叫 FreeBSD 的系统就提出过类似的概念。当时和如今的想法是隔离同一操做系统中的各个进程，即所谓的“操做系统级虚拟化”。

这在实践中意味着什么？

实际上，这意味着 Docker 的受欢迎程度急剧提高巧妙地映射了微服务的兴起——一种将软件分解为许多单独组件的软件工程方法。

而这些组件须要一个家。单独部署独立的 Java 应用程序或二进制可执行文件是十分痛苦的：管理 Java 应用程序的方式与管理 C++ 应用程序的方式不一样，这与你管理 Golang 应用程序的方式不一样。然而 Docker 能提供单一管理界面，容许软件工程师以一致的方式打包，部署和运行各类应用程序。

对于那个时候来讲，这是具备跨时代意义的。

Docker 的优点

进程隔离

Docker 容许每一个服务都具备彻底的进程隔离。服务 A 存在于本身的小容器中，具备全部依赖关系；服务 B 存在于其容器中，具备全部依赖性。并且二者彻底不会冲突。

此外，若是一个容器崩溃，只有该容器受到影响，其他的容器（应该！）仍然能继续愉快地跑着。这也有利于安全，若是容器被泄露，那么离开该容器并破解基本操做系统是很是困难的（但并不是不可能！）。

最后，若是容器行为不当（消耗太多 CPU 或内存），则能够仅将爆炸半径“压缩”到该容器内，而不会影响系统的其他部分。

部署

想一想在实践中各类不一样的应用是怎么搭建的。

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

另外，若是它是一个 Java 应用程序，它将具备一个 gradle 构建，并将其全部依赖项拉到适当的位置。

因此将各类使用不一样语言和不一样运行方式的应用程序，部署到生产环境进行构建将是一项重大挑战。

这样咱们该如何确保各个独立进程的安全呢？

更有甚者，若是出现冲突就会变得更加麻烦。好比一个服务须要 Python 依赖库 v1，而另外一个服务是基于 Python 依赖库 v2 的，由于 v1 和 v2 不能同时在同一台机器上安装，问题就产生了。

这时候，就须要 Docker。

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

运行管理

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

经过 Docker，咱们得到了一个统一的管理界面，容许咱们启动，监控，集中日志，中止和重启许多不一样类型的应用程序。这是一个巨大的胜利，并大大下降了运行生产系统的运维开销。

说了这么多 Docker 的好处，也是时候说说 Docker 的局限性了。

进入 Lambda 时代

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

其次，Docker 并不是 100％ 安全，至少不像虚拟机那样。大公司在虚拟机内部运行托管容器而不是在裸机之上，这样作是有缘由的——他们想要容器的快速启动时间和虚拟机的安全性。

第三，没有人真正按原样运行 Docker。相反，它几乎老是做为复杂的容器编排结构的一部分进行部署，例如 Kubernetes，ECS，docker-swarm 或 Nomad。这些是至关复杂的平台，须要专职人员来操做。

可是，若是我是开发人员，我只想编写代码并让其余人管运行的事，Docker，Kubernetes 和其余繁琐的东西都不是简单的东西——因此我真的须要学么？这就要具体问题具体分析了。

对于那些只想让其余人帮忙运行其代码的人来讲，AWS Lambda（以及其余相似的解决方案）就是答案：

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

若是你据说过“serverless”，这就是它！再也不须要运行的服务器或要管理的容器，只需编写代码，将其打包成 zip 文件，上传到亚马逊并让他们处理那些烦人的问题。

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

这样看来像 Lambda 这类的 serverless 功能真的挺不错的，可是即便这样，也是有缺点的。

第一，就现阶段而言，Lambda 暂时不支持长时间的进程。

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

第三，对 Lambda 进行故障排除是很困难的。做为云原生的应用，全部的 bug 修复都须要在亚马逊生态系统中修复，这一般挺烦人的且不直观。

简单来讲鱼和熊掌不能兼得，要根据本身的实际状况进行选择。

总结

Docker 和 Lambda 是时下最流行的云原生对应用进行包装、运行和管理的方式。它们一般是互补的，适用于不一样的用例和应用场景。

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

到目前为止，在咱们的系列中，咱们已经处理了初级到中级 DevOps 相关主题。在后续章节中，咱们将开始讨论更适合中级到高级 DevOps 工程师的技术。可是，与往常同样，没有捷径可循，须要一步一步脚踏实地！

译后记

CODING 近期正式推出了 CODING 2.0 致力于帮助大型企业和项目以最低的成本和精力推进 DevOps 转型，同时也上线了制品库和全新的持续集成功能，为企业搭建 DevOps 的核心枢纽。有效解决研发团队解决应用管理管理粗犷和版本追踪混乱的问题。在 CODING 2.0 的 DevOps 自动化流水线当中，持续集成的构建物自动存入制品库中，在部署时按需获取对应的版本，制品库让研发团队真正作到 deploy anytime anywhere。

同时，CODING 也会持续关注并分享软件研发领域最新理念与技术，与 DevOps 工程师一块儿成长。