2015-07-27 Mon
■ docker-machine を少し触ってみる [Docker]
そういえば、docker-machine もインストールしてみました。
docker-machine は、boot2docker が、ローカルの VirtualBoxを通じてしか Docker host を作れないのとは違って、driver が対応すれば、クラウド上でも Docker Host を作れます。
インストール方法は
Docker Machine
https://docs.docker.com/machine/
にある通りです。
$ curl -L https://github.com/docker/machine/releases/download/v0.3.0/docker-machine_darwin-amd64 > /usr/local/bin/docker-machine
$ chmod +x /usr/local/bin/docker-machine
version はこんな感じ
$ docker-machine -v
docker-machine version 0.3.0 (0a251fe)
とりあえず、boot2docker と同じく VirtualBox 上の VM に、Docker host を作ってみます。
asteroid:~ kunitake$ docker-machine create --driver virtualbox dev
Creating CA: /Users/kunitake/.docker/machine/certs/ca.pem
Creating client certificate: /Users/kunitake/.docker/machine/certs/cert.pem
Image cache does not exist, creating it at /Users/kunitake/.docker/machine/cache...
No default boot2docker iso found locally, downloading the latest release...
Downloading https://github.com/boot2docker/boot2docker/releases/download/v1.7.1/boot2docker.iso to /Users/kunitake/.docker/machine/cache/boot2docker.iso...
Creating VirtualBox VM...
Creating SSH key...
Starting VirtualBox VM...
Starting VM...
To see how to connect Docker to this machine, run: docker-machine env dev
メッセージにあるように、"docker-machine env dev" とすることで、docker client が docker daemon に接続するための環境変数を得ることができます。
Dockerホストは、boot2docker と同じイメージのようです。
asteroid:~ kunitake$ docker-machine create --driver virtualbox hogehoge
Creating VirtualBox VM...
Creating SSH key...
Starting VirtualBox VM...
Starting VM...
〜以下略〜
とすると、hogehogeというVMが作られるので、独立した別々の Docker host を用意できますね。
boot2docker では、
$ boot2docker ssh
とすることで、Docker Host にログインできましたが、同じような要領で、
asteroid:~ kunitake$ docker-machine ssh hogehoge
## .
## ## ## ==
## ## ## ## ##==
/"""""""""""""""""\___/
~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\_______/
_ _ ____ _ _
|__ ___ ___ | |_|___ \ __| | ___ ___| | _____ _ __
'_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
|_) | (_) | (_) | |_ / __/ (_| | (_) | (__| < __/ |
_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.7.1, build master : c202798 - Wed Jul 15 00:16:02 UTC 2015
Docker version 1.7.1, build 786b29d
docker@hogehoge:~$
と、イメージ名を指定することで個別に Docker Host にログインすることができます。
ちなみに、docker-machine では、Docker host に名前を作られる関係上、たとえ 1つのイメージしかなくても、省略するとこんな感じで怒られます。
asteroid:~ kunitake$ docker-machine ssh
Error: Please specify a machine name.
管理上の Docker Host 一覧を見るには
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
dev * virtualbox Running tcp://192.168.99.100:2376
hogehoge virtualbox Running tcp://192.168.99.101:2376
止めるには、kill、でいいのかな？
asteroid:bin kunitake$ docker-machine kill hogehoge
asteroid:bin kunitake$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
dev * virtualbox Running tcp://192.168.99.100:2376
hogehoge virtualbox Stopped
asteroid:bin kunitake$ docker-machine kill dev
asteroid:bin kunitake$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
dev virtualbox Stopped
hogehoge virtualbox Stopped
あ、killじゃなくて、stop があったので、stop の方が良かったかも。消すのは、rm です
asteroid:bin kunitake$ docker-machine rm hogehoge
Successfully removed hogehoge
asteroid:bin kunitake$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
dev virtualbox Stopped
止めた Docker Host は、start で起動できます。
asteroid:bin kunitake$ docker-machine start dev
Starting VM...
Too many retries. Last error: Maximum number of retries (60) exceeded
ありゃ？再開できない……
asteroid:bin kunitake$ docker-machine env dev
Unexpected error getting machine url: exit status 255
むむ？
asteroid:bin kunitake$ docker-machine start dev
Starting VM...
Too many retries. Last error: Maximum number of retries (60) exceeded
asteroid:bin kunitake$ docker-machine upgrade dev
Error getting SSH command: exit status 255
asteroid:bin kunitake$ docker-machine stop dev
asteroid:bin kunitake$ docker-machine upgrade dev
Error: machine must be running to upgrade.
うーん、手詰まり感が。
バグなのか、環境依存的な問題なのか……この当たりが問題なく動けば、汎用性が高くてヨサゲなんだけど。
■ linkdrawを動かしてみる [linkdraw]
私もこの喜びを共有してみたい＞ "インフラエンジニアがUnityをやるべきたった一つの理由" #engineer #iaas http://t.co/OCuBVbcytf @SlideShareさんから
— kunitake (@kunitake) 2015, 7月 27とツイートしたところ、
@kunitake linkdraw使いましょう。 https://t.co/e777A4uyM8
— Kouhei Maeda (@mkouhei) 2015, 7月 27とのリプライを頂いた。とりあえず手元に入れてみる。インストール方法は
https://github.com/mtoshi/linkdraw/wiki
に書いてあるので、それを参考にインストール。基本的にWebサーバにインストールするツールなので、/Library/WebServer/Docuemnt/linkdraw に入れる感じで。
$ cd ~/develop/github.com
$ git clone git://github.com/mtoshi/linkdraw.git
$ cd linkdraw
$ less ~/utils/setup.sh
$ sudo mkdir /Library/WebServer/Documents/linkdraw
$ sudo bash utils/setup.sh /Library/WebServer/Documents/linkdraw
http://localhost/linkdraw/demo.html
demo を見る限り、cacti の Weathermap と置き換え & 見通しが良くなりそう。
http://localhost/linkdraw/sample.html
こっちの sample が設定チュートリアルになってます。描写としてはSVGを利用していて、同一ディレクトリ内の
- configs/xxxx_config.json
が設定ファイルで
- positions/xxxx_position.json
が位置情報になってるようです。
さらに
@kunitake 大統一Debian勉強会の時の資料がこれです。 http://t.co/TYbZneUWaO あと、おまけで私がここでこれ使ったお遊びをしてます http://t.co/Q63OWpN2VD
— Kouhei Maeda (@mkouhei) 2015, 7月 27も教えて頂きました。
http://pgraph.palmtb.net/
は、Ruby 版(gem版？)も欲しいなぁ……ただ、今のところ私は、Ruby に愛がない。
■ 「Docker基本操作」の裏側で起きてること、の触りだけを調べる [Docker]
- [2015-07-22-2]Docker基本操作
- [2015-07-23-2]Docker基本操作」の裏側で起きてること、を調べる前準備
の続き。
とりあえずわかりやすいように、docker コンテナと dockerイメージをすべて消しておきます。
boot2docker で作られた Dockerホストは、コンテナ用のファイルシステムとして aufs を利用しています。なので、docker イメージを削除すると、、aufs 周りはすべて消されます(以下、docker host上の操作は docker@boot2docker で表記）
docker@boot2docker:~$ sudo find /mnt/sda1/var/lib/docker/aufs/ -print
/mnt/sda1/var/lib/docker/aufs/
/mnt/sda1/var/lib/docker/aufs/diff
/mnt/sda1/var/lib/docker/aufs/layers
/mnt/sda1/var/lib/docker/aufs/mnt
Docker は、Control Groups でリソース配分を行っているので、そのあたりも眺めておきます。
docker@boot2docker:~$ find /sys/fs/cgroup/
/sys/fs/cgroup/
/sys/fs/cgroup/net_prio
/sys/fs/cgroup/net_prio/tasks
/sys/fs/cgroup/net_prio/net_prio.ifpriomap
/sys/fs/cgroup/net_prio/cgroup.procs
/sys/fs/cgroup/net_prio/release_agent
/sys/fs/cgroup/net_prio/net_prio.prioidx
/sys/fs/cgroup/net_prio/cgroup.clone_children
/sys/fs/cgroup/net_prio/cgroup.sane_behavior
/sys/fs/cgroup/net_prio/notify_on_release
/sys/fs/cgroup/perf_event
/sys/fs/cgroup/perf_event/tasks
/sys/fs/cgroup/perf_event/cgroup.procs
/sys/fs/cgroup/perf_event/release_agent
/sys/fs/cgroup/perf_event/docker
/sys/fs/cgroup/perf_event/docker/tasks
/sys/fs/cgroup/perf_event/docker/cgroup.procs
/sys/fs/cgroup/perf_event/docker/cgroup.clone_children
/sys/fs/cgroup/perf_event/docker/notify_on_release
/sys/fs/cgroup/perf_event/cgroup.clone_children
/sys/fs/cgroup/perf_event/cgroup.sane_behavior
/sys/fs/cgroup/perf_event/notify_on_release
/sys/fs/cgroup/net_cls
/sys/fs/cgroup/net_cls/tasks
/sys/fs/cgroup/net_cls/net_cls.classid
/sys/fs/cgroup/net_cls/cgroup.procs
/sys/fs/cgroup/net_cls/release_agent
/sys/fs/cgroup/net_cls/cgroup.clone_children
/sys/fs/cgroup/net_cls/cgroup.sane_behavior
/sys/fs/cgroup/net_cls/notify_on_release
/sys/fs/cgroup/freezer
/sys/fs/cgroup/freezer/tasks
/sys/fs/cgroup/freezer/cgroup.procs
/sys/fs/cgroup/freezer/release_agent
/sys/fs/cgroup/freezer/docker
/sys/fs/cgroup/freezer/docker/tasks
/sys/fs/cgroup/freezer/docker/cgroup.procs
/sys/fs/cgroup/freezer/docker/freezer.state
/sys/fs/cgroup/freezer/docker/cgroup.clone_children
/sys/fs/cgroup/freezer/docker/freezer.parent_freezing
/sys/fs/cgroup/freezer/docker/notify_on_release
/sys/fs/cgroup/freezer/docker/freezer.self_freezing
/sys/fs/cgroup/freezer/cgroup.clone_children
/sys/fs/cgroup/freezer/cgroup.sane_behavior
/sys/fs/cgroup/freezer/notify_on_release
/sys/fs/cgroup/devices
/sys/fs/cgroup/devices/tasks
/sys/fs/cgroup/devices/cgroup.procs
/sys/fs/cgroup/devices/devices.allow
/sys/fs/cgroup/devices/release_agent
/sys/fs/cgroup/devices/docker
/sys/fs/cgroup/devices/docker/tasks
/sys/fs/cgroup/devices/docker/cgroup.procs
/sys/fs/cgroup/devices/docker/devices.allow
/sys/fs/cgroup/devices/docker/cgroup.clone_children
/sys/fs/cgroup/devices/docker/notify_on_release
/sys/fs/cgroup/devices/docker/devices.deny
/sys/fs/cgroup/devices/docker/devices.list
/sys/fs/cgroup/devices/cgroup.clone_children
/sys/fs/cgroup/devices/cgroup.sane_behavior
/sys/fs/cgroup/devices/notify_on_release
/sys/fs/cgroup/devices/devices.deny
/sys/fs/cgroup/devices/devices.list
/sys/fs/cgroup/memory
/sys/fs/cgroup/memory/memory.pressure_level
/sys/fs/cgroup/memory/memory.kmem.max_usage_in_bytes
/sys/fs/cgroup/memory/memory.use_hierarchy
/sys/fs/cgroup/memory/memory.swappiness
/sys/fs/cgroup/memory/memory.memsw.failcnt
/sys/fs/cgroup/memory/tasks
/sys/fs/cgroup/memory/memory.limit_in_bytes
/sys/fs/cgroup/memory/memory.memsw.max_usage_in_bytes
/sys/fs/cgroup/memory/cgroup.procs
/sys/fs/cgroup/memory/release_agent
/sys/fs/cgroup/memory/memory.usage_in_bytes
/sys/fs/cgroup/memory/memory.memsw.limit_in_bytes
/sys/fs/cgroup/memory/docker
/sys/fs/cgroup/memory/docker/memory.pressure_level
/sys/fs/cgroup/memory/docker/memory.kmem.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/memory.use_hierarchy
/sys/fs/cgroup/memory/docker/memory.swappiness
/sys/fs/cgroup/memory/docker/memory.memsw.failcnt
/sys/fs/cgroup/memory/docker/tasks
/sys/fs/cgroup/memory/docker/memory.limit_in_bytes
/sys/fs/cgroup/memory/docker/memory.memsw.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/cgroup.procs
/sys/fs/cgroup/memory/docker/memory.usage_in_bytes
/sys/fs/cgroup/memory/docker/memory.memsw.limit_in_bytes
/sys/fs/cgroup/memory/docker/memory.failcnt
/sys/fs/cgroup/memory/docker/memory.kmem.limit_in_bytes
/sys/fs/cgroup/memory/docker/memory.force_empty
/sys/fs/cgroup/memory/docker/memory.kmem.slabinfo
/sys/fs/cgroup/memory/docker/memory.memsw.usage_in_bytes
/sys/fs/cgroup/memory/docker/memory.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/cgroup.clone_children
/sys/fs/cgroup/memory/docker/memory.kmem.tcp.limit_in_bytes
/sys/fs/cgroup/memory/docker/memory.oom_control
/sys/fs/cgroup/memory/docker/memory.kmem.tcp.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/memory.kmem.failcnt
/sys/fs/cgroup/memory/docker/notify_on_release
/sys/fs/cgroup/memory/docker/memory.kmem.usage_in_bytes
/sys/fs/cgroup/memory/docker/memory.stat
/sys/fs/cgroup/memory/docker/cgroup.event_control
/sys/fs/cgroup/memory/docker/memory.kmem.tcp.usage_in_bytes
/sys/fs/cgroup/memory/docker/memory.move_charge_at_immigrate
/sys/fs/cgroup/memory/docker/memory.soft_limit_in_bytes
/sys/fs/cgroup/memory/docker/memory.kmem.tcp.failcnt
/sys/fs/cgroup/memory/memory.failcnt
/sys/fs/cgroup/memory/memory.kmem.limit_in_bytes
/sys/fs/cgroup/memory/memory.force_empty
/sys/fs/cgroup/memory/memory.kmem.slabinfo
/sys/fs/cgroup/memory/memory.memsw.usage_in_bytes
/sys/fs/cgroup/memory/memory.max_usage_in_bytes
/sys/fs/cgroup/memory/cgroup.clone_children
/sys/fs/cgroup/memory/memory.kmem.tcp.limit_in_bytes
/sys/fs/cgroup/memory/memory.oom_control
/sys/fs/cgroup/memory/cgroup.sane_behavior
/sys/fs/cgroup/memory/memory.kmem.tcp.max_usage_in_bytes
/sys/fs/cgroup/memory/memory.kmem.failcnt
/sys/fs/cgroup/memory/notify_on_release
/sys/fs/cgroup/memory/memory.kmem.usage_in_bytes
/sys/fs/cgroup/memory/memory.stat
/sys/fs/cgroup/memory/cgroup.event_control
/sys/fs/cgroup/memory/memory.kmem.tcp.usage_in_bytes
/sys/fs/cgroup/memory/memory.move_charge_at_immigrate
/sys/fs/cgroup/memory/memory.soft_limit_in_bytes
/sys/fs/cgroup/memory/memory.kmem.tcp.failcnt
/sys/fs/cgroup/blkio
/sys/fs/cgroup/blkio/tasks
/sys/fs/cgroup/blkio/blkio.reset_stats
/sys/fs/cgroup/blkio/cgroup.procs
/sys/fs/cgroup/blkio/release_agent
/sys/fs/cgroup/blkio/docker
/sys/fs/cgroup/blkio/docker/tasks
/sys/fs/cgroup/blkio/docker/blkio.reset_stats
/sys/fs/cgroup/blkio/docker/cgroup.procs
/sys/fs/cgroup/blkio/docker/cgroup.clone_children
/sys/fs/cgroup/blkio/docker/notify_on_release
/sys/fs/cgroup/blkio/cgroup.clone_children
/sys/fs/cgroup/blkio/cgroup.sane_behavior
/sys/fs/cgroup/blkio/notify_on_release
/sys/fs/cgroup/cpuacct
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu
/sys/fs/cgroup/cpuacct/tasks
/sys/fs/cgroup/cpuacct/cgroup.procs
/sys/fs/cgroup/cpuacct/release_agent
/sys/fs/cgroup/cpuacct/docker
/sys/fs/cgroup/cpuacct/docker/cpuacct.usage_percpu
/sys/fs/cgroup/cpuacct/docker/tasks
/sys/fs/cgroup/cpuacct/docker/cgroup.procs
/sys/fs/cgroup/cpuacct/docker/cpuacct.stat
/sys/fs/cgroup/cpuacct/docker/cgroup.clone_children
/sys/fs/cgroup/cpuacct/docker/notify_on_release
/sys/fs/cgroup/cpuacct/docker/cpuacct.usage
/sys/fs/cgroup/cpuacct/cpuacct.stat
/sys/fs/cgroup/cpuacct/cgroup.clone_children
/sys/fs/cgroup/cpuacct/cgroup.sane_behavior
/sys/fs/cgroup/cpuacct/notify_on_release
/sys/fs/cgroup/cpuacct/cpuacct.usage
/sys/fs/cgroup/cpu
/sys/fs/cgroup/cpu/tasks
/sys/fs/cgroup/cpu/cgroup.procs
/sys/fs/cgroup/cpu/cpu.rt_runtime_us
/sys/fs/cgroup/cpu/cpu.shares
/sys/fs/cgroup/cpu/release_agent
/sys/fs/cgroup/cpu/docker
/sys/fs/cgroup/cpu/docker/tasks
/sys/fs/cgroup/cpu/docker/cgroup.procs
/sys/fs/cgroup/cpu/docker/cpu.rt_runtime_us
/sys/fs/cgroup/cpu/docker/cpu.shares
/sys/fs/cgroup/cpu/docker/cpu.cfs_quota_us
/sys/fs/cgroup/cpu/docker/cpu.stat
/sys/fs/cgroup/cpu/docker/cgroup.clone_children
/sys/fs/cgroup/cpu/docker/cpu.cfs_period_us
/sys/fs/cgroup/cpu/docker/cpu.rt_period_us
/sys/fs/cgroup/cpu/docker/notify_on_release
/sys/fs/cgroup/cpu/cpu.cfs_quota_us
/sys/fs/cgroup/cpu/cpu.stat
/sys/fs/cgroup/cpu/cgroup.clone_children
/sys/fs/cgroup/cpu/cpu.cfs_period_us
/sys/fs/cgroup/cpu/cgroup.sane_behavior
/sys/fs/cgroup/cpu/cpu.rt_period_us
/sys/fs/cgroup/cpu/notify_on_release
/sys/fs/cgroup/cpuset
/sys/fs/cgroup/cpuset/cpuset.mem_hardwall
/sys/fs/cgroup/cpuset/tasks
/sys/fs/cgroup/cpuset/cgroup.procs
/sys/fs/cgroup/cpuset/release_agent
/sys/fs/cgroup/cpuset/cpuset.cpus
/sys/fs/cgroup/cpuset/cpuset.mems
/sys/fs/cgroup/cpuset/cpuset.sched_relax_domain_level
/sys/fs/cgroup/cpuset/docker
/sys/fs/cgroup/cpuset/docker/cpuset.mem_hardwall
/sys/fs/cgroup/cpuset/docker/tasks
/sys/fs/cgroup/cpuset/docker/cgroup.procs
/sys/fs/cgroup/cpuset/docker/cpuset.cpus
/sys/fs/cgroup/cpuset/docker/cpuset.mems
/sys/fs/cgroup/cpuset/docker/cpuset.sched_relax_domain_level
/sys/fs/cgroup/cpuset/docker/cpuset.memory_pressure
/sys/fs/cgroup/cpuset/docker/cpuset.memory_spread_page
/sys/fs/cgroup/cpuset/docker/cpuset.memory_spread_slab
/sys/fs/cgroup/cpuset/docker/cpuset.cpu_exclusive
/sys/fs/cgroup/cpuset/docker/cpuset.mem_exclusive
/sys/fs/cgroup/cpuset/docker/cpuset.effective_cpus
/sys/fs/cgroup/cpuset/docker/cpuset.effective_mems
/sys/fs/cgroup/cpuset/docker/cgroup.clone_children
/sys/fs/cgroup/cpuset/docker/cpuset.sched_load_balance
/sys/fs/cgroup/cpuset/docker/notify_on_release
/sys/fs/cgroup/cpuset/docker/cpuset.memory_migrate
/sys/fs/cgroup/cpuset/cpuset.memory_pressure
/sys/fs/cgroup/cpuset/cpuset.memory_spread_page
/sys/fs/cgroup/cpuset/cpuset.memory_spread_slab
/sys/fs/cgroup/cpuset/cpuset.cpu_exclusive
/sys/fs/cgroup/cpuset/cpuset.mem_exclusive
/sys/fs/cgroup/cpuset/cpuset.effective_cpus
/sys/fs/cgroup/cpuset/cpuset.effective_mems
/sys/fs/cgroup/cpuset/cgroup.clone_children
/sys/fs/cgroup/cpuset/cpuset.sched_load_balance
/sys/fs/cgroup/cpuset/cgroup.sane_behavior
/sys/fs/cgroup/cpuset/notify_on_release
/sys/fs/cgroup/cpuset/cpuset.memory_pressure_enabled
/sys/fs/cgroup/cpuset/cpuset.memory_migrate
Docker で最初定義されているサブシステムは
- perf_event
- freezer
- devices
- memory
- blkio
- cpuacct
- cpu
- cpuset
cpusets を眺めてみる。
$ cat /proc/cpuinfo | grep ^processor |wc -l
8
使っているマシンは 8コア。
docker@boot2docker:~$ cd /sys/fs/cgroup/cpuset/docker
docker@boot2docker:/sys/fs/cgroup/cpuset/docker$ cat cpuset.cpus
0-7
docker@boot2docker:/sys/fs/cgroup/cpuset/docker$ cat cpuset.cpu_exclusive
0
Docker グループに割り当てられているCPUは、8コア。この8コアは、専有しているわけではなく、他のグループからも利用可能になっている、と。
cpu を眺めてみる。
docker@boot2docker:~$ cd /sys/fs/cgroup/cpu/docker
docker@boot2docker:/sys/fs/cgroup/cpu/docker$ cat cpu.shares
1024
docker@boot2docker:/sys/fs/cgroup/cpu/docker$ cat cpu.cfs_period_us
100000
docker@boot2docker:/sys/fs/cgroup/cpu/docker$ cat cpu.cfs_quota_us
-1
cpu.shares は、標準のままですね。cpu.cfs_period_us は、100000マイクロ秒 = 0.1秒かな。でも cpu.cfs_quota_us が -1 なので、制限なしですかねぇ。
memory 周り
docker@boot2docker:~$ cd /sys/fs/cgroup/memory/docker
docker@boot2docker:/sys/fs/cgroup/memory/docker$ free
total used free shared buff/cache available
Mem: 2049924 29976 1831564 109012 188384 1808108
Swap: 1461664 0 1461664
$ cat memory.limit_in_bytes
9223372036854771712
docker@boot2docker:/sys/fs/cgroup/memory/docker$ cat memory.memsw.limit_in_bytes
9223372036854771712
特に制限は掛かってなさそう。
とりあえずこの状態で、Docker client から、Docker image の hello-world を pull してみる。
asteroid:~ kunitake$ docker pull hello-world:latest
latest: Pulling from hello-world
a8219747be10: Pull complete
91c95931e552: Already exists
hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:aa03e5d0d5553b4c3473e89c8619cf79df368babd18681cf5daeb82aab55838d
Status: Downloaded newer image for hello-world:latest
asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
hello-world latest 91c95931e552 3 months ago 910 B
あれ？消したつもりが、どっかにキャッシュ持ってたかな？
~# find /mnt/sda1/var/lib/docker/aufs -type f -print |xargs ls -l
-rwxr-xr-x 1 root root 910 Jul 9 2014 /mnt/sda1/var/lib/docker/aufs/diff/a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8/hello
-rw-r--r-- 1 root root 65 Jul 27 03:18 /mnt/sda1/var/lib/docker/aufs/layers/91c95931e552b11604fea91c2f537284149ec32fff0f700a4769cfd31d7696ae
-rw-r--r-- 1 root root 0 Jul 27 03:18 /mnt/sda1/var/lib/docker/aufs/layers/a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8
# cat /mnt/sda1/var/lib/docker/aufs/layers/91c95931e552b11604fea91c2f537284149ec32fff0f700a4769cfd31d7696ae
a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8
Dockerコンテナと aufs とは、どこで結びついてるのかな？
さて、docker runしてみます。
$ docker run hello-world:latest
Hello from Docker.
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(Assuming it was not already locally available.)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
For more examples and ideas, visit:
http://docs.docker.com/userguide/
実行直後、cgroup 周りに変化はなさそうですが、aufs 周りは、変化が有りました。
root@boot2docker:~# find /mnt/sda1/var/lib/docker/aufs -type f -print |xargs ls -l
-rwxr-xr-x 1 root root 910 Jul 9 2014 /mnt/sda1/var/lib/docker/aufs/diff/a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8/hello
-rwxr-xr-x 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/.dockerenv
-rwxr-xr-x 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/.dockerinit
-r--r--r-- 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/.wh..wh.aufs
-rwxr-xr-x 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/dev/console
-rwxr-xr-x 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/etc/hostname
-rwxr-xr-x 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/etc/hosts
-rwxr-xr-x 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init/etc/resolv.conf
-r--r--r-- 1 root root 0 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/diff/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792/.wh..wh.aufs
-rw-r--r-- 1 root root 65 Jul 27 03:18 /mnt/sda1/var/lib/docker/aufs/layers/91c95931e552b11604fea91c2f537284149ec32fff0f700a4769cfd31d7696ae
-rw-r--r-- 1 root root 0 Jul 27 03:18 /mnt/sda1/var/lib/docker/aufs/layers/a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8
-rw-r--r-- 1 root root 200 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/layers/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792
-rw-r--r-- 1 root root 130 Jul 27 03:26 /mnt/sda1/var/lib/docker/aufs/layers/c17d1149bc19ae3a3e044c79e103775882106efb1139d35eb0c7f3d0cbfd1792-init
cgroup がコンテナ毎に設定されるかどうかは、docker run をバックグランドで動作させないとわからなさそうですね。"docker run -d nginx:latest" してみます。
すると、各サブシステムの下にあった docker グループの下に、Dockerコンテナ IDで、サブグループが作られてました。docker run hello-world の時にも、同じようにして一瞬作られていたのかも。
root@boot2docker:~# find /sys/fs/cgroup/ -print |grep 69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/perf_event/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/perf_event/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/perf_event/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/perf_event/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/perf_event/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/freezer.state
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/freezer.parent_freezing
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/freezer/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/freezer.self_freezing
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/devices.allow
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/devices.deny
/sys/fs/cgroup/devices/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/devices.list
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.pressure_level
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.use_hierarchy
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.swappiness
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.memsw.failcnt
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.limit_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.memsw.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.memsw.limit_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.failcnt
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.limit_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.force_empty
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.slabinfo
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.memsw.usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.tcp.limit_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.oom_control
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.tcp.max_usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.failcnt
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.stat
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.event_control
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.tcp.usage_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.move_charge_at_immigrate
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.soft_limit_in_bytes
/sys/fs/cgroup/memory/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/memory.kmem.tcp.failcnt
/sys/fs/cgroup/blkio/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/blkio/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/blkio/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/blkio.reset_stats
/sys/fs/cgroup/blkio/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/blkio/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/blkio/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuacct.usage_percpu
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuacct.stat
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/cpuacct/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuacct.usage
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpu.rt_runtime_us
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpu.shares
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpu.cfs_quota_us
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpu.stat
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpu.cfs_period_us
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpu.rt_period_us
/sys/fs/cgroup/cpu/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.mem_hardwall
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/tasks
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.procs
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.cpus
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.mems
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.sched_relax_domain_level
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.memory_pressure
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.memory_spread_page
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.memory_spread_slab
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.cpu_exclusive
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.mem_exclusive
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.effective_cpus
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.effective_mems
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cgroup.clone_children
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.sched_load_balance
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/notify_on_release
/sys/fs/cgroup/cpuset/docker/69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4/cpuset.memory_migrate
ついでに、Dockerコンテナから見た時のプロセス情報
asteroid:~ kunitake$ docker exec -it 69bd35d3768f2a6868a3cb7621c8586926b55cc7c8baf428b1f5ed5de21f41d4 /bin/bash
root@69bd35d3768f:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 31500 5144 ? Ss 03:30 0:00 nginx: master process nginx -g daemon off;
nginx 6 0.0 0.1 31876 2788 ? S 03:30 0:00 nginx: worker process
root 7 2.5 0.1 20212 3156 ? Ss 03:37 0:00 /bin/bash
root 11 0.0 0.1 17492 2176 ? R+ 03:37 0:00 ps aux
Dockerホストから見たnginxのプロセス情報
root@boot2docker:~# ps aux |grep [n]ginx
root 7168 0.0 0.2 31500 5144 ? Ss 03:30 0:00 nginx: master process nginx -g daemon off;
104 7174 0.0 0.1 31876 2788 ? S 03:30 0:00 nginx: worker process
このPIDの対応もどっかに Docker が管理情報持ってるのかな？
という感じで、ざっと雰囲気が掴めたので、ドキュメントを読み込んでいこう。
2015-07-24 Fri
■ Photon by VMware [VMware][Docker]
コンテナ専用ミニマムOS / Photon
http://vmware.github.io//photon/
Project Boneville
http://blogs.vmware.com/cloudnative/introducing-project-bonneville/
インスタントクローンを作っていく。Linked Clone はファイルだけを差分で持つだけど、Instant Clone は、メモリの内容も差分だけ持つ。
Poweron の VM を Cloneする。
これでなにが嬉しいかというと、コンテナを VM毎に Instant Clone として作成していくので、通常のDockerコンテナと同じくリソースの消費が少なく、さらにコンテナの管理系がゲスト側から破られたとしても、被害がVM内に収まるので、よりセキュア、と。
ただ、現状は単独のライセンスではないので、仮想ディスクトップ用 & vSphere6でないとダメ。
2015-07-23 Thu
■ 「Docker基本操作」の裏側で起きてること、を調べる前準備 [Docker]
昨日書いた記事 [[2015-07-22-2]] は、あくまで Docker Client の使い方であって、Docker Daemon を通じて、Docker Host で何が起こっているかは、わかりませんでした。詳細を知るには、Docker Hostにログインする必要があります。
boot2docker は、VirtualBox 上で、boot2docker-vm という Docker Hostを仮想マシンとして作成します。この VM にログインしながら、いろいろ触れば、裏でなにをやっているか分かりそうですね。vagrant と同様に、boot2docker ssh で、そのあたりをケアしてくれます。
asteroid:bin kunitake$ boot2docker ssh
## .
## ## ## ==
## ## ## ## ##==
/"""""""""""""""""\___/
~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\_______/
_ _ ____ _ _
|__ ___ ___ | |_|___ \ __| | ___ ___| | _____ _ __
'_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
|_) | (_) | (_) | |_ / __/ (_| | (_) | (__| < __/ |
_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.7.1, build master : c202798 - Wed Jul 15 00:16:02 UTC 2015
Docker version 1.7.1, build 786b29d
docker@boot2docker:~$ cat /etc/os-release
NAME=Boot2Docker
VERSION=1.7.1
ID=boot2docker
ID_LIKE=tcl
VERSION_ID=1.7.1
PRETTY_NAME="Boot2Docker 1.7.1 (TCL 6.3); master : c202798 - Wed Jul 15 00:16:02 UTC 2015"
ANSI_COLOR="1;34"
HOME_URL="http://boot2docker.io"
SUPPORT_URL="https://github.com/boot2docker/boot2docker"
BUG_REPORT_URL="https://github.com/boot2docker/boot2docker/issues"
docker@boot2docker:~$ uname -a
Linux boot2docker 4.0.7-boot2docker #1 SMP Wed Jul 15 00:01:41 UTC 2015 x86_64 GNU/Linux
ip link showすると、なにやら見慣れないインターフェースが。
docker@boot2docker:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether b6:0b:83:ca:4c:0e brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 08:00:27:0a:49:46 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 08:00:27:fb:2e:8b brd ff:ff:ff:ff:ff:ff
5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 06:a2:62:51:7f:03 brd ff:ff:ff:ff:ff:ff
ファイルシステム構成
docker@boot2docker:~$ df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 1.8G 106.4M 1.7G 6% /
tmpfs 1000.9M 0 1000.9M 0% /dev/shm
/dev/sda1 18.2G 418.2M 16.8G 2% /mnt/sda1
cgroup 1000.9M 0 1000.9M 0% /sys/fs/cgroup
none 930.7G 326.1G 604.6G 35% /Users
/dev/sda1 18.2G 418.2M 16.8G 2% /mnt/sda1/var/lib/docker/aufs
ん？どうやら標準で、VirtualBox 動かしている母艦の /User を mount してる模様。
関係ありそうなdaemon達
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 1.2 0.0 9764 1900 ? Ss 01:40 0:03 init
root 143 0.0 0.0 8516 1992 ? Ss 01:40 0:00 /sbin/udevd --daemon
root 545 0.0 0.0 8512 1768 ? S 01:40 0:00 /sbin/udevd --daemon
root 546 0.0 0.0 8512 1696 ? S 01:40 0:00 /sbin/udevd --daemon
root 605 0.0 0.0 9764 108 ? Ss 01:40 0:00 /sbin/udhcpc -b -i eth0 -x hostname box -p /var/run/udhcpc.eth0.pid
root 617 0.0 0.0 9764 112 ? Ss 01:40 0:00 /sbin/udhcpc -b -i eth1 -x hostname box -p /var/run/udhcpc.eth1.pid
root 692 0.0 0.0 11856 1952 ? S 01:40 0:00 crond -f -d 8
root 719 0.0 0.1 25128 2960 ? Ss 01:40 0:00 /usr/local/sbin/sshd
root 723 0.0 0.1 16064 2060 ? S 01:40 0:00 ntpd -d -n -p pool.ntp.org
root 728 0.0 0.0 6092 1488 ? Ss 01:40 0:00 /usr/local/sbin/acpid
root 810 0.2 0.9 257412 19000 ? Sl 01:40 0:00 /usr/local/bin/docker -d -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376 --tlsverify --tlscacert=/var/lib/boot2docker/tls/ca.pem --tlscert=/var/lib/boot2docker/tls/server.pem --tlskey=/var/lib/boot2docker/tls/serverkey.pem
root 833 0.0 0.1 11860 2120 tty1 Ss+ 01:40 0:00 -sh
root 834 0.0 0.0 9768 1888 ttyS0 Ss+ 01:40 0:00 /sbin/getty -l /usr/local/bin/autologin 9600 ttyS0 vt100
docker 927 0.0 0.1 27688 3080 ? R 01:41 0:00 sshd: docker@pts/0
docker 928 0.0 0.1 11860 2172 pts/0 Ss 01:41 0:00 -sh
root 1000 0.0 0.0 9764 940 ttyS1 Ss+ 01:44 0:00 /sbin/getty -l /usr/local/bin/autologin 9600 ttyS1 vt100
docker 1005 0.0 0.0 13016 1748 pts/0 R+ 01:45 0:00 ps aux
その他、ユーザランド周りとか、眺めてみる。いやー以前 Dockerを軽く触ってから、結構経ってるので、いろいろと知識の更新が必要だなぁとつくづく……
lxc周りの見直しと、libcontainer あたりのチェックが先かなぁ……
Referrer (Inside):
[2015-07-27-1]
■ 小ネギでご飯のお供 [Food]
どこかで、下記のツイートを見ました。
友達に教えてもらったんだけど、
小ネギ切ってオリーブオイルと醤油1:1くらいでぶち込んで味の素かけたやつ白米にのっけてたべる、っていうやつ、あまりの美味しさに想定の倍は白米消費するからもっと広まれ。 pic.twitter.com/tRxm7AXbAK
— ┏┛こーすけ┗┓ですにゅ (@k_801_) 2015, 7月 4非常に簡単そうなので、試してみました。
……これは太る（確信）。みんなもやるといいよ！
2015-07-22 Wed
■ Docker 基本操作 [Docker]
とりあえず help 眺める
asteroid:~ kunitake$ docker --help
Usage: docker [OPTIONS] COMMAND [arg...]
A self-sufficient runtime for linux containers.
Options:
〜以下略〜
やれることは、なかなか多そうだ。せっかくなので、以前買って積ん読になってた
Docker エキスパート養成読本
http://www.amazon.co.jp/dp/B010N105SC/
をつらつらと眺める。
docker run -it で、フォアグランドでの実行だよとのこと。
-i, --interactive=false Keep STDIN open even if not attached
-t, --tty=false Allocate a pseudo-TTY
なるほど。さっそく実行。
asteroid:~ kunitake$ docker run -it ubuntu:latest /bin/bash
Unable to find image 'ubuntu:latest' locally
latest: Pulling from ubuntu
83e4dde6b9cf: Pull complete
b670fb0c7ecd: Pull complete
29460ac93442: Pull complete
d2a0ecffe6fa: Already exists
ubuntu:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:cb90b1a107073ab3e17271e45a6177b23f548b44157d88d955b7e8bcdbcfd14a
Status: Downloaded newer image for ubuntu:latest
root@bb421f5e88b9:/# cat /etc/debian_version
jessie/sid
root@bb421f5e88b9:/# uname -a
Linux bb421f5e88b9 4.0.7-boot2docker #1 SMP Wed Jul 15 00:01:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
root@bb421f5e88b9:/# dpkg -l |lv
bash: lv: command not found
root@bb421f5e88b9:/# dpkg -l |wc -l
189
最初 docker pull ubuntu:latest やってなかったので、その場でダウンロード。思ったより展開が速い。
最新版に上げるには、再度 docker pull でいいのかな
asteroid:~ kunitake$ docker pull ubuntu:latest
latest: Pulling from ubuntu
83e4dde6b9cf: Already exists
b670fb0c7ecd: Already exists
29460ac93442: Already exists
d2a0ecffe6fa: Already exists
Digest: sha256:cb90b1a107073ab3e17271e45a6177b23f548b44157d88d955b7e8bcdbcfd14a
Status: Image is up to date for ubuntu:latest
当たり前なのかもしれないけど、ダウンロードし直すわけじゃなくて、ちゃんと差分をチェックしてくれる。
いま手元にダウンロードした docker image の一覧を表示してみる。
asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu latest d2a0ecffe6fa 12 days ago 188.4 MB
hello-world latest 91c95931e552 3 months ago 910 B
busybox latest 8c2e06607696 3 months ago 2.433 MB
ついでに、nginx のイメージもダウンロード。
asteroid:~ kunitake$ docker pull nginx:latest
latest: Pulling from nginx
902b87aaaec9: Pull complete
9a61b6b1315e: Pull complete
aface2a79f55: Pull complete
5dd2638d10a1: Pull complete
97df1ddba09e: Pull complete
56c99fa886e8: Pull complete
cd27805ea89f: Pull complete
5e95ac0e9a79: Pull complete
9f36f81a1ccb: Pull complete
4c1809b04591: Pull complete
98c9ccd75644: Pull complete
6886fb5a9b8d: Already exists
nginx:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:a2b8bef3338643176198510fec71c18ceb7834e6f7c45b039ec6e963f43b4005
Status: Downloaded newer image for nginx:latest
これで、docker イメージが増えた。
asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
nginx latest 6886fb5a9b8d 4 days ago 132.9 MB
ubuntu latest d2a0ecffe6fa 12 days ago 188.4 MB
hello-world latest 91c95931e552 3 months ago 910 B
busybox latest 8c2e06607696 3 months ago 2.433 MB
コンテナをバックグラウンドで動かすには -d を使えとのこと。
-d, --detach=false Run container in background and print container ID
実行後には、Dockerコンテナの CONTAINER ID が表示されるらしい。
asteroid:~kunitake$ docker run -d nginx:latest
26a716ed3fea632df0a732bc6f1fdcc524c7f53b1e3cd8749c990c46abd37725
複数同一イメージからコンテナを動かすためなのか、コンテナに名前も付けられるよとのこと。
--name= Assign a name to the container
早速やってみる
asteroid:~ kunitake$ docker run -d --name nginx1 nginx:latest
d485c78b6b3d265a5e2344bc936d0a4cf44637991009f9d03fce9d5a77dfd9d4
稼働中のコンテナを確認するには、ps コマンドを利用 (docker help で確認)
ps List containers
稼働しているコンテナは２つのはず。
asteroid:~ kunitake$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 5 seconds ago Up 3 seconds 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of About a minute ago Up About a minute 80/tcp, 443/tcp gloomy_kowalevski
docker ps で表示される CONTAINER ID は、docker run で返ってくるものより短いですね。丸められてるっぽい。省略される前のIDも、UUIDっぽくもないなぁ……
なお、バックグラウンドで動作させているコンテナに接続するには、exec を利用する。
exec Run a command in a running container
exec の引数には docker run の時の -it がそのまま同じ意味で利用可能。引数には、CONTAINER ID を指定。
asteroid:~ kunitake$ docker exec -it 26a716ed3fea /bin/bash
root@26a716ed3fea:/# which rpm
root@26a716ed3fea:/# which dpkg
/usr/bin/dpkg
root@26a716ed3fea:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="https://bugs.debian.org/"
root@26a716ed3fea:/# touch 2015-07-22
root@26a716ed3fea:/# pwd
/
root@26a716ed3fea:/# exit
exit
動作上は、丸められたっぽい CONTAINER ID で十分みたい。ともあれ、もう一度接続してみて、確かに同じコンテナに接続できていることを確認。
asteroid:~ kunitake$ docker exec -it 26a716ed3fea /bin/bash
root@26a716ed3fea:/# ls -l /2015-07-22
-rw-r--r-- 1 root root 0 Jul 22 10:13 /2015-07-22
root@26a716ed3fea:/# date
Wed Jul 22 10:13:33 UTC 2015
root@26a716ed3fea:/# exit
exit
ちなみに、コンテナは稼働していなくてもそのコンテナを削除するまで、残ってる。停止状態にあるコンテナを表示するには "ps -a"を利用.
-a, --all=false Show all containers (default shows just running)
docker ps -a を発行すると、バックグラウンドで稼働させているコンテナに加えて、停止中のコンテナも表示される。
asteroid:~ kunitake$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 4 minutes ago Up 4 minutes 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of 5 minutes ago Up 5 minutes 80/tcp, 443/tcp gloomy_kowalevski
bb421f5e88b9 ubuntu:latest "/bin/bash" 10 minutes ago Exited (130) 8 minutes ago goofy_elion
3a2860ca69e9 busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago ecstatic_perlman
2d564b9c352e busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago determined_bell
048cd248b560 hello-world "/hello" 2 days ago Exited (0) 2 days ago boring_elion
9fc6d72b1470 busybox "ls" 3 days ago Exited (0) 3 days ago mad_fermi
55c268f2ca5e hello-world "/hello" 3 days ago Exited (0) 3 days ago stupefied_carson
c757592271d0 hello-world "/hello" 3 days ago Exited (0) 3 days ago hungry_franklin
8883e0e9d689 hello-world "/hello" 3 days ago Exited (0) 3 days ago suspicious_tesla
削除するには docker rm
rm Remove one or more containers
引数には、CONTAINER IDを指定。実際に消してみる。
asteroid:~ kunitake$ docker rm 8883e0e9d689
8883e0e9d689
asteroid:~ kunitake$ docker rm c757592271d0
c757592271d0
asteroid:~ kunitake$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 5 minutes ago Up 5 minutes 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of 6 minutes ago Up 6 minutes 80/tcp, 443/tcp gloomy_kowalevski
bb421f5e88b9 ubuntu:latest "/bin/bash" 12 minutes ago Exited (130) 9 minutes ago goofy_elion
3a2860ca69e9 busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago ecstatic_perlman
2d564b9c352e busybox "echo hello world" 29 hours ago Exited (0) 29 hours ago determined_bell
048cd248b560 hello-world "/hello" 2 days ago Exited (0) 2 days ago boring_elion
9fc6d72b1470 busybox "ls" 3 days ago Exited (0) 3 days ago mad_fermi
55c268f2ca5e hello-world "/hello" 3 days ago Exited (0) 3 days ago stupefied_carson
確かに消えた。docker rmi で、DockerコンテナのベースになっているDockerイメージも消せるとのこと。
rmi Remove one or more images
docker images で表示されていた hello-world を消してみる。引数には、CONTAINER ID ではなく、IMAGE ID を利用する。
asteroid:~ kunitake$ docker rmi 91c95931e552
Error response from daemon: Conflict, cannot delete 91c95931e552 because the container 048cd248b560 is using it, use -f to force
Error: failed to remove images: [91c95931e552]
稼働中/停止中のコンテナがあると、そのDockerコンテナの元となっているDockerイメージは消せないらしい。
どうせなので、さっき、マニュアルには、docker rm ではDockerコンテナを1つ以上消せるとあったので、同時に消してみる。
asteroid:~ kunitake$ docker rm 55c268f2ca5e 048cd248b560
55c268f2ca5e
048cd248b560
asteroid:~ kunitake$ docker rmi 91c95931e552
Untagged: hello-world:latest
Deleted: 91c95931e552b11604fea91c2f537284149ec32fff0f700a4769cfd31d7696ae
Deleted: a8219747be10611d65b7c693f48e7222c0bf54b5df8467d3f99003611afa1fd8
asteroid:~ kunitake$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
nginx latest 6886fb5a9b8d 4 days ago 132.9 MB
ubuntu latest d2a0ecffe6fa 12 days ago 188.4 MB
busybox latest 8c2e06607696 3 months ago 2.433 MB
消えた。コマンド１発だけ動かすような Dockerコンテナでは、いちいちイメージを消すのは面倒ですが、"--rm"をつけると、自動的に消してくれるらしい。
asteroid:~ kunitake$ docker --rm run busybox:latest ls
flag provided but not defined: --rm
See 'docker --help'.
間違えた。docker run の引数として "--rm" がサポートされてるんだった。
asteroid:~ kunitake$ docker run --rm busybox:latest ls
bin
dev
etc
home
lib
lib64
linuxrc
media
mnt
opt
proc
root
run
sbin
sys
tmp
usr
var
asteroid:~ kunitake$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d485c78b6b3d nginx:latest "nginx -g 'daemon of 17 minutes ago Up 17 minutes 80/tcp, 443/tcp nginx1
26a716ed3fea nginx:latest "nginx -g 'daemon of 19 minutes ago Up 19 minutes 80/tcp, 443/tcp gloomy_kowalevski
bb421f5e88b9 ubuntu:latest "/bin/bash" 24 minutes ago Exited (130) 21 minutes ago goofy_elion
3a2860ca69e9 busybox "echo hello world" 30 hours ago Exited (0) 30 hours ago ecstatic_perlman
2d564b9c352e busybox "echo hello world" 30 hours ago Exited (0) 30 hours ago determined_bell
9fc6d72b1470 busybox "ls" 3 days ago Exited (0) 3 days ago mad_fermi
asteroid:~ kunitake$
たしかに、停止中のイメージは増えなかった。
Referrer (Inside):
[2015-07-27-1] [2015-07-23-2]
■ OpenSSH に MaxAuthTries をバイパスできる脆弱性 [Security]
OpenSSHのバグにより攻撃者が短時間で数千のPW推測を可能に。ネットに公開されたsshアカウントのブルートフォースが可能に。通常はOpenSSHは3から6回のログイン試行しかできない。攻撃方法の詳細有り。公開鍵暗号鍵の利用が推奨http://t.co/yzmMfdYHWx
— 高梨陣平 (@jingbay) 2015, 7月 21パスワードの総当りアタックが大変捗ります、という攻撃手法が見つかってしまったようです。
念のためこの攻撃が成功するか確認してみました。上記サイトにも書いてあるんですが、この攻撃が成功する前提として、 keyboard-interactive authentication が許可されてないとダメというのがあります。
具体的には /etc/ssh/sshd_config に
PasswordAuthentication yes
ChallengeResponseAuthentication yes
となっているときに、攻撃が成功するというものです。FreeBSD は ChallengeResponseAuthentication が標準で yes になっているので、標的となる可能性が高いようですが、CentOS/RHEL系は、ChallengeResponseAuthentication が標準で no なので、この攻撃は成功しないようです。
ということで、念のためサーバ設定を確認しておくことをお勧めします。一番はパスワード認証を許可しないことですね。もちろん
PasswordAuthentication no
ChallengeResponseAuthentication no
にする前に、公開鍵認証でログインできるようにしておかないと、ログインできなくなっちゃいますけど。
[追記]:
KbdInteractiveAuthentication
Specifies whether to allow keyboard-interactive authentication. The argument
to this keyword must be “yes” or “no”. The default is to use whatever value
ChallengeResponseAuthentication is set to (by default “yes”).
KbdInteractiveAuthentication が個別に設定されている例もあるかも？
ChallengeResponseAuthentication no
KbdInteractiveAuthentication yes
では影響を受けず、
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication no
なら、影響を受けるようです（結局 ChallengeResponseAuthentication 次第？ KbdInteractiveAuthentication の存在意義は……）
Reddit についてるコメントも参考になりますね。
OpenSSH keyboard-interactive authentication brute force vulnerability (MaxAuthTries bypass)
http://www.reddit.com/r/netsec/comments/3dnzcq/openssh_keyboardinteractive_authentication_brute/
[追記その２]:
1つ指摘頂きました。
@kunitake Linuxの場合チャレンジレスポンス認証はPAMを使うので、UsePAM yesも成功条件ですね。noにするとチャレンジレスポンス認証がコケちゃいますw
— no root, nobody (@togakushi) 2015, 7月 22もうちょっと噛み砕いた情報が欲しい場合は、ozumaさんの
sshによるユーザ列挙攻撃"osueta"
http://d.hatena.ne.jp/ozuma/20140623/1403532516
内の、"ちょっと脱線：UsePAMとPasswordAuthentication" の部分が参考になります。
つまりは
ChallengeResponseAuthentication yes
の場合でも、UsePAM が no であれば、同じパスワードでのログイン不可となるので、攻撃に成功しないよということになります。より具体的には、ozumaさんが表にまとめられている通り、下記の３つのケースで成功しません。
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM no
Also see: sshd_config(5)
2015-07-21 Tue
■ junoser を使ってみる [junoser]
JANOG36のライトニングトークで、小島さんが発表されたものに
commit check offline
http://www.janog.gr.jp/meeting/janog36/program/lt-commit
というのがありました(今なら、ストリーミングアーカイブの閲覧可能 2015年7月21日現在)
ネットワーク設定の事前チェックというのは、なかなか難しく、実機投入時に初めてコマンドがないことに気づくとか、syntax が間違ってたとかあり得るので、なかなか泣かされます。
今回、小島さんが作られた junoser を使えば、JUNOS限定ですが、実機に依らず syntax check が可能となります。
junoser
https://github.com/codeout/junoser
インストール方法も、上記サイトに書いてあります。
ということで、さっそく手元のMacにインストール。
$ gem install junoser
Fetching: blankslate-3.1.3.gem (100%)
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.
ですよねー
$ sudo gem install junoser
で、さくっとインストール完了。と……いま会社に実機がなく試せないことに気づく orz
ないものは仕方ないので、ちょこっと適当に設定ファイルをでっち上げて食わせてみる。
junoser のマニュアルによれば
$ junoser -c config.txt
で、文法チェックが
$ junoser -d config.txt
で、set形式に変換されるそうです。試しに
protocols {
bgp {
group ebgp-peers {
type external;
neighbor 192.0.2.2;
}
}
みたいな設定ファイルを読み込ませてみると(rancid で取り込むと、上記のような形式になります）
$ junoser -d test-config.txt
set protocols bgp group ebgp-peers type external
set protocols bgp group ebgp-peers neighbor 192.0.2.2
のように、"show configuration | display set" としたように、set形式でコンフィグが表示されます。
なお、読み込ませる設定ファイルは、今回サンプルで使ったように、一部分でも良いので使い勝手もヨサゲです。
junoser は、netconf の xsd をベースにされているとのことですが、文法チェック的に、全く漏れがないとは言い切れないと思うので、手元の設定ファイルがある人は、どんどん Issue にフィード・バックするといいかと思います。
https://github.com/codeout/junoser/issues
こういうのが出揃えば、github enterprise やら gitlab やらで pull request による事前レビューからの実機へのコミット、とか進んでいけるんですかねぇ……みんなそのあたりどうやってるんだろう？
■ boot2docker 再び [Docker]
boot2docker インストール直後は、いろいろ環境変数がセットされたターミナルが開いているので不便はないわけですが、後日また触りたくなったら、それでは困ります。Docker Client が、Docker daemon に接続するためには、boot2docker-vm の起動以外にも、いろいろ設定しておく必要があります。まぁそれも boot2docker コマンドが手助けしてくれます。まずは、boot2docker start で起動です。
asteroid:~ kunitake$ boot2docker start
Waiting for VM and Docker daemon to start...
................ooooooooo
Started.
Writing /Users/kunitake/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/kunitake/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/kunitake/.boot2docker/certs/boot2docker-vm/key.pem
To connect the Docker client to the Docker daemon, please set:
export DOCKER_CERT_PATH=/Users/kunitake/.boot2docker/certs/boot2docker-vm
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://192.168.59.103:2376
Or run: `eval "$(boot2docker shellinit)"`
ここで表示されるように、環境変数(DOCKER_CERT_PATH/DOCKER_TLS_VERIFY/DOCKER_HOST)をセットするか、boot2docker shellinit を呼び出すことで、docker を動作するための環境変数がセットされます。
asteroid:~ kunitake$ eval "$(boot2docker shellinit)"
Writing /Users/kunitake/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/kunitake/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/kunitake/.boot2docker/certs/boot2docker-vm/key.pem
asteroid:~ kunitake$ docker run busybox echo hello world
hello world
これで Mac で遊ぶ分には不便がなさそうですが、より汎用性の高い docker-machine も気になるところです。
docker-machine を使って boot2docker から脱却する
http://qiita.com/voluntas/items/7bcc9402b51a2ba99096
docker-machineを利用してVirtualBoxとSoftLayer上に簡単にDockerサーバを構築する
http://niccloud.niandc.ne.jp/?p=1195
上記の記事を見るとわかるように、boot2docker では、ローカルの仮想環境をベースに docker環境が整備されていましたが、docker-machine では、ローカルだけでなく、クラウド上のVMを簡単に操作することが可能になります。
今のところ、driver で指定できるクラウドは
- Amazon EC2
- Windows Azure
- DigitalOcean
- Exoscale
- Google Computing Engine
- OpenStack
- RackSpace
- SoftLayer
- VMware vCloud Air
とからしいです。国内クラウド勢が使えるようには見えませんね。docker-machine 自体は Go言語で書かれているようです。githubにリポジトリがあるようですが、だれか pull request 投げたりしないのかなー
2015-07-15 Wed
■ boot2docker [Docker]
そろそろ Docker を真面目に追いかけようか、ということで Mac でやるなら定番の boot2docker をインストール。
https://github.com/boot2docker/osx-installer/releases
Boot2Docker を使うと、VirtualBox と連動して、Docker を扱うことができます。
ここから、現時点での最新版である Boot2Docker-1.7.1.pkg (132MB) をダウンロード。
ダウンロードしたファイルをダブルクリックしたら、インストール開始。
これで docker クライアントがインストールされます (docker, boot2docker コマンドについては /usr/local/bin にインストールされます）
詳細については
http://docs.docker.com/installation/mac/
Docker Client / Docker Host / Docker daemon との関係がわかるので、ざっと眺めておきます。
実際のところ、boot2docker でインストールした Docker client は、VirtualBox上の Linux VM との連動がメインなので、当然VirtualBoxも必要ですが、まぁ今日日 Vagrant で散々お世話になってるかと思うので、多くの人はインストール済ですよね。
VirtualBox がインストールされている状態であれば、
に書いてあるように、Quick-Start に進みます。アプリケーションフォルダにインストールされた boot2docker を起動するとターミナルが開いて、下記のようなスクリプトが実行されます。
bash
unset DYLD_LIBRARY_PATH ; unset LD_LIBRARY_PATH
mkdir -p ~/.boot2docker
if [ ! -f ~/.boot2docker/boot2docker.iso ]; then cp /usr/local/share/boot2docker/boot2docker.iso ~/.boot2docker/ ; fi
/usr/local/bin/boot2docker init
/usr/local/bin/boot2docker up
$(/usr/local/bin/boot2docker shellinit)
docker version
〜以下略〜
このスクリプトで、VirtualBoxで boot2docker-vm という仮想マシンが立ち上がります。
そのまま開いたターミナルから
$ docker run hello-world
を実行すると、こんな感じ
bash-3.2$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from hello-world
a8219747be10: Pull complete
91c95931e552: Already exists
hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:aa03e5d0d5553b4c3473e89c8619cf79df368babd18681cf5daeb82aab55838d
Status: Downloaded newer image for hello-world:latest
Hello from Docker.
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(Assuming it was not already locally available.)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
For more examples and ideas, visit:
http://docs.docker.com/userguide/
boot2docker コマンドで、この docker が動いてる boot2docker-vm の稼働確認ができる
bash-3.2$ boot2docker status
running
ちなみに
bash-3.2$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): darwin/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64
終了するには、boot2docker stop を実行する。
bash-3.2$ boot2docker stop
bash-3.2$ boot2docker status
poweroff
これでしばらく遊べそう
2015-07-07 Tue
■ 電子書籍所感 [よもやま]
そろそろ電子書籍が自炊を含めて千冊越えてきたようなので、所感を。
最初は紙至上主義でしたが、結婚して本の置き場所がなく、本が買えなくなってきたってこともあって、自身が読む本に関しては、電子書籍に大きく舵を切りました。ただ、いい面もあれば悪い面もあるなぁと思ってます。
- 良い面
- 省スペース
- 掃除しやすくなった（ハウスダストに弱いんです……）
- ちょっと安い (セールにはお世話になってます)
- 持ち運びに便利
- 悪い面
- 積んどくされている本が把握できなくなった (とりあえずセールで買って、まだ読んでない本が……)
- どれぐらいのボリュームがあるのか、把握できなくなった（本屋で実物見て、こんなに分厚い本だったのかと気づくことも）
で、振り返ってみて、そろそろ使い分けしてみようかと思い始めてます。
レイアウトが基本変わらないコミック系は、電子書籍のままでいいかな？と思ってますが、小説や技術書の類は紙に戻し、ある程度たったら、自炊して電子書籍化しようかなと考えてます。
なんでかというと、特に Kindle で読んでる時に困るんですが、ページを戻るとページに収まる文章の範囲が変わるんですよね。これはとっても困りました(Kinoppy はどうだったかな……）
よく教科書とかで読み返したり調べなおしたりするときに、本の厚みの 1/3 ぐらいの右のページの下辺りに書いてたはず……みたいなのがあったと思うんですが、こういうことが電子書籍では全然なくて、文字の大きさが可変でレイアウトが変わるというメリットが、むしろデメリットにしか感じられず、あとで振り返るときにストレスフルでした。
なんてことを考えると、iPadとかのタブレットが教育現場で利用され始めているようですが、子供が小学校上がった時も、紙の教科書に関しては、そのままだといいなぁとか思う今日このごろです。
| IPv4/IPv6 meter |
検索キーワードは複数指定できます
| 思ったより安い……時もある、Amazon |
カテゴリ
- Ajax (14)
- Amazon (1)
- Apache (28)
- Backup (4)
- Benchmark (5)
- Blog (3)
- Book (22)
- C (10)
- CGI (2)
- CPAN (8)
- CSS (2)
- Catalyst (8)
- CentOS (2)
- Chalow (11)
- CheatSheet (3)
- Computer (2)
- Crowi (1)
- DB (8)
- DBIC (10)
- DNS (6)
- Debian (31)
- Design (5)
- Django (9)
- Docker (7)
- Emacs (22)
- English (13)
- Excel (3)
- FileSystem (3)
- Firefox (19)
- Flash (2)
- Food (25)
- Framework (3)
- GTD (4)
- Gadget (6)
- Gmail (1)
- Google (19)
- HTML (2)
- Hacker (1)
- Health (22)
- Howto (5)
- IBM (3)
- IETF (2)
- IPv6 (45)
- JANOG (9)
- Java (8)
- Javascript (27)
- LDAP (4)
- Language (4)
- Life (4)
- Lifehack (3)
- Linix (1)
- Linux (127)
- Lisp (2)
- Mac (8)
- Mail (3)
- Manuscript (1)
- Monitoring (1)
- Munin (1)
- MySQL (23)
- Network (19)
- PHP (13)
- Perl (69)
- PostgreSQL (8)
- Programing (5)
- Python (42)
- RPM (1)
- RSS (4)
- React (1)
- RedHat (2)
- Regexp (3)
- Ruby (9)
- Samba (1)
- Scheme (3)
- Security (53)
- Server (4)
- Shell (6)
- Storage (6)
- Subversion (9)
- TAG (2)
- TIPS (26)
- TLS (1)
- Test (6)
- ThinkPad (9)
- Tomcat (3)
- Tools (18)
- Trac (9)
- Troubleshooting (2)
- Tuning (6)
- VMware (12)
- VPN (2)
- Vault (4)
- Vim (3)
- Vmware (5)
- VoIP (1)
- Vyatta (2)
- Web (28)
- WiFi (2)
- Wiki (3)
- Windows (10)
- XML (2)
- XSLT (1)
- Xen (2)
- XenServer (11)
- Zabbix (1)
- junoser (1)
- linkdraw (1)
- python (1)
- raspberry (2)
- skark (1)
- ssh (4)
- systemd (1)
- あとで読む (5)
- その他 (67)
- よもやま (29)
- アサマシ (24)
- イベント (4)
- ゲーム (1)
- ストリーム (2)
- セマンティック (1)
- ダイエット (1)
- ネタ (98)
- 仮想化 (11)
- 開発 (73)
- 環境 (3)
- 管理 (7)
- 休暇 (5)
- 携帯 (8)
- 検索 (3)
- 酒 (3)
- 小物 (10)
- 投資 (1)
- 文字コード (6)
- 勉強会 (1)