木曜日, 6月 16, 2016

doocker-machine bridge-network && HDDマウント

bridgenetwork周りについて

windows上でdocker動かすときって、以下の選択肢があると思ってて、

  • docker-machineとかでcreate(旧boot2docker(core linux?だっけ中身)) docker-machine create --driver=virtualbox
  • 使い慣れたVM状にdocker環境を構築、docker-machine create --driver=(不明)
私は汎用的に使える環境であることが好きだなぁ。と思ったので、docker-machine側でVMを用意する方式をとっていました。
が、この方式でbridge-networkを構築すると証明書が違う!という理由でdocker-machine env接続情報が取得できず、エラーで困ったことになることが多い。

理由としては、NIC起動順番が異なってしまて、docker-machine env でうまく接続できていないっぽい。
いろいろ不便だったので試行錯誤してみた(ホストVMのIPは環境切り替える際に不便なのでやりたくない)

結果として、以下の感じのコマンドでbridge-networkを追加するだけ。。。
GUI側でやってるのと何ら変わらないのだけど、なんでこっちだとうまくいくんでしょうかね。


vboxmanage  modifyvm default --nic3 bridged
vboxmanage modifyvm default --bridgeadapter3 "en3"
vboxmanage modifyvm dev --nic3 bridged
vboxmanage modifyvm dev --bridgeadapter3 "en3"

HDDマウントについて

あと、以下のような形でマウントすると、ホストマシンのサイズ依存となってしまう。
vboxmanage sharedfolder add 'dev'      -automount -name 'Volumes'  -hostpath '/Volumes/';
sudo vi /var/lib/boot2docker/bootlocal.sh
sudo mkdir -p /Volumes;
sudo mount -t vboxsf Volumes  /Volumes/  -o uid=1000,gid=100,iocharset=utf8;

なので、この場合は、一つずつ、ディスクをマウントさせましょう。
vboxmanage sharedfolder add 'default'  -automount -name '3tv1'  -hostpath '/Volumes/3tv1';
sudo vi /var/lib/boot2docker/bootlocal.sh
sudo mkdir -p /Volumes/3tv1;
sudo mount -t vboxsf 3tv1  /Volumes/3tv1  -o uid=1000,gid=100,iocharset=utf8;

samba経由でwindows backupするときに気づいた。
/Volumesだけだと、ホストVMの/ディスクのみのサイズしか見ないので、結果的にトンでもねーことになっちまいます。

電車、、、間違えて遅刻しそうかひやひやしながら書いています。

水曜日, 6月 01, 2016

Jenkinsで何かする事になった。

テキストベースでまとまったから、一旦公開。

会社の社員総会で話をすることになった。

当初は仮想技術について準仮想化、コンテナ技術で話をしようとしていた。
けども、どっちも説明すると「こいつ一体何が言いたいんだ。」ってことになるので、コンテナ技術の実践をやろうと思ったのだけど。

まだ、プロジェクトで利用することはなさそう。(まぁ、何故かいつも唐突に決まることが多いのだけど)
そうなると興味も半減しますね。何かいい案はありませんか?と。

「CIなら興味があるんじゃないか?」ってことで、じゃあ、テーマ変更と相成りました。

アプリ開発から離れて久しくすでにやりかたなんて忘れた。
しかしながら、今回はデプロイにフォーカスを絞ったほうがいいと判断しアプリのデプロイつまり、APKを作ったりすることだね!

Eclipseでやる方法はすごい多いけど、AndroidStudioで作ったのってまだあまり見ないな。ってことで、ブログに書き留めつつ、AndroidStudioのプロジェクトをJenkinsでAPK作成するところまでをやろうかと。

主だった話は、JenkinsとGradleプロジェクトについての話になるんだろうけどね。

サンプルプロジェクトに独自ライブラリ、Google純正ライブラリとかを使ったものをテスト、APK作成までがきっとゴールになるんだろうな。

環境としては、以下を想定
Docker + Jenkins + Java 7(Oracle) + Ruby製のGCM通知 + コンテナ用リポジトリ
あっ。Ruby製のGCM通知プログラムもテスト書いておかなきゃならんのか。(卵が先か鶏が先か。)

JenkinsでサンプルプルプロジェクトAPK作成まで頑張る。
Jenkinsで、テストも自動化まで頑張る。
そのあとサンプルプロジェクトにライブラリを追加して、簡易的なものを実装、テストも書いて、正しく動くまで頑張る。
GCM通知プログラムとして申請を出す。
Ruby製のGCM通知プログラムを書く。
Ruby製のGCM通知プログラムのテストも自動化する。
コンテナのリポジトリは、、、、公開しないと会社のマシンでひいひいいわないといけないから公開。

んー、発表が6月の2x日だって話だったから、6日か。
ツーリングにも行きたいので、3日でまとめられる内容ということを考えると。
Ruby製のGCM通知を削ろう。
Docker + Jenkins + Java 7(Oracle) + コンテナ用リポジトリ

スマホでググったら普通にやっている人見つけたし。
http://qiita.com/usamao/items/93535df778916ee70ad8

少し余裕過ぎるな。面白い要素を加えねば

最悪会社の資産乗っていないし、外部公開で自宅に立てればいいし。

こんあところか。全然新しくもないな。。。まぁ、頑張ろっと。