Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに AWS Elastic Container Service (ECS)は、Docker コンテナを簡単に実行できるようにするためのフルマネージド型のコンテナオーケストレーションサービスです。ここでは、ECSをEC2インスタンスと一緒に使用する方法を紹介します。特に、Fargateとは異なり、EC2を使用する場合はEC2インスタンスをECSに登録する必要があります。本記事ではその登録手順を記載しいます。 IAMロール作成 まず始めに、任意のIAMロールを作成し、以下の2つのポリシーをアタッチします。 AmazonEC2ContainerServiceforEC2Role AmazonSSMFullAccess ※EC2インスタンスにセッションマネージャーで接続したくAmazonSSMFullAccessを設定しています。 EC2インスタンスの作成 Amazon ECS最適化 AMI
めちゃくちゃ苦戦したのでメモ。 困ったこと Django のアプリを ECS(FARGATE) 上で動かすと Invalid HTTP_HOST header: '10.0.X.Y'. You may need to add '10.0.X.Y' to ALLOWED_HOSTS. みたいなエラーが出て、 ELB のヘルスチェックで落ちる。 だからといって、 ALLOWED_HOSTS = ['*'] みたいにするのはセキュリティ的にも気持ち的にもやりたくない。 解決策 Stack overflow に同じ問題にぶち当たっている人がいた。 stackoverflow.com 通常の ALLOWED_HOSTS の設定の下に、以下を追加すれば良いみたい。 try: resp = requests.get('http://169.254.170.2/v2/metadata') data = r
本資料は書きかけのメモです。もう少し中身が分かったら、詳細に書く予定です。 Dockerを使う Dockerを使うのですが、環境を整えるのが面倒なのでECSを使えないかと考えたので、そのメモです。 Amazon ECSの概念整理 クラスタ ECSが動作するEC2インスタンスをまとめて管理する単位として、「クラスタ」という概念を用います。クラスタを作るとCloudFormationで環境作ってくれます。 ECS インスタンス ECSを動作させるEC2インスタンスをECSインスタンスと呼びます。 クラスタの管理タブの一つとして表示されます。 実際のアクセスポイントはこのインスタンスのIPアドレスなどになるため、パブリックIPなどを確認します。 タスク定義 タスク定義は複数のコンテナを合わせて一つの集合をタスク・サービスと概念化して、その定義ファイルを「タスク定義」として管理します。 コンテナ定
フロントエンドはreact、バックエンドはlaravelっていうよくあるSPA構成をAWSのECSにデプロイするのはかなり大変だった。 慣れていればかんたんなのだろうが、不慣れなうちはみるみる工数が溶けてしまう。 本当にECSにデプロイすべきなのか検討してほしい。 開発環境の構築はかんたん。dockerのノリでECSを触ると火傷するよ 開発環境は、もちろん出来合いのdocker-composeでかんたんに構築できる。フロントエンドはyarn startとかyarn devとかでlocalhostにサーバーが立ち上がるし、バックエンドはlaravelなので特に難しいところはなにもない。 ECSにデプロイする ECSにデプロイするためには、フロントエンドもバックエンドもビルドして固めないといけない。 laravelを含めたバックエンドのビルド よくある開発用のdocker-composeファイ
https://qiita.com/sekikatsu/items/992e82671aa505c5a652 の続きです。 ローカル環境でlocustを実行できるようになったので、クラウドの豊富なマシンパワーを使って負荷掛けができるようにします。 Terraformを使って本格的にやる場合は https://qiita.com/neilli-sable/items/b17dfba5eabfcafccaf8 など既存記事があるので、ご参考ください。 この記事は、ECSを初めて使うくらいの人が、とりあえずAWS Webコンソールを使ってlocustを動かしてみる、という内容です。 序章 「ローカルで動いてるんだからAWSに移行するのも簡単やろ」と思ってたら、全然簡単じゃなかった。ECSのハードル高い。 とりあえず、スタート時点での知識レベルは以下くらい ECS: AWSでコンテナ使うためのサー
はじめに 以前の記事で、ECS on Fargateを用いてWebサイトの構築を行いました。 何か問題が起きた際に既存Fargateに接続したいということがあるかと思います。 そこで、Serverworks様の記事を参考に、Fargateに接続できるまでの手順をまとめていきたいと思います。 個人環境 Windows10 AWS CLIのインストール AWS CLIがインストールされていない場合は、公開されているインストール手順を参考に、AWS CLIのインストールを行います。 ※特に変更などせずデフォルトのままインストールを行っています。 ※AWS CLIに任意の認証情報を設定してください。 AWS CLI用のSession Managerプラグインのインストール Session Managerプラグインがインストールされていない場合は、公開されているインストール手順を参考に、Sessio
はじめに エアークローゼットのエンジニアアインです。 この記事はエアークローゼット Advent Calendar 2023 24日目の記事になります。 各マイクロサービス連携する マイクロサービス内に各サービス連携するのはよくあります。以下の方法を通じて連携できる: API calling: HTTPまたはRPCで実施する方法。 イベント駆動: イベント発火で各サービス連携する方法。 本記事は「イベント駆動」方法を中心として書かせていただきます。 SAGAパターン 各サービスが独自のデータベースを持っているため、service-Aがservice-Bを呼ぶと、異なるデータベース上でトランザクションを実行する必要があります。注意すべきは、異なるデータベース上でACIDトランザクションを実行できません。 SAGAで複数データベース上でトランザクション実行できます。 具体的には それぞれのロー
CODE DEPLOY で appspec をうまく書けずに試行錯誤していた。 設定 CodePiplineのDeployステージのアクション設定でプロバイダを AWS ECS(ブルー/グリーン)にしている前提 デプロイ実行時のエラー CodeBuildの「デプロイID」のページに表示されたエラー。こんなやつ。 appspecファイルが見つからない An AppSpec file is required, but could not be found in the revision レポジトリのトップに appspec.yml を置いてあるのにないと言われる 解決 buildspec.yml の artifacts に appspecファイルを指定すると解決した
インターネットゲートウェイ 作成したら、右上のアクション>VPCにアタッチから、 sample-vpcにアタッチするのを忘れずに。 エンドポイント この後設定していくサービスを利用するために、4つのエンドポイントを設けます。 com.amazonaws.ap-northeast-1.ecr.api com.amazonaws.ap-northeast-1.ecr.dkr com.amazonaws.ap-northeast-1.s3 com.amazonaws.ap-northeast-1.ssm エンドポイントを選択して、 アタッチしたいサブネットはpublic-subnet-a,public-subnet-cの2つのみ指定。 Interfaceタイプのエンドポイントには、セキュリティグループを適用する。 エンドポイント用のセキュリティグループとして、443ポートを開けたセキュリティグル
[AWS][ECS][Fargate]RailsをCircleCIでデプロイする前にDockerfileでやること投稿者: adachin 投稿日: 2020/02/222020/02/22 本番コンテナの(ECS/Fargate)運用で、一番大変なのはコンテナの設計とデプロイ方法です。ここをしっかり決めておかないと開発環境から全てやり直しになります。この2週間はだいぶハマりまくったのでだいぶ知見が増えました。今回はRailsでCircleCIのデプロイよりも前のDockerfileでやることをブログします。 ■デプロイする前にDockerfileでやることって? まずCircleCIを使わずにECRへpushする場合はローカルで docker build してからpushする流れが一般的です。実際のフローは以下。 Dockerfileでの各パッケージをインストール Dockerfileで
AWS ECSのCodePipeline(blue/green CodeDeploy)におけるtaskdef.jsonをcodebuild内で作成する。 クラウド事業部の原口です。 さて、今回はblue/greenデプロイにおけるタスク定義の管理方法について少し考えてみました。 AWS ECSのCI/CD環境としてはCodePipeline(CodeCommit -> CodeBuild -> CodeDeploy )を使った自動化を利用していますが、taskdef.jsonの管理に困っていました。 困ってたこと・インフラとアプリのリポジトリは別でtaskdef.jsonをどちらで管理するのがよいか悩んでいた ・というか、タスク定義は緊急でマネージメントコンソールからぽちぽちして修正される時があったり(!) ・stageやproductionなどの環境の違いによってどう管理していけばよいか
タスク定義で、コンテナの編集のヘルスチェックの欄には下のようなコマンドを書く。mariadbコンテナの場合を例とする。 CMD-SHELL,mysqladmin ping -u [mysqlのユーザー名] -p[パスワード] -h 127.0.0.1 || exit 1 CMD-SHELL コンテナのデフォルトシェルを開始する(windowsでいうところのコマンドプロンプトを起動する) , カンマ区切りで複数のコマンドを実行する mysqladmin ping -u [mysqlのユーザー名] -p[パスワード] -h 127.0.0.1 mysqlコンテナとmariadbコンテナの場合、このコマンドが成功すればコンテナが起動している サーバが起動中であるかを確認するコマンド pとパスワードの間はスペース不要 127.0.0.1は自分自身のIPアドレス || 左のコマンドが失敗したときに右
ECSは、クラウドのサーバ上で簡単にコンテナを動かせるサービスです。 ECSの実行環境は、EC2(自分で触れるサーバ)かFargate(フルマネージドなコンテナ専用サーバ)から選ぶことができます。今回はFargateを使って、サーバ運用のことをなんにも考えずにコンテナ実行を体験します。 チュートリアルはこちらから https://console.aws.amazon.com/ecs/home#/firstRun やること1. タスク定義 実行するコンテナイメージを選びます。サンプルが用意されてるのでこちらを使います。イタレリツクセリです。 タスクはアプリケーションとしてのまとまりで、1〜10個のコンテナでつくります。このチュートリアルのタスク定義では、Webサーバーのコンテナひとつだけが登録されます。 2. サービスの設定 サービスはタスクを指定した数だけ維持するひと。あとロードバランサー
以下の記事のパート3です。 【パート1】開発環境の準備 【パート2】Embulkコンテナの作成・単体テスト 【パート3】ECSのタスク定義と動作確認(★本記事) 【パート4】Step Functionsで簡単に実行できるように設定する 前回までのパートで、ECSでEmbulkを実行するための準備が完了しました。満を持してECSの設定をしていきましょう。 本編に入る前にECSに関して前提の知識を振り返っておきます。詳しくは手を動かしながら確認していってみるのがおすすめです! ・ECSはAWSが提供するコンテナのワークロードを実行するための多種多様な機能を持つコンテナ管理のためのマネージドサービス ・ECSはあくまでコンテナを実行するためのコントロールに徹していて、実際にコンテナを起動する基盤(クラスター)は「EC2」か「Fargate」を選べる(ほかにも外部のクラスターもあります) ・ECS
できるだけ簡易なPHPアプリケーションを題材にDockerでローカル開発環境を作り、AWS ECSにプッシュするところまで行う。 0.事前準備 ・Docker for Mac のインストール https://store.docker.com/editions/community/docker-ce-desktop-mac ・AWSアカウント https://aws.amazon.com/jp/register-flow/ Dockerでローカル開発環境構築 1.Docker基本コマンドの確認 Dockerを利用したことのない人のために基本コマンドを確認します. 本稿では細かい技術的な内容には触れません. Dockerの更に詳細な事を知りたい場合はDockerドキュメントを当たりましょう. ・イメージの一覧 docker images ・「すべての」イメージを表示(デフォルトは中間コンテナを
初めに AWS SAA学習時にAWS ECSについて触れたことがあり、おさらいとはなるが、改めてECSのハンズオンをやってみた。 ハンズオン教材 ECSの教材を探していたが、Cloud9を使い初心者でも挑戦しやすい内容のため、今回こちらでECR/ECSのコンテナ環境に触れてみたい。(Fargateはここでは扱わないこととする。) ハンズオン Cloud Formation上でネットワーク構築を実施 テンプレートは事前準備にあるハンズオンコンテンツをダウンロード オプションはデフォルトのままとする。 作成されたのを確認する。 ALB セキュリティグループ作成 ALB作成 GUIが変わっているから注意。 作成されていることを確認する。 不要なリスナーとターゲットグループは削除。 ECRリポジトリ作成 ECRリポジトリ作成後のプッシュコマンドの手順をメモしておく。 Cloud9作成 先ほどメモし
本記事は、Snowflake Advent Calendar 2022 その 2 の 3日目の記事です。 背景 筆者の所属企業では、約 2 年前に Snowflake を導入した際に、各種リソースの構成管理方法・デプロイ方法として、Terraform を導入しました。 当初は、Terraform で何でも管理しようと試みていましたが、以下の理由により、テーブルやビューといったデータ関係のリソースについてはデータ変換ツール dbt の OSS 版 dbt core を導入しました。 Terraform で大量のリソース管理を行うと、Terraform ステート更新に伴う計算量が増大し、必要な CPU・メモリ量が増加、またデプロイが完了するまでの時間が増大した。 デプロイ対象として、テーブルやビューの数が多いが、利用者に Terraform を学習させるのはコストがかかる。Terraform
AWS ECSの概要とアプリケーション環境構成 「Amazon Elastic Container Service(Amazon ECS)」は、クラスタ単位でDockerコンテナを簡単にスケーラブルかつ高速に実行/停止/管理できるコンテナ管理サービスです。 Linuxサーバ環境でDockerコンテナを単純に運用する場合と比較して、ECSではリージョン内の複数のアベイラビリティゾーンをまたいでコンテナを実行できるため、可用性の高い運用が可能です。2019年1月時点では、1つまたは複数のEC2上にクラスタを構築し、その上に任意のレジストリにあるDockerイメージをデプロイする「EC2起動型」と、実行するクラスタ自体をマネージドとしてAWSが自動で管理し、コンテナだけを意識する「Fargate」に分類できます。 本稿では理解を深めるために、EC2クラスタ型でECSアプリケーションを構築するもの
これはなに? Kyash Advent Calendar 2020 21日目の記事です。 今回はKyashに導入した負荷試験環境について紹介します。 経緯 Kyashでは決済や入金周りの性能試験は実施していましたが、シナリオベースの負荷試験など不十分な部分がありました。 そのためキャンペーンなどで通常より多くのアクセスが発生した場合に、 どのくらい耐えれるのか どこのサーバがボトルネックか 適切なスケール具合はどの程度か などの情報で曖昧な部分がありました。 そこでシナリオベースな負荷試験を実施することにより、 事前にどの程度までスケールすればどの程度の負荷まで耐えられるのかを把握し 適切なタイミングでの適切なスケーリングを実現することで システムを安定稼働をさせていきたいと考えました。 ツールの選定 負荷試験を実施するにあたり主な要件は下記でした。 loginしないといけないのでsess
概要 たまにVPC内のリソース(RDSやElastiCache)に手元のクライアントだったり、シェル経由でアクセスしたいことがあります。 そんな時に踏み台サーバーを用意するかと思うのですが、ECSのタスクを使うと素早く起動できて便利です。 やり方 事前にセッションマネージャープラグインをインストールして、タスクロールに必要な権限を当ててECS Execが使える状態にしておきます。 デバッグ用にAmazon ECS Exec を使用 - Amazon ECS まずタスク定義bastionを用意します。 踏み台サーバーに使いたいイメージを指定します。 ここではイメージにubuntu:latestを、コマンドはsleep 1hを指定しています。 (自分の場合、踏み台サーバーでの作業はそれほど長くないので1時間で終了するようにしています) あとはsession manager経由で入れるように -
はじめに 今回やりたいことのイメージ 構築の流れ この記事で作成するリソース 構築 1. IMA ロールの作成 2. 空のECSクラスタの作成 3. Auto Scaling 起動設定の作成 EC2起動時にECSコンテナインスタンスとして登録する 4. Auto Scaling グループの作成 5. ALBの作成 6. ECS サービスの作成 スケールアウトの設定 スケールインの設定 ECS コンテナインスタンスのオートスケーリング設定 動作確認 はじめに 「Docker(コンテナ) = 開発環境の構築に便利」という認識で止まっていましたが、最近では本番環境での利用のノウハウがネット上でも溜まりつつありますので、実際にどのようにして本番のコンテナ環境の構築・運用を実現しているのかを調べてみました。 独自のコンテナツールを利用している企業(Netflix等)もありましたが、AWS上ではAma
ECS ServiceのCPU使用率とタスク数をCloudWatch Alarm・SNS・ChatBotを利用して監視したいと思います。 リソース構築にはCloudFormation(以下CFnと略)を使います。 前提 監視対象のECS Cluster・Serviceが既に構築済み Container Insightsが有効になっている 要件 共通 正常(OK)・異常(ALARM)の通知 CPU使用率 80%を超過したら通知 タスク数 2個未満になったら通知 CFn AWSTemplateFormatVersion: 2010-09-09 #################################################### # Parameters #################################################### Paramete
AWSのコンテナサービス コンテナのオートストレーションサービス(EKSも同様のサービス)。 実行環境はFargate,EC2があり、イメージレジストリはECR。 コンテナが実行されるまでの流れ ①ユーザーがオーケストレーターに指示 ②仮想マシンにインストールされているエージェントからコンテナのランタイムを呼び出す ③イメージレジストリからコンテナイメージを取り出してコンテナを実行する ↓ 手作業によるミスオペや効率ダウンをなくす ECSの要素 タスク定義 ・コンテナの仕様書。 ・コンテナの定義(イメージの場所)、割り当てるIAMロールなどの情報が入っている。 ・JSON形式。 ・タスク定義は変更できない(イミュータブル)なので、更新したコンテナイメージ(古いイメージはバージョニングされているので別物)をタスク定義する(Familyパラメータ)。その後サービスを、古いものから新しいものに変
はじめに 前の記事で簡易的なECSクラスタを作成しました。 その続きとして、今回はタスク定義やサービスについて学びました。 タスク定義とは タスク定義はDockerコンテナの実行方法や起動タイプなどをECSに伝えるために必要なJSON形式のメタデータです。 タスク定義に基づいて実行されるコンテナ群のことをタスクといいます。 タスク定義には以下の情報が含まれます。 コンテナイメージ名 コンテナとホスト間のポートマッピング 必要CPU/RAM 環境変数 ネットワーク情報 IAMロール(タスクごとに定義) CloudWatchなどのログ設定 サービスとは サービスは以下の内容を設定する役割を持ちます。 タスク定義のコピー数を指定(何個のタスクを実行すべきかを補助) ELBとの連携(受信トラフィックを各コンテナに分散) 実装 Fargate起動タイプ、EC2起動タイプでそれぞれタスク定義とサービス
ECSの仕様で気になっていたことがあったので軽く調査しました。 というわけで早速ながら調査内容を共有させていただきます。 問題の内容 Agent versions <= 1.1.0:Nullと0のCPU値はDockerに0として渡され、Dockerはそれを1,024個のCPU配分に変換します。 1のCPU値はDockerに1として渡され、Linuxカーネルはそれを2個のCPU配分に変換します。 Agent versions >= 1.2.0:Null、0、1のCPU値はDockerに2個のCPU配分として渡されます。 引用:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html 気になったところというのはズバリ、ECSタスク定義のCPUユニットの割り当
Next.js(TypeScript), Rails, Docker, Vercel, AWS ECS(Fargate), Github Actions, Terraformを使用してポートフォリオを作成しました。RailsAWSDockerTerraformNext.js はじめに ポートフォリオとして作成したWebアプリケーションの紹介記事です。 開発アプリ概要 アプリ名: 近所の人たちと家で余っている食べ物をシェアするアプリ「Mottainai-zerowaste」 家庭内で発生するフードロスを解決するために作成したWebアプリです。 使用技術 Backend Rails 6.1.4.4(API mode) Ruby 2.7.2 Nginx Puma PostgreSQL 13.4 RSpec Rubocop Frontend Next.js 12.1.0 React 17.0.2
Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the executable that produces the output you
Wiki.js は無料で利用できる OSS の Wiki です。高速な Node.js エンジンで実行され、多機能でデザインもモダンな次世代の Wiki です。 Wiki.js の概要・特徴についてはこの記事にまとめています。 そんな Wiki.js を AWS Fargate 上にデプロイしてみます。 データベース Wiki.js はデータベースがないと起動できません。まずはデータベースを作成しましょう。 AWS コンソールの RDS のページから、「データベースの作成」を押下します。 データベースの作成方法を選択 : 標準作成 エンジンのオプション : MySQL エンジンバージョン : Mysql-8.0.35 テンプレート : 無料利用枠 DBインスタンス識別子 : wiki-js-mysql 認証情報の設定 マスターユーザ名 : admin マスターパスワード : wikis-s
ECS の CI/CD を GitHub Actions、Code シリーズ、Terraform というおいしいものづくしで作ります。 ECS の CI/CD は定番ものですが、構築にはいろいろなパターンがあるので、そのあたりに悩みつつも楽しみながら作ってみましょう 構築の方針 考えるポイントとしては、アプリとインフラの境界をどうするかというところです。本記事の CI/CD ではアプリの範囲はアプリ側の GitHub リポジトリで扱えるところまでとし、インフラは「それ以外すべて」と考えました。 ここをどう考えるかは、以下の記事がとても参考になります。上の記事ではパターン3、下の記事ではパターン 3-3 に近しいものを採用しました。 ECS の CI/CD において、アプリとインフラが構築に混在するのであれば、GitHub Actions + Code シリーズはファーストチョイスと考えてよ
はじめに ECSタスクをAWS Fargateで実行する際、Datadogを活用した監視やCloudWatch Logsを使ったログ管理が重要になります。 本記事では、Terraformを用いてECSタスク定義を構築する手順を解説します。 書こうと思ったきっかけ ECSタスクを運用する中で、コンテナの監視やログ管理を適切に設定しないと、トラブル時の原因特定が困難になると実感しました。 DatadogやCloudWatch Logsを組み合わせることで、リアルタイムの監視や効率的なデバッグが可能になるため、その方法を整理してみました。 実際に解説してみた このTerraformの設定は、AWS Fargate上で動作するECSタスク を定義しています。 タスクには、Datadog監視用のエージェントとアプリケーションコンテナが含まれており、CloudWatch Logsでログを管理 する構成
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 1.1 背景 クラウドアーキテクチャにおいて、スケーラブルなアプリケーションを構築することは重要な課題です。特に、マイクロサービス環境では、柔軟にリソースを増減できる仕組みが求められます。AWS の Elastic Container Service (ECS) と Simple Queue Service (SQS) を組み合わせることで、負荷に応じたスケール調整が可能になります。 本記事では、ECS とは何か、SQS とは何かを詳しく解説し、それらを組み合わせたスケーラブルなアーキテクチャの構築方法を詳細に説明します
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く