我希望有的 DevOps 简介

更新：spacelift 的朋友们写了一篇类似的文章。欢迎大家探索，获取更多有价值的信息。

流行语随处可见。你可能注意到了，我不太喜欢它们。它们随处可见（有时甚至用错了），正因为如此，大多数人都不敢问那些101个问题，因为他们不想显得无知。

几年前，我当时的经理问我，想不想在软件工程师的岗位上做一些 DevOps 的工作。当然，当时我年轻，也因为上述原因不敢开口，所以我就说：“好吧，试试看。最坏的情况是我死了，你也只能放一天假，过个悲惨的日子了。”

感谢上帝，我还活着，用我的作品折磨着别人。所以现在我想好好地、全面地概述一下我最初接触到的那些术语，那些我真希望当时就知道的术语，以及一些当时还没有发明出来，但现在知道了也挺好的术语。

让我们开始吧

DevOps

DevOps 的创立是为了弥合开发人员和运维人员（例如 IT、系统工程师、DBA 等）之间的差距。其主要愿景是（主要）实现从开发环境到测试/生产环境的无缝、快速、自动化和完全透明的过渡。

在此之前，部署工作经常引发两个“部落”之间枕头大战和nerf射击大战（有时甚至会扔键盘），部署过程缓慢、痛苦，耗费大量工时。如果你知道有哪家软件公司没有采用这种做法，你就能轻松验证这一点。

可以想象，这一运动受到了敏捷方法论日益普及的影响，敏捷方法论强烈鼓励快速部署，并且对于严肃的软件公司来说，快速部署是常态。

IaaS

基础设施即服务。您可以启动虚拟机，选择您喜欢的操作系统（当然，云提供商必须支持，但大多数知名的 Windows 和 Linux 版本都有），并选择您喜欢的规格（RAM、持久存储、CPU 数量等）。

与所有精简的虚拟机一样，您必须自己设置一切，以获得更好的控制权。

最著名的例子是 AWS 的 EC2、Google Cloud 的 Google 计算引擎。

平台即服务 (PaaS)

平台即服务。你可以把它看作是 IaaS 的抽象。

除了业务逻辑和数据库部分之外的一切对你来说都是黑匣子。你可能了解基础设施的细节，但你对它的控制力却非常有限。

例如，您可能能够更改所使用的软件的版本，但是会发生以下情况：

• 从供应商的用户界面
• 版本修改将在供应商支持的范围内进行。如果供应商不支持 Python 3.7，你就无法使用它，如果你尝试手动更新，很可能很痛苦，而且很有可能搞砸一切。至少，这是我的经验。

最著名的例子是 AWS 的 ElasticBeanStalk、Google Cloud 的 Google AppEngine。

注意：实际案例中，*aaS 组件会进行组合。PaaS 和 IaaS 的协同工作尤为常见。这被称为混合云。

SaaS

软件即服务。在这种情况下，您需要访问一款软件（基于云），并根据实际使用情况付费（如果没有免费计划）。

除了 UI 和潜在 API 允许的操作外，你无法控制软件本身。最知名的例子是 Netflix、Dropbox 以及大多数 Google 服务。

您可以在本文中看到 IaaS、Saas 和 PaaS 的直观比较。

供应

在 DevOps 上下文中，Provisioning 意味着（自动）引导基础设施。

因此，如果有人想要配置测试环境，那么他可能必须设置一些虚拟机（不是随机虚拟机，而是特定类型的虚拟机或用作模板的某个映像），然后设置所需的软件、设置任何 Web 服务器等。听起来很无聊，是吧？

确实如此，这就是为什么人们使用可以自动为他们完成工作的配置工具（这样他们就可以在等待时毫无负罪感地浏览 Reddit 和 9gag）。

最知名的两个配置工具是Ansible和Terraform。我暂时不会详细介绍，因为这需要一篇长 5 倍的文章，但我将通过 Terraform 中的一个例子来展示它是多么简单易用。

resource “aws\_instance” “example” {
ami = “ami-b374d5a5”
instance\_type = “t2.micro”
provisioner “local-exec” {
command = “echo ${aws\_instance.example.public\_ip} > ip\_address.txt”
}
}

（从此处复制）

可能需要对上述示例进行简短解释；ami代表 Amazon Image，并且基本上是一个 VM 模板。

t2.micro 指的是机器的计算特性（CPU、RAM 等）。如果你之前没见过这个，并且对此感到好奇，可以查看这个页面。

它基本上使用预定义的 ami 设置了一个 t2.micro 实例，并且在启动时在 local-exec 部分运行 echo 命令。

Ansible 的运行机制比较低，你需要定义一组命令（称为 playbook），其中包含更详细的命令。有很多很棒的文章，比如这篇，我建议你读一读。

Docker化

Dockerazition 意味着您需要执行一些特定的步骤才能使您的应用程序与 docker 一起工作。

简而言之，Docker 是一种轻量级虚拟化手段（稍微简化了，您可以在此处阅读更多内容）。

您可以使用所谓的 DockerFile 来定义 docker 镜像，这实际上是一组逐步构建 Docker 镜像的命令。

这是你能找到的最简单的 Docker 文件之一，并附带相关说明。更多镜像可以在Docker Hub中找到。

那么，为什么 docker 会引起这么大的关注呢？docker 到底能提供什么功能呢？

使用 docker 有很多好处，但对我来说最重要的用例是：

• 可移植环境。我可以使用完全相同的环境进行开发、生产、测试​​环境、复现生产问题、向客户演示等等。不再需要“只能在我的机器上运行”这样的借口。
• 只需几条命令即可设置环境。这与配置过程非常契合，具体操作可参阅本文。

无服务器

与名称所暗示的相反，我们仍然有运行后端逻辑的服务器。实际情况是：

当你想要执行某段代码（称为函数，因此这种计算模型有时也称为函数即服务 - FaaS）时，云提供商会分配必要的资源（以动态方式）来执行它。

执行结束后，它会释放这些资源。

这些功能在各种偶然触发下运行，或者以类似 cron 的方式定期运行。

理想情况下，函数应该是纯函数，这意味着它们仅依赖于它们的参数来计算结果，而不是任何外部状态（例如数据库），尽管使用外部数据库服务器等没有问题。

主要优点是您只需关心您的业务逻辑，并且您可以瞬间扩展您的功能。

如果您想对此有更多了解，它可能特定于 AWS，但这篇文章值得一读。

这段来自 Traversy Media 的视频非常适合作为简短的介绍。

持续集成/持续交付

持续集成和持续交付。故事是这样的：不同的开发人员针对即将发布的版本或一组并行进行的功能进行开发。当代码提交时（通常是提交到主分支，尽管这是可配置的），一组操作会自动运行，目标是确保所有操作都成功。

这些操作将确保代码编译、成功运行单元测试、确保测试覆盖率高于可接受的阈值、产品的 docker 镜像生成没有错误、镜像成功部署到云环境等。

我想你能理解持续的反馈以及无需思考就能完成所有必要步骤的重要性，更糟糕的是，无需依靠意志力。你认识很多喜欢测试的开发者吗？我不认识 :D

结论

感谢您阅读本文。如果您正在进入 DevOps 领域，这是一个引人入胜的领域。我希望本文能让您更清楚地理解这些极其基础的术语。如有任何反馈，欢迎随时留言。

最初发布于 https://perigk.github.io/ 。