使用基础设施管理器在Google Cloud中创建项目

2 年 ago
新, 韵
2 minutes

首先

2023年9月，Google Cloud推出了能够在其托管服务上运行的Terraform基础设施管理器！

 

以前我在Terraform Cloud上写了一篇关于如何创建Google Cloud项目的文章，现在我尝试使用Infrastructure Manager做同样的事情。

 

建构过程

我根据公式文档的快速入门进行了构建。

 

我制定了验证要求如下：

    • Terraform テンプレートは CloudStorage に置く

 

    作成するのは Google Cloud プロジェクトのみ、請求先アカウントの紐づけはしない

激活API

从命令或控制台激活基础设施管理器 API。

 

设置服务帐户

准备一个用于Infrastructure Manager的服务账号。然后给该账号分配Cloud Infrastructure Manager代理角色（roles/config.agent），以及创建所需资源的角色（本例中是roles/resourcemanager.projectCreator），该角色由Terraform模板指定。关于如何分配roles/resourcemanager.projectCreator角色的方法，请参考上一篇文章。

 

准备CloudStorage存储桶。

准备一个 CloudStorage 存储桶来放置 Terraform 模板。
为了对模板文件进行版本控制，创建一个启用对象版本控制的存储桶。

准备Terraform模板。

由于模板样本已经公开，因此我参考了这个。

 

我根据上次的模板文件创建了3个文件。
与上次相比，有一个不同之处是

    • Terraform Cloud ワークスペースの指定の削除

 

    • 認証情報の指定の削除

 

    変数宣言とデフォルト値の設定を variable.tf 内で実施
resource "google_project" "new_project" {
  name       = "<Project Name>"
  project_id = "<Priject ID>"
  org_id     = var.org_id
}

terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "4.51.0"
    }
  }
}

variable "org_id" {
  type      = string
  default   = "<Organization ID>"
}

在之前创建的桶中创建一个任意的文件夹（本例中为 src 文件夹），并将这三个文件放在那里。

基础设施经理的实施

从Cloud Shell执行以下命令。

gcloud infra-manager deployments apply projects/<Project Name>/locations/asia-east1/deployments/my-depolyment \
    --service-account projects/<Project Name>/serviceAccounts/<Service Account Name> \
    --gcs-source gs://<Bucket>/src

目前可在指令中选择的区域有三个，分别是亚太东部1（asia-east1），欧洲西部1（europe-west1）和美国中部1（us-central1）。因此，我们选择了亚太东部1（asia-east1）作为本次的指定区域。

 

确认部署完成后的状态。

要查看部署执行的状态和创建的资源，需要运行命令。
顺便提一下，基础设施管理器的元数据被放置在名为 gs://PROJECT_ID-LOCATION-blueprint-config 的存储桶中，但是即使是部署执行用户也没有访问权限，无法确认有哪些文件。

 

确认部署执行状态

指令

gcloud infra-manager deployments describe projects/<Project Name>/locations/asia-east1/deployments/my-depolyment

结果

createTime: '2023-12-04T06:07:43.895650003Z'
latestRevision: projects/<Project Name>locations/asia-east1/deployments/my-depolyment/revisions/r-0
lockState: UNLOCKED
name: projects/<Project Name>/locations/asia-east1/deployments/my-depolyment
serviceAccount: projects/<Project Name>/serviceAccounts/<Service Account Name>
state: ACTIVE
stateDetail: revision "projects/<Project Name>/locations/asia-east1/deployments/my-depolyment/revisions/r-0"
  applied
terraformBlueprint:
  gcsSource: gs://<Bucket>/src
updateTime: '2023-12-04T06:08:45.675848249Z'

确认已创建的资源

命令

gcloud infra-manager resources list --revision=projects/<Project Name>/locations/asia-east1/deployments/my-depolyment/revisions/r-0

结果 (jié guǒ)

NAME: project-<任意の文字列>
STATE: RECONCILED

结果的 NAME 与 Terraform 模板中指定的名称不同。通过 Infrastructure Manager 创建 BigQuery 数据集并确认 NAME，结果不是在 Terraform 模板中指定的名称，而是 bigquery-dataset-<任意的字符串>。因此，这里显示的应该是用于内部管理的名称。

对比一下Terraform Cloud（给出感想）

如果是个人开发或者临时使用，Infrastructure Manager似乎是不错的选择；如果是团队开发或长期运营，Terraform Cloud似乎更加合适。这就是我的感想。

我认为选择基础设施经理更好的原因。

不再需要管理服务账户的密钥！

在上一篇文章中，我们讨论了发放服务帐户密钥并将其用于Terraform模板和变量。但是，如果使用基础设施管理器，只需要授予服务帐户所需的角色即可。这样可以避免信息泄露的风险和密钥轮换的烦恼。

由于Google Cloud是专属的，所以模板和协作变得简单易用。

由於基礎設施經理在Google Cloud中是封閉的，因此模板更傾向於以提供者為中心的簡單形式。
此外，由於不再需要進行高負載服務之間的協同設定，所以從使用開始到部署完成都更加順暢。

我认为Terraform Cloud的优点是

可以使用GitHub的私有存储库

基础设施经理的模板配置选项包括云存储、Github的公共代码库和本地机器共三种。
就我个人而言，我希望使用Github来管理模板，因为我想通过团队来管理模板。然而，我不能将包含公司数据的模板文件放在公共代码库中。
因此，相对于能使用Github私有代码库的Terraform Cloud，更适合我的使用场景。

可以以隐密的方式进行变量管理。

项目创建的提供者会指定组织ID，但直接在模板文件中写入ID可能会引起安全隐患，因此希望能以类似Terraform Cloud的方式进行保密，确保信息不会轻易被看到。（当然，有关将需要保密的信息放置在Terraform中的利弊也存在争议。）

希望以上的内容。如果能对某人有所帮助，我将感到幸运。

✖
广告
将在 10 秒后关闭
bannerAds