Infrastructure-as-Code (IaC)

Infrastructure-as-Code工具

每个环境及其目的都是独一无二的. 有些工具比其他工具更适合, 所以有必要研究一下什么最适合你的具体需求. 值得注意的是，许多云提供商为其平台提供原生工具和服务. 尝试在研究过程中考虑到这一点，以避免在采用特定平台时可能已经可用的功能冗余.

了解更多关于我们的方法： 将云安全与DevOps和CI/CD工具集成

起程拓殖

起程拓殖帮助用户以人类可读的方式定义资源和基础设施, 声明性配置文件. 它可以在多个云平台上管理基础设施的生命周期, 以及在整个部署过程中跟踪资源更改.

厨师下文

厨师下文允许用户通过定义可重复的策略来自动化配置管理, 一致的, 和可重用. 它可以将配置和策略定义为可测试的代码, 可强制执行，并且可以作为自动化管道的一部分大规模交付. Chef还可以检测配置漂移并在需要时进行纠正.

Puppet

Puppet是一个使用声明性代码来帮助管理和自动化服务器配置的工具. 它支持根据组织的It需求扩展基础设施自动化. 用户可以描述所需的系统状态，而不是到达那里所需的步骤.

AWS CloudFormation

AWS CloudFormation帮助用户通过DevOps管理基础设施. 它支持自动化、测试和具有CI/CD自动化的基础设施部署模板. 它还可以扩展和管理基础设施，以包括在CloudFormation Registry中发布的云资源, 开发者社区, 以及用户的图书馆.

Ansible

Ansible是一个开源的命令行IT自动化软件应用程序. 它可以配置系统, 部署软件, 并编排高级工作流以支持应用程序部署, 系统更新, and more. Ansible具有最小的“移动部件”，并使用OpenSSH进行传输. 它还采用了一种人类可读的语言，因此用户可以快速入门.

SaltStack

SaltStack是基于python的, 用于远程任务执行和配置管理的开源软件, 使用户能够部署和配置复杂的IT系统. 它将人类可读的YAML与事件驱动的自动化相结合，从而使ITOps受益, DevOps, NetOps, 或SecOps函数.

IaC的好处是什么?

在云环境中，基础设施即代码的主要好处是——如上所述——速度. 再深入一点，就会发现以下更切实、更具体的商业利益：

• 手动配置模板化： 以前, 每次准备部署应用程序时，开发人员都必须手动配置基础设施. IaC用模板自动化了这个过程. 可以快速有效地利用可重复的代码, SecOps用这些模板建立安全控制和护栏.
• 降低风险: 风险永远不可能完全消除. However, 通过构建与组织安全标准和最佳实践保持一致的可重复模板, 人为错误和漏洞的风险将会降低.
• 减少浪费开支： 以及提供错误配置资源的可能性, 人为错误通常会导致基础设施资源的过度供应. 通过对资源卷应用护栏, 您可以避免与过度供应的资源相关的浪费.
• 打造更强大的团队： IaC可以节省成本，提高技术和业务效率. 也许最大的好处是减少了DevOps和SecOps之间的摩擦. 如果安全被自然地集成到流程中，那么安全组织在运行之前“检查开发人员的工作”的感觉就会减少. 这可以创造一个更积极的工作环境和团队友谊.

大多数现代企业希望实现的宏观效益是巨大的。”左移位.也就是说，将DevOps和SecOps整合成一个真正的 DevSecOps 将安全性移入CI/CD管道的文化, 将安全性和遵从性从被动的立场转变为预防性立场.

声明式与命令式IaC

再一次，什么是IaC? 很明显，有很多方法可以回答这个问题. 再深入一点, 一般有两种方式：声明式IaC和命令式IaC. 简单地说，这两种方法是开发人员告诉IaC自动化平台要做什么的方法.

声明式IaC

陈述期望的结果, 用户让系统依赖于预构建的模板和规则来获得该结果. 因此, 用户对配置过程的技术知识要求更少，并且通过委托获得效率. 用户实际上是在说, “我希望这个结果能在整个过程结束后出现, 我不管你怎么做.“另一个好处是，用户可以采取更具战略性的方法来塑造和部署整个应用程序.

作为快速复习, IaC的本质是编写定义代码运行的云基础设施的语句. 声明性IaC只是一种更快、更容易获得预期结果的方法, 是绝大多数时候使用的方法.

命令式IaC

负责定义每个步骤以获得最终结果可能听起来像是一个很大的缺点, 它可以是. 用户必须熟悉编程语言，并且必须完美地执行整个操作的每一步. 这样做的好处是用户可以更好地控制自动化过程和代码, 并且可以根据具体情况定制配置过程.

它包括告诉控制器如何做确切的事情. 重复这个循环, 检查这个边界条件, 如果满足条件，执行此操作, 但如果条件不满足，这另一个动作.命令式编程本质上是微观管理，通常由人主导.

IaC面临哪些挑战?

团队必须确保通过IaC将速度和效率添加到开发生命周期中不会产生安全问题——在过程中尽可能早地实现安全控制和检查是至关重要的. 这样做可以通过在创建模板之前捕获问题来帮助避免创建不遵循组织标准的资源. 让我们来看看IaC面临的一些挑战(别担心, 好处肯定超过了它们)：

• 存在安全风险的模板： 模板构建完成后，并不意味着它没有错误. 在使用模板之前检查模板是一个好主意，以避免在第一时间创建有风险的资源.
• 内置的分析: 一旦IaC付诸实施, 扫描工具也必须集成到, 如上所述, 在错误变成真正的漏洞之前抓住它们. 好消息是，静态IaC分析和动态IaC分析都可以帮助分析代码, 识别配置错误, 并评估运行IaC模板的云环境.
• 与IaC合作： 在给定的时间内，实现和使用IaC伴随着学习曲线，这可能会耗尽开发人员的资源，并可能创建一个与团队可能习惯的根本不同的工作流. 另外, 它要求IaC模板的存储库足够全面，以确保它适合整个开发团队的需求. 因此，涉众团队在保持模板更新的计划上保持同步是至关重要的.
• 人类摩擦: 在实现IaC时, 对于开发人员来说，由于需要持续使用安全工具来确保基础设施免受错误配置和漏洞的影响，因此很难处理中断或放缓的感觉. 为了安全起见，开发人员可以尽可能无缝地快速扫描IaC模板并继续工作.

阅读更多关于IAC安全的信息

Rapid7博客上最新的云基础设施主题