ChefやPuppet、Vagrantといったサーバーの設定を自動で行うツールが普及しつつあるが、それと同時にサーバーの自動テストについても注目されるようになっている。今回はサーバーの自動テストを実現するツール「Serverspec」をLinux環境で利用する手順を紹介する。 サーバーの自動テストの必要性とテスト駆動開発 最近ではサーバーの設定やソフトウェアのインストールといった作業を自動で行えるツールが注目されている。しかし、設定後のテストについてはあまり注目されておらず、各種設定やソフトウェアのインストールが正しく行われているかどうかは手作業で確認することが一般的だった。しかし、手作業での確認にはミスや抜けが発生する可能性があり、また対象とするサーバーの数が増えるとそれに比例して手間も増えてしまう。そこで活用したいのが、サーバーの自動テストツールだ。 サーバーの自動テストツールは、あら
この記事は最終更新から1年以上経過しています。 気をつけてね。 FAQなので書いておく。ファイル系ってのはこのへん。 cookbook_file template 問題の詳細はCHEF-3045のチケットで確認できます。 要約すると。 Chef-Clientが実行されたら、最初にChef-Server/Client間の認証が行われる ↑の有効期限はデフォルトで15分 ファイル系のリソースはCookbookロード時にはChef-Client実行NodeのCacheには落ちてこない Chef-Clientのリソース収束の段階で、必要なファイルがあったら1で作った認証情報を使ってChef-Server(Bookchelf API)に取りに行く 15分超えてたら4の挙動が403でアウトー キャッシュがある場合はそもそも取りに行かないが、NodeでのChef-Client初回実行時、いっぺんに色々や
ネットワークプログラマビリティ勉強会 #1 - connpass に行ってきたのでメモを残しておきます。 この勉強会の目的と方針(暫定) ネットワークのプログラマビリティに関するオープンな勉強会。 今のところ企画は2人。 あとは仕事のつながりとかで近い方に発表とかをお願いしてる。 経緯 SDNとかNFVはやってきてるけど、いままでクローズドな機械ベースの話してた人たちからすると、なかなかそういうオープンな話や素養を勉強していくのが難しい。 NWエンジニア同士でそういう勉強とか情報交換とか交流とか、なかなかチャンスがないですよね。 プロトコルや標準を作る…という観点ではいろいろやってるだろうけど、ソフトウェア開発とかそういう観点での勉強をやる機会はあまりなかったのではないか。 勉強会 NWエンジニア同士で、NWにおけるプログラマビリティ全般について情報交換をしたい ほかの業界から(インフラ、
みなさんこんにちは。@ryuzeeです。 Chef Serverを使って大規模なインフラを自動運用している場合、当然のことながら各ノードできちんとChef Clientが動作して、指定したロールやクックブックが実行されていることを確認しなければいけません。 残念なことに、継続的インテグレーションでクックブックの品質を常時担保していたとしても、実際にそのクックブックをノードに適用する歳に正常終了するとは限りません。たとえばパッケージの配布元が高負荷で落ちていたといったこともあります。 つまり、Chef Clientが正常に実行が終わったかどうかは監視の対象になるということです。 そこで今回は、Chefのハンドラを使って、SensuやSlackに通知する方法を紹介しましょう。 Chefのハンドラってなんぞ?詳細は公式サイトを見ていただくのが一番ですが、ハンドラとは処理の前後や例外の発生時に別の
templateディレクトリ配下は何で分かれてるかふと疑問だったので見てみた。(今まであんまり分ける必要性を感じてなかったので) 自分で決められるのかと思ったらこういう順番で決まっているらしい。 Blogに書くほどじゃないんでメモっとく。 /host-$fqdn/$source /$platform-$platform_version/$source /$platform/$source /default/$source A cookbook may have a /templates directory structure like this: ex) templates/ host-hostname.example.com windows-6.2 windows-6.1 windows-6.0 windows debian gentoo ubuntu default Register
はじめに 仕事忙しくて全然知らなかったんですけど、Chef-containerというのがリリースされたらしいです。 Cookbookとかの既存資産を流用できるのは大きいなあ、と思いつつ、そうでないなら別に使う必要ないのかも、なんて言いながら、やっぱり興味があるのでちょっと遊んでみます。 以下、ちょっと動かしてみた記録。導入手順くらいにはなると思います。 ※dockerをsudoなしで実行できるようにしてます。 環境 Ubuntu 14.04 Ruby 2.1.2p95 Docker 1.3.0 準備 前提として、既にRuby、Dockerの準備が済んでるものとします。 $ mkdir cc-test $ cd cc-test $ vi Gemfile $ bundle install --path=vendor/bundle $ bundle exec knife container do
poise/python · GitHub を使ってPython環境を作ると、自作のCookBookでpipやvirtualenvが使えるようになります。 poise/python · GitHub で は、Pythonのインストール、pipのインストール、virtualenvのインストールを行います。 インストールする場合はbuild-essentialが必要になります。 また、Redhat系の環境にパッケージでインストールするの場合はyumも必要になります。 インストール方法 recipesのdefault.rbを見ると、他のrecipeをincludeしているので、特に何も指定しなくてもpythonのインストール、pipのインストール、virtualenvのインストールが実行されることがわかります。 include_recipe "python::#{node['python']['
2016年3月4日のSoftLayerユーザー会でお話した資料です。 YouTubeにビデオがありますので、あわせてご覧下さい。https://youtu.be/xxUc7vRjW5k
Travis CIとは、SaaS型の継続的インテグレーションサービスで、GitHub上のプロジェクトのビルド・テストを行えます。 Travis CIはRubyにも対応しているため、これを利用してCookbookのテストを行うことができます。 Travis CIへの登録 Travis CIへの登録は、GitHubのアカウントを利用して行います。 詳細はTravis CI:Documentationを参照してください。 CookbookのテストをTravis CIで実施する Travis CI上でビルド・テストを行うには、対象のプロジェクトのトップディレクトリに.travis.ymlというYAMLファイルを設置し、設定を記載します。 ここではMVT: Knife Test and Travis CIを参考に進めます。 まず、.travis.ymlを用意します。 rubyの環境はrvmを使って1
[2014-09-14-1] に書いたとおり、このmasutaka.netではサーバのCIをして います。 今までテストが通ってから、手動でCook+Serverspecして不便に感じてませ んでしたが、試しにWerckerのデプロイ設定をしてみたら、案外便利でよく 使っています。 wercker.ymlはこんな感じです。 管理画面からDeploy targetを作る必要があります。ちょっと管理画面が古 いですが、こちらを参考にしてください。 wercker + Capistrano で自動デプロイ - milk1000cc’s blog 私はTarget nameをProductionにして、SSH keysで作った鍵を $WERCKER_SSH_KEY_PRIVATEという名前でwercker.ymlから参照できるように しました。 ブラウザからWerckerのサイトに行くのが面倒だけ
[2014-01-09-1] からmasutaka.netのCIを開始したが、残念ながら masutaka.netに直接serverspecする、なんちゃってCIだった。 masutaka.netにcookしてからPRを出して、WerckerにCIさせていた。 WerckerとAWSを連携させて、テストのたびにサーバをまっさらな状態から 作り、終わったら破棄することが可能になったので、ここに記録しておく。 去年くらいに話題になったこの辺の話。 Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー naoya/circleci-serverspec なんで今までやらなかったかというと、cookが一発で通らないレシピになっ ていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえ すればよかった
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
前回 Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。 - Qiita の続きといえば続きです。 Knife-Zeroのページはこちら。 http://knife-zero.github.io/ja/ Chef11.xからローカルモードというのが加わりました。Chef-Client/Server環境の簡易版であり、Soloの代わりでもあります。 Chef-Soloからの乗り換えとしてChef-Zero(ローカルモード)検索が多いようなので、この追記を先頭に移動 このサンプルではSSH越しにローカルモードを実行していますが、単にサーバ側にChef-Repoを置いてローカルモードをしたい場合、 Chefをインストール後にChef-Repoのディレクトリに移動してchef-client -zでOKです。 Soloみたいに
ブログ書きました → 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 soloの簡単な使い方、設定方法一覧メモ。 chefとその他の類似ツール比較 chef soloを使うにあたって、まずはchefとその他の類似ツールの比較。 今回紹介するツール。類似するツールの中では比較的新しく、rubyによるDSLで簡単に記述できることが強み。2013年2月頃にfacebookが肩入れすることが発表されたので今後主流になっていきそう。 後でもうちょい詳しく説明します。 puppet chefがでる前は主流だったツール。私は使ったことないので詳しくないです。 gihyo.jpに18回にも渡る連載があったので、詳しく知りたい人は見るとよさそう。 連載:オープンソースなシステム自動管理ツール Puppet fabric pythonで書かれたシェルスクリプトの薄いラッパーみたいなもの。簡単なコマンドを複数台に適用する時に便利。ほぼシェルスクリプトなので複雑な作業をす
$ ssh melody $ cd /vagrant $ git clone http://github.com/opscode/chef-repo.git $ knife configure WARNING: No knife configuration file found Where should I put the config file? [/home/vagrant/.chef/knife.rb] Please enter the chef server URL: [http://precise32:4000] Please enter an existing username or clientname for the API: [vagrant] Please enter the validation clientname: [chef-validator] Please
## ファイルのリストアをする例外ハンドラ class Chef::Handler::RollBacker < ::Chef::Handler def report run_data = data ## 更新済みリソースの列挙、ハンドラ共通処理 Chef::Log.warn '======= Update Resources are following...' run_data[:updated_resources].each.with_index do |r,idx| Chef::Log.warn [idx, r.to_s].join(':') end ## Chef-Clientが例外で終わった時の処理 if exception ## 更新済みのリソースに対して順番に処理する run_data[:updated_resources].each do |r| case r.resourc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く