サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
blog.msysh.me
コンテナワークロードでは CodeDeploy などで継続的なデリバリを行い、Auto Scaling を利用して負荷に応じて、動的にコンテナを増減させて運用されているのではないかと思います。特に ECS では CodeDeploy を利用して、Blue/Green デプロイメントを行うことができます。また、Auto Scaling ではスケーリングを判断する指標の1つとして Application Load Balancer(ALB)ターゲットグループ内のターゲットごとに完了したリクエストの数(ALBRequestCountPerTarget)を利用することができます。が、実は現時点ではそれらを一緒に使うと、そのままでは期待通りに動作してくれません。それぞれをうまく利用するために検討する機会がありましたので、考え方のベースとして記録に残しておきたいと思います。 本記事の内容をそのまま本番
“固定 IP で接続したい・・・” 送信元、あるいは接続先の IP を固定して接続したいケース、いろいろあるかと思います。最近はゼロトラストな考えでどんな IP だろうと信用しない、という考え方も見受けられるようになってきましたが、会社をまたいだ旧来のシステム間の連携など、まだまだ要件としては根強い状況かと思います。今回は “接続先の API Gateway の IP の固定化” について検討する機会がありましたので記録として残しておきたいと思います。 はじめに 残念ながら API Gateway 単体では IP を固定することはできません。他の AWS のサービスを組み合わせて実現することになります。 また、前提として名前ベースで接続できるものとしています。 アーキテクチャ 以下のようなアーキテクチャで実現してみました。 ポイントとしては以下の点になります。 API Gateway をプ
AWS による docker コンテナのオーケストレーションサービスである Amazon ECS / Fargate のヘルスチェックの挙動について調査する機会がありましたのでアウトプットしておきたいと思います。 前提として Fargate で ECS のサービスとして、ロードバランサーは Application Load Balancer(ALB)を利用して実行するケースで調査しました。網羅的ではない点、ご了承ください。 ECS におけるヘルスチェック さて、ECS でサービスを実行する上で、いわゆる「ヘルスチェック」は2種類あります。 Elastic Load Balancer(今回は ALB)に関連付けられる Target Group によるヘルスチェック タスク定義のコンテナに対して実行する docker によるヘルスチェック(参考 : docker ドキュメント, AWS ドキュ
FireLens fluent bit でログを振り分けたい場合、 fluent bit の設定ファイル内で Parsers_File などで指定した別のファイルを用いて、カスタム docker イメージを作成するサンプルが多いかと思いますが、カスタムイメージを作成することなく( Parsers_File 無しで)ささやかながら実現した例を紹介したいと思います。 前置き コンテナのログを簡単に取り扱うためのツールをとして AWS は FireLens を発表しました (AWS Blog) 。それまではログドライバに awslogs を指定することで、コンテナの標準出力に書き出せば CloudWatch Logs にログが出力されるようになっていましたが、一方コンテナから出力されるログは、アクセスログやアプリケーションログ、エラーログといった複数の種類があり、種類に応じて出力先を振り分けたい
このページを最初にブックマークしてみませんか?
『blog.msysh.me』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く