IaC

IaC 是什么

IaC（Infrastructure as Code），即基础设施即代码。参考维基百科的定义，IaC 中的 Infrastructure 广义上指 IaaS 层的基础设施，包括物理服务器、虚拟机以及相关的资源定义等。As Code 指这些配置都应被放在 VCS 上进行管理。

在服务上云的大趋势下，基础设施的概念已不再局限于 IaaS 层。云原生时代，开发者的焦点逐渐聚集到了应用上，即以应用为中心。持续集成、持续部署和 DevOps 概念的广泛推行和接受，要求产品团队对部署和运维具备更高的自主性。一个开发工程师若仅是把代码写好，是远远不够的，充其量完成了 Dev。而真正的软件交付生命周期，从 Ops 开始，运维工程师已不再负责应用的部署和运维，这些都是开发者的份内之事。

Docker 的出现使得镜像交付成为大多数应用软件事实上的交付标准。因此，应用需要一个文件来定义如何将代码制作成镜像，这个文件通常是 Dockerfile。

与此同时，PaaS 平台的普及，使得开发者甚至无需关心 Dockerfile。因为 PaaS 平台可通过应用目录结构和特征文件，自动探测和选择合适的构建方式，这个代码编译和镜像构建的过程被称为 BuildPack。当然，在编译之前，您可能还需做一些代码质量检查、合规性检查等工作，这些流程化的配置需有一个流程描述文件来声明。在不同的 PaaS 平台上，会有不同的声明方式。

Erda 如何实现 IaC

Erda 是以应用为中心的企业级一站式数字化 PaaS 平台，DOP（即 DevOps Platform）是以应用为中心的一站式 DevOps 平台。

在此，您可以通过 pipeline.yml 定义应用的 CI/CD 全流程，而 pipeline.yml 即该应用基础设施的一部分。同时，您需要以一个声明式的 dice.yml 描述应用微服务架构，包括微服务之间的依赖关系、对中间件的依赖等。

平台在设计之初已对应用做了抽象，使其可以被部署在任意平台（包括 K8s、DC/OS 等），并对开发者屏蔽了具体实现细节。因此，当应用部署在 Erda PaaS 平台上时，这两个文件是必不可少的。

除此之外，平台支持在 .erda 目录下定义 API 描述文件，实现对 API 的全生命周期管理。

当这些 Infrastructure 都被作为 Code 提交之后，Erda 平台便可根据这些配置，进行持续集成和持续交付，最终自动把应用完整部署起来。

dice.yml 部分内容示意如下：

用于 CI 的 pipeline.yml 部分内容示意如下：

若您的应用是一个标品，IaC 可简单化该应用的交付。您只需将代码仓库完整地推送至新应用代码仓库中，随后执行流水线，如此一个完整的应用便已交付至新的客户环境中。后续开发者可在新应用中进行定制化开发，当应用的基础设施变更时，将变更提交代码进行版本控制管理。