ECS運用のノウハウ - Qiita
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
ECS で Amazon CloudWatch Logs にログ出力が出来るようになったのでチュートリアル - ようへいの日々精進XP
tl;dr aws.typepad.com Docker 1.9.1 から Logging Driver として CloudWatch Logs はサポートされていたが、ECS の Task Definition に定義して利用は出来なかった（と記憶している）ので、今回から Task Definition に定義して利用出来るようになったとのことで、ecs-cli でチュートリアルしてみたのでメモ。 チュートリアル 要件 ECS で Amazon CloudWatch Logs にログ出力する為には以下のような要件を満たす必要がある。（上記のブログ記事より抜粋） ECS Agent のバージョンを 1.9.0 以上にする ECS optimized AMI 2016.03.b 以上（ap-northeast-1 の場合には ami-a98d97c7） ECS optimized AMI 2
DELISH KITCHENをECS移行した話(前編) | エンジニアブログ
挨拶エブリーの内原です。DELISH KITCHENのサーバサイドを担当していて、APIサーバの開発と運用、プッシュ通知まわりなどの業務を行っています。 簡単に自分のバックグラウンドを紹介しますと、古くは某パソコン通信サービスの開発、その後ヤフーで社内プラットフォームの開発、今は無き頓智ドットでセカイカメラというサービスの開発、などをしていました。 その後縁あってエブリーに入社しDELISH KITCHENの開発を担当することになりました。 今日はそういった業務の中から、インフラに関連する内容をお話しようと思います。Amazon Elastic Container Service(ECS)を用いた運用です。みなさんの参考になれば幸いです。 最近 AWS Fargateが発表されたのでそれも絡めたお話ができればよかったのですが、この対応をしたのは数ヶ月前のことなのでご容赦を。 以前の構成につ
JSONを超絶に読みやすくする jq コマンド | Basicinc Enjoy Hacking!
WebAPIを使っていると、よく出くわすJSON。XMLと違ってぱっと見ではかなり読みにくかったりしますよね。僕なんかはここ最近、APIの開発ばっかりなのでJSONとのにらめっこ状態。疲れたよパトラッシュ。 というわけで、読みにくくて憎いけど扱いやすいJSONをもっとフレンドリーな見え方にしてくれるコマンド jq を紹介。 今まではChromeの拡張機能でJSONを読んだりしていましたが、完全に jq に乗り換えました。 jqのインストール方法 Macの場合は方法は3つ。まずは、brewでインストール。 $ brew install jq 次は、GitHubにあるソースからビルド。 $ git clone https://github.com/stedolan/jq.git $ cd jq $ make && sudo make install 最後は、バイナリファイルをダウンロードして実
Balto開発の歴史｜Goodpatch Blog グッドパッチブログ
Balto サービス終了まで目前となりました。 ここまで来る間に様々な技術と出会い、格闘し、今の Balto があります。 今日は Balto の開発の歴史について振り返って行きます。 ちなみに私が iOS エンジニア兼サーバサイドエンジニアなので話の中心はこの２つになります。 御存知の通り、開発中のアプリを配布してフィードバックを送る、というシンプルなものです。 その起源は社内メンバーが開発中のアプリに対するフィードバックをスプレッドシートで管理するのが大変、かつスクリーンショットを撮って共有するのに手間がかかる、という問題からでした。 Balto によって1回のフィードバックにかかる時間を数分から約30秒に短縮。結果社内のプロジェクトの殆どで利用されるようになりました。 こういったシンプルな苦痛がサービスに繋がるのが面白いところですね。 くわしくはこちらの記事を。リリース後は、Tech
Baltoサービス終了の背景｜Goodpatch Blog グッドパッチブログ
Baltoはなぜ生まれたのか まず前提として、Goodpatchには、ProttやBaltoなどの自社事業をつくる部署とクライアントワークを担当する部署があります。そして、自社プロダクトにはクライアントワークで培った経験が活かされています。 Prottは、コードを書かずに本物のようなWebサイトやアプリの動きを再現できるサービスです。しかし、実際に実装し始めると、大きな手直しは少ないものの、細部では直したい部分が続々と出てきます。 それをどのようにメンバー間で伝えるかというと、モバイルでスクリーンショットを撮影してPCに送り、スプレッドシートやパワーポイントで指摘部分の説明資料を作る必要がありました。この方法では、1回のフィードバックに60秒くらい時間を要し、かつ単純作業なので、繰り返していくとフィードバックが億劫になっていきます。 そうすると細かいフィードバックをつい放置してしまい、結局
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Indoor mapping & Wayfinding for Smart Buildings