開発プロセス

2015年03月27日

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

個人作業環境を一撃セットアップ

身近なメンバーに説明する手頃な材料が欲しかったので、本エントリを書いた。

作業ノードを転々としていると、各所に作業環境を構築する回数が多くなる。作業対象が使い捨てである事が増えれば増える程、その傾向が強くなった。構築回数が多いからこそ、整理する機会に恵まれていたとも言う。その結果、今ではログイン後に下記コマンド1行を実行するだけだ。

$ curl -fSkL https://raw.githubusercontent.com/hansode/env-bootstrap/master/build-personal-env.sh | bash

build-personal-env.shの処理を掘り下げて行く。

build-personal-env.sh 処理概要

  1. mkdir -p ${HOME}/repos/git/github.com
  2. hansode/dotfiles${HOME}/repos/git/github.com/に配置
    1. cd ${HOME}/repos/git/github.com/ && make
    2. make 実行により、自分好みのdotfilesが配置・セットアップされる

dotfilesdotfileだけを管理し、env-bootstrapdotfilesをセットアップする。dotfilesにセットアップスクリプトを置いても良いが、役割分担を明確にする為にも別プロジェクトで管理している。今(2015/03/27現在)は、たまたまdotfilesしか扱ってないが、他のプロジェクトを扱いたい場合は、今の様に役割分担してる方が柔軟な管理が可能。かつては別プロジェクトを扱っていた経緯がある。

dotfilesが環境を判定

作業対象は複数あり、プラットフォーム毎に必要なdotfileが異なって来る。

  • Cygwin 1.7 / Windows 8.1
  • MacOS 10.10 (Yosemite)
  • Raspbian 7.6 (Wheezy)
  • Fedora release 20 (Heisenbug)
  • CentOS-6.6/6.5/6.4
  • CentOS-7.0.1406

例えばCygwin環境にはDropboxをインストールしているので、Cygwinのホームディレクトリからアクセスしやすいようにしている。また、CygwinとMacOSでは、Vagrantを扱う事があるので、Vagrant環境を整理している。

自身の${HOME}構造を標準化

build-personal-env.shが配置するdotfileswork/repos/git/github.com/dotfiles配下。これは自分だけのルールであり、第三者に強制されるものではない。長年の経験から程よく管理しやすい構造として辿り着いた構造は、下記の通り。

まとめ

自分が実施して来た手順を整理すると、こうなる。

  1. dotfilesを整理する
  2. dotfilesをセットアップするスクリプトを管理
  3. ${HOME}構造を標準化する
  4. 1〜3を繰り返す

自分は上記順序で整理して来たが、1〜3の順序に根拠や強制力は無い。整理出来そうな所から整理すれば良い。重要なのは、整理する事だ。

関連成果物




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

頻繁なRPMリリースサイクルを実現させる為に

rpmspecファイルの重要箇所のみ抜粋。一般的なrpmspecではReleaseタグを静的に定義する。

Release: 0.0.1%{?dist}

Wakame-vdcでは頻繁にrpmをビルドしている都合上、毎回rpmspecファイルを書き換える作業は、実に都合が悪い。可能であればリリースIDを動的に指定したい。そう言った要件を満たす為、wakame-vdc.specでは、少し工夫している。

Releaseタグを動的に指定出来れば解決する

工夫している該当箇所は、この3行。

https://github.com/axsh/wakame-vdc/blob/master/rpmbuild/SPECS/wakame-vdc.spec#L10-L12 (2015/03/27現在)

%define release_id 1.daily
%{?build_id:%define release_id %{build_id}}
Release: %{release_id}%{?dist}

コメントを添えて補足すると、

# release_idを定義。値は 1.daily
%define release_id 1.daily

# build_idが定義されている場合は、build_idの値でrelease_idを再定義
%{?build_id:%define release_id %{build_id}}

# Releaseタグの値をrelease_idの値で定義
Release: %{release_id}%{?dist}

rpmbuild実行時に--defineオプションを指定すると、マクロを定義可能だ。

$ rpmbuild -bb ./wakame-vdc.spec --define "build_id 20150318183519git1a6d5b4"

これにより、rpmspecをコミットごとに修正する事無く、頻繁にrpmをリリース可能に出来る。なお、リリースIDに関しては

で述べているので、合わせてどうぞ。

まとめ

SRPMの事を考慮すると、Releaseタグの値は固定化されている事が望ましい。しかしWakame-vdcではSRPM生成を放棄しているので、問題にはならない。少なくとも、独自RPMの道を歩んでいる限りは。




編集
@hansode at 17:00|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

<committer_datetime>git<commit_hash>に辿り着くまで

Wakame-vdcOpenVNetに付与するリリースIDは、Gitのコミット履歴を基にして生成している。具体的には、

  • 20150318183519git1a6d5b4

メタ情報を含めて説明すると、

  • <committer_datetime>git<commit_hash>

この文字列を生成する手順は、下記の通り。

$ commit_hash=$(git log HEAD -n 1 --pretty=format:"%h")
$ committer_datetime=$(date --date="$(git log ${commit_hash} -n 1 --pretty=format:"%cd" --date=iso)" +%Y%m%d%H%M%S)
$ echo ${committer_datetime}git${commit_hash}

本エントリは、何故この様にしたのかを振り返る。

先輩パッケージの幾つかは既にgitのコミット履歴を利用していた

過去に何度かバージョン番号にgit情報らしきものを含んだパッケージを見かけた事があったので、それらを参考にする事にした。CentOS6で調査してみると、RPMにおける%{Release}タグにgitの情報を含んだパッケージが存在する。その一例を列挙する。

$ rpm -qa --qf '%{NAME} %{Release}\n' | awk '$2 ~ "git"'   | sort | sed 's,.el6,,'
deltarpm 0.5.20090913git
dkms 30.git.7c3e7c5
libpcap 6.20091201git117cb5
python-deltarpm 0.5.20090913git
tcpdump 3.20090921gitdf3cb4.2
xz 0.3.beta.20091007git
xz-libs 0.3.beta.20091007git
xz-lzma-compat 0.3.beta.20091007git

これらを整理してみると、3つに分類される。

  1. 数字.<comitter_date>git
    • deltarpm 0.5.20090913git
    • python-deltarpm 0.5.20090913git
    • xz 0.3.beta.20091007git
    • xz-libs 0.3.beta.20091007git
    • xz-lzma-compat 0.3.beta.20091007git
  2. 数字.git.<commit_hash>
    • dkms 30.git.7c3e7c5
  3. 数字.<committer_date>git<commit_hash>
    • libpcap 6.20091201git117cb5
    • tcpdump 3.20090921gitdf3cb4.2

いずれも、先頭の数字の意味が良く分からない。良く分からないので削除。

  1. <comitter_date>git
  2. git.<commit_hash>
  3. <committer_date>git<commit_hash>

これらを吟味。

  1. 【却下】コミットハッシュが含まれていないので追跡し辛い
  2. 【却下】辞書順に並べた時に、新旧を判断できない
  3. 【採用】欲しい情報を含んでいる

3をそのまま採用すると、<committer_date>の場合、1日に複数回ビルドすると、どちらのbuildが古いのか・新しいのかが分かり辛い。そこで<comitter_date>ではなく<comitter_datetime>を使う事にした。

  • <committer_datetime>git<commit_hash>

コミット時刻とコミットハッシュを含んだ理想的なリリースID。

リリースIDを生成・組み立てる

1: <commit_hash>を生成

特定コミットのハッシュを取得する。

$ git log HEAD -n 1 --pretty=format:"%h"
1e1b0ec

なお、HEADの代わりにブランチ名を指定する事も可能である。

$ git log master -n 1 --pretty=format:"%h"
1e1b0ec

これによりコミットハッシュを取得出来る。

2: <committer_datetime>を生成

--date=shortを指定すると、Y-m-dで取得可能だ。

$ git log HEAD -n 1 --pretty=format:"%cd" --date=short
2015-03-25

-はパッケージマネージャの予約文字列である可能性が高いので、-を削除したい。また、Y-m-dだけでなくH:M:Sも取得したい。しかし、この2つの要望を満たす--date=xxxを、git-logがサポートしてなかった。そこで、dateコマンドと組み合せて生成する事にした。

$ date --date="$(git log HEAD -n 1 --pretty=format:"%cd" --date=iso)" +%Y%m%d%H%M%S
20150325193037

コミット時刻を取得出来た。

3: 文字列gitを含める

参考にしたパッケージには、Gitの情報である事を明確化する為に文字列gitが含まれている。そのポリシーを拝借し、1と2を合わせる。

$ echo ${committer_datetime}git${commit_hash}

期待する文字列を生成出来る。

4: 1+2+3

3つをつなぎ合わせる。

$ commit_hash=$(git log HEAD -n 1 --pretty=format:"%h")
$ echo commit_hash=${commit_hash}
commit_hash=1e1b0ec

$ committer_datetime=$(date --date="$(git log ${commit_hash} -n 1 --pretty=format:"%cd" --date=iso)" +%Y%m%d%H%M%S)
$ echo committer_datetime=${committer_datetime}
committer_datetime=20150325193037

$ echo ${committer_datetime}git${commit_hash}
20150325193037git1e1b0ec

これにより、リリースIDを生成出来るようになった。

最後はrpmbuildと組み合せる

rpmbuildを実行する際にリリースIDをオプション指定すれば良い。Wakame-vdcの場合は、こうなる。

$ rpmbuild -bb ./wakame-vdc.spec --define "build_id 20150325193037git1e1b0ec"

build_idは標準マクロではないので、rpmspecファイルを工夫する必要がある。rpmspecの書き方は、本エントリの本題ではないので、別エントリにて。

まとめ

Wakame-vdcは、このリリースIDで約3年運用している。もしも何か不具合が生じた場合には、リリースIDに含まれているコミットハッシュから追跡可能だ。また、コミット時刻も含まれているので、どのコミットをビルドしたのが一目瞭然。今の所、凄く上手く行っている。結構おススメです。




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

2014年12月20日

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

Wakame-vdc / OpenVNet Advent Calendar 2014 12/20担当 (5回目)

enter image description here

開発の話は、開発担当者にお任せし、自分はCI環境周りの裏側のお話。
書けるネタは多々ある事が悩ましい。今回は、このネタを。

これまでの開発環境の概略

前回 は開発環境の構成履歴に触れた。

env-changelog

コンポーネントから見た構成変化

Wakame-vdcのコンポーネントを大きく2つに分けると、dcmgrとhvaに分けられる。それを踏まえ、変化の経歴を振り返ってみる。

env-changelog2
V0: Hva 1台構成
  • 構成概要
    • 全部入り
    • dcmgrとhvaを、1台の物理上で起動
  • 問題・課題
    • コンポーネント単位の評価・検証を行えない
V1: Dcmgr VM化
  • 構成概要
    • dcmgrとhvaを明確に分離
    • dcmgr用に専用VMを作成
  • 問題・課題
    • 複数ホスト間のセキュリティグループ検証
    • L3越え
V2: Hva複数台構成
  • 構成概要
    • hvaを複数台構成にし、L3越え対応
  • 問題・課題
    • 1拠点内の検証
    • 内外通信の検証を行えない
V3: 2拠点構成
  • 構成概要
    • 複数拠点対応
  • 問題・課題
    • 今の所無し

あとがき

こう言った視点においては、V4が登場する事は無さそうか。敢えて何か定義するならば、V3管理レイヤーだろうか。




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

2014年12月16日

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

Wakame-vdc / OpenVNet Advent Calendar 2014 12/16担当 (4回目)

enter image description here

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

開発環境構成履歴

主にCI環境周りにおいて改良・改善して来た4世代分の簡単なまとめ。

V0: Real / 〜2012.08
v0
  • 運用状況
    • 新プロジェクトが発足する度に物理購入
    • 1プロジェクトにつき1物理
    • 時には相乗り出来そうなサーバに相乗り
  • 問題・課題
    • 後日使う可能性ががあるので、環境塩漬け
    • 慢性的に環境不足気味
V1: KVM / 2012.09〜2014.03
v1
  • 運用状況
    • ハードウェア依存しない環境から順にKVM化
    • スクラッチビルドスクリプトによる仮想マシンイメージ作成
    • 開発対象は常にビルドスクリプトセット
  • 問題・課題
    • KVM依存環境の試験・検証
V2: Nested KVM / 2014.04〜2014.10
v2
  • 運用状況
    • KVM依存環境の試験・検証
    • 環境クローン化
    • IPアドレス・MACアドレスのレベルまで複製された複数の検証環境
    • 物理ホスト用OSにfedora-20を採用
  • 問題・課題
    • 1物理内に同一Nested KVMクラスタ構築
V3: Nested KVM on LXC / 2014.11〜現在
v3
  • 運用状況
    • 高い集積率
    • Wakame-vdcクラスタとOpenVNetクラスタが1物理に同居
  • 問題・課題
    • 今の所、無し
    • 敢えて挙げるなら、冗長化

あとがき

V4を探す旅に出ます。




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

2014年12月13日

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

Wakame-vdc / OpenVNet Advent Calendar 2014 12/13担当 (3回目)

enter image description here

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

Wakame-vdc/OpenVNetのCI/CDを支えるJenkinsクラスタ

気付いたら結構な大きさに成長していた手元のJenkinsクラスタ。今回はJenkinsクラスタの一部を紹介。

jenkins ci

JenkinsCIクラスターSlaveノード一覧: 全36ノード

2014/12/13時点のSlaveノードをキャプチャしたもの。

ノード  Jenkins

JenkinsCIクラスターの構成図

Slaveノード一覧キャプチャを見る限りでは、フラットな構成に見えている。クラスタ構成を図に書き出してみると、下記の様になる。

wakame-ci-jenkins-blog

※クリックで拡大(少々見づらいので改善予定)

ノードの色の意味

  • 緑: Jenkins-Master
  • 白: Jenkins-Slave
  • 灰: 多段SSH用踏み台

ノードの分類

  • 物理
    • ci01.dh (nested kvm host)
    • ci02.dh (nested kvm host)
    • ci03.dh (nested kvm host)
    • phys023 (nested kvm on lxc host)
    • phys024 (nested kvm on lxc host)
    • phys025 (nested kvm on lxc host)
    • phys026 (nested kvm on lxc host)
    • phys027 (nested kvm on lxc host)
    • opty (踏み台)
  • KVM
    • master
    • kemumaki12 x2
    • kemumaki13 x2
    • vzkemumaki20 x3
    • lxckemumaki21
    • kemu50 (踏み台)
    • kemu51
    • dsv-fgw01 (踏み台)
    • stg-muscle01-01
    • stg-jenkins01-01
  • LXC Container for KVM Host
    • phys024a (nested kvm host)
    • phys024b (nested kvm host)
    • phys025a (nested kvm host)
    • phys026a (nested kvm host)
    • phys026b (nested kvm host)
    • phys026c (nested kvm host)
    • phys027a (nested kvm host)
  • OpenVZ Container
    • ct101 x3
    • ct102 x3
    • ct103 x3
  • LXC Container
    • lxc101
    • lxc102
    • lxc103

使ってるサーバ仮想化技術

これらはWakame-vdcで使っているもので、個人的には使い慣れた技術の一部。時にはJenkinsクラスタで試験運用し、Wakame-vdcへ反映する事もある。

大半が使い捨て環境

仮想化してあるノードに関しては週1程度の周期で入れ替えを実施。
入れ替えタイミングは、

  • JenkinsCIがリリースされた時
  • OpenVZのvkernelがリリースされた時
  • セキュリティパッチ

1人でメンテナンス、作業時間は5分程度。

各種工程をスクリプト化・自動化してるので、一人で面倒見切れる状況。入れ替え作業は、手動実施で、作業時間は5分程度。作業と言っても、入れ替えスクリプトを実行するだけである。簡単な作業なので自動入れ替えすれば良いのだけども、今の所は検討段階。

あとがき

『こんなJenkinsの使い方をしてる人は居ない。』そんな事を何度か言われた事がある。しかも、変態を見るようなに。そんな経緯があり、愛着を込めて『変態Jenkins』と呼んでいる。




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

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)

2014年12月06日

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

Wakame-vdc / OpenVNet Advent Calendar 2014 12/06担当 (1回目)

enter image description here

開発の話は、開発担当者にお任せし、自分はCI環境周りのお話。
書けるネタは多々ある事が悩ましい。今回は、このネタを。

開発環境におけるアカウント管理に悩まされて・・・

背景

アカウント管理が煩雑になっていた。

  • 各自が思い思いのタイミングで作成
  • SSHの認証方式が、パスワード認証だったり、公開鍵認証だったり
  • 各サーバによって、個人のユーザー名が異なる場合も

課題整理してみると・・

  • UNIXユーザー名
    • 作成時に悩みたくない
    • 開発機においては統一したい
  • SSHの認証方式
    • パスワード認証は不可
    • 公開鍵認証のみ

全員がGitHubにアカウントを持ってるので、GitHubベースで揃えられないものか・・・?

github


アカウント管理整理へ
  • 開発機のユーザー名?
    • 全員がGitHubにアカウントを持っている
    • GitHubにおけるユーザー名を使う
  • 公開鍵管理?
    • GitHubにはSSH公開鍵用APIの口があり、ユーザーの毎公開鍵を取得可能
    • 各自から公開鍵を貰う必要が無い
    • 公開鍵入れ替えは、ローカルの公開鍵ファイルを上書き
  • sudoers権限?
    • パスワード設定しないので、NOPASSWDを付与

必要なのは、GitHubのユーザー名だけである事が分かった。
手順整理も出来たので、あとはスクリプト化するだけ。

アカウント管理スクリプト作成

期待するスクリプトは、ユーザー名が唯一の引数。

$ sudo ./add-github-user.sh <github user>

仮に hansode を追加する場合は、

$ sudo ./add-github-user.sh hansode

そして作ったのが、下記プロジェクト。

インストール
$ curl -fsSkL https://raw.githubusercontent.com/hansode/add-github-user.sh/master/add-github-user.sh -o add-github-user.sh
$ chmod +x add-github-user.sh
実行例
$ sudo ./add-github-user.sh hansode
+ [[ -z hansode ]]
++ tr A-Z a-z
+ declare devel_user=hansode
+ declare devel_group=hansode
+ declare devel_home=/home/hansode
+ getent group hansode
+ groupadd hansode
+ getent passwd hansode
+ useradd -g hansode -d /home/hansode -s /bin/bash -m hansode
+ [[ -f /etc/sudoers ]]
+ egrep '^hansode' /etc/sudoers -q
+ echo 'hansode ALL=(ALL) NOPASSWD: ALL'
+ su - hansode -c '/bin/bash -ex'
+ egrep -w '^umask 022' -q /home/hansode/.bashrc
+ echo 'umask 022'
+ su - hansode -c '/bin/bash -ex'
+ mkdir -p -m 700 /home/hansode/.ssh
+ curl -fsSkL https://github.com/hansode.keys -o /home/hansode/.ssh/authorized_keys

あとはこのスクリプトを使い、開発機ごとに必要なアカウントを作成するのみ。

導入後

  • 誰のモノか分からないアカウントが無くなった
  • 構築後は対象サーバのIPアドレスを教えるだけ
  • 環境構築スクリプトからアカウント作成までワンストップ

あとがき

開発者全員がGitHubアカウントを持っているからこそ可能な事。




編集
@hansode at 11: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月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)