不是只單獨使用Terraform，而是與GitLab一起使用的方法

2 年 ago
韵, 科
2 minutes

由于所有的操作都可以在GitLab上完成，所以非常方便。

在使用Terraform时，通常需要在编辑器中准备配置文件，并在适当的计算机上安装和运行Terraform。但如果使用GitLab，可以实现更高级的操作（或者说，跨越数个阶段的操作），因此我强烈推荐使用。

什么让你开心？

只需一个选项！以下是原文的中文释义：

1. 我们可以委托您管理tf文件的版本控制。
2. 我们也可以委托您完成state文件的补全。
3. 同时还提供了秘密信息检测功能。
4. 您可以使用问题追踪系统，通过协作进行修正和更改管理。

无论如何，让我们试用吧。

详细的步骤 de

关于机制

首先，我简要解释一下机制。

GitLab有两种类型。一种是GitLab SaaS版，另一种是GitLab自托管版。
SaaS版只需注册账户即可立即使用。自托管版则需要自己准备云服务器或本地机器进行安装。

使用SaaS版，实际上所有的环境都可以完全交给GitLab公司处理，因此心理上会轻松很多。而自管理版则需要自己负责实例的繁琐事务。

接下来，我将解释如何在GitLab上运行Terraform。

通过查看Hashicorp社的书籍或Terraform的书籍，可以了解到，首先需要在一个适当的机器上（例如自己的Mac）安装Homebrew，或者从Hashicorp社的网站下载安装程序进行安装。然后，首先要确认是否成功安装，并且创建一个main.tf文件，按照规定的方式编写定义。这将包括填写与AWS、GCP、Azure等服务账号相关的ID，并进行运行。

使用GitLab来运行，意味着什么呢？简而言之，首先不再需要安装Terraform。确切来说，我们在GitLab的代理程序中，也可以称其为“Runner”，来运行Terraform。实际上，Runner为我们处理了这些操作。再进一步解释一下，我们可以在这个Runner上运行一个已安装Terraform的Docker镜像，并在其中执行我们自己编写的Terraform定义文件（例如main.tf）。我们有两个选择，一是在Runner上进行安装Terraform并验证运行main.tf等文件等方法，因为Runner本质上也只是一台Linux等系统的机器，我们可以在这里使用Terraform安装程序进行安装和验证。但在这个时代，后者过于过时，因此在本文中，我们将解释使用前者的Docker镜像来运行的方法。如果只能选择后者，因为无法使用后文中提到的include语法，将需要自行努力解决。因为这太麻烦了，所以在本文中不进行解释。

在Linux、Mac、Windows等操作系统上都可以使用Runner，但是如果使用GitLab的SaaS版本，我们就不需要考虑那么多了，只需要在Linux版的Runner上运行。因为GitLab的SaaS已经为我们准备好了，所以我们不需要再去考虑其他。其实，执行Terraform定义的机器的操作系统并不重要，只需要按照main.tf等文件的内容进行正确配置即可。

如果使用Self-Managed版本的GitLab，您需要自行准备Runner用机器，并完成GitLab服务器和Runner的协作设置。这是之前解释过的部分。如果选择使用Docker，只需通过Yum等方式确保Docker可以运行即可。

如果使用GitLab SaaS版，需要进行设置开始。

本文将介绍GitLab的SaaS版本。

步骤1. 注册账户

image.png

第二步：创建团体

image.png

第三步。前往存储库。

image.png

第四步。创建.gitlab-ci.yml文件。

image.png
include:
  - template: Terraform.latest.gitlab-ci.yml

variables:
 TF_STATE_NAME: default
 TF_CACHE_KEY: default
 TF_ROOT: terraform

顺便提一下，这里在TF_ROOT里指定了“terraform”。这是因为我不喜欢在这个仓库的直属目录下创建main.tf之类的文件，而是想创建一个名为“terraform”的文件夹来管理。不过其实这个指定是可有可无的。

基本上，这方面的内容已经在这里（https://docs.gitlab.com/ee/user/infrastructure/iac/）进行了解释，请努力阅读。在这里，

include:
  - template: Terraform.latest.gitlab-ci.yml

这句话的意思是，在这里指定了这个动作。由于有了这个指定，这个GitLab会使用Docker来执行Terraform的配置。

暫時先不用思考，直接按下「提交更改」然後儲存。

第五步：创建terraform文件夹

image.png

第六步：创建main.tf文件。

image.png

因为这个main.tf文件需要详细说明，所以在这里我会进行解释。
首先，

terraform {
  backend "http" {
  }
  required_providers {
    gitlab = {
      source  = "gitlabhq/gitlab"
      version = "16.0.3"
    }
  }
}
image.png

如果仔细看的话，它已经被定制过了，首先是这个。

  backend "http" {
  }
image.png

接下来

variable "gitlab_access_token" {
  type = string
}

provider "gitlab" {
  # Configuration options
  token = var.gitlab_access_token
}
image.png

下一步是遮蔽的部分

data "gitlab_project" "example_project" {
  id = xxxxxxxx
}
image.png

然后最后

resource "gitlab_project_variable" "sample_project_variable" {
  project = data.gitlab_project.example_project.id
  key     = "example_variable"
  value   = "Greeting Master!"
}

这只是一个完全毫无意义的动作，只是在Terraform中给一个随意的变量赋值。本来，在这里你可以尽情地写下各种巨大的配置，例如实例的大小、CPU核心数、内存大小等等。

最后点击“提交更改”，进行提交和保存。

第七步。访问令牌的设置。

image.png
TF_VAR_gitlab_access_token

“TF_VAR_”这个前缀有点奇怪，但是它被添加到了main.tf中，这样Access_Token就会被正确赋值。这个规则是在”.gitlab-ci.yml”文件中指定的，通过include文件进行定义。

第八步。执行main.tf文件。

其实在我到这里之前，GitLab尝试执行了多次。这是GitLab的默认行为，它会始终执行，就好像有任何变化都会被实时执行一样。当然，这是可以进行控制的。关于这方面的内容，需要对GitLab进行详细学习，所以在这里省略了解释。

image.png
image.png
image.png

太棒了。你可以自由地在main.tf文件中的”resource”部分做任何你喜欢的修改，或者根据terraform文件夹下的各种terraform书籍进行参考，自由地将文件分割成你喜欢的方式，最后请按照你的喜好继续操作。

你已经准备好了

问一下，假设要说的话是，可以通过编写Terraform的main.tf之类的东西，在测试环境（如VPC）上任意做一些混乱的事情，然后完成后将其用作生产环境，是这样的感觉对吧。
在这种情况下，可以在.gitlab-ci.yml文件中实现类似的功能，比如”如果分支名是main，则指定用于生产的VPC”，”如果分支名不是main，或者以xxx开头，则指定用于staging的VPC”之类的事情是可以实现的。

因此，由于需要学习GitLab的yml文件语法，我们将在另一个机会进行学习。

请在查看本文时，只需关注在GitLab上运行Terraform所需的步骤和流程。

GitLab万岁.

✖
广告
将在 10 秒后关闭
bannerAds