はじめに はじめまして。クックパッド株式会社の荒井（@ryot_a_rai）と申します。 今回から全5回、構成管理ツールであるItamaeの入門から実際の活用例までを解説していきます。今まで構成管理ツールを使ったことがなかった方から、Itamaeをすでに使っている方まで、ぜひご覧ください。 Itamaeとは Itamaeは筆者が中心となって開発を進めているオープンソースの構成管理ツールです。同様のツールとしてはPuppet、Chef、Ansibleなどが有名ですが、ItamaeはChefに影響を受けています。Chefの記述性・柔軟性を持ちながら、シンプルで導入しやすい構成管理ツールを目指して開発が進んでいます。 構成管理ツールの必要性 Itamaeの解説を始める前に、構成管理ツールを使う理由について軽く考えてみたいと思います。 サーバ構築の自動化 手動構築の手間と時間を減らす 手動構築によ
Chef から Itamae ？ EY-Officeではサーバーソフトの構築を行うプロビジョニングツールとして現在は Chef-solo を使っています。しかし Chef-solo は終了するらしいのですが、その移行先が良いように思えず悩みながら使い続けてきました。 そんなとき登場してきた Itamae はシンプルでとても魅力を感じました。詳しくは クックパッド開発者ブログのItamae記事 をご覧下さい。 今回時間があったので、EY-Officeの開発支援サーバー (Redmine, Git/Gnatara, CI ...)の全プロビジョニングをChefからItamaeに置き換えてみました。書き換えたレシピは約700行です、そこで感じた事を書きます。 Itamaeの良いところ、良くないところ 1. 情報が貧弱 まず良くない点ですが、Chefのドキュメント に比べると情報の量、質ともに低い
ブログ書きました → Chef-Soloを100倍楽しく使うためのrsoloというツールを作りました。 http://t.co/GI1DrlMx8O #chef #knifesolo — DQNEO.php (@DQNEO) September 27, 2014 @DQNEO ご存知かもしれませんが参考までにどうぞ（最近の流れだとchef-solo -> chef local mode）: http://t.co/wNvSJz3iOR — Shuhei Tanuma (@chobi_e) September 27, 2014 全俺が泣いた。 SoloからZeroへ。Chef Client Local Modeに移行しましょう 詳しくはChef公式ブログの記事に書かれています。 From Solo to Zero: Migrating to Chef Client Local Mode Ch
退職時の引継ぎの際に、chefで自動化されている作業を(chefを使わなくて済むように)サーバ構築手順書としてドキュメント化してくれと言われた…
Chef 12ではこれまで分かれていた商用版とオープンソース版のコードが1本化され、商用版の機能も25ノードまでは無償で利用できるようになりました。 新機能として、VMware vSphereおよびvCloud Airに対応。vCloud Air用のknfifeプラグインも公開されています。また、WindowsのPowerShell DSCとMicrosoft Azureにも対応。Windowsテクノロジーを採用したITインフラの自動化も行えるようになっています。 コンテナ機能にも対応し、Docker用のKnifeプラグインも公開されています。 これまで共有ストレージとDRBDに依存していたChef Serverの高可用機能も強化され、クラウド上での高可用性も実現。まずはAmazonクラウドの機能を用いた高可用性に対応し、今後ほかのクラウドの高可用機能やRedhat Cluster Man
ChefのAttributesで悩んだことがあったのでメモ。結論から言うと、AttributeファイルではできなくてRecipe内で定義するしかなさそう。 説明のために、Chefで構築するソフトウェアが以下のディレクトリ構造であるとする。 /opt +-sample ・・・インストール先のベースディレクトリ +-bin +-data ・・・仮想のソフトウェアのデータディレクトリ +-logs ・・・仮想のソフトウェアのログ出力ディレクトリ このソフトウェアのインストール先、データディレクトリ、ログ出力先をAttributesでパラメタ化する。Attributeを素直に書くとこうなる。 sample/attributes/default.rb default[:sample][:base_dir] = "/opt/sample" default[:sample][:data_dir] = "
本題に入る前に言っておきます。私は、このトピックは重大であるし、Chef Software（以後Chef Incと表記）の一部の人たちにとっては、ことさら重要な意味があると思っています。「Chefはオープンソースではない」という問題に向き合う時が来たのです。いつからそうなったか正確には分かりませんが、この数年間でChefはオープンソースモデルから確実にシフトしてきています。 「でも、コードはGitHubに公開されていますよ」 確かに、文字通りの意味では、コードは自由に閲覧および改変できるようになっていますが、それだけではオープンソースの理念を満たしているとは言えません。なぜなら、オープンソースとは協力してソフトウェアを構築するコミュニティだからです。 「でも、私もパッチを提供したことがありますよ」 皆さんのコントリビューションには感謝しますが、この問題は大局的に捉える必要があります。元々「
Chefマスターから見たら「えっそんなこともちゃんとやってなかったの？情弱」的な感じかもしれませんが、とりあえず自分で気をつけたポイントをメモしてみました。 ほんとはこう分けた方が良いよ！とかありましたら教えてもらえると嬉しいです！ 課題 やっとサービスが成長してきたので、ちゃんとChefで３環境(local, staging, production)を管理しているのですが、 「3rd partyのcookbookも使ってるし、attributeのoverrideをrunlistで行っていて、環境ごとのrunlistに差分が出る。ヤバい。目diff無理」 という素敵な課題が勃発 対策 このrunlist問題に対して、以下のような対策を打って、リファクタしました。 1. バージョンをattribute化してあるものは必ずserver specでテスト えぇ、、、なんでやってなかったんだって怒
chefでサーバーの構築をプログラマブルにやるっていうのはもうだいぶ昔から定番になってきています。 今回は特にMySQL 5.6のインストールをchefで行う場合のケースについて書いていきます。 MySQL5.6はインストールがなかなかめんどくさく、chefを使わなくても結構大変です。 だがしかし、度重なる試行錯誤の末、ついにMySQL5.6をchefでインストールする決定版が出来たため、公開しようと思います! ただし、今回はEC2 + RDS等、webサーバーとDBサーバーを分けて、かつEC2(webサーバー)のみにMySQL5.6をインストールする場合のことを書いていきます。 ちなみにserverはCentOSを想定していますのでubuntuの方はすみません そもそもchefとは MySQL5.6を単純にインストールする場合 MySQL5.6をchefでインストールする まとめ そもそ
データセンター内のサーバ設定やアプリケーションのデプロイなどの自動化ツールとして知られるChefが、Dockerに対応した「Chef Container 0.2.0（beta）」を発表しました。 DockerはLinuxコンテナ技術の1つとして軽量な仮想環境を実現し、分散アプリケーションを迅速にデプロイするなどの用途で広く使われようとしています。Dockerには、Dockerの構成を記述するためのDockerファイルがありますが、分散環境に適した自動化された構成手法が望まれており、現在さまざまな技術が登場しつつあります。 ChefがDockerに対応することで、既存のRecipeやCookbookといった構成ファイルをDockerの環境にも適用できるようになるため、管理者はこれまでの環境をDockerによるLinuxコンテナ環境へと移行しやすくなるでしょう。 Docker内で動作するChe
ちょっと前にリリースされた Berkshelf 3から、Berkshelf APIというインデックスサーバーからクックブックの情報を得るようになりました。 https://github.com/berkshelf/berkshelf/wiki/2.x-to-3.0-Upgrade-Guide https://github.com/berkshelf/berkshelf-api Berkshelf APIを使うと、外部に公開していないクックブックをBerksfileで指定する際の記述が簡潔になります。 まだ日が浅いせいか、Berkshelf API ＋ github:e の情報が少ないので、備忘録も兼ねて残しておきます。 環境は以下のとおりです。 berkshelf (3.1.3) berkshelf-api (2.0.0) Berkshelf APIが必要な理由 Berksfile で c
今年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
Chefでサーバー構築を全部自動化して、借りているさくらVPSに当ててみた。意地でも手作業はまったく入れない完全自動構築設定。これはよい。毎回手作業やらずに済むというのは、抜け漏れをなくすという点でも、構築時間を短縮するという面でも本当に楽。 前提 今回構築するサーバーの前提は次の通り。 CentOS 6.4環境で試行 vagrantを使って試験後、さくらVPSに対して適用 基本の設定として以下を実施 構築用のユーザーを作成 構築用ユーザーにsudo権限を付与 構築用ユーザーを秘密鍵認証でsshログイン許可 rootによるsshログインを禁止 パスワード認証によるログインを禁止 sshのポート番号を変更 ssh, http以外のアクセスをiptablesでシャットアウト nginxを導入 将来的にunicornを入れるための設定を準備 極力サードパーティクックブックは使わない（ブラックボッ
こんにちは、せーのです。 Chef SoloやKnife SoloにChef Server同様environmentがサポートされてから、レシピの書き方が一気に広がりました。 広がった結果、Attributeをどこに書いていいのか迷う人も多いのではないでしょうか。私は迷います。 Chefは結構ゆるーい感じなので、特に「こういう場合にはここに書きなさい」という決まりがあまりありません。 この「決まりがない」というのがクセモノで、ついついAttributeをバラバラに書いてしまい、Cookbookが会社の共有資産になった時に余計な値が埋め込まれる、という事例が多発したりしないでしょうか。私はします。 Attributeには順位があり、より上位の場所にAttributeを書くと下位の値が上書きされます。まずこの順番を体感で覚えておくことが重要です。 Attributeの順位はドキュメントに書いて
1年くらいchefを使ってサーバ構築をしていたのですが、最近ansibleに乗り換えたので紹介記事を書いてみます 1. サーバ側に何もインストールする必要がない chefは管理対象ノードにchef-clientをインストールする必要がありますが、ansibleはPython 2.4が入っていて、sshでログインできればOKです。 chefもパッケージや,knife bootstrapコマンド等があるので始めやすいですが、何もする必要がないansibleの方が敷居が低いのかなと思ってます。 例えばsshでログインできれば、以下のコマンドを打てば10.0.10.1～10.0.10.3サーバの情報をとってくれます(カーネルバージョン,CPU,メモリ,ディスクサイズ,ディストリビューション等)。 この機能はchefで使われているohai相当のことをしてくれます。 echo 10.0.10.1 >
薄い本(chef-solo本)、普通の本(Chef実践入門)、厚い本(Chef活用ガイド)の3冊をもって Chef三種の神本として本棚に祀ることをおすすめいたします。 書籍毎によるおすすめ chef-solo本(薄い本) 本を読むのが苦手、取り敢えずChefというものを動かしてみたい人向き Chef実践入門(普通の本) Chefはどのようなものか、手元でVagrantなどを利用して手で動かしながら学びたい人向き Chef活用ガイド(厚い本) 普段からChefを利用しているユーザのリファレンス、およびふとした瞬間に開いて発見したい人向き Chefを初めてさわる人へ Chefを取り敢えず触ってみようという人が どちらを購入すべきか迷われる可能性は多いにあるかと思うので、 参考程度に違いを記載します。 Chefの導入自体が、会社にとって大変大掛かりなタスクになる可能性がある場合は まずご自身が_
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 チームや組織、プロダクトをまたいでcookbookを使っていく場合に使えるcookbookの書き分け方を紹介します。 要はプロダクト毎にサーバに対する要求は変わりうるのでサービス毎にcookbookを分けるんだけど、会社全体として組織プロダクトをまたいで共通化しておきたい部分は共通のcookbookを使いましょうという話です。 こういう分け方をしたらよい、という話もします。 組織やプロダクトの成長とcookbook 小さな組織やチーム内でchefを導入した場合、cookbookを書くのは大抵の場合一人だと思います。 扱うサーバの種
はじめに こんにちは植木和樹です。2014年4月28日にアスキー・メディアワークスより「Chef活用ガイド コードではじめる構成管理」が出版されました。 Amazonでチェックする 実は私、本書のレビューに参加させていただきまして、4月の下旬にクリエーションライン様より本を頂戴していたのですが、ご紹介に時間が経ってしまって申し訳ありませんでした。 手元に本が届いて最初の感想が「厚っ！重っ！」というものでした。レビューは電子ファイルで行っていたのでピンとこなかったのですが、ページ数にして671ページ（！）あります。ビックリなボリュームです。決してボリュームに腰が引けてレビューが遅れたわけではないんですよ。 Chef初めての人には「入門Chef Solo」それは変わらず 私自身Chefを知り使い始めたのは昨年2013年の2月頃です。ちょうどネット界隈でChefが話題になった時期ですね。その後、
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 全国1000万人のInfrastructure as Code職人とImmutable Infrastructure芸人のみなさんこんばんは！ ということでタイトルの通りなのですが、このたび5月22日に「Chef実践入門 コードによるインフラ構成の自動化」(技術評論社)が発売になりますのでお知らせいたします。 本の表紙はこんな感じになります（カバーの色やデザインは変更の可能性があります）。 ご予約は、こちらで受付中です！昨年前半に着手していたので随分時間がかかってしまいましたが、なんとか出すことができました。 今回はCakePHP界隈でもおなじみの安藤祐介さん、イケメン寿司＆ドラクエ好きでおなじみの伊藤直也さん、Ruby使い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
