[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
この記事について みなさん、ECS利用していますか！？ AWSでコンテナを使うのなら、ECSですよね！?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが１つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル（以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく
![[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media](https://cdn-ak-scissors.b.st-hatena.com/image/square/44fc1474c22e3382588fd4b15ee70ff7f704163b/height=288;version=1;width=512/https%3A%2F%2Firet.media%2Fwp-content%2Fuploads%2F2021%2F07%2Fimg-eyecatch-aws-02-1200x630.png)
Amazon ECS の Blue/Green デプロイメントの動作は何が起こっているか解説したい - Qiita
はじめに Amazon ECS は、コンテナを動かしうまく管理するためのコンテナオーケストレーションサービスです。新たなバージョンのコンテナをデプロイするときに、いろいろなデプロイの方法が取れますが、ECS 側で用意されているデプロイ戦略が3種類あります Rolling Update : Service の中で稼働しているタスクを少しずつ順繰りアップデートする方式 Blue/Green Deployment : 新たな環境である Green 環境を用意して、LB レイヤーで切り替える方式 External Deployment : 外部のサードパーティの何かでデプロイをコントロールする方式 こちらの Document に記載があります。 : https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-types.htm
ECSで開発用と本番用のCodePipelineを作る
version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: <TASK_DEFINITION> LoadBalancerInfo: ContainerName: "app-container" ContainerPort: 3000 ビルド時に必要な環境変数があればssmのパラメータストアから渡す。ssmからも渡せる。 AWS_ACCOUNT_IDとAWS_DEFAULT_REGIONとIMAGE_NAMEに関してはcode buildの環境変数で定義している。 buildspec.yaml version: 0.2 env: parameter-store: DOCKER_USER: dockerhub-user DOCKER_TOKEN: dockerhub-t
ALB と docker ヘルスチェックによる ECS の挙動について
AWS による docker コンテナのオーケストレーションサービスである Amazon ECS / Fargate のヘルスチェックの挙動について調査する機会がありましたのでアウトプットしておきたいと思います。 前提として Fargate で ECS のサービスとして、ロードバランサーは Application Load Balancer（ALB）を利用して実行するケースで調査しました。網羅的ではない点、ご了承ください。 ECS におけるヘルスチェック さて、ECS でサービスを実行する上で、いわゆる「ヘルスチェック」は2種類あります。 Elastic Load Balancer（今回は ALB）に関連付けられる Target Group によるヘルスチェック タスク定義のコンテナに対して実行する docker によるヘルスチェック（参考 : docker ドキュメント, AWS ドキュ
Amazon ECS向けAmazon CloudWatch Container Insightsについて | Amazon Web Services
Amazon Web Services ブログ Amazon ECS向けAmazon CloudWatch Container Insightsについて 本記事は AWS のシニアソリューションアーキテクトの Sirirat Kongdeeによる寄稿記事です。 Amazon CloudWatch を利用することで、Amazon Elastic Container Service（Amazon ECS）のリソースを監視することができます。Amazon CloudWatchは、CPU やメモリの割り当てについてや、クラスター、サービスレベルでのリソース使用率のメトリクスを提供するサービスです。以前は、サービスとタスクについてカスタムモニタリングを有効にする必要がありましたが、CloudWatch Container Insightsを使用することで、すべての Amazon ECS リソースの監
「それコンテナにする意味あんの？」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019 | DevelopersIO
みなさんコンテナを使うことの意味を自信もって答えられるでしょうか？ ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。 「それはコンテナ化する意味があるの？」 「こんなコンテナ運用は危ない？」 「ECSの設定とか実際めんどい。docker runじゃだめ？」 「EKSって使えんの？」 そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。 「このアプリをコンテナ化する意味があるのか、わからない」 「コンテナ化することで余計めんどくさくなった」 「AWSのコンテナサービスの何を使ったら良いのかわからない」 という悩みを抱えている方には、
Building a scalable log solution aggregator with AWS Fargate, Fluentd, and Amazon Kinesis Data Firehose | Amazon Web Services
AWS Compute Blog Building a scalable log solution aggregator with AWS Fargate, Fluentd, and Amazon Kinesis Data Firehose February 12, 2024: Amazon Kinesis Data Firehose has been renamed to Amazon Data Firehose. Read the AWS What’s New post to learn more. September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details. This post is contributed by Wesley Pe
オンラインサービスをECS on Spot Instanceで構築＆運用した - Gunosy Tech Blog
広告技術部のUT(@mocyuto)です。 最近またポケモンGOをちょっとやり始めてしまいました。 今回はオンラインの広告サービスをSpotInstanceを利用したECSで構築し、2ヶ月ほど運用した話を紹介したいと思います。 はじめに アーキテクチャ設計 広告配信 ログ設計 EBSのログ運用 デプロイ設計 canaryデプロイ まとめ はじめに 今まで広告の部署では、コンテナの本番運用はバッチのみでした。 tech.gunosy.io ECS上でdigdagを運用しているものを以前紹介しましたが、オンラインでの大きなトラフィックが流入するものをECSに構築するのは初めてです。 今回、新しいサービスを作成するタイミングだったのでECS*1上にサービスを構築することにしました。 アーキテクチャ設計 今回は単一のECS Clusterに管理画面のサービスと配信系のサービスを同居させ、コスト効率
EC2上のPythonバッチをECSのDigdagに置き換えた話 - Gunosy Tech Blog
広告技術部のUT@mocyutoです。 ついに桜が開花し、やっと春の訪れを感じはじめましたね。 外で気持ちよく飲みたい季節になってきました。 はじめに システム概要 なぜ移行するのか Celeryをやめたい LevelDBをやめたい 移行計画 アーキテクチャ ECS Athena CI/CDフロー Pluginか自前実装か 移行後 よかったこと まとめ はじめに 今回はEC2上のPythonのバッチをECSのDigdagに置き換えた話をします。 システム概要 今回の移行対象は広告配信に関するバッチ処理を行うシステムでした。 役割としては以下のようなものがあります。 広告の配信候補を作成 広告の枠情報を作成 クリックなどのイベントの集計 なぜ移行するのか 大きく分けて以下の２つの理由がありました。 Celeryをやめたい LevelDBをやめたい Celeryをやめたい 今まではバッチにはP
AWS ECS Blue Green Deploymentのサンプルの挙動を解説します
どうもkoarakkoです。今回はAmazon Web Services（以下AWS）のAmazon Elastic Container Service(Amazon ECS)を使ったBlue Green Deploymentについて書きたいと思います。 Blue Green Deploymentとは？ Blue Green Deploymentとは、開発用DB(以下Dev)と本番用DB(以下Prod)を同時に稼働させ、テストが終わったタイミングでバサッとDevとProdを切り替えるデプロイメント手法の一つです。DevからProdまたはProdからDevへの切り替えを瞬時に行うことができるのが特徴です。 さあ、ここで考えてみましょう もし、あなたが本番へ切り替えたあと、何か不都合があった際に、旧環境への切り戻しを早急にやらなければならないシチュエーションがあるかもしれません。 そんな時に、
CodePipelineからECSにBlue/Greenデプロイする | DevelopersIO
こんにちは、かたいなかです。 以前、ECSがCodeDeployによるBlue/Greenデプロイに対応したことをお伝えしました。 今回は、CodePipelineからECS+CodeDeployへのデプロイを行うことで、CodeBuildでDockerイメージをビルドし、ビルドしたイメージをもとにタスク定義の新しいリビジョンを登録、ECSのサービスを更新するといった一連の流れを自動で行えるようにする方法をご紹介します。 構築するパイプラインの概要 今回は、以下のようなパイプラインを構成します。 GitHubの特定のブランチを変更を契機に処理を開始します。CodeBuildでイメージをビルドし、ECRにプッシュします。そして、最後にCodeDeploy + ECSを使用してデプロイを行うという流れです。 手順 では、実際にやっていきましょう。 設定としては以下の流れで進めます。 CodeD
ECSでコンテナのrolling update - Carpe Diem
概要 ECS上のコンテナをダウンタイム０で更新（デプロイ）する方法をまとめます。 環境 ALB ECS container agent 1.13.0 Docker 1.11.2 Amazon ECS Container Agent Versions - Amazon EC2 Container Service ポイント minimumHealthyPercentとmaximumPercentを適切に設定する connection drainingを適切な長さにする この２つを意識していればOKです。 minimumHealthyPercentとmaximumPercentを適切に設定する desiredCount: 4、min: 0%、max: 100%の場合 この場合最低０つ(0%)まで縮小し、最高でも４つ(100%)までしか増えない状態で更新するということになります。 つまりダウンタイ
Amazon ECS でコンテナをローリングアップデートする - Qiita
はじめに ECSのローリングアップデートの動作を確認しましたので、備忘録として投稿します。 もくじ 旧バージョンのコンテナをデプロイ 新しいリビジョンのタスク定義を作成 サービスを更新して新バージョンのコンテナをデプロイ ローリングアップデートの流れ 参考 ECSでコンテナのrolling update - Carpe Diem Amazon ECS launches new deployment capabilities; CloudWatch metrics; Singapore and Frankfurt regions | AWS Compute Blog コンテナイメージについて ローリングアップデートの動作確認用にECRへv1、v2とタグ付けしたコンテナイメージをプッシュしておきます。 今回の投稿では v1 旧バージョンのコンテナイメージ v2 新バージョンのコンテナイメージ
ECS(Fargate)でコンテナアプリケーションを動かすための設定情報の扱い方 - BASEプロダクトチームブログ
あけましておめでとうございます。 BASE BANK株式会社でソフトウェアエンジニアをやっている東口（@hgsgtk）です。 2018年末から年明けにかけて、EKSが東京リージョンに来たりAWSからのリリースが賑わいを見せていますが、その中から、AWS Fargateの次の新機能を実際のプロダクトに適用しました。 AWS Fargate プラットフォームバージョン 1.3 でシークレットのサポートを追加 これを期に、コンテナアプリケーションにおける設定情報を扱う考え方・それを実現するためのAWSのサービス構成と得られた利点についてまとめてみようと思います。 目次 設定情報の扱いに対する要件 コンテナベースの設計思想・原則 ECS(Fargate)を用いる場合の設定情報の扱い方 設定情報の扱いに対する要件 開発背景 BASE BANK社では、即時に資金調達ができる金融サービス「YELL BA
ECSでごっつ簡単に機密情報を環境変数に展開できるようになりました！ | DevelopersIO
従来アプリケーション側で必須だった機密情報の復号化が、マネージドな仕組みで実現できるようになりました。 これでついにあんな秘密やこんな秘密をコンテナに渡しやすくなりますね — ポジティブな Tori (@toricls) 2018年11月16日 先日のアップデートで、ECSコンテナ内への機密情報の受け渡しが非常に簡単になりました。 従来は機密情報の展開にアプリケーション側での処理が必要だったものが、マネージドな仕組みで実現可能となっているので、既存ECSユーザーには必見のアップデートとなっております。 参考：AWS Launches Secrets Support for Amazon Elastic Container Service あんなことやこんなこと！？ ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ / 従来の方法の面倒くささ（自前で機密情報を展開していた
ECSのHEALTHCHECKオプションでサービスの継続性を高めよう | DevelopersIO
ECSでは、Fargateや従来のECSサービスで「HEALTHCHECK」オプションを利用できるようになっています。 Amazon ECSはコンテナの健全性チェックとタスクの健全性管理をサポート AWS Fargate プラットフォームのバージョン 1.1 が、タスクメタデータ、コンテナのヘルスチェック、サービスディスカバリのサポートを追加 Docker自体は1.12以降で「HEALTHCHECK」オプションを利用することができますが、ECSで利用するとステータスが「不健康」なタスクを止めて新しいものに置き換えることが自動で可能になります。 DockerのSwarmモードだと、HEALTCHCHCK機能を使ってサービスの再起動をすることができますが、同じことがECSでも可能になった、ということになります。 ECSでHEALTHCHECKオプションを設定する すでにECS環境は作成されてい
Amazon EC2 Container Service(ECS)の概念整理 - Qiita
概念図 とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。 図1 概念図 Serviceが中心 ECSは平たく言うと クラスター（＝複数EC2インスタンスの集合）の上で Dockerコンテナを使って、 Serviceを動作させる ものです。 図2 例えばの構成 上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの） API Service （ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの） と言う２つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ
RundeckをECS上に構築してGitHubログインできるようにする - PartyIX
この記事はscouty Advent Calendar 2018 の3日目です． ECSで動かしているサービスのスケジュールジョブが多くなってきた． もともとECS Scheduled Taskを使っていたんだけど，数十個レベルになってくると，これで管理するのはだいぶつらい． というわけでRundeckを構築したメモ． そもそもECS Scheduled Taskやる気あんの？ ECS Scheduled Taskの辛いところ． Scheduled Taskは既存のTaskDefinitionを上書きしてタスクを実行するため，Override用にjsonでTaskDefinitionの一部を与える必要がある Scheduled Taskの一覧画面はあるのだが，そこから「何時に，どのタスクIDで実行されたか」を知る術がない そんなだから，タスクが正常に終了したのか，何かのエラーで途中終了した
[AWS]ECSとALBを使ったパスに従ったルーティング | DevelopersIO
コンニチハ、千葉です。 ALBのパスベースルーティングを利用すると、URLに従ったターゲットグループ(インスタンスのグループ)へルーティングできます。ECSも、こちらのパスベースルーティングに対応しているため試して見ました。 【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました メリット 振り分けのイメージです。 このように1つのALB、1つのECSクラスター上で、ECSサービス(コンテナ群)に対しパスルーティングを行えます。これの応用ですが、以下のような構成も可能です。 Classicロードバランサー時代アプリケーションを分けるには、アプリケーションごとにロードバランサーを用意する、または1つのロードバランサーとアプリケーションごとにポートを用意するという構成しかありませんでした。 大きなメリットしてALBでは、ロードバランサー1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AmazonがAWS Firelensを発表、コンテナログの新たな管理方法
