基础设施自动化管理-IaC工具-Terraform

前言

DevOps是实践、工具和文化理念的集合，旨在自动化和整合软件开发和运维团队之间的流程。

DevOps的核心目标是：

  • 自动化软件开发和交付过程：实现持续集成、持续交付和自动化测试。
  • 改善开发和运维团队的协作：通过共享目标和工具来提高团队之间的协作效率。
  • 基础设施自动化：通过自动化管理基础设施来提高一致性、可重复性和可靠性

DevOps不仅关注应用代码的持续集成（CI）和持续交付（CD），还关注基础设施的自动化和管理。

这也是为什么基础设施即代码（IaC）和自动化基础设施管理是DevOps实践的关键组成部分。

DevOps是CI/CD、GitOps实践和IaC工具Terraform产生的背景和基础。

DevOps实践

GitOps和CI/CD是DevOps文化的延伸，2种具体实践，但有以下区别

 特性  GitOps  DevOps-CI/CD
 核心概念  基于 Git 的配置管理和自动化部署  开发与运维的协作与自动化
 工具链  Git、Argo CD、Flux 等  CI/CD 工具（Jenkins、GitLab CI 等）
 操作对象  基础设施和应用配置  应用程序的构建、测试、部署
 优势  配置一致性、环境可追溯性、易回滚  持续集成、持续交付、协作自动化

--------------------------------------

特别是在云原生和 Kubernetes 环境中。

GitOps是1种将基础设施管理与版本控制系统Git深度结合的运维方法，通过自动化流程实现环境的一致性、可追溯性和高效性。

GitOps非常适合现代云原生架构，尤其是K8s环境中的配置和应用管理。

GitOps = IaC + 版本控制 + 自动化同步 + 持续监控

IaC（Infrastructure as Code）

GitOps 的基础是基础设施即代码（IaC），即通过代码的方式声明和管理基础设施的配置。所有资源的定义都是声明式的（如 Kubernetes 的 YAML、Terraform 文件），这为自动化和一致性奠定了基础。

版本控制（Version Control）

GitOps 将所有的基础设施和应用配置存储在Git 仓库中。Git 作为单一真实来源（Single Source of Truth），提供了：

变更管理：通过 Pull Request (PR)/Merge Request (MR) 进行代码审查和批准。

版本历史：所有的配置变更都有详细的历史记录，便于审计和回滚。

自动化同步（Automated Synchronization）

GitOps 工具（如 Argo CD、Flux）会持续监控 Git 仓库中的配置变化，并自动将变更同步到目标环境，确保实际状态与期望状态一致。

无需手动部署，一旦变更被合并到 Git，自动化工具会执行部署或更新。

持续监控和自愈（Continuous Monitoring & Self-Healing）

GitOps工具还会持续监控目标环境中的实际状态，确保其与 Git 中的声明状态一致。

如果环境发生了偏差（例如资源被意外修改或删除），工具可以自动纠正或触发告警，确保环境的稳定性和一致性。

总结

GitOps = IaC + GitOps Workflow (版本控制 + 自动化同步 + 持续监控)

这种组合不仅实现了基础设施即代码，还通过 Git 提供了协作、可追溯性、自动化交付和系统稳定性，使得运维流程更加高效、透明和可靠性。

DevOps工具集

如上所述，DevOps是文化理念、实践和工具的集合；

在DevOps中有CI/CD和GitOps两种具体实践；

CI/CD是DevOps中的一种具体实践，专注于自动化软件的构建、测试和部署。

GitOps也是DevOps的一种具体实践，专注于使用Git管理基础设施和应用配置，确保持续的自动化和一致性。

自DevOps文化兴起后，随着人们持续不断地进行实践，大量DevOps工具应运而生。

端到端到DevOps流程

在DevOps文化中，CI/CD和GitOps通常会一起使用，形成1个完整的自动化交付流程：

CI（持续集成）阶段：

开发人员提交代码到 Git 仓库。

自动触发CI 流程，完成代码的编译、测试、构建镜像，并将镜像推送到镜像仓库

CD（持续交付/部署）阶段：

CI 完成后，更新GitOps配置文件（如 Kubernetes 的 YAML 文件）中的镜像版本。

GitOps工具（如 Argo CD）检测到Git配置文件的变化后，自动将新的配置部署到 Kubernetes 集群中。

一、Terraform念

Terraform是Hashicorp开源的1款基础设施即代码 (IaC) 的工具，可让您以代码化的方式定义和管理云基础设施。

Terraform提供了“Provider”的插件机制，每个Provider面向一个独立的服务提供商的插件，可让您与不同的云服务提供商通过 API 与其进行交互，进而实现对不同云基础设施资源的自动化管理。

例如：您可以使用面向阿里云的 Terraform Provider 来定义和管理阿里云的基础设施。

1.架构

2.项目代码

3.工作流程

这张图展示了1个使用Terraform在Azure Cloud上部署Web应用的工作流程。以下是详细解释：
Write code（编写代码）

流程从左上角的 “Write code” 开始，表示编写 Terraform 配置代码的过程。

main.tf（主配置文件）

编写的代码存储在一个名为 “main.tf” 的文件中，这个文件是 Terraform 的主配置文件。

2.terraform init 初始化

从 “main.tf” 文件出发，箭头指向 “terraform init” 操作。这一步是 Terraform 的初始化步骤，用于初始化工作目录，下载所需的提供者插件等。

3.terraform plan 计划

初始化后，进入 “terraform plan” 步骤。这一步用于生成一个执行计划，显示 Terraform 将执行哪些操作来达到期望的基础设施状态。

4.Approve 批准

在 “terraform plan” 之后，有一个 “Approve” 步骤，表示需要人工审查并批准执行计划。这个步骤由一个绿色的对勾图标表示。

5.terraform apply 应用

批准后，进入 “terraform apply” 步骤。这一步用于实际执行基础设施的创建、更新或删除操作。

terraform.tfstate（状态文件）

在 “terraform apply” 操作之后，生成一个 “terraform.tfstate” 文件。这个文件记录了当前基础设施的状态。

6.基础设施创建成功

整个流程的最终目标是在 Azure Cloud 上部署基础设施。图的右侧展示了 Azure Cloud 中的资源结构：

        • Availability Zone 1 和 Availability Zone 2（可用区 1 和可用区 2）：这两个区域用于提供高可用性。
        • Web App（Web 应用）：在每个可用区内都部署了一个 Web 应用，这些应用由蓝色的图标表示。

以上执行流程主要涉及以下几类文件：

.tf 文件

这是最核心的配置文件，用于定义基础设施资源相关内容。

声明要创建的各类资源（像云服务器、数据库、存储桶等），同时可以设定资源的具体属性、参数等，还能定义变量、输出变量以及模块调用等情况，

示例如下：

# 定义一个阿里云的OSS存储桶资源

resource "alicloud_oss_bucket" "my_bucket" {

  bucket = "my-test-bucket"

  acl = "private"

}

.tfvars  文件 

.tfvars文件主要功能是为.tf文件中定义的变量赋值。

在不同的部署环境（如开发环境、生产环境）中，变量的值往往不同，通过.tfvars文件可以灵活地指定这些具体值，方便配置复用；

例如：

region = "us-west-1"

instance_type = "t2.micro"

versions.tf

主要用于声明期望的版本要求，指定

  • Terraform核心版本范围
  • 各个 Provider的版本范围
  • 模块大致的版本

它更多是1种宽泛的、基于规则的版本设定，给出了一个允许使用的版本区间。例如在versions.tf里写 

provider "aws" { version = "~> 4.0" }，表示希望使用接近 4.0 版本的 AWS Provider，但具体是 4.0 几并不明确限定。

# 指定Terraform核心版本要求
terraform {
  required_version = ">= 1.1.0"
}

# 指定AWS Provider版本要求
provider "aws" {
  version = "~> 4.0"
}

# 指定具体模块及版本
module "my_web_app" {
  source  = "my-org/my-repo/my-web-app"
  version = "2.0.0"
}

 

.terraform.lock.hcl  文件

Terraform在首次运行terraform init命令初始化Terraform工作目录，或者在添加/更新提供者或模块时自动生成或更新.terraform.lock.hcl文件。

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of kreuzwerker/docker...
- Installing kreuzwerker/docker v2.12.2...
- Installed kreuzwerker/docker v2.12.2 (self-signed, key ID 24E54F214569A8A5)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

这确保了文件能够及时反映当前项目所依赖的资源的最新版本信息。

当Terraform 执行初始化（terraform init ）等操作时，会根据versions.tf里的要求去查找并下载符合条件的具体版本，然后把实际用到的这些版本信息记录到terraform.lock.hcl文件中。

比如按照上述 AWS Provider 的要求，实际下载使用了 4.0.5 版本，就会在这个文件里明确记录下来，后续再次执行相关操作时，就会固定使用这个已经锁定的 4.0.5 版本，避免因意外引入不同版本而出现兼容性问题

# 示例的部分内容，展示锁定的模块及版本信息

provider "registry.terraform.io/hashicorp/aws" {

  version = "4.64.0"

  hashes = [

    "h1:abcdefg123456789...",

  ]

}

versions.tf和terraform.lock.hcl文件的区别

虽然versions.tf设定了版本的大致要求，但terraform.lock.hcl通过锁定实际使用版本来进一步增强版本管理的精确性、一致性和稳定性；

二者相互配合共同完善Terraform项目的版本管理工作。

terraform.tfplan文件

- 执行terraform plan命令后会生成该文件，它呈现了Terraform根据当前配置将要对基础设施资源做出的更改计划，清晰列出哪些资源会被创建、哪些要更新、哪些会被删除等内容，方便提前查看操作规划。

.tfstate文件

由Terraform backend管理存储的状态文件，记录着已创建资源的实际状态信息，像资源的具体ID、当前的属性详情、资源间的关联关系等。

Terraform依据这份文件里的状态去执行后续的更新、删除等操作。

为了便于团队协作，通常存在S3对象存储；

.tfstate文件通常为JSON格式可以使用Ansible调用生产主机清单（inventory）；

本地存储

在使用terrafom apply执行部署计划之后，当前目录中就产生了名叫 “terraform.states” 的 Terraform 的状态文件，该文件中记录了已部署资源的状态。

默认情况下，在执行部署计划后，Terraform 的状态文件会存储在本地，但是这样往往就造成一些弊端：

（1）不适用团队之间协助，就好比在数据库中对同一条数据进行操作时，就会引起异常

（2）状态文件中包含一些机密信息，会造成一定的机密泄露

（3）如果不慎将本地的状态文件删除掉的话，已执行部署计划的资源的管理将很难在通过Terraform进行管理

所以，Terraform 是支持在远端存储状态文件，也就是在 Azure Storage Account 中存储远端状态文件，Terraform 状态的存储是由1个称之为Backend的组件决定的

远端存储

面对本地状态存在的问题，当使用远端状态存储时，这些问题将会得到解决：

  1. 远端状态文件会自动更新

    当远程存储时，状态文件会自动更新，即一旦配置了远程后端，每次运行 plan 或 apply 命令时，Terraform 将自动从远端加载状态文件。除此之外，它还会在每次 apply 后自动将状态文件同步存储在远端中，因此不存在手动错误的情况。

  2. 远端状态文件支持状态锁定

    当执行Terraform命令时，可以对远端状态文件进行加锁，这样如果多个开发人员同时运行 terraform apply，它不会因同时更新而损坏。

  3. 远端状态文件存储比本地存储更安全

    OSS Bucket 支持本地传输加密和远端加密功能。此外，OSS Bucket 包括多种配置访问权限的方法，因此你可以以精细化的方式控制状态文件的访问权限。

4.Ansible对接Terraform

使用Terraform创建出IaaS层之后，可以使用Ansible配置主机的环境、安装基础软件

以下是两个比较知名的terraform.py开源项目：

python-terraform项目

- 项目地址：https://gitcode.com/gh_mirrors/py/python-terraform.

- 功能特点：其启动文件  python_terraform/terraform.py  定义了  Terraform  类，封装了Terraform命令的执行，如  init()  用于初始化工作目录， plan()  生成执行计划， apply()  应用计划， destroy()  销毁资源等，可通过Python代码直接调用Terraform命令来管理基础设施.

- 使用场景：适用于需要在Python项目中集成Terraform功能，实现基础设施自动化部署和管理的场景，例如在自动化运维、持续集成/持续部署流程中，通过Python脚本调用Terraform命令来创建、更新或销毁云资源.

Terraform.py项目

使用Terraform创建好基础设施资源后，可以使用Ansible对基础设施资源进一步做环境配置

- 项目地址：https://gitcode.com/mantl/terraform.py.

- 功能特点：核心文件是  src/ati/terraform.py ，主要功能是解析Terraform的  tfstate  文件并生成动态的Ansible库存，支持AWS、Google Cloud、Openstack等多种云服务提供商，仅使用Python标准库，便于部署和维护.

- 使用场景：在使用Ansible进行配置管理时，可借助该项目动态获取Terraform创建的资源信息，自动生成Ansible主机清单，实现对基础设施的自动化配置和管理，特别适合需要跨多个云平台进行基础设施管理的企业.

 

参考

posted on 2023-06-26 09:15  Martin8866  阅读(659)  评论(0)  编辑  收藏  举报