运维从零认识IaC

需求

随着云计算的发展，基础架构组件的数量也在不断增加，每天都有更多的应用发布到生产环境中，而且基础架构本身也要被不断地使用、扩展和移除。

面对不同需求的基础架构变更，如何快速的响应及交付是运维需要思考的问题！

解决方案

基础架构即代码（IaC）是通过代码（而非手动流程）来管理和置备基础架构的方法。利用 IaC，我们可以创建包含基础架构规范的配置文件，从而便于编辑和分发配置。此外，它还可确保每次置备的环境都完全相同。通过对配置规范进行整理和记录，IaC 有助于实现配置管理，并避免发生未记录的临时配置更改。

如果没有相应的 IaC 实践，那么管理现今这样大规模的基础架构会变得越来越困难。IaC 可以帮助我们管理 IT 基础架构需求，同时提高一致性并减少错误和手动配置。

优势：

• 降低成本
• 加快部署速度
• 减少错误
• 提高基础架构一致性
• 消除配置偏移

服务器自动化和配置管理工具通常可以用来实现 IaC。当然，也有一些专门针对 IaC 的解决方案。 一些常见的方案如下：

• Chef
• Puppet
• Ansible
• Saltstack
• Terraform
• AWS CloudFormation

IaC模块化

为了更好的基于IaC部署，我们可以将基础架构划分为若干模块化组件，通过自动化以不同的方式进行组合来实现我们的需求。
结合CI/CD可以有效减少错误、手动部署及不一致的情况，进而保证各个环境配置一致性，为整个运维团队更好的赋能。

IaC与GitOps

IaC不是孤立存在的，其中版本控制是 IaC 的一个重要组成部分，就像其他任何软件源代码文件一样，配置变更也应该在源代码控制之下。结合版本控制，我们可以确保配置变更可靠执行，部署一旦出错也可以进行快速回滚，有效的降低了配置管理的难度。因此我们可以将IaC与GitOps理念更好的结合。

GitOps 的核心理念：将应用的所有环境配置都通过源代码控制系统 Git 进行管理，并通过自动化的流程进行交付和变更。

1. 从应用定义到基础设施环境，所有的配置都以源代码的方式保存在 Git 中。
2. 所有变更、审批记录也记录在 Git 的历史状态中。
3. Git 成为 “sourceof truth”，我们可以追溯变更历史、可以回滚到指定版本。
   

云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

• 基础架构即代码（Infrastructure-as-Code，IaC）则是一种典型的声明式 API。
• Docker 和 Kubernetes 容器技术是实现 Immutable Infrastructure 模式的最佳实践。

GitOps 与声明式 API、不可变基础设施相结合，保障了应用环境的可复现性，提升了交付与管理效率。

总结

虽然IaC的应用范围很广，但我们不要别它宏大的管理理念所吓退。“对的那条路，往往是最好走的”，首先我们要有一个清醒的思路：

1. 将基础架构分而治之，分解成不同的功能模块；
2. 选择合适的配置管理工具作为统一的配置管理中心，能够对不同模块进行编排；
3. 结合版本控制工具，实现对配置文件的代码托管；
4. 结合CI/CD工具，对不同场景进行自动化实现；

经过我们逐步的“庖丁解牛”，相信我们对IaC的认识会更加深刻，为以后更好的融入云原生运维体系做好准备。

1.什么是基础架构即代码（IaC）？
https://www.redhat.com/zh/topics/automation/what-is-infrastructure-as-code-iac
2.云原生时代的运维体系进化
https://developer.aliyun.com/article/841569