Wakame-vdc

2015年07月03日

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

2015/06の出来事を個人的視点で振り返ってみる。毎月月初にお届けするつもりで、今回が第四弾。

機能に関して

1: Pull Requestより

今回も盛り沢山。機能別に分類。

それぞれ簡単にまとめると

  • rpm
    • 【改修】v1.0へ向け、rpmビルド時に任意タグ指定にする仕組み
  • dcmgr
    • 【修正】windows対応へ向けた機能修正
    • 【改修】windows対応へ向けた期限付きパスワード機能追加
    • 【改修】ip_pools/releaseのvalidation強化
  • vdc-manage
    • 【改修】dhcp addrange/delrangeの機能仕様変更。今までの仕様が柔軟過ぎた為、機能制約を追加
    • 【修正】dhcp showの出力不備修正
  • gui-manage
    • 【修正】アカウントと紐づいてないユーザーでログインするとGUIがクラッシュする問題を修正
  • document
    • 【改修】Google Analytics用コード追加
    • 【改修】vdcユーザーリスト更新

関連記事やblogエントリ

あとがき

関連エントリの少なさが目立つ。




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

2015年06月03日

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

2015/05の出来事を個人的視点で振り返ってみる。毎月月初にお届けするつもりで、今回が第三弾。

機能に関して

1: Pull Requestより

今回も盛り沢山。機能別に分類。

それぞれ簡単にまとめると

  • webui
    • 【修正】アカウントと紐づいてないユーザーでログインするとGUIがクラッシュする問題を修正
  • dcmgr
    • 【修正】DBマイグレーションのdownタスクを修正
  • mussel
    • 【改修】completion対象を追加
    • 【改修】retryヘルパーの未定義変数を定義
    • 【改修】セキュリティグループをタイプ指定で検索出来るように改修
  • document
    • 【改修】wiki用のリポジトリを統合(作業中)

関連記事やblogエントリ

プレスリリース効果。

あとがき

どうにか第三弾まで継続。




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

2015年05月07日

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

2015/04の出来事を個人的視点で振り返ってみる。毎月月初にお届けするつもりで、今回が第二弾。

機能に関して

1: Pull Requestより

今回は盛り沢山。機能別に分類。

それぞれ簡単にまとめると

  • document
    • 【改修】 wiki用のリポジトリを統合(作業中)
  • vmapp
    • 【更新】CentOS-6.4CentOS-6.6に更新
  • api
    • 【修正】stateを対象にした絞り込み検索にhaltedを追加修正
    • 【新規】network_vifsの一覧を取得出来る様に機能追加
  • hva
    • 【修正】KVM: run.shの改行を修正
    • 【修正】LXC: lxc-1.0.0対応へ向けた修正
  • load_balancer
    • 【改善】低スペック環境向けの修正対応
      • Upstart System Job Configに適切なsleepを追加
  • webui
    • 【修正】不具合修正
  • mussel
    • 【追加】不足オプション追加
    • 【新規】mussel-completionをリリース
  • mussel rpm
    • 【新規】wakame-vdc-client-musselとしてrpm化
      • wakmae-vdcを分割

関連記事やblogエントリ

あとがき

何度か書いてみないと分からないので、可能な限り継続する。




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

2015年04月05日

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

まとめページを作りたかった

これまでWakame-vdc情報をはてブにてwakame-vdcタグを付けしていたので、とりあえず集約は出来ている。そう、とりあえずは...。しかし、どこか使い辛かった。例えば初期リリースから今までを振り返ろうとすると、ブックマークした順序では使い辛い。

  • いつ、はてブしたのか?ではなく
  • 何日付けの記事なのか

都合の良いツールが見つからなかったので、Markdown形式でリンク集を作る事にした。

これで目出度く欲しい情報を手に入れた。なお、更新作業は気が向いた時に行っている。

リンクの過不足報告は、プルリクエストで

今の所は自分個人のリンク集でしかない。GitHubで公開しているので、もしも過不足を発見した等の場合はプルリクエストして頂けると幸いです。

あとがき

勝手に情報収集するbotを作るのが良いのか。




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

2015年04月02日

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

2015/03の出来事を個人的視点で振り返ってみる。毎月月初にお届けするつもりで、今回が記念すべき第一弾。

機能に関して

1: Pull Requestより

分類すると3つの機能が取り込まれた事になる。

それぞれ簡単にまとめると、

  • wakame-init for ubuntu-14.04
    • マシンイメージをubuntu対応して欲しいとの要望が来ていたので、ubuntu用wakame-initの開発が進んでいる。
  • isonoのバージョンを0.2.19から0.2.20へ
    • 低スペック環境においてキューの扱いに問題が生じていたので、その修正。
  • wakame-vdcのバージョンを13.08から15.03へ
    • 影響範囲は主にRPM。
      • wakame-vdc-13.08-<commit-datetime>git<commit-hash>.el6.x86_64.rpmから
      • wakame-vdc-15.03-<commit-datetime>git<commit-hash>.el6.x86_64.rpm
2: enterprise-iaas-easy-builder 公開

このツールは、これまでに構築して来た作業手順を整理したもので、環境構築作業時間を大幅に短縮する事が目的の1つとなっている。今後の構築作業のベースとして使用する予定で、改善すべき内容があれば、随時EIEBに反映して行く。

関連記事やblogエントリ

あとがき

何度か書いてみないと分からないので、宣言通りに毎月月初にアウトプットする。




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

2015年03月27日

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

頻繁な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)