OpenVNet

2015年03月27日

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

<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月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月19日

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

Wakame Users Group Advent Calendar 2013 12/19担当 (5回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の声をお届けします。

もうすぐRHEL7がリリースされる

先日、RHEL7betaがリリースされた。今後やるであろうRHEL7対応作業へ向けて、ここ数日で気になった3項目に関して頭の中を整理してみた。

  1. epel6 -> epel7
  2. msyql -> mariadb
  3. systemd対応
1. epel6 -> epel7
  • epel-release-7-x.rpmへ変更する程度で済むはず
  • それと、rpmbuildツールが少し頑張れば良い領域
2. mysql -> mariadb
  • DB初期化時に使用している管理コマンドmysqladmin等を切り替え
  • Rubyの依存パッケージの検証が必要。仮にMySQLのままだとしても、ある程度のバージョン差異が生じるため、検証が必要。
3. systemd対応

現在upstartを採用している理由はいくつあって、その1つは、以前、ubuntuがメインディストリビューションだった事。upstart system confであれば、ubuntuでもrhel互換でも、どちらでも使える。そう言った理由で採用した経緯がある。しかし、最近ではubuntu環境へのインストール要件は皆無に近い。

  • rhel7には、upstartのrpmパッケージが存在してないので、SysV initかsystemdへ変更する必要がある。
  • rhel7の標準initはsystemd
  • これらを踏まえると、systemd対応は必至
あとがき

12/08担当 @debilityさんのエントリ:

2年ほど前にWakame-vdcと大いにまみれさせていただいた

2年前はRHEL6.0対応し始めてから間もない頃で、RPM化するよりも半年以上も前の事。ご迷惑をおかけしつつも、苦しみを分かち合いながら一緒にお仕事した日々は、今では良き思い出。あれから2年、あっと言う間。

福岡出張へのお誘い、まだ来てません。そろそろですね?




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

2013年12月18日

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

Wakame Users Group Advent Calendar 2013 12/18担当 (4回目の登場)

Wakame2-logo-mini

今回に限り「使ってみました/インストールしてみました」をしてみます。

Dockerと連携させる

Wakame Users Group Advent Calendar 2013 12/02担当がOpenVNetインストールネタ。

手順が正しいのかどうかをDockerで確認してみた。(あれ?Wakame-vdcじゃないの?)

検証環境
  • CentOS 6.5 (OpenVNet推奨はCentOS 6.4らしいけども気にしない)
  • 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
  • wakame-vnet.noarch 20131108190022git48a1361.fpm0-1
何度も再現させるのはDockerの得意とする所

手戻りと作業切りわけを兼ねて、3つのイメージを作成する戦略にした。

  1. repoファイルセットアップまで実施
  2. RPMインストールまで実施
  3. DB初期化まで実施
1: openvnet.repo
openvnet.repo/Dockerfileを配置
FROM hansode/centos-6-x86_64

RUN curl -fsSkL -o /etc/yum.repos.d/openvnet.repo             https://raw.github.com/axsh/openvnet/master/openvnet.repo
RUN curl -fsSkL -o /etc/yum.repos.d/openvnet-third-party.repo https://raw.github.com/axsh/openvnet/master/openvnet-third-party.repo
RUN rpm -Uvh http://dlc.wakame.axsh.jp.s3-website-us-east-1.amazonaws.com/epel-release
イメージをビルド
$ sudo docker build -t openvnet.repo .
Uploading context 10240 bytes
Step 1 : FROM hansode/centos-6-x86_64
 ---> cff199166afa
Step 2 : RUN curl -fsSkL -o /etc/yum.repos.d/openvnet.repo             https://raw.github.com/axsh/openvnet/master/openvnet.repo
 ---> Running in 5907fffae0ed
 ---> 79cea9051987
Step 3 : RUN curl -fsSkL -o /etc/yum.repos.d/openvnet-third-party.repo https://raw.github.com/axsh/openvnet/master/openvnet-third-party.repo
 ---> Running in 0ec98e92ddac
 ---> 103fb501492e
Step 4 : RUN rpm -Uvh http://dlc.wakame.axsh.jp.s3-website-us-east-1.amazonaws.com/epel-release
 ---> Running in 57110506cb9b
warning: /var/tmp/rpm-tmp.epxeye: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Retrieving http://dlc.wakame.axsh.jp.s3-website-us-east-1.amazonaws.com/epel-release
Preparing...                ##################################################
epel-release                ##################################################
 ---> ceb9cf50ef7e
Successfully built ceb9cf50ef7e
ビルドされたイメージの内容を確認
$ sudo docker images openvnet.repo
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
openvnet.repo       latest              ceb9cf50ef7e        25 seconds ago      14.42 MB (virtual 586.8 MB)

ここまでに586.8 MB使用。

2: openvnet.common
openvnet.common/Dockerfileを配置
FROM openvnet.repo

RUN yum install --disablerepo=updates -y wakame-vnet
イメージをビルド
$ sudo docker build -t openvnet.common .
Uploading context 10240 bytes
Step 1 : FROM openvnet.repo
 ---> ceb9cf50ef7e
Step 2 : RUN yum install --disablerepo=updates -y wakame-vnet
 ---> Running in 8ab3ffbfd54f
Loaded plugins: fastestmirror
Determining fastest mirrors
 * base: ftp.iij.ad.jp
 * epel: ftp.iij.ad.jp
 * extras: ftp.iij.ad.jp
Setting up Install Process
Resolving Dependencies
--> Running transaction check
...
Installed:
  wakame-vnet.noarch 0:20131108190022git48a1361.fpm0-1

Dependency Installed:
  dash.x86_64 0:0.5.5.1-4.el6
  dracut.noarch 0:004-335.el6
  dracut-kernel.noarch 0:004-335.el6
  file.x86_64 0:5.04-15.el6
  grubby.x86_64 0:7.0.15-5.el6
  kernel.x86_64 0:2.6.32-431.el6
  kmod-openvswitch.x86_64 0:1.10.0-1.el6
  libdrm.x86_64 0:2.4.45-2.el6
  libpcap.x86_64 14:1.4.0-1.20130826git2dbcaa1.el6
  libpcap-devel.x86_64 14:1.4.0-1.20130826git2dbcaa1.el6
  libpciaccess.x86_64 0:0.13.1-2.el6
  libxslt.x86_64 0:1.1.26-2.el6_3.1
  libyaml.x86_64 0:0.1.3-1.el6
  mysql.x86_64 0:5.1.71-1.el6
  mysql-server.x86_64 0:5.1.71-1.el6
  openpgm.x86_64 0:5.1.118-3.el6
  openvswitch.x86_64 0:1.10.0-1
  perl.x86_64 4:5.10.1-136.el6
  perl-DBD-MySQL.x86_64 0:4.013-3.el6
  perl-DBI.x86_64 0:1.609-4.el6
  perl-Module-Pluggable.x86_64 1:3.90-136.el6
  perl-Pod-Escapes.x86_64 1:1.04-136.el6
  perl-Pod-Simple.x86_64 1:3.13-136.el6
  perl-libs.x86_64 4:5.10.1-136.el6
  perl-version.x86_64 3:0.77-136.el6
  plymouth.x86_64 0:0.8.3-27.el6.centos
  plymouth-core-libs.x86_64 0:0.8.3-27.el6.centos
  plymouth-scripts.x86_64 0:0.8.3-27.el6.centos
  redis.x86_64 0:2.4.10-1.el6
  tar.x86_64 2:1.23-11.el6
  wakame-vnet-common.noarch 0:20131108190022git48a1361.fpm0-1
  wakame-vnet-ruby.x86_64 0:2.0.0.247.axsh0-1
  wakame-vnet-vna.noarch 0:20131108190022git48a1361.fpm0-1
  wakame-vnet-vnmgr.noarch 0:20131108190022git48a1361.fpm0-1
  wakame-vnet-webapi.noarch 0:20131108190022git48a1361.fpm0-1
  which.x86_64 0:2.19-6.el6
  zeromq.x86_64 0:2.2.0-4.el6
  zeromq-devel.x86_64 0:2.2.0-4.el6

Complete!
 ---> f4585f3b20de
Successfully built f4585f3b20de
ビルドされたイメージの内容を確認
$ sudo docker images openvnet.common
REPOSITORY          TAG                 IMAGE ID            CREATED              SIZE
openvnet.common     latest              f4585f3b20de        About a minute ago   632.1 MB (virtual 1.219 GB)

ここまでに1.219 GB使用。

3: openvnet.smallci
openvnet.smallci/Dockerfileを配置
FROM openvnet.common

ADD ./initdb.sh /initdb.sh
CMD /initdb.sh
openvnet.smallci/init.shを配置
#!/bin/bash
#
# requires:
#  bash
#
set -e
set -x

[ -f /etc/sysconfig/network ] || : > /etc/sysconfig/network
/etc/init.d/mysqld start

until mysqladmin -uroot ping; do
  sleep 1
done
mysqladmin -uroot create vnet

cd /opt/axsh/wakame-vnet/vnet
PATH=/opt/axsh/wakame-vnet/ruby/bin:$PATH /opt/axsh/wakame-vnet/ruby/bin/bundle exec rake db:init

実行権限を付与。

$ chmod +x init.sh
イメージをビルド
$ sudo docker build -t openvnet.smallci .
Uploading context 10240 bytes
Step 1 : FROM openvnet.common
 ---> f4585f3b20de
Step 2 : CMD : > /etc/sysconfig/network
 ---> Running in 885a743efd17
 ---> ce5389ddeb69
Step 3 : CMD /etc/init.d/mysqld start
 ---> Running in e6049c2aeaeb
 ---> 6957beeae0cd
Step 4 : CMD export PATH=/opt/axsh/wakame-vnet/ruby/bin:$PATH
 ---> Running in 7743b6dd88f1
 ---> c78f8c15a74d
Step 5 : CMD printenv PATH
 ---> Running in e76ba9bc75bb
 ---> f412fdc6fa00
Step 6 : CMD mysqladmin -uroot create vnet
 ---> Running in 6a5fea2907ca
 ---> eeb6f5b51fac
Step 7 : CMD cd /opt/axsh/wakame-vnet/vnet && /opt/axsh/wakame-vnet/ruby/bin/bundle exec rake db:init
 ---> Running in c7415047c846
 ---> 7a7db5249aa5
Successfully built 7a7db5249aa5
ビルドされたイメージの内容を確認
$ sudo docker images openvnet.smallci
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
openvnet.smallci    latest              6f6e46b2dbb9        25 minutes ago      1.192 GB (virtual 2.411 GB)

ここまでに2.411 GB使用。パッケージインストールするだけで、ディスクサイズが2.5GB弱必要である事が分かった。インストールしましたエントリでは触れられてない事の1つ。

コンテナを起動
$ sudo docker run -t openvnet.smallci
+ '[' -f /etc/sysconfig/network ']'
+ :
+ /etc/init.d/mysqld start
Initializing MySQL database:  Installing MySQL system tables...
OK
Filling help tables...
OK

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h 02b537893292 password 'new-password'

Alternatively you can run:
/usr/bin/mysql_secure_installation

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the manual for more instructions.

You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd /usr/mysql-test ; perl mysql-test-run.pl

Please report any problems with the /usr/bin/mysqlbug script!

[  OK  ]
Starting mysqld:  [  OK  ]
+ mysqladmin -uroot ping
mysqld is alive
+ mysqladmin -uroot create vnet
+ cd /opt/axsh/wakame-vnet/vnet
+ PATH=/opt/axsh/wakame-vnet/ruby/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ /opt/axsh/wakame-vnet/ruby/bin/bundle exec rake db:init

$ echo $?
0

DB初期化する所までは動作を確認できた。しかも、CentOS-6.5で!

まとめ
  • パッケージインストール程度ならばDockerで検証可能
  • OpenVNetはCentOS 6.5で動作しそう
  • DB初期化するまでとは言え、ディスクサイズは2.5GB弱使用する
あとがき

その先のOpen vSwitchやOpenFlowを使う構成になると、Dockerで検証できるかどうかは未知の世界。検証した結果、Dockerでは検証出来なかった。そんな結果になるかも知れない。そう言う時こそ、Wakame-vdcの出番。見事に繋がった?

参考文献



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