以前のこちらの記事でAWS Protonを試しましたので、今回は実践編としてウェブアプリケーションを構築していきます。
目標
- Railsのアプリケーションをデプロイできる
- SSL
- Protonで証明書の作成はしない
- 別途行っておいてArnだけ設定する形
- WAF
- RDS(Aurora MySQL)
- パスワード自動生成 & SecretManagerに保管
- 削除保護の有無を選択可
- ElastiCache(Redis)
- sidekiqから利用
- Fargate
- Container Insightsの有無を選択可
- AutoScallingを設定可
- ヘルスチェック
- コスト配分タグの付与（要所のみ）
- アプリケーションは Githubへpush → ビルド＆デプロイ → Slackへ通知のフロー
- テスト環境・ステージ環境構築時には課金を少な目にできる気配り
出来たもの
今回作成したテンプレートは、案件情報をマスクした上でProtonの公式サンプルに上書きして置いてあります。
環境テンプレート
環境テンプレートはざっくり以下のような構成になりました。
パラメーター
パラメーターで以下のように設定・選択することができます。
| パラメーター | 値 | |
|---|---|---|
| CertificateManagerArn | Arn | SSL証明書のArn ALBのHTTPS Target Groupに設定される |
| Elastic IPが必要かどうか | Yes/No | Yesであれば各PrivateSubnetにNATGatewayを置いてElasticIPを紐づける |
| DBエンジンモード | Serverless/Provisioned | Amazon Aurora Clusterのエンジンモード 本番用: Provisioned テスト用: Serverless※1 |
| DBインスタンスクラス | small/medium/large | Provisioned選択時のインスタンスタイプ |
| DBキャパシティ | AutoPause/low/high | Serverless選択時のキャパシティ ※AutoPauseを選択すると一定時間アクセスがない場合は自動的に停止し課金もなくなる |
| Container Insightsの有効化 | enabled/disabled | FargateのContainer Insightsを有効化します |
| 削除保護が必要かどうか | Yes/No | YesにするとDBに削除保護を付与（YesのままでProtonから環境を削除しても失敗するので注意） |
使い分けとしては、以下のようなイメージです。
- テスト環境ではServerless & AutoPause & Container Insightなし で課金節約、削除保護なし
- 本番環境ではProvisioned & リリース初期はsmall、削除保護あり
- Elastic IPはどうしても必要な案件のときだけ利用する（NATGatewayが高価なため）
また、今回はRoute53系やドメイン系は自動構築していません。
ドメインの取得がRoute53でされるかは案件によるのと、一回取得したドメインのサブドメインで次のサービスを作ることもあり、テンプレート化が複雑になるためです。
同様にSSL証明書も手作業で取得したもののArnをパラメーターで入力する形にしています。
サービスインスタンス
サービスインスタンスはこのようになりました。
ALB
ALBは、Protonの公式のサンプルを試したときはサービスインスタンス毎に作られていましたが、
今回は環境の方で構築済みのALB Listenerに対してサービスインスタンスで作成したFargateのServiceを登録（TargetGroupを作成して新規のListener Ruleに紐づけてListener Rulesに追加）していくようにしています。
この形だと、同環境内で別のサービスインスタンスを立てるときも同じALBを使えるため課金を抑えられるかなという目論見です。
パラメーター
サービスインスタンスも、パラメーターで以下のように設定・選択することができます。
| パラメーター | 値 | |
|---|---|---|
| サービスのドメイン | ドメイン | S3のCORSを設定したり、 Railsの config.hostsの設定に利用する |
| Fargateのタスクサイズ | small/medium/large | smallだとcpu: 512, memory: 1024 など |
| Autoscalling キャパシティ （最小～最大） |
1～10 | |
| ビルドしたイメージのECR Arn | Arn | ※パイプラインから更新されるため手動設定不要 |
| Railsのログレベル | DEBUG～FATAL | |
| メンテナンスモード | YES/NO |
メンテナンスモード
メンテナンスモードに変更すると、
アプリケーションのコンテナを起動せずに、Nginxイメージでコンテナを起動します。
ソースコードのリポジトリの用意が出来ていない時期にインフラだけ作って疎通確認したいときなどに使用します。
サービスパイプライン
パイプラインはビルドコマンドを少々変更しただけで公式サンプルほぼそのままなので割愛します。
Jinjaテンプレート
Protonのテンプレートでは Jinja というテンプレート構文でちょっとした文字列演算などができます。
構文は {{ pythonのコード }} となっています。
あまり使いどころもないですが、あると地味に便利だった箇所を抜粋してみます。
# 「8時間」を指定したいけど、「秒」に換算するのがめんどいとき
SecondsUntilAutoPause: {{ 60 * 60 * 8 }}
# Mappings内での文字列結合や演算（通常のCloudFormationではこの中ではJoin等が使えない）
Mappings:
EnvironmentNameConfig:
Environment:
Name: '{{ environment.name}}'
ResourceTagConfig:
Project:
Key: 'Cost:Project'
Value: '{{ environment.inputs.project_base_name }}'
Service:
Key: 'Cost:Service'
Value: '{{ environment.inputs.project_base_name }}-{{ environment.inputs.project_short_name }}'
Env:
Key: 'Cost:Env'
Value: '{{ {"stg": "staging", "prod": "production"}[environment.inputs.service_environment] }}'
# 公式サンプルにあった黒魔術
# Note that the Name property has a 32 character limit, which could be
# reached by using either {{service.name}}, {{service_instance.name}}
# or a combination of both as we're doing here, so we truncate the name to 29 characters
# plus an ellipsis different from '...' or '---' to avoid running into errors.
Name: '{{(service.name~"--"~service_instance.name)|truncate(29, true, 'zzz', 0)}}'
おわり
以上でアプリケーションは継続デプロイできるようになりました。
Protonの方も、Protonの画面上からポチポチとテンプレートのリポジトリを紐づけるだけで各種設定が完了し、Githubが更新されたら自動的に最新バージョンのDraftを用意してくれるようになります。あとはまたポチポチしていけばマイナーバージョンが切り替わるのでとても便利でした。
ただ、テンプレート名とメジャーバージョン番号をリポジトリのディレクトリ名にしておかないといけない仕様が全然Gitと相性が良くないなとは感じました。リネームしたら変更履歴追いにくいじゃん。という
この点はAWSにフィードバックを送信してみたので、今後良くなればなと願っています。