Amazon ECSを用いたDocker本番運用の実現 - Qiita
はじめに 現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。 税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。 そういった中、各アプリケーションをDocker化することでインフラとしては共通基盤としてのDockerクラスタのみの管理になり、運用コストが下がるのではないかという仮説からDocker化を進めることになりました。クラスタを実現するに辺りKubenatesなどの選択肢もありましたが、今回はECSを選択し、下記のようにAWSの
EC2 のAuto Recoveryが東京リージョンにリリースされました ｜ DevelopersIO
はじめに AWSチームのすずきです。 AWSのシステム側に起因するEC2障害が発生した場合、 インスタンスのSTOP、STARTによる再起動操作が必要となる事があります。 この再起動を自動化する「Auto Recovery」機能が東京リージョンでも利用可能となりましたので紹介させていただきます。 Auto Recovery設定 Auto Recovery、AWSコンソールのCloudWatch画面で設定します。 詳細な設定手順は、Auto Recoveryが先行提供されていた米国リージョンと同じです。下記記事をご覧ください。 【新機能】EC2 Cloudwatchの新機能「Auto Recovery」を使ってみた まとめ AWSのEC2環境が稼働している仮想ホストやネットワークなどに物理的な障害が生じ、 EC2インスタンス障害に至る可能性、頻繁に発生するものではありませんが、0ではありませ
クラウド専業CIerがAWS監視運用でZabbixを使う理由 - サーバーワークスエンジニアブログ
CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
