docker imageを外部で保持する
cut-ter.hatenablog.com ↑のサイトでnfsを用いて外部に保持するところまでやったので，今回は実際に動かすところまでやります．
挫折
とりあえずdocker runするかってことで，ubuntuを立ち上げようとしたところ下記のようなエラーが．
docker: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/d9f6368b43e592400902de3ca7f07a6f2abc69655ba9e6b0c3770df22f9661c9-init/merged: invalid argument.
調べてみたところ，↓のような記事が．これによると，ext4にすると治ったとのことでファイルシステム系がダメなんやなって感じですね． github.com
まぁnfsでマウントしてきたのをさらにマウントするのは，ちょっと無理がありましたね．ということで別の方策を考えていきます．
iSCSI
iSCSIだったら，自由にマウントするファイルシステム選べるし，ディスクレベルのマウントなのでいけるやろってことで試していきます．
ホストの設定
sudo apt-get install -y iscsitarget sudo vim /etc/default/iscsitarget
false をtrueに書き換える
ISCSITARGET_ENABLE=true ISCSITARGET_MAX_SLEEP=3 # ietd options # See ietd(8) for details ISCSITARGET_OPTIONS=""
sudo mkdir /var/lib/iscsi sudo dd if=/dev/zero of=/var/lib/iscsi/iscsi.img count=0 bs=1 seek=100G sudo vim /etc/iet/ietd.conf
末尾に追加
Target iqn.2016-05.net.my:iscsi.img Lun 0 Path=/var/lib/iscsi/iscsi.img,Type=fileio
sudo service iscsitarget restart
クライアントの設定
sudo apt-get install open-iscsi sudo iscsiadm -m node --targetname iqn.2016-05.net.my:iscsi.img --login sudo apt-get install lsscsi
lsscsiでどこにマウントされてるのかわかるようになります．
cut-ter@ubuntu:~$ lsscsi [1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0 [2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda [3:0:0:0] disk IET VIRTUAL-DISK 0 /dev/sdb
ってことで今回は/dev/sdbにマウントされます．
sudo parted --script /dev/sdb "mklabel msdos" sudo parted --script /dev/sdb "mkpart primary 0% 100%" sudo mkfs.ext4 /dev/sdb1
↑のようにパーティション作成してiSCSIの設定は完了です．
調査
とりあえずoverlay2のなかにlディレクトリがあるので動かして，マウントしたりします．
mv overlay2/l/ ~ mount /dev/sdb1 /var/lib/docker/overlay2/ mv ~/l/ /var/lib/docker/overlay2/
docker pull ubuntu して容量がどんな感じになるか試します．
前
root@ubuntu:/var/lib/docker# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489692 0 489692 0% /dev tmpfs 101612 4560 97052 5% /run /dev/sda1 15349744 1861256 12685724 13% / tmpfs 508060 0 508060 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508060 0 508060 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 /dev/sdb1 103080224 61044 97759968 1% /var/lib/docker/overlay2
後
root@ubuntu:/var/lib/docker# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489692 0 489692 0% /dev tmpfs 101612 4560 97052 5% /run /dev/sda1 15349744 1861748 12685232 13% / tmpfs 508060 0 508060 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508060 0 508060 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 /dev/sdb1 103080224 194452 97626560 1% /var/lib/docker/overlay2
ってことで大部分が/dev/sdb1 に保存されてることが確認できました．ここまでは前回と変わらないので今回はdockerでubuntuを動かして，比較的重そうなlinuxのカーネルをgithubからプルしてこようと思います．
linuxのカーネルをプルした結果，↓ような感じになりました．結果としてはしっかりと動作中のイメージもマウント領域に保持されているようなので，これでどんなにファイルを追加したりとかしてもdockerホストの容量が足りなくなったりすることはなくなったかな．
root@ubuntu:/var/lib/docker/overlay2# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489692 0 489692 0% /dev tmpfs 101612 4636 96976 5% /run /dev/sda1 15349744 1862192 12684788 13% / tmpfs 508060 0 508060 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508060 0 508060 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 /dev/sdb1 103080224 3456468 94364544 4% /var/lib/docker/overlay2 overlay 103080224 3456468 94364544 4% /var/lib/docker/overlay2/3b2c4f03fe9743da169bde51725e0893942cb500bd725723ac08a3748ee1cffa/merged shm 65536 0 65536 0% /var/lib/docker/containers/d13f92d8cec61e79c5982435b73c591aa5a58dfbb2e6c586e253fb3591743eec/shm
とりあえずiSCSIでやれば，容量の対策はできそうなので研究室にNASが来た時に一度ちゃんと速度計測しようとおもいます．
Turtlebot3の組み立て
少し前にTurtlebot3というロボットを組み立てた時に，写真だけ撮って何もしてないので適当にまとめます．
Turtlebot とは
ROS（Robot Operating System）というロボット開発フレームワークで,開発プラットフォームとして使われているロボットです．
このロボットでmove_baseと言われる行動計画や，レーザーセンサによるslamなどが行えるます．それにより，障害物を避けながら移動するロボットを作成することができます．
まぁROSっていう便利なロボット開発ツールのデファクトスタンダード的なデバイスです．
開封式
Turtlebotには色々バージョンがあるのですが今回はTurtlebot3 burgerを組み立てます．
箱は↓みたいな感じです．
大きさ分かりづらいですが，右上に写ってるスマホと比べてもらえればまぁまぁ大きいのがわかると思います．
中には4つの箱と説明書とケーブルが入ってました．
中にはraspberry pi3とSDカードとかも入っているので，別途用意する必要があるものは特にありません．Turtlebot2まではノートPCを利用していたりしたのでだいぶ小さく進化したことがわかります．
説明書は日本語にも対応しており，とてもわかりやすいです．組み立て図等も比較的綺麗に描かれてるので特に迷うことなく組み立てることができます．でもネジの色と説明書のネジの色の白黒が全部逆になってることにだけ注意です．
ネジ類は細かく小袋に分かれており，それぞれにそれがどんなネジなのか細かく書いてあるので特に迷うことはないです．各ネジの予備が1-4本ずつくらいついてるのでなくしたりしても大丈夫です．
組み立て
1段目
2段目
3段目
完成品
ぐだぐだやりながら，1時間ちょっとくらいで組み立てることに成功しました．
結構ネジをきつく締めすぎると組み立てづらい部分がありました．しかしそこを緩めたままにすると最後にネジがポロポロ落ちてくるので，位置を決めたらしっかりネジを締めましょう．
こいつをちゃんと動かしたいなぁ．
最近使って便利だったりはまってるもの
このブログは↓のアドベントカレンダーの6日目です．
今日は適当に最近使い始めて便利だったりするツールだったりはまってることについて書いていこうと思います．
Not-My-Fault-俺のせいじゃない
- 出版社/メーカー: スパ帝国
- 発売日: 2017/06/10
- メディア: おもちゃ＆ホビー
- この商品を含むブログを見る
ゲームの要素として単純にプロジェクトを進めていくだけでなく，トランプゲームのダウトのような要素が入っています．
ダウトと違う要素として自分の数だけでなくそれまでの蓄積で判定されるという部分があったりします．
まぁちゃんと詳しく公式だったりが説明してくれてるのでリンクを貼っときます．
詳しくルール説明してあるやつ:
ゲーム紹介『Not My Fault! ~俺のせいじゃない!~』 : ニコボド | ニコのボードゲーム日記
bitzeny
最近bitzenyっていうコインが高騰してるので滅多面白いです．
1週間前あたりから価格を確認し始めたのですが，1週間前は0.5-1.5円くらいを上がり下がりしてる感じだったのですが，今日の朝確認してみたら驚愕の値段になってました．
20倍近くになってるんだが．．．．．
1週間のグラフを見てると綺麗な右肩上がりで面白い．
仮想通貨が急騰すると誰が最初に売り始めるかのチキンレースになってしまって辛い．冬のボーナスでみんな買い始めたのかよくわからんけど，年明け急落してみんな阿鼻叫喚になってたらおもしろいなー．
tmux
研究関連で結構長い時間ビルドしたりすることが増えたので使い始めたらマジで便利でした．
sshでつないでビルドが終わらなくてパソコン閉じられないとかいう状況になってたりしたのが，ssh切ってもサーバー側でtmuxのプロセスは動き続けてくれるのでビルド途切れたりしないのは本当に便利です．
サーバーでちょっと長い時間動かしておきたい処理とかも，わざわざデーモン起動しなくても動き続けてくれたりするし便利です．
あとsshは少しの間でもネット切れると通信が切断されますが，tmuxはネットが切れても復活すると通信を復元してくれたりして便利です．
ダラダラと紹介しましたが，今日はこれで終わりです．明日はytm_nです．
メモリテストとハード整理の続き
土曜日に研究室のタワーPC系の整理をしていたのですが，core 2 quadの2台のセットアップが終わってなかったのでそれの続きをやったり，PXEブートにメモリテストを追加したりしてました．
タワーPCの整理
結論から言うとcore 2 quadのPC2台はお亡くなりになりました．
正直原因がよくわからないのですが，インストトール途中に固まってそこから進まなくなってしまうとよく分からない状況になってしまいました．
最初は2GBしかメモリが載ってなかったのでメモリ不足かなとか思いましたが，正直2GBもメモリがのってればOSのインストールには十分だと思うんだけどなー．一応4GB載せてみたりしたけど結局死．
電源関連で死んでしまってるのかそもそもCPU系で死んでるのか，こういうPCのエラーの切り分けに慣れてないのでどうしたらいいかわからん．
まぁ渡す予定だった3年生には別の小型PCを割り当てることになったのでとりあえず奥の方に放置．
メモリテスト
今回6台くらいのPCのテストをしたときに思ったのは，USBで色々やるのめっちゃ面倒ってことでした．centosだったり，ubuntuだったり切り替えたりとかメモリテストだったり色々切り替えるのがクッソ面倒でした．
全部PXEブートでできたら楽だよなぁってことでメモリテストをPXEブートに追加したいなぁって感じでググったら↓がでてきました．
参考にして追加したらサクッと動いたのでメモリテストもいい感じに動く環境が研究室に整いました．
欲を言えばディスクチェックとかも自動化したいのでその辺もうちょい調べてみます．
あとはひたすらレポーヨを書く1日でした．レポーヨつらいよー
docker imageを外部で保持したい
昨日の記事（↓）の最後で機械学習系のイメージバカでかすぎるので，なんか外部で保持したいって書いたやつを調査してみます．
実際，機械学習系のイメージ馬鹿でかいし画像とかを，尋常じゃない量置いていくので容量がすぐ足りなくなります．それを解決するために，とりあえずイメージの実態がどこで保持されてるのか調べてみます．
調査
cut-ter@ubuntu:~$ sudo docker version Client: Version: 17.09.0-ce API version: 1.32 Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:42:18 2017 OS/Arch: linux/amd64 Server: Version: 17.09.0-ce API version: 1.32 (minimum version 1.12) Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:40:56 2017 OS/Arch: linux/amd64 Experimental: false
今回のdocker のバージョンは↑みたいな感じです．
とりあえず同じようなこと考えてないかなーって感じで検索かけた所↓
とりあえずバージョンが古いので同じようなディレクトリがあるか調べてみるために/var/lib/dockerを確認
root@ubuntu:/var/lib/docker# ls builder containers image network overlay2 plugins swarm tmp trust volumes
はい全然違いますね．こっからは自分で調査していきます．
ぱっと見怪しそうなのがimageですね．
root@ubuntu:/var/lib/docker/image/overlay2# ls distribution/ root@ubuntu:/var/lib/docker/image/overlay2# ls imagedb/ content metadata root@ubuntu:/var/lib/docker/image/overlay2# ls layerdb/ root@ubuntu:/var/lib/docker/image/overlay2# ls imagedb/content/ sha256 root@ubuntu:/var/lib/docker/image/overlay2# ls imagedb/metadata/ sha256 root@ubuntu:/var/lib/docker/image/overlay2#
↑みたいな感じで一通り調べてみた感じそれっぽいのが見当たらず．
そこで検討つけるためにubuntuのイメージをpullしてきて，ファイル容量等を確認した所overlay2が怪しいってことで調査した所
root@ubuntu:/var/lib/docker/overlay2/222a6d0ce3984fa6f9b294e5a2faa02e374cf89e3cf20fc6bd17d3d9b675c989# ls diff link lower merged work
フォルダもそれっぽいし容量もでかいので多分これが中身
実験
overlay2ディレクトリをnfsとかでマウントするとどのくらい使用容量減らせるのか調査
普通のやつ
root@ubuntu:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489692 0 489692 0% /dev tmpfs 101612 4540 97072 5% /run /dev/sda1 15349744 3873228 10673752 27% / tmpfs 508056 0 508056 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508056 0 508056 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 root@ubuntu:~# docker pull fedora Using default tag: latest latest: Pulling from library/fedora a8ee583972c2: Pull complete Digest: sha256:25f7dac76b2c88d8b7e0b1d6213d3406e77c7f230bfa1e66bd1cbb81a944eaaf Status: Downloaded newer image for fedora:latest root@ubuntu:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489692 0 489692 0% /dev tmpfs 101612 4540 97072 5% /run /dev/sda1 15349744 4154420 10392560 29% / tmpfs 508056 0 508056 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508056 0 508056 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 root@ubuntu:~#
overlay2を外部からマウントしたディレクトリにした場合
root@ubuntu:/var/lib/docker# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489696 0 489696 0% /dev tmpfs 101612 4568 97044 5% /run /dev/sda1 24638844 1568628 21795592 7% / tmpfs 508056 0 508056 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508056 0 508056 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 kube-master:/data/cut 3845330944 56159232 3593833472 2% /var/lib/docker/overlay2 root@ubuntu:/var/lib/docker# docker pull fedora Using default tag: latest latest: Pulling from library/fedora a8ee583972c2: Pull complete Digest: sha256:25f7dac76b2c88d8b7e0b1d6213d3406e77c7f230bfa1e66bd1cbb81a944eaaf Status: Downloaded newer image for fedora:latest root@ubuntu:/var/lib/docker# df Filesystem 1K-blocks Used Available Use% Mounted on udev 489696 0 489696 0% /dev tmpfs 101612 4568 97044 5% /run /dev/sda1 24638844 1569548 21794672 7% / tmpfs 508056 0 508056 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 508056 0 508056 0% /sys/fs/cgroup tmpfs 101612 0 101612 0% /run/user/1000 kube-master:/data/cut 3845330944 56441856 3593550848 2% /var/lib/docker/overlay2 root@ubuntu:/var/lib/docker#
通常だと281,192kb使用しているのが，マウントした場合は920kbしか使用しないのでめっちゃ削減できてる．
これはかなり削減できてるのでどんなに重いイメージでもへっちゃらなのでは．．
まぁ実はnfsしてるせいでプルがクソ重かったりするのは内緒
問題点
通信速度がネックになる
あとたまにpullに失敗する．原因はよくわからん．
root@ubuntu:/var/lib/docker# docker pull nvidia/cuda Using default tag: latest latest: Pulling from nvidia/cuda 660c48dd555d: Already exists 4c7380416e78: Already exists 421e436b5f80: Already exists e4ce6c3651b3: Already exists be588e74bd34: Already exists f597507b3c37: Pull complete 9c5d4127a23d: Extracting [==================================================>] 366.4kB/366.4kB 398bf259fcdc: Download complete 4f4092762618: Download complete 94130a21e154: Download complete failed to register layer: Error processing tar file(exit status 1): operation not supported
今回は軽く調査しただけで終わってるので↑の解決方法だったり，実際に利用するとどうなのか深く調べたいと思います．
nvccコマンドが使えるコンテナを用意する
yoloをビルドする際にnvccを利用するのですが，それの環境を一度環境構築した後にメモらないでいたら全部頭から記憶喪失していたのでメモ．
イメージの選び方
https://hub.docker.com/r/nvidia/cuda/
↑のイメージをとりあえず使っておけば無難です．
しかしながら，latestとか使ったりとかするとnvcc使えなったり，タグの選択を間違えると大変なことになります．
でも↑みたいな感じで大量にバージョンがあってどれかわからん．．．．
環境構築してる人の中には機械学習マンもいると思いますけど，そうじゃない人もいると思います．僕は後者です．
正直cudaとかcudnnの違いとかわからないので，僕みたいな人は最初にcudnn使う？とコンテナを利用する人に聞きましょう．
環境構築進めてからcudnn入れるのは結構面倒です．
cudnn使うし，開発環境にするって人たちはnvidia/cuda:9.0-cudnn7-devel-ubuntu16.04を使っておけばいいと思います．間違ってもruntimeを選ばないようにしときましょう．
困るかもしれないこと
コンテナを立ち上げて作業するぶんにはnvcc使えるけど，sshして使うとするとnvccが使えないなんてことがあると思います．
それは，sshした際には通ってる環境変数が違くて実行パスが微妙に違うのが原因らしいので，↓みたいな感じでシンボリックリンクを貼って対応しましょう．
ln -s /usr/local/cuda/bin/nvcc /usr/local/bin/
まぁ↑は根本的な解決にならないので環境変数通したいよって人は↓みたいな感じで環境変数通してください．正直こっちをやるべきですね．
export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
TODO
機械学習系のイメージ馬鹿でかいので，docker imageを保持するのをいい感じに外部に持っていかないと容量やばい．
研究室のタワーPCの整理
自分が所属している研究室にはタワーPCが10台以上ありますが，あまり管理されてないので整理しました．
作業
とりあえず動いてたりとか誰か使ってるやつは触るとまずい可能性があるので止まってる6台を中身開けて動作確認しました．
動作確認するためにとりあえず↑みたいな感じで全部開けます．
動作しなかった時に動作確認する予備パーツが手元になかったので，複数PCを開けてやり取りしてました．
そもそも動作するかわからんものでパーツやり取りしてもまともな動作確認になってないので，ちゃんと動いているPC一個用意するかって感じで適当に研究室内で動いているPCを一個持ってきてそれで動作確認してました．
土曜日だし誰もプリントサーバーの死活とか気にせんやろって思って，適当にプリントサーバー止めてたら同期からプリントサーバー止めた？ってSlackきてちょっと焦りました．
スペック
一応スペック確認しながらやろうかなーって感じでcpuの種類をざっと調べながらやってました．
- intel core i7 780
- 2台
- intel core 2 duo
- 2台
- intel core 2 quad
- 2台
なんとも言えないスペックですね．全体的にいつの時代やねん感があるスペックになってます．
一応ちゃんと動いているPCには i7の7000系とかもあるので全部が全部古いわけではないですが昔からのPCが一応残ってました．
core 2 duoのPCは2台とも電源がいかれてたりしたので（そもそも動く価値があまり感じられないのでとりあえずちゃんと動作しないのを確認して）放置しました．
core i7 780のやつはまぁ今でも使えるレベルなので，1台はグラボがいかれてたのでオンボードに切り替えて動作するようにしました．
もう一台は2ヶ月くらい前までは動いてたんですが，ここ最近急につかなくなってしまったもので原因調査してもよくわからなかったです．同期に聞いたら元々450Wの電源だったのを400Wに変えたらしいのでそこらへんが原因かなー．
ちょっと前までは動いてたのに動かなくなった原因として冬場は電源に負荷かかるってこういうことなのかなってちょっと無理やり納得してます．
intel core 2 quadのやつは，いま3年生にアクセスポイント自作してもらったりする課題出してるのでちょうどいいやんって感じで動かそうと思ったけど動かず．HDDが原因かなと思い，同期が開封してから1日しかたってないHDDを借りてきたところ認識せず．2TBと容量が大きすぎて認識しないのか壊れてるのか．．．．．
研究室には容量の少ないまともなHDDないのでとりあえず保留．メモリはちゃんと動かないとまずいのでメモリチェックをとりあえずしたところ．．．
見事に真っ赤ですね．まぁ長期的に放置されてたのでしょうがない部分はありますね．DDR2のメモリとかそんなに量ないので1枚ずつメモリテスト回していっていい感じの探し当てるか．．．．
ハードの管理は大変なので個人PCとかも実機でやらなきゃいけないことじゃなかったら，VMだったりdockerだったりに完全に移行したいですね．
