使用Bitbucket Pipelines通过Terraform在GCP上实现基础设施CI/CD

1 年 ago

雅, 悟

3 minutes

個の選択肢のみです。

Bitbucket中自带有一个名为Bitbucket Pipelines的管道工具，可用于自动化处理，如CI/CD等。
即使是免费计划，每月也可以使用高达500分钟的构建执行时间。

本文介绍了如何使用Bitbucket Pipelines来执行Terraform，并进行Google Cloud Platform的配置管理。
还介绍了通过GitOps进行基础设施CI/CD的工作流程。

更新记录

2020-05-02 初稿投稿

动作确认环境

terraform-provider-google v3.19.0

準備物資

Service Account

Bitbucke Pipelines内で実行するTerraformで利用する
Terraformで行う操作に必要なCloud IAMの権限をつける
今回の構成では、少なくともGCSへの読み書き権限が必要

GCSバケット … TerraformのBackendとして利用し、tfstateを保存する
必要なAPIを有効化する

例）GCEインスタンスの操作には、Compute Engine APIの有効化が必要

建议的开发环境

推荐在本地操作 terraform 命令进行验证时，做好以下工具的准备：

Google Cloud SDK

安裝步驟

「存储库设置 > 管道 > 存储库变量」
键名设置为GOOGLE_CREDENTIALS（※从5/3开始更改为GOOGLE_CREDENTIALS_DATA）
不需要对值进行Base64编码
※勾选“Secured”

在存储库的根目录下，准备以下样式的bitbucket-pipelines.yml文件。

bitbucket-pipelines.yml 的配置

bitbucket-pipelines.yml是Bitbucket Pipelines的构建配置文件。

以下是用Terraform进行基础设施CI/CD的样例配置。

image: hashicorp/terraform:0.12.24

# パイプライン設定で重複するステップの記述をまとめるため、YAMLアンカーを定義
definitions:
  steps:
    - step: &terraform-plan
        name: terraform plan
        script:
          - terraform init -input=false
          - terraform plan -input=false
    - step: &terraform-apply
        name: terraform apply
        script:
          - terraform init -input=false
          - terraform apply -input=false --auto-approve

# パイプライン設定
pipelines:
  # プルリクエストによって実行されるパイプライン
  pull-requests:
    '**': # 任意のブランチからのPRが対象
      - step: *terraform-plan

  # ブランチの更新によって実行されるパイプライン
  branches:
    master:
      - step: *terraform-plan
      - step:
          <<: *terraform-apply
          # terraform applyは手動で実行する
          trigger: manual

2020年5月3日增設：已刪除將環境變數寫入文件的處理（詳見下文）。

也许不需要太多的解释，但是通过上述的流程设置可以实现以下目标：

マージ元ブランチの更新によってもトリガーされる

masterブランチの更新によってトリガーされるパイプラインによって、 terraform plan 及び terraform apply を順番に実行する

terraform apply のステップには trigger: manual を指定しているので、パイプラインの画面から手動で「Run」ボタンを押して実行します

通过这样的流程，你可以使用Git对基础设施代码进行管理，使用拉取请求进行更改审查，并通过CI / CD应用。在后续的“演示”部分中，我们将介绍其实际运行方式和工作流程。

关于GCP的认证设置（5/3编辑）

使用已创建的服务帐户密钥进行以下两个验证：

terraform-provider-googleによる認証

在每个规范中，指定Service Account Key文件路径的环境变量略有不同，但共同使用GOOGLE_CREDENTIALS是可行的。

对于这个问题，我一直误以为只能指定路径名，直到我试了一下，发现也可以直接将JSON文件内容设置为值，跟提供者设置一样，并没有问题。因此，我改变了上面的仓库变量设置，并简化了bitbucket-pipelines.yml的管道设置。

请参阅:

https://www.terraform.io/docs/providers/google/guides/provider_reference.html#full-reference

如果要在任何分支更新时执行terraform plan，

比如，如果您通过更改以上的YAML文件中的 pipelines: 部分，可以在除了master分支之外的其他分支上运行terraform plan操作。

# :
#（ここまでは上のYAMLと同じ）

# パイプライン設定
pipelines:
  branches:
    '**':
      - step: *terraform-plan
    master:
      - step: *terraform-plan
      - step:
          <<: *terraform-apply
          trigger: manual

当主分支(master)更新时的行为与先前相同。

根据分支的使用风格，我认为这种方式也很方便。

参考文档

YAML アンカー – アトラシアン製品ドキュメント

演示: 基于GitOps的基础设施持续集成/持续交付

我们将查看在使用上述示例（拉取请求驱动）的bitbucket-pipelines.yml配置的情况下，基础设施CI/CD工作流程会是什么样子。

0. 准备好了

除了之前提到的预备工作和设置步骤外，还进行以下操作：

リポジトリの「CHAT NOTIFICATIONS」設定により、Slack通知を有効にしています

5/3补充：关于示威活动中管道设置的差异

情况没有变化，但为了谨慎起见，我会做个注记。

我已经在5/3更改了仓库变量，并简化了bitbucket-pipelines.yml。
在以下的演示中，有两点不同：

-bitbucket-pipelines.ymlのアンカー &terraform-plan, &terraform-apply それぞれで定義したscriptの先頭に以下の2行がある

         script:
+          - echo "${GOOGLE_CREDENTIALS_DATA}" > service-account-key.json
+          - export GOOGLE_APPLICATION_CREDENTIALS=service-account-key.json
           - terraform init -input=false
           :

创建主题分支并推送代码更改

因为这段代码存在错误，所以接下来的流水线将失败。

将分支推送到 Bitbucket。

% git checkout -b topic/add-test-sa
% $EDITOR main.tf
% git diff
diff --git a/main.tf b/main.tf
index b6bb61a..d5c0613 100644
--- a/main.tf
+++ b/main.tf
@@ -31,3 +31,7 @@ resource "google_project_iam_member" "sa_terraform" {
   role    = "roles/owner"
   member  = "serviceAccount:${google_service_account.terraform.email}"
 }
+
+resource "google_service_account" "test" {
+  account_id = "test"
+}
% git add .
% git commit -m "Add test service account"
% git push origin topic/add-test-sa

由于除了主分支外，没有在其他分支上设置触发器，因此在此处将不会执行流水线。

2. 创建一个拉取请求

在Bitbucket界面上创建拉取请求。

根据在 bitbucket-pipelines.yml 中设置的 pull-requests 触发器，将执行 terraform plan 的流水线。

3. 检查构建结果（失败）

在Slack上收到了构建结果的通知。

点击「Pipeline #37」的链接，查看构建日志。

我们发现了google_service_account.test.account_id验证错误的情况。

4. 修改代码并重新推送

修改google_service_account.test.account_id并重新推送分支。

% $EDITOR main.tf
% git diff
diff --git a/main.tf b/main.tf
index d5c0613..fd9a3ec 100644
--- a/main.tf
+++ b/main.tf
@@ -33,5 +33,5 @@ resource "google_project_iam_member" "sa_terraform" {
 }

 resource "google_service_account" "test" {
-  account_id = "test"
+  account_id = "test01"
 }
% git add .
% git commit -m "Fix test service account id"
% git push origin topic/add-test-sa