Wakame-vdc

2014年12月09日

このエントリーをはてなブックマークに追加

Wakame-vdc / OpenVNet Advent Calendar 2014 12/09担当 (2回目)

enter image description here

引き続き、開発の話は、開発担当者にお任せし、自分はCI環境周りのお話。

開発者がコミットしてからmasterにmergeされるまでの流れ

略図を書き出してみると、下記の様になる。

wakame-vdc-ci

各工程ごとに簡単な説明

branch base build / spot-build

wakame-vdc-ci


  1. JenkinsUIのbuild用ジョブから、
  2. branch名を指定し、
  3. ビルドボタンを押下

34f9c1e4-4bc7-11e4-8890-77fed9adf628


今の所、この工程は、敢えて手作業。

rpmbuild: kemumaki

wakame-vdc-ci


  • rpmbuild用chroot環境構築
  • wakame-vdcのrpmbuildのspecファイルからrpmをbuild
  • ローカルyumリポジトリを生成
1box: vmapp-vdc-1box

wakame-vdc-ci


  • vmbuilderを使い、
  • KVM用マシンイメージをbuild
  • Wakame-vdcデモ環境構築configセット
smoketesting: mussel

wakame-vdc-ci


  • APIクライアント
  • 正常性確認用シナリオテスト
    • 簡単なシナリオを挙げると、
      • API呼び出しをしてインスタンス作成
      • インスタンス作成後、SSH接続
      • インスタンスを破棄
GitHub Flow 連携

wakame-vdc-ci


  1. PRを作成
  2. CI環境におけるbuild工程の結果が、コメントに反映される
  3. レビュー担当者によるレビュー
  4. Mergeし、PRを閉じる

9310550c-4bc9-11e4-93fb-22c9e36858da


※Merge後は、リリース工程が存在する。今回はdeveloperに関わる範囲のみなので省略。

developerの負担を可能な限り少なく

以上の様に、developerが登場するのは3回のみで、操作対象はGitHub 2回、JenkinsUI 1回。 その他の作業はCI環境が面倒を見る。build工程は人手を介さないので、失敗する時は毎回失敗する。今時点の課題の1つは、結果が出るまでの時間。buildボタンを押してから、1時間半後に結果が出る。build行程を考慮すると、いくつかは妥協が必要。なお、buildが途中で失敗する場合は、失敗した時点で中断する。

CI構築期間の参考に

この仕組みが出来上がるまでに、1人で、1年半。(他作業を掛け持ちしながら)

あとがき

一度動いてしまえば、あとは継続的改善。




編集
@hansode at 10:30|PermalinkComments(0)TrackBack(0)

2013年12月20日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/20担当 (6回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の風景をお届けします。

Wakame-vdcを読み解く

背景

困った時がドキュメントの書き時。今回は下記状況に陥って困った。

環境構成:

  • カナリア環境(しばらく稼働させてる環境)
  • ナイトリービルドによりスモークテスト実施

遭遇した状態:

  • どうやら断続的に node.state が !online状態(onlineではない状態の意味)のhvaが登場
    • 何故、断続的だと判断できるのは、一定時間経過したジョブを処理していたから
  • 何故 !online になっていたのか・・・を調査したいが、今の実装では state 変更をロギングする仕組みがないくて、ログだけでは調査出来ない
  • 今できる事は、state変更ロジックを確認しておく事

未理解な内部実装を理解する為、目出度く?!コードリーディングを開始したのであった。

パッケージバージョン
  • isono 0.2.19
  • wakame-vdc 13.08.0
家族構成

wakame-vdcは、複数agentによってクラスタが構成されていて、各agentはAMQPネットワークに参加している。この辺の詳細は、また後日、追い詰められた時に、書くのだと思う。触れる必要が中たっ為、今回は省略。

dcmgr-agent-cluster

今回の第一調査対象はhva。

役者: hva

hvaを覗いてみる。

wakame-vdc/dcmgr/bin/hva#L35

途中をざっくりと端折りつつ、読み解いて分かった事は、

  • NodeHeartbeatによって各agentがpingしているようだ
  • NodeHeartbeatの結果を集計しているのはNodeCollector
  • NodeCollectorモジュールを刺してるagentが誰か…
役者: collector

NodeCollectorモジュールを刺してるのは、collector。

wakame-vdc/dcmgr/bin/collector#L24

この先は、wakame-vdcではなく、Isono家の謎に迫る必要がある。さよなら、Wakameちゃん。

Isono家の謎 『状態遷移の条件』

状態遷移する条件を探していくと、

isono/node_modules/node_heartbeat.rb#L12-L19

      initialize_hook do
        @timer = EventMachine::PeriodicTimer.new(config_section.heartbeat_offset_time.to_f) {
          rpc = RpcChannel.new(node)
          rpc.request('node-collector', 'notify', manifest.node_id, node.boot_token) do |req|
            req.oneshot = true
          end
        }
      end

heartbeat_offset_time毎に、NodeCollector宛てにnotifyしてる事が分かる。

heartbeat_offset_timeは、何秒?

isono/node_modules/node_heartbeat.rb#L7-L10

      config_section do |c|
        desc "second(s) to wait until send the next heartbeat signal"
        heartbeat_offset_time 10
      end

明示設定が無い場合、 heartbeat_offset_time は 10 秒。

stateが !:online になる条件は?

少なくとも online ではない事までは分かっている。そうなると、!:onelineになる条件と、!:onlineとは、具体的に何かを探っていくと、node_stateモデルに辿り着く。

isono/models/node_state.rb#L23-L45

      def after_initialize
        self[:state] ||= :init
      end

      def process_event(ev, *args)
        case [ev, self.state.to_sym]
        when [:on_ping, :online], [:on_ping, :init], [:on_ping, :timeout]
          self.state = :online
          self.last_ping_at = Time.now
        when [:on_unmonitor, :online]
          self.state = :offline
        when [:on_unmonitor, :timeout]
          self.state = :offline
        when [:on_unmonitor, :init]
          self.state = :offline
        when [:on_timeout, :online], [:on_timeout, :timeout]
          self.state = :timeout
        when [:on_timeout, :init]
          # Do nothing
        else
          raise "Unknown state transition: #{ev}, #{self.state}"
        end
      end

onelineを含め、どんな状態になりえるのかが分かる。

  • init
  • oneline
  • timeout
  • offline

どの条件で、どうなるか・・・わけWakame(やっと使えた!)なので、直感的に分かりやすくしたくて図にしてみると、

isono-fsm

これで状態遷移を俯瞰しやすい。少なくとも普段コードを書かない自分にとっては最高に読みやすい。今回に限らず、今後の調査材料として役立つ。

前述の通りで、!onelineからonlineへ遷移してるのだから、その経路は絞られる。

!onlineからonlineへ遷移してるのだから・・・

online ⇒ timeout ⇒ online だった事が分かって来る。

isono/node_modules/node_collector.rb#L32-L49

            Models::NodeState.dataset.all.each { |row|
              next if row.state == :offline

              diff_time = Time.now - row[:last_ping_at]
              if row.state != :timeout && diff_time > config_section.timeout_sec
                row.process_event(:on_timeout)
                row.save_changes
                event.publish('node_collector/timedout', :args=>[row.values])
              end

              if diff_time > config_section.kill_sec
                row.process_event(:on_unmonitor)

                event.publish('node_collector/killed', :args=>[row.values])
                row.destroy
              end
            }
          }
  • 最終pingから何秒経過しているか
  • とある閾値を越えている場合、timeoutとして判定

と言う事が分かる。

閾値 config_section.timeout_sec は?

isono/node_modules/node_collector.rb#L8-L15

      config_section do
        desc "time in second to recognize if the agent is timed out"
        timeout_sec (10*2).to_f
        desc "the agent to be killed from the datasource after the time of second"
        kill_sec (10*2*2).to_f
        desc ""
        gc_period 20.0
      end
  • 明示指定が無い場合、 timeout_sec は (10*2).to_f => 20.0
Isono家の安否確認まとめ
  • 各agentは、一定時刻(10秒)毎に生存してる事を通知
  • NodeCollectorは、前回の確認時刻から一定時刻(20秒)以内に通知して来たかどうかを確認
    • 時間以内通知の場合は、online
      • 一定時間が経過してる場合は、timeout

Isono家は、20秒以内に返事しないagentを、timeout扱いする。

Isono家の安否確認を踏まえて、当時の状況を考察すると
  • 20秒以内に返事して無いhvaが居た

と言う事までが判明。しかし、何故返事してなかったのかは、謎のまま。Isono家とは違う次元の何かが起きていたようだ。調査は続くのであった。

あとがき

追い詰められた時の学習意欲。

参考文献



編集
@hansode at 10:00|PermalinkComments(0)TrackBack(0)

2013年12月19日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/19担当 (5回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の声をお届けします。

もうすぐRHEL7がリリースされる

先日、RHEL7betaがリリースされた。今後やるであろうRHEL7対応作業へ向けて、ここ数日で気になった3項目に関して頭の中を整理してみた。

  1. epel6 -> epel7
  2. msyql -> mariadb
  3. systemd対応
1. epel6 -> epel7
  • epel-release-7-x.rpmへ変更する程度で済むはず
  • それと、rpmbuildツールが少し頑張れば良い領域
2. mysql -> mariadb
  • DB初期化時に使用している管理コマンドmysqladmin等を切り替え
  • Rubyの依存パッケージの検証が必要。仮にMySQLのままだとしても、ある程度のバージョン差異が生じるため、検証が必要。
3. systemd対応

現在upstartを採用している理由はいくつあって、その1つは、以前、ubuntuがメインディストリビューションだった事。upstart system confであれば、ubuntuでもrhel互換でも、どちらでも使える。そう言った理由で採用した経緯がある。しかし、最近ではubuntu環境へのインストール要件は皆無に近い。

  • rhel7には、upstartのrpmパッケージが存在してないので、SysV initかsystemdへ変更する必要がある。
  • rhel7の標準initはsystemd
  • これらを踏まえると、systemd対応は必至
あとがき

12/08担当 @debilityさんのエントリ:

2年ほど前にWakame-vdcと大いにまみれさせていただいた

2年前はRHEL6.0対応し始めてから間もない頃で、RPM化するよりも半年以上も前の事。ご迷惑をおかけしつつも、苦しみを分かち合いながら一緒にお仕事した日々は、今では良き思い出。あれから2年、あっと言う間。

福岡出張へのお誘い、まだ来てません。そろそろですね?




編集
@hansode at 10:00|PermalinkComments(0)TrackBack(0)

2013年12月08日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/08担当 (3回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の悲鳴をお届けします。

全体が見えない

ここ1年は特に、自分がRubyコードをコミットするタイミングは、バグ修正がメイン。バグであるかどうかを確認する過程でモデルの関連を把握したくなる時がある。実装コードを読めば分かる訳だが、全体を俯瞰したい事が多い。実装者は狭い所を見ていれば良いみたいで、実装時のER図の需要は極めて低い。無くても実装されている事が、それを裏付けていると言えるのだろうか。

とある一部機能の実装を把握したくて実装コードを読み進めて行くと、途中で理解した内容を忘れてしまうほど、複雑怪奇(恐らく設計検討不足)になっていて・・・、俯瞰図が無いままでは効率が悪い。そこで、俯瞰図を書き始めた。

lib/dcmgr/models俯瞰図

俯瞰図作成後、調査効率は期待通りに向上した。

困った人が書く!

『ドキュメントがあれば・・・何故、書かないのか?』と思ってる時期はあったが、最近は、困った人が書けば良いと言う考え方へ切り替えた。と言うのは、誰向けに書かれてるのか分からないドキュメントを書く為の時間を割くよりは、実装に注力してもらった方が良い。そう思える事が多いからだ。

困った時が、ドキュメントの書き時

少なくともドキュメント対象は一人存在し、その人が欲するドキュメントが出来上がる。

コードを書かずに実装把握し、プロジェクトに貢献する事は十分可能。副産物として、実装を読み解くスキルは向上し、実装の理解度は高まる。この辺のドキュメント作成に興味のある方がいらっしゃいましたら、ご一報下さい。




編集
@hansode at 15:00|PermalinkComments(0)TrackBack(0)

2013年12月06日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/06担当 (2回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の悲鳴をお届けします。

2012/06末 こんにちは、『結合苦』さん

前エントリの継続RPMビルドする仕組み作りの裏では『結合苦』との戦いを繰り広げていた。

ファイル配置程度のインストール作業は、パッケージングによって軽減されていたが、コミッターは結合作業の事は気にせず、思い思いのタイミングで新機能をコミットして来る状況だった。当時の結合作業の大半は自分ひとりで行っていたので(そして今も)、システム結合に悩まされるのは自分ひとり。極度の結合苦に悩まされていた日々。

  • 「何故こうなったのか・・・」
  • 「何故こうなるのか・・・」
  • 「いっそのこと、開発を一時中断できないものか・・・」

苦い経験を踏まえ、後に実感した事は、

  • 「新たなRPMがビルドされてから結合するまでの時間が長ければ長い程、結合苦に陥る」

今となっては当たり前な着地点だが、当時は、それを身体で感じられなかった頃。結合苦を乗り越えたくて、早め早めに結合する作業へ挑み始めたのが、2012/06末。

2012/07 「インスタンス起動/破棄」連続成功への道

Wakame-VDCにおける結合成否の指標の1つ、それは、WebUIからインスタンス起動してインスタンスにログイン出来る事。もしもログイン出来なければ、容赦なく結合失敗と判断されてしまう。たかがログインの舞台裏には、幾つも前提条件が存在している。

  • インスタンスが起動している事
  • インスタンス管理エージェントが起動している事
  • APIサーバが起動してる事
  • WebUIが起動してる事
  • DBサーバが起動してる事
  • ○○・・・が起動している事

更に各コンポーネントが協調して動作する必要がある。

  • 起動順序通りに起動してる事
  • 各configが正しく設定されている事
  • 初期データが投入されている事
  • etc.

これ等は氷山の一角で、前提条件は他にも多々ある。何か1つでも条件が不足していると、ログイン可能状態にならないのは言うまでもない。動かない原因を1つ1つ分析し、動かすための組み合せを探って行く。とある組み合わせで動いていても、新たにビルドされて来た新機能入りRPMパッケージで入れ替えてみると、あっさり動かなくない。ふり出しへと戻される・・・。

2012/08 結合失敗回数と結合成功回数が、逆転する

原因を調査・分析、新たな動く組み合せを作っては、新たな変更によって壊れて行く。この泥臭い修復作業を、ただただ、繰り返す。何度か調査回数を重ねて行くと、似た調査パターン・コマンドセットに分類されて行く。例えばインスタンス作成失敗時エラーログに対するgrepコマンドの組み合わせ。そんな時はコマンドヒストリを駆使し、以前使ったコマンドを分析。少しずつ改良を重ね、手順を少しずつ確立させ、継続的に改善して行く。

  1. 調査手順を確立
  2. 調査手順を分析
  3. 手順を簡略化・単純化
  4. 内容によってはスクリプト化

結果、出来上がるのは、アプリケーション監視相当の仕組み。外堀が埋まって行った。

また、その当時、調査作業と並行してデプロイ作業改善も同時に進めていた。2012/07末にはパッケージ自動ビルドする仕組みを作り上げていたので、残り作業は、

  1. パッケージリポジトリを常時監視
  2. リポジトリが更新されていれば、新パッケージを関連ノードにインストール
  3. インストール後、プロセス再起動

この一連の流れを行うデプロイパイプラインの成長につれシステム全体が安定したのは、2012/08末の頃。 ただ、これは、特定環境におけるパイプラインであり、ポータブルなパイプラインを手に入れるまでには、まだ時間が必要だった。その辺の話は、別エントリに持ち越し。




編集
@hansode at 10:00|PermalinkComments(0)TrackBack(0)

2013年12月04日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/04担当

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場から見た風景をお届けします。

お粗末な対応からパッケージング生活へ

「Wakame-VDC RPM化」の話が舞い込んで来たのは2012年03月。RPM化以前のパッケージデプロイ手順は、下記の通りで、大分お粗末なものだった。

  1. ビルドサーバでbundle update等を半手動実行
  2. ビルドサーバからアプリケーションサーバへrsyncによる半手動デプロイ
  3. 依存関係に従い、プロセス再起動

少なくとも半年以上は同様のお粗末な対応でその場をやり過ごし続けていた。やがて、RHEL系の構築需要が高まり、政治的圧力も手伝い、RPM化が本格始動したのが2012年03月。ここからパッケージング生活へとシフトして行く。

RPM化へ向けて生きた参考材料収集

参考にしたのは、openstack-rhel。

当時は既にGitHubのおかげでrpmspecファイルを探す事も簡単になっていた頃。それまでは、SRPMをダウンロードしてインストールする等の作業を必要としたが、GitHub登場により状況は一変した。プログラミングのソースコードだけでなく、パッケージングの領域までオープンになりつつあった。

2012/04/17 rpmspec初コミット

最初の wakame-vdc.repoをコミットしたのは、2012/04/17。この日付には意味があり、Wakame-VDCがリリースされたのは、更に2年前の2010/04/17。2歳のお祝いと、成長の証として、この日にコミット。

2012/07/20 継続的RPMビルド開始 (cron方式)

初コミットからしばらくの間は手動実行で間に合う回数だったが、コミット頻度に比例してビルド需要が高まる。とある時期から手動運用では間に合わなくなり始め、リポジトリの先頭コミットハッシュを監視し続ける簡単な仕組みを導入し、自動ビルドさせる仕組みを導入したのが2012/07/20。小さな変化だったが、手持ち作業に注力出来るようになり、自動化による恩恵を、ジワジワと身体で感じ始めた頃。

2012/08/24 RPMビルド結果メール通知

継続的RPMビルドが安定稼働し始めると、『ビルド結果がどうだったのか』それを知りたい!と言う需要が高まり、ビルド成否をメール通知を開始。この頃から『少なくとも帰る前にコミットするルール』が開発メンバー内で自然に定着し始める。RPM化着手してから半年弱の出来事。

自動化体質へシフトし始めた半年間

パッケージングをきっかけに得た事は、数知れず。

  • 継続的ビルドがどう言うものか
  • 何を気を付けるべきか、何を気を付けるべきだったか
  • 開発プロセスの改善とは

自動化による恩恵を身体で感し始めた半年間。その後の品質向上について検討可能な時期へとシフトして行く話は、別エントリに持ち越し。




編集
@hansode at 10:00|PermalinkComments(0)TrackBack(0)

2011年10月28日

このエントリーをはてなブックマークに追加

不慣れなRHELと、インターネット非接続と

インターネット非接続RHELサーバに、Rubyで作られたアプリケーション(Wakame-VDC)をインストールする必要があった。

手元にはRHEL環境が無かったので、RHEL互換であるはずのCentOS上にRuby開発環境を構築。 CentOSでは苦労する事なくruby環境を構築出来たので、RHELでも同様に問題ないだろう・・・そう思っていた。 作業対象のRHELで問題に遭遇。

ruby-develが見つからない

RHELのインストールDVDの中身を確認してみても、ruby-develが存在しない。何故・・・? その理由は、ruby-develがextrasに所属している事だった。 RHELのインストールDVDに収録されているのは、baseパッケージ。見つからなくて当然の結果だった。

一般手順と例外手順

理由が判明し、extrasパッケージをインストール対象に追加する方法を調査してみると、少なくとも2つの方法が存在していた。

上記2つの手順は、インターネット接続された環境用。今回の作業環境は、インターネット非接続環境。一般的な手順で済む話ではない。下記にインターネット非接続向け手順をまとめた。

検証環境
  • RHEL Server 6.0 x86_64
特筆事項
  • 作業対象サーバは、インターネット非接続
作業概要
  1. Red Hat Network(RHN)より関連rpmをダウンロード
  2. 対象サーバへアップロード
  3. パッケージをインストール
前提条件
  • Red Hat Networkアカウントを持ってる事。
    これは、RHELを使う時点でアカウント取得済みであるはず。
作業内容
  1. ruby, ruby-libsをインストール。これらはインストールDVDに含まれているので、yumコマンドで解決。
    $ sudo yum install ruby ruby-libs
  2. extras所属のパッケージをRHNからダウンロード。rpmは、ページ下部の"Download Package"から辿れる。 ※i686用のrpmも存在するので、i686用ページからダウンロード可能。
  3. どうにかして、rpmを対象サーバへ配布(例えば、USBメモリを利用)
  4. rpmをインストール
    $ sudo rpm -ivh /path/to/ruby*.rpm
あとがき

RHELとCentOSの違いを意識する事。

続きを読む


編集
@hansode at 16:30|PermalinkComments(0)TrackBack(0)

2011年03月31日

このエントリーをはてなブックマークに追加

開発し辛さを少しでも解消したくて

OpenStackコンピュートのnovaには、nova.shと言うスクリプトがある。これは、novaを手軽に起動停止する目的のスクリプト。novaの起動停止だけでなく、データを初期化もしてくれる。各コンポーネントがscreenのwindowで起動し、ログが出力されている。是非、これをWakame-vdcに入れたくなった。

そして作ったのが、vdc.sh

▼検証環境

  • Ubuntu 10.04.2 Server LTS
  • Wakame-vdc 10.11

▼使い方

wakame-vdcをcloneし、プロジェクトの最上位ディレクトリで実行する事が前提。

$ git clone git@github.com:axsh/wakame-vdc.git
$ git clone git://gist.github.com/895965.git gist-895965
$ mv -i gist-895965/vdc.sh wakame-vdc/.
$ cd wakame-vdc
$ chmod +x ./vdc.sh
$ ./vdc.sh

vdc.shを実行すると、screenが起動し、コンポーネントの数だけwindowが作成され、それぞれのwindowではコンポーネントが実行される仕掛け。

開発時はinitctlでコンポーネントを起動停止するのが面倒で仕方が無い。コンポーネントを起動しては、tailでログを常時表示、そして停止。これを何度も繰り返す。一方、foregroundで実行すればログが表示され、停止するだけで済む。どちらにしても、コンポーネント毎にscreen windowを作成している訳だ。だったらscreenを起動し、コンポーネント分のscreen windowを作成して、コンポーネントを実行してしまえば良い。明らかに作業効率は向上する。vdc.shは、この単純作業を一撃で済ませてくれる。また、事前にデータを初期化するので、開発時は特に重宝する。

あと書き

良いものがあれば、どんどん取り込んで行かない理由がない。




編集
@hansode at 21:15|PermalinkComments(0)TrackBack(0)

2011年02月18日

このエントリーをはてなブックマークに追加

「開発の苦労話してよ」と頼まれて

2011/02/07(月)に開催された『第47回 GRACE セミナー』に参加して来た。

果たして参加者は何を聞きたいのかを自問自答しつつ、スライドを作って参加。当日、会場に到着してみると…年齢層が高く、スーツ姿が約9割。普段参加している勉強会とは違い、アウェイ感タップリ。スーツさん達を相手に、私服姿で高橋メソッド気味のスライドでWakame-vdcの開発話をして来た。




編集
@hansode at 18:20|PermalinkComments(0)TrackBack(0)

2010年08月04日

このエントリーをはてなブックマークに追加

簡単に言えば、先日作ったwakame-fuel-builderのwakame-vdc版だ

作ったキッカケはwakame-fuelと同等

  • やるべき作業が何か、明確になった
  • そして、毎回同じ作業が面倒臭い
  • 作業者による作業ムラを無くす

wakame-fuelはgemパッケージ化されている事が手伝い、環境構築は楽な部類だ。
それと対照的なのがwakame-vdcの環境構築だ。

ひたすら手順通りにコマンドを実行し続ける、マンパワー重視による物だった。
何度か作業をしている自分自身が一番面倒である事を知っている。

とにかく、駄目な状況を、どうにかしたかった。

使用例

▼検証環境

  • Windows 7 Professional, 32-bit
  • VMware Workstation 7.1.0 build-261024
  • CentOS-5.5 i386

ひとまず、wakame-fuel環境のみ構築

▼Git未使用

$ cd /tmp

$ wget http://github.com/hansode/wakame-vdc-builder/raw/master/centos/5/01_setup-base.sh
$ wget http://github.com/hansode/wakame-vdc-builder/raw/master/centos/5/02_setup-ruby.sh

$ sudo sh ./01_setup-base.sh
$ sudo sh ./02_setup-ruby.sh

▼Git使用

$ cd /tmp

$ git clone git://github.com/hansode/wakame-vdc-builder.git
$ cd wakame-vdc-builder/centos/5/

$ sudo sh ./01_setup-base.sh
$ sudo sh ./02_setup-ruby.sh

10分ほどでwakame-vdc環境構築が完了する。


ベースだけは出来上がる

ベースだけではwakame-vdcを使う意味が無い。

例えば、VMイメージの配置などが必要だ。
今回は、ここに触れずに終わる。




編集
@hansode at 19:05|PermalinkComments(0)TrackBack(0)