何が起こるか把握する
まずは触ってみて、何が起こるか見てみます。
使用を開始する
ガイドに従って以下を作成していきます。
- 環境テンプレート
- サービステンプレート
- 環境
- サービス
- サービスインスタンス
- ※今回はFargateのサンプルバンドルを選択する
- ※名前が必要なものは連番で
sampleNと付けていくことにする
結果を確認
エンドポイント
ALBのパブリックエンドポイントが生成されてアクセスできるようになりました。
Proton
| リソース | 結果 |
|---|---|
| 環境テンプレート |  |
| サービステンプレート |  |
| 環境 |  |
| サービス |  |
| サービスインスタンス |  |
CloudFormation
| Proton | 結果 |
|---|---|
| 環境 |  |
| サービス (サービスインスタンス) |
 |
| サービス (CI/CD piepline) |
 |
ソースも確認する
今回使ったサンプルはこちらから確認できます。
分かったこと
- 環境を作成すると、
VPC一式と空のECSクラスターが作られる- ※DBやRedisなどが必要な場合はここで作ることになりそうか
- サービスを作成すると、作成ウィザードの中でサービスインスタンス用の設定も聞かれ、サービスインスタンスも作られる
- ※Fargateの場合、サービスインスタンスで
ECS ServiceECS TaskDefinitionALBALB TargetGroupなどアプリケーション一式を作るイメージか
- ※Fargateの場合、サービスインスタンスで
- サービスインスタンスの作成が終わればALBのエンドポイントが出力される
- そのURLにアクセスするとNginxの画面が見える
-
サービスのスキーマにpipeline_infrastructureがある場合は
CodePipeline周りも作成される模様-
ECRが作られる -
Codepipelineが作られる- Sourceステージ
- ウィザードで選択したアプリケーションのGitリポジトリはここに紐づけられている
- Buildステージ
CodeBuild- アプリケーションのDockerfileをビルドしてECRにプッシュする
- Deployステージ
CodeBuild- Protonのサービスインスタンスのパラメーターを上書き（サンプルでは
image）して新バージョンに更新する - 新バージョンの更新が終わるまで待つ(aws cliの
--waitオプション）
- Sourceステージ
-
何に使えるか考える
さて、ここからが面白い作業ですね。
何に使えるか考えていきましょう。
※この先は今後随時追加していくと思います。
ブランチプレビュー環境
ウィザードでリポジトリとブランチをポチポチ選んでFargateのデプロイができてしまうのであれば、まず思いつくのはやはりこれではないかと思います。
手作業で作って消してもよいですし、GithubActionsで自動化しても面白そうですね。
フロントのコーディングだけ確認したい版
- 課金少なめになるよう工夫できれば嬉しい
- DBはタスク定義の別コンテナで建てるかSQLiteにでもする
- 永続ストレージも不要なのでコンテナの一時ストレージを使う
ステージ環境
- 本番に似た環境で課金少なめの構成も作れそう
パッケージアプリケーションのカスタマイズ版
OEM開発
自社である程度まで開発したアプリケーションをカスタマイズして別サービスとしてリリースするようなことってよくありますよね。
ベースが同じアプリケーションであればインフラのベースも（最初は）同じでよいので、予め作っておいたProtonで簡単に量産体制が作れるかもしれないですね。
買い切り
販売したパッケージのカスタマイズまで請け負わないケースもありますよね。
そういう場合も、初期デプロイと継続デプロイのセッティングまで行う納品をエンジニア不要で出来てしまうかもしれませんね。
よく使うちょっとしたAPI
本記事ではFargate版バンドルを試しましたが、Lambda版バンドルも試したところ簡単にAPI GatewayでCRUD APIが生成されたので、Fargate以外でも使い道がありそうです。
郵便番号検索API
郵便局のデータを使って郵便番号検索APIってよく作りますよね。
こんなのはもうパッケージにしておいて案件ごとにProton起動させて瞬殺にしてしまいたいですね。
CI/CD付きなので最新データへの更新も心配ないですね。
静的サイトのメールフォーム系
昨今、静的サイトを瞬殺デプロイできるサービスは様々ありますが、やはりメールフォームや申込フォームをどうするか悩みますよね。
そういうのも、Lambdaでさっと作ってあるものをProtonでデプロイできれば楽になりそうですね。
LambdaであればAWSコンソール上で編集までできるので、「ちょっと返信メールの文言変えたい」くらいの事がやはりエンジニア不要でできますね。
AWSアカウントを跨いだ納品
今回は試していないですが、別アカウントにデプロイする機能もあるようなので、
納品先のAWSの子アカウントの権限だけもらって、Proton自体は自社アカウントで作動させて納品完了ということもできるのかもですね。
※CodePipelineはどっちにできるんだろうか・・ 要調査
おわり
ある程度ベースを作っておけば、量産系の作業が楽になったり、エンジニアの作業範囲から外せてしまうものもありそうでとても良さそうですね。