gooseをdockerイメージにした話

gooseというgoで書かれたDBマイグレーションツールがあり、これだけを含んだDockerイメージを作った。
hub.docker.comにアップしてあるので
でという感じで実行出来る。

これで解決!Docker for macのディスク容量を小さくしよう(ベータ)

先日、Docker for macでDocker.qcow2というファイルが肥大化する件というのを書かせていただきましたが、こちらの件、Docker for macの最新版ベータにて、ある程度自動で解消されるような処理がマージされたようです。

New Data Management commands #26108
https://github.com/docker/docker/pull/26108

Docker for mac のベータチャンネルにも降ってきましたので、試してみました。

今回ベータチャンネルで降ってきた内容は多いのですが、その中でReclaim disk size on rebootというのが今回の対応になってそうです。

DataManagement commands周りの主な対応内容としては、VM内のdfを表示するコマンド(docker system df)と、お掃除用のコマンド(docker system prune)が出来たといった感じでしょうか。

というコマンドで、今現在のVM内のディスク使用状況が以下のように表示出来ます。

RECLAIMABLEという列が、再利用可能な容量、といったところでしょうか。

早速、実際にpruneしてみます。

このような確認事項が表示されて

[y]を選択すると処理が始まります。

という感じにログが表示され、4.931 GB空いたようです。

prune後にDockerを再起動

メニューからrestartを選択すると再起動します。

起動したら、先ほどのdfを確認してみます。

docker system df

再利用化出来たようです。

実際のVMのサイズの変化は

prune実行前は

という巨大なVMになってしまっています。

prune実行後は

約2GBほど縮小されたようです。

これが正式版に入れば、VMのコンソールに入ったり

ディスクの変換をかけたりする必要がなくなり、dockerのコマンドで解消出来るので良さそうです。


追記

後日、何度かDocker for macを再起動してたら、さらにサイズが小さくなってました。

断片的に縮小していく感じなのかもしれません。

Reclaim disk size on rebootという位なので、もしかしたらDocker for macの再起動のたびに不要な領域が解放されていく、という事なのかもしれません。

そろそろ、自分のdocker-compose.yml周りを公開

docker便利ですね。

最近そんなことばかりしか言ってない気がします。

自分がdockerを使い始めた頃は、dockerってなんなのかわからない人が多く

話すと便利そうだけどプロダクションで使う想像がつかないとか

環境がめんど臭いとか

色々言われていました。

今現在は、開発環境として使うのであれば

docker for macというのがあって、これ入れるだけでかなり簡単にdockerが試せるようになりました。

環境を作るのが簡単になったのであれば、使えるdockerfileとかdocker-compose.ymlとかも

そろそろテンプレ的な何かがあった方が良いかな、と思い

今自分の手元でよく使っている構成でdocker-compose.ymlを公開してみます。

まずは、作りたい環境ですが

サーバサイドとしてRuby on Railsを使うことが多いので、Ruby on Railsを立ち上げる

という前提で行きます。

必要なコンテナとしては

  • Ruby on Railsが動くコンテナ

このコンテナの中には

/productsというディレクトリを作って、この中にRuby on Railsのプロジェクトを置くようにします。

  • mysqlが動くコンテナ

この二つが最低限なので、この構成を作って行きます。

まずは手元にRuby on Railsのプロジェクトを適当に作ります。

docker-compose-templateの中に入ってDockerfileを作成します。

主な構成ですが、プロジェクトのファイル以外に以下のようなファイルが追加になります。

それぞれのファイルについて中身とその解説をして行きます。

#Dockerfile

FROMのベースになるイメージは、officialのrubyにRuby on Railsで良く使うパッケージを追加したものを使用しています。

あと、特徴は

entrypoint.shという物を作成しており、ここで毎回コンテナ起動するたびに実行したい処理などを入れておきます。

#entrypoint.sh

bundle、db:migrate、pidファイル削除などを毎回起動時に行う

#Dockerfiles/mysql/conf.d/default.cnf

mysqlのコンテナで、新らし目のコンテナだとsocketの置き場所が変わったりしているので

後ほどdocker-compose.ymlでmysqlのバージョン指定はしますが、今回はdockerのofficialのmysql:5.5.54を前提に書きます。

#Dockerfiles/mysql/docker-entrypoint-initdb.d/init-user-db.sh

mysqlインスタンスの初回起動時に実行されるスクリプトになります。

これはofficialのmysqlで、コンテナ内の

/docker-entrypoint-initdb.d

というディレクトリに置かれたシェルはインスタンスの作成時に実行される

という仕組みがあるので、そこにファイルを置くように設定します。

(あとでdocker-compose.ymlでファイルを指定します)

最後、docker-compose.yml

#docker-compose.yml

ここまでで、docker-compose.ymlでRuby on Railsを起動するために必要なものは完成しました。

プロジェクトを起動するには

とやると、mysqlを起動して

init-user-db.shによってデータベースが作成され

その後にmainコンテナが起動して

entrypoint.shで初期化されて

プロジェクトが起動します。

init-user-db.sh

は、色々とカスタマイズすることで、すでにマイグレーションされたmysqlのダンプを置いて

それを初期データとして投入したり出来ます。

そうすると、

とするだけで、データベースの初期化が完了します。

また、entrypoint.shで細工しているので

の時はdocker-compose.ymlに指定したcommandが実行されてプロジェクトが起動します。

railsコマンドを叩きたい時は

とやると、コマンドが実行出来るようになっています。

なるべくシンプル構成でなるべく便利に使う想定で、今回このテンプレートっぽいファイルを作ってみました。

参考にしていただけたら幸いです。

一応githubリポジトリ

https://github.com/gendosu/docker-compose-template

 

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 for Mac bata(1.12)とpowが共存出来ない

Docker for Mac bataがリリースされ、早速インストールしてみました。

docker-app-icon

アプリケーションディレクトリに入れて、このアイコンをダブルクリックするだけで

Dockerの環境が自動的に構築されるようです。

docker-menu-iconメニューバーにはDockerのアイコンが表示されるようになります。

1.11以前にDocker ToolboxでDockerを使っていた場合、この初回の起動時に

既存環境を新しい環境で使えるように変換が行われます。(yesにした場合)

今回は、全く新しい環境にインストールをしているので

変換も何もなく、すぐにインストールが終わりました。

変換した場合には、既存環境に応じて、それなりのディスク消費があるので

ディスクの空きが少ない場合は要注意です。

さて、Dockerの環境としては、まだこれから試してみる事はたくさんありそうですが

ここで出てきた問題が、タイトルの通り

powと相性が悪そう、という点です。

powは、Rackサーバで、ローカルでバーチャルホストを提供します。

なので、test-appというプロジェクトであれば、http://test-app.devでアクセスができるようになりますが
test-app.devは127.0.0.1になるので、localhostです。

一方、Docker for Macもポートを80番で指定してコンテナを起動したりすると

http://localhost/でアクセスができるようになります。

Docker for Macは、今までのDocker toolboxとは違い

Mac上でネイティブにハイパーバイザーを使って環境を構築しているようです。

ですので、標準の設定のままだと、これらが衝突し、Dockerのコンテナにアクセスできない、といった状況が発生します。

自分でもこのあたりが今出来る設定で回避可能なのかどうかは、調査中ではありますが

覚書として書いてみました。

 

関連情報

http://pow.cx/

https://www.docker.com/

https://github.com/docker/hyperkit

http://bhyve.org/

Bash on Ubuntu on Windows のアンインストールについて

https://github.com/Microsoft/BashOnWindows/issues/29

lxrunというコマンドがコマンドプロンプトでたたけるようになっているようで、これでオプションにuninstallを付ければ

Bash on Ubuntu on Windows のサブシステム一式が削除出来るようだ。

試しに消してみた。

キャプチャ6

 

Windows 10 Insider PreviewをONにしてみた

最近、MacとWindowsの両方で似たような環境を作って作業することが多くなった訳ですが、どうもMacと比べると色々とWindowsの場合は開発環境といった面では劣る部分が多いというのを改めて感じました。

ただこれ、Windows10は開発用途以外の場合、結構使いやすいOSだと思っています。

自分の場合はノートPCでタッチ画面付きのものなので、マウスが無くても、サッと画面をタッチできたりして便利です。

ブラウジング用途でも手でスクロール出来る&拡大縮小が出来るというのは使ってみるとかなり便利な部分です。

ブラウジングの操作がスマホでなれているというのもあるかもしれません。

そこでMacを触ると、ついつい画面に手が行ってしまいがちです。

あ、タッチ出来ないのか。。と思いつつタッチパッドをスルスルする訳です。

少し話がそれました

Windows 10を開発環境として見た場合に、圧倒的に足りないのがコマンド操作周りだと感じました。

昔はCygwinやらCoLinuxからVirtualPCやVMwareなど、仮想環境は結構手を出してきていましたが

シームレスな環境というのはなかなか見つかりませんでした。

最近はDockerを入れてコンテナ起動ですが、結局は裏でVirtualboxが起動しています。

そんななか、Windows 10 Insider Previewで、Bash on Ubuntu on Windowsなる環境が試せるという話を聞き、これは入れるしかない。

と思いつつも要はベータなので、最悪環境が吹っ飛ぶかも?というところで躊躇してましたが

ふっきれました。

キャプチャ

ONにしちゃいましたよ。

というのも、最近Windowsがブルースクリーンになることが多く、どっちにしろリセットするなら、という気持ちが強くなってきました。

あとは純粋に試したい!という事で。

ついさっきONにしたわけですが、しばらく待たないと入らないようなので、続きはまたしばらく待ったあとにアップしたいと思います。

追記

やっとWindows Updateとして降ってきました。

キャプチャ

入れたらまた別途追記します。

追記2

早速bashをONにしてみます。

キャプチャk

Windowsの機能の有効化または無効化というのをクリックして

キャプチャ2

Windows Subsystem for Linux (Bata)

というところにチェックを付けてOKを押します。

ここで、一度再起動します。

コマンドプロンプトでbashと入力してリターンです。

キャプチャ3

そうすると、インストールするかどうかを聞かれるので、yと入力します。

キャプチャ4

アカウントとパスワードを最初に入力すると、文字は化けますが正常にインストールされたようです。

これで、スタートメニューには

キャプチャ5

このようにBash on Ubuntu on Windowsという項目が出来ています。

これを起動するとbashが使えるようです。

 

Dockerfileを作っている最中にデバッグするときの基本的な手順

Dockerfileを作っている最中に動作確認中に途中で落ちてしまって、その状態でイメージの中身を確認したい時とかが多々あるかと思いますが
今回はそんなやり方、定番かもしれないですが書いてみようと思います。

まずは適当なDockerfileを作ってビルドします。

このビルド時にエラーが出てイメージの作成が止まったという想定です。

docker buildで失敗すると・・・

docker imagesには

というイメージが出来ています。
こいつは

Dockerfile上のタスク(RUNとかADDとかの単位)で正常に処理が完了した状態が一時的にイメージ化されているものです。
で、docker buildで失敗した状態というのは
docker ps -aで表示される停止しているコンテナが持っています。
なので、このコンテナに入ることが出来れば、失敗の原因を調べる事ができそうですね。

コンテナ状態だと、
例えば

こんな感じの表示にある通り、実行コマンドとして/bin/sh -c 〜〜〜〜というのが書いてあり

普通にdocker startしてしまうと、このコマンドが動いて終わるので

このコンテナを一時的にイメージにしちゃいます。

さらに、イメージ化したものをdocker runします。

これで、docker buildで失敗した時点のコンテナに入る事が出来ました。

開発サイクルをブースト!するかもしれない。Dokku触ってみた(初期編)

開発環境って、一度作るとあとはそれほどいじらないのでいいんですが

適当に作ったけど適当に社内で公開したい場合にお気軽にデプロイしたい。

Capistrano使ったりするのもいいんだけど…。

それに、小さめのツール類が多いんだけど、毎回nginx立ててポート変えてとかconfでゴニョゴニョして公開するの、面倒。

サクッとデプロイしたら即公開みたいな環境ないかなー。herokuみたいな。

と思って探したらdokkuというのがあったので、触ってみました。

dokkuとは


OSSのherokuライクなPaaS実装。
dokkuを入れたサーバに対してgitでプッシュするだけでデプロイ完了します。
バックエンド(MySQLとかRedisとか)はプラグインで対応。

公式

https://github.com/dokku/dokku

調査


まずは手元で動作確認。

vagrantを使っての動作確認をしていきます。

まず、何も入っていないvagrantのvmを起動します。

バージョン違いで動かないのは嫌なので、公式通りUbuntu14使います。

調査用Vagrantfile
https://github.com/gendosu/vagrant-dokku

以下のdokkuのインストールをvagrantのprovisionに入れてあるので、自分で手順を試す場合は

としてください。

しばらく待つと起動する。

起動したらvmにログインします。

続いて、dokkuのインストール。

公式にある通りにコマンドを入れます。
https://github.com/dokku/dokku

で初期設定画面が待機しているので、開いてこれが完了すると、

http://[dokkuを入れたサーバのIP]/

id_rsa.pubのキーとドメイン名を設定して初期設定します。
初期設定画面で入れるドメインは、とりあえず触る程度であれば
ドメイン名にIPを含ませて叩くと常にそのIPを返してくれるという
xip.ioというサービスがあるので、これを使います。
もしdokkuを本番に組み込むようなことがある場合、自分でワイルドカードドメインを設定する必要があると思います。
ということで、vagrantで起動したvmのIPを使ってドメイン名を作ります。
dokku.172.28.128.5.xip.io

dokku-domain-setting

こんな感じになるかと思います。
Finish Setupボタンを押すと、設定が完了します。
続いて、ローカルのマシンの方にdokkuのクライアントを入れていきます。
多分公式のshellでやるのが手っ取り早いので、そのままコマンド実行します。

ローカルに適当にテスト用のrailsプロジェクトを作ってデプロイしてみましょう。これでローカルのマシンでdokkuコマンドが使えるようになりました。

今回は本当にとりあえずなので、公式サイトの
Deploying an Application
からサンプルリポジトリを使ってデプロイします。

サーバに入って、postgreSQLのプラグインを入れておきます。

再びローカルで、postgresqlサービスを作成して、アプリにリンクさせておきます。

デプロイはherokuとほとんど一緒です。これで、デプロイ準備は整いました。

でdokku

が追加されていると思います。(dokku apps:createで作成される)
このリポジトリに対してpushするだけでアプリがデプロイ出来ます。

早速デプロイされたアプリにアクセスしてみます。
http://ruby-rails-sample. dokku.192.168.1.1.xip.io
以上です。

感想


heroku cloneそのままという印象。
裏でdockerが動いているが、ほぼ意識しなくて良い。
dokkuはスタンドアローンな仕組みなので、スケールさせるサービスには向かないと思います。
社内で適当にサイトを立ち上げてプレビューするとか
外部公開でも絶対にアクセスが増えないとか
ローカルだけどherokuみたいに気軽にデプロイしてサーバで動いているのを確認したいとか
そーいう用途向きのプロダクトに感じました。
スケールさせることが前提なのであれば
deisやflynnといったプロダクトを使ってみるのがいいかもしれません。
最近だとDocker社がApache Auroraを手中に収めてたりするので
DockerでいくのであればApache Mesosあたりを試してみるのもいいかもしれません。

参考サイト


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

Dockerをmacで使うのが簡単になった

ここ最近のDockerの進化が早くて日々楽しいです。

で、つい先日、macでDockerを使うのが簡単になるツールが出ました。

Docker Toolbox
docker_mac

これは、Dockerを使う上で必要なツールをまとめたインストーラになっています。

toolbox

 

VirtualBoxも同時にインストールされます。

すでに入っていれば、上記のようにグレイアウトになります。

これは、以前Boot2Dockerで使われていたインストーラと同じ物のような感じで

それに加えて

Docker Machine
Docker Compose
QuickStart Terminal
kitematic

が同梱された物、という感じでしょうか。

正式にBoot2DockerからDocker toolboxへ移行する為の動きのようです。

厳密には、Boot2Dockerの後継としてDocker Machineが出来た。

※注意
このインストーラで入るツールはほぼベータ版になります。

ベータ版のため、docker clientのオプション「–valume(-v)」、ホストディレクトリとDocker内でファイルを共有する為のオプションがワーニングを出すようになります。

これは、近い将来

Docker volumeが実装された時の為のワーニングになりますが、現在はまだDocker volumeは実装されておりません。

https://github.com/docker/docker/pull/14242

これで、今までボリューム用の空コンテナを作ってそれを-vでマウントして使って、みたいな面倒な事をやっていたのが、これである程度解消される物と思われます。

ローカルで環境ごとの仮想マシンを起動してるときにWARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!が出る場合の対処方法

というのは、SSHログインするときに
「SSH host key」というのを、確認してて
以前known_hostsに登録したものと違う場合に出すメッセージで
普段はほとんど出ないはずですが
仮想マシンで同じIPで別の仮想マシンを起動してたりすると
良く出ます。

たとえば、localhost:2200で仮想マシン1にSSHする時に

と聞かれて、yesとすることで

known_listsに仮想マシン1のHost Keyが登録されます。

この状態で
仮想マシン1を落として
仮想マシン2を再度localhost:2200で起動させた場合に

上記のワーニングが出ます。
これがめんどくさいので
localhostへのssh接続の場合は、このワーニングを出ないようにしたいと思います。

で、以下を追記

これでワーニングが出なくなります。