Google Cloud | MISO https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com 未来を創造するITのミソ Mon, 13 May 2024 07:49:27 +0000 ja hourly 1 https://wordpress.org/?v=6.7.2 https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/wp-content/uploads/2017/09/tdi_300-300-300x280.png Google Cloud | MISO https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com 32 32 Google CloudでインフラCI/CDを実現する https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/google-cloud-infrastructure-ci-cd Mon, 13 May 2024 06:40:35 +0000 https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/?p=17495 はじめに 前回の記事では、手動でコマンドを実行しTerraformで仮想マシンを構築しました。   今回は手動実行から抜け出すために、Google Cloudを使用してインフラCI/CDを実現します。 Infr…

The post Google CloudでインフラCI/CDを実現する first appeared on MISO.]]>
はじめに
前回の記事では、手動でコマンドを実行しTerraformで仮想マシンを構築しました。

 

今回は手動実行から抜け出すために、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

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

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

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 {}
  }

}

backend.tf

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

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']

②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 {}
  }

}

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

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

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

まとめ

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

The post Google CloudでインフラCI/CDを実現する first appeared on MISO.]]>