CloudIaC正式开源！推动环境即服务在企业落地

作为一名运维，管理IT基础设施是一项艰巨的体力劳动，从最原始的用Excel记录维护配置信息，到开发CMDB系统来进行资源的配置管理，从传统上，运维的任务就是管理和配置所有的软件和硬件，这些配置信息对于保证基础架构中的应用程序平稳运行至关重要，但这始终是一个漫长的过程。

IT基础设施管理的痛点

长期以来，我们将服务器部署到机房，对机器进行软、硬件配置，安装并初始化操作系统，在做好基础配置后提供给业务部门；业务部门拿到机器后进行应用的部署，在这整个手动过程中通常会导致很多问题。

成本问题

从网络工程师到硬件维护人员，在流程的每一步必须有相应的专业人员来执行必要的任务，作为企业而言，聘请专业人员的报酬以及管理成本都是必不可少的，同时人员增多还会增加组织内部沟通的复杂性，钱花了也未必能构建和维护好自己的数据中心。

扩展性和可用性

由于手动配置太慢，当我们的应用遇到访问高峰，运维人员需要配置更多服务器来增加负载，这必然会影响可用性，如果没有提前准备好备份的服务器甚至数据中心，可能导致应用长时间不可用。

监控和性能可见性

应用上线后，如何确保我们的基础架构正以最佳方式运行？当遇到问题时，又如何准确定位问题来自基础设施的哪个位置？我们的应用的整体拓扑映射、事件关联和根本原因分析，这些都需要我们去维护相应的业务关系，通过配置管理来完成。

不一致性

如果有多个运维人员都在负责手动部署配置，基础设施以及环境的不一致性将成为不可避免的问题。

IaC（Infrastructure as code 基础设施即代码）

随着云计算的到来，在很大程度上帮我们解决了上述的部分问题，通过云计算，我们甚至无需构建和维护自己的数据中心即可让我们的应用运行起来。

不过，云计算并不能解决所有问题。虽然它能够让我们快速设置基础设施需求，从而解决高可用性和可扩展性等严重问题，但它对解决不一致问题没有任何帮助。当多个人员都在执行配置或变更时，差异必然存在。

而IaC（基础设施即代码）正好能够弥补上面问题的缺失部分。

IaC是什么

IaC（Infrastructure as code 基础设施即代码）是通过使用配置文件来管理所有的基础设施并自动化基础架构管理。

使用基础设施即代码，我们的基础设施配置会采用代码文件的形式。由于它只是文本，因此可以轻松编辑、复制和分发它。我们可以使用VCS（版本控制系统）来管理配置文件，就像管理任何其他源代码文件一样。

IaC的优点

那么IaC能给我们带来什么样的好处呢？我简单罗列了一下：

1. 易于复制
2. 易于查看
3. 易于销毁
4. 易于分享
5. 易于移植
6. 易于找到
7. 易于审核
8. 易于回滚
9. 易于重构

如果你使用过云平台的console来进行资源的管理，那你一定能够体会到实现以上操作的繁琐和复杂程度，如果只是创建一次，后续就不用再管理操作的话还好，但往往我们需要不断重复的创建、管理类似的基础设施，当然我们可以通过调用云平台的SDK或API来实现自动化操作，但这一方面增加了我们的开发成本，另一方面在跨云平台使用时我们需要对不同的云平台进行适配。

而使用IaC，则完全解决了我们上面遇到的问题，在方便管理基础设施的同时，也实现了环境一致性的管理。

通过VCS管理资源配置

使用IaC管理环境资源的一大好处是我们可以通过VCS（版本控制系统）像管理普通代码文件一样来管理资源配置文件，这样我们在多人参与管理时对资源配置文件的修改可以直接通过分支或Tag来进行管理，清晰记录下所有的变更。

IaC工作原理

基础设施即代码工具的工作方式各不相同，通常可以分为两种主要类型：遵循『命令式资源配置方法』的工具以及遵循『声明式资源配置方法』的工具。

“命令式”和“声明式”这两个概念最初来自于编程语言，其中，命令式资源配置方法指的是资源使用者没有正式编码所需的状态，并且由资源使用者来决定命令序列。最值得注意的是，命令式方法是不可重复的，当重复执行时可能会产生与预期不一致的结果。

而声明式资源配置方法指的是编写一个配置文件，描述想要的部署结果，然后由平台解析这个配置文件并自动生成部署结果。声明式方法是可重复的（幂等性），因此可以实现自动化，重复执行时如果状态没有变更则不会产生任何修改动作。

Terraform

目前，市场上存在很多基础设施即代码的自动化部署及编排工具，其中Terraform可以说已经是IaC事实上的标准，各大公有云平台都为其提供Provider，方便用户以IaC的方式来管理云平台资源。

Terraform 是一个安全、高效地部署、更改、版本化基础设施和应用程序的工具，可以用来管理多层次的资源，从上层的软件配置到底层的网络、系统配置都可以使用 Terraform 统一进行管理。

Terraform 用配置文件来描述一个应用，在将配置文件与当前环境对比后，生成一个执行计划，这个计划会列出为了达到配置文件中定义的状态所需要执行的操作，然后执行计划以达到期望的状态。

Terraform 通过插件机制管理不同的资源提供者（Provider），以此来接入各种资源，如虚拟机，存储，网络和各种应用服务。

Terraform通过HCL语言来对资源进行声明式描述，如下是一个资源声明的示例：

data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
  }
  owners = ["099720109477"]
}

resource "aws_instance" "this" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "t3.small"
  key_name               = "ansible"
  subnet_id              = aws_subnet.subnet.id
  vpc_security_group_ids = [aws_security_group.sg.id]
  tags = {
    Name = "ansible-${random_id.hash.hex}"
  }
}

执行计划

当资源配置文件中声明好资源后，Terraform可以通过执行teffaform plan指令来生成一份执行计划，该执行计划中可以预览这份配置文件执行后会产生的资源变更，用户可以根据该计划判断结果是否符合预期。

执行变更

通过执行计划预览结果符合我们的预期后，如果想要真正的执行变更动作，可以通过terraform apply指令来执行变更，如果执行过程中发生错误导致失败，在配置正确的情况下可以重复执行该指令，以达到预期的资源状态。

Terraform状态

当我们执行terraform applay后，资源成功创建，Terraform会保存一份资源的状态文件，通过该状态文件，后续我们对配置文件做了修改，重新执行terraform plan/apply指令时，Terraform会比较新的配置与状态文件的差别，基于修改的部分去执行变更，变更后同样会将状态保存至状态文件。

资源销毁

在应用上云后，尤其在公有云环境下，在快速实现弹性伸缩的同时也能够提高我们对资源的利用率，从而实现对成本的控制，通过Terraform创建的环境，因为资源的状态都保存在状态文件里，在该环境再使用的时候我们可以通过terraform destroy指令方便的实现一键销毁。

Terraform工作区

通过Terraform我们实现了对代码定义的资源快速部署、更新以及销毁的生命周期管理，在需要创建及管理多个不同环境时，我们可以通过建立不同的目录来进行管理，但缺点是需要把资源配置文件复制到不同的目录，当修改资源配置文件时需要同时修改不同目录下的配置文件。

那有没有方法可以让我们使用一份资源配置文件实现多个环境状态的管理呢？答案是肯定的，Terraform提供了工作区（workspace）的概念，通过workspace，我们可以在同一个目录使用同一份资源配置文件实现多个不同环境的管理。

terraform workspace 指令可以用来管理当前的工作区，这个指令包含一系列子命令：
terraform workspace new 命令用来创建新的工作区；
terraform workspace show 命令用来打印出当前使用的工作区；
terraform workspace list  命令会打印出存在的工作区，当前工作区使用*号标记；
terraform workspace select 命令用来选择使用的工作区；
terraform workspace delete 命令用来删除已经存在的工作区。

CloudIaC

虽然Terraform提供了workspace让我们能够管理不同的环境，但当有多个人员需要对环境进行管理时还是会存在资源配置文件分发、同步，状态统一管理等问题，并且时常会发生操作时忘了切换当前工作区，导致错误操作了目标环境的问题，CloudIaC可以帮助我们解决以上的管理问题。

CloudIaC是由云霁科技开发的一个开源项目，该项目提出了『环境即服务』的理念，可以通过组织、项目、云模板、环境等管理维度，精确的授权用户对环境的管理权限，让用户可以分配不同的角色对不同项目下的不同环境进行管理；同时，CloudIaC将Terraform和Ansible进行了打通，让我们可以在资源创建出来之后自动调用Ansible的playbook来完成应用的自动部署。

除了在公有云环境下帮助管理IaC环境，CloudIaC还为私有云、混合云环境下使用Terraform提供了解决方案，除了使用公有云平台提供的Provider之外，针对私有云、专有云、VMware、PaaS等服务，CloudIaC也针对相应场景提供Provider支持；为了让企业内部私有化部署且因为安全因素不能访问外网的场景，CloudIaC还提供了私有的Provider Registry，通过在企业内部部署Provider Registry，让私有化部署场景下也可以顺畅的使用IaC管理我们的环境。

CloudIaC官网：CloudIaC
CloudIaC开源地址：GitHub - idcos/CloudIaC: Cloud Infrastructure as Code
CloudIaC文档：Home - CloudIaC

下面，让我们通过一个示例来看一下CloudIaC是怎么帮助我们对环境进行管理的：

创建组织

CloudIaC提供组织、项目、环境等管理维度，根据用户所属组织及项目实现数据隔离，我们首先创建我们所在的组织：

创建云模板

在成功创建组织后，我们选择一个组织即可进入组织视图，进入组织视图后默认进入云模板页面，我们可以通过『新建云模板』来添加新的云模板，这里的云模板指的就是我们托管在VCS（版本控制系统）中的资源配置文件仓库

选择VCS（如果没有添加过VCS，则可以直接点击『新增VCS』进行添加，目前支持Gitlab、Github、Gitee、Gitea）、仓库、分支或Tag

设置该云模板需要的变量

最后是将我们创建的云模板关联到具体的项目上，如果当前没有创建项目，可以直接点击『创建项目』来创建一个新项目

添加变量

CloudIaC支持在组织、云模板、项目、环境四个层级设置变量，这些层级的变量会在实际部署环境时通过自动继承把高层级的变量带入下层。

变量类型主要有Terraform变量以及环境变量，Terraform变量是在执行部署传递给Terraform的变量（如果在VCS仓库中定义了variables.tf，CloudIaC还支持自动解析该文件中的变量，在设置Terraform变量时可以直接导入），环境变量通常是我们访问云平台的凭证信息。

部署环境

在顶部导航栏选择所属项目

进入『项目信息』-『环境』页面

点击『部署新环境』新选择相应云模板的『部署』来发起新环境部署

部署过程中可以通过『部署日志』来查看实时日志，部署完成后通过『资源』可以查看当前环境的资源详情，后续如果修改了资源配置，可以通过『重新部署』来发起变更操作，在环境不再使用后可以通过『销毁资源』来实现一键销毁

通过以上步骤，我们的环境就在CloudIaC平台上运行并管理了起来，我们可以通过给项目中的用户指定不同角色来控制权限，也可以在不同层级管理不同作用域的变量，而且可以通过联动Ansible来实现更多高级功能，大家如果感兴趣可以自行探索。

总体来说，CloudIaC提供了较完善的环境管理视角，通过RBAC来控制不同角色的权限，同时在部署过程中可以实现审批管理，在资源创建后动态部署应用，后续还会增加合规、自定义pipeline等功能，感兴趣的同学可以关注CloudIaC开源项目，欢迎大家提问题或建议，一起加入到CloudIaC的建设中来。

CloudIaC官网：CloudIaC

CloudIaC开源地址：GitHub - idcos/CloudIaC: Cloud Infrastructure as Code

CloudIaC文档：Home - CloudIaC