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/

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の使い方(Docker composeを使う)

dockerを開発環境で使うに当たって

前回「gendosu流、dockerの使い方」という内容を書きました。

その内容だと、

通常Dockerコンテナを手動で起動するには
まず、Dockerfileを作って自分好みにイメージを作成
作成したイメージからdocker runコマンドでコンテナ起動
たとえば、memcachedとmysqlとredisを使った一通りの構成を手動で起動しようとした場合
それぞれにイメージ作成やdocker run(start)をして起動していかないといけないです。
コンテナ間にリンクを張っている場合は起動順序も考慮する必要があります。

面倒ですね。

そこで、今回はDocker-composeを使ってみたいと思います。
こちらのツールはDockerのオフィシャルで配布されているツールになります。

簡単に言うと、複数コンテナの情報を1ファイルに集約して、そのファイルを元に
1コマンドで全コンテナを起動できるようにするツール

という事になると思います。

早速

インストール

Docker composeのインストールは

https://docs.docker.com/compose/install/

をみて作業を進めます。

これでdocker-composeというコマンドが入りました。

docker-composeを使うには
コマンドを実行するディレクトリ配下にdocker-compose.ymlというファイルを作成します。

※ディレクトリ構成

今回は前回の構成
webとmysql
という2つのコンテナを起動するような構成でファイルを作ってみたいと思います。

Dockerfile(supervisordのディレクトリも)は前回の物を流用します。

# Dockerfile

EXPOSEとCMDは、次のdocker-compose.ymlで設定するので、ここでは設定してません。

# docker-compose.yml

これで設定ファイルの準備が完了しました。

起動はdocker-composeにオプションを指定して実行します。

docker-composeのオプションで、代表的な物は

  • up
    コンテナをイメージから作り直して起動する
  • stop
    すでに起動しているコンテナを終了する
  • start
    停止しているコンテナを起動させる

あたりかと思います。

起動してみます。

upというオプションを指定して起動させました。

Dockerfileのビルドが走った後に

各イメージからコンテナが生成されて起動された事が確認できると思います。

あとは、前回同様、ポート2200を指定してsshすることでwebコンテナへログインする事が出来ます。

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という感じにインクリメントしていくことで、比較的容易にコンテナを管理できると思います。