opscodeのリポジトリにあるMySQLのcookbookでは、rootユーザやレプリケーション用のユーザのパスワードをランダムに生成して設定している。 opscode の recipe の特徴 このランダムという点をカバーするべく、うまい仕組みが組み込まれている。 パスワードを設定するところは node.set_unless['mysql']['server_root_password'] = secure_password といった形で、attributeに設定されていない場合はランダムに生成するという事をして、2度目以降も同じパスワードとなるようになっている。 2回目以降も同じパスワードを保証するために、もうひとつの技が unless Chef::Config[:solo] ruby_block "save node data" do block do node.save end
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
斎藤です。こんにちは。 Chef の話題がアツくなっている今日この頃、みなさまいかがお過ごしでしょうか？Chefの解説本も出つつある今日この頃ではありますが、プログラミングそのものに慣れないうちはそれさえ読むのもちょっと大変かもしれません。そこで今回は、 Chef のレシピ＋ライブラリを用いて、MySQLの設定の自動化を試します。いわゆる「写経」から始めてみて、少しずつ「手動」からプログラムを通じた「自動化」にチャレンジしてみましょう。 ※Chef 11.04.0, knife-solo 0.2.0, Ruby 1.9.3p327, CentOS 6.3 で検証しています。 今回のお題 MySQLサーバをインストールしてみます。ITインフラを構築・運用している方ならご存知かと思いますが、MySQLはインストールだけでなくmy.cnfの設定までが作業です。その際にinnodb_buffer_
ChefSpecはCookbookテストフレームワークです。RSpecを用いたテスト駆動開発(TDD, Test Driven Development)と呼ばれる開発手法のためのテストフレームワークで、まずテストを書き、次のそのテストをパスするコードを書き、それらを繰り返して開発を進めていくという手順を取ります。実際にCookbookをノードに適用せず、Cookbookが期待した動作を行うように記述されているかどうかをテストします。 ChefSpecのインストール gemでインストールが可能です。 なお、以前インストールできるChefSpec 0.9.0はChef 11には対応していなかったので、インストールオプションに--preをつけるか、--version '1.0.0.rc1'をつけてChefSpec 1.0.0.rc1をインストールする必要がありました(Error in runni
ガリレオスコープ開発チームによる �最新Web動向、技術メモ ( Ruby, Rails, node.js ) です 序CentOS6にて、Chefを導入しようと、chef-soloでuser登録しようと頑張っていました。 ためしに、パスワードを"ユーザー名+0123"にしてみようと思って以下を書いてみました。 %w(yamda sato).each_with_index do |u,i| user "activate_#{u}" do username u password "#{u}0123" home "/home/#{user}" shell "/bin/bash" uid 500+i gid 10 end end ところが、パスワードが上手く設定できないorz。 ということで、色々調べると、 chefのuserのパスワードは平文でそのまま設定することはダメみたいです。 /etc/
OpscodeのChefとは何なのかを中級者以上向けに説明します。 普通のHow to とは方向性が違うので注意。Read less
先日 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
問題 VMをぽこぽこ作りながらあれこれツールを入れて試してみたりしたいという時に、chefを使って構成管理はしたいけど、chef-serverを入れるのは面倒、というか、構成パッケージの記述・インストールだけできればいいという要求からするとオーバスペックなように感じるのだし、また、ホストの管理にはcapistranoを使っているので、cap実行側のみで処理が完結する方がよいという場合もあろうかと思う。 前提 デプロイ先ホストには、公開鍵認証でログインできるものとする(capを使うので) デプロイ先ホストでは、既にgit, chef-soloが使える状態であるものとする(そこまではなんらかの方法でがんばる) 解決案 そこで、chef-soloという、chef-serverなし、スタンドアロンにレシピの実行を行うコマンドをcapで実行するようにしてみる方法を試してみた。例として、GrowthF
たくさんのホストをChef設定したいけどChefサーバー立てるのめんどくさいし！ でもコマンド一発ですべてのホストが更新されて欲しいし！ というわけでこの組み合わせです。 Capistranoはインストール済みでsshのログインに必要な鍵も各ホストに配ってあるものとする。 加えてChefのクックブックなどはすでに定義済みで以下のパスにある前提で。 /home/akahige/chef-repo Chefに関してはここでは深くつっこまないので、よかったら以前書いたものをどうぞ。 chef-soloで作業環境構築の自動化 | ひげろぐ Chefを試してみた | ひげろぐ sudoの設定 chef-soloはsudo経由（root権限）で実行する必要がある。 そしてCapistranoでsudoを実行するにはパスワードなしでコマンドを実行できる必要がある。 そういう事情なのですべてのホストにてs
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
