我们希望听到您的意见!帮助我们深入了解 Ansible 生态系统的现状。
参加 2024 年 Ansible 项目调查













使用 Ansible 构建云基础设施

使用 Ansible 构建云基础设施

diagram one

轮子发明于公元前 4 千年。现在,在 4 千年后,我相信轮子是当时最热门的东西,只有最受欢迎的新石器时代酷猫才有轮子。快进到今天,我们都可以同意轮子没什么特别值得说的。它是我们日常生活的一部分。轮子并不性感。如果我们想让轮子再次变得性感,我们只需要将一辆跑车与所有最新的配件和磁通电容器组合在一起,涂上漂亮的 Ansible 红色,瞧!我们就有了我们想谈论的东西。 

就像跑车一样,Red Hat Ansible 自动化平台也具有将现有资源转变为更有趣事物的相同能力。它可以增强工具集并将它们进一步扩展到自动化工作流中。 

让我们以 Terraform 为例。Terraform 是一种常用于基础设施即代码的工具。在跨多个大型公共云提供商(如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform (GCP))以可重复的方式预配基础设施时,这是一个非常棒的工具。许多组织每天都使用 Terraform 进行快速的基础设施预配,但如果我们将其与 Ansible 的强大功能相结合,我们会发现它构建成一个高效的工作流。

不要替换工具 - 重用、增强和掌握它

正如我所说,Ansible 有一种方法可以增强现有工具并对其进行大修。如果一个组织已经使用 Terraform,那么浪费构建其清单和配置的所有工时将是一件可惜的事情。相反,我们可以利用我们现有的资源创建一个工作流,该工作流构建更多 Terraform 清单、自动化预配并提供一种可扩展的方法来触发预配后任务。随着 Ansible 处于领先地位,我们能够扩展 Terraform 的基础设施预配,并允许进行配置即代码、应用程序部署和合规性自动化。可能性清单与最新德国汽车上的配件一样无穷无尽。 

首先要考虑的是,在将 Terraform 作为自动化的一部分使用时,我们需要哪些自动化执行环境。我们的执行环境需要能够执行 Terraform 任务,因此我们需要确保 Terraform 实际上正在执行环境上运行。

我通过下载二进制文件并将其简单地复制到基本执行环境中来实现这一点。 

我还嵌入了一个 keep_secrets 文件,我们将与 Ansible vault 一起使用。

[---
version: 1

build_arg_defaults:
    EE_BASE_IMAGE: < BASE EE >

dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

additional_build_steps:
  prepend: |
    ADD terraform /sbin
    ADD keep_secrets /opt
  append:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc

一旦我将我的执行环境推送到我的私有自动化中心,我们就准备好开始构建了! 

我将使用三个文件处理使用 Terraform 进行预配的简单用例

  • main.tf - 此文件包含我需要的基础设施所有配置信息
  • variables.tf - 此文件将保存我使用并在 main.tf 文件中引用的所有变量
  • cloud-init.conf - 我使用 cloud-init 来注入配置信息,例如要创建的用户和要添加到 authorized_keys 的 SSH 密钥 - 这样我的自动化控制器就可以连接并执行其操作。

部署云基础设施所需的所有组件都是这些清单的一部分 - 这是我们的基础设施即代码。使用 Terraform 部署它们使我们能够快速轻松地销毁所有预配的基础设施。这可以通过避免在您的云平台上留下任何配置工件并加快整个生命周期来带来好处。 

要创建这些清单,我们可以使用 Jinja 模板并在我们的自动化工作流中使用调查。Ansible 自动化平台中的调查使我们能够向自动化使用者提供输入数据的机会,我们可以在自动化内部使用这些数据。  

diagram two

这意味着创建所有基础设施即代码组件实际上成为我们团队的动态机制,使流程变得更加容易。使用 Jinja 模板,我创建变量清单,然后 main.tf 将使用所有这些组件来构建和计划部署。 

main.j2 > Summarized Example


resource "aws_instance" "ioc_basic" {
  for_each      = data.aws_subnet_ids.production.ids
  ami           = "${var.ami_number}"
  instance_type = "${var.instance_type}"
  subnet_id     = each.value
  key_name   = "${var.terraform_prov}"
  user_data = file("./cloud-init.conf")
  tags = {
      Name = "${var.instance_names}"

 variables.j2 > Summarized Example


variable "ami_number" {
  default = "{{ ami_number }}"
}
variable "secret_key" {
  default = "{{ secret_key }}"
}
variable "instance_names" {
  default = "{{ instance_names }}"
}
variable "instance_type" {
  default = "{{ instance_type }}"
}

预配基础设施

diagram three

提供调查数据后,我们可以让 Ansible 为 Terraform 创建一个项目文件夹。这应该存储在真相来源中,在我的示例中,我使用的是 Git 存储库。获得项目文件夹后,我们将创建 Terraform 构建和部署基础设施所需的所有清单和配置。Ansible 自动化平台有一些模块可用于从我们的 playbook 中触发所有 Terraform 操作,它将在构建过程中触发 Terraform 初始化此项目文件夹,以确保它安装了正确的供应程序。 

我目前正在使用 AWS;但是,如果您想为 Terraform 提供对多个提供商的访问权限,这就像为其创建一个 Jinja2 模板并在工作流调查中为用户提供选项一样简单。在我们的 playbook 中,我们现在可以使用 Terraform 模块来触发 IoC 清单的初始化、规划和部署。

- name: Creating Terraform IoC
  block:
   - name: Initialize Terraform Provider
     community.general.terraform:
       project_path: /{{ working_dir }}/{{  my_terraform_build }}
       state: absent
       force_init: true

    - name: Deploy Terraform Instance
      community.general.terraform:
        project_path: /{{ working_dir }}/{{ my_terraform_build }}
        state: present
      register: deployed_tf

Terraform 部署基础设施后,它会创建一个状态文件,用于存储您管理的基础设施配置和映射资源。如果我们要修改基础设施,我们将重用状态文件。但是,它也可以用作有关该实例的信息来源,用于预配后任务。例如,如果我们需要更改负载均衡器,则此文件是我们可以利用的简单信息来源。由于我们的执行环境是短暂的,因此在加密这些状态文件后,我们将将其推送到我们的构建存储库。

现在,Terraform 擅长创建基础设施以及销毁它。它简化了整个过程,并且在清理方面做得很好。我们将需要用于取消预配基础设施的变量清单,因此最好将这些清单和我们的状态文件放在构建存储库中,以便不仅以后能够销毁实例,还能够重用此配置或修改基础设施。由于这些文件将包含敏感信息,因此我们可以使用 Ansible 在将它们推送到我们的真相来源之前使用我们嵌入到执行环境中的密钥文件加密这些文件。 

轮子在转动,但现在呢?

Ansible 自动化平台允许我们使用动态清单插件,因此我们将使用相关插件来允许我们更新清单以适应我们新预配的主机。这里真正酷的一件事是,我们可以在 Terraform 清单文件中提供我们想要的标签,并且在 Ansible 中,我们可以使用过滤器缩小我们的清单主机,专门查找这些标签。 

 example

regions:
  - "eu-west-2"

keyed_groups:
  - tag:Environment: terraform_dev

filters:
  instance-state-name: running

我们动态清单源中的这些过滤器允许自动化控制器仅收集与这些条件匹配的实例,并简化预配后的进一步任务。预配过程的最后一部分是为我们创建的实例的终止创建和更新调查。为此,我们使用 Ansible 创建 Terraform 存储库中所有项目的列表,我们可以将其传递给创建调查规范,我们在每次运行创建或销毁作业时更新它。 

销毁基础设施

diagram four

由于我们使用 Terraform 预配了我们的基础设施,因此取消预配它非常简单。正如我之前提到的,当 Terraform 创建基础设施时,它会建立一个真相来源,可以用作取消预配基础设施的简单方法。我们可以使用我们的自动化工作流从我们的存储库中获取正确的 Terraform 构建详细信息,对可能受影响的任何外部系统(如负载均衡器)进行更改,然后触发 Terraform 从我们的 playbook 中销毁它创建的实例。 

- name: Destroy Terraform Instance
  community.general.terraform:
    project_path: /{{ working_dir }}/{{ my_terraform_build }}
    state: absent

启动引擎!预配后

我们创建了一种使用 Ansible 和 Terraform 构建和销毁基础设施的可再生方法。为了进一步扩展自动化并完成部署工作负载、系统强化和合规性的重要工作,我们只需要依赖 Ansible。Ansible 自动化平台允许我们创建自动化工作流,这些工作流向我们展示了自动化步骤的视觉逻辑流程,并允许我们将任务组合到端到端流程中。这不仅是查看和检查自动化流程的好方法,而且我发现它有助于查明可能的改进,或者在步骤失败或遇到问题时向流程中添加回滚功能。

process diagram

是时候使用 Terraform 构建您的云,将基础设施即代码和配置即代码与我们的集中式 Ansible 自动化平台结合起来!