Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
毎秒 "Hey, Yo!" と言い続けるコンテナ
1秒ごとに “Hey, Yo!” というログを吐き続けるだけのコンテナをちょうど1年前くらいにデバッグ用に作って GitHub と Docker Hub に置いていたんですが、ふと昨日見てみたらすでに 10,000 回以上 pull されていました. いったい誰がどんな目的で使っているのか非常に興味があります. 僕以外の人が何に利用してくれているのかは全くもって不明ですが、もしかしたら他にもこれを便利だと思ってくれる人がいるかもしれないので記事に起こしてみました. ちなみに GitHub: toricls/everlasting-hey-yo Docker Hub: toricls/everlasting-hey-yo に置いてます. Everlasting “Hey, Yo” per second この “Hey-Yo” コンテナはもともと ECS でタスク内コンテナの起動・停止順の指定
プラットフォームの上でものを作るということ
プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.
Docker マトリョーシカと私 | ORIH
Docker マトリョーシカと私 この記事は Docker Advent Calendar 2015 の 21 日目です. 昨日は rotoni さんの Docker Registry Proxy Cache を使ってみる でした… と思ったら現時点ではまだ書きかけだったようです. Docker Hub のネットワークレイテンシーが気になることは度々あるので続きが非常に楽しみです. その昔 LT でこんなことを 自分自身の LT なんですが、簡単にまとめると Docker の --privileged オプションと dind を使って、Docker コンテナの中で docker コマンド使っちゃおうって話です. コンテナの中でコンテナを起こし、さらにその中で… みたいなことができるようになります. オンプレの CI システム(Jenkins とか)でこの privileged オプションを
Amazon ECS を本番環境で使ってみて感じたこと・困ったこと
Amazon ECS を本番環境で使ってみて感じたこと・困ったこと 先日行なわれた JAWS-UG コンテナ支部 #1 にて、Amazon ECS を利用して本番環境を構築した際に感じたこと・困ったことについて発表する機会をいただきました. 当日は時間の都合と緊張から駆け足で進めてしまったので、補足 & まとめ的な記事をば. スライドでも触れていますが、今回本番環境に持って行ったのは Fluentd (ウェブサーバーなどから送られてくるログの受け取り、パース処理など) Elasticsearch (Fluentd で受け取ったログの突っ込み先) Kibana (Elasticsearch に溜め込んだログを集計したりグラフ出したり)という構成のホットデータなログの収集サーバー部分です. 以下、勘違いしてる箇所/もっといい解決方法などありましたら Twitter などにてぜひご指摘くださいま
チーム開発の開発環境として Docker + Vagrant を選択し続ける理由
チーム開発の開発環境として Docker + Vagrant を選択し続ける理由 Docker Advent Calendar 2016 の 25 日目です. Docker アドベントカレンダーとして書いているはずだったんですが、推敲と校正を重ねているうちに Docker というよりは VM とか開発環境とかの話が色濃くなってしまい、主役のツールが Vagrant になってしまいました. 謹んでお詫び申し上げます. 僕が所属する会社の事業の一つに Web/モバイルアプリの SI + 運用があり、その際の Web/API サーバー開発は macOS + Vagrant + VirtualBox (CoreOS) + Docker を社内標準のローカル開発環境(以下、開発環境)としています. 勉強会後の懇親会やコンサルティングを提供する場で良く質問されることの一つに「Docker for Ma
サーバーレスな外形監視ツール pingbot | TORI
サーバレスアーキテクチャーって言葉が流行っているのでその近辺技術に触れてみたくてアプリを一本こしらえてみました. リポジトリは github.com/toricls/pingbot です. 何を作ったか サーバーレスな外形監視ツールです. 1 分ごとに任意の Web サイトに対して http/https リクエストを投げることで外形監視を行い、その結果を保存します. 前回チェック時と比較してステータスが変化した場合、Slack にその旨通知してくれます. 安価かつ安定して任意の Web サイトに対してヘルスチェック(死活監視)を行うことを目的として、AWS Lambda、Amazon CloudWatch Events、Amazon DynamoDB あたりを使っています. サーバーレスアーキテクチャーの構成要素として良く利用されるサービスですね. 管理画面となる Web アプリの方は R
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
