この記事は fujiwara-ware advent calendar 2024 の20日目です。 mirage-ecs とは mirage-ecs は、Amazon ECS で好きなだけブランチ別の環境を作るためのツールです。 「ブランチ別の環境」とは、例えば以下のようなものです。 main ブランチのコードをデプロイした URL main.example.com feature/xxx ブランチのコードをデプロイした URL xxx.example.com fix/yyy ブランチのコードをデプロイした URL yyy.example.com 多くのメンバーがいるチームで開発をしていると、それぞれのメンバーが作業をしているブランチごとにデプロイされた環境がほしくなります。そのような環境を手動で作るのは大変ですが、mirage-ecs を使えば簡単に作ることができます。 なぜ作ったのか
こんにちは、リードエンジニアの @dachi_023 です。今回はGitHub Actionsとecspressoでデプロイフローの構築をしたのでそれについて書いていきます。先に言っておくと簡単にセットアップできるし設定もシンプルなのでかなりおすすめです。 Actions | GitHub kayac/ecspresso: ecspresso is a deployment tool for Amazon ECS これまでのデプロイ コネヒトではECS環境へのデプロイに silinternational/ecs-deploy を採用しています。CodeBuildもしくはTravis CI上からecs-deployを利用してECS環境にアプリケーションをデプロイする構成です。 CI/CDツールの乗り換え検討 これまでずっとTravis CIを利用してきました。しかし 料金体系の変更 があった
Amazon Elastic Container Service (Amazon ECS) と AWS Fargate が Amazon Elastic Block Store (EBS) と統合されました。これにより、AWS Fargate や Amazon Elastic Compute Cloud (EC2) で実行されている Amazon ECS タスクに EBS ボリュームを、Amazon ECS API を使用して簡単にプロビジョニングしてアタッチできるようになりました。この機能により、サーバーレスコンテナを使用して、ETL ジョブ、メディアトランスコーディング、ML 推論ワークロードなど、ストレージやデータを大量に消費するアプリケーションをより簡単にデプロイできるようになります。 Amazon ECS タスクで EBS ボリュームを使用するには、タスク定義で EBS ボリュー
ECSにサービスをデプロイする場合、ecspresso を含めいろいろなツールがあり情報も多いですが、タスクのスケジューリング（cron的なもの）に関してはあまり情報が見つかりません。みんな定期実行どうしてるんでしょう 探してみると、ecspressoにインスパイアされた ecschedule というツールがありました。 実際に使ってみてなかなか良かったので、ecscheduleの使い方と注意点を紹介します。 インストール ecscheduleはGo製なので、go get か自分の開発環境にあった実行ファイルをパスの通った場所に置けば動きます。また、READMEには書いてありませんが、Macを使っている方はHomebrewでインストールできます。
AWS FargateでCDK Typescriptを使ってCodeDeplyを作成する。 CDKでFargateのCodeDeployを作成したので、記事を書きます。 本番環境にデプロイするときは、Codedeploy使ったほうがいいですよね。 またCDKで記述しておけば、後々らくです。 手作業に対するCodeDeployのメリット 公開する前に、同じ環境で、動作確認ができる。 一部の人に最初に公開し、問題ないか確認できる。 すぐに切り戻しができる。 ある程度、好きなタイミングで公開できる。 前置き すでにCDKでFargateを作成していること。今回の記事はCodeDeploy部分の解説です。 CodeDeployの動きなどは自分で調べてください。 サービスの命名はきちんと適切なものに変更してください。 サービスの修正 const loadBalancedFargateService
こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回はタイミーで実践しているECSのオートスケール戦略についてお話ししようと思います。 TL;DR タイミーではTarget Tracking ScalingとStep Scalingを組み合わせてオートスケールをしています Target Tracking Scaling -> 通常のスケールアウト・スケールイン Step Scaling -> スパイク時のスケールアウト 2つを組み合わせることで、様々なリクエストに対し適切なリソースを用意しています タイミーのアクセス量の変化とビジネス要求 タイミーのアクセス量の変化とこれまでのオートスケール タイミーは空いた時間に働きたい人とすぐに人手が欲しい店舗・企業をつなぐスキマバイトアプリです。 したがって、仕事の募集数や働いてくださるワーカーさんの数は世の中の動向に大きく左右されます
こんにちは。AWS Container Hero の新井です。 Amazon ECS の登場から間もなく 10 年が経ちますが、その間、ECS ⾃体の進化に加えて、さまざまな AWS マネージドサービスとの連携が可能になりました。 現在では、コンテナベースのワークロードを活⽤することで実現できないことを探す⽅が難しいほど、柔軟なアーキテクチャが構築できるようになっています。 しかし、⾃由度が⾼い分、要件に合ったアーキテクチャを模索する際には、迷うことも多いでしょう。 AWS上でシステムを適切に構築するためには、あらかじめサービス間のつなぎ⽅やパターン、その特徴を把握しておくことが重要です。 これにより、フィージビリティを迅速に確認でき、その後のトライアンドエラーのサイクルを加速させることができます。 今回は、最新の AWS サービスアップデートを踏まえつつ、Amazon ECS / AWS
バッチ実行環境を EC2+cron から StepFunctions + ECSonFargate + EventBridge に移行しました 新しく発足したシステム戦略推進チームの delikuです！ これまでPRONIアイミツシステムの定時バッチは、EC2 + cron で稼働していましたが、この度 cron + EC2 環境を脱却し、新しくマネージド環境に移行するようにしました。 システム戦略推進チームの役割各チームの開発プロセスにおける課題解決のサポートを行う 開発プロセスや技術における課題解決のサポートを行うことで各チームの向き合う領域へ集中できる環境を作る手助けをする 具体ではインフラ構成・リリース手順・自動テスト・バージョンアップ...など あるべきシステム境界を模索していく（寄せていく） ただ、手当たり次第に統合/分割はせず、時間軸やユースケースを見極める必要がある。そのた
Amazon ECS provides the ability to restart containers without requiring a task relaunch Amazon Elastic Container Services (Amazon ECS) now improves container resiliency by giving you the ability to define a flexible container restart policy for restarting individual containers locally, without requiring a full task relaunch. With local container restarts, Amazon ECS can recover your containers fro
Amazon ECSデプロイツール ecspresso v2.4.0 をリリースしたのでお知らせです。 github.com 目玉機能は Jsonnet native functions と ignore.tags です。どうぞご利用下さい。 github.com 新機能 Jsonnet native functions を追加 Add Jsonnet native functions by fujiwara · Pull Request #702 · kayac/ecspresso · GitHub Jsonnet で利用できる関数として env, must_env, tfstate, ssm など、テンプレート関数と同等のものを追加しました。 これまでの以下のような設定ファイルは # ecspresso.yml region: '{{ must_env `AWS_REGION` }}'
はじめに こんにちは。 Amazon ECSはCloudFormation経由でBlue/Greenデプロイを行うことができます。 挙動のイメージが湧かなかったので実際に動かして整理してみました。 図解 早速ですがスタックの更新によってBlue/Greenデプロイが起こった際の挙動を図にすると以下になります。（図内のリソースはスタックの新規作成時に作成されていた前提） 検証に使ったコード (AWS CDK) を参考で以下に置いておきます。↑の図の構成を実現できます。 lib/ecs-bg-stack.ts import { aws_ecs as ecs, aws_ec2 as ec2, aws_elasticloadbalancingv2 as elbv2, aws_iam as iam, Stack, StackProps, CfnOutput, Duration, CfnCodeDep
はじめに こんにちは。プラットフォームGのOperationToolManagerチームでPlatformEngineeringとかツール周りの開発・運用の役割の島村です。 同じくプラットフォームGのOperationToolManagerチームで内製ツールの開発を行っている山田です。 KINTOテクノロジーズではAmazon ECS＋Fargateをアプリケーション実行基盤として使用しています。また、CICDについてはGitHubActionsを使用しています。 AWSのECSにおけるBlueGreenDeploymentの仕組みは、DeploymentControllerとして「CODE_DEPLOY」が主として使用されており、「EXTERNAL(サードパーティーでの制御)」を使用している実例は少ないと思います。 CI/CD Conference 2023 by CloudNative
Containers Faster Scaling-in for Amazon ECS Cluster Auto Scaling Introduction Amazon Elastic Container Service (ECS) customers who use Cluster auto scaling (CAS) have expressed that they would like to scale-in more quickly so that they can avoid paying extra charges for compute resources during scale-in events. To make scaling-in more responsive, today we are pleased to introduce an enhancement to
EC2インスタンスの踏み台を用意したくない こんにちは、のんピ(@non____97)です。 皆さんはEC2インスタンスの踏み台を用意したくないと思ったことはありますか? 私はあります。 VPC上のRDS DBインスタンスやRedisクラスター、OpenSearch Service ドメインなどのリソースに接続したい場合、Site-to-Site VPNやClient VPN、Direct Connectがなければ踏み台(Bastion)が必要になります。 踏み台へのアクセス方法は以下のようなものがあります。 直接SSH SSMセッションマネージャー EC2 Instance Connect そして、踏み台となるリソースとして採用される多くがEC2インスタンスだと考えます。EC2インスタンスの場合、OS周りの面倒をみる必要があります。OS内のパッケージのアップデートが面倒であれば「踏み台が
こんにちは、つくぼし(tsukuboshi0755)です！ 以前以下のブログで、CDK(TypeScript)でECSとECRのコンテナ構成を実装しました。 今回はこの構成に対して、CodeCommit及びCodeBuildを含むCodePipelineを追加し、ECSのローリングアップデート構成を実現するCDKコードを作ってみたいと思います！ 前提条件 今回は以下の通り、CDKv2を使ってコードを書いていきます。 $ cdk version 2.83.1 (build 006b542) またDockerクライアントとしては、Rancher Desktopを使用します。 $ rdctl version rdctl client version: 1.1.0, targeting server version: v1 全体構成 今回はVPC+ALB+ECS(Fargate)+ECRに加えて、
FireLens でログ出力を分岐する記事もよかったら見てみてください。 https://qiita.com/sugimount-a/items/c43b1bd4f9ecbbb448b7 Amazon ECS におけるログ出力 Amazon ECS 上で稼働するログを、外部に保存する方法は、主に 3 つあります。 引用 : https://speakerdeck.com/prog893/aws-startup-tech-meetup-number-3-kantankontenaroginguxuan-shou-quan awslogs logging driver 独自で Fluentd のサイドカーを構成 FireLens awslogs logging driver は、シンプルに実装できますが、ログの出力先は CloudWatch Logs だけです。大量なログが発生する環境では、C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く