Google CloudでインフラCI/CDを実現する

はじめに
Google CloudのCI/CDツール
手順
まとめ

はじめに

前回の記事では、手動でコマンドを実行しTerraformで仮想マシンを構築しました。

クラウドの構築をInfrastructure as Code(IaC)で実現する

https://www.tdi.co.jp/miso/terraform-iac

Infrastructure as Code(IaC)とはInfrastructure as Code(IaC)をご存じでしょうか︖変化の激しいビジネス環境に対応できる開発体制はもちろん、ソフトウェアやインフラにも柔軟かつ迅速な提供が求められています。その中で柔軟かつ迅速にインフラを提供するため、近年Infrastructure as Code(以下、IaC)の必要性が⾼まってきています。IaCとは、サーバーやネットワークをはじめとしたインフラの構成をプログラムのようにコード化し、構築や管理を⾃動化する⼿法のことです。IaCを実現するための構成管理ツール(IaCツール、クラウドリソ...

MISO

今回は手動実行から抜け出すために、Google Cloudを使用してインフラCI/CDを実現します。

Infrastructure as Codeは、文字通りソースコードからインフラを構築する技術となるので、ソースコードの管理が必要です。ソースコードを管理するリポジトリツールを用いれば、ブランチへのpushをトリガーとしてソースコードを実行する CI/CD パイプラインを構築できます。インフラCI/CDをとりいれると、設定変更やパッチ適用が必要になった場合に、元のソースコードを修正し、バージョン管理リポジトリにプッシュすることで、自動でインフラを更新できます。

Google CloudのCI/CDツール

Cloud Build

CI/CDを実現するツールは様々ありますが、Google CloudでCI/CDを実現できるCloud Buildを紹介します。Google Cloud でビルド、テスト、デプロイを実行するサービスです。Cloud Build は、さまざまなリポジトリやクラウドストレージからソースコードをインポートし、仕様に合わせてビルドが実行されることで、Docker コンテナや Java アーカイブなどのアーティファクトを生成できます。

手順

①前準備

最初にインフラの設定が記述されたコードを、管理するリポジトリを設定します。コンソール画面から検索し、Cloud Source Repositoriesに移動します。

コンソール右上にある、リポジトリを追加からリポジトリを作成していきます。

今回はGithubなどの既存のリポジトリからミラーリングしないため、新しいリポジトリを作成で進めます。

次に、リポジトリ名を入力しプロジェクト名を選択し作成します。

リポジトリにソースコードを追加していきます。今回はローカルのGitリポジトリからpushします。pushするソースコードは下記のようになっています。

.
├── README.md
├── ci
│   ├── terraform_apply.sh
│   └── terraform_plan.sh
├── cloudbuild.yaml
└── terraform
    └── main.tf
    └── backend.tf

├── README.md

├── ci

│ ├── terraform_apply.sh

│ └── terraform_plan.sh

├── cloudbuild.yaml

└── terraform

└── main.tf

└── backend.tf

terraform_apply.sh

＃!/bin/bash

cd terraform

WORKSPACE=prd

terraform init -backend-config="prefix=${WORKSPACE}" -reconfigure

if [ ! $(terraform workspace list | grep ${WORKSPACE}) ]; then
  terraform workspace new ${WORKSPACE}
fi
terraform workspace select ${WORKSPACE}

echo 'terraform apply'
terraform apply -auto-approve -parallelism=50

＃!/bin/bash

cd terraform

WORKSPACE=prd

terraform init -backend-config="prefix=${WORKSPACE}" -reconfigure

if [ ! $(terraform workspace list | grep ${WORKSPACE}) ]; then

terraform workspace new ${WORKSPACE}

terraform workspace select ${WORKSPACE}

echo 'terraform apply'

terraform apply -auto-approve -parallelism=50

terraform_plan.sh

＃!/bin/bash

cd terraform

WORKSPACE=prd

terraform init -backend-config="prefix=${WORKSPACE}" -reconfigure

if [ ! $(terraform workspace list | grep ${WORKSPACE}) ]; then
  terraform workspace new ${WORKSPACE}
fi
terraform workspace select ${WORKSPACE}

echo 'terraform plan'
terraform plan -parallelism=50

＃!/bin/bash

cd terraform

WORKSPACE=prd

terraform init -backend-config="prefix=${WORKSPACE}" -reconfigure

if [ ! $(terraform workspace list | grep ${WORKSPACE}) ]; then

terraform workspace new ${WORKSPACE}

terraform workspace select ${WORKSPACE}

echo 'terraform plan'

terraform plan -parallelism=50

main.tf

Google Compute Engineを起動させます。

provider "google" {
  project = "プロジェクト名"
}

resource "google_compute_instance" "default"{
    name = "インスタンス名"
    machine_type = "e2-medium"
    zone = "asia-northeast1-b"
 
    tags = ["demo"]
 
    boot_disk {
    initialize_params {
      image = "debian-10-buster-v20220719"
    }
  }
    network_interface {
    network = "default"
    access_config {}
  }
  
}

provider "google" {

project = "プロジェクト名"

}

resource "google_compute_instance" "default"{

name = "インスタンス名"

machine_type = "e2-medium"

zone = "asia-northeast1-b"

tags = ["demo"]

boot_disk {

initialize_params {

image = "debian-10-buster-v20220719"

}

network_interface {

network = "default"

access_config {}

}

backend.tf

Terraformではリソースを作成や変更したときに、stateというインフラの状態を管理するファイルを作成します。そのstateファイルは、個人で使う分にはローカルに保存しておいても問題ないのですが、複数人で使用する場合、共有フォルダを作成してどこかで管理する必要が出てきます。その共有フォルダの指定を行うために、このbackendというものがあります。今回はGoogle CloudのCloud Storageで管理するので、バケット名を指定します。

terraform {
  backend "gcs" {
    bucket = "一意なバケット名"
    prefix = "terraform/state"
  }
}

terraform {

backend "gcs" {

bucket = "一意なバケット名"

prefix = "terraform/state"

}

cloudbuild.yaml

Cloud Buildでビルドを開始するために使用できるビルド構成ファイルです。ファイルの内容としては、利用したいコマンドを1つずつ書いていくようなイメージです。

substitutions:
  _TERRAFORM_VERSION_: 0.12.10
steps:
  - id: 'tf plan'
    name: 'hashicorp/terraform:${_TERRAFORM_VERSION_}'
    entrypoint: 'sh'
    args: ['./ci/terraform_plan.sh']
  - id: 'tf apply'
    name: 'hashicorp/terraform:${_TERRAFORM_VERSION_}'
    entrypoint: 'sh'
    args: ['./ci/terraform_apply.sh']

substitutions:

_TERRAFORM_VERSION_: 0.12.10

steps:

- id: 'tf plan'

name: 'hashicorp/terraform:${_TERRAFORM_VERSION_}'

entrypoint: 'sh'

args: ['./ci/terraform_plan.sh']

- id: 'tf apply'

name: 'hashicorp/terraform:${_TERRAFORM_VERSION_}'

entrypoint: 'sh'

args: ['./ci/terraform_apply.sh']

②Cloud Buildの設定

Cloud Buildは、サーバーレスCI/CDプラットフォームです。Cloud Buildを使用して、Cloud Source Repositoriesに変更があった際に変更を検知して自動的にビルドしデプロイします。まずCloud Buildのリソース画面から先ほど作成した、リポジトリにトリガーを作成します。

トリガーの作成画面で、必要項目を入力していきます。注意点としては、Cloud Source Repositoriesに変更があった際に変更を検知して自動的にビルドしデプロイしたいのでブランチにpushするを選択します。どのリポジトリを対象にするか選択します。

リポジトリは先ほど作成したものを選択します。ブランチは今回はmasterを選択しますが本来は、開発環境や本番環境など分けて使用します。

③cloudbuild.yamlについて

次に、Cloud Buildでビルドを開始するために使用できるビルド構成ファイルを選択します。

作成するボタンを押下すると、トリガーが作成されコンソールに表示されます。

実行前には、backend.tfで指定したバケットを事前に作成する必要があります。

トリガーが作成されコンソールから、トリガーを実行しリソースが作成されるか確認します。

実行が正常に完了したことを確認します。

設定ファイルに記載した、Google Compute Engineが作成されているか確認します。

設定ファイルを変更し、リソースに反映されるか確認します。今回はインスタンスタイプを変更しています。インスタンスタイプ変更には、一度インスタンスを停止する必要があるのでdesired_status = “TERMINATED”を記載して停止させています。

provider "google" {
  project = "プロジェクト名"
}

resource "google_compute_instance" "default"{
    name = "インスタンス名"
    machine_type = "f1-micro"
    zone = "asia-northeast1-b"

    desired_status = "TERMINATED"
 
    tags = ["demo"]
 
    boot_disk {
    initialize_params {
      image = "debian-10-buster-v20220719"
    }
  }
    network_interface {
    network = "default"
    access_config {}
  }
  
}

provider "google" {

project = "プロジェクト名"

}

resource "google_compute_instance" "default"{

name = "インスタンス名"

machine_type = "f1-micro"

zone = "asia-northeast1-b"

desired_status = "TERMINATED"

tags = ["demo"]

boot_disk {

initialize_params {

image = "debian-10-buster-v20220719"

}

network_interface {

network = "default"

access_config {}

}

変更をpushして、Cloud Source Repositoriesに反映させます。

作成したリポジトリに、変更が加えられたタイミングでトリガーが起動していることがわかります。これにより、自動的にリソースに変更が反映されます。

設定ファイルを変更した通りに、Google Compute Engineも変更されていることがわかります。

まとめ

インフラコードをリポジトリで管理することで、環境変更作業する前に、作業実施前後の差分をコードで客観的にレビュー可能となり、インフラ運用における人的ミス混入が最小化されると感じています。

執筆者プロフィール

Teraoka Naoyatdi　クラウドビジネス推進室: AWS、Azure、GCPの全てを極めることを目標に日々奮闘しております。
新しい技術が好きで、常に情報収集しています。皆様に有益な情報を届けられるようにしていきたいです。

この執筆者の最新記事

この執筆者の記事一覧

Pick UP!2024.05.13Google CloudでインフラCI/CDを実現する
Pick UP!2023.04.27クラウドの構築をInfrastructure as Code(IaC)で実現する

Pocket