AWS 入門ブログリレー 2024 〜AWS Proton編〜

AWS Protonについて2024年時点の情報をまとめてみました。AWSサービス入門記事として是非ご活用下さい。
特集

トクヤマシュン

2024.05.09

こんにちは。AWS事業本部トクヤマシュンです。

当エントリは弊社メンバーによる『AWS 入門ブログリレー 2024』の39日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今回のテーマは『AWS Proton』です。

AWS Protonとは？

AWS Protonはサーバレスおよびコンテナベースで動作するアプリケーションのIaC(Infrastructure as Code)のプロビジョニングとデプロイの自動化を行うためのサービスです。 ジャンルとしてはCloudFormationやElastic Beanstalkといったプロビジョニング系のサービスとなっています。

ProtonではLambdaやECSを使ったサービスの構成をテンプレート化してバージョン管理し、それらを構築することができます。さらにそれらのサービス上で動作するアプリのCI/CDパイプラインも作ることができます。
イメージとしては、CloudFormationとCodePipelineを統合的に管理できるサービスといったところでしょうか。 ただしこれはProtonの機能の一部でしかなく、思ったより色々なことができますので、これからひととおり説明した上で実際に動かしてみようと思います。

Protonの動作イメージ

動作イメージは下図の通りです。

出典：AWS Proton とは?

Protonは特有の概念が多いので、最初は理解に時間かかるかもしれません。 はじめにいくつかの前提を説明し、その上で動作の流れをお伝えします。

前提

登場人物のロール

Protonでは登場人物のロールとして下記の2つを想定しています。

  • Administrators（管理者）
    • IaCを用いたAWSインフラ部分の管理・構築担当者
    • とくにAWSインフラの標準化やバージョン管理をしたい！と考える管理者に向いてるサービスです
  • Developers（開発者）
    • LambdaやECSといったサービス上で動作するアプリケーションの開発者
    • AWSインフラに詳しくない開発者の方でも、詳細な設定を意識することなくインフラを利用し、開発したアプリを稼働させることが可能です

Protonのコンセプトは、こうした管理者と開発者の境界線を明確にし、それぞれの範囲のプロビジョニングとデプロイに集中することができるようにする、というものです。

環境（Environments)とサービス（Service）のプロビジョニング

ProtonでプロビジョニングするAWSリソースは環境（Environments)とサービス（Service）に大別されます。

  • 環境
    • アプリケーションを動作させるコンピューターリソース以外のもの
    • VPC、ECSクラスター、ELB、API Gatesway、Cloud Mapなど
  • サービス
    • アプリケーションが動作させるコンピューターリソースやデプロイパイプラインに関するもの
    • ECSサービス、ECSタスク定義、Lambda、ECR、CodePipelineなど

ユーザーガイドのAWS Proton の働きでは「環境」は管理者が、「サービス」は管理者と開発者の双方がこうしたサービスの構築・更新を行うものとして記述されていますが、実際は自組織の実情に当てはめてこれらのスコープを決定いただければと思います。
AWSリソースを環境・サービスのどちらで定義するのか？についてもあくまでも一例で絶対ではないですので、管理者がやりやすいように決めてしまって良いかとおもいます。

出典：AWS Proton の働き

こうした環境やサービスをプロビジョニングする方法は3つあります。

  • AWSマネージドプロビジョニング
    • ProtonからCloudFormationを用いてプロビジョニングする
    • CloudFormationテンプレートのみ対応
  • セルフマネージドプロビジョニング
    • Protonから指定したGitリポジトリにプロビジョニング対象のTerraformテンプレートファイルのpull requestを送る
    • Protonで実施するのはここまで
    • pull requestをマージした後は、作業者自身で別途terraform applyを行なってプロビジョニングする
    • Terraformテンプレートのみ対応
  • CodeBuildプロビジョニング
    • ProtonからCodeBuildジョブを実行することでプロビジョニングする
    • CDKに対応可能（ビルドプロジェクト上でコマンドから実行可能なIaCであればなんでも使える）

自身の組織で採用しているIaC言語に応じてご選択いただくのが良いかと思います。

テンプレートバンドル

環境やサービスはIaCで定義された「テンプレート」をそれぞれ持ち、バージョン管理されます。 このテンプレートは下記のようないくつかのファイルを持った「テンプレートバンドル」として構成されます。

  • IaCファイル
    • CloudFormation、Terraform、CDKなどを用いたプロビジョニング設定を記載したファイル
    • Proton用に記載する場合は少しお作法があり、専用の記述が必要
      • CloudFormationの場合にはパラメータをJinja形式で指定する必要がある、など
  • マニフェストファイル
    • IaCファイル名やプロビジョニング方法などを記載するファイル
  • スキーマファイル
    • IaCファイルへの入力パラメーターを定義したファイル

Protonではバージョン管理されたテンプレートをもとに、環境やサービスの実体を構築します。

動作の流れ

それでは、Protonの動作の一連の流れを説明します。

動作イメージの画像を再掲します。

出典：AWS Proton とは?

① 管理者は環境テンプレートバンドルをProtonに登録することで環境テンプレートを作成します。 環境テンプレートバンドルは手動もしくは同期設定を用いて登録が可能です。

  • 手動
    • S3バケットにテンプレートバンドル一式をZip化したものをアップロード
  • 同期設定
    • Gitリポジトリを同期させて登録
    • GitHub、GitHub Enterprise Server、BitBucketが利用可能

基本的にはGitリポジトリを使う同期設定を推奨します。

② 環境テンプレートから実際の環境を作成します。 例のように同じテンプレートを用いたとしても、入力パラメーターを環境ごとに変更することで、異なった設定を持つ複数の環境を構築することが可能です。

③ 管理者はサービステンプレートバンドルをProtonに登録することでサービステンプレートを作成します。 ①と同様に手動登録・同期設定が可能です。

⑥ （これだけ順番前後しますが、分かりやすさのためにここで説明します）
管理者もしくは開発者はサービステンプレートから実際のサービスを作成します。 このサービスはECSやLambdaといったコンピューティングリソースだけでなく、CI/CDパイプラインをオプションで含むことができます。

④ 開発者はソースコードをアップロードしてCI/CDパイプラインを起動します。 このアップロードも手動登録と同期設定が可能ですが、①・③と同様に同期設定を推奨します。

⑤ CI/CDパイプラインはアプリのソースコードからビルド・デプロイを行い環境上で動作しているサービスに反映します。

以上が大まかなProtonの動作の流れとなります。

Protonでコンテナベースで動くアプリケーションを構築してみる

ここからはデモとして、Protonをマネジメントコンソール経由で実際に動かしてみます。
AWS Management Console の開始方法にチュートリアルが書いてあり、サンプルテンプレートも提供されていますので、試してみます。
今回は下記のような方式を取ることとなります。

  • プロビジョニング方法
    • AWSマネージド(CloudFormation利用)
  • 環境テンプレートバンドル、サービステンプレートバンドル、アプリケーションソースコード
    • GitHubから同期連携
  • CI/CDパイプライン
    • あり

構成図

今回作成する構成は下記の通りです。

出典：aws-proton-cloudformation-sample-templates/service-templates /backend-fargate-svc/

ECSサービスにはアプリケーションとしてnginx Webサーバーを起動します。 ECSタスクがパブリックサブネットにあったりなど一部よろしくない設定があったり、デモでは使わないCloudMapなどが含まれていますが、サンプルテンプレートを流用するためと割り切ることとします。

では、つぎから構築を進めていきます。

GitHubリポジトリのFolk準備

まず、自身のGitHubアカウントを持っていない方は作成します。
参考：GitHub でのアカウントの作成

つぎに、自身のGitHubアカウントにサンプルテンプレートバンドルとサンプルソースコードを準備します。 下記リポジトリがAWS公式から提供されていますので、両方とも自身のGitHubリポジトリにFolkしておきます。

参考：リポジトリをフォークする

ここでは簡単にコードの内容を説明します。詳細は直接リポジトリにアクセスしてコードをご確認ください。

環境テンプレートバンドル

aws-proton-cloudformation-sample-templates/environment-templates/fargate-envが今回利用する環境テンプレートバンドルです、

v1フォルダ配下に今回作成する環境バージョンのコードが一通り記載されています。 簡単に説明します。

  • infrastructure
    • cloudformation.yaml
      • 環境テンプレートでプロビジョニングする対象を定義したCloudFormationテンプレート
      • VPCやSubnet、ECS Clusterなどのリソースを定義
      • パラメータの付与方法がJinja形式になっているのが特徴。
    • manifest.yaml
      • template_language: cloudformation とすることでAWSマネージド型プロビジョニングを利用することを宣言。
      • 他の記載はテンプレート名やレンダリングエンジンにJinjaを使うこと
  • schema
    • schema.yaml
      • 今回は入力として利用するCIDR範囲の書式を指定。

サービステンプレートバンドル

aws-proton-cloudformation-sample-templates/service-templates/backend-fargate-svcが今回利用する環境テンプレートバンドルです、

v1フォルダ配下に今回作成する環境バージョンのコードが一通り記載されています。 いくつか抜粋して簡単に説明します。

  • instance_infrastructure
    • cloudformation.yaml
      • サービステンプレートのうち、サービスインスタンス（アプリを動作させt実態）をプロビジョニングする対象を定義したCloudFormationテンプレート
      • ECS Serviceやタスク定義などを定義
  • pipeline_infrastructure
    • cloudformation.yaml
      • サービステンプレートのうち、パイプラインをプロビジョニングする対象を定義したCloudFormationテンプレート
      • ECRやCodeBuild、CodePipelineを定義
  • schema
    • schema.yaml
      • サービスインスタンス、パイプラインの入力となる書式を定義

アプリケーションソースコード

aws-proton-sample-services/ecs-backend が今回利用するアプリケーションのサンプルコードです。 いくつか抜粋して簡単に説明します。

  • app.py
    • 今回のアプリのコード。ngingx Webサーバ上で動作する。
    • HTTPレスポンスとして{"response": "Hello from backend-svc. Time: Monday, May 02 2022, 15:26:06"}のような値を返す
  • Dockerfile
    • パイプラインのビルドステージで使われる

今回利用するサンプルコードの簡単な説明は以上です。

AWS CodeConnectionsの作成

自身のGitHubリポジトリにFolkできたら、AWS CodeConnections(旧CodeStar connection)からそれぞれのリポジトリに接続できるようにします。

下記を参考に、GitHubへの接続を作成してください。手順ではすべてのリポジトリへのアクセスを許可していますが、必要に応じて許可するリポジトリは絞ってください。（今回Folkした2つのリポジトリは許可してください。）

参考：GitHubへの接続を作成する

環境テンプレート・サービステンプレートの作成

つぎに、環境テンプレートとサービステンプレートを作成します。 AWS Protonのトップページから、「使用を開始する」ボタンをクリックします。

ステップ1はProtonの紹介ページとなってます。 専用の用語がいくつかあるので、あらためて説明してくれるのは嬉しいですね。 確認したら「次へ」ボタンをクリックします。

ステップ2は初期セットアップの画面です。 ここでは先ほど作成したCodeConnectios接続を選択します。

次に、Protonがパイプラインをプロビジョニングするために使われるIAMサービスロールを作成します。 ここでは新しいサービスロールを作成するよう設定し、ロールに管理特権を付与するチェックボックスも有効にします。

ここまでできれば「次へ」ボタンをクリックします。

ステップ3は環境テンプレートの作成画面です。

今回はバンドルをGitHubから取得するため、Gitからテンプレートバンドルを同期を設定します。

テンプレート定義リポジトリでは、はじめてGitリポジトリとProtonをリンクさせるため、「別のGitリポジトリをリンク」をクリックして、先ほどFolkしたGitHubリポジトリ（aws-proton-cloudformation-sample-templates）に接続するようCodeConnection、リポジトリ、ブランチを設定します。

あとは適切な環境テンプレート名と表示名を設定し、「次へ」ボタンをクリックします。

最後のステップ4はサービステンプレートの作成画面です。 内容としては環境テンプレートとほぼ同じで、サービステンプレートのためのバンドルをGitHubから取得するための設定をしていきます。

CodeConnection、リポジトリ、ブランチ、サービステンプレート名、表示名を設定します。

パイプラインの定義に関しては、今回のサンプルテンプレートはCI/CDパイプラインを含んでいるもののため、「〜含まれています。」の方を選択します。

ここまで終われば「完了」ボタンをクリックします。

すると、Proton開始方法のサマリー画面に遷移します。 初期セットアップ、環境テンプレート作成、サービステンプレートの作成ステータスが緑色になれば、完了です。

次からは環境を作成していきます。 「環境を作成する」ボタンをクリックします。

環境の作成

テンプレートの作成が終わったので、ここからは実際に環境やサービスを作成します。

まずは環境の作成からです。 「環境を作成する」ボタンをクリックします。

ステップ1では環境テンプレートを選択します。 先ほど作成したテンプレートを選択し、「設定」ボタンをクリックします。

ステップ2では環境の基本となる設定を行います。 今回はCloudFormtaionテンプレートを利用するため、プロビジョニング方法は「AWS マネージド型プロビジョニング」を設定します。

展開アカウントは「この AWS アカウント」を設定します。

環境の詳細はユニークな環境名を設定します。

AWS マネージド型プロビジョニングロールでは、既存のサービスロールを設定し、初期セットアップで作成したProton用のIAMサービスロールを設定します。

他はオプションで今回は不要となるので、設定を省略し。「次へ」ボタンをクリックします。

ステップ3ではカスタム設定を構成します。 ここでは、環境作成する時の入力となる値を設定します。 今回はサンプルテンプレートに設定されているデフォルト値を使うこととし、なにも変更せず「次へ」ボタンをクリックします。

ステップ4はレビュー画面となっています。 確認して問題なければ「作成」ボタンをクリックします。

しばらく待って、ステータスが「Succeeded」となればデプロイ完了です。 ProtonによってCloudFormationのスタックが構築され、実際に設定した環境が構築されます。 Protonの画面からCloudFormationに設定されたOutputなども確認できるのは便利ですね。

サービスの作成

次に、サービステンプレートからサービスを作成します。 サービスの画面から「サービスを作成」をクリックします。

ステップ1ではサービステンプレートを指定します。 先ほど作成したテンプレートを指定します。

ステップ2ではサービスの設定を行います。 サービス名はユニークなサービス名を設定します。 アプリケーションソースコードのリポジトリはこれまでとは違い、aws-proton-sample-servicesリポジトリを指定する必要があります。

「別のGitリポジトリをリンク」を指定して、ポジトリプロバイダとしてGitHubを選択し、 最初に作成したCodeStar接続、リポジトリにはaws-proton-sample-services、ブランチはmainを指定します。 タグはオプションなので割愛して、「次へ」ボタンをクリックします。

ステップ3ではサービスインスタンスを設定します。

サービス定義ソースは「Protonでサービスを直接定義」を選択し、コンソールからサービスのECSタスクのサイズなどを直接設定していきます。 なお、「Gitからサービスを同期」を設定することで、サービスインスタンスの設定をGit上の「proton-ops」ファイルを使って自動設定・更新することも可能です。

サービスインスタンスの設定箇所ではユニークなサービスインスタンス名と先ほど作成した環境を指定し、他はサービスインスタンスの入力パラメータとしてサービステンプレートに定義されているデフォルト値を設定します。

Pipelineの入力もデフォルト値を設定して、「次へ」ボタンをクリックします。

ステップ4ではレビューをおこない、問題なければ作成ボタンをクリックします。

しばらく待つと、サービスステータスがActive、パイプラインのプロビジョニングステータスがSucceeded　となります。

こうなれば構築は完了です。 パイプラインは実行中なので、パイプラインタブを確認します。 しばらく待つと、Source-Build-Deployとステージが進み、サービスがデプロイされます。

こうなればデプロイ完了です。 では、デプロイ結果を確認してみます。

ECSの画面から対象のECSタスク→ネットワークタブにアクセスすると、パブリックIPアドレスが確認できますので、その横にある「open address」をクリックします。

次のように表示され、想定していたアプリケーションが動作していることを確認できます。

ここまでで、protonによる構築の一通りの流れを確認することができました。

パイプラインの更新

最後に、パイプラインを更新してみます。

次のようにaws-proton-sample-servicesリポジトリのecs-backend/app.py16行目のHelloをByeに書き換えます、

app.py

from flask import Flask
import json
import time

app = Flask(__name__)


@app.route("/ping", methods=["GET"])
def healthcheck():
    return "ok"


@app.route("/", methods=["GET"])
def inc():
    data = {
        "response": "Bye from backend-svc. Time: {}".format(
            time.strftime("%A, %B %d %Y, %H:%M:%S")
        )
    }
    response = app.response_class(
        response=json.dumps(data), status=200, mimetype="application/json"
    )
    return response


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80)

書き換えたらgit add、git commit、git pushを行ない、GitHub上のコードを更新します。

git pushをトリガーに、パイプラインが動作し始めます。これもprotonのサービス画面上から確認できます。

しばらく待つとパイプラインが完了まで進みます。

この状態で先ほどと同様にタスクにアクセスすると、更新後のByeの文字がレスポンスとして返されました。

このように、protonで作成されたパイプラインをGitHubリポジトリの更新を契機として実行することができました。

リソースの削除

最後に、サービス・環境の順に削除を行います。 それぞれ、Protonのコンソール画面のアクションから削除をすることができます。

サービスの削除

環境の削除

サービスや環境を削除してもサービステンプレートや環境テンプレートは削除されません。 テンプレートは別にお金がかかるわけではないですが、今回は削除しておきます。

環境テンプレートの削除

サービステンプレートの削除

以上でデモは完了です。

最後に

以上、『AWS 入門ブログリレー 2024』の39日目のエントリ『AWS Proton』編でした。

実際の開発現場に導入するかどうかは開発・運用組織の構成や必要なガバナンス・スキルセットに応じて決定してもらえればと思います。

個人的には、検証環境をサクッと作ったり削除したりするのにも便利だな、と感じています。 独自の用語がありますが、いざ使ってみるとそれほど難しくなく使えました。ご興味をお持ちの方は、まず触ってみてはいかがでしょうか？

次回、5/10(金)は弊社あしざわによる「AWS CloudTrail編」の予定です！

スキルアップ|初心者向け|書評|デベキャン|AWS認定|スキルアップ|デベキャンだより|勉強会|コミュニティ

関連記事

Windows インスタンスのローカルユーザーに Fleet Manger で RDP 接続してみた

このみ

2024.06.28

【IaC導入を成功させよう】IaCジャーニーマップを作ってみた

ちゃだいん

2024.06.28

AWS Well-Architected Framework がアップデート(2024年6月27日)されたので変更点を Well-Architected Tool で比較してみた

いわさ

2024.06.28

Amazon ConnectからAWS Lambdaを呼び出し、SMS送信してみた

平井裕二

2024.06.28