使用Terraform、Ansible和GitLab实现基础设施即代码平台

在需要跨多个环境创建基础设施的同时确保标准化和有效监控，确保这些环境安全地提供变得至关重要。为了实现这一点，采用不可变基础设施方法，其中环境作为代码提供，是至关重要的。

本文的目的是通过使用GitLab的结构来强制模板和标准，使用Terraform在服务器上应用和维护标准，以及使用Ansible进行软件提供和配置，并在存储库之间使用共享角色模型，展示实现这一目标的可能方法。为了管理Terraform中机器的状态，我们使用MinIO，因为它使此实施可以在本地进行。

架构设计

第一步

流程总是从提交一个标准化的议题开始，指定要使用的堆栈模型，是否需要防火墙权限，以及是新的设置还是只是资源升级。

第二步

操作者审查议题并开始流程。所有对话和花费的时间都在议题中记录。

第三步

一个新的项目在GitLab中启动，基于将创建的基础设施模型。该项目被放置在GitLab中相应的组内，在这里它继承了创建标准化基础设施所需的环境变量。

步骤4

当项目创建后，您只需在问题中指定的环境（KVM，VMware）中，定义要配置的基础设施的IP。通过Terraform规划后，所需的资源将被创建，包括根据标签策略为Veeam执行备份时需要的标签。如果需要，标签也会被添加。完成后，创建的基础设施状态将存储在一个bucket中。

步骤5

下一步是为所有服务器执行标准任务，例如识别服务器、更新软件包、安装必要的工具，并在Zabbix中注册主机，以便对操作系统和栈进行基本监控。根据资源组，适当的访问密钥将分配给相关的团队。例如，数据库管理员（DBAs）会接收数据库服务器的访问密钥。

步骤6

根据选定的模型，执行整个栈的安装和配置流程。同样，在必要时会创建用户，并在Vault中注册凭据。

步骤7

应用现在在新的环境中运行，可以对每个堆栈进行具体的监控，并在Consul中注册新服务器。Prometheus反过来确定它需要从哪里收集信息。每个堆栈都有自己的监控仪表板，只是创建的项目名称不同。

第8步

新基础架构交付给请求者。在数据库的情况下，凭据直接在Vault中提供。

项目结构

GitLab中的文件结构如下所示：

• /infrastructure/：主要组，应存储全局环境变量和默认值
• /infrastructure/gitlab-models：流水线模型，其中有两个主要项目
  • ansible-pipelines：一个致力于维护堆栈和角色组合的项目。

• terraform-pipelines：可用基础架构模型的流水线，如vSphere、KVM、AWS等。

• /infrastructure/templates：在这个组中，我们有启动项目，将用于创建栈模型。

• /infrastructure/provision/ansible/roles：在这个项目中，我们只包含了Ansible角色，允许我们以隔离的方式集中管理和更新角色。
• /infrastructure/dependencies-iac：这个代码库包含了平台的依赖项，例如Terraform和Ansible的Dockerfiles，确保必要的工具和库的版本不会被更改。
• /infrastructure/modules/：为Terraform创建的模块存储在此代码库中，每个项目都有其各自的文件夹。
• /infrastructure/on-premise/：这个组是用于维护创建的基础设施的，并按环境、数据中心、栈和项目进行分段。在图片中，我们可以看到从组到子组再到最终项目的层次结构。在这些层级中的每一个，我们都可以覆盖与组相关联的变量值。

如何使用平台

为了简化平台的使用，我们创建了一个名为issues-ops的代码库，在这里我们提供了一个问题模板，可以根据具体需求选择使用。这样，基础设施请求从一开始就被记录下来。

一旦创建了问题，DevSecOps团队可以开始设置环境。为此，他们只需导航到适当的组，即infrastructure/on-premise/staging/dc1/loadbalancer/nginx，并基于模板创建一个新的项目。然后，他们应该提供要创建的项目的名称并分配必要的变量。

在每个模板中，用于环境创建的.gitlab-ci.yml文件已经配置好。在NGINX的情况下，它是按此格式设置的。

在这种设置中，包括了基础设施创建模板和Ansible模板，确保这些项目已经集成了默认角色。此外，我们还提供了扩展模型的步骤。如果需要安装附加角色，您可以简单地添加相应的块，实现了配置的模块化、积木式构建方法。

在下面的图片中，我们看到运行了请求的环境创建管道。您会注意到authorized_keys和common被执行了，尽管它们并没有在.gitlab-ci.yml中显式声明。这是因为我们从导入的Ansible模板中包含了标准角色，确保了默认角色应用于所有项目。

结论

基础架构平台极大地贡献了维护和执行标准的工作，因为它要求在创建任何新基础架构之前，必须规划、测试、实施并作为模板提供预定义模型。这个过程确保了无论何时我们需要在环境中配置资源，我们都在建立一致的标准，对这些环境进行版本控制，并确保必要时它们可以被可靠地重建。

主要的挑战之一是保持模型的最新和验证，特别是随着应用的演变和操作系统版本的更改。使用基础设施即代码时，关键是要记住，所有更改都应该通过它进行，确保正确的配置版本控制和环境不可变性。不这样做可能会导致平台将环境恢复到其定义状态，可能会覆盖手动更改。

本文提出的模型是多功能的，适用于本地和多云环境，使其成为混合基础设施的有效解决方案。