概要 チームや組織、プロダクトをまたいでcookbookを使っていく場合に使えるcookbookの書き分け方を紹介します。 要はプロダクト毎にサーバに対する要求は変わりうるのでサービス毎にcookbookを分けるんだけど、会社全体として組織プロダクトをまたいで共通化しておきたい部分は共通のcookbookを使いましょうという話です。 こういう分け方をしたらよい、という話もします。 組織やプロダクトの成長とcookbook 小さな組織やチーム内でchefを導入した場合、cookbookを書くのは大抵の場合一人だと思います。 扱うサーバの種類もそんなに多くないので、apacheのインストールやphpの設定を一つのrecipeにベタ書きしても人間が管理できるボリュームに収まると思います。 というか、変に分割するよりもベタ書きのほうがrecipeの見通しがいいと思います。 ところが、組織が大きくな

はじめに DockerでコンテナイメージをbuildするときにはDockerfileにOSイメージの指定や導入パッケージ、実行したいコマンドなどを記述してパッケージングします。 このDockerfileはほぼコマンドべた書きのような形なので難しいわけでは無いのですが、実行処理が多くなればなるほど長く読みづらくしまうし、テストも大変です。また既にChefやPuppet、Ansibleなどの構成管理ツールを用いているのであれば、既存の資産をうまく流用したほうが楽が出来ます。 ということで、Dockerfileにはほとんど仕事をさせずに、Dockerfileからchef-soloをキックしてコンテナをプロビジョニングしてみました。 やってみた ファイル構成は以下のような形です。今回はopscode謹製のbuild-essentialをレシピとして用意しました。 . ├── Dockerfile

Chef Soloの正しい始め方 | tsuchikazu blogがどういうわけかgoogleさんに好かれているので、続編を書きました。入門Chef Soloと正しい始め方を読んで、じゃあ実際に色々やってみようかな。とはいえ、チュートリアル的なことでなく、もうちょっと実践的なことをして理解を深めたい。このような人を対象に、さくらVPSの初期設定を題材に、Chef Soloを説明していきます。 この記事でやることは以下のとおりです 一般ユーザの作成 鍵認証の設定 sudo有効化 sshの設定 iptablesの設定 さくらVPSでよく行われる初期設定で、これを実施すればrootが乗っ取られてヤバイことになった。とかそういう事態は防げるはずです。AWSのEC2ですと、デフォルトで設定される内容になっていますので、さくらVPSをEC2レベルまでセキュリティ向上させるのを目標にします。 前提 自

cookbookを書くときの冪等性 cookbookはインストール時だけでなく、何度実行しても同じ状態に保たれることが重要視されます。 chef業界ではこれを冪等性（べきとうせい）と読んでいたりします。これは設定ファイルやパッケージのインストールなど、すべてに当てはまります。 例えば、パッケージシステム経由でvimをインストールするようば場合のrecipeは以下のようにして書きます。 package 'vim' このようにすることで、それぞれのディストリビューションにあったパッケージシステムをつかってvimをインストールしてくれます。当然、二重にインストールされることはありません。 sourceからインストールするcookbook たとえばCentOSにphpをパッケージ経由でインストールすると、ちょっと古いバージョンのものがインストールされてしまいます。 新しいバージョンを使いたい場合は

今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr

類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att

自動化ツールの必要性 昨今、仮想化およびクラウドの普及に伴い、サーバを短時間で増設することが容易になってきました。例えばユーザアクセスが増えてシステムの負荷が高くなった場合、サーバそのものは即座に準備できるようになりました。しかし、システムの設定は別途実施しなければいけないという状況も多々見受けられています。 サーバの台数が少なければ一台一台構築や設定を行えますが、何百台ものサーバを扱うとなると時間がかかって迅速性は失われてしまいますし、多くの人手が必要となれば設定の間違いが起こる可能性も高くなるでしょう。そして管理するサーバが増えたとしても、それらを管理する人は増えていないのが現状です。 そのため、サーバ構築とともにアプリケーションやミドルウェアの設定をも実施する自動化ツールが注目されています。 Chefとは Chef（シェフ）は、米Opscode社が提供するクラウドコンピューティングを

サーバー管理ツール「Chef（シェフ）」は、ファイルに記述した設定内容に応じて自動的にユーザーの作成やパッケージのインストール、設定ファイルの編集などを行うツールだ。今回はChefの応用編として、Chefサーバーなしに複数台のサーバー管理を行う「knife-solo」というツールと、設定のためのデータなどを一元管理できる「Data Bag」という仕組みを紹介する。 knife-soloを使った複数台サーバー管理 Chefは「Cookbook（クックブック）」や「Recipe（レシピ）」と呼ばれる設定ファイルに従って、ユーザーの作成やソフトウェアのインストール、ネットワークやファイアウォール、データベースなどの設定など、さまざまな設定作業を自動で実行するツールだ。利用するメリットとしてサーバーの設定を一元的に管理できる、実行する設定内容をチェックしやすくミスを防ぎやすいなどがあり、近年注目を

前提 必要なファイルをインストール 今回の環境は以下のとおりです。（MacOSX） VirtualBox 4.2.18 r88780 Vagrant 1.3.4 Ruby 2.0.0p247 Bundler 1.3.5 (Ruby Gems) VirtualBox => https://www.virtualbox.org/wiki/Downloads Vagrant => http://downloads.vagrantup.com/ Ruby => rbenvやrvmなんでもいいので1.9以上を入れるといいと思います bundler(Ruby Gems) => 「gem install bundler」としてbundlerを入れる 初期ディレクトリ /tmp以下を今回の作業環境とする。以下のディレクトリ構成を作る。

Chef を使っていると、not_if を使うケースが多くなると思います。 not_if の条件や、オプションについて備忘録を残したくなったので投稿します。 すべて、次のページに書いてある内容です。 http://docs.opscode.com/resource_template.html まずは、ある特定のファイルがないときに command execute したいときの書き方。基本的な書き方ですね。 execute "aaa" do command "git clone https://github.com/aaa" not_if { File.exists?("/home/vagrant/aaa") } end 次に、template です。template にも not_if 渡せること知りませんでした。(勉強不足) また、not_if で grep 渡せること知りませんでした。

前提 knifeとは Chefレポジトリを操作するためのツール。 chef solo環境で利用するのは主に以下の二つ ・knife cookbook（クックブックの作成） ・knife solo 前者は生のchef soloを利用する場合に用いる。 詳しくは以下。 Chefの基本 http://qiita.com/kidachi_/items/9d569b8673e70ef93f0e knife-soloとは 今回のトピックはこちら。 それ単体でリポジトリやクックブックの作成、実行まで一括して行ってくれる。 基本はchef soloを利用したい場合はこのknife soloに頼ればok。 knifeの初期設定

社内でBerkshelfがウワサになっていたので試してみた。 Berkshelfとは？ Berkshelfとは、「Chefのcookbookとその依存関係を管理するツール」らしい。 要するに、定義ファイルに使うcookbookを定義しておけば、リポジトリから勝手に依存関係を解消した上で 落としてきてくれるらしい。RubyのBundlerみたいな感じ。 同じようなので、Librarian-Chefというのもあるが、Berkshelfの方が現時点で主流っぽい。 Berkshelfの使い方 Berkshelfはgemで配布されているので、gem installでインストールできる。 使用したいcookbookを定義するBerksfileを作成する。 Berkshelfの公式サイトにも書いてあるが、opscodeからmysqlとnginxのcookbookを使う場合はこんな感じ。 cookbook

Provisioning Frameworks Casual Talks vol.1 (https://gist.github.com/studio3104/5417631) での発表スライドです

先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2　なにこれすごい。 % vagra

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

2013/05/13 この記事は書かれてから1年以上が経過しており、最新の情報とは異なる可能性があります techChefVagrantvirtualization だんだんと Chef いじりが楽しくなってきた girigiribauer です、こんにちは。 この前**『入門 Chef Solo』**というKindle本（電子書籍）を購入して、休憩時などに少しずつ読み進めていたのですが、 ようやくざっと一通り目を通すことができました。 今回以降、この辺も見ながらいろいろ試してみようと思います。 レシピを書くとどんなことが設定できるの？前回までで、Vagrant と Chef を連携させて、 超シンプルなレシピを書いてみたわけですが、 今回はレシピを書くことで他にどんなことが出来ちゃうのかを、もう少し試してみようと思います！ 『入門 Chef Solo』に、この Cookbook はユーザ

OpsCode社のシニアコンサルタントであるJulianさんがChefConf2013で話された内容が参考になるので、簡単に紹介します。 スライドはこちらに公開されています。 また動画はこちらです。 ここで出てこない話として僕がやるべきだと思うことは「テストを書くこと」です。 test-kitchenとserverspecの組み合わせがおすすめです。 ばかでかいレポジトリをつくらないいろいろなものをまぜこぜにしない たくさんのレポジトリに分割するのを怖がらない (opscodeも昨年opscode/cookbooksの巨大構成から、opscode-cookbooks/個別cookbookに構成を変えています) 個々のCookbookの連携はBerkshelf使えば大丈夫 全員が共用するような会社用Cookbookをつくらない関係ないプロジェクトのものが含まれると見通しが悪くなる 大きすぎる