2013年12月07日

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

EPELリポジトリにDockerパッケージが追加された

CentOS6にDockerホストを構築しようとすると大分面倒だったが、状況は一変した。EPELにパッケージが追加されたからだ。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
Dockerをインストール
$ sudo yum install -y http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
$ sudo yum install -y docker-io

実に簡単。これだけ。

Dockerを起動
$ sudo /etc/init.d/docker start
Starting docker:                                           [  OK  ]
$ sudo /etc/init.d/docker status
docker (pid  1428) is running...
マシンイメージをダウンロード
$ sudo docker pull base
Pulling repository base
b750fe79269d: Download complete
27cf78414709: Download complete
$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
base                latest              b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
base                ubuntu-12.10        b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
base                ubuntu-quantal      b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
base                ubuntu-quantl       b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
コンテナを起動
$ sudo docker run -i -t base /bin/bash
root@d004fa70a753:/# ip addr show
7: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether f2:df:e9:48:38:52 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
    inet6 fe80::f0df:e9ff:fe48:3852/64 scope link
       valid_lft forever preferred_lft forever
9: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
root@d004fa70a753:/# uname -a
Linux d004fa70a753 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
root@d004fa70a753:/# exit
exit
</loopback,up,lower_up></broadcast,multicast,up,lower_up>
参考文献



編集

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)Wakame 

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)Wakame 

2013年10月12日

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

2013/10/12 15:48:44 @ 新杉田駅

新杉田駅にタッチ! : 最近は月いちペースで帰って来てる。

住所:神奈川県横浜市磯子区新杉田町6

2013/10/12 15:54:35 @ 杉田駅

杉田駅にタッチ! : 杉田商店街を久々に通り抜けたら、立呑屋が増えてる事に気づいた。。

住所:神奈川県横浜市磯子区杉田2-1-9

2013/10/12 16:18:21 @ 杉田バッティングセンター

杉田バッティングセンターにタッチ! : 昔からあるのに1度も利用したことが無い。

住所:神奈川県横浜市磯子区




編集
@hansode at 15:48|Permalinkライフログ | ロケタッチ

2013年07月01日

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

世間では余り使われてないのか

test(1)コマンドによる変数の中身やファイル・ディレクトリの存在有無を確認する方法は、良く知られている気がする。しかし、functionに関して触れらてるエントリを見かけないので、ここに書いておく。

declareかtypesetの出番

declareとtypeset、どちらでも良い。同じ意味。自分は何となくな理由で declare を使っている。

declare -f [name]

サンプルコード

#!/bin/bash

function defined_func() { :; }

declare -f defined_func
echo $? # should be zero

declare -f undefined_func
echo $? # should be non-zero

実行結果は、こうなる。

defined_func ()
{
    :
}
0
1
結果まとめ
項目declare -f 実行結果終了ステータス
定義済み関数の内容0
未定義無し1

もしも関数の内容を表示させたくない場合は /dev/null へリダイレクトすれば良い。

declare -f [name] >/dev/null
使い所は?

declare -f [name] を上手く使うと、bashでDSLが可能になって来る。bashでDSLのネタを書く為の前提エントリとして書いたのが、本エントリ。次回、bash-DSLエントリをお楽しみに?

続きを読む


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

2013年06月30日

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

個人見解: 大半は "$@" にしておけば、期待する動作となる

幾つかスクリプトを書いて来て、気を付けておいた方が良かったことの1つが、$@の扱い。$@ と "$@" は、内部処理では大きく違う。サンプルコードと結果を、まとめてみた。

dump-vers.sh

#!/bin/bash
#
# $ dump-vers.sh [args]
#

function dump_vers() {
  while [[ "$1" ]]; do
    echo "'$1'"
    shift
  done
}

echo '#1'; dump_vers $@
echo
echo '#2'; dump_vers "$@"

実行例1: " なし

$ ./dump-vers.sh a b c d
#1
'a'
'b'
'c'
'd'

#2
'a'
'b'
'c'
'd'
  • #1 引数4つ
  • #2 引数2つ

実行例2: " あり

$ ./dump-vers.sh "a b" "c d"
#1
'a'
'b'
'c'
'd'

#2
'a b'
'c d'
  • #1 引数4つ
  • #2 引数2つ
まとめ
引数#1#2
実行例1a b c d44
実行例2"a b" "c d"42

大半は "$@" にしておけば、期待する動作となる。

続きを読む


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

2013年06月29日

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

Travis CIでビルドテストしよう

fpm-cookeryのrecipie.rbを作ったとする。そのテストをしたくなったら、どうするか。Travis CIで出来ないか・・・と思って、やってみたら、ビルド出来た。

ところで、fpm-cookeryとは

rpmを作るには、通常、specファイルを作成してrpmbuildする。その手順を単純化しつつも、debなども美味しくビルド出来てしまうのが、fpm。これだけでもパッケージング作業の苦しみを軽減してくれる。しかし、その苦しみを更に軽減してくれるのが、fpm-cookeryだ。DSLにより、レシピを定義出来るようになっている。

仮にfpmを単体利用する場合は、fpmコマンドを実行する為のラッパースクリプトかMakefileで実行する戦略となるだろう。fpmコマンドには決して少なくはないオプションを指定する必要があり、これが結構しんどい。fpm-cookeryを使えば、recipie.rbを定義するだけで良い。

$ fpm-cookery recipie.rb

これで終わる。凄く簡単だ。

recipie.rbをテストするには

fpm-cookeryコマンドの終了ステータスコードが、

  • 0 か
  • そうでないか

これにより、recipie.rbが正しいかどうかを判断可能。ゆえに、テスト可能である。

Travis CIでビルドする

ビルドするのに必要な材料。

  • .travis.ymlファイル
  • fpm-cookery環境
  • recipie.rbファイル

fpm-cookeryはRubyで書かれているので、.travis.ymlに、rubyを指定する。

language: ruby

rubyが指定されている時、Travis CIは、Gemfileの存在を検知し、bundle installを自動的に実行してくれる。明示的に実行する必要は無い。つまり、Gemfileにfpm-cookeryを定義しさえすれば、fpm-cookery環境が手に入ってしまう。

gem 'fpm-cookery'

fpm-cookery-travis-exampleでは、fpm-cookeryのrecipie.rbを拝借した。CIワーカーに配置するため、.travis.ymlのbefore_installターゲットで git cloneを実行させている。

before_install:
 - git clone https://github.com/bernd/fpm-cookery.git

仕上げ、.travis.ymlのscriptターゲットに、bundle execを指定。 なお、ここでsudoを指定しているのは、fpm-cookery/recipe.rbが /opt 配下への書き込みをするので、root権限を付与する為である。

script:
  - sudo PATH=$PATH -E bundle exec fpm-cook fpm-cookery/recipes/fpm-cookery/recipe.rb

これでfpm-cookeryを実行するパイプラインが構築される。fpm-cookery-travis-exampleでは外部のrecipie.rbを使用しているが、recipie.rbをリポジトリに内包し、変更のたびにGitHubへpushすれば、CIが回る。

あと書き

fpm-cookery専用ビルドサーバをサービス化したら面白いんじゃないか。

  • recipie.rb登録
    • recipie.rbのURIを指定
      • recipie.rb の中身を登録(プライベートパッケージ向け)
  • ビルドが完了すると、アクセス制限付きパッケージリポジトリにデプロイ
  • メール等でアクセス手段を通知

自分が欲しいので、何か作る。




編集
@hansode at 15:30|PermalinkComments(0)TrackBack(0)PaaS/Travis-CI 
このエントリーをはてなブックマークに追加

二度と同じ失敗を犯さぬように

手元のRubyプロジェクトをTravis CIでビルドさせてみると、あっさり失敗。レポートを見ると、/opt配下にディレクトリを作成しようとして、失敗していた。この場合は、root権限が必要だ。

そこで調べてみると、Travis CIでは、sudoコマンドを使える事が判明。

The Build Environmentより

To set up the system for your build, you can use the sudo command to install packages, to change configuration, create users, and so on.

と言う事で、早速sudoコマンドを指定してみたが、見事に何度も失敗ビルド。その要因は、環境変数。良くある事ですね・・・。二度と同じ失敗を犯さぬよう、ここに書き残す。

成功ビルドの組み合せ

成功ビルドとなったコマンドの組み合せ例は、下記の通り。

$ sudo PATH=$PATH -E env
  • PATH=$PATH で環境変数PATH指定(維持)
  • -E オプションで、実行元ユーザーの環境変数を維持

快適なTravis CI生活を。

続きを読む


編集
@hansode at 13:00|PermalinkComments(0)TrackBack(0)PaaS/Travis-CI 

2013年06月28日

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

継続的改善と自動化が品質を作り上げる

GW代休として、丸一週間お休みを頂いた。
今回の休暇は、いつもとは、一味も二味も違うものであった。

その要因は、自動化。

自動化による脱属人化

下記は、苦しみながら、この1年間で積み上げたWakame-VDCに関する自動化の一部で、今はJenkins(CIサーバ)さんが行っている。

  1. (誰かがSCMにコードをプッシュすると)変更を検知
  2. アプリケーションパッケージを生成
  3. パッケージリポジトリを再構築
  4. パッケージリポジトリから新規VMイメージをビルド
  5. ビルドされたVMイメージを起動
  6. VMに対し、スモークテストを実行
  7. テスト結果をチャットへ通知

ビルドが失敗した時は、ビルドを失敗させたコミッターが、失敗レポートを閲覧して対応する。
休暇中、一度だけビルドが失敗していたが、直ぐに修正され、自分に連絡が来る事は無かった。

これらの工程・処理に関しては、脱属人化に成功した。
自動化により、自分自身が一番助かっている。

身体で感じる重要性

CI環境は、作ってみない限り、その良さと意味が分からない事は、多々ある。
情報整理を兼ね、これまでの取り組み、支える技術等を書き綴ってみる事にする。

継続的インテグレーション入門 開発プロセスを自動化する47の作法
ポール・M・デュバル スティーブ・M・マティアス アンドリュー・グローバー
日経BP社
売り上げランキング: 132,948



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

2013年03月03日

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

2013/03/03 15:34:48 @ グラビティ高田馬場店

グラビティ高田馬場店にタッチ! : 心地よい肉体疲労感を得られた。

住所:東京都豊島区高田3-13-8 吉美ビル1F

2013/03/03 17:48:20 @ 参宮橋駅

参宮橋駅にタッチ! : 参宮橋駅から事務所へ向かってみる。

住所:東京都渋谷区代々木4

2013/03/03 18:42:45 @ 株式会社あくしゅ

株式会社あくしゅにタッチ! : 荷物回収ついでに倉庫整理。

住所:東京都新宿区西新宿3-5-15 栄マンション805




編集
@hansode at 15:34|Permalinkライフログ | ロケタッチ