基础设施即代码:初识

我们公司正在加入SRE团队。 我从开发方面来介绍整个故事。 在此过程中,我想与其他开发人员分享思想和见解。 在这篇冥想文章中,我讨论了会发生什么,如何发生以及其他人如何生活。



根据我们在内部DevForum活动上的演讲,继续撰写的一系列文章

1.不带盒子的薛定inger猫:分布式系统中的共识问题。
2.基础架构即代码。 (你在这里)
3.为c#模型生成Typescript合同。 (进行中...)
4. 服务器之间如何达成共识:Raft分布式共识算法。
5. 基础架构即代码:如何克服XP问题。
...

我们决定让SRE团队实施google sre创意。 我们从自己的开发人员中招募了程序员,并派他们学习了几个月。

团队面临以下培训任务:

  • 描述我们的基础结构,该结构主要以代码形式(Terraform及其周围的所有内容)存在于Microsoft Azure中。
  • 教开发人员如何使用基础架构。
  • 为开发商做好准备。

介绍基础设施即代码的概念


在世界的通常模型(古典管理)中,有关基础结构的知识位于两个地方:

  1. 或以专家心目中的知识形式。
  2. 或者这些信息是关于某些打字机的,其中一些是专家所知道的。 但这不是事实,外界的人(以防我们整个团队突然死亡)将能够弄清楚什么有效以及如何有效。 机器上可能有很多信息:存取器,冠状插头,驱动器(请参阅磁盘安装 ),以及可能发生的情况的无穷无尽列表。 很难理解现实情况。

在这两种情况下,我们都被困住,变得依赖:

  • 或来自凡人,容易生病,坠入爱河,情绪波动甚至只是平庸解雇的人;
  • 或从同样会掉落,偷窃,带来意外和不便的物理工作机器上。

毋庸置疑,理想情况下,所有内容都应翻译为易于理解,受支持的高质量书面代码。

因此,作为代码的基础架构(Inafastructure as Code-IaC)以代码的形式描述了整个可用基础架构,以及用于使用该基础架构并从中实现实际基础架构的相关工具。

为什么将所有内容都转换为代码
人不是汽车。 他们无法记住一切。 人与机器的反应是不同的。 自动化的一切可能比一个人的工作更快。 最重要的是真理的单一来源。

新的SRE工程师来自哪里?
因此,我们决定联系新的SRE工程师,但是从哪里得到他们呢? 正确答案的书( Google SRE Book )告诉我们:来自开发人员。 毕竟,它们可以与代码一起使用,并且您可以达到理想的状态。

我们在公司外部的人员市场上搜索了很多很长时间。 但是我们不得不承认,我们没有根据要求找到一个。 我必须自己穿。

基础架构即代码问题


现在,让我们看一下如何将基础架构连接到代码中的示例。 该代码写的很好,质量高,带有注释和缩进。

Terraforma的示例代码。



来自Ansible的示例代码。



先生们,但是如果一切都这么简单! 在现实世界中,我们与您同在,他时刻准备为您带来惊喜,提出惊喜和问题。 这里不是没有他们。

第一个问题是,在大多数情况下,IaC是某种dsl。

而DSL则是对该结构的描述。 更确切地说,您应该拥有什么:Json,Yaml,一些大公司的修改,这些修改都带有他们自己的dsl(在地形中使用HCL)。

问题在于,其中可能不存在我们熟悉的事物:

  • 变数
  • 条件;
  • 在没有评论的地方,例如在Json中,默认情况下不提供评论;
  • 功能
  • 我不是在谈论诸如类,继承之类的高级事情。

2.此代码的第二个问题通常是异构环境 。 通常您会坐在C#上工作,即 一种语言,一种堆栈,一种生态系统。 在这里,您拥有各种各样的技术。

当使用python的bash启动Json滑倒的某个进程时,这是非常现实的情况。 您分析它,然后另一个生成器生成另外30个文件。 为此,来自Azure Key Vault的输入变量被输入,并由Go语言编写的drone.io插件将其汇集在一起​​,并且这些变量通过yaml传递,而yaml是从jsonnet模板引擎生成的结果。 当您拥有如此多样化的环境时,很难拥有严格描述的代码。

在一项任务框架内的传统发展只有一种语言。 在这里,我们使用多种语言。

3.第三个问题是图灵 。 我们习惯于为我们做一切的酷炫编辑(Ms Visual Studio,Jetbrains Rider)。 即使我们无聊,他们也会说我们错了。 这似乎是正常和自然的。

但是附近有一个VSCode,其中有一些以某种方式安装,支持或不支持的插件。 已发布新版本,但不支持它们。 平常过渡到功能的实现(即使它存在)成为一个复杂而又不容易的问题。 一个简单的变量重命名就是在十几个文件的项目中重播。 幸运的是它需要修复。 当然,有些地方有背光,有自动编译功能,有格式化的地方(尽管我不是在Windows平台上启动的)。

在撰写本文时, vscode-terraform插件尚未发布以支持版本0.12,尽管它已经发布了3个月。

现在该忘记...


  1. 侦错
  2. 重构工具。
  3. 自动完成。
  4. 检测编译错误。

这很有趣,但是它也增加了开发时间并增加了不可避免发生的错误数量。

最糟糕的是,我们被迫不考虑如何设计,将文件分解为文件夹,分解,使代码受支持,可读等,而是考虑如何正确编写此命令,因为我不正确地编写了该命令。

作为一个初学者,您正在尝试学习terraform,而IDE对此完全没有帮助。 当有文档时-他们进去了,看着。 但是,如果您要输入一种新的编程语言,那么IDE会建议您使用这种类型,但没有。 至少在int或string级别。 这通常是有用的。

但是测试呢?


您问:“测试,先生们程序员呢?” 认真的人正在测试产品上的所有内容,这很难。 这是Microsoft网站上terraform模块的单元测试的示例。



他们有很好的文档。 我一直很喜欢Microsoft的文档和培训方法。 但是您不必成为Bob叔叔就可以了解这不是理想的代码。 请注意右侧显示的验证。

单元测试的问题在于您和我可以验证Json输出的正确性。 我抛出了5个参数,为我提供了2000行的Json鞋垫。 我可以分析这里发生的情况,验证测试结果...

在Go中很难解析Json。 而且您需要用Go编写,因为Go上的地形是您使用所编写的语言进行测试的一种很好的做法。 代码的组织非常薄弱。 同时,它是最好的测试库。

Microsoft自己编写其模块,并以此方式对其进行测试。 当然,这是开源的。 我所讲的关于您的一切都可以来修理。 我可以坐下来一周内修复所有问题,打开VS代码插件,terraforms,制作骑士插件。 也许编写一些分析仪,螺丝短绒,复制库进行测试。 我什么都可以做 但是我不必这样做。

最佳实践基础架构作为代码


我们走得更远。 如果没有在IaC中进行测试,并且IDE和调优都不好,那么至少应该有最佳实践。 我刚刚去Google Analytics(分析)并比较了两个搜索查询:Terraform最佳实践和c#最佳实践。



我们看到了什么? 无情的统计数字对我们不利。 通过材料的数量-同一件事。 在C#开发中,我们只是浸入材料,我们拥有超一流的实践,有专家撰写的书,以及批评这些书的其他专家在书上的书。 官方文档,文章,培训课程之海,现在也开源开发。

至于IaC请求:在这里,您会一点一点地尝试从highload或HashiConf的报告,官方文档以及github上的许多问题中收集信息。 您如何传播这些模块,如何使用它们? 看来这是一个真正的问题……有一个社区,先生们,对于任何问题,您都会在github上收到10条评论。 但这是不准确的。

不幸的是,此时此刻,专家才刚刚出现。 虽然它们太少了。 社区本身也处于原住民的水平。

这一切都去哪儿了,该怎么办


您可以放下所有内容,然后回到C#,进入骑手的世界。 但是没有 如果找不到解决方案,为什么还要这么做呢? 接下来,我给出我的主观结论。 您可以在评论中与我争论,这将很有趣。

我个人做了一些事情:

  1. 这方面的发展非常快。 我给出了DevOps的请求时间表。



    也许这个话题是炒作,但是这个领域正在增长的事实给了我们一些希望。

    如果某件事发展得如此之快,那么聪明的人肯定会出现,他们会说如何做,如何不做。 受欢迎程度的提高导致这样的事实,即也许有人将有时间最终为vscode添加jsonnet插件,这将使我们能够继续执行该功能,而不是通过ctrl + shift + f查找它。 当一切发展起来时,就会出现更多的材料。 关于SRE的同一本Google书就是一个很好的例子。
  2. 我们可以在此处成功应用常规开发中已开发的技术和实践。 是的,测试存在细微差别,环境异构,调整不足,但是已经积累了大量实践,可以为您提供帮助。

    一个简单的例子:通过结对编程进行协作。 弄清楚它很有帮助。 当您附近有一个邻居也在尝试了解某些​​东西时,您在一起会更好地理解。

    即使在这种情况下,了解重构的完成方式也有助于实现重构。 也就是说,您不能一次更改所有内容,但可以更改命名,然后更改位置,然后可以突出显示某些部分,哦,但是注释不足。

结论


尽管我的推理似乎很悲观,但我仍对未来充满期待,并衷心希望我们(和您)能够成功。
接下来是文章第二部分 。 在其中,我谈论了我们如何使用极限编程实践来改善学习过程并与基础架构一起使用。

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


All Articles