#author("2024-11-14T11:42:27+00:00","default:wikiadmin","wikiadmin") #author("2024-12-11T10:45:17+00:00","default:wikiadmin","wikiadmin") -AWSのコンテナオーケストレーション *CLI [#ee1dbc66] -タスク一覧取得 aws ecs list-tasks --cluster XXXX -タスク詳細 aws ecs describe-tasks *FARGATE SPOT [#k0ca383a] -安いので動作検証&開発用途はこれでよし! -SPOT殺されそうになったら、CLIで変更 aws ecs update-service --cluster ${CLUSTER} --service ${SERVICE} --capacity-provider-strategy capacityProvider=FARGATE,weight=1,base=1 --force-new-deployment *VPC endpoint [#z0f87410] https://dev.classmethod.jp/articles/vpc-endpoints-for-ecs-2022/ -S3以外は課金発生なのでNG! *デプロイ戦略 [#d603182d] -タグのLatest運用はやめましょう! *用語集 [#wa2e3062] **ECS独自 [#c0bc6927] -タスク定義はいくら作っても無料(生成されないので!) -Fargateにおけるクラスターは単なるサービスと結びつける枠なのでこれまた無料(実際にはサービスと同じ生存期間なので無料ではないが) -ServiceでタスクをいくつとかALBと組み合わせたりすると課金発生 |Fargate|EC2の管理不要| |タスク定義|タスクの情報。作成しても課金なしなので作ることをためらうな!だが削除できないという欠点あり| |タスク|コンテナ1つに対応する。タスク定義とタスクはクラスとインスタンスの関係。タスク定義はVersion管理されており、更新すると別のタスクが立ち上がり入れ替わる| |サービス|タスクが幾つ必要かとかALBと紐づけるとか。| |クラスタ|EC2の塊、Fargateだと意識することはない。| **Docker [#f53c5d76] |CMD|Docker起動時に実施するCMD。起動時に指定するものと同じものが定義できると考えるべし。docker exec -it xxx /bin/bashの/bin/bashの部分だ| |ENTRYPOINT|Docker起動時に実施するコマンドではCMDと一緒だが、上書き不可能だったりもできる。ENTRYPOINTを指定したときは、runの後の記述は起動するプロセスを特定する指示としては機能しない| *Task role/ Task Execution Role [#o4efefa4] -Task RoleはECSに対するIAMロールでEC2のIAMのようにECSからAWSサービス使うときのRole(任意) -Task Exection Roleはタスクを実行するためのRole。ECR読み取りとかCW書き込みとか(必須) というかそんな説明で納得できるわけがない。「アプリのコードでAWSリソースへアクセスする場合、タスクロールに権限をつける」「コンテナの設定でAWSリソースする場合はタスク実行ロールに権限をつける」。SecretManagerにアプリコードでアクセスするならタスクロールで、task definitionでSecretManager使うならタスク実行ロール *aws-cli ecs編 [#k173107f] |aws ecs list-task-definitions|タスク定義の一覧| |aws ecs describe-task-definition --task-definition test-mysql:2|タスク定義の詳細。このままではRegisterできない。| **Blue/Greenの時のために整形 [#t051a8f8] aws ecs describe-task-definition --task-definition test-mysql:2 | jq '.taskDefinition | del(.status, .compatibilities, .taskDefinitionArn, .requiresAttributes, .revision) ' https://dev.classmethod.jp/articles/describe-task-definition-to-register-task-definition/ *firelens [#aa006800] -ログドライバをCloudWatch Logs以外に選択できるようになった。 -ログドライバはECS固有ではなくて、Dockerにある概念。 -Dockerの制約で16kb超えるログは分割される **ポイント [#x04a0057] -ログを早出する側はfirelensを指定するだけ -firelens側ではNameでcloudwatchやforwardを指定する。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/using_firelens.html -terraform https://qiita.com/neruneruo/items/b3fb35ad5064c045a15b **Fluentdへ [#h8fc2f9e] -Optionの設定にFluentdに関係ないものを入れてはいけない。400エラーとなる。 -PortもStringなど特殊なので以下のまま使うこと -送信先がない場合は、firelensコンテナログにその旨が出る "options": { "exclude-pattern": "^.*(hoge|open).*$", "Port": "24224", "Host": "HOST", "Name": "forward" } **直接Cloudwatchlogsへ [#eb70c121] 指定のロググループ名でストリーム名は「$prefix/コンテナ名称/乱数」となる https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/cloudwatchlogs https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/using_firelens.html#firelens-filtering-logs +試しに最小構成のnginx/firelensで実施。 +CloudWatchLogsにロググループ作成権限が必要で、初回は起動失敗。 +起動失敗しても繰り返し上がってくるのでポリシー更新後成功 -firelens側の設定 "options": { "awslogs-group": "firelens-container", "awslogs-region": "ap-northeast-1", "awslogs-create-group": "true", "awslogs-stream-prefix": "firelens" } 以下のロググループとストリーム名で出力される。これはFluentBitの起動ログである。ngixのログは出ないので注意 log-group/firelens-container/log-events/firelensXXXXX -nginx側の設定。CloudWatchに流すにはNameにcloudwatchと設定。exclude-patternでopenとhogeが含まれるものを除去している "options": { "log_group_name": "firelens-testing-fluent-bit", "auto_create_group": "true", "log_stream_prefix": "from-fluent-bit", "region": "ap-northeast-1", "exclude-pattern": "^.*(hoge|open).*$", "Name": "cloudwatch" } log-group/firelens-testing-fluent-bit/log-events/from-fluent-bitapp-firelens-XXXXX **参考 Docker標準のログドライバ [#cc65c477] |json-file|標準 Docker logsで見れる| |syslog|Syslogに転送| |journald|| |fluentd|| *CMDとENTRYPOINT [#n847003c] **ENTRYPOINT [#c5e6089f] 固定で与えるものなので、docker run -it xxx 'コマンド'が実行時にentrypointに加わる |/bin/bash -c|docker run it xxx 'ls'|ls | |/usr/bin/git |docker run it xxx 'log'|git log| **CMD [#l4b913ea] Docker runで何も指定しなかったときの実行コマンド。またはentrypointでのデフォルト引数。 |EntryPoint設定値|CMD設定値|docker runコマンド|実際のコマンド| |なし|ls |docker run -it xxx |ls | |/bin/bash -c|ls |docker run -it xxx |ls | *Sidecar [#x1eac69d] https://y-ohgi.com/2019-aws-handson/datadog/ecs/ https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_task_definition *トラブルシューティング [#n23f2328] **ECRがPullできない。 [#efeeefad] -LatestのECRをPushしたところ古いバージョンを参照していたTaskDefinitionが失敗してた。なのでTaskDefinition作り直しで同じECRのURLを指定。どこかでキャッシュしているのだろうか? -Private Subnetに配置するとインターネットに出られない状況。NatGW必要 -[ is not authorized to perform: ecr:GetAuthorizationToken on resource: ]ECRから取得する権限不足 https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/ECR_on_ECS.html ***失敗した原因 [#ie9fce6a] -terraform targetで必要なもののみapplyしていたが、IAMが足りてなかった。 -それでもエラーにはならず、起動に失敗するのでLogGroupあるのにエラーが出るように見えた(ログに書き込む前に落ちているので当たり前) -pull失敗はIAMのエラーであったのでprivateで駄目かどうかはもう一回試す(おそらく駄目だろうが) -ecs service削除が全く終わらず。手動でstate消して進めたというのがあった。再現性はない。が上記IAMにポリシーが紐付いてない状態はTerraformのコード上はありえないので、削除時に中途半端に残った可能性が高い。 ***ECS新しいVPCで起動しない問題 [#u3f2ccae] -iam_roleが不完全だったので、ちゃんとPolicyがあタッチされていることを確認して、デプロイだが、起動失敗無限ループ。原因はやはりterraform targetによる不完全VPCの作成だった。Public subnet に配置したのだが、InterNetGatewayが作成されず。きちんとmodule.vpcを指定しないと依存関係の最小限のみ作成することになる。上記IAMポリシーが紐付いけない件も同様の理由だったと推測 ResourceInitializationError: unable to pull secrets or registry auth: The task cannot pull registry auth from Amazon ECR: There is a connection issue between the task and Amazon ECR. Check your task network configuration. RequestError: send request failed caused by: Post "https://api.ecr.ap-northeast-1.amazonaws.com/": dial tcp 3.112.64.212:443: i/o timeout ***ALB接続後にTask_definitionを変更できない問題 The container nginx does not exist in the task definition. [#b8d2b7ab] -ALBにコンテナ名が記録されるのでtask defを変更しないほうがよい。 ***Service削除に時間がかかる [#g17f05fc] Drainingに時間がかかるので、コンソール上見えてなくても5分はまつこと。消えきらないとApplyしても同名サービス削除中で失敗する *Tips [#ad365403] 起動したPublic IPの確認。タスクから詳細(タスク定義ではない!) *ローカルでECSタスク定義実行 [#e9968eff] -タスク定義はdocker-compose.ymlに相当するが、独自仕様のため、以下のページ通りにするとdocker-composeに変換してくれる https://dev.classmethod.jp/articles/ecs-local/ -デプロイ https://dev.classmethod.jp/articles/aws-devday-2019-fargate-deploy/ *Secret Managerとの連携 [#z47d52ef] https://dev.classmethod.jp/articles/try-to-protect-aws-fargate-container-environment-variable-with-aws-secrets-manager/