Chef-ClientにはWhitelist Attributesという機能があって、Ohaiが収集した(Automatic)Attributesから、任意のAttributeのみ保存対象することができます。 使い方はclient.rbに書けばOK。 Knife Zero Bootstrap で普通にnodeオブジェクトを作成するとでかい 適当なAmazon EC2インスタンスにbootstrapを仕掛けてみます。 $ knife zero bootstrap 52.69.40.215 -x ec2-user -i ~/.ssh/privatekey --hint ec2 -N test-server Doing old-style registration with the validation key at ... Delete your validation key in order
こんにちは、sunflatです。 今期のアニメは、とんかつDJアゲ太郎と宇宙パトロールルル子が好きです。 今回は、リモートのサーバーを設定するためのツールである Knife-Zero を使った時に、つまづいた点とその解決策をまとめてみました。 Knife-Zero とは Misocaでは、サーバーの設定の自動化にChefを使っています。 Chefのレシピ（設定手順をコードで書いたもの）をリモートのノードに適用するためのツールとして、Misocaでは以前から knife-solo を使っていました。しかし、knife-soloが使っているChefの機能であるChef Soloが非推奨となったことなどから、代わりにKnife-Zeroを使うことを計画しています。 *1 Knife-Zero を使った時につまづいた点とその解決策 その1. ノードファイルに色々書き込まれる knife-solo
よく使うものを逆引きできるように。 アンチパターンを知る http://www.slideshare.net/JulianDunn/beginner-chef-antipatterns http://www.creationline.com/lab/3080 すべてのChefデータを1つの巨大なGitレポジトリに入れてしまう cookbooksにはバージョンがあるが、environmentsやrolesにはない cookbooksとして分割すべきものはリポジトリを分けるべき 会社名つきの巨大なCookbookを作ってしまう 本来組み合わせるべきでないものが混ざる危険がある プロジェクト別に分けるべき Environmentsを論理的な環境以上の目的で使ってしまう developmentとかproductionとか論理的な環境で使い、クラスタとかデータセンターといった割り当てに使わない Co
こんにちは、せーのです。 Chef SoloやKnife SoloにChef Server同様environmentがサポートされてから、レシピの書き方が一気に広がりました。 広がった結果、Attributeをどこに書いていいのか迷う人も多いのではないでしょうか。私は迷います。 Chefは結構ゆるーい感じなので、特に「こういう場合にはここに書きなさい」という決まりがあまりありません。 この「決まりがない」というのがクセモノで、ついついAttributeをバラバラに書いてしまい、Cookbookが会社の共有資産になった時に余計な値が埋め込まれる、という事例が多発したりしないでしょうか。私はします。 Attributeには順位があり、より上位の場所にAttributeを書くと下位の値が上書きされます。まずこの順番を体感で覚えておくことが重要です。 Attributeの順位はドキュメントに書いて
Chef を使い始めた頃からちょっと引っかかっていたことなのですけど、インストールするパッケージの設定ファイル等の作成・編集を template/cookbook_file リソースで行うか、bash/execute 等のリソースで sed を使って置換して行うかという課題。現在は一応自分の方針がまとまって、以下の方針で使い分けるようにしていますので軽くまとめ。 常時起動させるサービスの設定ファイルは template/cookbook_file リソース 設定ファイルを変更した後に、reload や restart が必要なパッケージの場合は、template/cookbook_file を使うようにしています。つまり chkconfig on にしてサービスとして起動させるパッケージの場合は、必ず template か cookbook_file リソースのどちらかで設定ファイルを作成
レシピ職人になろうかな。 recipeにはシステムのあるべき姿を記述する。 recipeはResourceという命令単位で記述する。 Resourceの基本構文 {Resourceタイプ} "Resource名" do # (1)実行条件 {only_if | not_if} { {条件文} } # (2)Action action :action # 後述のResourceタイプ毎のActionテーブルを参照 # (3)Notifications {notifies|subscribes} :action, "{Resourceタイプ[Resource名]}",｛:immediately|:delayed} # (4)Attribute {attribute} "value" # 後述のResourceタイプ毎のAttributeテーブルを参照 end (1)実行条件 「only_if」
October 26, 2014 サーバ/インフラ徹底攻略 (WEB+DB PRESS plus) ご恵贈ありがとうございます！ TL;DR mizzyさんのServerspecを利用したインフラCIの章、 サイバーエージェント社のメンテナンスの章は最高だった もくじ 巻頭企画 ［入門］コードによるインフラ構築 サーバ構成管理の自動化を実現する 第1章：ChefとVagrantによるインフラのコード化 設定の一元管理で作業を省力化する……伊藤 直也 第2章：Serverspecによるテスト駆動インフラ構築 設定変更の反映を確実なものにする……伊藤 直也 特集1 Amazon Web Services最新活用 レイヤ別比較，構築の定石，構成管理の自動化 第1章：Amazon Web Servicesレイヤ別比較 各サービスの特徴を理解し，うまく使い分ける……片山 暁雄，平山 毅 第2章：EC
最近プライベートなプロジェクトのCIにはcircleciとかが人気なんでしょうかね。 GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー 近頃のCIサーバはアプリケーションのテストだけじゃなく、インフラのテストやデプロイ、ChatOpsなどgitやチャットツールなど他のシステムと連携した自動化のための必須プラットフォームといった感じになってきてる。とはいえ、趣味で開発しているプロダクトに余計なコストはかけたくない。ああ、でもやっぱCIはしたい。 そんなわけで以前から契約だけしていて放置気味だった、さくらのVPSの1GにjenkinsをたててオレオレCIを育てているのでその辺のことを書いてみる。CIの実行環境はDockerを使って仮想化し、ジョブの内容はTravisやcircleciのようにリポジトリ側のyamlファイルに記述できるようにしてみた。構成をざっくりと図解すると以
ブログ書きました → 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
##概要 仮想環境（VirtualBoxなど）上への仮想マシンの立ち上げ、操作が可能。 ##用語 ###プロバイダ 仮想環境 eg.VirtualBoxやVM Ware、EC2など ###プロビジョニング ミドルウェアの設定やインストールを行うツール eg.シェルスクリプト、Chef（chef-solo, chef-client）、Puppetなど ###Boxファイル 仮想マシン起動の際にベースとなるイメージファイルのこと。 仮想環境ごとに必要。 通常はOSイメージから作成する。 Vagrant利用の上で最低限必要な設定（Vagrantユーザの作成、sshdの起動、プロビジョニングツールのインストール）のみを行っておくのが普通。 ###Vagrantfile 構築する仮装マシンのスペックやプロビジョニングツールの指定など、仮想マシンの構成を記述する。 Rubyベース。 基本的に、本ファイ
Engine Yardさんの勉強会に行ってきた 皆さんこんにちは。 2/22に開催されたChefの勉強会に行ってきました。 事務所の引っ越しなどでバタバタしていたので時間が経ってしまいましたが、参加して分かったことを元に、本エントリーではvagrantの仮想環境をchef-soloで設定できるようにしてみたいと思います。 というかはてブのトップがこのネタばかりで、なんというか旬を逃した感が拭えないんですけど…、よろしくおつきあいください。 どうしてchefとvagrant？ 以前からちょいちょい動作確認環境のをvagrantで用意していました。で、毎回環境作るのがめんどいぞと。頻度がそんなになかったんで、ある意味我慢してました。一方で、社内の環境を chef-solo 使って環境構築することはあったんですけど、管理する対象はvagrantで構築したのとは別の環境だったり。。。ちょっとちぐは
OpscodeのChefとは何なのかを中級者以上向けに説明します。 普通のHow to とは方向性が違うので注意。Read less
Chef-Soloをやるにあたって、とりあえずknife-soloを入れとけって、「入門Chef Solo」に書いてあったので、入れてみることにしたよ。 knife-soloのインストールを試みる $ sudo gem install knife-solo ERROR: Error installing knife-solo: mime-types requires Ruby version >= 1.9.2. いきなり玉砕（笑） Rubyのバージョンを1.9.2以上にしろって怒られた。 バージョンを確認してみる。 $ ruby -v ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0] うむ、確かに古い。 rbenvのインストール rbenvを入れると、Rubyのバージョンを切り替えて使えるようになるので、まずコイツか
皆様、はじめまして。2010年9月に入社した並河です。 インフラ周りの話題を・・・ということで、今回はサーバの構築やシステム管理作業を楽にしてくれるツールである「Chef」について紹介します。 ■ Chefとは「Chef」は、サーバOSでのインストール・設定・各サービスの状態管理等、諸々のシステム構築や運用作業を自動化してくれるRuby製のシステム管理ツールで、オープンソースとして公開されており、既に、37signalsやEngine Yard、RightScaleなどでも使われており、利用実績も出始めています。 Ruby製のシステム管理ツールといえば「Puppet」を思い浮かべる方も多いのではないでしょうか。ChefはPuppetの競合ソフトウェアとなる位置付けで、出来ることだけでいうと、特別大きな差はないと感じていますが、Puppetは外部DSLとして設定を記載するのに対し、Chefは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く