ロックとチュウーハイとこりんがるな日々

日々のインプットした事をアウトプットする場所

serverspec を使って初めてのインフラテスト

serverspec テスト

仕事でserverspecを使ってテストを行ったのでその時のメモを公開します

provisoning toolにはchef(chef-solo)を使っています、今まではvagrant + chefでテスト環境を構築するだけでしたが production環境にもcookbookを定期用する事になりました、今まではテスト環境の構築だったので例えばiptablesはoffとか の設定をしていましたがそういうわけにも行かず一度全てのcookbookの見直しを行い、足りない部分は追加しました

production環境にcookbookを適用するにあたってやはりcookbookが正しいかどうかを1台づつ確認するのはさすがに手がかかり すぎるしコストもかかります、何より正しいかどうかもうたがしいです

って事でテストを書く事にしました、今となっては当たりの事ですが今までアプリのテストは書いてましたがサーバのテストを 書くのは初めてです

サーバのテストを行うにあたって色々ツールがあるようですが、一番簡単で汎用的なserverspecを使う事にしました

以下ログです

$ install

rubyはinstallされている前提です

# gem install serverspec

$ init

  1. テストを作成するdirectoryに移動

     # cd [test directory]

  2. init

     # serverspec-init

 Select OS type:

 1) UN*X
 2) Windows

 Select number: 1

 Select a backend type:

   1) SSH
   2) Exec (local)

 Select number: 1

 Vagrant instance y/n: n
 Input target host name: 192.168.33.10
  + spec/
  + spec/192.168.33.10/
  + spec/192.168.33.10/httpd_spec.rb
  + spec/spec_helper.rb
  + Rakefile

    色々聞かれるけどとりあえず 1) 1) n を選択

  3. 実際のテストに使ったResource Types

    netを検索すると色々情報が出てきますがとりあえず公式サイトが一番わかりやすかったです

    http://serverspec.org/

    Resource Types に使えるresourceとサンプルコードが載っています

    実際に使ったresourceを以下に紹介します

    • package resource

      package

        describe package('httpd') do
    it { should be_installed }
  end

      • be_installed

        package('httpd') に記述されているpackageがinstallされているかをテスト

    • file resource

      file

        describe file('/etc/httpd/conf/httpd.conf') do
    it { should be_file }
    it { should contain "DocumentRoot \"/home/ecocatcms/current\"" }
  end

      • be_file

        file('/etc/httpd/conf/httpd.conf') に記述されているファイルが存在するかをテスト

      • contain

        file('/etc/httpd/conf/httpd.conf') に記述されているファイルに contain "〜"の記述が書かれているかをテスト

    • service resource

      service

        describe service('httpd') do
    it { should be_enabled   }
    it { should be_running   }
  end

      • be_enabled

        service('httpd')に記述されているpackageの起動設定がされているかをテスト

      • be_running

        service('httpd')に記述されているpackageが起動しているかをテスト

    • port resource

      port

        describe port(80) do
    it { should be_listening }
  end

      • be_listening

        port(80) に記述されているportが開いているかをテスト

    • command resource

      command

        describe command('convert --version') do
    it { should return_stdout /ImageMagick/}
  end

      • return_stdout

        command('convert --version')に記述されたcommandを実行した結果から return_stdout /ImageMagick/ に書かれた記述が存在するをテスト 記述の仕方は正規表現も使える

    • iptables resource

      iptables

        describe iptables do
    it { should have_rule('-P INPUT ACCEPT') }
    it { should have_rule('-P FORWARD ACCEPT') }
    it { should have_rule('-P OUTPUT ACCEPT') }
    it { should have_rule('-A INPUT -p icmp -j ACCEPT') }
    it { should have_rule('-A INPUT -i lo -j ACCEPT') }
    it { should have_rule('-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT') }
    it { should have_rule('-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT') }
    it { should have_rule('-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT') }
    it { should have_rule('-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT') }
    it { should have_rule('-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT') }
    it { should have_rule('-A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT') }
    it { should have_rule('-A INPUT -j REJECT --reject-with icmp-host-prohibited') }
    it { should have_rule('-A FORWARD -j REJECT --reject-with icmp-host-prohibited') }
  end

      • have_rule

        have_rule('-P INPUT ACCEPT')に記述された設定がされているかをテスト

    • php_config resource

      php_config

        describe 'PHP config parameters' do
    context php_config('date.timezone') do
      its(:value) {should eq 'Asia/Tokyo'}
    end
    context php_config('post_max_size') do
      its(:value) {should eq '5000M'}
    end
    context php_config('upload_max_filesize') do
      its(:value) {should eq '5000M'}
    end
    context php_config('extension_dir') do
      its(:value) {should eq '/usr/lib64/php/modules'}
    end
    context php_config('enable_dl') do
      its(:value) {should eq 1}
    end
  end

      • php_config

          context php_config('date.timezone') do
    its(:value) {should eq 'Asia/Tokyo'}
  end

        php.iniの設定項目をphp_config('date.timezone')に書く、設定項目の値を its(:value) {should eq 'Asia/Tokyo'} に書く、設定が正しいかをテスト

    • selinux resource

      selinux

        describe selinux do
    it {should be_disabled}  
  end

      • be_disabled

        selinuxがdisabledになっているかをテストする、ほかにもbe_enforcing, be_permissiveがある

    • user resource

      user

        describe user('deploy') do
    it {should exist}
    it {should belong_to_group 'deploy'}
    it {should have_home_directory '/home/deploy'}
    it {should have_login_shell '/bin/bash'}
  end

      • exist

        user('deploy') が存在するかをテスト

      • belong_to_group

        user('deploy') がbelong_to_group 'deploy'に属しているかをテスト

      • have_home_directory

        user('deploy') のhome directoryが should have_home_directory '/home/deploy' かどうかをテスト

      • have_login_shell

        user('deploy') のshellが should have_login_shell '/bin/bash' かどうかをテスト

$ run test

以下のコマンドでテストを実行します

# rake spec
.........................................................

Finished in 2.2 seconds
57 examples, 0 failures

テストが成功したら「.」が表示されます、テストが失敗したら「F」で表示されて、エラーの内容が表示されます エラー内容と一緒に裏で吐かれているコマンドも一緒に表示されます

$ tips

serverspecはテストの実行時にserverspecを実行するPCにログインしているユーザでテストを実行するサーバにログイン しようとします

クライアントPCがmacでテストを行うサーバがlinuxなどの場合はデフォルトのままでテストを実行するとテストサーバに対して macにログインしているユーザ名でログインしようとしてしまします

僕の場合は「spec/spec_helper.rb」を以下のように編集しました

- c.ssh   = Net::SSH.start(host, user, options)
+ options[:password] = "password"
+ c.ssh   = Net::SSH.start(host, "user", options)

options[:password] = "password"

鍵認証の場合は問題ないかと思いますが、僕の場合は普通にpassword認証を行うので直接passwordを書き込みました

c.ssh   = Net::SSH.start(host, "user", options)

「"user"」にテストを行う対象のサーバにログインするユーザ名を直接設定しています

今回はじめてインフラのテストをしましたが、serverspecはとても使いやすかったです、chefに依存してないところが気に入りました 開発環境のvagrantにも、本番のsakura VPSにも同じようにテストを流す事ができました

次回はdockerなんかを使ってCIをまわす環境を構築してみようかと思います

でわでわ、失礼します

OSをMarvericksにしてphp-buildでphpをinstallしたら「configure: error: Cannot find libz」って言われた時の対処方法

php 開発環境 libz php-build

ターミナルから以下のコマンドを実行する

$ xcode-select --install

実行後installコマンドを発行

$ php-build 5.4.19 ~/.phpenv/versions/5.4.19

問題なくinstallできました

参考サイト

Qiita : OS X 10.9 Marvericksでzlibがない

php freamwork なにを使おうか迷ったのでとりあえず調べてみた

angularjs php freamwork 比較

今作ってるアプリはフロントをangularjsで作っていて、サーバサイドはjsonを返すだけの仕様にしています とりあえず先にフロントを作りこんだ状態でサーバはdummyのphpがあるだけです

サーバサイドのfreamworkなにつかおうと思って調べてみたので以下に書きます

比較対象のfreamwork

ちなみに僕はphoerなのでphp freamworkを比較しました

過去12ヶ月で比較

日本の場合

cakephpが突き出た感じ、laravelがもうちょい上がってるかとおもいきやそんなにでした

全ての国の場合

世界的にはCodeIgniterが完全に突き出てるが、laravelが急激に追い上げている感じでしね

どうするか？

日本ではcakephpの情報量の多さとコミュニティがしっかりしている点はかなりの魅力かと思います、 新しいfreamworkを追いかけてみるという点ではlaravelを追いかけるのも面白いと思います

cakephpは何度か触った事があるがlaravelはほぼ触ってないのでlaravelを触ってから検討しようかと思います

追記

今後の勉強も兼ねてrubyで作るのもありかと思います、ruby の場合は必然的にrailsになるのかな？ json返すだけならSinatraでもいいのかな？ まったくの知識ゼロなので調べてみるとしよう

またレポートします

「エンジニアのためのリーンスタートアップ」勉強会に参加してきました

devlove リーン・スタートアップ 勉強会

DevLove関西の勉強会にいってきました、内容は「エンジニアのためのリーンスタートアップ」 僕自身起業しようとかそういった気持ちはないんですが、仕事で商品開発をしているのでその為 に役立つ事があるかと思って以前から書籍などには目を通していましたがあまり実感はなく実際の 話が聞ける良い機会だと思って参加してきました

僕が読んでいる本はこちら

紹介されていた本とは違ったので、上記の本が読み終わったら勉強会で紹介されていた以下の本も購入してみようかと思います

では勉強会で印象に残った事をメモ書きしましたので以下に書いていきます

リーンスタートアップ基本理解（和波俊久さん）

  • アイデアに価値は一切ない、マーケットが欲しいと思うようにアイデアを仕上げる

    一番衝撃的な言葉でした

  • 何を使って目的を達成するかが大事なポイント

  • 同じパターンの成功例はないが、同じパターンの失敗例はある！！

  • マーケティング・リサーチをちゃんと行わない事がたたある、マーケティングの罠

    • 自分に都合の良いデータだけを集めてしまう、会社に対して承認の判子を押させる為に！！

    • 成功する前提でプロジェクトをスタートする為、ローンチしてもなにも起こらない、結果失敗する

    マーケティング・リサーチではネガティブな情報を徹底的に検討する事が大事なポイント

    この話はまさに現在働いている会社で起こっている事、会社の規模は２０人程度ですが、自分のアイデアを正当化する為に 都合の良いデータを集めたり、成功する前提でのプロジェクトだったり、とあ〜あるあるって思いながらメモりました

  • 実験を繰り返す

    • フィードバックループ

        1. アイデア
  2. 構築
  3. 実験
  4. 測定
  5. データ
  6. 顧客からの学習

    • 1 〜 6 短いスパンで繰り返す事でアイデアを追い込みではないものにする！！、ウォーターフォール型のもの作りでは学習は１回だけ、まさにギャンブル！！

    • アイデアを「6. 顧客からの学習」 から都度修正していく

    • 顧客から学ぶ

    • リーン・スタートアップのPDCAを回す事で事業価値の向上

    • PDCAはマーケットのニーズに対して行う事が重要

  • 事業アイデアがフリマ化している

  • 多産多死の時代

    “起業ありきで多産多死”の現状を打破する異色メンター・小澤隆生のインキュベート法

  • アイデアの価値は¥0

  • 自分の思い込みをすてて、simpleにする事が大事

    • 自分の思っている事は伝わらないと思ってほうがよい

    • マーケットがわかる言葉に置き換える

    ここはかなり納得しました、僕自身伝えるのが下手くそなので、これから意識していこうと思いました

  • 完成品は目指さない

    仕事でのもの作りにおいてはかなり意識しているつもりだが、プログラマーのわるいくせが顔をだすので今後はもっと意識してぐっとこらえて 顧客からのフィードバックをもっと大事にしていこうと心に誓いました

    また資料などに時間をかけすぎるなどの話はまさに現在進行形でしたので、考え直します

  • リーン・スタートアップを実践するうえで、現場が考える事が大事

    • 提供される道具を教えられた通りに使うのではなく現場が判断し現場が使いやすいように考え、形を変えることが大事なポイント

    • 上司などから強制的におこなった事は失敗する

リーンスタートアップ実践事例(齋藤瑛史)

  • マーケット・イン、プロダクト・アウトは既にスピードが遅い

    妙に納得、調査だけに半年も時間をかけるって、マーケティングが得意な45歳ぐらいのおっさんに違和感を感じていたのはこの 事がと思いました

  • 主にユーザインタビューからフィードバックを得ている

  • 分析は資産である

    • ナレッジの蓄積

    • 分析は基本的に１週間単位で行っているが、分析の項目として長期的な目で見ている内容もある

  • ユーザの獲得にはBlogが効果的だった

    • １日に2,3本postしている

個人的に気になって聞けなかった事あベンチマークはどのようにしたのかとかを聞きたかったです

ワークショップ（和波俊久さん）

ワークショップは基本的には手を動かすというかとなりの人と喋って自分が将来なにをするかを考えそれを発表する という形でした

自分が将来なにをするかを常に考える・言語化・書く・しゃべるこれは起業するとかではなく大事な事かなと心に刻みました

発表自体は１分間で話すでしたが、僕自身の発表は最後のほうだったので考えてまとめる時間があったのでうまく話せた方かな〜 と個人的には思っています

将来なにをしたいかを考える事は自分を商品として見た時にも結構大事なポイントやなと思い、自分自身を商品としてみた時に 自分の価値を伝える上で非常に大事なポイントになると思い今後ずっと考えてblogなどにアウトプットしていこうと思いました

また今後しゃべる機会があればどんどん喋っていこうと思います

一つこころ残りはなのは懇親会に参加出来なかった事です・・・

devLove関西に参加したのは２回目ですが、今後も参加していこうと思います

ありがとう御座いました

AirMac の設定を見なおしたら早くなりました

airMac 無線LAN wi-fi

先日airmacを買って設定したところあんまり早くならなかった事をブログにpostしたところ @void_No3さんにtwitterでアドバイスを頂いたので設定を変更して見ました

なにも設定していない状態

設定変更後

めちゃくちゃはやくなった感はないですが、リビングでこの速度がでれば満足です、これからも設定都度設定を見直そうかと思います

@void_No3さん ありがとう御座いました

でわでわ

AirMac Express を買いました

airMac 無線LAN wi-fi

家のルーターがそろそろ限界だったので（クソ遅い）買い替えを検討していました

色々検討したのですが家の環境はmacが2台、iphoneが3台、nexus5が1台、PS3が1台と比率でいうとmac製品が

ほとんどなのと、wi-fiに接続する機器で11acに対応しているのが1台も無いことから今回はこれにしました

スピードテスト

変更前

変更後

AirMacは玄関に設置していて、計測した場所はリビングです扉が一枚あり、6 〜 7mぐらい離れています

結果思ったほどはやくなりませんでしたが、設定の簡単さなどには満足しています

リビング用の中継器としてもう一台買おうか検討してみようと思います

でわでわ

DevLove 関西 ～Decision～に行ってきました

DevLove関西

初めてDevLoveのイベントに参加しました、今までに参加してきた技術系のイベントなどとは一味違っていて 開発系のイベントではあるが技術の話がでないのがなにか新鮮な感じがしました

僕が参加したセッションは以下になります

組織の中でアジャイルな開発をするということ 椎葉 光行(@bufferings)

プログラマから経営者へ変わる決断と、プログラマを一生の仕事にする決断 倉貫 義人(@kuranuki) 伊藤 淳一(@jnchito)

キャラ立ちしたエンジニアになる！ 新原 雅司(@shin1x1)

大企業、未踏ソフトウェア、起業 - 様々な働き方から学んだ「モノ作り」のエッセンス 染田 貴志(@tksmd)

未来のために我々の帆をたてよう 市谷 聡啓(@papanda)

今回イベントに参加したきっかけは一度倉貫さんの話を聞いてみたいと思っていた事がきっかけでした 結果どのお話も印象的で得るものがたくさんあったかと思います

得に印象に残ったセッションを下に紹介させて頂きます

組織の中でアジャイルな開発をするということ 椎葉 光行(@bufferings)

椎葉さんの話は組織の中で実際にアジャイル開発を行ってその中で感じた事や実際に行った施策などの話をされて とても実践的な内容でした

得に印象に残ったのが本に書いてある事をそのまま実践されていない事でした、自分たちのスタイルに合わして 柔軟に対応してされていました、得に交渉可能スケジュールのつくり方は真似してみようと思いました

エンジニアでなくてもわかりやすいスケジュールはとても印象に残りました

あとやはりビジネスゴールの共有は改めて大事だと感じました

あと振り返り出来てないなーって自分に言い聞かせました

キャラ立ちしたエンジニアになる！ 新原 雅司(@shin1x1)

僕自身がphperという事もあり、phpカンファレンスなどで発表している新原さんは何度か見た事はあります が今回はほぼ技術的な話題はなかったのでとても新鮮でした

なになにの人のように自分になにかのキャラをつける事で「知ってもらう」、「覚えてもらう」、「思い出してもらう」 たしかにこれ大事やとめちゃくちゃ思いました

自分にキャラをつける事で自分の商品価値を上げる事にも通じるなと真剣に考えさせられました

全てのセッションを通じて感じた事は自分に出来る事を理解し、商品としての自分の価値を正しく理解する事 が大事なのかなと感じました

あとやっぱ発表している人たちはすごく楽しんでいたのが印象的でした、自分もそうなりたいと強く思いました

これからも自分の興味のある分野にはどんどん参加していこうかと思います