タグ: アジャイル

Fulcrumのcookbookを作成

FulcrumPivotal Trackerのクローンを目標にしているプロジェクトです。

Pivotal Trackerに似ているツールFulcrum: プログラマの思索

malclocke/fulcrumのインストール方法を参考にcookbookを作りました。
さらにそれを使って、Vagrantとchef-soloでCentOS6.4(x86_64)上で動かしてみました。

1. 条件

  • Fulcrumの依存パッケージ(Qt 4.8)をインストールするためにゲストOSはCentOS 6.4の64bitのみ
  • FulcrumはRuby on Rails製で、今回使用するRubyはbox内にすでにある/opt/chef/embedded/binにあるruby(1.9.3p286)です。
  • 検証用として作成したので、実行時の環境(RAILS_ENV)はdevelopmentでDBはSQLiteを使い、実体はdb/development.sqlite3となります。

2. 必要なもの

  • VirtualBoxとVagrantとchef-solo,knife-solo一式
    入門Chef Solo – Infrastructure as Codeなどを参考に
  • Berkshell
    RubyGemsのbundlerのようなもの
    cookbookを作成するに当り、yum cookbookが必要だったので、依存管理のため

3. ファイルの構成

chef-repo/ - cookbook置き場(A)
    Berksfile
    cookbooks/
    data_bags/
    nodes/
    roles/
    site-cookbooks/
fulcrum/ - ゲストOS(B)
    Vagrantfile

chef-repo(A)はknife soloを使用して

knife solo init chef-repo

としたときのもの

fulcrum(B)は
ディレクトリを作成(mkdir fulcrum)して、

vagrant init

とした状態

4. cookbookの作成

  1. (A)に移動
    cd chef-repo
    
  2. Berksfileを編集して
    cookbook 'yum'
    

    を追記。新規作成する場合は

    site :opscode
    cookbook 'yum'
    
  3. Berkshellを使って依存cookbookをダウンロード
    berks install --path cookbooks
    
  4. Fulcrum用cookbookを新規作成
    knife cookbook create chef-fulcrum -o site-cookbooks
    
  5. metadata.rbを編集して依存cookbookを列挙する
    cd site-cookbooks/chef-fulcrum
    
    depends 'yum'
    
  6. recipes/default.rbを編集
    長いのでこちら

5. Vagrantを使ってゲストOSを起動する

  1. (B)に移動
    cd ../../../fulcrum
    
  2. Vagrantfileを編集
    # Centos 6.4 64bit版のbox
    config.vm.box = "CentOS-6.4-x86_64-ja"
    config.vm.box_url = "https://dl.dropboxusercontent.com/u/428597/vagrant_boxes/CentOS-6.4-x86_64-ja.box"
    
    # ホストOSからアクセスするためにIPをセット(IPは各々の環境に応じて変更する)
    config.vm.network :private_network, ip: "192.168.33.105"
    
    # chef soloのprovitionを有効にして、cookbookのパスを設定、run_listにfulcrum cookbookを設定
    config.vm.provision :chef_solo do |chef|
    chef.cookbooks_path = ["../chef-repo/cookbooks", "../chef-repo/site-cookbooks"]
    chef.roles_path = "../chef-repo/roles"
    chef.data_bags_path = "../chef-repo/data_bags"
    
    chef.run_list = [
        "recipe[chef-fulcrum]"
    ]
    end
    
  3. ゲストOS起動
    vagrant up
    
  4. upし終わったら、http://192.168.33.105:3000でアクセス
    ユーザID:test@example.com、パスワード:testpassでログイン
ユーザID:test@example.com、パスワード:testpassでログイン

ユーザID:test@example.com、パスワード:testpassでログイン

Fulcrumログイン後の画面

Fulcrumログイン後の画面

サンプルプロジェクトの中身

サンプルプロジェクトの中身

6. 作成したcookbookをgithubにUPしました。

mistymagich/chef-fulcrum

6.1 使用方法

  1. 3.の状態で(A)に移動し、Berksfileを編集
    site :opscode
    
    cookbook 'chef-fulcrum', git: 'https://github.com/mistymagich/chef-fulcrum.git'
    
  2. Berkshellを使ってcookbookをダウンロード
    berks install --path cookbooks
    
  3. あとは4. は不要で、5. の手順でvagrant up

boxのダウンロード後、ゲストOS起動からURLでアクセスできるようになるまで、Vagrant起動時の表示では794sec(約13分)、実際には19分程度かかりました。(ホストOS WindowsXP / CPU Core2 Quad Q9550 / Memory 3.5GB)

広告

bpstudy #47

URL: BPStudy#47 : ATND

場所:R3C貸会議室 NOF新宿南口ビル4F セミナルームA

日時:2011/07/29 19:00 to 21:00

Togetter – 「BPStudy#47のまとめ」

XenServerによるお手軽サーバ運用(@tokibito)

業務の課題

  • 本番に近い環境
  • お客さんに見てもらう
  • 外部システムの連携
  • etc…

開発用のサーバがほしい

  • 前提条件
    • コスト(時間、お金)をかけすぎない
    • 今やらなくていいことはやらない
    • 必要以上に複雑にしない
      • メンテナンスコスト
      • 移行コスト

選択肢

  • レンタルサーバ
    • 共用
    • 専用
    • VPS
  • 自社
    • データセンター内に設置
    • 社内に設置

今後プロジェクトが増えたら?

  • 物理的に増やす
  • VirtualHost
  • chroot
  • 仮想化

検討

  1. プロジェクトごとに環境を作りたい
    →レンタルの共用は難しい
  2. 1プロジェクトの期間の平均は1〜3ヶ月
    →DCやレンタルの専用サーバは費用が高い

結果

社内にサーバを設置、仮想化で
→XenServer

なぜXenServerを選択?

  • VPSを借りるより自前サーバの仮想化は性能面、機能面で有利
    →いざとなればいろいろできる
  • KVMやXenは知識ないと大変そう
  • 8コアマシンを使いたかった
    →当時(2009.4)VMwareESXiは4コア上限
  • 無償だから

ハードウェア

  • 20〜30万の据え置き型
    (当時はオフィスが大きくなかったのでラックは置き場所や電源に困る)
  • CPU: Xeon
  • メモリ: 4GB

XenServerインストール

無償版ライセンスは1年毎に更新

XenCenter

GUIでXenServerを管理できるWindowsソフト

windows以外用にopenxenmanagerがある

Xenここが便利

  • 管理ソフトがGUI
  • VM(仮想マシン)のスナップショット
  • VMのテンプレート

運用後の課題

  • 設定が面倒
    • ネットワーク設定
      →スクリプトを作った
  • ユーザ管理
    →鍵認証にした

運用管理

  • VMの管理
    スプレッドシートで管理表(IPや用途)
  • VMの作成
    ルーチンワーク化

その他

  • XML-RPC形式のAPIがある
  • 物理3台で40VM程度運用

プロジェクトが失敗する要因+α(bash0C7)

プロジェクトとは?

プランニングオニオンの変形で
戦略→ポートフォリオ→プロダクト→リリース

プロジェクトの成功とは

予定通りの期間、予定通りの予算で最初に定義したすべてのフィーチャーを実現していること
『Extreme Chaos 2001. Standish Group International, Inc.』

失敗の要因

いっぱい

プロジェクトが失敗する1つの原因

見積もりミス
『ソフトウェア開発 55の真実と10のウソ』

見積の意義

  • 実施価値判断
  • 優先順位付け
  • 体制を検討

キーワード

  • 不確実性コーン
  • 規模と期間
  • 正確さと労力

不確実性コーン

プロジェクト初期ほど具体的なことが決まっていないので見積りの精度は不正確
プロジェクト終端は1つの点に見積りが収束

横をプロジェクト時間、縦を見積り(実績)にしてグラフ化すると、横に倒したコーン(円錐)になる
アジャイル開発にすることで、コーンを小さくなりブレが少ない見積りができる

規模と期間

例:東京大阪を移動するとき何時間かかりますか

かかる時間(期間)は
2時間40分(のぞみ)
1時間ちょっと(飛行機)
仮にのぞみがこだまとしたら
5時間

→条件によって期間はばらばら

でも距離500km(規模)はかわらない

→まず規模を決めよう
まず要求される機能の中から規模がわかるものを比較対象(基準)とする、その基準と他の機能を見比べて各機能の規模を決めていく。(これは基準の2倍だとか)

その後、基準を実装するのにかかる期間を見積もってあとは比率で各期間を計算する。(基準が1週間でできるからこれは2倍なので2週間だとか)

正確さと労力

見積もりをしっかりやっても確実性はあがらない

参考書:『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』
『アジャイルサムライ――達人開発者への道』