改善

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)

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)

2011年09月12日

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

参考比較: 単発curl v.s. 100分割curl

参考値とは言え、約21倍性能が増した。

内容所要時間
単発2,226秒
100分割103秒

ネットワーク帯域や検証マシンスペックによっては、もっと顕著な差が生まれるかも知れない。

検証内容
単発curl
$ time curl -s -L -o textinstall-134-x86.iso http://dlc.sun.com/osol/install/downloads/text_install/134/textinstall-134-x86.iso

real    37m6.561s
user    0m1.216s
sys     0m45.667s
100分割curl
$ time ./pararell-curl.sh http://dlc.sun.com/osol/install/downloads/text_install/134/textinstall-134-x86.iso
...(省略)...

real    1m43.885s
user    0m3.576s
sys     0m32.038s
検証環境
  • Ubuntu 10.04.3 LTS
  • bash 4.1.5
  • curl 7.19.7
レシピ
  1. 何並列で実行するのか決めておく。今回は100本。
  2. ダウンロード対象のContent-Length取得
  3. Content-Length値をもとに、curlコマンドの --range オプション でcurlコマンド毎に担当範囲を指定し、バックグラウンドジョブとして実行。

    man curlより

           -r/--range 
                  (HTTP/FTP/SFTP/FILE)  Retrieve a byte range (i.e a partial docu‐
                  ment) from a HTTP/1.1, FTP or  SFTP  server  or  a  local  FILE.
                  Ranges can be specified in a number of ways.
    
                  0-499     specifies the first 500 bytes
    
                  500-999   specifies the second 500 bytes
    
                  -500      specifies the last 500 bytes
    
                  9500-     specifies the bytes from offset 9500 and forward
    
                  0-0,-1    specifies the first and last byte only(*)(H)
    
                  500-700,600-799
                            specifies 300 bytes from offset 500(H)
    
                  100-199,500-599
                            specifies two separate 100-byte ranges(*)(H)
    
  4. 全ジョブが完了するまで待機
  5. 分割ダウンロードされたファイルを結合
ソースコード

レシピをもとにラッパースクリプトを作成。

使い方

第一引数を指定しない場合、CentOS 6.0のISOイメージがダウンロード対象となる。

$ git clone git://gist.github.com/1205668.git
$ ./pararell-curl.sh
$ ./pararell-curl.sh http://mirror.3tier.com/centos/6/isos/i386/CentOS-6.0-i386-bin-DVD.iso
参考文献
あと書き

分割によってこれほどの性能差が生まれるとは思っても見なかった。

続きを読む


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

2011年08月13日

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

サーバを新調する度に幾つものコマンドを実行するのか?

新プロジェクトが発足する度に開発環境が用意される事は、良くあるはずだ。 そして、その度に、使い慣れた環境へと変身させる作業が発生するはずだ。 中には何も設定しない人も居るのだろうか? 何も無い環境だと、どうしても作業し辛い。その要因の大半は、いつもの使い慣れた環境とは違うからだ。

数年前、CodeReposdotfilesとして個人環境設定を登録する流れが発生した。この流れに自分も少し乗っかり、emacsの設定をコミットしてみた。 使い慣れた環境の設定を登録しているだけだったので、その時には気付いていない、新規調達サーバ・開発環境をリプレースした際、素早く環境整理する仕掛けまでは用意していない自分が居た事に。

きっかけは開発環境の移行

Wakame-VDCの開発をアメリカからしてる時の事。アメリカの通信回線の細さに対し次第にストレスを感じ始める。Wakame-VDCの開発環境は、東京事務所内に置いてある物理サーバを使っていたのだ。これまでの開発スタイルは、

  • 開発サーバへSSH接続してログイン
  • emacsでプログラムを書く
  • コマンドラインでコンポーネントを起動・停止

これをアメリカから行っていると、日本の10年以上前のダイアルアップ接続をしていた頃の様な速度になる時がある。YouTubeで動画を見たり、OSのインストールイメージをダウンロードしている時だ。東京に居たら考えられない事が、アメリカの通信事情では起こり得る。

通信状況に不満を覚えた自分は、『手元のラップトップに開発環境を構築してしまえば解消するはずだ。』 そう思い、開発環境移行に着手した。開発に必要となるOSは2つで、UbuntuOpenSolaris。 Windows 7にインストールしたVirtualBoxで仮想マシンを用意し、2つのOSをインストール。ここまでは実に順調だ。しかし、この後だ。開発環境整理が待ち受けていた訳だ。

  1. GitHubにdotfilesを作成、コミット
  2. dotfileをデプロイする仕掛け・・・が無い
  3. デプロイする仕掛けをシェルスクリプトで作り始めた

これらが、スクリプト作成に着手するまでに至る過程だ。

異なるOS、異なるユーザー名に対応させる

OSが2種類あり、作業するUNIXユーザー名も違う。いつも同じユーザー名を使えるとは限らない。 汎用性を重要視し、下記3つの事に注意してスクリプトを書き上げ、Gistに登録した。(※スクリプトのソースコードは、エントリ後半に埋め込んである。)

  • OSに依存しない事
  • ユーザー名に依存しない事
  • ファイルシステムのフルパスに依存しない事

スクリプトを実行しさえすれば、使い慣れた環境の一歩手前、必要最低限の環境が手に入る。 一歩手前なのかは、アプリケーションインストールまでを行わないからだ。

スクリプト化した事により、新環境へ移行せざるを得ない状況になっても一撃必殺で作業が終わる。 細かい制約を挙げると、事前にGitをインストールしておく必要がある訳だが…大した問題ではない。 スクリプト化後は、大幅に作業工数が減った。

ギーク達がどのように個人的開発環境を新規構築しているのかが気になる。 『開発環境構築手順を晒すブーム』が到来してくれないだろうか?

あと書き
変化を好機と位置づけ、それを楽しめ
個人的な環境を構築するスクリプト

この環境は個人使用に特化しているので、万人が使って幸せになれる訳ではない。

詳解 シェルスクリプト
Arnold Robbins Nelson H. F. Beebe
オライリージャパン
売り上げランキング: 95612



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

2008年09月26日

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

ログインすると何が良いのかが書かれていない


ログインページを改善してみた。

以前までは
  • 認証にlivedoor Authを使っている事
  • livedoor Authへのリンク
果たしてログインしたら何が良いのか?
それが書かれていない事に気づいた。



何が書かれているべきか


自問自答。
  • ログイン後に可能となる事は何か
  • 何を出来るようになるのか
  • それをしたら何が嬉しいのか
それぞれ考えてページに反映させてみた。

ただ作っているだけだと忘れがちな事が多々ある。
時には何も知らないユーザーの立場になってみるのが大切だね。



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