pull requestを利用したいい感じのECS feature環境管理方法を考えた - Nealle Developer's Blog
はじめに SREチームの大木です。スノボの季節がもう終わりかけており、さみしい限りです。 feature staging環境*( 以下 feature環境 )自体のライフサイクルや管理をどうするか問題、なかなかどこも苦労していると思いますが、その中で今回それなりにいい感じの回答を出せたと思うので共有したいと思います。 *呼び方はpre-staging環境、pull request環境、テスト環境などいろいろありそうですが、私たちはfeature環境と呼んでいます。 どこが「いい感じ」なのかというと、PRのラベル付与によって環境の生成/削除を制御できる点です。PR画面上で楽々とfeature環境の管理ができたり、PR一覧からどのブランチでfeature環境が立っているかが分かりやすくなります。 feature環境について feature環境を当社のプロダクトであるPark Directの開発
踏み台にはECSコンテナを。～ログイン有無を検知して自動停止させる～ - NRIネットコムBlog
こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません！！コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ
改めてECSのデプロイ方法を整理する - NRIネットコムBlog
こんにちは。梅原です。 今日はECSのデプロイタイプについて改めて整理します。 ECSのデプロイ方法は3つあります。 ローリングアップデート Blue/Greenデプロイ 外部デプロイ の3つです。 この記事ではローリングアップデートとB/Gデプロイについて流れをおさらいします。 ECSの前段にALBを置いた構成を例にします。 ローリングアップデート ローリングアップデートの流れを見る B/Gデプロイ B/Gデプロイの流れを見る ローリングアップデートとB/Gデプロイの比較 最後に ローリングアップデート ローリングアップデートとは、稼働中のECSタスクをそのまま新しいタスクに置き換える方法です。一番オーソドックスなデプロイ方法なのではないでしょうか。 ECSのみでデプロイすることができ、設定箇所も主に後述する2つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた
AWS Fargate/Batchでスケールするなるはや動画エンコード｜Wano Group Developers Blog
伏見です。 今回は弊社の一部ビデオ系プロジェクトでのFargate & Batchの使用例について書いてみたいと思います。 まず、サービスとして次のような処理の流れがあるとします。 (1) ユーザーさんが好きな動画ファイル(mp4/prores)をブラウザから複数同時アップロードする (2) アップロードされた動画ファイルに対して、フレームレートやコーデックなど、軽い検品を行う (3) サイズ圧縮版のmp4/サムネイル用gifを作る (4) 生成したファイルをs3に格納しつつ、ユーザーさんにプレビュー用動画や検品結果を表示する 基本的にはこれだけの流れですが、単純にスケーリングでまず行き詰まりました。 動画のエンコードは「重い」 プロジェクト当初はEC2上で直接ffmpegを操作し、各種プレビューやサムネイルを生成していましたが、なにぶんエンコードはCPUリソース食いなので、アクセス流用が
WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか？
はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS（Fargate）を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。 AWS利用費と人件費の話 AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。 ApiGW+LambdaがWebAPIのための構成として唯一無
AWS ECS Fargate のCPU性能と特徴 | 外道父の匠
ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在
AWSでバッチ処理を実装する際の選択肢とサービス比較
処理が複雑でジョブの依存関係を定義したい場合は、AWS Batch 単体で制御するか、より複雑な場合は Step Functions を用いて Lambda、ECS（Fargate）、AWS Batch（Fargate） を組み合わせる。 AWSにおけるバッチ処理の選択肢 ざっくりとした選択肢は下記。 Lambda ECS（Fargate） AWS Batch（Fargate） これらのサービスに実際は SQS や Step Functions を組み合わせることもあるので選択肢はさらに広がる。 ちなみに、SQS + Fargate（常時起動でポーリング） という構成や、SQS + Lambda + Fargate（都度実行） という構成は、AWS Batch が Fargate に対応した現在は特にメリットがないので取り扱わない。 2021/5/2 追記 「常時リクエストがくるユースケー
Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
NEW – Using Amazon ECS Exec to access your containers on AWS Fargate and Amazon EC2 | Amazon Web Services
Containers NEW – Using Amazon ECS Exec to access your containers on AWS Fargate and Amazon EC2 Today, we are announcing the ability for all Amazon ECS users including developers and operators to “exec” into a container running inside a task deployed on either Amazon EC2 or AWS Fargate. This new functionality, dubbed ECS Exec, allows users to either run an interactive shell or a single command agai
待望！Amazon ECSのコンテナにログインできるAmazon ECS Execを試してみた - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 前回のブログにも書きましたが、弊社では昨年末から既存のEC2からECS/Fargateへのインフラ移行作業を実施しています。 EC2からECSへ移行する上では、特に運用面が大きく変わります。利便性やメンバーへの教育コストを考慮すると、今までEC2でやっていた運用をECSでどう上手く代替するかが力の入れ所だと思います。 一ヶ月前に弊社インターンの関口が書いた以下の記事も、既存運用の置き換えやデバッグ時の利便性向上を目的とした手段の１つで、この記事を執筆した時点ではECS/Fargate上のコンテナに対するAWS公式のログイン手段はありませんでした。 tech.smartcamp.co.jp 弊社のECS移行も稼働直前の佳境を迎えている最中ですが、この度Amazon ECS Execがリリースされ、待ち望んでいたECS/Fargate上のコンテナに対す
Amazon ECS on EC2でキャッシュされたコンテナイメージを使用するには? | DevelopersIO
ECS on EC2はエージェントの環境変数「ECS_IMAGE_PULL_BEHAVIOR」設定でコンテナイメージのキャッシュを利用できます。 Amazon ECS on EC2利用時に、コンテナの起動時間を短縮させるために、ホストでキャッシュされたコンテナイメージを使用したいことがあります。 Amazon ECS コンテナエージェントの環境変数「ECS_IMAGE_PULL_BEHAVIOR」を利用すると、イメージのプルプロセスをカスタマイズできます。 ECS_IMAGE_PULL_BEHAVIOR パラメーター 4つの中から選べます(説明文はマニュアルから引用)。 キャッシュを優先しない default : リモートでイメージがプルされます。イメージのプルに失敗した場合、コンテナはそのインスタンスにキャッシュされたイメージを使用します。 always : 常にリモートでイメージがプル
Under the hood: FireLens for Amazon ECS Tasks | Amazon Web Services
Containers Under the hood: FireLens for Amazon ECS Tasks September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details. Recently, Amazon ECS announced support for custom log routing via FireLens. FireLens makes it easy to use the popular open source logging projects Fluentd and Fluent Bit; enabling you to send logs to a wide array of AWS Services and pa
AWS ECS で FireLens ログドライバを試したメモ - Qiita
FireLens という ECS で EC2/Fargate のどちらの起動タイプでも使用できるログドライバが、パブリックプレビューで誰でも使用できるようになったので試してみたメモです。 Amazon ECS タスクから FluentBit, Fluentd を利用したログルーティングを可能にする "FireLens" ロギングドライバの Public Preview 開始です 👏👏👏 ECS, Fargate が利用できる全リージョンで今日からお試しいただけます！ / "Amazon ECS and AWS Fargate FireLens ..." https://t.co/ZJDxRyBalk — ポジティブな Tori (@toricls) August 31, 2019 これまでの状況 Fargate のログドライバはしばらくの間 CloudWatch Logs しか使用で
Deploy applications on Amazon ECS using Docker Compose | Amazon Web Services
Containers Deploy applications on Amazon ECS using Docker Compose Note: Docker Compose’s integration with Amazon ECS has been deprecated and is retiring in November 2023 There are many reasons why containers have become popular since Docker democratized access to the core Linux primitives that make a “docker run” possible. One reason is that containers are not tied to a specific infrastructure or
Amazon ECS サービスディスカバリ | Amazon Web Services
Amazon Web Services ブログ Amazon ECS サービスディスカバリ Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが Amazon Route 53 の予測可能でフレンドリーな DNS 名で自動的に登録することができるようになります。負荷やコンテナの健全状態に対応してサービスがスケールアップまたはダウンすると、Route 53 のホストゾーンは最新の状態が保たれ、他のサービスが各サービスの状態に基づいてコネクションを行う必要がある場所を発見できるようになります。次のアドレスで、架空のソーシャルネットワークアプリでサービスディスカバリのデモを見ることができます。https://servicediscovery.ranman.com/. マイクロサービスや最新のアーキテクチャへの移行の一部には、障害や変化する負荷に迅速に対
ECS task definition を Jsonnet で生成する - 酒日記 はてな支店
Amazon ECS でタスクの構成定義に使う task definition をリポジトリで管理する場合、JSON 形式で取り扱うことが多いと思います。 ECS デプロイツールである ecspresso でも、task definition は環境変数等を展開できる記法があるものの、基本的には JSON ファイルとして扱っています。 これは AWS コンソールで作成した task definition を aws describe-task-definition や ecspresso init コマンドでファイルとして取り出して利用することを前提としているためで、これを YAML や別の形式で扱うことは考えていません。 ところで、実際に ECS でそれなりのサービスを運用すると、task definition JSON の管理で悩むことが増えてきました。 JSON は人間が編集するのに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSにおけるアプリチームとインフラチームのコワーク設計 / Co-working Design about App and Infra on AWS
AWS Step Functions and Fargate task: container runtime error does not cause pipeline to fail
[ECS] [Proposal]: ECS Execute-Command proposal · Issue #1050 · aws/containers-roadmap![[ECS] [Proposal]: ECS Execute-Command proposal · Issue #1050 · aws/containers-roadmap](https://cdn-ak-scissors.b.st-hatena.com/image/square/2cb9186290c7c3d9e24341902f8c4272e73d8877/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2Ff568b79010ce3e346d06766e8282f0089be928de5c86a4c493858bdb0af04870%2Faws%2Fcontainers-roadmap%2Fissues%2F1050)
GitHub - aws-containers/amazon-ecs-exec-checker: 🚀 Pre-flight checks for ECS Exec
