新年あけまして地味なことから始めましょう。 ECS Exec におけるタイムアウト対策の雑多なメモで、AWS ECS Exec を使ってみたTips | 外道父の匠 の補足みたいな内容です。 問題点 引っかかった問題はシンプルで、こんな風にごく普通に execute_command を実行したときに、20分強経過するとプロセスが強制終了されるというものです。 ecs = boto3.client('ecs', region_name="ap-northeast-1") cluster = 'test' task_arn = 'arn:aws:ecs:ap-northeast-1:0123456789:task/test/0123456789abcdef' container = None interactive = True command = "/bin/sh -c 'echo ABC;

前回の考察をより実現しやすくするために、ECS on EC2 と Fargate でリソース構成にどのような違いがあるのか、をTerraformコードで追っていきます。 １つの設定で気軽に切り替えられる書き方にしていますが、実際にはそんな風にする必要はないので、ポイントを確認する感じで見てもらえればと思います。 構成の概要 ECS on EC2 と Fargate では、細かくは多くの違いがあるのですが、基本的な構成はそう違いはないとも言えます。このどっちつかずの表現は、以降のTerraformコードを見ていただければ、なんとなくわかってもらえると思います。 ただ、１つだけ大きめの違いがあり、on EC2 ではネットワークの選択余地があります。それはネットーワークモードが「awsvpc」か「bridge」かの違いです。 Fargate では「awsvpc」固定になり、タスクにPublicI

Fargate はコンテナホストとしてのリソースが不要なので、こんなもんでしょう。以前は貧弱CPUのせいで割高感が強かったですが、これならトントンに近い印象です。 ECS on EC2 or Fargate ? 性能・コスパ差が拮抗したとして、ではECSにおいて on EC2 と Fargate どちらを選ぶべきか、の要点を考えてみます。 構築 まず構築についてですが、細かい違いは多くあるものの、コード化してしまえば困ることはそうありません。EC2の方が、より選択と工夫の余地があり、Fargateの方がそれなりにシンプルに仕上る感じです。 リソース構成の差異については、後でTerraformコードで切り抜いて記述します。 EC2のデメリット 構成で最も異なるのは当然、インスタンスの有無──すなわちAutoscalingGroupの有無ですが、on EC2 にすることでデメリットと考えられる

前回が思いのほか反響があったので、インドカレーのナンの如くおかわりです。 今回は完全に蛇足っ……圧倒的蛇足っっ……です！同じことを他のリージョンで確認したら、どんなもんなのかという、おまえ暇ナンかと言わてれもおかしくないやつ、参りましょう。 おまえ暇なん……？ 暇っちゃ暇。つーか、チャットとかで今忙しいですか？って話しかけられたら、俺はいつでも暇やでって応えるスタンスや。 元々趣味でやってるモンだから、休日にゲームしようか映画みようかエンジニアリングしようかって考えたときに、気になることがあったら先にやっちまうべき優先度が高いのがエンジニアリングってだけ。 こんなどーでもいい釈明をしたくなるくらいには、蛇足回……。 ……と思うやん？ リージョン別CPUモデル とりあえず結果を見たらよいと思うやつです。選択したリージョンは基本USで、一部適当にやってみただけです。 まずは出現CPUを、CPU

ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在

ここ１ヶ月半くらい、ちょっとした独自システムを創っていたのですが、そこで編み出したテクニックを紹介してみます。 要はECS Execを使い込んだよってだけなんですが、こういうオモチャを使ったオモチャを作らせたら一級品の自負、ある。 ECS Exec の概要 基本的なところは他に任せたいのでリンクだけ貼っておきます。 New – Amazon ECS Exec による AWS Fargate, Amazon EC2 上のコンテナへのアクセス | Amazon Web Services ブログ [アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました | DevelopersIO デバッグに Amazon ECS Exec を使用する – Amazon ECS 外からコマンドを実行できる旨味 ECSっていっても自分の中では Fargate の話にな

ECS Fargate でコンテナ内部をいじくってたら、いくつかやりたいことがあって、まとまりができたので更新です。 メタデータの扱いがわかれば大体イケるみたいな感じですが、たどり着くまでわりと時間かかったので、サクッとまとめ。 Fargate に渡される環境変数 最終的にはコンテナに sshd とか用意しないのがベターではあるのですが、やっぱりSSHは大正義。シェルで作業しないと、こーゆーのは捗りません。 Fargate で基本的な値が入った環境変数はこのように取得できるので確認します。これがあれば、あとはトントン拍子に進みますね。 (参考) Amazon ECS で “アクセス拒否” エラーを発生させないように IAM タスクロールを設定する $ sudo strings /proc/1/environ | sort AWS_CONTAINER_CREDENTIALS_RELATIVE

EKS Fargate が出たので、男の子なら ECS Fargate と対決させてみたくなるじゃないですか。 でも、結果が全然おもしろくなかったので、雑にいきますね！ EKS のCPUモデル まずは、EKS Fargate を起動して、CPUをチェックしていきました。リソース量を多くしてあからさまに変わったら恥ずかしいので、ちゃんと１回ずつ網羅しておきました。例によって、テーブルに起こすの面倒なので画像で失礼しやす。 ちな、CPUの性能値については、私の大好きなこちらから検索したものになります。 CPU Benchmarks いくつか補足を。 起動の時間にはムラがある。おそらくNodeとして新規起動なのか、起動済みに入るのかで変わるのだろう CPUモデルはリソース量に関係なくランダムだと思われる PodからみたNodeのメモリ容量は、4GiB弱～32GiB あたりで構成されるようだ 30

コンテナ。それは便利そうではあるが、面倒くさそうであり、積極的に取り入れるべきか微妙な存在。 個人的な感想としては、慣れるまでそれなりに大変・慣れれば楽しく便利。そう、つまり触ってみないと何もわからない、いつものヤツだ！細かいことはスッとばして、最低限の感触を掴むための構築手順を AWS + Terraform を用いて懇切丁寧に分解していくぞ！ 目的 AWSはチョットデキルし、コンテナに触れてみたいんだけど、何から手を付けたらいいかよくわからない。くらいのコンテナ初心者向けの内容にしていきます。コンテナ感覚を得るための具体的な構築メインなので、細かい話は飛ばし気味にいくため、ド素人向けではないです。 今回、構築するのはよくあるWEBサイトのような形をした超簡易的なコード管理とコンテナ運用で、それをAWSで表現していきます。これがスタンダードな構成だ、というわけではなく、これを１つのベース