Fargateさわってみる

CloudWatch Container Insightsとは？

VPCを新規作成しなくてもクラスターは作成できる
既存の中には入れられない？
VPCある場合とない場合の違いは？

github actionsのamazon-ecs-deploy-task-definition@v1でデプロイしようとしたら

Error: Failed to register task definition in ECS: Fargate only supports network mode ‘awsvpc’.
Error: Fargate only supports network mode ‘awsvpc’.

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-taskdefinition.html
task-definision.jsonに
"NetworkMode": "awsvpc", を指定してないからでは？

Fargate 起動タイプを使用している場合、awsvpc ネットワークモードが必要です。

"networkMode" か

次のエラー

Failed to register task definition in ECS: When networkMode=awsvpc, the host ports and container ports in port mappings must match.

prot関連の項目消したらいけた。

次

 ECS: Fargate requires that 'cpu' be defined at the task level

"cpu": 256,
"memory": 512,
cpuとmemoryが必須です。fargateの場合。

taskが動かせない。実行中にならない？なってるけど一瞬で観測できてないとか？
作ったimageはローカルでrunしたら動く。
cloudwatchログに何も出ない。

CannotPullContainerError: Error response from daemon: Get https://yaaaaaaaaaaaaaa.dkr.ecr.ap-northeast-1.amazonaws.com/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

https://aws.amazon.com/jp/premiumsupport/knowledge-center/ecs-pull-container-error/

Fargate 起動タイプ

タスクの実行に使用されるサブネットのルートテーブルに、インターネットゲートウェイまたは NAT ゲートウェイへのルートがあることを確認します。
注意: インターネットゲートウェイまたは NAT ゲートウェイの代わりに、AWS PrivateLink を使用できます。エラーを回避するには、AWS PrivateLink または HTTP プロキシを正しく設定してください。
パブリックサブネットでタスクを起動する場合は、Amazon EC2 コンソールでタスクを起動するときに、[自動割り当てパブリック IP] を [有効] にします。これにより、イメージを取得するためのアウトバウンドネットワークアクセスをタスクに付与できます。
Amazon VPC で Amazon が提供する DNS を使用している場合は、インスタンスにアタッチされたセキュリティグループに HTTPS (ポート 443) に対するアウトバウンドアクセスが許可されていることを確認します。
カスタム DNS を使用している場合は、ポート 53 の DNS (UDP および TCP) およびポート 443 での HTTPS アクセスに対してアウトバウンドアクセスが許可されていることを確認します。
ネットワーク ACL ルールがレジストリへのトラフィックをブロックしていないことを確認します。

タスク実行時のサブネットprivateのにしたら。コンテナ起動できた。
natゲートウェイ使っている？
ちなみに自動publicip割り当てはdiabledでタスク実行している。

taskを実行できてログに書き込まれているのを確認できた。

スクリプトを実行したいが、動かない。

状況の理由	CannotStartContainerError: Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "/bin/sh start.sh": stat /bin/sh start.sh: no such file or directory: unknown
コマンド	["/bin/sh start.sh"]

lsコマンドで確認したがファイルは存在している。

task定義確認したら、
"command": [
"/bin/sh start.sh"
],

こんなふうになってる。

違うような。

コンソールでtask定義のコンテナの追加のとこでぽちぽちやってるけど、
/bin/sh start.sh
じゃなくて
/bin/sh,start.sh
だ。
コンマ区切りってプレースホルダで書いてあった。

Fargateクラスターを本番とstagingに分ける必要はある？

Q3: Amazon ECS において、クラスタはどう分けるのがよいか？
まず、起動タイプが EC2 なのか Fargate なのかで考慮する範囲が違ってきます。EC2 起動タイプであれば、クラスタを分けた場合 EC2 インスタンス自体が別になるので、例えばクラスタが持つ CPU やメモリなどのリソース量はクラスタごとに起動しているインスタンスタイプ・数によります。 対して Fargate であればクラスタは論理的な空間であり、EC2 インスタンスという概念自体が存在しません。

他にもいくつかの観点がありますが、例えば以下のような権限管理の面を考えてみます。

ECS が提供する API である CreateService, UpdateService, DeleteService, RunTask, StartTask API などは、AWS IAM のポリシー内の Condition keys で操作可能なクラスタを指定できるので、クラスタを分けることで例えば「IAM ユーザー A / IAM ロール A は Staging 環境のクラスタでサービスやタスクを作成・更新できるが、本番環境のクラスタではできない」といった詳細な権限制御を行うことができるので、そういった面で検討してみるのはいかがでしょうか。

https://aws.amazon.com/jp/blogs/startup/weekly-aae-17/

バッチを1日1回定期実行する、みたいな小さい場合でも分けておいたほうがいいのかな。