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/

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接続の場合は、このワーニングを出ないようにしたいと思います。

で、以下を追記

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