コンテンツに移動
Containers & Kubernetes

新たに導入された Application Manager により、Google Kubernetes Engine で GitOps を実現

2020年3月4日
https://storage.googleapis.com/gweb-cloudblog-publish/images/Google_Cloud_Kubernetes.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2020 年 2 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。 

Kubernetes はコンテナ化されたアプリケーションを管理するための事実上の標準となっています。しかし、デベロッパーやアプリ オペレータは Kubernetes アプリケーションのオーサリング、リリース、管理など、エンドツーエンドの Kubernetes ライフサイクル管理に苦労することがよくあります。

そこでこのたび、アプリケーションのライフサイクルと構成の管理を簡素化するため、Application Manager をリリースいたします。これは Google Kubernetes Engine(GKE)のアドオンとして提供される、アプリケーション配信ソリューションです。現在ベータ版で提供中の Application Manager を使用すると、デベロッパーは開発から本番環境アプリケーションまでの配信フローを簡単に作成しながら、リリース構成を管理するための Google のベストプラクティスを組み込むことができます。また、会社のポリシーに沿ってアプリケーションを GKE で効率的かつ安全に実行できるため、アプリケーションのモダナイゼーションの目標を達成できます。

Kubernetes アプリケーションのライフサイクルに対応

Kubernetes アプリケーションのライフサイクルは、オーサリング、リリース、管理の 3 つの主要な段階で構成されています。オーサリングでは、アプリケーションのソースコードとアプリ固有の Kubernetes 構成の記述を行います。リリースでは、コードや構成に変更を加え、その変更を異なるリリース環境に安全にデプロイします。管理フェーズでは、本番環境での大規模なアプリケーションの運用化を行います。現時点では、このような段階について明確に定義した標準が存在しないため、運用開始に役立つベストプラクティスや推奨事項についてお問い合わせいただくことがよくあります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Lifecycle_of_Kubernetes_application.max-2000x2000.jpg

Kubernetes アプリケーションのライフサイクル


さらに、Kubernetes アプリケーション構成は、長くて複雑であるために大規模な管理が困難になる場合があります。特に、テスト、ステージング、本番のリリース環境全体にデプロイされたアプリケーションでは、複数の Git リポジトリに構成が重複して保存される場合があります。1 つの構成に対する変更は、他の構成にも複製する必要があるため、人為的エラーが生じる可能性があります。

Application Manager は GitOps の原則を採用しており、Git リポジトリを活用した宣言型構成管理が可能です。そのため、変更を環境にデプロイする前に変更の監査と確認を実施できます。また、推奨される Git リポジトリ構造を自動的にスキャフォールディングして適用し、Kubernetes ネイティブの構成管理ツールである Kustomize を使ってテンプレートなしでカスタマイズすることも可能です。

Application Manager はクラスタ アドオンとして GKE クラスタ内で実行され、次のタスクを行います。

●Git リポジトリ(Git ブランチ、タグ、コミット内のもの)から Kubernetes マニフェストを pull し、クラスタ内のアプリケーションとしてそのマニフェストをデプロイします。

●デプロイされたアプリケーションに関するメタデータ(バージョン、変更履歴、正常性など)を報告し、Google Cloud Console でアプリケーションを可視化します。

Application Manager によるアプリケーションのリリース

ここからは、Git リポジトリのスキャフォールディング、アプリケーション リリース環境の定義、クラスタへのデプロイなど、Application Manager を使用してアプリケーションをリリースまたはデプロイする方法について詳しく説明します。Application Manager のコマンドライン インターフェースである appctl で簡単なコマンドを実行することにより、こうしたすべてのタスクを行えます。

ステージング環境と本番環境の両方に「Bookstore」アプリをリリースする場合のワークフロー例を次に示します。

最初に以下のコマンドを実行します。

appctl init bookstore --app-config-

repo=github.com/$USER_OR_ORG/bookstore 

これで 2 つのリモート Git リポジトリが作成されます。1 つ目はアプリケーション リポジトリで、アプリケーション構成ファイルを kustomize 形式で保存し、構成管理を簡易化します。2 つ目はデプロイ リポジトリで、自動生成され完全にレンダリングされた構成ファイルを、クラスタにデプロイするファイルの信頼できるソースとして保存します。

Git リポジトリが初期化された後、appctl env add staging --

cluster=$MY_STAGING_CLUSTERを実行して Boookstore アプリにステージング環境を追加し、本番環境でも同じことを行います。この時点で、アプリケーション リポジトリは次のようになります。

読み込んでいます...

この例では、kustomize を使用して、環境固有の構成の違いを管理しています。kustomize を使用すると、基本構成の上にオーバーレイをパッチすることで、異なる環境向けに明確にカスタマイズされた Kubernetes 構成を Kubernetes API リソース ファイルのみを使って宣言的に管理できます。

アプリケーションをステージング環境にリリースする準備ができたら、アプリケーション リポジトリで git tag を使用してアプリケーション バージョンを作成してから、appctl prepare staging を実行します。これにより、アプリケーション リポジトリのタグ付きバージョンから供給された構成を自動的に生成し、デプロイ リポジトリの staging ブランチに push して管理者が確認できるようにします。

この Google 推奨のリポジトリ構造により、Application Manager はアプリケーション リポジトリ内の保守しやすい kustomize 構成と、自動生成されたデプロイメント リポジトリ(確認しやすい唯一の正確な情報源)を明確に分離します。また、この 2 つのリポジトリが発散するのを防ぎます。

供給された構成への commit が確認され、デプロイ リポジトリにマージされたら、appctl apply staging を実行してステージング環境のクラスタにデプロイします。

ステージング環境から本番環境へのプロモーションは、appctl apply prod --from-env staging で簡単に実行できます。エラーが発生した場合は、appctl apply staging --from-tag=OLD_VERSION_TAG を実行すれば簡単にロールバックできます。

さらに、この appctl ワークフローをスクリプトまたはパイプラインで実行すれば、自動化と合理化が可能です。

すべての Kubernetes アプリに対応した Application Manager

このたびの Application Manager の導入により、Google が推奨するシンプルな宣言型アプローチを使用して、開発環境から本番環境へのアプリケーション配信フローを簡単に作成できるようになりました。また、Google Cloud Marketplace で調達した Kubernetes アプリケーションをシームレスに更新していただけるよう、Google Cloud ではパートナーと連携してそうしたアプリケーションの自動更新とロールバックを可能にしています。詳しくはこちらをご覧ください。Application Manager の詳細については、デモ動画をご覧ください。使用を開始する準備ができたら、こちらのチュートリアルの手順を行ってください。

- プロダクト マネージャー Palak Bhatia、ソフトウェア エンジニア Janet Kuo
投稿先