Google Kubernetes Engine（GKE）のワークロードに自動デプロイを構成できます。
このページでは、ワークロードにシンプルな継続的インテグレーション / 継続的デリバリー（CI / CD）パイプラインを設定する方法について説明します。リポジトリに変更を push すると、Cloud Build がコンテナを自動的にビルドして GKE クラスタにデプロイします。
自動デプロイの仕組み
GKE に単一コンテナ イメージを参照するワークロードがある場合、このワークロードに自動デプロイを構成できます。自動デプロイを構成すると、コードの変更がリポジトリにチェックインされるたびに、アプリケーションが再ビルドされ、デプロイされます。
自動デプロイでは、ワークロードを YAML ファイルとして定義し、この YAML ファイルをリポジトリに保存します（ベスト プラクティスに準拠）。GKE はこの目的で使用できる YAML を生成します。
YAML ファイルを使用する方法には、次の 2 つがあります。
ワークロードを定義する YAML ファイルがない場合は、生成された YAML ファイルを使用できます。YAML ファイルをリポジトリに保存します。Cloud Build は毎回、これを使用してワークロードをデプロイします。
ワークロードを定義する YAML がすでにある場合は、リポジトリ内の場所を GKE に指定できます。リポジトリの YAML ファイルと推奨の YAML ファイルを比較することで、正しいワークロードが適切な方法でデプロイされることを確認できます。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API が有効になっていることを確認します。 Google Kubernetes Engine API の有効化
- Google Cloud CLI がインストールされていることを確認します。
- 次のいずれかの方法で、プロジェクトにデフォルトの Google Cloud CLI 設定をセットアップします。
- プロジェクトのデフォルトの設定全般を確認する場合は、
gcloud initを使用します。 gcloud configを使用して、プロジェクト ID、ゾーン、リージョンを個別に設定します。-
gcloud initを実行して、次の操作を行います。gcloud init
リモート サーバーで SSH を使用している場合は、
--console-onlyフラグを指定して、コマンドがブラウザを起動しないようにします。gcloud init --console-only
- Google Cloud アカウントを使用できるように、gcloud CLI の承認手順を行います。
- 新しい構成を作成するか、既存の構成を選択します。
- Google Cloud プロジェクトを選択します。
- デフォルトの Compute Engine ゾーンを選択します。
- デフォルトの Compute Engine リージョンを選択します。
- デフォルトのプロジェクト ID を設定します。
gcloud config set project PROJECT_ID
- デフォルトの Compute Engine リージョン（例:
us-central1）を設定します。gcloud config set compute/region COMPUTE_REGION
- デフォルトの Compute Engine ゾーン（例:
us-central1-c）を設定します。gcloud config set compute/zone COMPUTE_ZONE
gcloudを最新バージョンに更新します。gcloud components update
gcloud init
gcloud config
デフォルトの場所を設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。
次の追加の API を有効にします。
Cloud Build
Cloud Source Repositories
Artifact Registry
要件
自動デプロイには次の要件があります。
自動デプロイは、単一のコンテナ イメージを指定する
Deploymentタイプのワークロードでのみ使用できます。マルチコンテナ ワークロードと他のワークロード タイプ（ReplicaSetなど）はサポートされていません。ソースコード リポジトリには、イメージのビルドに使用する Dockerfile が必要です。
このリポジトリは、次のいずれかのプロダクトでホストできます。
- Cloud Source Repositories
- GitHub
- Bitbucket
GitHub または Bitbucket を使用する場合は、リポジトリに Google Cloud へのアクセス権を付与する必要があります。
コンテナ イメージを GKE クラスタと同じ Google Cloud プロジェクトの Artifact Registry に保存します。イメージを Artifact Registry に配置し、少なくとも 1 回はデプロイする必要があります。これにより、ワークロードが GKE で処理されます。
自動デプロイの作成
自動デプロイを作成するには、次の手順を行います。
Google Cloud コンソールの [ワークロード] ページに移動します。
ワークロード リストで、変更する Deployment の名前をクリックします。
list [アクション] > [自動デプロイ] の順にクリックします。
[デプロイの自動化] ペインで、次の手順を行います。
[ソース リポジトリ] で、ソースコード リポジトリを選択します。
[リポジトリ プロバイダ] プルダウン リストで、リポジトリのプロバイダを選択します。
自動デプロイは次のソース管理ホストに対応しています。
- Cloud Source Repositories
- GitHub
Bitbucket
GitHub または Bitbucket を使用する場合は、ユーザー名とパスワードで認証を行います。
[リポジトリ] プルダウン リストから、Deployment のソースコードを含むリポジトリの名前を選択します。
[続行] をクリックします。
[ビルド構成] で、ビルド構成情報を指定します。
- ビルド元のブランチの名前か、ブランチに一致する正規表現（RegExp2）を入力します。デフォルトのブランチは
masterです。このブランチに push すると、Cloud Build がアプリケーションをビルドします。 - [Dockerfile のディレクトリ] を相対パスで入力します。
[Dockerfile の名前] を入力します。
[続行] をクリックします。
- ビルド元のブランチの名前か、ブランチに一致する正規表現（RegExp2）を入力します。デフォルトのブランチは
[自動デプロイの構成] で、構成 YAML ファイルの場所を指定します。
YAML ファイルが自動的に生成されます。これにより、YAML ファイルをリポジトリに格納できます。
[Google 推奨の YAML を表示] をクリックすると、生成された YAML が表示されます。
独自の YAML ファイルがある場合はそれと比較し、結果に基づいて更新します。
それ以外の場合は、新しいファイルを作成し、生成された YAML を入力します。これにより、デプロイされたワークロードと現在実行中のワークロードが一致します。ファイルには任意の名前を付けることができますが、拡張子は
.yamlまたは.ymlにする必要があります。YAML ファイルがあるディレクトリへの相対パスを指定します。
指定したディレクトリに複数の YAML ファイルがある場合、GKE はそのすべてを使用します。
[設定] をクリックして、自動デプロイの構成を完了します。
Cloud Build サービス アカウントに権限を付与するように求められる場合があります。この権限は必須です。
次のステップ
選択したワークロードの自動デプロイを設定すると、リポジトリの選択したブランチに push された後にコンテナ イメージをビルドする Cloud Build トリガーが作成されます。Cloud Build は、元のイメージがデプロイされているクラスタにワークロードの新しいリビジョンをデプロイします。
ワークロードの詳細については、[デプロイの詳細] ページ（[変更履歴] タブ）をご覧ください。