こんにちは、普段PR TIMES STORY（以下STORY）の開発リーダーをしている岩下(@iwashi623)です。 PR TIMES STORYは弊社のMissionである「行動者発の情報が、人の心を揺さぶる時代へ」をそのまま体現したようなプロダクトで、「創業ストーリー」や「開発秘話」などの行動者の熱量をそのまま配信して、企業とメディア、生活者のより良い・多くのリレーションが生まれることを目的としています。 PR TIMES STORYトップページ 本記事では、私も今月から2年目となったので新卒の時よりさらにチームに貢献していきたい！と思っていたところ、STORYの現状の環境では開発速度が出しづらい状況を抱えていたので、そちらを解消するためにチームで行ったことを書いていきます。 現状 STORYは一部PR TIMESとは別リポジトリ、別インフラで独立して管理されており、独立している部
Amazon ECSデプロイツールのecspressoについて、もうすぐv2.0をリリースする予定ですのでお知らせします。先行してバージョン v1.99.x をプレリリースしていますので、利用できる方はお試し頂ければと思います。 (2022-12-15追記: v2.0.0をリリースしました！) もし不具合や不審な挙動を見つけた場合、GitHub issue や作者の Twitter (@fujiwara) へのメンションで教えていただけると嬉しいです。 github.com CircleCI Orb をご利用の方に大事なお知らせ まず最初に大事なお知らせです。CircleCI Orbを利用していて次の条件に両方合致している場合、v2が正式リリースされるとv2がインストールされるため、ワークフローが期待通り動かなくなる恐れがあります。 CircleCI Orb fujiwara/ecspre
概要 下記記事にありますとおり、Docker Compose to ECS pluginを用いることで これまでDocker Composeで起動していたコンテナ群をECSへデプロイすることが可能となります。 Docker Compose と Amazon ECS を利用したソフトウェアデリバリの自動化 サンプルアプリケーション 動作確認をおこなうため公式のサンプルアプリケーションを利用させてもらいます。 サンプルアプリケーション 下準備 Contextの確認 以下コマンドで現在のContextを確認します。 docker context list 表示結果例 $ docker context list NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR default * moby Current
This all started with a blog post back in 2020, from a tech curiosity: what's the fastest way to scale containers on AWS? Is ECS faster than EKS? What about Fargate? Is there a difference between ECS on Fargate and EKS on Fargate? I had to know this to build better architectures for my clients. In 2021, containers got even better, and I was lucky enough to get a preview and present just how fast t
https://aws.amazon.com/jp/events/devday/japan/
こんにちは、AppBrewに業務委託で参加させてもらっているsnikiです。 本業ではヤフー株式会社でYahoo! JAPANアプリのバックエンド開発をやっています。 今回は、AWSのChatbot/Step Functions/CDK等を利用してAmazon Auroraをcloneするツールを作成したのでご紹介します。 背景 機能の説明 利用したAWSのサービスとシステム構成 この構成に至るまで slackのコマンドを受け付けるには cloneからmasking、instance class設定、通知まで Aurora Clone(Lambda) Aurora Masking(ECS) Modify Clone DB Instance Class(Lambda) Notify Slack(Lambda) 補足 なぜLamdaとECSが別れているのか インスタンスクラス変更のタスクは何？
1. はじめに こんにちは、SWEのあかりです。 今回のテーマは、SRE NEXT 2023のCall For Proposals（CFP） に応募したものの、残念ながら不採択になってしまったものです。話せるネタとしてはまとまっていたので、テックブログとしてここに捧げます😇 2. 本記事の概要 社内で最も古くから稼働している施工管理アプリでは、主にデータ修正と有事の際のログイン環境として開発者向けのEC2インスタンス（以降、「バッチサーバ」と表現）が存在していました。この記事では、このバッチサーバの廃止1を目的として、このサーバが担っていた役割をサーバレス環境・コンテナ環境へ移行し、EC2インスタンスからの脱却を達成した取り組み2について説明します。 この記事を読んで得られることは以下の通りです。 EC2インスタンスを廃止する取り組みの流れ 技術選定時に定性分析を行う事例 本番データを修
ECS Service Connectによるサービスの新しいつなぎ方 / A new way to connect services with ECS Service Connect
こんにちは！技術部プラットフォームグループのharukin, pochyです。 この記事では、「ISUCON」を模したパフォーマンスチューニング研修を複数社合同で実施した概要と、そのための準備について紹介します。 研修について 目的 今回の研修の目的は次のものとしました。 パフォーマンスチューニングの問題を会社横断でチームを組成し取り組むことで、サーバサイドやインフラのパフォーマンス・チューニングを中心に幅広い知識を総動員して課題解決に望む。 課題解決過程のコミュニケーションを通じて、会社の枠を超えた同期作りを促進する。 概要 今回の研修では、チームごとにパフォーマンスチューニングの課題に挑戦しました。 実際のISUCONのように、各チームにwebサーバーを貸し出す形式です。各チームはそのアプリケーションを時間内にパフォーマンスチューニングし、最適化された度合いによってチームに点数をつけま
今年の頭から税理士ドットコム事業部に異動した @komtaki です。3 月末から 7 月まで育休を頂いていたのですが、無事復帰しました。 部署異動してすぐに、ジョブ追加の際にコンテナや CI/CD の最適化がされず開発体験を損なっていると感じました。そこで、異動直後の 2 月末に、フルスクラッチでコンテナと CI/CD を作り直しました。 約半年運用し GitLab CI でのデプロイ運用のデータが溜まり、定量的にデプロイを分析できるようになりました。 そこで税理士ドットコムのデプロイフローにどのような問題があったのか、CI/CD の設計の考え方と改善後の効果についてお話しします。 CI/CDとは CI: Continuous Integration CD: Continuous Delivery / Continuous Deployment CI/CDを設計するポイント 税理士ドット
DevOps エンジニアの 根本 征 です。 7月からエクサウィザーズ にジョインし、CI / CD パイプラインの改善や自動テストの布教などを行っています。 今回は GitHub Actions の self-hosted runners を AWS ECS 上に構築し運用してみたので、その試行錯誤について紹介したいと思います。 GitHub Actions と self-hosted runners self-hosted runners を Docker で動かす self-hosted runners を AWS ECS で動かす アプリケーションを AWS ECS へデプロイする Workflow を作る おわりに GitHub Actions と self-hosted runners GitHub Actions は GitHub ユーザーであれば現在多くの方がご存知・ご活用
ちゃだいん（@chazuke4649）です。 前回のブログの過程で、Container Insights画面以外でサクッとコンテナ単位のCPU・メモリ使用量を確認する方法があったので共有します。 今回紹介するのは２パターンです。 1.Container Insights画面から飛ぶ方法 2.サンプルクエリをそのまま実行する方法 前提 Container Insights画面ではみませんが、Container Insightsを有効化し、これによるカスタムメトリクスやログを収集する必要があります。 その他Container Insightsに関係する有用情報を下記ブログで紹介しているので、ぜひ見てみてください。 Container Insights でコンテナ単位のCPU・メモリ使用率を表示させる | DevelopersIO 1.Container Insights画面から飛ぶ方法 Clo
はじめに おはようございます、加藤です。現在AWSには223個（2022/01/05時点）のサービスがあります。コンピューティングのカテゴリだけでも10数個のサービスが存在し、WebアプリケーションをAWS上に構築するエンジニアは要件に応じて利用するサービスを選定しアーキテクチャを決定しなければなりません。 動くだけならばともかくアジリティ・スケーラビリティ・コストパフォーマンスを高水準で満たすアーキテクチャを設計するにはスペシャリストの存在が必要不可欠です。プロジェクトチーム内にスペシャルが存在しない場合は多くの会社がAWSのコンサルティングサービスを提供しているので外注で解決する事ができます。（もちろん、弊社もAWSコンサルティングサービスを提供しております、お気軽にお問い合わせください！） しかし、コスト・スケジュール・組織的な都合で外注が出来ないことやまずはノウハウを蓄積するために
こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回はタイミーで実践しているECSのオートスケール戦略についてお話ししようと思います。 TL;DR タイミーではTarget Tracking ScalingとStep Scalingを組み合わせてオートスケールをしています Target Tracking Scaling -> 通常のスケールアウト・スケールイン Step Scaling -> スパイク時のスケールアウト 2つを組み合わせることで、様々なリクエストに対し適切なリソースを用意しています タイミーのアクセス量の変化とビジネス要求 タイミーのアクセス量の変化とこれまでのオートスケール タイミーは空いた時間に働きたい人とすぐに人手が欲しい店舗・企業をつなぐスキマバイトアプリです。 したがって、仕事の募集数や働いてくださるワーカーさんの数は世の中の動向に大きく左右されます
自分は Amazon ECS のデプロイに ecspresso を利用することが多いのですが、頻繁にデプロイする環境だと 1 年で数百を超えるタスク定義が作られます。直近の数世代はロールバックする可能性があるので残しておきたいのですが、さすがに数か月前のリビジョンに戻すことはないため不要なものは断捨離したいと思っていました。 そういうリクエストが多かったのか、以前はタスク定義を非アクティブにすることしかできませんでしたが、今年の 2 月についに削除できるようになりました。 Amazon ECS が非アクティブなタスク定義リビジョンの削除をサポート さらに AWS が管理する Containers Roadmap のプロジェクトを眺めてみると、Issue #1967 でタスク定義にライフサイクルを追加してほしいというリクエストが挙がっていました（この Issue を作ったのは中の人っぽいので
はじめに 弊社が提供する無料のAWS運用かんたん自動化ツール「opswitch」を使って、夜間や土日祝日などの使わない時間帯に開発環境のAWS Fargate、Amazon ECSを停止させる方法を紹介します。プログラムなどの知識はなくても、Webの操作だけで設定を行えます。Fargateを例に説明をすすめます。ECS(ECS on EC2)の場合は「タスクの作成」が少し違いますので補足をご覧ください。 準備 ユーザーガイド opswitchを開始するを参考に以下の初期設定を完了させてください。 opswitchのアカウント作成 opswitchアカウントの初期設定 ユーザー属性情報登録 組織作成 AWSアカウント連携作成 タスクの作成 それではFargateを起動させるタスクから作成します。 Management Consoleでタスク数を変更したいECSサービスにタグをつけます。どのサ
Leaner 開発チームの黒曜(@kokuyouwind)です。 先日開催された AWS Startup Community Conference 2022 に登壇させていただきました。 AWS Startup Community に合わせた若干釣り気味のタイトルですが、内容としては Copilot CLI の使い方や利用の際のポイントをまとめたものでした。とはいえ新規アプリケーション構築に向いていることやマルチアカウント運用に癖があることから、スタートアップでよりハマる局面が多いだろうというのも本心です。 ちなみに CFP 提出時点の仮タイトルは「1 年間本番運用してきた AWS Copilot CLI の悲喜こもごも」で、もう少しエピソードベースでの Tips に比重を置いた内容を考えていました。 今回は大まかな発表内容や、発表で触れられなかった個別 Tips などをあわせて記事にまと
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内のパッケージのアップデートが面倒であれば「踏み台が
SREチームの橋本です。SRE連載の7月号になります。 カヤック社内では弊社藤原のecspressoをAmazon ECSのデプロイツールとして活用していますが、AWS公式のデプロイツールAWS Copilot(現在v1.29)もそのオールインワン的な性質から、開発・運営リソースが限られるプロジェクトでは選択肢に入るようになってきました。 今回はそのAWS Copilot活用のため、背後にあるAWS CloudFormationテンプレートをカスタマイズする手法を紹介します。 AWS CopilotとCloudFormation AWS CopilotはECSなどのデプロイを簡単にするCLIツールですが、実態としてはManifestと呼ばれるYAMLの設定ファイルからCloudFormationテンプレートを生成し、各種リソースを作成・管理するものです。 AWS Copilotは内部的にC
00 自己紹介 安藤 裕紀 / あんどぅ NewsPicks SREエンジニア SREチームのマネージャー兼テックリード 好きなAWSのサービス：ECS、Cost Explorer 、CDK ©NewsPicks Inc. All Rights Reserved.
AWS CDKでコードの記述30行ほどでVPC, ECS, Fargateなどを使ったインフラ環境を構築してみました。 HAPPY BIRTHDAY, クラスメソッド! 弊社には 7月7日の会社のお誕生日にブログ書くという文化があります。 せっかくなので私も最近はまっている CDK ネタで一本書いてみようと思います。 ついこの間、はじめて CDK を使って VPC 環境を構築する機会があったのですが、思いのほかシンプルだったのでご紹介したいと思います。 作るもの VPC、 ECS、 Fargateでインフラ環境を構築します。 使うもの AWS CDK を Typescript で記述します。 cdk --version 1.32.2 tsc -v Version 3.7.4 Typescript の watch モードをオンにする 私はよくビルドし忘れてデプロイの時にこけるので Watch
こんにちは。エンジニアの佐々木です。 最近、映画アルゴの主人公のような密度が濃く整った髭を目指し日々手入れを行っています。 さて。以前、社内勉強会で発表した「北欧、暮らしの道具店」におけるSREについての記事を書きました。 今回は、上の記事の中のスライド内で少しだけ触れていた「コンテナ技術(ECS/Docker)への移行」について、バッチ実行まわりでの技術選定や注意した点について紹介したいと思います。 ECS/Fargate移行前の課題「北欧、暮らしの道具店」はこれまで、AWSのOpsWorks(Chef)を使用しEC2の構成管理を行ってきました。 インフラ側の変更を反映するためには新しくプロビジョニングしたEC2を毎回用意する必要があるため、そのときには以下の様な課題を抱えていました。 - Web・APIサーバーとして動いているEC2インスタンスは、その数だけプロビジョニングを実行し新規
以下のイベント「Security-JAWS DAYS」で発表した際の登壇資料です。 https://s-jaws.doorkeeper.jp/events/155024
皆様、本当にありがとうございました。これは「開催しました」ではなく「していただきました」と書くしかないやつです。 connpass.com 発端 2024年10月に開催された YAPC::Hakodate、懇親会後の Findy さん主催ビアバッシュ会場でのことです。@moznion が突然、「fujiwara tech conference というのをやりたいんですけどいいですか？」と言ってきて、なんだそれはと思いつつも面白そうなので「ど、どうぞ」と応えました。 その場に人もいっぱいいたし、Findy さんも会場を提供できそうと盛り上がってしまい、これは冗談では済まないなと思っていたら早速一週間後に連絡が来て、あれよあれよと開催が決まってしまいました。 12月に募集開始したときは、最初は50人だったのが1時間ほどで埋まってしまい、70→90人(会場の限界)までその日のうちに埋まってしまっ
はじめに 背景 信頼性 監査プロセス コスト 要件 機能要件 非機能要件 設計 システムの構成要素 なぜECSを選んだのか 監査ログ保全における適切なリソース管理 私達のユースケースに合わせたオブジェクトキー 実装と検証を繰り返しフィードバックループをまわす ログが途中で途切れる 並行運用 転送量のコスト増加 ECS Fargateのキャパシティ不足 ログの整合性をチェック ログローテーションサイズの変更 オンコールドキュメントを作成 成果 Future Works まとめ harukin drumato はじめに こんにちは。技術部技術基盤グループのharukin,drumatoです。 カラーミーでは従来Data Firehose（旧Kinesis Data Firehose）を用いて、Amazon RDSの監査ログをS3に保存する仕組みを運用していました。 しかし、運用していく中で継続
https://lancersrecruit.connpass.com/event/219434/ 【SPACEMARKET×Lancers】シェアリングエコノミーを支えるインフラ/SREでのスライドとなります。
AI事業本部の協業リテールメディアdivでソフトウェアエンジニアをしている 中澤 といいます。直近では、プロダクト開発以外にAI 事業本部の新卒研修の運営を行なったりもしていました。 私が所属しているチームで最近、定期バッチを行うワークフロー管理ツールを AWS Step Functionsへ移行したので、移行の背景や得た知見を記事として公開します。 移行前の構成 私たちのチームでは、ワークフロー管理ツールを AWS Step Functions に置き換える前には、Prefect を使っていました。 Prefect に関しては、弊社ブログの別記事があるので、Prefect について知りたい方はそちらも参考にしてみてください。 Prefect を利用している時の構成では、Prefect 側でワークフローのスケジュール管理やワークフロー内のタスク実行を Prefect、実際のワークフローのタ
インフラエンジニアの菅原です。 最近、バイクに念願のグリップヒーターをつけました。 これでツーリング時の手の寒さが多少楽になりそうで喜んでいます。 とはいってもなかなか出かけられないのですが… 現在私はAWS Fargateを使ったサービスをECS上に構築を進めており、日々コンテナと戯れています。 基本的にストレージ以外のコンポーネントはほとんどECSで動いているのですが、VPCのネットワーク内でちょっとした作業（たとえばネットワークの疎通確認など）をしたい場合、都度新しいタスクを起動して作業しています。 また、DBにテストデータを入れたかったり、どうしてもDBを直接操作したいことがある場合、stoneを新しいタスクを起動した上で、そのタスクを踏み台としてaws ssm start-sessionでポートフォワーディングを行い、手元から直接DBにアクセスできるようにしたりしています。 しか
GameDayとは 起源はAWSが毎年行っているAWS re:inventの中で開催される行事の1つです。 チームを組んでクラウド・アプリケーションを襲う謎の障害や悪意のある攻撃に対処し、トラブルシューティング能力を競うコンテストとなっています。 のちに様々な企業が社内でも実施するようになり、今ではAWS Well-Architectedのセキュリティ項目でもその実施が推奨されています。 ゲームデーを実施する ゲームデーを実施する: さまざまな脅威について、インシデント対応イベントのシミュレーション (ゲームデー) を実施します。このゲームデーには、主要なスタッフや管理者を参加させてください。 教訓から学ぶ: ゲームデーの実行から得られた教訓は、プロセスを改善するためのフィードバックに含まれている必要があります。 GameDayの手順 今回社内で行なったGameDayの流れです。 1. 発
こんにちは！LayerXの高際 (@shun_tak) です！過去にはOCR関連の記事を書きました！ LayerX インボイスのアプリケーション・サーバーはAmazon ECS と AWS Fargateで動作しています。今回の記事ではそのコスト最適化手法について解説したいと思います。よろしくお願いします！ tech.layerx.co.jp サマリーとしては、LayerX インボイスではオーソドックスに費用の削減とタスク数の最適化という2つの方法でコスト最適化を行っています。 Savings PlansとFargate Spotを活用した費用の削減 Auto ScalingとScheduled scalingによるタスク数の最適化 早速次節から解説していきます！ Savings Plansを活用した費用の削減 Fargateは使った分だけ料金が請求されます（vCPU数×メモリサイズ×起動
The article is also available in Chinese. Disclaimer: This post is a very long collection of thoughts and problems I've had over the years, and also addresses some of the arguments I've been repeatedly told. This post expresses my opinion the has been formed over using Rust for gamedev for many thousands of hours over many years, and multiple finished games. This isn't meant to brag or indicate su
async/await、聞いたことはあるけどなんだか難しそう。と思って使ってなかったりしませんか？ これに対する自分の答えは、「難しい使い方で使うと難しい。」 逆に言えば、簡単な使いみちで使う分にはめっちゃ簡単なんですよ。 なので早速今から簡単な使い方を紹介していきます。 どこで使えるか ズバリ、「状態の制御」。 ゲームを作る上では必須ですが、状態を扱うサンプルコードって意外と少ないんですよね。 状態というのは例えば、「タイトル画面」「インゲーム画面」「リザルト画面」みたいな画面だとか、 RPGなら「マップを歩いている」「村人と会話している」など。 後は「ロード中」なんかも状態と言えますね。 このスライドにおける素直で読みやすいコードとは 色んな思想があるとは思いますが、このスライドにおいて自分が考えている素直で読みやすいコードとは、 「同じ抽象レベルの状態の制御が同じ場所で行われている」
最近業務でNext.js+LaravelのアプリケーションをAWSのAmazon ECS(Fargate)にデプロイするタスクを担当しているので、デプロイするにあたりNext.js側、Laravel側でやっておくこと、エラー対応などをまとめておく。 ECSへのデプロイはEC2へのデプロイに比べそもそもネットに情報が少ないECSの中でもデータプレーン（コンテナ実行環境）にEC2を使った記事が多くFargateを使った記事はかなり少ないECS+Fargateへのデプロイでも本記事のようなフロントエンド+APIの構成のデプロイ例はマジで少ない という状態で結構苦戦したので、自分で苦戦したことを残しておくとともに同じ構成でデプロイする方に向けて参考になれば嬉しいです。 ECS、ECR、Fargateについての技術説明・全体的なデプロイ作業の手順についてはこの記事では扱わないが、この記事（というかZ
本ブログは「Aqua Security」社の技術ブログで2021年1月20日に公開された「 The 3 Riskiest Cloud Native AWS Configurations 」の日本語翻訳です。 EC2 だけでも数十もの主要なセキュリティ設定が可能なため、AWS の設定オプションの多さに圧倒されることがあります。複雑さが増す一方で、クラウドネイティブデプロイメントにおいて動的なインフラ要件に対応するには、クラウドアカウントを適切に、そして安全に設定することが重要です。サービスを適切に設定するという課題は、利用可能な AWS サービスの数が膨大であり、それぞれが独自の要件を持っているため、さらに複雑になっています。 AWS のクラウドサービスは、新しいサービスの提供や定期的なアップデートなどで常に変動し、CSPM(Cloud Security Posture Management
Lancers Engineer Blog をご覧のみなさんこんにちは。開発部/技術基盤 SREの安達(@adachin0817)です。以下前回のブログから3ヶ月経ちましたが、ついにLancersのBatch、AppサーバーをEC2からECS/Fargateに移行完了しました。 そして長年自前で運用していたデプロイシステムを廃止して、CI/CDはCircleCIに完全統一しました。これにて、Lancersの全サービスをコンテナに移行完了となりました。 ※見ていない方はぜひ一読してもらえると幸いです。 ・LancersをAmazon Linux2へログ基盤のリニューアルと管理画面をECS/Fargateに移行しました 旧開発環境、EC2での運用課題 Ansibleコンテナによる開発環境の統一により工数がかかる 本番コンテナ化以前は、EC2で利用しているAnsibleの管理を開発環境にも適用す
こんばんわ、札幌のヨシエです。(亜人大好きです、よつばと！と同じぐらい好きです) コンテナ業界盛り上がってますね、中でもFargateのプラットフォームがアップデートされ様々な新機能が追加されてます。 挙げるとキリがないですがFargate PV1.4からコンテナエンジンがDockerからcontainerdに切り替わり、様々な変更が加えられております。 詳しくは↓をご確認ください。 その中でFargate(PV1.4)の発表があった時は「あーはいはい、中身が変わるんですね。わかりました。まぁコンテナホストのバージョンが上がってもコンテナが起動することだけ確認すれば良さそうっすね」と考えておりましたが、 AWSドキュメントに以下の記載を確認しました。 Fargate 起動タイプおよびプラットフォームバージョン 1.3.0 以前を使用する Amazon ECS タスクでは、この機能を活用する
こんにちは！コンサル部のinomaso(@inomasosan)です。 ECS FargateでFireLensからCloudWatch LogsやKinesis Data Firehoseへのログ出力を、Terraformでコード化したので紹介します。 検証にあたり、弊社の以下ブログを参考にしました。 そもそもFireLensって何？ FireLensは、複数のAWSサービスやAWSパートナーネットワーク(Datadog等)にログ出力することができます。 ECSタスク定義でサイドカーとして起動し、他のコンテナからログドライバーとして使用します。 コンテナイメージにはFluentdとFluent Bitを選択可能です。 今回の検証では、リソース使用率が低く、ログルータに推奨されているFluent Bitを使用します。 2021/11/6時点でFluent Bitでは、以下のAWSサービスに
![[Terraform]ECS FargateでFireLensを使って複数サービスにログ出力する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a77b081e14c8d61a2e80498092f8ffb9b60da03/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Fterraform-eyecatch.png)
はじめに おはようございます、加藤です。先日、こちらの記事で紹介しましたが、AWS CDKは本来Cloud Formationテンプレートを生成してデプロイを行いますが、Lambda関数をデプロイする際にCloud Formationを使用せずにAWS SDKを使うことで高速にデプロイする機能が登場しました。この機能はhotswap deploymentと呼ばれます。 昨日、v1.128.0がリリースされ、hotswap deploymentにECSサービスが対応しました。また、気づいていませんでしたがStep Functionsも対応していました。 デプロイ速度 具体的にどれぐらい早くなるのか、ecs-patternsのApplicationLoadBalancedFargateServiceを使った構成で試してみました。使用したDockerfileとアプリケーションは下記のとおりです。
追記 (2020/06/15) Container Insights は GA しています！ tl;dr kobanzame 作ったもの 仕組み なんちゃってプラグインアーキテクチャ 使い方 設定ファイル 実行 Example 参考 それ, Container Insights で良いんじゃないのか おっしゃるとおり じゃあ, なぜ, 俺は kobanzame を作ったのか 以上 追記 (2020/06/15) Container Insights は GA しています！ 2020/06/14 現在はベータ版として提供されていますが この記述は誤りで Container Insights は 2019 年 11 月には既に GA されておりますので, ここで訂正させて頂きます. aws.amazon.com 確認不足で誤った情報を記述してしまい大変申し訳ございませんでした. tl;dr 以
TL;DR 3行で。 シンプルで セキュアな Ruby on Rails on ECS by Terraform を作りました。 目次 はじめに 本構成のテーマ リポジトリ アーキテクチャ Terraform側のTips Rails側のTips さらなるカスタマイズ はじめに ここ数年、業務やプライベートで様々なパターンのRuby on Rails + AWS ECS構成を構築してきました。 例えば、構築したことがるパターンを要素ごとに列挙するとざっと以下のようになります。 フロント部分 ALBのみ CloudFront -> ALB assetsのみCloudFront ECS 起動タイプEC2 起動タイプFargate 2種の混在 デプロイパイプライン 全部GitHub Actions Capistrano + ecs-cli CodePipeline + CodeBuild Code
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
