【译文】原文地址
快速回顾
在第1部分中，我们讨论了DevOps文化和所需的基础。
在第2部分中，我们讨论了如何正确地为代码部署提供基础设施。
在第3部分中，我们讨论了如何保持代码管理。
在这里，我们将讨论如何打包代码以方便部署和后续执行。
作为参考，我们的规划如下:
注意:您可以看到每个部分是建立在前一部分的基础上，并为后续部分奠定基础的。这很重要，而且是有目的的。
原因在于，无论你是在和你现在的雇主还是未来的雇主交谈，你都必须能够清楚地说明DevOps是什么，以及它为什么重要。
你可以通过讲一个连贯的故事来做到这一点——一个如何将代码从开发人员的笔记本电脑上快速高效地发布到一个赚钱的产品部署上的故事。
因此，我们并不是在学习一堆孤立、时髦的DevOps工具。而是在学习一套被业务需求驱动、技术工具支持的技能。
记住，每个阶段大约是一个月的学习时间，总共是6个月。
好了，废话少说，我们开始吧!
基于虚拟化
还记得物理服务器吗?那些你不得不等上几周才能获得审批、发货、数据中心接收、安装、联网、安装操作系统和打补丁。
人们对所有事情花费的时间感到恼火，一些非常聪明的人提出了虚拟化的想法:如何在单个物理机器上运行一堆假装的“机器”，并让每个假装的机器工作的和真正的机器一样。
打个比方，如果你想要一所房子，你可以自己建一所，但要等六个星期。或者你也可以住在公寓里，和其他租户共享资源。也许没自己建的房子那么舒服，但已经足够好了!最重要的是，没有等待!
这种情况持续了一段时间，一些公司(比如VMWare)在这方面取得了绝对的成功。
直到其他聪明的人认为在物理机器中塞入一堆虚拟机还不够好:我们需要更紧凑的打包方式，将更多的进程放在更少的资源中。
在这一点上，房子太贵了，公寓仍然太贵。如果我只是想暂时租个房间怎么办?太神奇了，我可以随时进出!
本质上，就是docker实现的原理。
docker的诞生
Docker是项新的技术，但是Docker背后的理念是非常古老的。一个名为FreeBSD的操作系统有一个监狱的概念，可以追溯到2000年!的确，一切新事物都是基于旧的。当时和现在的想法都是在同一个操作系统中隔离单个进程，这就是所谓的“操作系统级虚拟化”。
注意:这与“完全虚拟化”不同，后者是在同一物理主机上运行多个虚拟机。
这在实践中意味着什么?实际上，这意味着Docker的流行正好反映了微服务的兴起，微服务是一种软件工程方法，将软件分解成许多独立的组件。
这些组件需要一个执行环境。单独部署它们，作为独立的Java应用程序或二进制可执行文件是一个巨大的痛苦:你如何管理一个Java应用程序不同于你如何管理一个c++应用程序，这也不同于你管理一个Golang应用程序。
相反，Docker提供了统一的管理接口，允许软件工程师以一致的方式打包(!)、部署和运行各种应用程序。
这是一个巨大的胜利!
好的，让我们来谈谈Docker的优缺点。
docker有优点
进程隔离
Docker允许每个服务都有完整的进程隔离。服务A存在于它自己的小容器中，包含了它所有的依赖。服务B存在于它的容器中，以及它的所有依赖。而这两者并没有冲突!
此外，如果一个容器崩溃，只有这个容器内进程受到影响。其余的将(应该)继续快乐地运行。
这也有利于安全性。如果一个容器被破坏了，要想从这个容器中出来并入侵宿主机操作系统是极其困难的(但不是不可能的!)
最后，如果一个容器行为不正常(消耗太多CPU或内存)，它可能只影响本容器范围之内，而不会影响系统的其他部分。
部署
想想各种应用程序在实践中是如何构建的。
如果是一个Python应用程序，它将有一系列不同的Python包。有些通过pip模块安装，有些是rpm或deb包，还有一些是简单的git克隆安装的。或者，如果使用virtualenv，将是virtualenv目录中所有依赖项的zip文件。
另一方面，如果它是一个Java应用程序，它将有一个gradle构建，将其所有依赖项分散到适当的位置。
你明白了吧。各种通过不同的语言和运行时来实现的应用程序，导致部署到生产环境成为挑战。
我们如何才能保证应用程序所有的依赖得到满足呢？
另外，如果有冲突，问题会更严重。如果服务A依赖于Python库v1，而服务B依赖于Python库v2，该怎么办?现在出现了冲突，因为v1和v2不能在同一台机器上共存。
使用Docker，Docker不仅支持进程隔离，还支持依赖隔离。在相同的操作系统上，多个容器并排运行是完全常见的，每个容器都有自己包，包括相互冲突的库和包。
运行时管理
同样，我们管理不同应用程序的方式也不同。Java代码日志与Python不同，启动方式和监控方式都不同。Python也不同于Golang等等。
通过Docker，我们获得了一个独立、统一的管理接口，允许我们启动、监控、集中日志、停止和重启许多不同类型的应用程序。
这是一个巨大的胜利，大大减少了运行应用的操作开销。
尽管docker很好，但也存在缺点。
引入Lambda
首先运行docker还是运行服务器。 服务器很脆弱。它们必须得到管理、修补和照顾。
第二docker并非100%安全。至少不像VM那么安全。运行托管容器的大型公司之所以在vm内运行容器，而不是在裸金属之上，是有原因的。他们想要快速的容器启动时间和虚拟机的安全性!
第三，没有人只单纯运行Docker。相反，它几乎总是作为一个复杂的容器编排架构的一部分部署，如Kubernetes、ECS、docker-swarm或Nomad。这些都是相当复杂的平台，需要专门的人员来操作(稍后会详细介绍这些解决方案)。
然而，如果我是一名开发人员，我只想编写代码，然后让别人替我运行它。Docker, Kubernetes和所有类似技术都不简单，我真的要学吗?
简单的回答是，看情况而定!
对于那些只想让别人来运行他们的代码的人来说，AWS Lambda(以及其他类似的解决方案)是最合适的。
AWS Lambda允许您在不配置或管理服务器的情况下运行代码。您只需要为所消耗的计算时间付费——当您的代码不运行时，不需要支付任何费用。
如果你听说过“无服务器”运动，这就是它!不再需要运行服务器或管理容器。只需要编写代码，将其打包到一个zip文件中，上传到Amazon，让他们来处理那些头痛的问题!
此外，由于基于Lambdas的服务存在时间短，没有什么可被黑客攻击的——Lambdas在设计上是相当安全的。
是不是很棒？确实如此，但是也有一些需要注意的地方。
Lambdas是函数即服务(Functions-as-a- service)，这意味着您的应用程序必须完全分解为微服务，并与AWS Step Functions等其他复杂的PaaS服务协调。并不是每个企业都达到这种微服务体系结构的要求的。
对Lambdas进行故障排除很困难。它们是云原生运行时，所有的错误修复都发生在亚马逊生态系统内。这通常具有挑战性和非直觉性。
总之，天下没有免费的午餐。
总结
Docker和Lambda是当今最流行的两种打包、运行和管理生产环境应用的云原生方法。
它们通常是互补的，各自都适合略有不同的场景和应用程序。
无论如何，现代DevOps工程师必须精通这两项技术。因此，学习Docker和Lambda都是很好的中短期目标。
注意:到目前为止，在我们的系列文章中，我们已经讨论了初级到中级DevOps工程师应该知道的主题。在接下来的章节中，我们将开始讨论更适合中级到高级DevOps工程师的技术。然而，正如往常一样，经验是没有捷径的!
接下来
要了解有关现代部署最佳实践的所有内容，请关注!