2014年12月16日

#WakameVdc / #OpenVNet 開発環境の改善履歴

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

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を探す旅に出ます。





2014年12月13日

#WakameVdc / #OpenVNet のCI/CDを支える #JenkinsCI クラスタ

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

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』と呼んでいる。




2014年12月09日

#WakameVdc 開発フローと、CI環境の裏側の一部

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

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年半。(他作業を掛け持ちしながら)

あとがき

一度動いてしまえば、あとは継続的改善。




2014年12月06日

#WakameVdc / #OpenVNet 開発環境のアカウント管理改善

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

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アカウントを持っているからこそ可能な事。




2014年02月26日

Vagrant-VirtualBoxにおける応用設定 - シリアルポート有効・無効

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

実は初のVagrant Boxエントリ

logo_vagrant-81478652

Vagrant Box生活してる人にだけ伝わればよい。そんな内容。更に限定すると、Vagrant-VirtualBoxの組み合せで生活をしていて、vagrant packageやPackerを使わずにVagrant Boxをbuildするような内容の濃い生活をしてる人。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
設定項目(VirtualBox)
  • Serial Port: 1つ有効化
/var/log/messagesに出続けるメッセージ

余りにも最小設定・最小構成すぎて、syslogにガンガン書き込まれていた。

Feb 26 00:12:49 vagrant-centos6 init: tty (/dev/ttyS0) main process (2952) terminated with status 1
Feb 26 00:12:49 vagrant-centos6 init: tty (/dev/ttyS0) main process ended, respawning
Feb 26 00:12:49 vagrant-centos6 /sbin/mingetty[2953]: ttyS0: not a tty

このメッセージが出てる原因は、/dev/ttyS0は存在するけども、デバイスとして認識されてない事。VMの構成要素にシリアルポートを追加し忘れていた。

box.ovfを修正

box名によってbox.ovfのファイルパスは異なる。

  • ~/.vagrant.d/boxes/${name}/virtualbox/box.ovf
修正前
        <UART>
          <Port slot="0" enabled="false" IOBase="0x3f8" IRQ="4" hostMode="Disconnected"/>
          <Port slot="1" enabled="false" IOBase="0x2f8" IRQ="3" hostMode="Disconnected"/>
        </UART>
修正後: slot="0" を enabled="true" へ
        <UART>
          <Port slot="0" enabled="true" IOBase="0x3f8" IRQ="4" hostMode="Disconnected"/>
          <Port slot="1" enabled="false" IOBase="0x2f8" IRQ="3" hostMode="Disconnected"/>
        </UART>

vagrant reloadかvagrant upによりシリアルポートが1つ追加された構成でVMが起動する。

あとがき

本エントリではbox.ovfによる修正を行ったけども、Vagrantfileから有効化・無効化する方法もある。その場合は、VBoxManageのmodifyvmコマンドに指定するオプションを知っている必要がある。最終的には、VagrantBoxとVagrantfile、どちらで指定するのかなどプロジェクト単位における構成管理方針次第か。provider固有設定する必要がある限りは、存在し続ける悩ましい課題の1つ。

Links



半袖 at 15:30|PermalinkComments(0)TrackBack(0)hacks/Vagrant 

2014年02月22日

Vagrant-VirtualBoxにおける基本設定Vagrantfile - 複数内部ネットワーク・NICグループ化

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

bondingを検証したい

logo_vagrant-81478652

bondingを3セット、そんな検証環境が欲しかった。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
設定項目
  • NIC枚数: 7(6枚追加)
  • インターナルネットワーク: 3本
Vagrantfile

bondingインターフェースとスレーブインターフェースの構成。

  • bond0
    • eth1
    • eth2
  • bond1
    • eth3
    • eth4
  • bond2
    • eth5
    • eth6
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos-6-x86_64"

  config.vm.provider :virtualbox do |v, override|
    config.vm.synced_folder ".", "/vagrant", disabled: true

    # bond0: eth1, eth2
    v.customize ["modifyvm", :id, "--nic2",   "intnet"]
    v.customize ["modifyvm", :id, "--nic3",   "intnet"]
    v.customize ["modifyvm", :id, "--intnet2", "bond0"]
    v.customize ["modifyvm", :id, "--intnet3", "bond0"]
    # bond1: eth3, eth4
    v.customize ["modifyvm", :id, "--nic4",   "intnet"]
    v.customize ["modifyvm", :id, "--nic5",   "intnet"]
    v.customize ["modifyvm", :id, "--intnet4", "bond1"]
    v.customize ["modifyvm", :id, "--intnet5", "bond1"]
    # bond2: eth5, eth6
    v.customize ["modifyvm", :id, "--nic6",   "intnet"]
    v.customize ["modifyvm", :id, "--nic7",   "intnet"]
    v.customize ["modifyvm", :id, "--intnet6", "bond2"]
    v.customize ["modifyvm", :id, "--intnet7", "bond2"]
  end
end

ここで注目したいのは、単にintnetを追加するだけでなく、bondingペア毎にintnetを構成してる事。--intnetXで指定しない場合は、VirtualBoxは全て "intnet" としてインターネットワークを構成する。

あとがき

もはやVBoxManageコマンドを相当意識しないと細かな設定を行えない。

Links



半袖 at 13:00|PermalinkComments(0)TrackBack(0)hacks/Vagrant 

2014年02月13日

Docker Meetup in Tokyo #1 / DockerのNetwork周りについて話して来た

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

イベント
Docker Meetup in Tokyo #1
日付
2014/02/12(水) 19:00〜21:00
場所
国立情報学研究所
天気
晴れ
概要
発表後記
  • 開始直後の会場アンケート、30人強のうち、ICCを知ってるのは、たった1人!マジか
  • ↑な状況で話を進めたので、何だか会場全体を置き去りにしてる感
  • しかし、この発表をきっかけにICCを使う人が増え、情報共有・検証報告が増えたら、それは成功と言える。
  • 身近な数人からは『むしろ突き抜けてて良かった。』との言葉を頂けた。
  • ICCに関わらず、Dockerのネットワーク周辺を触ってる人は少数派だと言う事を実感。



半袖 at 14:00|PermalinkComments(0)TrackBack(0)hacks/Docker 

2014年01月31日

/etc/yum/vars/releasever ファイルでリリースバージョンを固定する

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

次のマイナーバージョンがリリースされた事により、困った事は無いだろうか?

少し前の事だが、CentOSが6.5がリリースされた。何も気にせずにyum updateすると、6.5へ・・・・。検証等の理由あって手元の環境は6.4を維持しておきたい事がある。さて、この状況をどうやって回避するのか。その手段の1つが、/etc/yum/vars/releaseverファイルによる固定。

検証環境
  • CentOS 6.4
  • kernel-2.6.32-358.el6.x86_64
  • yum-3.2.29-40.el6.centos.noarch
手順は/etc/yum/vars/releaseverを作成するだけ
  1. /etc/yum/vars/releasever を作成
  2. ファイルの中身は、固定化したいバージョン
例: 6.4 固定化
/etc/yum/vars/releasever を作成
$ sudo $SHELL -c "echo 6.4 > /etc/yum/vars/releasever"
中身を確認
$ cat /etc/yum/vars/releasever
6.4
考察

例えばCentOSであれば、/etc/yum.repos.d/CentOS-Base.repo を修正し、 $releasever を特定バージョンに固定化する手段がある。しかし、これはCentOSに限定される。 /etc/yum/vars/releaseverファイルの場合、特定ディストリビューションに依存しせず、固定が可能である事。RHELであろうがCentOSだろうがScientificLinuxであろうが、幅広く利用可能である事。

あとがき

1つ前のリリースバージョンのパッケージが、ミラーサイトから徐々に消えて行くのは、どうしたものか。

Links



2014年01月29日

Vagrantにおける基本設定Vagrantfile - IPアドレス無しeth1を追加する

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

bridgeインターフェースを追加する時は特にIPアドレスは不要

logo_vagrant-81478652

2枚目のNICを追加し、bridgeインターフェースを作成した環境で検証したい。そうした場合、private_networkに属したNICを追加すれば良いのだが、IPが必須パラメタとなっている。そんな場面の回避策。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
  • VMware Workstation 10.0.1 build-1379776
設定項目
  • NIC枚数: 2
  • config.vm.network "private_network", ip: "0.0.0.0"
Vagrantfile

特定provider非依存パラメタであるので、virtualboxであろうがvmwareであろうが、有効設定。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos-6-x86_64"

  config.vm.network "private_network", ip: "0.0.0.0"
end

キモは、 0.0.0.0。

前述した通り、IPは必須パラメタなのである。仮に省略した場合はエラーとなる。これは後ほど触れる。8割り以上の設定では、NICとIPアドレスが対となる構成なのだろうけども、bridgeインターフェースを作成したい場合は、邪魔である。

参考までに、IPアドレス指定しない場合

前述のVagrantfileとは違い、ip: "0.0.0.0"を指定しない場合。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos-6-x86_64"

  config.vm.network "private_network"
end
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* An IP is required for a private network.

実行結果により、private_network指定の場合、IPは必須パラメタである事が分かる。

あとがき

『IPアドレス設定は、provisioner任せにした方が良さそうだ。』と言うのが、これまでのVagrant生活の経験則として落ち着いて来た。

Links



半袖 at 15:00|PermalinkComments(0)TrackBack(0)hacks/Vagrant 

Vagrantにおける基本設定Vagrantfile - shared folderを無効化

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

shared folder不要な場合もある

logo_vagrant-81478652

例えばshared folder非依存な場合がある。そんな時はshared folder機能を無効化しておく事により、起動時間を短縮可能だ。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
  • VMware Workstation 10.0.1 build-1379776
設定項目
  • config.vm.synced_folder: disabled: true
Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos-6-x86_64"

  config.vm.synced_folder ".", "/vagrant", disabled: true
end

特定provider非依存パラメタであるので、virtualboxであろうがvmwareであろうが、有効設定。また、provider毎に有効・無効する事も可能。今の所、shared folderを使う場面に遭遇した事が無いので、個人環境では基本的に無効化している。

あとがき

本エントリでは無効化する話が主題だけども、本来はマウントポイント変更(/vagrant -> /path/to/mnt)する使い方が多いのだろう。

Links



半袖 at 14:00|PermalinkComments(0)TrackBack(0)hacks/Vagrant