Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。Rubychefknifeknife-zero Chef(ChefInc)の管理ツールKnifeのプラグインで、Knife-Zeroというのを作りました。 https://github.com/higanworks/knife-zero 追記： バージョンアップして、knife zero chef_client/convergeサブコマンドを追加しました。 追記： ひと通りの機能を実装したので、knife-zeroのことをまとめるドキュメントをゆるやかに作成しています。 https://knife-zero.github.io 端的にいうとAnsibleのやり方をパクりつつ、Chef-Serverから構成管理を含む機能全部を頂戴しながら本体の管理を捨てました。 Kni

最近話題になっているImmutable Infrastructure（イミュータブル・インフラストラクチャ/サーバ）。あんまりよく解っていないので、整理してみました。 Immutable Infrastructureとは？ そもそもImmutable Infrastructureとは、何でしょう？極論すると、「稼働中のサーバの構成管理をやめて、サーバを使い捨てにしよう」という考え方です。これだけ言われても、さっぱり解らないと思います。 まずは従来の考え方。Mutable Infrastructureというのか、既存のサーバに変更を加えていくことが前提になります。 それに対して、Immutable Infrastructure。直訳すると変化しないインフラとなります。どういうことかと言うと、サーバ構成（ミドル・アプリ）を変更したい場合は新規にサーバを立ちあげ、そこに既存の機能と新規の機能を加

最近、微妙に気になっているテーマがあります。EC2でインスタンスを使う際に、Amazon Linux AMIを使うかどうかという点です。何を言っているのだ、お前というような悩みなので背景を簡単に書いておきます。 Amazon Linux AMIを使わないようにしようかなと思った理由 そもそものキッカケは、Chefを使うようになったことです。Chefで環境をコードで記述するようになると、ローカルの開発環境であろうが、検証・本番環境でも基本的にはコマンド１つで構築できます。しかし、気が付いてしまいました。ローカルの開発環境に、Amazon Linuxをインストール出来ないことに。このことはChefを使い出すと同時に、VirtualBox+Vagrantを使いだしたことで顕著に感じるようになりました。 また私の所属しているチームの特性上、様々なプロジェクトに関与してプラットフォームもAWSだけで

最近、ちょくちょく起こるのが新着／ホットエントリーしたエントリーがはてなブックマーク入りした際に想定したカテゴリーと違うところに入るケースです。直近では、"Chefを支えるohai。プラットフォームの情報を取得するためのライブラリ"という記事を書いて、"暮らし"に入っておりました。暮らしを支えるライオンですかね。あ、見つめるか。 ということで、ブログのカテゴライズをするのであれば、自分であればどうするか考えてみました。カテゴライズ機能の鉄板といえば、ベイズ推定を使ったカテゴライズだと思います。対抗としては、SVM（回帰分析）があると思いますが、2値分析が得意なSVMよりポイント性のベイズの方がカテゴライズにはあっているような気がします。どちらも教師データ（正解データ）を用意して、学習させる手法です。具体的には、カテゴリーごとにそれにあう数千くらいの記事を用意して、特徴を抽出して覚えさせると

先日の【神戸】OpsWorks (Chef) 特集 !に参加＆登壇してきました。正直なところ、Engine Yardの安藤さんやHiganWorks 澤登さん、クリエーションライン 浦底さんと日本を代表するようなChefの人たちの間で、私が話をしても良いのか悩みました。Chefの説明や技術的な部分ではとても敵わないので、Chefなどを使って自動化して何を目指すのかという所を中心に話をさせて頂きました。 私にとって、自動化もアジャイルもDevOpsも手段でしかありません。目的とすることは、ビジネスで儲かりつつ働く人が楽できるモデルを作ることです。楽しつつ儲かるビジネスモデルであれば、手動でもウォーターフォール型でも何でもよいのです。でも、現状では我々の業界では競争は激化して、現状維持ではジリ貧という状況です。そうなると今まで通りのやり方では、単純に労働強化でしか対応出来ません。そうならない為

セッションタイトル：「開発運用の現場でのChef活用。」 簡単な説明：SIerの現場での、Chef活用について。Knife-Solo,ChefServer,OpsWorksの中から、どういった観点で選んだのか？またインフラ管理とアプリ管理の狭間での、ChefとCapistranoの使い分けについて。インフラの構成管理とアプリのデプロイとAutoScalingの為のAMI化をどう考えるか？一緒に悩みましょう！！Read less

AWS界隈で今一番熱いテーマは何でしょうか？色々ありますが、自動化がその1つでしょう。そして、その実現手段としてChefを取り上げる人はかなり多くいると思います。何故、今この動きが出てくるのでしょうか？ AWS登場前と登場後のサーバ構築 Chefのことを考える前に、AWS登場前と登場後のサーバ構築のプロセスを考えてみます。AWS登場前のオンプレミスサーバの構築の場合、最低でも見積もり⇒発注⇒製造⇒配送⇒設置⇒設定⇒デプロイという工程があると思います。 これに対して、AWSのアカウントが既にあれば、起動⇒設定⇒デプロイという3ステップでシステムが利用出来る状態になります。 AWSの意義 前述のことを考えるとAWSには、2つの意義があると言えます。まずクラウドという文脈で、コンピュータリソースを所有から利用へと変化させたことです。次に、コンピュータリソースを物理の制約から解き放ち、必要な時に必

最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る

Chef Soloの入門として、Knife SoloとAmazon EC2を使ってのセットアップの練習です。Chefの取っ付きにくさは、最初に色々なファイルやフォルダを用意する必要があるところだと思います。そこをKnife Soloは、コマンド1つで初期設定してくれます。ということで、Knife Soloで使い方を覚えるというのは良い選択肢だと思います。今回は、次のようにクライアントからKnife Solo経由でChef Soloを流しこんで、サーバの設定を行う構成になっています。 Amazon Linux AMIの起動 EC2のウィザードから、Amazon Linux AMIを起動します。今回利用したバージョンは、Amazon Linux AMI 2013.03です。インスタンスサイズは何でも良いので、試すだけであればMicroインスタンスで充分です。セキュリティグループなど適時設定して

最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。 何故、fluentdが必要か？ まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。 次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログ

ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。 状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。 Chef Server サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabri

入門Chef Solo - Infrastructure as Codeを読みました。アプリエンジニアだけでなく、インフラエンジニアでもあり1,000台規模のサーバを運用管理してきた経験のある元はてなの伊藤直也さんの著書です。そんなこともあり本書では一貫して実際の運用時の課題を元にChefでどう解決出来るかという観点があり、非常に実用的でした。また入門と銘打う通り、初めてChefを触る人に理解出来るように、概要説明からChef独特の用語説明とその役割、必要とされる背景まで解説してあります。またポイントとしては、Chef Server/Clientではなく、Chef Soloの入門ということです。Chef Server/Clientはフルスタックの機能を使えるのですが、その分構成がややこしくて挫折する人も多いと思います。その点Chef Soloは構成も単純で、手軽に始められるという点で非常に