CentOS6.7にてgolang-1.5.1-0を使用してdocker-machine.exeをビルドする。docker-io-1.7.1-2.el6.x86_64を使用

docker-machine.exeをwindowsでビルドする環境を整える事は少々難がある。
具体的には開発環境用のVisualStudio等をインストールする必要がある訳だが、古い開発環境を今も使わざるを得ないというケースもあるだろう。
docker-machine.exeの為だけに既存の開発環境を変えてしまうのは抵抗があるだろう。

こうした場合はCentOS6.7で用意してしまうのが容易でいい。
epelにgolangがあるのでこれを利用する。
基本、CONTRIBUTING.mdに書いてある通りだが、どの様な環境でビルドすれば良いかは書かれていないのでまとめた。
(docker-machine.exeを必要とする事例は度々ある様だ。）

epelを利用するので、以下の環境となる。
golang-1.5.1-0.el6.x86_64
docker-io-1.7.1-2.el6.x86_64
centos-release-6-7.el6.centos.12.3.x86_64

Dockerオフィシャルのjenkinsコンテナイメージにjenkinsのテストを含める方法

jenkinsのDockerオフィシャルイメージでは、jenkins上で作成したテストがホスト側に保存される仕組みとなっている。
個人でDocker上のjenkinsを使う場合は不都合ない。
しかし、jenkins上で作成したテストも含めてコンテナイメージとして外部へ保存するには不便な仕様となってしまっている。
つまり、テストのファイルは個別にコピーする必要がある。
Docker pullでjenkinsのテストも含めた形でコンテナを起動できると利便性が高い。

DockerfileでVOLUMEの指定を外すだけで、コンテナイメージにテストが含まれる。
こちらに作成した、Dockerfileからコンテナイメージを作る事で利用できます。
（とはいえ、15行のVOLUME /var/jenkins_homeをコメントアウトしただけ。）
手順としては以下の通り。
１）docker buildしてコンテナイメージを作成する。
２）jenkisコンテナ上でテストを作成して、docker commitすればjenkinsのテストを保存できる。
３）このコンテナイメージをdocker registry等にpushする事で、他のdockerからdocker pullするだけでテスト環境が整う。

もちろん、docker hubにテストを含めたコンテナイメージを配置する場合は注意してほしい。
自己責任でお願いします。

なお、jenkinsのテスト項目はどの様な形式で保存されているかは次の書籍にある。
2012年3月6日発行　初版第2刷発行 john Fergusom Smart （著） Sky株式会社 玉川 竜司 （翻訳） P343
13.4.1 Jenkinsのバックアップの基礎
$JENKINS_HOME/var　展開されたWARファイル
$JENKINS_HOME/cashe ダウンロードされたツール
$JENKINS_HOME/tools 展開されたツール

jenkinsはcommitする前にjobを止めた方が精神衛生的にはいい気がします。

kitematic(Beta) Version 0.7.6(MacOS)でipアドレスを追加する

kitematicを通常起動した場合、kitematicを起動したPCが持つIPアドレスしか利用されない。
すなわち、VirtualBoxから割り当てられたIPアドレスしか利用できない。
これは安全ではあるが、若干不便な仕様ではある。
（NAT設定の仕様）
そこで、VirtualBox上でIPアドレスを任意に付け足す。
ただ付け足すだけではkitematicから利用できない。
そこで証明書の再作成を実行する。
IPアドレスを複数設定する事自体は可能だ。
なお、この操作はMac OS X 10.5.5 Yosemite上のkitematic(Beta) Version 0.7.6で動作を確認した。
VirtualBOXは 5.0.2 r102096を利用している。

注意事項としては、既に、docker-machine上でコンテナを起動させてしまっていたら、なんらかの方法で退避する事をおすすめする。

自己責任でお願いしたい。
最低限、以下の作業の前にはコンテナを一旦停止して実行した方がいい。

具体的な手順としては以下になる。
まず普通にkitematicを起動する。

この操作は既にVirtualBoxからdevというVMが作られていれば不要。
メニューバーからQuitを選択してkitematicを一旦終了する。

VirtualBoxのメニューからdevというVMが起動されている事を確認する。
このVirtualBox上のVMの内部でdockerが起動している。
このdevというVMにNICを追加する為一旦停止する。

ここではVirtualBox上の4番目のNICを追加する。

他のホストからアクセスする事を目的としているのでプロミスキャスモードは全て許可としている。
追加後、停止したVMはそのままにして、kitematicを起動する。
kitematic起動後、エラーが表示される。

このエラーを回避する為、kitematicに内包されている、docker-machineを利用して、証明書を作り直す。
一旦、kitematicは終了する。
理解しやすさを優先させてエラー画面を見せているだけで必要な動作ではない。
コマンドとしては以下のようにregenerate-certsを実行する。
（ちなみにkitematicのソースを見ると異なるコマンドがかかれていて、気持ちがわるい。他の箇所から呼ばれていなく未使用コードなのでPRを出しにくくもある。）
https://github.com/docker/kitematic/blob/master/src/utils/DockerMachineUtil.js#L84-L86

./Kitematic\ \(Beta\).app/Contents/Resources/resources/docker-machine regenerate-certs -f dev

Macの場合、コマンドライン上からパッケージ内部に内包されているdocker-machineでも実行できる。
devとしてVMの名称を指定する。
最後の-fオプションはTSL証明書の強制的な上書きとなる。
regenerate-certsはVMが起動していないと実行できない。
証明書作成後は一旦VMも終了させる。
dhcpサーバがあれば、あとはkitematicを通常起動するだけで、IPアドレスが追加された状態で起動できる。
docker-machineが用意するIPアドレスとは別にNICの4番に割り振ったのIPアドレスからもdocker上で立ち上げた各種サービスも利用できる。
無線LANを使ってiphone等からMac上のkitematicで作成したコンテンツ等を閲覧するといった用途に向いている。

ネットワーク環境により（例えばアドレスクラスCが既に利用されている場合など）上記の様に意図した動作しないケースもあるので留意していただきたい。