Zenn
🐕

WordPress ホスティング環境に CI/CD パイプラインを構築

2024/05/27に公開
WordPress
Google Cloud
CI/CD
Cloud Build
tech

はじめに

こんにちは、クラウドエース SRE 部の渡辺です。今年で社会人(エンジニア) 2 年目になりました。最近、コンテナ化した WordPress を Cloud Run にホスティングし、Continuous Integration/Continuous Delivery & Deployment（以下、CI/CD） パイプラインを組み合わせることでクラウド ネイティブな WordPress 運用環境について学びました。本記事では、自分で実装したことを整理し、CI/CD パイプラインの構築について解説していきたいと思います。

概要

本記事では、WordPress ホスティング環境に CI/CD パイプラインを構築することに重点を置いて解説します。自分が習熟のために実装したコードを例にしており、本番環境を想定した詳細なカスタマイズやセキュリティ設定は考慮していません。

以下が作成された際の全体構成図です。
全体構成図

前提

本記事の対象読者、説明すること/しないことについて記載します。

対象読者

説明すること/しないこと

説明すること

  • CI/CD パイプラインと Cloud Build の概要説明
  • Cloud Build を利用した CI/CD パイプライン構築の解説

しないこと

  • WordPress を CloudRun にホスティングする環境の構築
  • プロジェクトのセットアップや Cloud SDK のインストールなど、準備の詳細
  • 各サービスや実装コードの行ごとの詳細な解説

CI/CD パイプラインとは

CI/CD パイプラインは、ソフトウェア開発のライフサイクルを自動化して効率化する一連の手順です。"CI"（Continuous Integration、継続的インテグレーション）は、開発者が変更したコードを定期的にメイン リポジトリに統合するプロセスで、コードのビルドと自動テストが含まれます。"CD"（Continuous Deployment、継続的デプロイメント）は、テストを通過したコードを自動的に本番環境にデプロイするプロセスです。このパイプラインを利用することで、開発プロセスのスピードと品質が向上し、ヒューマン エラーが減少し、より一貫性のあるリリースが可能になります。詳細は以下のサイトをご覧ください。

Cloud Build とは

Cloud Build は、Google Cloud のサーバーレス サービスで、コードのビルド、テスト、デプロイを自動化します。GitHub などからソースコードを取り込み、Docker イメージや Java アーカイブなどのアーティファクトを生成できます。また、ビルド構成ファイルを使ってカスタム ビルドステップを定義でき、スケーラブルでセキュアなビルド環境を提供します。詳細は以下の公式ドキュメントをご覧ください。

WordPress ホスティング環境に CI/CD パイプライン構築

この章から、WordPress ホスティング環境に CI/CD パイプラインを構築する手順を解説します。構築手順は、自分が実装したコードを例に記載していきます。

以下の赤枠部分を構築します。
CI/CD パイプライン構築

事前準備

WordPress ホスティング環境に CI/CD パイプラインを構築する前に、以下の事前準備を満たしている必要があります。

  • コンテナ化した WordPress が Cloud Run にホスティングされている
  • ドメインの設定が完了している
  • WordPress に、Cloud SQL と Cloud Storage が接続されている
  • GitHub リポジトリが作成されている

まずは、以下の構成図（赤枠部）が、構築と動作ができることを確認します。具体的な構築手順については、Google Cloud Japan のカスタマー エンジニア Yuki Suwa 氏によって執筆された「Cloud Run でサーバレス WordPress を構築する」の記事がとても参考になります。

WordPress をホスティングする環境を構築

次に、WordPress をホスティングする環境が構築されていて、ドメインの設定が完了していることを確認します。ホスティングされた WordPress にアクセスし接続確認をします。以下がドメインの例と接続確認画面になります。

ドメインの設定例: wordpress.example.com
ホスティングされた WordPress にアクセス

本記事の環境では、 以下の 3 つの Cloud Storage バケットを Cloud Run にマウントして使用しました。以下の表が、それぞれのバケットの名前と用途、公開範囲になります。

名前（例） 用途 公開範囲
ca-sre-wordpress-watanabe-dev 静的ファイル保存用 インターネットに公開
ca-sre-wordpress-backet-themes-dev テーマ保存用 非公開
ca-sre-wordpress-backet-plugins-dev プラグイン保存用 非公開

最後に、GitHub リポジトリは各自で作成してください。以下がリポジトリを作成する公式ドキュメントのリンクになります。

構築手順

ここから、WordPress ホスティング環境に CI/CD パイプラインを構築する手順を解説していきます。構築の準備として、ローカル環境に以下のディレクトリ構成でファイルを作成します。

.
├── Dockerfile
└── cloudbuild.yaml

構築の流れ

大まかな流れは以下の通りです。

  1. Cloud Build 用サービス アカウントの作成
  2. Artifact Registry リポジトリの作成
  3. ビルド構成ファイルの作成
  4. Cloud Build トリガーの作成

サービス アカウントの作成

まずは、Cloud Build 用のサービス アカウントを作成します。Cloud Build は、サービス アカウントを使用してユーザーの代わりにビルドを実行します。サービス アカウントに権限を付与することで、ビルドが必要なリソースにアクセスできるようになります。以下の 5 つの権限を付与します。

  • Artifact Registry 書き込み(roles/artifactregistry.writer)
  • Cloud Run 管理者(roles/run.admin)
  • サービス アカウント ユーザー(roles/iam.serviceAccountUser)
  • ストレージ管理者(roles/storage.admin)
  • ログ書き込み者(roles/logging.logWriter)

以下の画像が、作成した Cloud Build 用サービス アカウントの画面になります。
Cloud Build 用サービス アカウント

Artifact Registry リポジトリの作成

次に、Cloud Run にデプロイするコンテナ イメージを格納するための Artifact Registry リポジトリを作成します。Artifact Registry は、Docker イメージ、npm、Python などのアーティファクトを保存、管理、配布するためのリポジトリを提供します。以下の手順でリポジトリを作成します。

コンソール画面から形式を [Docker] 、リージョンは asia-northeast1(東京) にします。その他の設定はデフォルトで作成します。

以下が作成されたリポジトリの画面になります。
Artifact Registry リポジトリ

また、事項で記載するビルド（Step1、Step2）の具体的な流れのイメージを持ってもらうために、Artifact Registry にコンテナ イメージをプッシュするステップの流れを以下のアコーディオン メニューで記載しています。参考程度にご覧ください。

コンテナ イメージを Artifact Registry にプッシュ

コンテナ イメージを Artifact Registry にプッシュ

リポジトリが作成されていることを確認したら、WordPress のコンテナ イメージを ArtifactRegistry にプッシュします。以下のステップでコンテナ イメージをビルドし、Artifact Registry にプッシュします。

ステップ 1: Dockerfile の作成
まずは、Dockerfile を用意します。

Dockerfile
# WordPressの公式イメージをベースに使用
FROM wordpress:6.5.2

ステップ 2: Docker イメージのビルド
Dockerfile があるディレクトリで以下のコマンドを実行してイメージをビルドします。

docker build -t asia-northeast1-docker.pkg.dev/ca-watanabe-ryusei-wordpress/artifact-registry-docker/wordpress:latest .

レジストリ名は以下のコンソール画面（赤枠部分）からコピーできます。

ステップ 3: Docker イメージのプッシュ
次に、ビルドしたイメージを Artifact Registry にプッシュします。

docker push asia-northeast1-docker.pkg.dev/ca-watanabe-ryusei-wordpress/artifact-registry-docker/wordpress:latest

プッシュ が完了したら、Artifact Registry にイメージが登録されていることを確認します。

ビルド構成ファイルの作成

次に、CI/CD パイプラインを構築するための ビルド構成ファイルを作成します。ビルド構成ファイルでは、Cloud Build がタスクを実行するために必要なフィールドを定義します。ビルド構成ファイルは YAML または JSON 構文で記述されます。今回は、YAML ファイルをビルド構成ファイルとして作成します。詳細については以下の公式ドキュメントを参考にしてください。

以下が、今回作成した cloudbuild.yamlの例になります。このファイルでは、3 つのステップを定義しています。

cloudbuild.yaml
cloudbuild.yaml
steps:
  # Step 1: Build the Docker image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'asia-northeast1-docker.pkg.dev/ca-watanabe-ryusei-wordpress/artifact-registry-docker/wordpress:latest', '.']

  # Step 2: Push the Docker image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'asia-northeast1-docker.pkg.dev/ca-watanabe-ryusei-wordpress/artifact-registry-docker/wordpress:latest']

  # Step 3: Deploy to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args: [
      'alpha', 'run', 'deploy', 'wordpress-cloudrun',
      '--region', 'asia-northeast1',
      '--image', 'asia-northeast1-docker.pkg.dev/ca-watanabe-ryusei-wordpress/artifact-registry-docker/wordpress:latest',
      '--execution-environment', 'gen2',
      '--port', '80',
      '--service-account', 'run-service-account',
      '--allow-unauthenticated',
      '--add-cloudsql-instances', 'ca-watanabe-ryusei-wordpress:asia-northeast1:wordpress-db',
      '--network', 'default',
      '--subnet', 'default',
      '--vpc-egress', 'private-ranges-only',
      '--add-volume', 'name=gcs-images,type=cloud-storage,bucket=ca-sre-wordpress-watanabe-dev',
      '--add-volume-mount', 'volume=gcs-images,mount-path=/var/www/html/wp-content/uploads',
      '--add-volume', 'name=gcs-themes,type=cloud-storage,bucket=ca-sre-wordpress-backet-themes-dev',
      '--add-volume-mount', 'volume=gcs-themes,mount-path=/var/www/html/wp-content/themes',
      '--add-volume', 'name=gcs-plugins,type=cloud-storage,bucket=ca-sre-wordpress-backet-plugins-dev',
      '--add-volume-mount', 'volume=gcs-plugins,mount-path=/var/www/html/wp-content/plugins',
      '--update-env-vars', 'WORDPRESS_DB_HOST=10.17.208.3',
      '--update-env-vars', 'WORDPRESS_DB_USER=wordpress-user',
      '--update-env-vars', 'WORDPRESS_DB_PASSWORD=wordpress',
      '--update-env-vars', 'WORDPRESS_DB_NAME=wordpress-db'
    ]

options:
  logging: CLOUD_LOGGING_ONLY

各フィールドname、args、entrypointついて説明します。

name

nameフィールドは、使用するビルダーイメージを指定します。ビルダー イメージとは、特定のタスク（例：Dockerイメージのビルドやプッシュ）を実行するためのコンテナ イメージのことです。Cloud Build では、公式のビルダーイメージが提供されており、それらを指定することで特定のタスクを実行できます。
(例:gcr.io/cloud-builders/docker、gcr.io/google.com/cloudsdktool/cloud-sdk)

args

args フィールドは、ビルダー イメージ内で実行されるコマンドの引数を指定します。args はリスト形式で指定され、各引数は個別のリスト要素として記述します。これにより、ビルダー イメージ内で実行されるコマンドを柔軟に制御できます。

entrypoint

entrypoint フィールドは、ビルダー イメージ内で実行されるデフォルトのコマンドを上書きするために使用します。通常、ビルダー イメージにはデフォルトのエントリー ポイントが設定されていますが、entrypoint を指定することでそれを上書きできます。

上記の YAML ファイルにより、WordPress の Docker イメージをビルド、Artifact Registry にプッシュ、最終的に Cloud Run にデプロイするプロセスが自動化されます。

以下は、YAML ファイルが正常に動作することを確認するために Cloud Run サービス名を変更した例です。参考程度にご覧ください。

YAML ファイルの動作確認

YAML ファイルの動作確認

YAML ファイルが正常に作成されて動作することを確認します。以下のコマンドをローカルのターミナルで実行します。

gcloud builds submit --config cloudbuild.yaml .

実行結果

上記の結果から YAML ファイルが正常に作成されていることを確認できました。

Cloud Build のトリガー作成

最後に、Cloud Build トリガーを作成します。Cloud Build の「トリガー」は、ソースコードのリポジトリに変更が発生したときに自動的にビルドプロセスを開始するためのルールまたは指示のことです。今回は、GitHub の リポジトリのmainブランチにマージされたときに、自動的に CloudBuild が実行されるようトリガーを作成します。

リポジトリを接続

まずは、GitHub リポジトリを Cloud Build に接続します。[第 1 世代] を 選択します。

次にソースコード管理プロバイダの選択と認証を行います。リージョンは [グローバル] を選択します。ソースコード管理プロバイダは、[GitHub] を選択します。[続行] をクリックすると自動で認証画面に遷移します。

認証後に事前に作成した [GitHub リポジトリ] を選択し、リポジトリを接続します。

以下が接続されたリポジトリの画面になります。
接続したリポジトリの画面

トリガーの作成

トリガーを作成していきます。

トリガー名は、任意に記入します。トリガーを呼び出すイベントは [ブランチに Push する] を選択します。ソースは、接続したリポジトリを選択して、ブランチをmainに設定します。

構成は、[Cloud Build 構成ファイル（yaml または json）] を選択します。構成ファイルの場所は、Git リポジトリ内の Cloud Build 構成ファイルのパスを指定します。最後に、作成した Cloud Build 用のサービス アカウントを選択します。

以上で、Cloud Build トリガーの作成が完了です。以下が作成したトリガーの画面になります。
作成したトリガー

CI/CD パイプラインの動作確認

構築は以上で完了です。GitHub リポジトリにコードをプッシュして、Cloud Build トリガーが作動することを確認します。以下のコマンドをローカルのターミナルで実行します。動作確認の例して、main ブランチ以外にプッシュしてプルリクエストを作成し、マージすることでトリガーを作動させます。
まずは、以下のコマンドを実行して、feature/build ブランチを作成します。

git checkout -b feature/build # 新しいブランチ（任意）を作成して切り替え

次に、以下のコマンドを実行して、feature/build ブランチにプッシュします。

git add .
git commit -m "Build Test"　# 任意のコメント
git push origin feature/build # mainブランチ以外

その後、GitHub リポジトリのfeature/buildブランチからmainブランチにプルリクエストを作成し、マージします。

以下がビルドの結果です。作成したトリガー（wordpress-cicd-test）が正常に作動していることを確認します。
トリガーによるビルドの結果

まとめ

この記事では、自分が実装したコードを例に WordPress ホスティング環境に CI/CD パイプラインを構築するについて記載しました。この記事を参考に、Google Cloud における CI/CD パイプラインのイメージをつかんでいただければと思います。また自分の感想になりますが、自分で WordPress の運用環境と CI/CD パイプラインを構築することでそれぞれのサービスの理解と CI/CD についての理解がより深まりました。この記事を通じて、皆さんにも何かしらのヒントや参考になることがあれば幸いです。

最後まで読んでいただきありがとうございました。

Discussion