この日記のはてなブックマーク数 Subscribe with livedoor Reader

最近 5 日分 / 今月の一覧

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]




とツイートしたところ、



とのリプライを頂いた。とりあえず手元に入れてみる。インストール方法は

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
Image

demo を見る限り、cacti の Weathermap と置き換え & 見通しが良くなりそう。

http://localhost/linkdraw/sample.html
Image

こっちの sample が設定チュートリアルになってます。描写としてはSVGを利用していて、同一ディレクトリ内の

- configs/xxxx_config.json

が設定ファイルで

- positions/xxxx_position.json

が位置情報になってるようです。

さらに



も教えて頂きました。

http://pgraph.palmtb.net/

は、Ruby 版(gem版?)も欲しいなぁ……ただ、今のところ私は、Ruby に愛がない。



「Docker基本操作」の裏側で起きてること、の触りだけを調べる [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]


どこかで、下記のツイートを見ました。



非常に簡単そうなので、試してみました。

……これは太る(確信)。みんなもやるといいよ!


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


稼働しているコンテナは2つのはず。

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


消えた。コマンド1発だけ動かすような 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]




パスワードの総当りアタックが大変捗ります、という攻撃手法が見つかってしまったようです。

念のためこの攻撃が成功するか確認してみました。上記サイトにも書いてあるんですが、この攻撃が成功する前提として、 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/

[追記その2]:

1つ指摘頂きました。



もうちょっと噛み砕いた情報が欲しい場合は、ozumaさんの

sshによるユーザ列挙攻撃"osueta"
http://d.hatena.ne.jp/ozuma/20140623/1403532516

内の、"ちょっと脱線:UsePAMとPasswordAuthentication" の部分が参考になります。

つまりは

ChallengeResponseAuthentication yes


の場合でも、UsePAM が no であれば、同じパスワードでのログイン不可となるので、攻撃に成功しないよということになります。より具体的には、ozumaさんが表にまとめられている通り、下記の3つのケースで成功しません。

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 投げたりしないのかなー


IPv4/IPv6 meter
検索キーワードは複数指定できます
ChangeLogを検索
Google
Web www.kunitake.org
思ったより安い……時もある、Amazon

カテゴリ