运用GitOps来启动环境,可为开发团队带来一致性、版本控制、速度等多方面的好处。
译自 How We Evolved from IaC to Environments as Code,作者 Edan Evantal 是 Quali 的CTO Edan Evantal负责Quali基础设施自动化和环境交付平台的所有产品工程。在加入Quali之前,Edan曾在Matrix IT和Sibam Ltd担任工程管理职务。他在高科技行业拥有18年以上的经验......
这些年来,在构建我们的平台的过程中,并与我们的产品所支持的其他DevOps和平台工程师一起工作,我亲眼见证了应用基础架构的演变正在打破它本来意在提供的自动化。
基础设施即代码(IaC)工具对于定义和自动交付云服务非常宝贵。当一个开发团队的需求扩展到此范围之外时,自动化通常就会中断。
原因有两个:
开发人员在基础设施自动化功能与应用需求实际情况之间存在鸿沟。其结果是速度降低,基础设施存在未管理或配置错误的风险增加。
我们询问自己,我们能做些什么来弥合这一鸿沟,这让我们想到了一个简单的问题:
如果您可以以代码的形式启动所有环境,而不管基础设施的范围或用于定义它的 IaC 工具是什么,会怎么样?
为了将环境定义为代码,我们首先需要以开发人员启动环境所需的一切来定义,这种格式对于DevOps来说既易于理解,又方便自动化机器读取。
使用我们的Torque平台,我们连接到一个Git仓库,发现其中定义的IaC模块,并将资源配置打包成一个新的由平台自动生成的YAML。
从那里,我们可以修改任何YAML代码,以包含环境启动时将生成的基础架构组件、参数、依赖项、元数据、身份验证和输出。
下面是YAML代码片段示例:
kind: environment
environment_name: "Workstation Staging A"
description: "EC2 workstation for staging workloads"
state: inactive
owner_email: "myemail@email.com"
blueprint:
name: "test-workstation"
repository_name: "cloud-native-application"
branch: "main"
commit: "536955389cd4ecbd1b8895c4a1093fe14a809b65"
inputs:
service-account: "sa"
agent: "review3"
grains:
create-ec2:
source:
commit: "697d1"
specs:
instance_type: "t2.large"
ami: "ami-0c55b159ertafe1f0"
security_groups: ["sg-0246e9ddc2b2f23f4"]
post-deployment:
scripts: ["./configure-environment.sh", "./deploy-application.sh"]
这包含了环境所有必要元数据的单一定义,以结构化格式呈现。
简单来说,我们利用现有的基础设施代码来定义环境为代码。
为了满足客户的需求,我们需要使这一定义具有操作性。
我们的初始答案是依赖我们的自助门户。当我们平台中的管理员创建这些YAML文件(我们称之为环境的“蓝图”)时,他们可以选择“发布”它。这会将环境添加到平台中的一个自助服务目录中,拥有最终用户权限的用户可以按需启动该环境。对于那些将环境集成到开发者工具、CI/CD或内部开发者门户的人来说,发布新蓝图也可以通过这些工具访问。
为了支持采用GitOps的团队,我们需要将已发布的蓝图集成到日常工作流程中。
通过在我们发现IaC模块的原始仓库中存储这个新的YAML文件,我们使环境定义在GitOps中可访问。实际上,我们为能够访问该仓库的用户“发布”了环境定义。
现在,开发人员可以使用单个命令启动完整的环境。
这种方法还提供了几个额外的优势:
在平台工程中,每一秒都是宝贵的,每一个资源都很重要。随着基础设施变得越来越复杂,以代码的形式管理环境是现代DevOps组织成熟的下一步。