発見し隊

毎日周りをみつめて色々なことを発見したい。 それをここにメモする。いつしかそれが自分の通ってきた道に…なると信じて…

bitcoinのpdfファイルをasciidocからビルドしようと思ったら、とても面倒だったのでメモ。

bitcoinのasciidoc

  • - https://github.com/aantonop/bitcoinbook
    • oreilly書籍の編集前documentとのこと
    • github上であれば、そのまま読めるからわざわざpdfビルドする必要ないかもしれない

簡単にビルドできず、情報も少なかったので、少し調べてみた。

docbookまでは簡単

docbookファイルの出力はあっさりです。

でもxmllintエラーはバグらしいので、--no-xmllintオプションをつけます。

それでもlatex関連でエラーがでます。

$ brew install asciidoc

export XML_CATALOG_FILES="/usr/local/etc/xml/catalog"

$ a2x -f pdf -r ./images/ --no-xmllint book.asciidoc

a2x: ERROR: "dblatex" -t pdf -p "/usr/local/Cellar/asciidoc/8.6.9/etc/asciidoc/dblatex/asciidoc-dblatex.xsl" -s "/usr/local/Cellar/asciidoc/8.6.9/etc/asciidoc/dblatex/asciidoc-dblatex.sty" "/Users/user/develop/bitcoinbook/book.xml" returned non-zero exit status 127

$ ls book*

book.asciidoc book.xml

docbook.xmlの中身をみると、もう本のデータはばっちりに見えます。

あとはxslですね。直接指定してみます。

# 色々指定する

a2x -f pdf --xsl-file=book.xsl --dblatex-opts="--param=latex.encoding=utf8" --verbose --no-xmllint -r ./images/ book.asciidoc

久しぶりのギア使用レポートです。

昨年登場したファイントラックのダウンジャケットです。

ポリゴンギア

今年購入したのは2ULジャケットです。

特徴とその効果

  • 濡れに強い

濡れても保温性が落ちにくい。走って少し蒸れる感覚があっても、すぐに解消される。乾きが早いです。

  • 保温効率が高い

素材の偏りが少なく、単位面積あたりの材料に対する保温効果が高い。

  • 軽い

とにかく軽い。2ULシリーズは着用した感覚がないくらい軽いです。

ポリゴン2ULとポリゴン4のモデル

2ULと4シリーズのどちらにするか悩みました。

最終的には、着用感がないくらいの軽さとインナー着用を想定できる2ULシリーズを選びました。主な理由としては、厳冬期のアルパインクライミングをする機会も以前と違ってそれほどなく、むしろトレイルランと軽装アルパインでの使用の方が多いからです。

実使用例

2014-10現在では、この程度の利用例しかないですが、快適に利用できています。

  • 秋の寒い日の通勤
  • 夜間の5km程度のランニング

実利用例が増えたら随時アップデートしていきます。

昨年も参加しました。高尾森林マラソン公式ページ

この大会の特徴は、距離が比較的短いながらも、給水ポイントが3カ所もあり、高尾駅から送迎バスがでていてアクセスがよいことです。参加価格が比較的安いことも人気がある理由だと思います。

高尾森林マラソン2014

記録:1h28m40s/15km

林道にあがるまでの道のりが少しかわった気がする。気のせいかな?

トレーニング不足でしょうが、昨年よりキツかった。当然タイムを遅かった。

フラットな道でスピードを上げられなかったのが一番の原因です。

スピードを上げられる走力が足りなかったので、トレーニングを重ねないといけません。

陣場山トレイルが2週間後に控えているので、トレーニングを加速させたい。

ルートの詳細については、「ルートラボ」でも確認ができます。

http://latlonglab.yahoo.co.jp/route/watch?id=92423ba0f1b60b351196984dc9d0b22b

googlecodeのsvnリポジトリからgitへcloneする時に以下のようなエラーがでたのでメモ。

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree svn rebase

Can't locate SVN/Core.pm in @INC .......

MacOS:MarvericksとMountainLionでライブラリリンクエラーがあるらしいので修正すればよいとのこと。

参考:http://blog.victorquinn.com/fix-git-svn-in-mountain-lion

sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/SVN /System/Library/Perl/Extras/5.16/SVN

sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/auto/SVN/ /System/Library/Perl/Extras/5.16/auto/SVN

研究ベースのライブラリー等はC/C++で実装されることが多い。それらをwebに持ち込むという一つの手段としてemscriptenというC/C++->javascript変換(コンパイラー)を利用しているケースは多いようだ。

ということでemscriptenのインストールと使い方を調べて試してみた。

emscripten

https://github.com/kripken/emscripten

http://kripken.github.io/emscripten-site/

Emscripten is an LLVM-based project that compiles C/C++ into highly-optimizable JavaScript in asm.js format. This lets you run C/C++ on the web at near-native speed, without plugins.

全てのC/C++コードを変換できるわけではないらしいです。

構造がよくわかっていないのですが、LLVM-baseということで、ちょうどApplicationVMの勉強をしたいと思っていたところなんで、少し詳しくなれればいいなという感じ。

インストール

MacOSX-Marveriks想定でインストール。

(ubuntuの場合はこちらを参考)

- emscriptenはgit cloneするだけ

- LLVMとClangが必要

MACの場合はXCodeでClangがインストールされているので、LLVMをインストールするだけでよし。

# Macの場合

brew install llvm --with-clang

with-clangしなくても、/usr/local/bin/clangを/usr/local/Cellar/llvm/3.x/bin/clangにコピーすればよし。

=>emscriptenがllvmバージョン3.3想定ということのようだが、llvm3.4でも動作した。

- nodejs利用

backendのjavascript変換はnodejsやspidersmonkeyなどを利用できるということで、インストールが楽なnodejsを選択。

# Macの場合nodejsがらくちん

brew install node

- path設定

一度cloneしたemscriptenのディレクトリ内にあるemccを実行すると.emscripten設定ファイルが生成される。.emscriptenにパスなどの設定あり。

Macの場合。直接llvmのパスを入力しておく

$ vi ~/.emscripten

...

LLVM_ROOT = os.path.expanduser(os.getenv('LLVM') or '/usr/local/Cellar/llvm/3.3/bin') # directory

...

# cloneしたemscriptenのパス

$ vi ~/.bashrc

...

PATH=$HOME/emscripten:$PATH

基本的な使い方

C/C++のソースコードを用意。

emscripten/tests以下にサンプルコードがあるので環境構築テストに利用する。

いくつか設定オプションをいじる必要があるのが注意です。

#エラー回避のためにfast-compilerオプションを設定

EMCC_FAST_COMPILER=0 emcc ./hello_world.c -o hellotest.js

node hellotest.js

  • o オプションで出力するファイル名を指定すると、そのファイル名によってjs/htmlなど、出力するように作られているようです。

openstack、あきらめないでトライしていれば少しずつ進んでます。

これまで、しっかり構築する上でchefなどと同じように「冪統性」を調べながら構築してきましたが、compute-nodeを増やす作業で再びエラー発生。

最初の構築時にも発生したエラーですが、packstackを利用していくにはそれなりに深刻なエラーです。

原因はmysql.ppでのパッケージコンフリクトとrootログインにあります。

修正されたとかされないとか情報が混乱してます。

少なくともpackstack-icehouse-4パッケージでは修正されてない模様です。

そんなわけで、puppetファイルをのぞくことにしました。

https://github.com/puppetlabs/puppetlabs-openstack

packstackが実施していることと何が違うのかがまずわかりません。

packstackはRHEL/CentOS用のrpmを落としてきて、設定するというppファイルを利用しているようにも思えます。

openstack、、はまってます・・・悪い方向にw

そして、はまっている人の情報もよく見かけます。ただし、解決しているかどうかが全然わかりません。なにせ構成がよくわからないので。

クラウドサービスやVMware(VSphere)あたりでは標準機能として当たり前にできていたことができないというのが一番痛いところ。オプション的機能ならまあよしとするところですが、インスタンス起動・テンプレート作成とか、一番効率的に楽したい基本的な部分ができない。。基本部分が使えればユーザーが増えて、情報も増えると思うのですよねー、なんでこんなことになっているのか。。

もう数回キレて、導入あきらめようと思いました。(だって、openstackの研究するわけじゃないし)

でも自由度の高いプライベートクラウドとSWIFTはあきらめきれませんでした。あと、次のプロジェクトとして物理サーバとの連携とかありますし。

openstack構築想定(TODO)

こんなイメージ。

http://dream.daynight.jp/openstack/install-guide/yum/content/section_networking-routers-with-private-networks.html

一番欲しいのは、検証環境用のローカルネットワークをプロジェクト毎にすぐ作れて、かつ、他のセグメントとポリシーをかました上で通信できること。仮想ネットワーク万歳!ってしたいです。

イメージの作成

クラウドサービス、VSphereができる基本的な部分は当然できると思っていましたが、ここからコケルとは思ってませんでした。

  • ISOイメージからVM作成できない
  • 別でVMイメージ構築するにも一定の決まりで作らないといけない
  • Thin-provisioningでVMボリュームのスケールアウトができない

もう、死ねって思いました。まあ、インスタンス作るだけであれば、cloud-image使えということですよね。ということで、cloud-imageでインスタンス生成を試してます。

  • ubuntu

http://cloud-images.ubuntu.com/releases/13.10/release/

qemu/kvm用ってことでこれを選択。ubuntu-13.10-server-cloudimg-amd64-disk1.img

  • centos

いくつかリンクを発見するのですが、rdoのofficialのリンクがきれているという怒り心頭な状態。

とりあえず、githubでみつけたので利用してみてます。

https://github.com/vermut/veewee-centos6-cloudinit

初期設定問題

なんとかcloud-imageは起動したのですが、ログインできません。「openstack,cloud-image,password」とかで検索してみたらやたら候補でてきました。

結論からいうと、cloud-imageはセキュリティ的な問題もあるので、パスワードログインが全てOFF状態のようです。。「ん?コンソールも駄目って、それでいいのでしたっけ?」となりますが、どうしようもありません。そのかわり、cloud-initというアプリケーションを起動時にキックできるようになっているので、そこで様々なカスタマイズスクリプトを実行できるようになってます。

cloud-init

http://cloudinit.readthedocs.org/en/latest/topics/examples.html

初期構築時に色々できます。chef/puppet実行とか

ただし、残念なことにopenstack上でのカスタマイズスクリプトによるvncパスワードログインがなぜか効きません。

#cloud-config

password: vmpass

chpasswd: { expire: False }

ssh_pwauth: True

色々試しましたが、centos6.5/ubuntu13.10の両方でNGでした。みなさま色々苦労しているようです。

http://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/

password-injection

そこで、openstack-horizon/novaによるrootパスワード変更機能を使います。

http://docs.openstack.org/admin-guide-cloud/content/admin-password-injection.html

#/etc/openstack-dashboard/localsetting.py

OPENSTACK_HYPERVISOR_FEATURE = {

...

'can_set_password': False, # =>True

}

#/etc/nova/nova.conf

[libvirt]

inject_password=true

keymap変更

cloud-imageはen-usのkeymapです。Compute-NodeであるNovaの設定で、vnc_keymap=ja、とはしましたが、imageの設定が変わるわけではないので、keymap変更します。普通のkeymap変更です。これは自動化したいですよね。

#CentOS -> /etc/sysconfig/keyboard

# command: loadkeys jp106

KEYTABLE="jp106"

MODEL="jp106"

LAYOUT="jp"

KEYBOARDTYPE="pc"

#Ubuntu/Debian -> /etc/default/keyboard

# command: loadkeys jp

XKBMODEL="jp106"

XKBLAYOUT="jp"

異動により職場が変わりました。

同じく東京なので引っ越しとかありませんが、開発環境を一から構築しないといけない状況になりました。以前はVMwareVsphereの流れがありましたが、それがないのでせっかくならということでOpenStackでプライベートクラウドを作ることにしました。

年々余ったサーバを増強して、数年後には巨大なクラウドになったら面白いです。

OpenStack

それほど知らなかったので一から調査です。CloudStackと迷いましたが、チューニングとかあるいは別途APIを作ったりすることもありそうなので、自由度の高いOpenStackにしてみました。内容についてはこのあたりがわかりやすかったです。

openstack全般: http://www.slideshare.net/obara13/open-stack-16166193

openstack-nw: https://www.scsk.jp/product/oss/pdf/OpenStack_5_1.pdf

構成イメージはこんな構成ですが、まずは3台構成のサーバから構築します。

Controller/Network: stack1-sv

Compute1: stack2-sv

Compute2: stack3-sv

インストール

Puppetエラーにはまる

めちゃくちゃはまりました。色々見ましたが、PuppetによるインストールErrorではまりました。原因はまだよくわかりませんが、色々なサイトを参考にしてなんとか完了。ちなみに、allinoneオプションはなにやっているかわからないので、Errorの時に困ります。。結局、logみたりすることになるので本末転倒でしょうか。

自動設定&インストールスクリプト

ということで、何度も同じようなインストールをするので、色々参考にしつつsetup用のshell-scriptを作りました。他サイトで一から全部手動インストールしているケースを見かけますが、今後computing-nodeを増やすたびに同じような作業をするなんて現実的でないので、ヤル気がおきませんでした。dockerfileつくってインストールという手も考えましたが今回はやめです。

インストール作業は二度できない罠

なお、一度インストールに失敗すると、mysqlのインストールあたりで確実にpuppetエラーが発生しました。mysqlの権限とかパスワード関連らしいですが、結局、このスクリプトでuninstallしてから再度以下のスクリプトをまわすとよいという記事を見つけて、何度もいろんなパターンでテストインストールしました。

自動設定&インストールshell-script

以下サイトを参考に仕上げたshell-scriptです。

http://tech-sketch.jp/2014/07/openstack-icehouseall-in-one.html

http://www.slideshare.net/h-saito/openstack-quickstart-icehouse

setup

network

いろんなやり方がありますが、基本インストールはopen-vswitchベースのようです。

bridgeの設定をしてあげます。

ネットワークについては、virtualbox上でのインストール例が一番わかいやすいと思います。

http://blog.hirokikana.com/?p=461

# vi /etc/sysconfig/network-scripts/ifcfg-br-ex

DEVICE=br-ex

DEVICETYPE=ovs

TYPE=OVSBridge

BOOTPROTO=static

IPADDR=XX.XX.XX.XX

NETMASK=XX.XX.XX.XX

GATEWAY=XX.XX.XX.XX <-- 内部NWのGateway

DNS1=XX.XX.XX.XX <-- 内部NWのDNSか8.8.8.8など

ONBOOT=yes

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0

DEVICETYPE=ovs

TYPE=OVSPort

OVS_BRIDGE=br-ex

ONBOOT=yes

# reboot

keymap

インスタンス生成時のkeymapをjpにする

#guest os instanceのvncによるコンソールkeymap

$ vi /etc/nova/nova.conf

vnc_keymap=ja

インストール完了

画面

課題

無事にインストールができましたが、puppetで落ちるケースがあって何度もuninstall->installを繰り返しました。packstackを使うにあたって、fleshインストールしかできないと言う意味では、「puppetの意味あるんでしょうか?」って聞きたくなります。

コマンドラインで一つずつインストールしている人が多い理由もなんとなくわかるような気がします。

ただし、compute-nodeやstorage-nodeを追加していくというような運用していくのであれば、packstackでなくても、puppet/chefで冪統性を確保することは大切です。でも、今のままでは駄目ですね。

CentOSパーティション

ホストマシンのCentOSはminimal-isoを利用したのですが、驚いたことに/homeに対してlvm-volumeの90%のディスクを割り当てていました。なぜでしょう。。minimal-installは素人利用を想定していないと思うので、全て「/」に割り当ててもよいと思うのですが。。

ということで、久々にLVMによるパーティション拡縮作業です。

以下がピンポイントのblog情報です。

http://blog.fenrir-inc.com/jp/2013/04/centos-6-lvm.html

sparkがいつの間にかApacheプロジェクトに組み込まれ、さらにドキュメントを読むとpysparkというAPIもあることが判明したので、トライしてみる。

まず、今後、VMはdockerでやっていくと決めたので、dockerコンテナ上でsparkを動かすことからはじめてみる。

apache sparkについて

clouderaの翻訳ページがわかりやすい

http://www.cloudera.co.jp/blog/putting-spark-to-use-fast-in-memory-computing-for-your-big-data-applications.html

centos6.5 with dockerの用意

ここはvirtualboxも想定してvagrantで実施。CentOS6.5以上でないとdockerが入らないので注意。

sparkをCentOS6.5ヘインストール

sparkのインストール自体は、sparkの公式ページ等で公開されている。

spark公式ドキュメント

How_to_install_spark_on_CentOS

でも、毎回インストールするのはこの仮想化・クラウド時代において正直だるいというか、out-of-date。

そこで、UC-Berkleyが作ったshellスクリプトが公開されていたので利用する。このスクリプトを使えばクラスターもすぐできる。

https://amplab.cs.berkeley.edu/2013/10/23/got-a-minute-spin-up-a-spark-cluster-on-your-laptop-with-docker/

ソースコード

実質的に以下のコードでsparkの起動までができた。

公開など

docker0というdocker閉域ネットワークだけにexposeされるので、外から見えるようにするにはportforwardingが必要。

pysparkを試す

ようやくpythonAPIをたたく段階。と思ったら、./bin/pysparkコマンドがない。。

deploy.shコマンドたたくと、spark-shell(scala)が起動するけど、pysparkコマンドは起動しないのだ。

調べていると以下のサイトを発見。

http://www.rankfocus.com/run-berkeley-sparks-pyspark-using-docker-couple-minutes/

sshでコンテナへの接続を試したところ、今度はsshdが起動しているはずのdockerコンテナからssh session closed by remoteされる。

いろいろと調べたところ、namespaceの問題とかsshd/pamの問題とか色々あるみたい。このあたりが情報。

https://meta.discourse.org/t/unable-to-ssh-into-docker-container/14272

https://bugzilla.redhat.com/show_bug.cgi?id=1085081

http://stackoverflow.com/questions/18173889/cannot-access-centos-sshd-on-docker

http://blog.glatts.com/blog/imai/?p=949

=>もう少し調べないと根本の原因がわからないです。

ということで、ssh接続をあきらめて、pysparkコマンドを起動するためのコンテナに直接入ります。

#dockerコンテナにbashで入る

macosx: $ sudo docker run -i -t amplab/spark-master:1.0.0 /bin/bash

###以下spark-masterノードのコンテナ内

root@2dbb4f19bcd5:/# /opt/spark-1.0.0/bin/pyspark

Run Berkeley Spark’s PySpark using Docker in a couple minutesにあるように、python2.7がないとなぜかおこられるのでインストールする。

# spark-masterコンテナにpython2.7をインストール

root@2dbb4f19bcd5:/# sudo apt-get update

root@2dbb4f19bcd5:/# sudo apt-get install python2.7

これでようやくpysparkが使える。

# pyspark-shellの起動画面

14/07/29 04:16:58 INFO HttpServer: Starting HTTP Server

14/07/29 04:16:59 INFO SparkUI: Started SparkUI at http://2dbb4f19bcd5:4040

Welcome to

____ __

/ __/__ ___ _____/ /__

_\ \/ _ \/ _ `/ __/ '_/

/__ / .__/\_,_/_/ /_/\_\ version 1.0.0

/_/

Using Python version 2.7.3 (default, Feb 27 2014 19:58:35)

SparkContext available as sc.

>>>

システム化する際にはREPLなんてことはないので、batch投げをする。

# *.pyファイルをsubmitする

./bin/spark-submit test_aggregation.py

あとはどうやって外からこのコマンドをキックするかでしょう。

dockerですので、docker runでしょうか?

# dockerコマンドでコマンド発行

sudo docker run -i -t amplab/spark:1.0.0 /opt/spark-1.0.0/bin/spark-submit test_aggregation.py

でもやはり、解析システムとloggerシステムとか別でしょうから、ansibleあたりでssh経由でコマンド発行するのが普通ですよね。。

さて、ssh経由でコマンド流し込むツールをあさる旅にでます。

GoogleのlevelDBをforkして作られた"HyperLevelDB"というDBがHyperDexという企業からでているということを知りました。HyperLevelDBを試す前にlevelDBのpythonバインディングを試すことにする。

正直、levelDBがオープンソース化されてから、情報を集めていなかったので気づいたらラッパーがいくつかできていたので、ようやくlevelDBを使ってみるというのが真相です。

個人的には非同期処理できるFileDBとして、sqliteの置き換えとして期待している。

さらに言えば、windowsで動いてくれるとデータ含めてアプリケーションを1パッケージにできて都合がよい。特に非同期処理できるってところはとても大きなところ。

Install

virtualenvでpython3.4モードにし、leveldbパッケージをインストールします。

#python3

$ virtualenv -p /usr/local/bin/python3 .venv

$ source .venv/bin/activate

(.venv) $ pip install leveldb

サンプルコード

- 適当なデータをstore->fetch
- jsonデータstore->fetch

ひとまず、公式ページ等にあるサンプルコードを動かそうと思ったらいきなり動かず。PYPIをみると、python3に対応しているけれど、結局はredisと同じくデータは全てbyteコードでstoreするようです。

つまり、str(unicode) => byte、への変換が必要ってことですね。

5/1-5/4の行程で杓子岳山行。

結果を言えば、雪が少なくて撤退。露出した薮を抜けるのに時間がかかり、スケジュール的に厳しかったというのも一つの理由。

杓子岳:双子尾根ルート

今回のルートは積雪時限定ルート。

雪稜があるから良いルートのはず。

[ルート]

猿倉荘 - 小日向のコル - 双子尾根 - 樺平 - [この途中で撤退] - ジャンクションピーク - 杓子岳

詳細なルートはヤマレコのページを参照。

今回初めてヤマレコを利用して計画書やルート情報を得た。後日、ヤマレコの山行記録に差し替える予定。

小日向のコル

テント場として最適なこの広いコル(ほぼ台地)へは、車で侵入できる終点である猿倉荘から雪上徒歩3時間。広い雪平原を歩くため、帰りの日に吹雪かれてもよいように目印の赤旗をたてながら歩いた。

それにしても、天気があまりにも良すぎて手袋、フェイスフード(バラクラバ)などしたくもなかった。

ところが、これが想像以上の雪焼けとなって、2週間経っても全然消えない。

鑓温泉入り口目印雪平原-猿倉to小日向コル
小日向コル直下小日向コルまでの急登

コルの状態はとてもよかった。ここだけを見ると雪が少ないとはあまり感じない。天気がよいだけにすばらしい景色を堪能。

小日向コルからの鑓・杓子・白馬岳

雪の少ない双子尾根

雪が少なく、本来ならば雪稜を歩いていくところが、岩肌や薮を抜けるしかなく、予想以上の時間がかかった。1時間半で抜けるところを2時間半もかかってしまった。

残り少ない雪部分も危なっかしくてGW初日で使えなくなりそうな箇所が多く、今年のGWでこのルートをいってみようとする方々は困った人が多くいたのではないかと思う。

残雪少双子尾根

樺平--ジャンクションピーク

それにしても、樺平から見たジャンクションピークの景色は立体感がすごくて感動でした。

写真をよく見ると、中央付近に3人組が登攀していて山と人のサイズの違いがわかります。

ジャンクションピークfrom樺平

撤退はしたものの、おそらくここが核心部分だと感じた。

まず、急登であること。そして、雪状態によって選択肢を変えないといけないこと。特に今年は雪が少ない上に溶け・崩れ掛かってクレバス的に穴が開いていたりしたので細心の注意が必要な箇所でした。

さらにその雪もシャリシャリで、日差しが数時間当たった帰路で使えるかどうか不安な感じでした。これが一番の撤退理由。

樺平-JP雪解け

まあ、へたれと言えばへたれですが、この判断基準こそが山で一番重要なことで、ミスると命が危ないので私のチームは考えうるリスクが大きければすぐ撤退します。所詮、趣味ですから。特に私は残雪期の雪稜に足を置いて、すばらしい景色が見れたことで満足です。

ちなみに、樺平もテント場ですが、時折、かなりの突風が吹いていたのでテントを張るどころではない感じだった。でもこの後、小日向のコルに戻る最中に多くのパーティが樺平のテント場を目指していました。この突風をモノともしない、テント場の中心になる一本木が絵になります。

有名な樺平の一本木

帰路

予想以上に雪が解け、崩れて使えなくなり、往路よりも薮を抜ける箇所がいくつか増えた。小日向のコルに到着したのは11:00過ぎだったが、樺平へ向かうパーティは少なくとも5、6いたと思う。

小日向のコルにも予想以上にテントが増えていた。

小日向コルパノラマ

一息休憩を入れてから、テントをたたみ、雪ブロックで作ったテント・炊事・食事スペースを崩して撤収。行きよりは軽いけれど、再び20kg程度の荷物を担いで下山。

往路よりも雪がシャリシャリだったけれども、山スキーの人たちが雪面を平らにしてくれたおかげで、山靴でもある程度スケートのようにうまく滑らせながら楽に下山できた。1時間で下山できたのがその証拠。

小日向のコルからの下山の直後に天気が崩れ始めたが、それもほんの少しの雨だったので全く苦労はなかった。当然、赤旗の恩恵を受けずに済んだ。

無事に猿倉荘へ到着してタクシーで白馬八方の宿へ向かうことができた。

雪の状態が悪く、杓子岳山頂へはいけなかったが、天気と景色に恵まれて、そしてなにより安全に怪我なく下山できた今回の山行であった。

python3.4がリリースされたので、本格的にレガシーpython2.7からの移行をしている最中。

お気に入りのtornadoのcore実装がpython3.3から入ったconcurent.futureベースとなっていて、その書き直しに時間がかかっている。

そんな中、macのリニューアルでgolangの設定をし始めたら、並列処理系はもはやpythonで書く意味もなくなってきたよね、、って改めて思ったので、1年ぶりにrevel webFrameworkを触った次第。

Revel

久々に触ってまず思ったこと。

どのFramworkも似ていて当然だけど、それでもScala-Play!Frameworkに構成がめちゃくちゃにている・・・

=> まさしくPlayを参考に作られたみたいです。

Revelのコンセプト

各ディレクトリとファイルの構成

  • conf/route : URIと処理関数を結びつけるdispatcher
  • conf/app.conf : 設定ファイル
  • app/controllers/*.go : 処理関数
  • app/views/*.html : htmlテンプレート

その他特徴

  • interceptor
  • 何かアクションを関数実行で起こした前後の処理をinterceptorという仕組みで簡単にできる。

    http://revel.github.io/manual/interceptors.html

    => 感覚的にいうと、decorator的に関数へのoption処理を実施できるって感じだ。

    # before/afterが指定できるようだ。

    revel.InterceptFunc(checkUser, revel.BEFORE, &Customer{})

  • job
  • 標準でjob処理機構が使える。http://revel.github.io/manual/jobs.html

    # job登録の例

    jobs.Schedule("0 0 0 * * ?", batchjob{})

    jobs.Schedule("@every 1h5m10s", batchjob{})

    jobs.Every(24 * time.Hour, batchjob{})

    cronと同じ仕組みでjobがまわせるよって書いてあるけど、組み込まれているjob-moduleの説明を読むと、秒単位でjob指定できる設計なのでうれしい。

    => 1秒毎にstatus-checkして、そのstatusを配信したりできる。

    また、登録されているjobステータスは標準でhttp://HOST/@jobsで見えるとのこと、すばらしい。

やる気が湧いたのでさっそくなんか作ってみる。

ProxyApi

RestAPIをRestAPIでたたくってものを作ってみました。

要はAPIのProxyです。

スケジューラーなどもうまく使ってRESTAPIをガシガシたたくためのRESTAPIにしてみます。

ソースコードはこちら=> https://github.com/wolf20xx/go_api_proxy

  • 裏で指定されたURLのRESTAPIがworkerとしてぐるぐる動くような感じ。
    • goroutine使って非同期にquery指定されたURLをたたく
    • channelでたたいたRESTAPIのresponseを返していく
  • RESTAPIのresponseが変化したときだけ、responseを返してあげるようなAPIであるとよい

websocketAPIにすれば楽チンか?

機をみて機能追加してみよう。

macをリニューアルしたので、GO関連の設定をしていたがさっぱり忘れたので再び最初から調べた。

install

これはあまり必要ないけど念のため。

brew install go

ちなみに、私はbrewfileで標準インストール。

環境設定

わかっていれば悩まない。

$ vim ~/.bashrc

export GOROOT=`go env GOROOT`

export GOPATH=$HOME/.go

export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

editor

結局、sublime or vimが現状では最適解。

sublimeText + gosublime

sublimeTextのパッケージinstallでgosublimeをインストール。

preference->package-settings->userより以下を設定。

{

"env": {

"env": "/usr/local/bin;$PATH",

"GOROOT": "/usr/local/bin"

},

"gslint_cmd": ["go", "tool", "gotype", "-p", "$pkg", "$files"],

"autocomplete_tests": true,

"autocomplete_builtins": true,

"fmt_tab_width": 4

}

仮想環境

gvm(rvm的) / goenv(virtualenv的) / goenv(rbenv的)

仮想環境ツールも少し増えた気がするけれど、とりあえず以前と同じでgoenv。

$ vim ~/.bashrc

export GOENVTARGET=$HOME/.goenvtarget

export PATH=$GOENVTARGET:$PATH

$ curl -L https://bitbucket.org/ymotongpoo/goenv/raw/master/shellscripts/fast-install.sh | bash

とりあえず、今日はここまでで終了。

vim設定はあとで追記。

boxen、本当にお騒がせです。

あまりにめんどい対策が必要なんで、もうこれっきりかなぁと。

とはいえ、なんだかよくわからないエラーが出たのでこれだけは解決させた。

/opt/boxen/env.sh実行時エラー

ログイン時の環境変数設定をしているだけなのだが、そこでこけてる。

BOXEN_SETUP_VERSIONでのgitコマンドが原因。

git rev-parse --short HEAD

見慣れないコマンドだけど、HEADのrevisonのhashのshortバージョンとってきているだけ、なのだがなぜこけるか謎だった。

なんせ、boxenって自動構築だから便利なわけで、中身調べはじめたらもはや意味なし、って感じだ。

検索するに、git リポジトリ設定で失敗しているらしい。

この/opt/boxen/repoを生成するのは、our-boxen/config/boxen.rbで、その中でリポジトリ追加urlに問題あり。

実際に、これはおかしい。

git remote -v

origin https://github.com/undef

ということで、ひとまず解決するにはこれをboxen_webにするのがよいとのこと。つまり、

git remote rm origin

git remote add

origin https://github.com/boxen/our-boxen

git fetch -q origin

git reset --hard origin/master

根本的解決は?

そもそも、このbug情報は、一年も前のissue。fixしているように見えるが、プライベートリポジトリ使った場合は結局起きてしまうって、書いてあった。本当か、どうかもう一度試そうかと思ったけど、すでに気力なし。

もえboxenはないな。

brew+caskをしっかりやろう。

[参考URL]

https://github.com/boxen/boxen/issues/62

haskellに限らないけれどデータや処理を試したり解析したりするのに、Replを使うのはとても有効だ。

python/scalaではよくお世話になる。

HaskellのRepl:ghciでもお世話になりたいけれど、関数や型定義のために複数行入力する方法がわからなかったので調べたメモ。

ghciで複数行入力する方法

  • :{と:}で囲む

# Haskell勉強の定番教科書の例(「すごいHaskell楽しく学ぼう」)

Prelude> :{

Prelude| instance Eq Light where;

Prelude| Red == Red = True;

Prelude| Yellow == Yellow = True;

Prelude| Green == Green = True;

Prelude| :}

I/Oモナドでも役立つ

複数行入力は競技プログラミングでも役立つようだ

http://qiita.com/siquare/items/ec0c01c81c22ce060405

2月に適当なmac(Mavericks)のセットアップをboxenで試したら、うまくインストールできたけど、3月下旬に他の端末で実行したらうまくいかず。

調べたらいくつかの課題がからみあっているようだ。

  • XCodeのdevelopment commandline toolsのインストール&agreementが必要

[対処法] http://qiita.com/yuku_t/items/30015dba2b6497b80074

  • Mavericksのruby2.0.0-p247にバグがある

[対処法] http://stackoverflow.com/questions/22352838/ruby-gem-install-json-fails-on-mavericks-and-xcode-5-1-unknown-argument-mul


以下がその課題の現象。

gemでjsonモジュールのインストールができない

Fetching: json-1.8.1.gem (100%)

Building native extensions. This could take a while...

ERROR: Error installing json:

ERROR: Failed to build gem native extension.

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby extconf.rb

mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/include/ruby.h

Gem files will remain installed in /Library/Ruby/Gems/2.0.0/gems/json-1.8.1 for inspection.

Results logged to /Library/Ruby/Gems/2.0.0/gems/json-1.8.1/ext/json/ext/generator/gem_make.out

rubyバージョンによるバグ

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby extconf.rb

creating Makefile

make "DESTDIR=" clean

make "DESTDIR="

compiling generator.c

linking shared-object json/ext/generator.bundle

clang: error: unknown argument: '-multiply_definedsuppress' [-Wunused-command-line-argument-hard-error-in-future]

clang: note: this will be a hard error (cannot be downgraded to a warning) in the future

make: *** [generator.bundle] Error 1

make failed, exit code 2

Gem files will remain installed in /opt/boxen/repo/.bundle/ruby/2.0.0/gems/json-1.8.0 for inspection.

Results logged to /opt/boxen/repo/.bundle/ruby/2.0.0/extensions/universal-darwin-13/2.0.0/json-1.8.0/gem_make.out


ruby2.0.0-p451をrbenvなど入れて切り替えれば解決するという話だけど解決しない。

ここにたどり着くまで数時間かかった。

gemインストール時のパラメターの問題が原因

参考URLにあったgemインストール時のパラメター設定をconfigにあてるパッチが有効だった。

curl https://gist.githubusercontent.com/Paulche/9713531/raw/1e57fbb440d36ca5607d1739cc6151f373b234b6/gistfile1.txt | sudo patch /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin13/rbconfig.rb

marvericksデフォルトのruby2.0.0p247でもconfigのパッチあてるだけで動作した。

boxenが最適解かどうか・・・それは疑問

冷静になると自分以外の人が毎回この作業をboxenでインストールするのに必要だと考えるとboxenのメリットが全然ないのであきらめた。

そもそもboxen使うのは、「チーム」などで「同じ環境」を「コマンド一発」で「共有(共通化)」することだ。だから、環境によってchefのような再現性が高いレベルで維持できない:簡単に設定してインストールできなければ、メリットが全然なくなる。

現状では、同じ用途であれば、brew+brew-cask+brewdlerの組み合わせが、手軽+エラー解決しやすい+管理可能ってことで利用価値が高いという結論。

Haskellの中間演算子の動作についての疑問。

使う時ハマってまた混乱してしまうのでメモしておく。

高階関数での中間演算子の動作

# 高階関数

prelude> foldl (-) 1 [1,2,3,4,5]

-15 # 内部動作 (((((1 - 0) - 2 ) - 3 ) - 4 ) - 5)

prelude>foldr (-) 0 [1,2,3,4,5]

3 # 内部動作 (1 - ( 2 - ( 3 - (4 - ( 5 - 0)))))

(-)は左結合

Prelude> :info (-)

class Num a where

...

(-) :: a -> a -> a

...

-- Defined in `GHC.Num'

infixl 6 -

左結合:infixlとなってる

foldrとfoldlはどうなっているのか?

#foldl/rの情報

Prelude> :info foldl

foldl :: (a -> b -> a) -> a -> [b] -> a -- Defined in `GHC.List'

Prelude> :info foldr

foldr :: (a -> b -> b) -> b -> [a] -> b -- Defined in `GHC.Base'

んー、左結合性がどう効いているのか?

#今度は右結合の例

Prelude> :info (:)

data [] a = ... | a : [a] -- Defined in `GHC.Types'

infixr 5 :

Prelude> foldr (:) ["0"] ["1","2","3","4","5"]

["1","2","3","4","5","0"]

Prelude> foldl (:) ["0"] ["1","2","3","4","5"]

エラーとなる

ん?(:)は型クラス?なんだかおかしい。

少なくとも、foldrやfoldlで適用されるには型クラスではなく関数でないといかんのではないか?

typeもみてみる。単に型クラス制約受けた引数をもつ型クラス関数。

# それぞれのtype

Prelude> :t (:)

(:) :: a -> [a] -> [a]

Prelude> :t (-)

(-) :: Num a => a -> a -> a

typeを見れば当たり前だけど、2引数の型が異なる&右結合というのが効いているってこと。

そもそも(:)はfoldrでは使えないってことだ。

右結合、左結合は意識して使わないと当然いけないってこと。

カリー化による部分適用も注意が必要。

Haskellの勉強熱が再加熱されてきたので、勉強素材を新たに探したのでリストアップ。

随時更新していく。

Haskell勉強リスト

Learn You Haskell for Great Good : http://learnyouahaskell.com/

日本語版もある。OriginalはWeb閲覧がFree。

Real World Haskell: http://book.realworldhaskell.org/

オライリー本がWebだとFreeで閲覧可能。

School of Haskell: https://www.fpcomplete.com/school?show=tutorials

本のようにTuorialがしっかりしている。下記のHaskellオンラインIDEと連携している。すごい。

Yesod Framework: http://www.yesodweb.com/

HaskellのWeb Frameworkの公式ページ。OnlineTutorialがある。オライリ本のFree版?

Haskell-Toolsリスト

HaskellLint: http://community.haskell.org/~ndm/hlint/

TryHaskell: http://tryhaskell.org/

HaskellのOnline実行Web。さらっとオンライン処理するツールとかにいいかも。

FP Complete IDE

HaskellのOnlineIDE。School of Haskellと連動している。自分のプロジェクトをFreeCommunityEditionでよりよく使う事もできる。

前記事で簡単なHinemos用recipeを作ってみたつもりだったが、あくまでもHinemos_managerだけのインストールで、これではすぐに使えないので、Hinemos_webclientもインストールするrecipeへと改良する。

Hinemos_webclient

NECがHinemos用に作ったWebclientサーバプログラムのようです。

Hinemosは2010年を越えた今でも標準ではWebClientでの監視・制御ではないということをrecipeを作ったあとに知った。機能がいくらあっても、agentプログラムならまだしても、監視と制御がWindowsのクライアントだけでは使い勝手が悪いのでWebclientは必須です。(もはやクライアントアプリケーションがないと利用できないシステムはナンセンスだと思ってます)

recipe

さっそくHinemos_managerと同様にrecipeを作ります。

[hinemos_webclient.rb]

install_dir = '/usr/local/src'

log '[hinemos::hinemos_webcli]fetch hinemos_webclient package'

remote_file "/tmp/hinemos_webcli.tar.gz" do

source 'http://sourceforge.jp/frs/redir.php?m=jaist&f=%2Fhinemosweb%2F59854%2FHinemosWebClient-2.0.2.tar.gz'

end

log '[hinemos::hinemos_manager]install hinemos_webcli'

bash 'install_hinemos_webcli' do

user 'root'

code <<-EOL

install -d #{install_dir}

tar xfz /tmp/hinemos_webcli.tar.gz -C #{install_dir}

cd #{install_dir}/HinemosWebClient-2.0.2

./webclient_installer_JP.sh

EOL

end

log '[hinemos::hinemos_manager]set hinemos daemon'

execute 'set hinemos daemon' do

command 'bash /opt/apache-tomcat-6.0.35/bin/startup.sh'

action :run

end

~/site-cookbooks/hinemos/recipe/default.rb にincludeしてprovisionするなどすれば完了です。

%w(readline.i686 net-snmp net-snmp-utils).each do |package|

yum_package package do

action :install

end

end

include_recipe "hinemos::hinemos_server"

include_recipe "hinemos::hinemos_webclient"

$ vagrant provision

失敗しました。なぜでしょう??

直接sshでログインしてwebclientのインストーラーをみたところ、java6が必要でした。

java6と7を両方インストールする

hinemos_managerはjava7

hinemos_webclientはjava6

を必要とするようです。めちゃめちゃですね。

ただし、chefではjavaのパラメターをjsonで二つしていしても二つ同時にインストールできないみたいです。jdk_versionをリスト型にしたりしても失敗しました。

config.vm.provision :chef_solo do |chef|

chef.cookbooks_path = ["cookbooks", "site-cookbooks"]

chef.add_recipe "yum"

chef.add_recipe "java"

chef.add_recipe "newgit"

chef.add_recipe "hinemos"

chef.json = {

"java" => {

"install_flavor" => "openjdk",

"jdk_version" => '7'

},

"java" => {

"install_flavor" => "openjdk",

"jdk_version" => '6'

},

"newgit" => {

:version => '1.8.3.4',

:source_uri => 'https://git-core.googlecode.com/files/git-1.8.3.4.tar.gz'

}

}

end

急遽、イベント用にHinemosを試すことにしたのだけれども、今後もイベント毎にHinemosを作ったりすることもあるので、Vagrant+Chef+Berkshelf設定ファイルを作ってみた。

Hinemos

Hinemosとは、NTTデータが開発したオープンソースのサーバー運用管理ツール。

  • リポジトリ情報管理機能
  • 管理対象となるコンピュータに関する情報を集中管理。Hinemosの基盤機能。

  • 監視管理機能
  • イベントログ情報やステータス情報の集中監視をグループ化して可能。

  • 性能管理機能
  • CPU・メモリ・ディスク・ネットワークのリソース情報を、グループまたは管理対象ごとに管理。リアルタイム性能グラフ表示と実績性能情報収集の各機能を有する。

  • ジョブ管理機能
  • ユーザ作成ジョブを、複数の管理対象で連携させて定義・実行。

  • 一括制御機能
  • 仮想・物理関係なく、複数サーバを一括処理実行。パッチ適用、起動停止の管理などをGUI操作実行。

vagrant+chef-solo+berkshelfの手順

例として、gitとjava7とHinemosをインストールしたCentOSの仮想マシンをたてる。

最下部の[参考]をみれば、もっと詳しく手順の説明が書いてある。


1. Vagrant が VM を立ち上げる(Vagrantfile設定後->vagrant up)

2. Cookbook を VM に転送する(chefとBerkshelfの設定をしておく)

3. VM 上で Chef Solo を実行する(knifeコマンド)


Berkshelfは使った事なかったので初トライ。

codeはGithub::hinemos-chefにおいたので参照。

Vagrant準備

Vagrant公式ページから各OS毎にあわせてインストール。

  • 必要なCentOSをDL

    Boxリストにvagrantのリポジトリ上にベースとなるOSの仮想マシンデータ(box)があるので取得。

    $ vagrant box add centos6.4_64 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130731.box

    $ vagrant plugin install vagrant-omunibus #仮想マシンへchef自動インストール

    $ vagrant plugin install vagrant-berkshelf # パッケージインストールの依存解決に必要

  • vagrantのデフォルト設定ファイルを作成して必要な設定を書く

    $ cd hinemos-chef

    $ vagrant init centos6.4_64

    $ vagrant up # 仮想マシン作成

    $ vagrant ssh # 仮想マシンへssh接続、account:vagrant/pass:vagrant

  • Vagrantfileのconfig.vm.provisionのルーチンを全てコメントアウトすれば、VirtualBox上でCentOSが起動する。

chef-solo導入

shef-soloはknifeコマンド使って設定や処理のcookbootとrecipeを実行できる。


まず、chef-soloで利用されるcookbookとレシピのテンプレート作成。

そして、以下のようにchef-sofoでローカル・リモートサーバ上でサーバ設定できる。

$ knife solo init hinemos-chef

$ tree hinemos-chef/

hinemos-chef/

├── Berksfile

├── cookbooks

├── data_bags

├── environments

├── nodes

├── roles

└── site-cookbooks

$ knife cookbook create [COOKBOOK-NAME] -o site-cookbooks/

$ vim node/xxx.xxx.compute.amazonaws.com.json # リモート名 or SSH_host名

{

"run_list":[java, newgit, hinemos]

}

$ knife solo prepare -i ~/hoge.pem ec2-user@xxx.xxx.compute.amazonaws.com

$ knife solo cook -i ~/secretkey.pem ec2-user@xxx.xxx.compute.amazonaws.com

  1. chef-soloの設定をVagrantに組み込む

    Vagrantfileをcookbooksやnodesと同じディレクトリにおく。

    $ vim Vagrantfile

    ########################

    # -*- mode: ruby -*-

    # vi: set ft=ruby :

    # Vagrantfile API/syntax version.

    VAGRANTFILE_API_VERSION = "2"

    Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

    config.vm.box = "centos6.4_64"

    config.vm.box_url = "https://github.com/2creatives/vagrant-centos/releases/download/v0.1.0/centos64-x86_64-20131030.box"

    config.vm.network :forwarded_port, guest: 80, host: 8080

    config.vm.network :private_network, ip: "192.168.33.33"

    config.berkshelf.enabled = true # berkshelf設定

    config.omnibus.chef_version = :latest # omunibus設定

    config.vm.provider :virtualbox do |vb|

    # Use VBoxManage to customize the VM. For example to change memory:

    vb.customize ["modifyvm", :id, "--memory", "1024"]

    end

    config.vm.provision :chef_solo do |chef|

    chef.cookbooks_path = ["cookbooks", "site-cookbooks"]

    chef.add_recipe "yum"

    chef.add_recipe "newgit"

    chef.add_recipe "java"

    chef.add_recipe "hinemos"

    # # You may also specify custom JSON attributes:

    chef.json = {

    "java" => {

    "install_flavor" => "openjdk",

    "jdk_version" => '7'

    },

    "git" => {

    :version => '1.8.3.4',

    :source_uri => 'https://git-core.googlecode.com/files/git-1.8.3.4.tar.gz'

    }

    }

    end

    end

  2. gitとhinemos用のレシピを作る。

    gitのcookbook名をnewgitとしているのは、CentOSのデフォルトインストールgit-1.7.1パッケージを削除したり、configureオプションいれたりしてインストールするため。

    (opscode上のgit-cookbook使ったら、うまくいかなかったので別途用意)

    $ vim site-cookbooks/git/recipe/default.rb

    install_dir = '/usr/local/src'

    version = node['git']['version']

    source_uri = node['git']['source_uri']

    configure = node['git']['configure']

    node['git']['packages'].each do |package_name|

    package "#{package_name}" do

    :install

    end

    end

    remote_file "/tmp/git-#{version}.tar.gz" do

    source "#{source_uri}"

    end

    bash 'install_git' do

    user 'root'

    code <<-EOL

    yum -y remove git

    install -d #{install_dir}

    tar xfz /tmp/git-#{version}.tar.gz -C #{install_dir}

    cd #{install_dir}/git-#{version}

    #{configure} && make && make install

    EOL

    end

    賛否両論あるが、hinemosに必要なパッケージをまとめてinstallさせる。

    (add_recipeに書いてもよい。。というか依存関係を解決するには望ましい)

    $ vim site-cookbooks/hinemos/recipe/default.rb

    %w(readline.i686 net-snmp net-snmp-utils).each do |package|

    yum_package package do

    action :install

    end

    end

    include_recipe "hinemos::hinemos_server"

    $ vim site-cookbooks/hinemos/recipe/hinemos_server.rb

    install_dir = '/usr/local/src'

    log '[hinemos::hinemos_manager]fetch hinemos_manager package'

    remote_file "/tmp/hinemos.tar.gz" do

    source 'http://sourceforge.jp/frs/redir.php?m=jaist&f=%2Fhinemos%2F60378%2Fhinemos_manager-4.1.1_rhel6_64.tar.gz'

    end

    log '[hinemos::hinemos_manager]install hinemos_manager'

    bash 'install_hinemos' do

    user 'root'

    code <<-EOL

    install -d #{install_dir}

    tar xfz /tmp/hinemos.tar.gz -C #{install_dir}

    cd #{install_dir}/Hinemos_Manager-4.1.1_rhel6_64

    ./manager_installer_JP.sh

    EOL

    end

    log '[hinemos::hinemos_manager]regist hinemos daemon'

    bash 'regist_daemon_hinemos' do

    user 'root'

    code <<-EOL

    cp /opt/hinemos/sbin/service/hinemos_manager /etc/init.d/

    EOL

    end

    log '[hinemos::hinemos_manager]set hinemos daemon'

    execute 'set hinemos daemon' do

    command 'chkconfig --add hinemos_manager'

    action :run

    end

    log '[hinemos::hinemos_manager]start hinemos daemon'

    if File.exists?('/etc/init.d/hinemos_manager')

    service 'hinemos_manager' do

    provider Chef::Provider::Service::Init::Redhat

    supports :start => true, :restart => true, :reload => true, :stop => true

    action :start

    end

    end

Berkshelf

Berkshelfが必要なcookbooks依存関係を解決してくれる。

opscodeの公式cookbook以外はsite-cookbooks以下に作るのが慣例のようだ。

まず、利用する全cookbookをリストアップしてBerksfileに書く。

$ cd hinemos-chef

$ vim Berksfile

###############

site :opscode

cookbook 'yum'

cookbook 'sudo'

cookbook 'users'

cookbook 'java'

cookbook 'newgit', path: 'site-cookbooks/git'

cookbook 'hinemos', path: 'site-cookbooks/hinemos'

次に以下コマンドを実行すると、依存関係のあるcookbookをcookbooksディレクトリへDLしてくれる。

$ berks install --path cookbooks

$ ls cookbooks/

aws dmg java users yum-epel build-essential newgit runit windows chef_handler hinemos sudo yum

思ったよりいっぱいありますねえ。

Berkshelfすばらしい。

いよいよ実行

設定はできたのでvagrantを動かすだけ。

$ vagrant up # 仮想マシン起動

$ vagrant ssh # vagrantユーザーでssh接続

$ vagrant provision # cookbookを編集->反映させる

$ vagrant halt # 仮想マシン停止

$ vagrant destroy # 仮想マシン削除

後記

今回、「自前でcookbookのrecipeを書くこと」「Berkshelfの利用」を初めて試した。

Berkshelfはものすごい役立つので利用必須になりそうだ。

bash実行設定でcodeを複数行書いても実行されないchkconfigとか、なんらか細かいルールが他にもあるので、vagrantup -> vagrant ssh -> vagrant destroyを数十回テストしてようやく使えるようになった。

chef/puppetにとって一番重要な「冪等性」は数十回のテストの後、確かに保証されるようになるとは思う。

前述したけれど、今回作成したレシピとか設定codeはGithub::hinemos-chefとしてとりあえずおいた。

参考

http://knowledge.sakura.ad.jp/tech/420/

http://qiita.com/taiki45/items/b46a2f32248720ec2bae

http://tsuchikazu.net/chef_solo_start/

http://blog.a-way-out.net/blog/2013/11/15/fuelphp-vagrant-centos/

http://dev.classmethod.jp/tool/vagrant-chef/

↑このページのトップヘ