デベロッパー プラットフォームとコンテナ化されたアプリケーションを運用するには、さまざまな管理タスクを継続的に行う必要があります。このようなタスクには、テンプレートからの新しいアプリケーションの作成、新しいデベロッパー グループによるデベロッパー プラットフォームの使用の承認、容量のニーズの計画、ランタイムの問題のデバッグなどがあります。
運用は自動化することも、手動で実行することもできます。
一般的な自動運用
このブループリントは、単純な API タイプである Webhook トリガーの形式での最も一般的なタスクの自動化を示します。トリガーは、ソース コントロール リポジトリの 1 つで生じた Webhook イベントに自動的に接続されます。デベロッパー プラットフォーム開発者は、他のトリガーを接続できます。通常は、デベロッパー プラットフォーム開発者がデベロッパー ポータルを作成します。デベロッパー ポータルは、フォームの送信時に Webhook トリガーを呼び出す単純なウェブフォームにすることができます。
次の表に、ブループリントが Webhook トリガーを使用して自動化する一般的なタスクを示します。タスクの頻度はさまざまな要因に左右されるため、ここでの説明は一例にすぎません。タスクは必ずしも正確な間隔で繰り返されるわけではありません。
| タスク | ユーザー | 説明 | タスクの頻度 |
|---|---|---|---|
テナントを追加する。 |
デベロッパー プラットフォーム管理者 |
管理者がデベロッパー ポータルでフォームを送信します。新しいテナント フォーム フィールドには、テナント名とチームメンバーが含まれます。自動トリガーにより、新しいテナントのリソースが作成されます。 |
年に数回 |
既存のアプリケーション テンプレートに基づいてアプリケーションを追加する。 |
アプリケーション デベロッパー |
デベロッパーがデベロッパー ポータルでフォームを送信します。新しいアプリケーション フォーム フィールドには、テナント名、アプリケーション名、ベース アプリケーション テンプレートが含まれます。自動トリガーにより、新しいアプリケーションのリソースが作成されます。 |
年に数回 |
アプリケーションのソースコードの変更をビルドして、開発環境にデプロイする。 |
アプリケーション デベロッパー |
デベロッパーがソースコードを編集し、ローカルでコードを実行してテストしてから、コードを commit します。ブループリントはローカル デベロッパー ワークフローには関与しませんが、Skaffold ツールはローカルビルド ステップをサポートします。 |
アプリケーションごとに 1 日に数回 |
アプリケーションの YAML 構成の変更を開発環境にデプロイする。YAML 構成の変更の例として、デプロイ リソースの CPU の追加があります。 |
アプリケーション デベロッパー |
デベロッパーがアプリケーション構成を編集して、変更を commit します。 |
アプリケーションごとに週に数回 |
アプリケーション インフラストラクチャの変更を開発環境にデプロイする。アプリケーション インフラストラクチャは、アプリケーションのプロジェクト内のクラウド リソースです。変更の例として、AlloyDB for PostgreSQL インスタンスの CPU 数の追加があります。 |
アプリケーション デベロッパー |
デベロッパーがアプリケーション リソースの Terraform プロジェクトを編集して、変更を commit します。デベロッパーがデベロッパー ポータルでフォームを送信します。自動トリガーにより、プランが開始され、パイプラインが適用されます。 |
年に何度も |
アプリケーションの変更を開発環境から非本番環境に（または非本番環境から本番環境に）昇格させる。アプリケーションの変更には、新しいアプリケーション イメージやアプリケーションの YAML 構成の変更が含まれる場合があります。 |
アプリケーション オペレーター |
オペレーターが、変更を開発環境ブランチから非本番環境ブランチに（または非本番環境ブランチから本番環境ブランチに）マージします。オペレーターはロールアウトを監督します。 |
アプリケーションごとに週に数回 |
アプリケーション インフラストラクチャの変更を開発環境から非本番環境に（または非本番環境から本番環境に）昇格させる。 |
アプリケーション オペレーター |
オペレーターが、選択した変更を開発環境ブランチから非本番環境ブランチに（または非本番環境ブランチから本番環境ブランチに）マージします。オペレーターはロールアウトを監督します。 |
アプリケーションごとに四半期に数回 |
一般的な手動運用
デベロッパー プラットフォームの運用の中には、本質的にあまり構造化されておらず、デベロッパー プラットフォームでの自動化を使用しないものもあります。このブループリントに基づいて独自のハンドブックを作成し、Google Cloud コンソールでこれらのタスクを実行できます。
次の表に、これらの自動化されていないタスクを示します。タスクの頻度はさまざまな要因に左右されるため、ここでの説明は一例にすぎません。タスクは必ずしも正確な間隔で繰り返されるわけではありません。
| タスク | ユーザー | 説明 | タスクの頻度 |
|---|---|---|---|
新しいアプリケーション テンプレートを定義する。 |
デベロッパー プラットフォーム開発者 |
デベロッパーは、ブループリント テンプレートに基づくアプリケーション テンプレートを変更するか、テンプレートを新しい言語に移植します。 |
年に数回 |
開発環境でサービスのランタイム エラーを調査する。 |
アプリケーション デベロッパー |
デベロッパーは、Google Cloud コンソールのログ エクスプローラと Metrics Explorer を使用して、テナントとアプリケーションのエラーログ、モニタリング指標、時系列データを確認します。 |
月に数回 |
本番環境または非本番環境でサービスのランタイム エラーを調査する。 |
アプリケーション オペレーター |
オペレーターは、Google Cloud コンソールのログ エクスプローラと Metrics Explorer を使用して、テナントとアプリケーションのエラーログ、モニタリング指標、時系列データを確認します。 |
月に数回 |
ビルドエラーを調査する。 |
アプリケーション デベロッパー |
デベロッパーは、ビルド ステータスやログなどの Cloud Build の履歴を Google Cloud コンソールに表示します。 |
週に数回 |
開発環境でデプロイエラーを調査する。 |
アプリケーション デベロッパー |
デベロッパーは、Google Cloud コンソールに Cloud Deploy のリリースとロールアウトの履歴を表示して、デプロイ試行の成功ステータスとログ（エラーを含む）を確認します。 |
月に数回 |
非本番環境と本番環境でデプロイエラーを調査する。 |
アプリケーション オペレーター |
オペレーターは、Google Cloud コンソールに Cloud Deploy のリリースとロールアウトの履歴を表示して、デプロイ試行の成功ステータスとログ（エラーログを含む）を確認します。 |
月に数回 |
クラスタに接続して GKE の問題をデバッグする。 |
デベロッパー プラットフォーム管理者 |
管理者は、Connect Gateway を使用して限定公開クラスタに接続します。スケジュールされていない Pod などの一般的な問題については、管理者が Google Cloud コンソールで一般的な問題（スケジュールされていない Pod など）に関する情報を確認できます。 |
月に数回 |
容量を計画し、費用を最適化する。 |
デベロッパー プラットフォーム管理者 |
管理者は、Google Cloud コンソールでスコープまたは Namespace ごとに集計された GKE リソースの使用率を確認します。 |
毎月繰り返すタスクとしてスケジュールされる。 |
ノードプールをサイズ変更、追加、削除する。 |
デベロッパー プラットフォーム管理者 |
管理者は、必要に応じて IaC を編集し、アプリケーションを再デプロイします。 |
容量の計画に応じて行われる。 |
セキュリティ対策を確認する。 |
デベロッパー プラットフォーム管理者 |
管理者は、GKE のセキュリティ ポスチャー ダッシュボードを使用して、脆弱性と標準の遵守を確認します。 |
毎月繰り返すタスクとしてスケジュールされる。 |
クラスタのシステム ソフトウェア バージョン（Kubernetes のバージョンなど）をアップグレードする。 |
デベロッパー プラットフォーム管理者 |
管理者は GKE のメンテナンスの時間枠と除外を使用して、計画された時間でのアップグレードのみ許可します。管理者は、まず開発環境で開いているアップグレード ウィンドウを使用します。アップグレードの状態を評価した後、非本番環境をアップグレードしてから本番環境をアップグレードします。 |
四半期ごとに繰り返すタスクとしてスケジュールされる。 |
クラスタの重要なセキュリティ アップデートをインストールする。 |
なし |
GKE により自動的に行われます。 |
年に数回 |
リージョン フェイルオーバーをテストする。 |
デベロッパー プラットフォーム管理者とアプリケーション管理者 |
管理者は、必要に応じて環境のリージョン フェイルオーバーをスケジュールし、手動で開始します。 |
障害復旧演習の一環として年 1 回 |
リージョンを追加する。 |
デベロッパー プラットフォーム管理者、デベロッパー プラットフォーム開発者、アプリケーション管理者 |
デベロッパー プラットフォーム管理者は、新しいリージョンに追加の GKE クラスタをデプロイします。管理者は、アプリケーション テンプレートを更新して、関連する環境の新しいデプロイ ステップを追加します。次に、アプリケーション オペレーターが変更を統合して、新しいリージョンを含むデプロイ シーケンスを追加します。 |
ほとんどない |
新しいリージョンに移動する。 |
デベロッパー プラットフォーム管理者、デベロッパー プラットフォーム開発者、アプリケーション管理者 |
ユーザーがリージョンを追加するの説明に従って新しいリージョンを追加します。新しい構成をテストした後、ユーザーは古いリージョンを削除します。 |
ほとんどない |
次のステップ
- デベロッパー プラットフォームの費用とアトリビューションを管理する（このシリーズの次のドキュメント）を読む。