Ansible + Mackerel APIによる1000台規模のサーバオペレーション - ゆううきブログ
Ansible と Mackerel API を組み合わせて、1000台規模のサーバ群に対して同時にパッケージの更新やその他のサーバオペレーションのための方法を紹介します。 タイトルに Mackerel とありますが、それほど Mackerel に依存しない話です。 (AnsibleとDockerによる1000台同時SSHオペレーション環境 - ゆううきブログに続編を書いています。) 背景 社内では、サーバ構成管理ツールとして Chef を使用しています。 Chef Server は運用が大変なので使用しておらず、knife-solo と Mackerel APIを組み合わせてホストと Chef role とのマッピングに Mackerel のロール情報を用いています。 また、Mackerel の Ruby クライアントを利用して recipe 内で API を叩いて、Mackerel か
Chefを読んで実行するための全知識 - Qiita
このドキュメントでは、Chefを実行して、インフラを作成したい人が、既存のレシピがあるのを前提に、Chefの概要を理解するためのドキュメントです。Chef-soloの構成のみに対応した記述になっています。理解が間違えているところとかあればご指摘ください。 1. Chefの概要 1.1. Chefとは シェフは、インフラストラクチャーをコードに変換するための自動化プラットフォームです。仮想環境でも、物理環境でも、クラウドでも使う事ができます。インフラストラクチャを自動化することで、プロダクトのマーケット投入を早めたり、スケールや複雑さに対応したり、システムを安全に保ちます。 1.2. Chefの仕組み Chefはサーバーをセットアップして、希望の状態にするための「クックブック」「ノードオブジェクト」というDSL(設定ファイルっぽいもの)をローカルのワークステーションで作成します。それらのDS
AWS OpsWorksって何？ から、運用しやすくなる下準備のポイントまで
AWS OpsWorksって何？ から、運用しやすくなる下準備のポイントまで：AWS OpsWorksアプリケーション運用の勘所（1）（1/5 ページ） はじめに 2013年2月にリリースされたAWS OpsWorks。筆者が試しにいじっているうちに、どう使うと便利なのか、気を付けないと逆に運用が大変になるポイントなどが見えて来ました。 本連載では、何回かに分けてAWS OpsWorksの便利な点、不便な点をおさらいしながら使い勝手を紹介して行きたいと思います。題材として、「EC-CUBE」というAWS OpsWorksに最適化されていないオープンソースのパッケージを使ってみました。 AWS OpsWorksは、Amazon Web Servicesが提供するChefをベースにしたサービスです。Chefのレシピを使ってシステムの構成などを一元的に設定できます。また、アプリケーションのデプロ
いまさら聞けない「DevOps」
最近さまざまなイベントやブログエントリで見かける「DevOps」。この言葉をひもとき、なぜ「Dev」と「Ops」が衝突するのか、その解決に必要な要素とは何かを分かりやすく解説します。 DevOpsとは 2009年にオライリーが開催した「Velocity 2009」というイベントにおいて、Flickrのエンジニアが、“開発と運用が協力することで、1日に10回以上のペースでリリースが可能になること”を紹介しました。いまさまざまなシーンで見かける「DevOps」という言葉は、このプレゼンの中で登場したものです。 DevOpsとは、開発（Development）と運用（Operations）が協力し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。多くの人々により議論は続けられていますが、ITILとは異なり、現時点においては、DevOpsに厳密な
監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
Chefをベースにした日本製の運用自動化ツール「Cloudrop」、エクシードから
データセンターへ投入したサーバの構成やアプリケーションのデプロイツールとしてよく知られているのが「Chef」や「Puppet」といったオープンソースの運用自動化ツールです。特にChefは先日Facebookが採用したことが発表されています。 そのChefをベースにした運用自動化ツール「Cloudrop」がエクシードから発表されました。同社はシステム構築や運用サービスに加え、パブリッククラウドの「Libra」などを提供する日本の企業で、Cloudropはそうした同社の経験を踏まえて作られたもの。 運用自動化ツールは、開発と運用が協力してビジネスゴールを目指す「DevOps」ムーブメントの中で、システムの開発運用を迅速に改善するうえで欠かせないツールとして注目されています。 運用の属人性を排除して自動化、効率化 CloudropはChefをベースにしているため、Chefでの手順書に当たるレシピ
運用担当者、激減中
ユーザー企業の情報システム部門で今、運用担当者の人数が大きく減り始めていることをご存じだろうか。 運用業務には、「アプリケーション保守」や「OS/ミドルウエア運用」、「ITインフラ運用」などがあるが、あらゆる業務に関わる運用担当者が減少しているのだ。まずは4社の事例を紹介しよう。 サイバーエージェント 運用担当者の人数 20人→0人（予定） サイバーエージェントで消費者向けWebサービスを手がけるアメーバ事業本部では、現時点で20人いるOS/ミドルウエアの運用担当者を、2年後の2015年までにゼロにする計画だ。 彼らは現在、OS/ミドルウエアをサーバーにインストールしたり、パッチを適用したり、アプリケーションの負荷に応じてサーバー台数を増減したりする業務を行っている。これらの業務を、オープンソースソフトウエアの運用管理ツール「Chef」を導入することで、自動化する計画だ（図1）。
小規模SI案件で、 AWS + Chefを使ってみて
2. Copyright © 2013 AGREX INC. 2 プロフィール てるい まさし 照井 将士 http://www.facebook.com/marcy.terui (株)アグレックス 札幌事業所 システム部 1987年 東京都大田区生まれ 1992年 札幌移住 2011年 (株)アグレックス入社 担当業務 ・ECサイトを中心としたWEBシステムの受託開発、運用 役職 ・下っ端、雑用係 担当職務 ・インフラ構築、管理という名の雑用 ・アプリケーション設計、実装、テストという名の雑用 ・雑用という名の雑用 ・雑用という名の(ry 好きなサービス ・CloudWatch ・Route53 13年9月10日火曜日 3. Copyright © 2013 AGREX INC. 2 プロフィール てるい まさし 照井 将士 http://www.facebook.com/marcy.
データセンター自動化ツール「Chef」、国内の商用提供開始。クリエーションライン
多くのサーバが投入されるデータセンターでは、多数のサーバに対してソフトウェアの構成や設定を人の手で行っていては作業スピードが追いつかないばかりか、設定の間違いによる運用のミスにもつながってしまいます。 データセンターでいま注目されているツールのひとつが、そうした大量のサーバの構成や運用を自動化する「Chef」（シェフ）です。Chefは米Opscodeがオープンソースで開発しているツールで、機能を強化した商用版やサポートなども同社が提供しています。 Chefは大規模なWebサービスなどの現場で最近注目され始めており、国内ではサイバーエージェントの「アメーバピグ」など大規模システムの現場の構成自動化などですでに使われています。 国内でクラウド関連の設計や構築などを行っているクリエーションラインは10月2日、Opscodeと提携し、Chefの国内での商用ライセンス販売、保守サポート、コンサルティ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インフラチームを持たない会社でのインフラ運用