インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
システム管理ツールChefのチュートリアル(RailsConf2009レポート) - クックパッド開発者ブログ
RailsConf2009に参加中の高田悟史です。RUNNING THE SHOW: CONFIGURATION MANAGEMENT WITH CHEFを聞いてきました。 Chefというのは、Puppetのようなシステム管理ツールです。 Puppetとの違いをいまいち分かっていないのですが、サーバー(Chef Server)とクライアント(Chef Clients)という構成で、サーバーの設定(cronやApacheなど)をrubyで記述し(これをCookbookと呼ぶ)、新しく導入するサーバー(Chef Clientにあたる)のセットアップや設定変更やRailsアプリケーションのデプロイなどを自動的に行うことができるツールです。また、このCookbookという設定情報はバージョン管理されます。例えば、Apacheの設定ファイルをERBで記述し、rubyで変数値を指定するというような書き
Puppet、Chefより先にKokkiを試す(1)
Oneiricにdotdeeが入るらしいから、OpenVZ上のDebian(6.0)に突っ込もうとした...が、upstartとか依存関係で諦めた。 本家では、黒魔術とか突っ込まれてる（w それにしても、作者的にはPuppetやChefなんてスカイネットかとネタにされている。 けれど時流としては、カオスな運用 → Puppet → Chef。 PuppetやChefを試そうにも、Rubyなだけに食べず嫌いだった。 それぞれイイヨ！とかいっている人達は、まさかこの運用改善って目的だけにRubyいれてるのかな... そこは規模なんだろうか? 先日、たまたまChefのPythonポートといわれるKokkiを見付けたので、試してみる。 やっぱりPythonはどこでも走る(走ってる)から気楽だなぁ。 まずは、ソースを取得する。 本来は本家ドキュメントにある通り、 easy_install kokki
Chefを最速で使いこなすためのいくつかのポイント - Masatomo Nakano Blog
前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。 前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。 ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！ client vs node Chef Client Nodes ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。 client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて clien
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
