Iac发展历史

IaC 简介

过去的 IaC：面向配置工具管理在公有云普及之前。

基础架构部门先采购 300 台服务器，数据中心工程师负责将机器推上机架，加电开机。网络组同学会为这批新机器分配 Vlan、Subnet 等资源。

系统运维同学根据需求分配机器，然后安装操作系统，运行配置管理工具，完成后，再交付给负责应用发布的同学。负责应用发布的同学发布应用，最终完成整个业务上线。

其中第三步是最耗费时间的，系统运维的同学不仅要安装操作系统，还要对这个 300 台的服务器做配置管理。这 300 台服务器的用途不同，所以系统配置肯定也不相同，这时就需要借助配置管理工具来帮忙。

那这个配置管理工具背后是怎么运行的？它是如何保证 300 台机器能被正确管理的呢？

就拿我们比较熟悉的工具——Puppet 举例，这是一个 Client-Server 模型的配置管理工具。

它的原理是这样的：每台机器上的 Puppet agent 每 30 分钟去 Puppet master 上拉取一次本机对应的配置，然后与本机上的配置做比对，发现不一致就会更改成 Puppet Master 里存储的配置。

为了方便团队协作，一般运维团队会将 Puppet 的配置文件放在公司内的 git 上，通过一些代码控制流程来管理代码的变更历史，这就是我们常说的 Infrastructure as Code，简称 IaC。

基于配置管理的 IaC 方式，尽管具体选哪种工具可能有所不同，比如我们还可以选择 Saltstack 或者是 Ansible 工具，但是思路和流程大体应该差不多。这种管理方式相比自己写脚本的传统管理方式，具有三个重要的标准。

快速：一旦节点的角色定义好了之后，Puppet agent 会自动拉取配置完成配置变更。

可靠：通过工具自动定期对比配置，防止有人手动做了更改，确保实际配置与定义配置保持一致。

可重复：无论是配置数据库服务器，还是设置冗余服务器，运维只需要定义好服务器角色，设置一次应用配置，Puppet 就能搞定所有的配置工作，省去了手工重复配置数百台机器的烦恼。

我们稍微总结一下什么是 IaC。

IaC 是一种自动化基础设施管理的方法，通过代码描述和配置基础设施资源，实现快速、可靠和可重复的部署和管理过程。

现在的 IaC：面向 API 与资源管理。

AWS 为了帮助用户简化工作，快速复制基础设施，推出了 CloudFormation 这个功能。

CloudFormation 使用结构化的文本，通过模板方式组合来创建一组资源。这些资源能一起合作，共同创建一个应用程序或解决方案。这种方式叫做声明式方法。

声明式方法定义了系统的预期状态，包括所需的资源以及它们应具有的属性，声明式方法的 IaC 工具执行时可能会中断或出错，但是这类工具可以不断重试，直到最终的实际状态与预期状态一致。

Terraform 这种多云基础设施编排工具和 CloudFormation 一样，Terraform 也是声明式方法，但是它没有使用结构化文本，而是 Terraform 自己的语法，这里我贴一个小样例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

module "ec2_instance" {
  source  = "terraform-aws-modules/ec2-instance/aws"

  name = "single-instance"

  instance_type          = "t2.micro"
  key_name               = "user1"
  monitoring             = true
  vpc_security_group_ids = ["sg-12345678"]
  subnet_id              = "subnet-eddcdzz4"

  tags = {
    Terraform   = "true"
    Environment = "dev"
  }
}

这个例子中导入了 terraform-aws-modules，因此能够支持 Google Cloud，Azure Cloud 等其他云的模块。

未来的 IaC：面向应用管理。

早期 IaC 是为系统管理员服务，通过 Puppet 这样的工具帮助系统管理员自动化配置 server；

现在的 IaC 是面向资源，通过 Terraform 这样的工具将计算网络存储的管理整合在一起。

这两种管理方式的共性是，先由应用申请资源，再由我们为应用准备资源。