CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章什么是DevOps？一份简单易懂的教程由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

DevOps是对已建立的 IT流程的简化或者自动化。这里有一个简短的教程来帮助你理解和开始使用 DevOps.

DevOps…CI/CD…Docker…Kubernetes…我敢肯定你在过去的一年里经常听人说这些词。好像全世界都在谈论这些技术，以至于你觉得即将到达NoOps阶段.

别担心，在工具和各种最佳实践的浩瀚海洋中感到迷失是正常的。是时候让我们来分析一下DevOps到底是什么了.

这篇文章的目的，就是为你建立一个坚实的基础。所以让我们从一个明显的问题开始.

什么是DevOps?

  。

DevOps是对已建立的 IT流程的简化或者自动化.

我见过很多人开始使用DevOps，最终却都迷失了。这似乎是一种魔咒.

通常从一段视频开始，讲述一家高科技初创公司是如何自动化整个产品发布流程的。一旦所有测试通过，部署就会自动进行。发生故障时，可以自动回滚。同时进行A/B测试，提高了客户参与度.

老实说吧，我们都想实现这样的DevOps。我们都厌倦了像坐过山车一样的发布新版本.

不幸的是，DevOps不是这样工作的。DevOps并不是一根魔法棒，它能在一瞬间解决你所有的问题.

相反，这是一个系统性的工程，你应该使用合适的工具和技术来完成不同的任务.

所有的一切都是为了流程 。

具体是什么流程并不重要，只要它可以简化应用程序的部署或者自动化测试，让你的生活更轻松，那这就是DevOps的全部内容.

事实上，如果你的流程不能手动完成(针对较小的流程)，你可能需要重新定义你的流程.

好了，让我们举一个真实的例子来更好地理解“流程”.

一个真实的DevOps例子 。

我们举一个，在云虚拟机上部署Nodejs应用程序的例子.

流程 。

我们的流程如下:

从源代码开始(Start with the source code)：只要我们能访问源代码，我们就可以在任何地方运行我们的代码.

构建制品(Build an Artifact)：然后我们打包源代码来构建一个制品。如果是Java语言，那么JAR文件就是我们的制品。但在我们Nodejs的例子中，源代码本身就是要发布的制品.

发布到制品仓库(Publish to an Artifact Repository)：接下来，我们将制品推送到制品仓库。然后我们的虚拟机就可以从制品仓库中提取制品。我们可以直接使用Github作为我们的制品仓库，因为我们的源代码即制品.

拉取并运行应用程序(Pull and run your app)：最后，我们将制品拉取到虚拟机上，并通过指令npm start来启动Nodejs进程.

我们的第一个DevOps项目

  。

我们不会在这里做任何花哨的事情。最简单的自动化的方式就是写一个shell脚本，按顺序顺序运行所有命令。恭喜你完成了我们的第一个DevOps项目!!.

我知道shell脚本听起来太简单了，不值得认真对待。我怀疑你曾经也写过这样的脚本。但相信我，这就是DevOps.

别担心，我们马上就可以看到那些花哨的东西了。但重要的是要理解DevOps就是这样工作的.

“可重复”的重复性

  。

让我问你一个问题。你喜欢以下哪一个？

一个在60%的时间内，能正常工作的自动化部署管道,

一个无聊的shell脚本，但是每次执行都能完成任务.

如果你曾经在半夜处理过生产故障，那么你将选择shell脚本.

原因很简单。可靠性远比自动化程度更重要。换句话说，一个DevOps流程必须能够在每次运行时产生一致的结果.

使我们的过程可重复

  。

以我们的shell脚本为例。目前，我们的shell脚本依赖于安装在虚拟机上的Node.js.

如果没有在虚拟机上安装Node.js，会发生什么?一个错误的Node.js版本足以使我们的应用程序不能正常运行。当我们需要在虚拟机上安装多种语言运行时时，情况只会变得更糟.

一个简单的解决方案是将Node.js运行时与我们的源代码一起归档到zip文件中。然后可以将zip文件发送到虚拟机。这样，虚拟机就可以使用zip文件中的本地Node.js运行时来运行我们的应用程序.

幸运的是，有一种工具可以让我们的生活更轻松.

Docker和容器

  。

如果你对Docker不熟悉，可以将Docker看作是一种将你的制品(artifact)及其所依赖的操作系统以及Node.js，一起打包进容器镜像中的方法.

使用容器，我们可以在安装了Docker的虚拟机上部署任何应用程序.

使用Docker，我们的流程将如下所示:

容器不仅仅能做到这些，但这却是容器能如此流行的重要原因之一.

Docker对比容器

  。

让我澄清一下，Docker和容器并不是同一个东西.

Docker是一组实用工具，用于构建和运送容器镜像，以及使用容器运行时(如containerd)来运行容器.

考虑到最近发生的事件，许多人对Docker的未来感到担忧.

重要的是要明白，Docker不会立马消失，在构建和运送容器镜像领域，将继续发挥重要作用.

认真对待DevOps 。

我们已经取得了一些重大进展。希望我们能理解Docker是如何融入DevOps流程中的.

是时候把事情推向下一个层次了.

基于事件的触发部署 。

我们的脚本看起来很稳定，但仍然是手动触发的.

如果我们能，当有人往GitHub上推送代码时自动触发这个脚本，那不是更好吗?换句话说，我们希望基于事件的触发部署.

GitHub可以在一组特定的事件上调用webhook。为了实现这一点，我们需要创建一个简单的HTTP服务器，每当服务器接收到请求时，它就会执行shell脚本。我们可以将GitHub配置为，当发生Push事件时，触发HTTP请求。我们将这个过程称之为持续部署(Continuous Deployment).

我们的新流程如下所示:

恭喜你，你刚刚成功创建了一个CD pipeline.

持续部署是一种软件，负责将应用程序从GitHub之类的东西一直带到最终部署的目标环境中.

这基本上就是你经常听到的CI/CD。当人们谈论像Jenkins和CircleCI这样的工具时，他们通常指的是CI/CD.

DevOps模式

  。

我想你已经找到了一个模式。我们从一个流程开始，找到一个我们不满意的部分，然后引入一些软件来简化或自动化它.

用代码的方式来操作流程，这就是DevOps.

引入容器编排 。

最后让我们做一个小小的改进。到目前为止，我们一直将应用程序部署在单个虚拟机上。如果我们想将应用程序部署到多个虚拟机或者节点上呢？

实现这一点的最简单方法是让CD Server通过ssh连接到所有虚拟机，并将容器部署到每个虚拟机中.

使用这种方式时，每当虚拟机的数量发生变化时，我们就需要更改脚本。但在真实世界中，我们希望我们的应用程序是可以自动扩缩容的.

更好的方法是创建另一个HTTP服务器来跟踪虚拟机数量的变化。我们可以称这个服务器为“飞行员(Pilot)”.

此服务器将负责对集群中的各个虚拟机执行健康检查，以维护活动的虚拟机列表。它甚至可以与云供应商进行通信，使事情变得更加健壮.

Pilot还将公开一个HTTP端点，以接受要生成的容器的详细信息。然后，它可以与各个虚拟机通信以完成任务.

现在，我们的CD Server可以简单地请求Pilot，而不是单独与每个虚拟机通信.

我们的新流程如下所示:

我们将Pilot称为容器编排器。其实这就是Kubernetes!你刚刚设计了一个迷你版的Kubernetes.

另外，Kubernetes在希腊语中就是Pilot的意思。这是不是巧合？

从哪里开始?

  。

我们一起讨论了不少工具。这是我的最后一点。有没有想过为什么DevOps的空间如此分散？

如果你仔细想想，有这么多的工具，让你很难决定：什么是正确的选择，或者你应该从哪里开始？

每个组织都有自己的做事方式和流程，因而他们使用的工具也不同。你的工作不是找出哪种工具是最好的。你的工作就是找出最适合你的流程。一旦你明白了这一点，这些工具就只需要谷歌搜索了.

所以现在你知道从哪里开始了。不是工具。而是从了解你的公司和团队如何做事开始.

原文地址：http://dockone.io/article/2434083 。

最后此篇关于什么是DevOps？一份简单易懂的教程的文章就讲到这里了,如果你想了解更多关于什么是DevOps？一份简单易懂的教程的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。