什么叫作IaC,与DevOps有什么关系？如何实现？

　　互联网时代  ，Development应运而生，用户高并发  ，Operations 因势而动，用户终体验  Dev + Operations = DevOps。茫茫IT大江湖，创新钻研的人总会相遇，接头暗号：敏捷、持续、稳定、交付，探讨DevOps趋势，今天要给你们普及的是IaC，那么什么叫作IaC,与F5的DevOps有什么关系？如何实现呢？

　　Infrastructure as Code：基础设施即代码(如下均简称IaC)是一种用描述性的方式来管理基础设施（包括网络，虚拟机，存储，负载均衡等），IaC模型在每次应用时都生成相同的环境，它是与DevOps结合的关键时间，与持续交付(Continue Delivery)结合使用。
　　

　　IaC的发展，解决了CD流水线中的环境飘移问题。若是没有IaC，团队必须维护各个环境的设置。随着时间的推移，每一个环境都会成为了信息孤岛，没法自动复制相同的配置。环境之间的不一致会致使部署期间出现问题，最后会致使基础设施的管理，变得很是难以跟踪，而且只能经过手动进行单独的维护。
　　

　　与DevOps的关系

　　IaC是成为在DevOps中实现最佳实践的关键属性，开发人员能够更多地参与定义配置，Ops团队在开发过程的早期阶段就参与其中。利用IaC的工具能够提升服务器状态和配置的可见性，最终为企业内的用户提供可视性，旨在将团队汇集在一块儿，最大限度地发挥他们的做用。自动化一般旨在解决手动过程当中的混乱和容易出错的问题，并使其更高效，更高效。容许建立更好的软件和应用程序，灵活，减小停机时间，并为公司提供总体成本效益的方式。IaC旨在下降从手动配置中带来的复杂性。自动化和协做被认为是DevOps的核心要点，基础架构自动化工具一般做为DevOps工具链的重要一环。

　　IaC的特色

　　1版本控制和历史管理

　　2全部操做能够追溯和进行审计

　　3快速简单，容易回滚

　　4方面团队协做，共同维护

　　5幂等性(Idempotence)

　　而幂等性是这里面一个很重要的规范原则，不管环境的起始状态如何，这个部署指令执行了多少次，它均可以保证环境最终的状态是一致的。所以，经过IaC，团队对环境描述进行更改并对配置模型进行版本化，一般会采用标准化并容易理解的代码格式（如JSON，YAML）。持续交付Pipeline以IaC方式配置目标环境。若是团队须要进行更改，他们会编辑源，而不是目标。记住，Source of the truth!

　　IaC主要带来三个主要的价值

　　1成本（减小）

　　2速度（更快的执行）

　　3风险（人为的操做错误所带来的安全隐患）

　　实施IaC的团队能够快速，大规模地提供稳定的环境。团队经过代码表示环境的最终指望状态，从而避免手动配置环境并强制实现一致性。使用IaC进行基础架构部署都是可重复的，可防止因配置误差或缺乏依赖性而致使的运行时问题。
DevOps团队能够与统一的实践和工具协同工做，快速，可靠，大规模地交付应用程序及其支持基础架构。

　　实现IaC一般有两种方法

　　1Imperative（命令式）

　　2Declarative（声明式）
　　

　　命令式的特色很是明显，若是须要达到最终的目的，你要以适当的顺序执行特定的命令，好比你执行的顺序是123，就绝对不能是321。而且每一步操做，你都须要执行对应的API或者指令应该在哪里。
　　

　　而声明式就很是简单了，只须要描述你所需环境的最终状态，而后经过少许的API任务，post过去，最终环境就能够根据你所须要的描述，生成最终的状态，因此也很是受开发者喜好。
　　

　　而f5有4种声明式的组件来匹配在持续交付流水线中的每个环节：部署，上线，配置，监控。