[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)
ECS on EC2 から ECS on Fargate への移行で考慮した4つのポイント - Link and Motivation Developers' Blog
こんにちは、リンクアンドモチベーション SREグループの久原です。今回はSREチーム内で取り組んでいるAmazon ECS on Amazon EC2(以下 ECS on EC2)構成からAmazon ECS on AWS Fargate(以下ECS on Fargate)構成への移行プロジェクトについて、特にEC2とFargateの差分を中心にお話しできればと思います。 背景 サーバーレスへの移行に関するメリットについてはここでは詳しくは触れませんが、一般的に言われているように サーバー管理等の運用コスト削減 が主な移行の背景となります。 弊社ではこちらの記事に記載のある通り、4Keys Metricsという指標をモニタリングし、開発組織の継続的な改善活動に取り組んでいます。 開発フローの細かな改善も重要ですが、より高いレベルに進化させるためには抜本的なアーキテクチャの見直しが必要となり
ECSからEKSへの移行への移行事例の紹介
発表資料の中に出てくるURLです。 * [Amazon EKSでのArgoCDを使ったGitOps CD](https://tech.recruit-mp.co.jp/infrastructure/gitops-cd-by-using-argo-cd-at-eks/) * [EnvoyとAmazon ECS Service Discoveryを利用したgRPCの負荷分散](https://tech.recruit-mp.co.jp/infrastructure/post-17098/) * [Amazon EKSでAWS App Meshを利用してgRPCサーバーを運用する](https://tech.recruit-mp.co.jp/infrastructure/post-20765/) * [https://tech.recruit-mp.co.jp/infrastructure/po
ECSのARNとResource IDのフォーマット設定してなくてハマった - Qiita
InvalidParameterException: The new ARN and resource ID format must be enabled to add tags to the service. Opt in to the new format and try again. ECSで遊んでみようとTerraformで遊んでいたら、 ECSのServiceリソースを生成する際に上記のようなリクエストエラーが返ってきた。 意外と知らなくて詰まったのでその対処方法。 環境 macOS Mojave 10.14.5 terraform: v0.12.13 対処方法 参考になったのは下記の2ページ。 AWSのブログのこの画像の通りですが、下画像のECSのアカウント設定ページで設定を行う必要がありました。結構書籍や実践例はこの設定を以前に行なっているユーザーでTerraformでリソー
毎日生まれ変わるセキュアな踏み台サーバ - Hatena Developer Blog
こんにちは。 はてなインターン2019 システム基盤開発コースでやったことをお話していきます。 今年のシステム基盤開発コースでは、コードネームphoenixと題して、「毎日生まれ変わるセキュアな踏み台サーバ」の作成に取り組みました。 なぜつくったのか 踏み台サーバ なぜ毎日生まれ変わるのか なぜコンテナを使ったのか 踏み台サーバを更新する仕組み SSMセッションを用いたログイン CloudFormationによる自動デプロイ（未完） Terraformによる自動デプロイ 感想など なぜつくったのか まずはじめに、なぜこのような踏み台サーバの構築を行うことになったのかについて説明します。 多くの現場でもそうであると想像されるように、現状のはてなでは様々な社内サービスや、稼働中のサーバー・データベースにアクセスするために踏み台サーバを経由する必要があります。はてなには種々のサービスが存在してい
AWS x Docker x Goで始める新規サーバーサイド開発
はじめまして。株式会社トルテでサーバーサイドを担当している中川です。 レディーファーストの恋アプリTorteを開発しています。 https://sweet-torte.com/ 今年8月にリリースしたTorteのサーバーサイドのアーキテクチャについて、技術選定の理由やTipsと共にご紹介いたします。 技術選定 Go + Docker 以前担当していたサービスで急激な高負荷に耐えられないことが多々あり、EC2を使ったスケールに限界を感じていました。Docker Containerを使ったオートスケールやデプロイに関心があり、今回はDockerと、シングルバイナリで稼働して相性が良いGo言語を採用する運びとなりました。サイバーエージェントグループでの採用事例もあり、新規ならDocker + Goという流れがあったので、採用にあたって特に障壁はありませんでした。 Cloud Service クラ
スタディサプリ on Quipper プラットフォームを支える技術 - hakobera's blog
前置き hakobera.hatenablog.com この記事を公開した当時はまだオープンにできなかったのですが、実はこの記事は2月25日にリリースされたスタディサプリ（受験サプリ）を Quipper のプラットフォームに載せ替えるという移行プロジェクトを前提として内容も含んでいました。 【公式】スタディサプリ｜苦手克服・定期テスト対策～大学受験まで 無事にリリースできたので、このプロジェクトで変わったことや導入したソフトウェア、ツールについていくつかピックアップして書いていきたいと思います。 目次 メンバーが増えた Infra as Code Deis AWS ECS + Docker + Locust による負荷テスト nginx (HTTP/2, ngx_mruby) 分析基盤 技術的課題 メンバーが増えた 前回の記事を書いた時はインフラ関連のエンジニア（Quipper では En
ECS + ecs-cli + Locust + consul でカヂュアルにスケールする負荷試験を構築する考察 - ようへいの日々精進XP
ども、かっぱです。 tl;dr 考察シリーズ第三弾。 hakobera.hatenablog.com 上記の記事で紹介されていた「AWS ECS + Docker + Locust による負荷テスト」について、どんな風に実現するんだろうなあとずーっと気になっていたので、自分なりに ECS + Locust な負荷試験環境を考えてみたのでメモ。 メモ こんな感じになった（ゴール） ソースコードとか github.com 何をする必要があったのか Locust Master と Locust Slave をそれぞれ異なるタスクに分割する 同一の ECS クラスタに Master と Slave を個別にデプロイする コンテナインスタンスを跨って Locust クラサバ構成を構築する必要があったので etcd や Consul にお出まし頂いた（結局は Consul を採用した） 困った点 Do
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
