Zenn
⚛️

AWS Proton が GA したのでやっていきましょう Part.3 (マルチアカウント編)

2021/07/04に公開
AWS
proton
tech

やっていく

さて、だいぶん間が空いてしまいました。
// おじさんにも仕事があるんや…。

Part.1 座学編, Part.2 ハンズオン編 では、同一アカウント内に環境を作り、その中にサービスインスタンスを展開しました。

今回はハンズオン編に引き続き、マルチアカウント編と称して、異なる AWS アカウントに環境とサービスインスタンスを展開していきましょう。

インフラ担当者の作業

他のマルチアカウントをサポートする AWS サービス同様、AWS Proton でもアカウント間の接続は一方のアカウントからリクエストを送り、もう一方のアカウントで承認する必要があります。

マルチアカウント ユースケース図

AWS Proton では、環境テンプレートやサービステンプレートを保有しているアカウントを管理アカウント、環境テンプレートを元に環境を展開される側のアカウントを環境アカウントと呼びます。クロスアカウントは環境アカウント側からリクエストを送信し、管理アカウントで承認するフローになっています。

今回のハンズオンでいうと、下記のような組み合わせです。

  • 開発アカウント＝管理アカウント
  • 本番アカウント＝環境アカウント

それでは、ここからはインフラ担当者になりきって、本番アカウントと開発アカウントを接続しましょう。

1. 環境アカウントの接続

まずは本番アカウント(環境アカウント)にログインをしてください。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [AWS Proton] をクリックします。
  • ナビゲーションペインから [環境アカウントの接続] をクリックします。
  • [管理アカウントへの接続リクエストを送信] から、[接続をリクエスト] ボタンをクリックします。
  • [接続をリクエスト] 画面で下記の値を入力します。
    • [管理アカウントに接続]
      • [管理アカウント ID]: (開発アカウントの AWS アカウント ID)
      • [環境名]: prd
    • [管理アカウントに接続]
      • [環境ロール]: 新しいサービスロール
      • [環境ロール名]: ProtonServiceRole
      • [アカウントに管理特権を持つ …(以下略)]: チェックを入れる
  • [接続をリクエスト] ボタンを選択します。

ここで指定する環境名は管理アカウント側では変更できないので、命名規則があればそれに合わせた環境名を付ける必要があります。

次に開発アカウント(管理アカウント)にログインして承認をします。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [AWS Proton] をクリックします。
  • ナビゲーションペインから [環境アカウントの接続] をクリックします。
  • [環境アカウントの接続リクエスト] から、対象のリクエストをチェックして [受け入れる] ボタンをクリックします。
  • [ステータス] が Connected になれば完了です。

本番アカウント(環境アカウント)に再度ログインして AWS Proton の各種リソースを見ると分かるのですが、何もありません。基本的には管理アカウント側で AWS Proton の操作をすることになりそうです。

2. 本番アカウント用の環境の作成

接続された本番アカウント向けの環境を作成します。先ほども述べた通り、管理アカウント側での操作になります。

  • ナビゲーションペインから [環境] をクリックします。
  • 環境一覧画面の右上から [環境を作成する] ボタンをクリックします。
  • [環境テンプレートを選択] 画面で下記の値を選択し、[次へ] ボタンをクリックします。
    • [環境テンプレート]: my-environment-template
  • [環境を設定] 画面で下記の値を選択し、[次へ] ボタンをクリックします。
    • [展開アカウント]: 別の AWS アカウント
    • [環境設定]
      • [環境アカウントの接続]: prd
    • その他のパラメーター: (デフォルト値)
  • [カスタム設定を構成] 画面ではそのまま [次へ] ボタンをクリックします。
  • [レビュー] 画面で入力した値に問題がないことを確認し、[作成] ボタンをクリックします。

環境一覧画面で [デプロイのステータス] が Succeeded になればデプロイが完了です。

それでは実際にデプロイされた環境を確認してみましょう。本番アカウント(環境アカウント)に再度ログインして AWS Proton の各種リソースを見ると、相変わらず何もありません。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [CloudFormation] をクリックします。
  • ナビゲーションペインから [スタック] をクリックします。
  • スタック一覧画面に下記のスタックが作成されているのが分かります。
    • AWSProton-<環境名>-cloudformation—<ランダム文字列>
  • スタック名をクリックします。
    • 画面上部のタブから [リソース] をクリックします。

しかし、CloudFormation の画面に行くとしっかりと環境のためのリソースが展開されていることが分かります。

アプリ担当者の作業

ここからはアプリ担当になりきって、本番アカウントで ECS サービスのデプロイをしていきます。ドキュメント上ではインフラ担当、アプリ担当のどちらが行ってもよいことになっています。

マルチアカウント ユースケース図

3. サービスの作成 / サービスインスタンスの作成

本番アカウントでデプロイ…と言っても、前述の通り操作は開発アカウント(管理アカウント)側になる点、注意が必要です。

  • ナビゲーションペインから [サービス] をクリックします。
  • サービス一覧画面の右上から [サービスを作成] ボタンをクリックします。
  • [サービステンプレートを選択] 画面で下記の値を選択し、[設定] ボタンをクリックします。
    • [環境テンプレート]: my-service-template
  • [サービスを設定] 画面で下記の値を選択し、[次へ] ボタンをクリックします。
    • [サービス設定]
      • [サービス名]: my-service-prd
    • [サービスリポジトリの設定]
      • [ブランチ名]: production
      • [リポジトリ ID]: xeres/my-service
        • この時点で GitHub 側にリポジトリが存在していなくても問題ありません
      • [リポジトリ接続]: proton-github
    • その他のパラメーター: (デフォルト値)
  • [カスタム設定を構成] 画面で下記の値を選択し、[次へ] ボタンをクリックします。
    • [Name]: dev-instance
    • [Environment]: dev
  • [レビュー] 画面で入力した値に問題がないことを確認し、[作成] ボタンをクリックします。

サービス一覧画面で [ステータス] が Active に、サービスインスタンス一覧画面で [デプロイのステータス] が Succeeded になればデプロイが完了です。

まず、開発アカウント(管理アカウント)にログインしたまま、CloudFormation の画面を確認します。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [CloudFormation] をクリックします。
  • ナビゲーションペインから [スタック] をクリックします。
  • スタック一覧画面に下記のスタックが作成されているのが分かります。
    • AWSProton-<サービス名>-cloudformation—<ランダム文字列>
  • スタック名をクリックします。
    • 画面上部のタブから [リソース] をクリックします。

開発アカウントのリソース一覧に ECR リポジトリがあるというのはポイントです。これを確認しておいてください。

次に本番アカウント(環境アカウント)にログインして、同様に CloudFormation の画面を確認します。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [CloudFormation] をクリックします。
  • ナビゲーションペインから [スタック] をクリックします。
  • スタック一覧画面に下記のスタックが作成されているのが分かります。
    • AWSProton-<サービス名>-<サービスインスタンス名>-cloudformation—<ランダム文字列>
  • スタック名をクリックします。
    • 画面上部のタブから [リソース] をクリックします。

本番アカウントに ECS サービスとタスク定義があります。これも重要です。

4. ECR のクロスアカウントアクセスの設定

リポジトリ ID xeres/my-service の production ブランチに git push すると開発アカウント(管理アカウント)の ECR にイメージが格納されます。しかし、これを利用する ECS サービスは本番アカウント(環境アカウント)にありますから、ECS サービスから ECR リポジトリのアクセスはクロスアカウントアクセスになります。

残念ながら現時点での AWS Proton ではこの点が配慮されていません。開発アカウント(管理アカウント)の ECR でクロスアカウントアクセスを許可しましょう。

  • ナビゲーションバーの左上から [サービス] - [コンテナ] - [Elastic Container Registry] をクリックします。
  • ナビゲーションペインから [Registries] をクリックします。
  • [プライベート] から [アクセス権限] ボタンをクリックします。
  • [プライベートレジストリのアクセス許可] 画面で [ステートメントを生成] ボタンをクリックします。
  • [ポリシーステートメントジェネレーター] で下記の値を入力し、[ポリシーに追加] ボタンをクリックします。
    • [ポリシータイプ]: Cross account policy
    • [ステートメント ID]: prd-cross-account
    • [アカウント]: (本番アカウントの AWS アカウント ID)

これで ECR レジストリのクロスアカウントが許可されました。次に ECR リポジトリのクロスアカウントを許可します。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [CloudFormation] をクリックします。
  • ナビゲーションペインから [スタック] をクリックします。
  • スタック一覧画面に下記のスタックが作成されているのが分かります。
    • AWSProton-<サービス名>-cloudformation—<ランダム文字列>
  • スタック名をクリックします。
    • 画面上部のタブから [リソース] をクリックします。
  • リソース一覧画面から [論理 ID] が ECRRepo で [物理 ID] がリンクになっているのでクリックします。
  • するとリポジトリが表示されるので、ナビゲーションペインから [Permissions] をクリックします。
  • アクセス許可の画面で [編集] ボタンをクリックします。
  • アクセス許可の編集の画面で [ステートメントを追加] ボタンをクリックし、下記の値を入力します。
    • [ステートメント名]: prd-cross-account
    • [AWS アカウント ID - オプション]: (本番アカウントの AWS アカウント ID)
    • [アクション]: 下記3つを選択する
      • ecr:BatchCheckLayerAvailability
      • ecr:GetDownloadUrlForLayer
      • ecr:BatchGetImage
    • その他のパラメーター: (デフォルト値)
  • [保存] ボタンをクリックします。

これで本番アカウントから開発アカウントの ECR へクロスアカウントアクセスが出来るようになりました。

アプリ担当者の作業

5. CI/CD パイプラインを利用して、サービスにソースコードをデプロイする

ソースコードをデプロイする前に、本番アカウントにデプロイされたアプリケーションの動作を確認します。

  • ナビゲーションバーの左上から [サービス] - [管理とガバナンス] - [AWS Proton] をクリックします。
  • ナビゲーションペインから [サービスインスタンス] をクリックします。
  • サービス一覧画面から prd-instance を選択します。
  • 画面中程の [出力] 欄に [ServieEndpoint] キーと値に URL が記載されています。

この URL をコピーして、ブラウザでアクセスしてみましょう。

Nginx のデフォルトトップページ

以前、開発環境で確認した時と同様に、無機質な Nginx のデフォルトトップページが表示されるでしょう。

では、さっそくアプリケーションをデプロイします。前回、手元にクローンした xeres/my-service で操作します。

$ cd my-service
$ git branch -a
* master
  remotes/origin/master
$ git branch -c master production
$ git checkout production
Switched to branch 'production'
Your branch is up to date with 'origin/master'.
$ git push origin production
You are pushing to the remote origin at https://github.com/xeres/my-service.git
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'production' on GitHub by visiting:
remote:      https://github.com/xeres/my-service/pull/new/production
remote:
To https://github.com/xeres/my-service.git
 * [new branch]      production -> production
  • ナビゲーションバーの左上から [サービス] - [開発者用ツール] - [CodePipeline] をクリックします。
  • パイプライン一覧画面に下記のパイプラインが作成されているのが分かります。
    • AWSProton-<サービス名>-cloudformation-<ランダム文字列>-Pipeline-<ランダム文字列>
  • パイプライン名をクリックします。

productiuon ブランチへの git push をトリガーに、CI/CD パイプラインが実行されていることが分かります。

パイプラインの全ステージが完了後、再び [ServieEndpoint] に表示されていた URL にアクセスしてください。

AWS Proton のアイコン

AWS Proton のアイコンが表示されたら完成です。

最後に

これで、マルチアカウントにおける AWS Proton 環境の構築が完了しました。

これ以降、アプリ担当者は master ブランチと開発環境でアプリケーション開発します。そして、十分にテストが行えたら production ブランチにマージすることで本番環境にリリースすることが出来ます。簡単なオペレーションで GitLab Flow に対応した開発・本番環境を構築できました。

GitLab Flow

その他、実践的な利用に向けて、下記のような機能が必要だと考えています。

他のコンテナサービスと同様、GitHub でロードマップの管理がされている点も良いですね。

AWS Proton の現時点でのネックは、環境テンプレートやサービステンプレートを作成するために十分なガイドが無い点です。インフラ担当者が環境テンプレートやサービステンプレートを気軽に作れるようになる、あるいは AWS Marketplace のような形で汎用的な実装を共有できるようになると良いですね。

さて、いかがだったでしょうか。

インフラ担当者とアプリ担当者が上手く連携してコンテナを使ったモダンな開発環境を用意できる、これぞ待ち望まれていたサービスです。是非 AWS Proton を使っていただいて、身近な AWS 社員にフィードバックをいただけると幸いです。

Discussion