基础架构即代码,我们取得了成功(Kirill Vetchinkin,TYME)

基础架构即代码(IaC)模型(有时也称为“可编程基础架构”)是一种模型,基础架构配置过程类似于软件编程过程。 本质上,它标志着开始消除编写应用程序与为这些应用程序创建环境之间的界限的开始。 应用程序可以包含创建和管理自己的虚拟机的脚本。 这是云计算的基础,也是DevOps的组成部分。


使用基础结构作为代码,您可以在软件级别管理虚拟机。 这消除了对单个设备组件进行手动配置和更新的需要。 基础架构变得极为“具有弹性”,即可重现和可扩展。 一个操作员可以使用同一组代码部署和管理一台和1000台计算机。 作为代码,基础架构可保证的好处包括速度,成本效益和降低风险。


这正是Kirill Vetchinkin在2018年莫斯科DevOpsDays大会上的报告的解读内容:该报告:Ansible模块的重用,Git中的存储,审查,重建,财务收益,一键式水平缩放。



谁在乎,请在猫下。


大家好 如前所述,我是Vetchinkin Kirill。 我在TYME工作,今天我们将讨论基础架构作为代码。 我们还将讨论如何学会节省这种做法,因为这样做非常昂贵。 编写大量代码对于建立基础结构而言非常昂贵。


简要介绍一下公司。 我在TYME工作。 我们进行了品牌重塑。 现在我们称为PaySystem-顾名思义,我们从事支付系统。 我们拥有自己的解决方案-这些是处理和定制开发。 定制开发是电子银行业务,计费等。 如您所知,如果这是定制开发,那么每年这就是大量项目。 该项目紧随项目之后。 项目越多,就必须筹集更多相同类型的基础设施。 由于项目通常负担很重,因此我们使用微服务架构。 因此,在一个项目中有许多许多小的子项目。



因此,在没有完整的DevOps的情况下管理整个动物园非常困难。 因此,我们公司已实施了各种DevOps实践。 自然,我们使用看板,SCRUM,将所有内容存储在git中。 提交后,将进行持续集成,并运行测试。 测试人员在每晚开始的PyTest上编写端到端测试。 每次提交后开始进行单元测试。 我们使用单独的构建和部署过程:组装,然后多次部署到各种环境。 我们在窗户上。 在Windows上,我们使用Octopus deploy进行了部署。今年,我们在DotNet Core上进行开发。 因此,我们现在能够在Linux系统上运行软件。 我们离开了章鱼来到安西布尔。 今天我们将讨论这部分,这是我们今年开发的一种新做法,这是我们以前从未有过的。 当您进行测试时,当您知道如何很好地构建应用程序时,将其部署在某个位置就可以了。 但是,如果您有两个配置不同的环境,那么您仍然会陷入困境,并投入生产。 因此,管理配置是非常重要的做法。 那就是我们今天要谈论的。



我将简要介绍该产品如何构建劳动力经济: 60 %的资源用于开发10 %的数据分析 ,约20 %的质量保证 (测试),以及其他所有费用都分配给了配置。 当系统全面运行时,它们将具有许多第三方软件,而操作系统本身的配置方式几乎相同。 我们花费额外的时间来执行此操作,基本上是在做同样的事情。 有一个想法可以使一切自动化,并降低配置基础结构的成本。 类似的任务是自动的,经过良好调试的,并且不包含手动操作。



每个应用程序都在某种环境下工作。 让我们看看它的全部内容。 至少必须有一个操作系统 ,它需要进行配置,还有一些第三方应用程序也需要进行配置, 应用程序本身必须接受配置,但是要使整个产品正常工作,应用程序本身必须启动,并在整个系统中运行。 还有一个网络也需要配置,但是由于我们拥有不同的客户和不同的网络设备,因此今天不再讨论该网络。 我们还尝试自动执行网络配置,但是由于设备不同,因此没有特别的好处,因此我们在此上花费了更多资源。 但是,我们使操作系统,第三方应用程序以及配置参数到应用程序本身的传输自动化。



有两种方法可以配置服务器:用手-如果用手配置它们,则可能会出现这样的情况,即以一种方式配置产品,测试是不同的,测试是绿色的,测试是绿色的。 您部署到生产环境,那里没有框架-没有任何适合您的东西。 另一个示例:手动配置了三个应用程序服务器。 一台应用程序服务器以一种方式配置,另一台应用程序服务器以不同方式配置。 服务器可以以不同的方式工作。 另一个例子:有一种情况是一台Stage服务器完全停止为我们工作。 我们开始使用创建新服务器,并在30台服务器准备就绪之后。 另一个例子:服务器刚刚停止工作。 如果您用手设置它,则需要寻找一个知道如何配置它的人,您需要提出文档。 众所周知,文档几乎无关紧要。 这些是大问题。 而且,最重要的是,这是一次审核,也就是说,您有十位管理员,他们每个人都用自己的双手进行设置,不清楚他们设置正确还是不正确,以及如何理解是否正确然后设置,他们可以放一些多余的东西,打开一些不必要的端口。



有一个替代选项-这正是我们今天所谈论的-这是代码的配置。 也就是说,我们有一个git存储库,用于存储整个基础结构。 所有脚本都存储在此处,我们将借助它来配置它。 由于这一切都在git中,所以我们获得了代码管理的所有好处,就像在开发中一样,也就是说,我们可以进行审阅,审核,更改历史记录,谁做,为什么做,发表评论,我们可以回滚。 要使用代码,您需要使用连续的汇编管道-部署管道。 为了使某些系统可以更改服务器,也就是说,不是一个人用手做某事,而是由系统专门做。



作为进行更改的系统,我们使用Ansible。 由于我们没有大量的服务器,因此非常适合我们。 如果那里有100-200台服务器,那么您将遇到一些小问题,因为它(即Ansible)仍然可以连接到每台服务器并依次进行配置-这是一个问题。 最好使用其他不推但拉的方式。 但是从我们的历史来看,当我们有很多项目但服务器不超过20个时,这对我们来说是非常合适的。 Ansible具有很大的优势-进入门槛低。 也就是说,实际上任何IT专家都可以在三周内完全掌握它。 他有很多模块。 也就是说,您可以管理云,网络,文件,安装程序,部署-几乎所有内容。 如果没有模块,则可以编写自己的模块,最后可以使用Ansible shell或命令模块编写某些内容。



通常,我们将简要考虑此工具的外观。 Ansible具有我已经讨论过的模块。 也就是说,可以交付正在做某事的自己写的东西。 有清单-这是我们进行更改的地方,即,这些是主机,其IP地址,特定于这些主机的变量。 并据此扮演角色。 角色就是我们将在这些服务器上使用的角色。 而且我们的主机也分为几组,也就是说,在这种情况下,我们看到有两个组:数据库服务器和应用程序服务器。 在每个组中,我们有三辆车。 它们通过ssh连接。 因此,我们解决了前面提到的问题,首先,我们的服务器配置相同,因为相同的角色会出现在服务器上。 同样,如果我们在多台计算机上运行此角色,则每台计算机都将以相同的方式工作。



如果我们深入研究Ansible项目的结构,那么在这里我们可以看到主机可以接受生产库存。 已指示该组,并且其中有两个服务器。 如果转到特定服务器,则会看到此处显示了该计算机的IP地址。 其他参数也可能在此处指示-该环境特定的变量。 如果我们看看角色。 该角色包含将要执行的几个任务。 在这种情况下,这是安装PostgreSQL的角色。 也就是说,我们安装必要的应用程序,创建数据库。 在这里,我们使用一个循环。 他们(数据库)将被创建一些。 然后,我们建立必要的连接-可以登录该数据库的IP地址。 并且,因此,我们在防火墙的最后进行配置。 设置将应用于组中的所有服务器。



只需解决问题本身即可:我们学习了如何使用Ansible配置服务器,一切都很好。 但是,正如我所说,我们有很多项目。 他们几乎都是一样的。 其中的一些系统涉及每个项目(k8,RabbitMQ,Vault,ELK,PostgreSQL,HAProxy)。 我们为每个角色编写了一个角色。 我们可以从按钮上滚动它。



但是我们有很多项目,并且每个项目本质上都是重叠的。 也就是说,在一个这样的集合中,在第二个这样的集合中,在第三个这样的集合中。 我们得到在不同项目中具有相同角色的交点。



我们有一个带有应用程序的存储库,我们有一个带有项目基础结构的存储库。 第二个项目完全相同。 持续的基础设施。 第三。 如果我们实现相同的事情,那么复制粘贴实际上就会出现。 我们将在10个地方扮演相同的角色。 然后,如果有任何错误,我们将在10个地方统治。



我们做了什么:我们承担了所有项目的所有角色,以及所有从外部到单独存储库的配置所共有的角色,并将它们放在git的单独文件夹中-我们称为TYME Infrastructure。 在那里,我们为PostgreSQL和ELK负责部署Kubernetes集群。 如果我们需要放入某个项目,比如说同一个PostgreSQL,则只需将其作为子模块打开,重写清单即可,也就是说,大致来说,是将角色扮演角色的配置。 我们不重写角色本身:它已经存在。 只需单击一个按钮,PostgreSQL就会出现在所有新项目中。 如果您需要提升Kubernetes集群-同样的事情。



因此,事实证明减少了编写角色的成本。 也就是说,他们写了一次-使用了10次。 当项目进行到项目之后–非常方便。 但是,由于我们现在正在使用基础结构作为代码,因此我们自然需要我们讨论过的管道。 人们使用git提交,他们可能会犯某种错误-我们需要跟踪所有这些。 因此,我们已经建立了这样的管道。 也就是说,开发人员在git中提交Ansible脚本。 Teamity会跟踪它们并将其转移到Ansible。 这里仅出于一个原因需要Teamcity:首先,它具有可视界面(有Ansible Tower-AWX的免费版本,可以解决相同的问题-ed。),与Ansible不同,后者是免费的,并且从原则上讲,Teamcity是单个的慈 因此,原则上,Ansible具有一个可以跟踪git的模块。 但是在这种情况下,他们只是按照形象和相似性来做。 一旦他跟踪了它,它将把所有代码分别转移到Ansible和Ansible,在集成服务器上启动它们并更改配置。 如果违反了此过程,那么我们正在分析错误的原因,脚本编写得不好的原因。



第二点是有一个特定的基础结构,这里我们将基础结构分开部署,将应用程序分开部署。 但是每个应用程序都有一个特定的基础结构,即在我们启动它之前需要对其进行部署。 因此,此处不可能将其传输到其他管道。 您应该将其部署在与应用程序本身相同的容器中。 就是说,当您需要为新应用程序安装一个框架并为另一个应用程序放置另一个框架时,框架是很流行的事情。 这就是这种情况。 或者您需要清理缓存。 例如,Ansible还可以爬升,清理缓存。



但是这里我们将docker与Ansible结合使用。 也就是说,我们的特定基础架构位于docker中,而Ansible中则非特定。 因此,我们有点在Docker中共享了这个小增量,在Ansible中共享了其他所有基本信息。



非常重要的一点-如果您通过某种脚本,代码来滚动基础结构,那么如果您仍然可以手动进行服务器操作,则这是一个潜在的漏洞。 因为假设您将Java放在测试服务器上,编写了ELK角色,然后将其滚动。 在测试中部署成功。 在生产环境中部署,但是没有Java。 而且您没有在脚本中指定java-生产环境中的部署失败了。 因此,您需要从管理员那里夺走所有服务器的权限,以免他们用手抓取权限并通过git进行所有更改。 我们自己经过的所有输送机。 但有一件事-不要过多地拧紧螺母。 即,有必要逐步引入这样的过程。 因为它仍未裁剪。 在我们的案例中,如果发生不可预见的事件,我们将所有系统的访问权留在了主要管理员的头上。 授予访问权限的条件是它不会手动配置任何内容。



开发如何进行? 分阶段推出时,生产应无错误。 这里可能会破裂。 如果在集成环境中推出产品时经常出错,那将是很糟糕的。 这类似于在远程计算机上调试应用程序。 当开发人员首先在计算机上开发所有内容时,请对其进行编译。 如果一切都能编译,则将其发送到存储库。 它使用相同的方法。 开发人员将Visual Studio Code与Ansible,Vagrant,Docker等插件一起使用。 开发人员在本地流浪汉上测试其基础结构代码。 出现了一个干净的操作系统。 用于提升计算机的脚本本身也位于我们讨论过的基础结构中的存储库中。 开发人员开始在其上安装FTP服务器。 如果出现问题,他只是删除它,重新加载它,然后再次尝试使用部署脚本在其上安装必要的软件。 调试部署脚本后,它将对主分支发出合并请求。 合并合并请求后,配置项将这些更改回滚到集成服务器。



由于所有脚本都是代码,因此我们可以编写测试。 假设我们安装了PostgreSQL。 我们要检查它是否有效。 为此,请使用Ansible断言模块。 将已安装的PostgreSQL版本与脚本中的版本进行比较。 因此,我们了解它已安装,通常正在运行,并且正是我们期望的版本。



我们看到测试通过了。 因此我们的剧本正常工作。 您可以根据需要编写任意数量的测试。 它们是幂等的。 幂等 (一种操作,如果多次应用于任何值,则始终会产生与单个应用程序相同的值)。 如果编写用于安装和配置的免费脚本,则请确保多次运行它们始终获得相同的值。



还有另一种类型的测试与基础结构测试不直接相关。 但是它们似乎间接影响了他。 这些是端到端测试。 我们拥有基础架构,并且应用程序本身安装在测试人员测试的同一台服务器上。 如果我们推出了某种不正确的基础架构,那么我们只是复杂的测试将无法通过。 也就是说,我们的应用程序将在某种程度上无法正常工作。 在此示例中,我们在生产环境上安装了新版本-该应用程序正常运行。 然后,在晚上进行的git和端到端测试中进行了一次提交,结果是在这里我们在ftp上没有文件。 我们拆开这种情况,发现问题出在ftp设置中。 我们在代码中修复了脚本,再次部署,一切变成绿色。 与代码相同的故事。 基础结构代码和基础结构以一种或另一种方式间接测试。 然后,我们可以将其部署到生产中。



当我们引入这种方法时,对集成服务器进行更改的CI(Teamcity)在10中下降了8倍。没有人注意它,因为没有反馈。 对于开发人员来说,这些过程已经实施了很长时间,但是消息没有到达OPS(系统管理员)。 因此,我们在办公室中显眼处的大型监视器上添加了带有该项目的组件的仪表板。 在其上,各种项目以绿色突出显示-这意味着一切都与他井井有条。 如果用红色突出显示,则表示一切都对他不利。 我们看到某些测试失败。 在演示文稿的第二部分的左侧,从顶部开始,我们看到了部署部署的结果。 . , , , . : - . . Slack , - - - .



Ok, , , - , . trunk based . Master — . Master CI (Teamcity) integration . CI , integration . release candidate. . . , end-to-end , staging . production. , staging .



. ? , PostgreSQL. 5 . , . 1-2 . . , PostgreSQL . PostgreSQL , staging, production 4 . , , . , . - .



git submodule Ansible . , . git submodule Ansible . inventories , . 30 . git submodule .



: , . , , , staging , . , , , , , , staging. — , , - .



6 . — 10 . . . , . - git submodule, . . , , , . , , .



.


-, , : , Ansible git , : “ , - ”. ? git . , . 100% . . .


, . . , RabbitMQ, ELK, . , ELK . , , ELK. ELK, , ELK .


, , , , . , , , , . , . .


. , , , , , , . git. , — git, , : , - . .


, , , code review. , , . , . , , , , , . , : . . . , - - .


, .


: , git submodule, . - , latest . inventories. — , . , , .. . — . .


: - Ansible ( A B, B C A, )? , ?


: . . , - IP , , , , . . , , , , , . , - , , , RabbitMQ RabbitMQ, . - , .


PS:我建议每个对github感兴趣的人将会议中有趣的报告翻译成文本。您可以在github上建立一个小组进行翻译。到目前为止,我正在将其翻译为github帐户中的文本-您还可以发送一个Pull请求以更正那里的文章。

Source: https://habr.com/ru/post/zh-CN438748/


All Articles