Docker for macでDocker.qcow2というファイルが肥大化する件

Docker便利ですね。

Docker for macが出てからは、もうmac上には環境を作らない
なんて運用も可能じゃないかというくらいです。

実際、サーバサイド系の環境はほぼ全てDockerで運用してます。
gulpとかでブラウザのオートリロードとかしたい場合は
さすがに難しいので、そこはmac上に環境を作っておりますが。

ということで、ハードにDocker for macを使っていくと
ディスク容量が日々減っていくのが実感出来るかと思います。

これは、Docker for macも実体はVMであり
VMのディスクとして仮想ディスクがあり
この仮想ディスクが
~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux
に作成されています。

単純に考えると、docker imagesで表示されるイメージで容量を消費しているならば、docker rmiでイメージを消したら良いのでは?と思うのですが
そこはVM、仮想ディスクは一度領域を広げたら、通常運用では領域を解放してくれません。

ですので、この仮想ディスクを手で小さくしてあげないといけないです。

一番簡単な方法は

メニューバーに表示されているDocker for macのアイコンの中の
Preferancesからresetを開いてReset factory defaultsを選ぶこと。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-12-15-9-52-06

この仮想ディスクをクリアするコマンドでは、今までpullしたイメージや起動させたコンテナなども消してしまいます。

Dockerの運用ではあまりないかとは思いますが
コンテナにその場限りではあるけど変更を持ってて
コンテナとかを消したくない、といった場合はこの方法をとると
大切な変更が失われてしまいます。

そこで、仮想ディスクをshrinkする方法をとることで
現状を維持したまま
仮想ディスクを小さくする、といったことが可能になります。

方法ですが、
brewが入っている前提ですが

でqemuというツールをインストールします。
このqemuというのは、仮想マシンの一種になります。

仮想マシンで有名なところですと
VirtualBoxとかVMwareあたりになると思いますが、これらと
似たソフトウェアになります。

で、Docker for macで使用している仮想ディスクのフォーマットは
このqemuのディスクイメージフォーマットを採用しております。
なので
仮想ディスクのファイル名が
Docker.qcow2
となっています。

さて、qemuのインストールが完了したら
このツールの中の
仮想ディスクを操作するコマンドがあるので
そのコマンドを使って
Docker.qcow2
を変換かけます。

変換をかける前に、考慮する部分があり
通常ディスク上でファイルを削除した場合にはインデックス上で削除したという情報を管理して、実体は消えていない状態ですが
通常の場合だとそこに上書きすることになるので、容量があるという見え方になりますが、仮想ディスクはそのインデックス上では削除されているけれど、実体がある場合も、ディスク容量として消費していることになります。
この削除されているけれど実体がある部分を綺麗にしてから
変換をすることで、効率よくファイルを小さくする事が出来ます。

ということで、実際に変換するためのコマンドは
以下のようにします。

これを実行する際に、いらないコンテナ、イメージは全て削除しておくことをお勧めします。

で一覧表示されるコンテナの中からいらないものを全て削除します。
次に

で表示されるイメージで不要そうなものを全て削除します。

続いて、Docker for macの本体になるVMにログイン

仮想ディスク内で削除されているファイル群を削除します。

この方法の欠点は、ディスクフル(Docker.qcow2のディスクサイズ上限 or macのディスク上限)になるまでゼロ埋めファイルを作ってからそのファイルを消すということをやるので、macの容量が少ない場合は結構難しいです。
自分の場合は、ddでサイズ指定(例えば、Docker.qcow2の現在のファイルサイズの半分くらい)をして、消してます。

screenから抜けて

Docker for macを停止します。
Docker for macの停止の仕方は自分がまだ分かってないので、アレなのですが、
Docker for macのPreferenceから、Start Docker when you log inをoffにしてquitしてmacを再起動してます。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-12-15-9-59-53

それから仮想ディスクファイルをshrinkします。

実行時間は、そこそこ長いです。

実行が終わると、
Docker.qcow2.new
というファイルが出来上がっていると思います。

半分位になりましたね。

出来上がったら、一応ですが古い方はリネームしておいて
新しいものに差し替えます。

差し替えた状態で、Docker for macを起動します。
無事に起動して、dockerコマンドが通るようになれば、問題なくshrinkが完了しました。
古い方のDocker.qcow2を削除しましょう。

これで、溜まりに溜まったDocker.qcow2のディスクが綺麗になりました。

Dockerを使っていく上で避けて通れないChef,ansibleとの付き合い方

こんにちは。

最近はローカルの開発環境も、ほとんどDockerに移行した感じです。

そこで、本番も見据えたDockerという事で気になることの一つ

構成管理ツール
chef、ansibleなどなどとの兼ね合い、どうするかな?

と言ったところ考えてみようと思います。

Dockerはコンテナ作成・管理ツールという性質上、コンテナ内部のパッケージやアプリの配備などをDockerfileで行う仕組みになっています。

ということは、端的に言ってしまうとchef、ansibleなどがなくてもコンテナを作れてしまいます。

わざわざDockerで作ったコンテナに対してchefを流して環境を作る、とか意味がありません。

では、Dockerfileの中でChefを呼ぶのはありか?という所ですが

個人的にはこれもあまり嬉しくないなと思います。

Dockerfileを見るだけで、そのコンテナがどんな環境になるのか、というのが一発でわかるようにしたいです。

また、構成管理ではないですが、Dockerでシェル叩いていたり、起動する単一プロセスに構成設定のシェルを指定しているDockerfileが割と多かったりしますが、これも実際何しているのか?というのをシェル見ないと分からなくなってしまうので避けるようにしています。

では、全く使わないのか?

と言われると、NOで

Dockerをそもそも動かすホストマシン側の構成管理については

Chef、ansibleが使える物と思っています。

最低限、Dockerが動かせる環境をChefで構築する

docker engine
docker machine
docker compose
docker swarm

あたりのインストールを自動化しとくのが良いと思います。

そうすることで、ホストマシンが自前だろうがAWSだろうがIDCFだろうがさくらだろうが

さらにOSがUbuntuでもCentOSでも、ホストマシンを自動で構築することも可能になってきます。

所定のdocker engineさえ入っていればコンテナが動くわけです。

なお、docker-machineを使う場合、docker-machineが対応しているクラウドサービスの場合は構成管理しなくても良い位手軽に起動する事が出来たりします。
これは、docker-machineのcreateで作成されるホストには、docker-machineが自動で上記のモジュール類を入れて環境設定してしまうためです。

Dockerを本気で使っている方々には当然の内容ではありますが、以上、一つの考え方として参考にしていただけたらと思います。

gendosu流、dockerの使い方

以前よりローカルでの仮想環境の生成・破棄は容易になったような気がしますが

Vagrantでは、インスタンスの生成、破棄のコストが高い気がするので

そこのところをDockerを使ってやってみるようにしてみました。

gendosu流dockerの使い方

まずは、ベースになるマシンとしてUbuntu Server 14.10 64bitの仮想マシンを立ち上げます。

これは、VagrantでもVMwareでも問題ないです。

今後、頻繁にアクセスすることになるので、vmのIPをhostsに登録してしまいます。

hostsには

192.168.?.?    local-vm

として登録しちゃいます。

これで、vmに

ssh root@local-vm

という感じでログインできるようになりました。

ここから、dockerのセットアップをします。

ubuntu14では、

http://docs.docker.com/installation/ubuntulinux/

にあるとおりに

とやってインストールします。

これで、入ったので、dockerにコンテナを作ってみます。

ただ、普通にやるとコンテナ内へのアクセスが面倒なので

各コンテナ内にsshを起動してしまいます。

これで、ポート指定で外部からssh接続できるコンテナになります。

やり方ですが

Dockerfileを作ってイメージを作成するようにします。

# => Dockerfile

というファイルを作成します。

同じ階層にsupervisord/ssh.conf

を作成します。

こちらは

とします。

このDockerfileをdocker buildでイメージにします。

これで、sshdが起動するdockerコンテナのイメージが作成されました。

このイメージを元に、「run-ubuntu-ssh」という名前でコンテナを起動します。

これで、2200番のポートを指定してssh接続が出来るようになりました。

各コンテナでsshが起動するのは無駄な気がしますが

アクセスが容易になる分、開発環境では便利になるのではないでしょうか。

さて、sshdは起動しましたが、たいていの場合MySQLとかも同時に入れたりしたくなったりします。

MySQLの場合は、別のコンテナでMySQLだけが入ったものを用意します。

これは、Docker.ioのdockerhubから持ってきます。

https://registry.hub.docker.com/

この中に、MySQLというリンクがあるので、ここを開いて、手順通りにやると

MySQLの入ったコンテナが起動できます。

先ほど、「run-ubuntu-ssh」コンテナを起動したときに使ったコマンド

docker runに、別のコンテナへのリンクを追加するというオプションがあります。

今回はそのオプションを追加します。
※先ほどのdocker runを実行している場合、一度docker stop、docker rmでコンテナを破棄します。

mysqlという名のコンテナに対してリンクを張っています。

run-ubuntu-sshコンテナの内部からは、mysqlという名前でmysqlコンテナへ接続できるようになっています。

というコマンドでMySQLへ接続できていればOKです。

別のコンテナを起動する場合、先ほどのdocker runのコマンドで、-p 2200:22のところを2201:22という感じにインクリメントしていくことで、比較的容易にコンテナを管理できると思います。