运维从零认识IaC
需求
随着云计算的发展,基础架构组件的数量也在不断增加,每天都有更多的应用发布到生产环境中,而且基础架构本身也要被不断地使用、扩展和移除。
面对不同需求的基础架构变更,如何快速的响应及交付是运维需要思考的问题!
解决方案
基础架构即代码(IaC)是通过代码(而非手动流程)来管理和置备基础架构的方法。利用IaC,我们可以创建包含基础架构规范的配置文件,从而便于编辑和分发配置。此外,它还可确保每次置备的环境都完全相同。通过对配置规范进行整理和记录,IaC有助于实现配置管理,并避免发生未记录的临时配置更改。
如果没有相应的Ia 实践,那么管理现今这样大规模的基础架构会变得越来越困难。IaC可以帮助我们管理IT基础架构需求,同时提高一致性并减少错误和手动配置。
优势:
-
降低成本 -
加快部署速度 -
减少错误 -
提高基础架构一致性 -
消除配置偏移
服务器自动化和配置管理工具通常可以用来实现IaC。当然,也有一些专门针对IaC的解决方案。 一些常见的方案如下:
-
Chef -
Puppet -
Ansible -
Saltstack -
Terraform -
AWS CloudFormation
IaC模块化
为了更好的基于IaC部署,我们可以将基础架构划分为若干模块化组件,通过自动化以不同的方式进行组合来实现我们的需求。结合CI/CD可以有效减少错误、手动部署及不一致的情况,进而保证各个环境配置一致性,为整个运维团队更好的赋能。
IaC与GitOps
IaC不是孤立存在的,其中版本控制是IaC的一个重要组成部分,就像其他任何软件源代码文件一样,配置变更也应该在源代码控制之下。结合版本控制,我们可以确保配置变更可靠执行,部署一旦出错也可以进行快速回滚,有效降低了配置管理的难度。因此我们可以将IaC与GitOps理念更好结合。
GitOps的核心理念:将应用的所有环境配置都通过源代码控制系统Git进行管理,并通过自动化的流程进行交付和变更。
-
从应用定义到基础设施环境,所有的配置都以源代码的方式保存在Git中。 -
所有变更、审批记录也记录在Git的历史状态中。 -
Git 成为 “sourceof truth”,我们可以追溯变更历史、可以回滚到指定版本。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
-
基础架构即代码(Infrastructure-as-Code,IaC)则是一种典型的声明式 API。 -
Docker和Kubernetes容器技术是实现Immutable Infrastructure模式的最佳实践。
GitOps与声明式API、不可变基础设施相结合,保障了应用环境的可复现性,提升了交付与管理效率。
总结
虽然IaC的应用范围很广,但我们不要被它宏大的管理理念所吓退。“对的那条路,往往是最好走的”,首先我们要有一个清醒的思路:
-
将基础架构分而治之,分解成不同的功能模块; -
选择合适的配置管理工具作为统一的配置管理中心,能够对不同模块进行编排; -
结合版本控制工具,实现对配置文件的代码托管; -
结合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
❞
运维:对数据要有敬畏之心
ansible自动化:备份管理实践 ansible自动化:基础软件的自定义安装
Jenkins+Ansible:助力基础设施建设
运维从零认识云原生
容器CNI 这么多,如何选型?
札记:对的那条路,往往不是最好走的! 喜欢这篇文章,记得 点赞+在看 哦~