Amazon Web Services ブログ
Amazon EKS クラスターのプロビジョニングメカニズムとして AWS Proton を使用する
この記事は Using AWS Proton as a provisioning mechanism for Amazon EKS clusters (記事公開日: 2022 年 6 月 1 日) を翻訳したものです。
AWS のお客様は、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターをデプロイするために、EKS コンソール、eksctl CLI、AWS Cloud Development Kit (AWS CDK)、 または、他のいくつかのオプションを使用することができます。多くの場合、運用に精通した 1 人のユーザー (またはチーム) が、これらのオプションのいずれかを選択して、Kubernetes クラスターを定義、デプロイ、使用、そして維持し続けます。
多くの組織では、上記のデプロイサイクルを、いわゆるプラットフォームエンジニアリングチーム (クラスターの標準化に責任を持つチーム) と開発者チーム (アプリケーションに責任を持つチーム) の間で共有するモデルを導入し始めています。
もしあなたが、開発者に Kubernetes クラスターのセルフサービスプロビジョニングを提供しながら、デプロイの標準化とガバナンスを作成するチームの一員であるなら、この記事は役立ちます。
この記事では、Amazon EKS クラスターのベンディングマシーン (自動発行機) として AWS Proton を使用するメリットと仕組みについて説明します。これは、インフラストラクチャの構成 (この場合は EKS クラスター) を一元的に定義する方法と考えてください、それをプラットフォームエンジニアリングチームが、一元的に保証され、一貫性があり、標準化された構成としてセルフサービスでデプロイすするために使用できます。この GitHub リポジトリでは、プロビジョニング構成を作成して、最初のクラスターをデプロイする方法を、ステップごとに詳しく説明しています。
このソリューションは、EKS クラスターをデプロイするための全てが構成されている AWS 監修のテンプレートセットである EKS Blueprints がベースになっています。これらのブループリントは、Terraform と CDK を使用したデプロイに利用でき、Proton のプロビジョニングメカニズムとは別に使用することもできます。
AWS Proton とは何ですか? どのように機能しますか?
AWS Proton は、セルフサービスによるデプロイのためのインフラストラクチャテンプレートを定義、払い出し、維持することで、プラットフォームエンジニアがイノベーションを加速するためのマネージドサービスです。Proton を利用することで、お客様は、一元化されたテンプレートを標準化して、セキュリティ、コスト、およびコンプライアンスの目標を達成できます。Proton は、プラットフォームエンジニアの影響力をセルフサービスモデルによりスケールアップし、その結果、アプリケーションのライフサイクル全体で、開発およびデプロイプロセスの速度が向上します。
ほとんどの場合、お客様は、次の 2 つの主要なタイプのリソースを許可するテンプレートを作成して Proton を使用しています。
- 「環境」と呼ばれる共有のインフラコンポーネント (VPCなど)
- 「サービス」と呼ばれるアプリケーション専用のインフラコンポーネント (Fargate上で動作するアプリケーションなど)
典型的な Proton のコンテキストでは、プラットフォームエンジニアの役割は、環境とサービスの両方のテンプレートを定義して、共有の環境をプロビジョニングすることです。開発者の役割は、既存の環境の上にアプリケーション用のサービスをプロビジョニングすることです。
Proton の仕組みは、プロビジョニング時に指定された入力を使って、Infrastructure-as-Code (IaC) テンプレートをレンダリングすることです。これを行うために、Proton は、テンプレートの定義に使用される IaC 言語に関する知識を持っている必要があります。現在、Proton は CloudFormation と Terraform で動作します。
この記事と付随する GitHub リポジトリでは、リファレンス実装として EKS Blueprints for Terraform を使用してクラスターをプロビジョニングする方法について詳しく説明します。CloudFormation での使用方法については、この Template bundles ページで詳しく説明されています。
プラットフォームエンジニアと開発者にどのようなメリットがありますか?
この時点で、なぜ EKS クラスターの払い出しメカニズムとして Proton を導入する必要があるのか、疑問に思われるかもしれません。これらの理由のいくつかを取り上げます。
プラットフォーム エンジニアにとってのメリットは次のとおりです。
- 会社の要件や標準をベースに、十分に精査された Kubernetes クラスターを払い出すメカニズム
- 社内ユーザーのリクエストを契機に Kubernetes クラスターをプロビジョニングするといったループから抜け出すことが可能
- クラスターテンプレートの新バージョンが利用可能になったことを AWS コンソールを介してユーザーに伝える機能
- Kubernetes クラスターの設定が必要なときに強制的に更新する機能 (コンプライアンス上の理由など)
- デプロイされたクラスターとその設定について、Proton が追跡している情報を一元的に表示する機能
開発者にとってのメリットは次のとおりです。
- AWS コンソール、または API を使用して、完全な機能と完全なコンプライアンスを備えた EKS クラスターをセルフサービスでプロビジョニングする機能
- 複雑な構成のクラスターのデプロイをワンクリックで行うことが可能
- Kubernetes の適切な基本設定のベストプラクティスを活用する機能
- ニーズに応じてクラスターを構成する機能 (サイズ、バージョン、アドオン、その他)
- Kubernetes クラスターのアップグレードエクスペリエンスの簡素化
- クラスターに接続して作業を開始するために必要なパラメータを取得するためのセルフサービス型のワークフロー
Proton 自体はクラスター管理およびアップグレードソリューションではないことに注意してください。Proton は、一貫性があり、制御され、使いやすい IaC テンプレートを保証する方法を提供します。利用者は、アップグレード戦略を決定し、テンプレートがどのように機能するかを評価する必要があります。特にこのソリューションの文脈では、EKS Blueprints が Kubernetes の新しいバージョンへのアップグレードをどのようにサポートするか、また、任意の時点でどのバージョンをサポートするかを確認することをお勧めします。
Proton は、プラットフォームエンジニアが開発者のフィードバックを取り込み、テンプレートを更新するという好循環を生み出します。プラットフォームエンジニアは、製品のオーナーであり、エンジニアでもあるため、人気のある需要をベースにテンプレートに何を取り込むかの優先順位を決めることができます。このソリューションにより、プラットフォームエンジニアと開発者がより簡単に、より速く、よりスムーズに連携し、共同作業を行うことができるようになります。
Kubernetes クラスターを払い出すための Proton 構成の概要
このソリューションの本質を十分に理解する前に、一歩下がって、いくつかのコンテキストを理解する必要があります。よくあるパターンの 1 つは、複数のアプリケーション開発者が Kubernetes アプリケーションを Proton サービスとしてデプロイできる EKS クラスターを共通の Proton 環境としてデプロイすることでしょう。
しかし、多くのお客様は、Proton をクラスター全体のベンディングマシーンとして機能させ、開発者が、幅広い Kubernetes エコシステムの中で柔軟に利用できるようにすることに、より興味を示していると話しています (開発者が事前定義された Proton アプリケーションのサービステンプレートを Proton API 経由で使用することとは対照的に) 。
プラットフォームチームが環境を作成、管理するのではなく、開発者が直接必要に応じて環境を作成するため、この記事で提案するソリューションでは、開発者が EKS クラスターを Proton 環境としてデプロイできることを前提にしています。繰り返しになりますが、これは従来の Proton パターンでは例外になりますが、Kubernetes の文脈では有用なモデルだと考えています。
これらの概念をより明確にするために、以下の図は Proton を使用した 2 つの異なるアプローチを示しています。上段は、従来のシナリオで、Proton 環境は、VPC と Amazon Elastic Container Service (Amazon ECS) クラスターで構成され、プラットフォームエンジニアによりプロビジョニングされています。Proton サービスは、Amazon ECS サービス (Application Load Balancer と独自のデプロイパイプライン付き) が構成され、開発者によりプロビジョニングされています。下段は、VPC と EKS クラスターで構成される Proton 環境を開発者がプロビジョニングした場合の具体的な解決策です。
上の図では、誰が何をデプロイするかのみを示していることに注意してください。誰がこれらの環境とサービスをデプロイしたかについては関係なく、プラットフォーム エンジニアリング チームは関連するすべてのテンプレートを所有していることを覚えておくことが重要です。これにより、ベスト プラクティスが組み込まれ、適度な制御が保証されます。
はじめるには
前述のとおり、上記の EKS クラスターをベンディングマシーンとして実装するための手順を含む専用の GitHub リポジトリを用意しました。このリポジトリは、やり方に重点を置いているので、この記事の残りの部分では、これから行うことについての追加のコンテキストを提供します。
GitHub リポジトリは、Proton と Terraform の統合がどのように機能するかについて、機能の豊かさとそれに関連する複雑さの一部を隠蔽しています。このリポジトリには、EKS Blueprints をベースにクラスターを払い出すためのサンプルである Proton テンプレートと、基本的な Terraform パイプラインを模倣するサンプルである GitHub Actions ワークフローの両方が含まれています。このリポジトリを出発点として、テンプレートをカスタマイズし、GitHub Actions を削除して、チームの要件に合わせて調整できます。
このソリューションを本番環境で使用する場合は、統合の詳細をよく理解しておくことを強くお勧めします。その良い方法として、AWS Proton Terraform Templates と AWS Proton Self-Managed Provisioning の記事を読むことです。さらに、EKS Blueprints のワークフローに慣れてください。結局のところ、Proton はファサードに過ぎず、作成できるテンプレートの性質は、Terraform モジュールが提供する柔軟性と同じくらい良いものだからです。
Proton を EKS クラスターのベンディングマシーンとして使用すると、開発者は次のような直感的なインターフェイスを使用してクラスターをプロビジョニングできます。
クラスターがデプロイされると、Proton は kubectl
を介してクラスターに接続するために必要なすべての情報を Outputs
から提供します。上記の例では示されていませんが、開発者がプロビジョニングされたクラスター上でアプリケーションを保守するために GitOps を好む場合、プラットフォームエンジニアリングチームは、GitOps モジュールを有効にすることができます。
また、Proton は、新しい Kubernetes のバージョンを含んだテンプレートを更新すると、以下に示すように、ユーザーが既存のクラスターを新しいバージョンにアップグレードできるようにします。
このソリューションでは、開発者が標準の Kubernetes API を介してクラスターを利用できることに加え、EKS コンソールで新しい Kubernetes リソースビューを活用することができます。最近リリースされたこの機能は、クラスター内部にデプロイされたすべての Kubernetes リソースを探索、およびナビゲートするための、すぐに使えるマネージドなグラフィカルユーザーインターフェースを提供します。
宣伝は十分です。これで GitHub リポジトリに移動して、自身の AWS アカウントで試してみる準備ができました!
まとめ
この短い記事では、EKS クラスターを払い出すメカニズムとして Proton を使用することの価値について説明しました。これにより、プラットフォームエンジニアは、承認済みのテンプレートを定義でき、開発者によるセルフサービスが可能になります。このソリューションは、ガバナンスを改善し、プラットフォームエンジニアリングチームの知識を広げ、セルフサービスによるクラスターのプロビジョニングとガイド付きのメンテナンスによって Kubernetes を使用する開発者のアジリティを向上させることができます。このソリューションがあなたのチームにどのように役立つかについての概要を説明するだけでなく、ベンディングマシーンの実装例についてステップバイステップのワークフローを GitHub リポジトリを通じて提供しました。最後になりましたが、このソリューションを可能にする Proton と Terraform の統合について、さらに深く掘り下げるために、他の記事へのリンクを多数提供しました。
翻訳はプロフェッショナルサービスの高橋たまが担当しました。原文はこちらです。