Home > Docker

Docker Archive

CircleCI + Docker で PHP 7 と PhantomJS 使って CI する

  • コメント (Close): 0
  • トラックバック (Close): 0

2014 年に発表したセッションと資料まとめ

この記事の所要時間: 648

2014 年も残すは、あと 1 週間になりました。今年も様々なイベントで登壇しましたので、発表したセッションと資料をまとめてみます。

phpcon_kansai_2014
写真提供:久岡写真事務所

登壇イベント

2014/04/04 「わかってるフレームワーク Laravel」Laravel勉強会福岡

「わかってるフレームワーク Laravel」とうタイトルで発表しました。

Laravel で、とあるプロジェクトの開発が終わった後だったので、Laravel への良さを主観たっぷりでお話しました。

翌日の Laravel Meetup Tokyo と合わせて、一人 Laravel Japan ツアーでした:D

2014/04/05 「知っておくべき Auth オートログイン」 Laravel Meetup Tokyo vol.3

Laravel 4.1.25 以前にあった Auth フィルタ利用時のオートログインの問題点についてお話しました。

いくつかの前提条件は必要ですが、影響度が大きいので、「これはやばい」というのが伝わっていました。

なお、この問題は、4.1.26 にて修正されたので、現在は問題ありません。

Laravel ユーザなら知っておくべきAuthオートログインのこと

2014/04/12 「Vagrant ユーザのための Docker 入門」 第3回コンテナ型仮想化の情報交換会@大阪

Docker が盛り上がってきた時だったので、Vagrant ユーザを対象に Docker 入門をお話しました。

セッション途中でも活発に質問が飛び込んできたり、デモでコンテナ起動の速さに驚きの声があがったりで、盛り上がったのを覚えています。

「VagrantユーザのためのDocker入門」を発表してきました

2014/04/19 「最近なんだか、はてブがおかしい」俺聞け8 in Tokyo

資料未公開

当初は「Webエンジンアとしてご飯を食べていく」という内容を考えていたのですが、事前に、主催の @msng さんから「ブログに関する発表が多くて嬉しい」というコメントがあったので、ブロブに寄せようと内容を変えました:)

会場には、著名なブロガーの方が多く、みなさん同じようなことを感じているようで、発表後の情報交換が捗りました。

2014/04/24 「Vagrant 体験入門」DevLove関西

これから Vagrant を学ぶ方向けに、Vagrant 概要についての発表と体験ハンズオンを行いました。

Vagrant ハンズオンでは、みんなで同一拠点から一斉にプロビジョンを行うので、遅延やエラーが起こったり、環境の違い(Vagrant + VirtualBox が起動するまでの)でトラブルが発生したりで、毎回発見があります。

ハンズオンの資料は Qiita に公開しています。

Vagrant体験入門ハンズオン手順 – 2014/04/24 DevLove関西

Vagrant体験入門ハンズオンの資料を公開します

2014/06/19 「Heroku で作るスケーラブルな PHP アプリケーション」第16回関西PHP勉強会

Heroku で PHP が正式サポートされたので、スケーラブルな構成をどう組むかという内容でお話しました。

その後、いくつかのプロジェクトで Heroku + PHP を使っているのですが、やはり PaaS として良くできていますね。まだ掴みきれていない部分もあるので、引き続き追いかけていきます。

Heroku で作るスケーラブルな PHP アプリケーション

2014/06/28 「PHPコードではなく PHPコードの「書き方」を知る」PHPカンファレンス関西2014

PHPカンファレンス関西の初心者向けセッションということで、FizzBuzz を題材に、関数化、クラス化、そして自動テストを書くという流れをお話しました。

「PHPコードではなくPHPコードの「書き方」を知る」を発表してきました

2014/07/05 「開発現場で活用する Vagrant」夏の JAWS-UG 三都物語 2014

関西での JAWS-UG イベント、三都物語でのセッションでした。JAWS-UG では久しぶりの発表になりました。

Vagrant を実際に使う例として、デモで実演しながらセッションを進めました。

会場がフランクな雰囲気で、話しやすかったのが印象的でした。あと Yo を使って、バーチャル拍手というかうなずきを送ってもらったりもしましたね。

「開発現場で活用するVagrant」を発表しました

2014/08/23 「Vagrant 心得 5 ヶ条」DevLove 甲子園 2014 西日本大会

資料未公開

DevLove 甲子園にて、Vagrant についてお話しました。ここでは、Vagrant を活用する上で、気をつけておくと良いことを 5 つにまとめました。

内容は、いずれ blog に書きたいと思います。

2014/10/11 「Ansible ではじめるサーバ作業の自動化」PHPカンファレンス 2014

PHP カンファレンスで、Ansible についてお話しました。発表を聴いた方からは、好意的なフィードバックが多く、「Chef を使っていましたが、Ansible 使ってみます!」という意見もあり、良かったです。

準備している時は、話したいことをどう上手くおさめるかを苦心したので、普段スピーカーをしているコミュニティの仲間から「うまくまとまっていましたね」と言ってもらえ、やはり見ている人には分かるんだなあと感じたりもしました。

このセッションを見た方から、別のイベントでの登壇についてお誘いがあったり、次につながったセッションでもありました。

「Ansibleではじめるサーバ作業の自動化」を発表してきました

2014/12/19 「ビルドサーバで使う Docker」DevLove 関西

年内最後の発表は、やはり Docker でした。今年は、ほんと Docker が躍進した一年でしたね。

Jenkins サーバでの活用例から、導入のポイントや設定方法などをお話しました。

「Jenkinsサーバで使う Docker」を発表してきました

ロクナナワークショップ 「Laravel で学ぶモダン PHP 開発講座」

11 月から、ロクナナワークショップさんにて「Laravel で学ぶモダン PHP 開発講座」という講座を行っています。

みっちり 1 日で、Vagrant や Composer の使い方、Laravel を使った REST API の実装、そして、その自動テストを書くという内容です。

すでに 2 回開催しているのですが、参加された方は熱心に課題に取り組まれていて、講師としても勉強になることが多いです。まとまった時間でじっくり課題をこなしていくので、これから学んでいこうという方にはおすすめです。

次回は 2015/02/17 に開催予定ですので、もし興味がある方は、ご参加下さい。

新原雅司のLaravel で学ぶモダン PHP 開発講座

さいごに

今年を振り返ってみると、自分で名乗り出るよりも、お声がけ頂いて、登壇するという機会が増えました。お声がけ頂けるのは嬉しく、スケジュールやタイミングが許せば、できるだけお引き受けしたいです。

人前で話すというのは、準備も大変ですし、いつも緊張しますが、毎回色々な発見があり、また、終わった後は何ともいえない解放感というか充実感を感じることができます。聴いて頂いた方からのフィードバックも嬉しいものです。

今年も、セッションに参加して頂いた方、イベントにお声がけ頂いた方、本当にありがとうございました。

2015 年は、年始の 1/16 に GoAzure 2015 で登壇する予定です。Websites でスケーラブルな PHP アプリケーションを作るという内容ですので、ご参加お待ちしています!

  • コメント (Close): 0
  • トラックバック (Close): 0

「Jenkinsサーバで使う Docker」を発表してきました

この記事の所要時間: 142

すっかり年の瀬ですが、今年最後の発表を DevLove 関西にて行いました。

docker

Docker 実践編ということで、CI の一環でビルドサーバに使っている Docker についてお話してきました。

発表資料

Jenkins サーバに Docker を入れており、ビルドの環境として利用しています。構成や使い方は、わりとベーシックな内容です。

プロビジョンには Ansible を使っており、ローカルコネクションで ansible-playbook を実行しています。

使い捨てできる環境なら実用的

勉強会の最後に、発表者への QA の時間があったのですが、多数の質問があり、Docker に対する関心が高いのをあらためて実感しました。

今回、参加された方は、これから Docker を使ってみようという方が多いようで、導入に関することや、安定性などに対する質問が多かったです。(安定性に関しては、私のセッションでトラブルの話をしたせいもありますが。)

セッションでも触れましたが、現状は、開発環境やビルドやジョブワーカーのように、作って、使って、捨てるという環境では、Docker は実用的です。

一方、Web システムのように、常に動き続ける環境では、Docker デーモン自体の運用やイメージリポジトリなど、Docker コンテナをデプロイ、運用していく上で考慮すべきことがあり、まだ様子を見ているというのが率直なところです。

とはいえ、この時期だからこそ、果敢にチャレンジして、ノウハウを貯めるというのも一つの戦略で、トラブルシュート込みで実践してみるというのもアリです。(今回、自前でビルドサーバを構築したのは、こういった意味合いもありますし。)

個人的には、Docker コンテナが動く環境は AWS や GCE などのクラウドサービスに任せて、こちらでは Docker コンテナをビルドして、然るべきところへ送信すれば、後はよしなにやってくれるようになると嬉しいです。

  • コメント (Close): 0
  • トラックバック (Close): 0

Docker Hub 公式 PHP イメージで、複数バージョンの PHP コンテナを起動する

この記事の所要時間: 422

Docker Hub の 公式 PHP イメージで、PHP 5.4, 5.5, 5.6 のコンテナを起動します。

docker

PHP Advent Calendar 2014 の 12 日目です。昨日は、PHPで簡単に華麗にDIとAOPをキメる でした。

Docker Hub には、公式でミドルウェアや言語のイメージがで公開されています。PHP もその一つで、現在は、5.4, 5.5, 5.6 が公開されています。また、バージョン毎に複数のタグが存在し、cli / fpm / apache(mod_php) といた構成違いのものが存在します。

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

ここでは、5.x-apache タグのイメージを使って、複数バージョンのコンテナを起動して、ブラウザから、同一コンテンツを異なる PHP バージョンで確認できるようにします。

boot2docker のインストールと起動

Docker の実行環境として、boot2docker を使いました。

pkg ファイルが公開されているので、これをダウンロードして、インストールすると良いです。

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

インストールできたら、boot2docker を起動しておきます。

$ boot2docker init
$ boot2docker up

boot2docker の VM が起動したら、IP アドレスを確認しておきます。

$ boot2docker ip

The VM's Host only interface IP address is: 192.168.59.xxx

公式 PHP イメージでコンテナを起動

Docker Hub 公式の PHP イメージを使って、5.4, 5.5, 5.6 の Docker コンテナを起動します。5.4-apache / 5.5-apache / 5.6-apache のイメージは、Apache + mod_php の構成になっており、手軽に Web アプリケーションを実行できます。

実行するコンテンツは、OSX 上にあるファイルを利用します。boot2docker では、1.3 から shared_folder で、OSX の /Users のディレクトリを、VM から /Users として参照することができます。これにより、VM の docker コンテナからシームレスに OSX のディレクトリをマウントすることができます。

コンテンツは、単純に PHP バージョンを出力するだけです。

$ cat /Users/path/to/index.php
<?php
echo 'PHP ' . phpversion();

バージョン毎にポートを分けて、以下のようにコンテナを実行します。初回は、各イメージをダウンロードするので時間がかかります。次回以降は、即座に起動します。

$ docker run -v /Users/path/to:/var/www/html -p 8084:80 -d php:5.4-apache
$ docker run -v /Users/path/to:/var/www/html -p 8085:80 -d php:5.5-apache
$ docker run -v /Users/path/to:/var/www/html -p 8086:80 -d php:5.6-apache

ブラウザから確認

では、ブラウザから起動した Docker コンテナにアクセスします。ポートを変えて、アクセスすると、それぞれの PHP バージョンが出力されます。

  • http://boot2docker-vm:8054/
PHP 5.4.35
  • http://boot2docker-vm:8055/
PHP 5.5.19
  • http://boot2docker-vm:8056/
PHP 5.6.3

さいごに

Docker Hub 公式の PHP イメージを使って、複数バージョンの PHP を起動しました。

このイメージは、使ってみると分かるのですが、拡張は必要最低限となっており(mbstring も pdo_mysql / pdo_pgsql もありません)、実際のアプリケーションを動かすには、拡張を追加して、ビルドする必要があります。

もちろん、こうした状況は考慮されており、イメージには docker-php-ext-install という拡張を追加するコマンドが用意されています。

実用する場合は、公式イメージをそのまま使うのではなく、これをベースに Dockerfile を書き、独自に拡張を追加したイメージを使うという方法になりますね。

明日の PHP Advent Calendar 2014は、ngyuki さんです。お楽しみに!

  • コメント (Close): 0
  • トラックバック (Close): 0

「VagrantユーザのためのDocker入門」を発表してきました

この記事の所要時間: 414

第3回 コンテナ型仮想化の情報交換会@大阪 で行った発表です。

docker

コンテナ超人みたいな人ばかりで、この内容で発表して良いものやらと思ったのですが、アプリケーションを書く側からの視点で話してきました。

Vagrant ユーザのための Docker 入門

VagrantユーザのためのDocker入門 from Masashi Shinbara

Docker を知った時は、速くなった Vagrant のようなものだと思っていたのですが、色々と見る内にそもそも別のもので、ユースケースとして重なるところはあれど、別のツールだと認識した方が良いです。

Docker の入り口としては、デモを見てもらうのが、手っ取り早いので、そのあたりが伝わったなら良かったです。

Introduction to Docker

発表で引用した「Introduction to Docker」は下記です。公式の資料なので、色々ググる前に、まずはこれを読むのがおすすめです:D

Docker introduction from Docker

CentOS で Docker を動かす Vagrantfile

デモで使った Docker が動く CentOS を作る Vagrantfile です。

https://github.com/shin1x1/vagrant-centos-docker.git

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don&#039;t touch unless you know what you&#039;re doing!
VAGRANTFILE_API_VERSION = &quot;2&quot;

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = &quot;opscode-centos65&quot;
  config.vm.box_url = &quot;http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box&quot;

  config.vm.provider :virtualbox do |vb|
    vb.name = &quot;docker&quot;
    vb.customize [&quot;modifyvm&quot;, :id, &quot;--memory&quot;, 1024]
  end

  config.vm.network :private_network, ip: &quot;192.168.33.10&quot;
  config.vm.network :forwarded_port, guest: 4243, host: 4243

  config.vm.provision :shell, :inline =&gt; &lt;&lt;-EOT
    #
    # iptables off
    #
    /sbin/iptables -F
    /sbin/service iptables stop
    /sbin/chkconfig iptables off
    #
    # yum repository
    #
    rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
    yum install -y vim-enhanced telnet
    #
    # docker
    #
    yum install -y docker-io
    sed -i &#039;s,^other_args=&quot;&quot;,other_args=&quot;-H tcp://0.0.0.0:4243 -H unix:// -dns 8.8.8.8&quot;,g&#039; /etc/sysconfig/docker
    chkconfig docker on
    service docker restart
  EOT
end

さいごに

Docker 盛り上がっていますね。

今後、本番環境としての Docker 活用例や、Docker コンテナをそのまま deploy できる DaaS(Docker as a Service)が増えてくると、面白くなりそうです。

なお、Docker が出たから、Vagrant は終わりとかそういう話では無いので、今後も Vagrant も活用していきたいですね。

  • コメント (Close): 0
  • トラックバック (Close): 0

Vagrant に見るインテグレーションのヒント

この記事の所要時間: 612

Shin x blog Advent Calendar 2013 の 23 日目です。

vagrant

今年一年を振り返った時に、一番インパクトがあったのは Vagrnat でした。

昨年までも存在は知っていたものの、本質を理解しておらず、単に仮想マシンをコマンドで扱えるもの程度の認識でした。今年に入り、利用法が分かった後は、開発環境や検証環境などを構築するのに大いに役立っています。

Vagrant はパッケージとしてよく出来ており、それまで一部の人しか扱わなかった仮想化環境を多くの人に解放してくれました。ここでは、Vagrant の構成から、システムインテグレーションを行う上でのヒントを見出してみたいと思います。

既存技術をインテグレーションしたツール

まず、Vagrant で興味深いのは、基礎的な技術要素は、Vagrant 自身では提供しておらず、外部のソフトウェアやサービスを利用しているという点です。

仮想化環境にしても、プロビジョニングツールにしても、以前から存在しており、特段珍しいものではありません。これらを上手く組み合わせて、Vagrant という一つのツールとして扱えるようにしています。

Vagrant を知っても、すぐに触手が伸びなかった人(私も含めて)は、このインテグレーションしている部分が見えず、単に技術要素だけを見ていたのではないでしょうか。もちろん、技術要素が無ければ動作しないのですが、そこだけを見ていると本質を見誤ります。それらを組み合わせて、より良い使い方を提示しているのが Vagrant というツールです。

ある意味、技術要素は上手く隠蔽して、ツールの目的を果たせるような作りにするのが手腕の見せ所なのかもしれません。

実行環境を同梱

Vagrant 1.0.x の頃は、パッケージでのインストールの他に gem でのインストールも可能でした。もともと gem コマンドを使っている人にとっては便利なものですが、そうで無い人にとっては、まずは gem の環境を整える必要があり、インストールの障壁となる場合がありました。また、Ruby や gem のバージョンがユーザ毎に異なるので、その環境固有が問題が生じてしまいます。

そこで Vagrant 1.1 からは、Ruby の実行環境ごと Vagrant にパッケージングして、これさえダウンロードすれば、同じ環境で動くようになっています。これには、Vagrant 開発側が多様な環境をサポートする手間を削減するという面もありますが、ユーザとしても、自分の環境に Ruby があろうが無かろうが、そんなことは気にする必要が無く、ただパッケージをダウンロードして、インストールするだけで良くなりました。

実行環境が同梱できるかどうかはケースバイケースになりますが、ストレージやネットワークがリッチになった今では、こういった方針は、開発側、ユーザの双方にとってメリットになりますね。

メインの操作を vagrant up に集約

Vagrant で、一番行う操作は vagrant up でしょう。

このコマンドを実行するだけで、仮想マシンの構築から、プロビジョニングの実行を自動で行ってくれます。その裏では、Vagrantfile に書かれた情報を読み取って、仮想環境を作り、ベース仮想イメージを取得し、仮想マシンを起動。OS ブートが完了したら、プロビジョニングを実行して、仮想サーバの設定を行っています。

ユーザは、こういった一連の流れを意識することなく、複雑なところは Vagrant が連携するソフトウェアと協調して、良しなにやってくれます。これは非常に分かりやすい方法です。

Vagrantfile を利用するだけの人は、このコマンド(と halt / destroy などの基本的なコマンド)だけを覚えるだけで、Vagrant の恩恵を十二分に受けることができます。

また、Vagrantfile を書く側の人にとっても、操作方法がはっきりしているので、それに合わせて Vagrantfile やプロビジョニング設定の記述することになります。vagrant up するだけで全ての環境構築が完了するように設定を書いていくわけです。記述した Vagrantfile を管理する方法も、プロジェクトのソースコードと同じリポジトリに含めて、git clone して、vagrant up するという流れができるように行います。

こうして、主となる操作がはっきりしているので、使う側はそれだけ覚えれば良く、設定する側もそれに合わせて構築すれば良くなります。

vagrant up を打ち出して、これだけで環境構築ができます!と謳ったのは、Vagrant の本質を伝えるにはとても有効な手法だったと思います。

プラガブルなソフトウェアとエコシステムの利用

先に書いたとおり、Vagrant は多様な技術を組み合わせて使うツールなので、別システムとの連携が必須です。

Vagrant では、そういった外部ツールとの連携処理をプラグインで実装しています。利点は、もし新しい技術が登場した場合、Vagrant 本体は触らなくても、プラグインを追加すれば、利用が可能となるということです。プラグインは、gem パッケージにて配布できるようになっているので、有志によるプラグインが作られています。

gem パッケージで配布されているからといって、ユーザは gem を意識する必要はありません。プラグインのインストールには vagrant plugin というコマンドが用意されており、これを使うことで、プラグインのインストールやアップデート、アンインストールが可能です。

実際、仮想化環境、プロビジョニングツールは、プラグインとなっているので、Vagrant 本体に同梱されているもの以外にも、AWSDigital OceanFabric など多くプラグインが公開されています。中には Vagrant 自体のパッケージに同梱されていくパターンもあります。

ソフトウェア自体はプラガブルにして、機能拡張が容易に行えるようにしています。プラグインの配布には、Ruby のエコシステムを利用して、誰もが開発したプラグインを配布できるようにしています。そして、ユーザにはそういった構成を知る必要は無く、単にいつものコマンドを使うだけで良いわけです。

さいごに

同じように既存の技術を組み合わせて、パッケージングしていると感じるのが、Docker です。これも lxc や aufs など、以前からある技術を利用していますが、それらを組み合わせて、コンテナベースの仮想マシンという形を作り上げています。エコシステムに関しては、まだ荒削りな面がありますが、これも次第に成熟が進んでいくと期待しています。

Vagrant が多くの人に受け入れられているということは、ある意味レゴブロック型プログラミングでも上手くやれば、多くの人に使ってもらえるようなものが作れるということを示唆しているように思います。個人的にはこの点でも Vagrnat や Docker は気になるソフトウェアで、今後何かを作っていく時のヒントにしていきたいですね。

  • コメント (Close): 0
  • トラックバック (Close): 0

開発現場で Docker をどこで使うか考えてみた

この記事の所要時間: 657

Shin x blog Advent Calendar 2013 の 16 日目です。

docker

最近話題の Docker 色々と触っています。

触ってみる中で、普段の開発現場でどのような用途に使えそうなのかを考えています。こうだ!という結論が出ているわけではないのですが、一度書き出してみます。

前提

  • Webシステムの開発現場を想定しています。
  • 言語は普段使っている PHP ですが、内容にはあまり関係無いです。
  • 開発機には Mac OSX を使っています。

検証環境(サンドボックス)

まず一番に思いつくのが、検証環境としての利用です。Docker を使えば、OS のみがインストールされている状態のコンテナを手軽に作成できるので、そこでミドルウェアのインストール、設定などを自由に行い、検証が済んだら、破棄します。

OSX 環境では Docker は動かないので、Vagrant + VirtualBox 上の VM に Linux 環境を構築して、その上で、Docker を動かします。

Docker のインストールは、Vagrantfile に仕込んでおき、vagrant up すれば、Docker デーモンが起動している状態にします。

SSH でログインして、docker run してコンテナを起動するイメージです。dockerui を VM or docker コンテナで動かして、OSX のブラウザからコンテナする方法もありますね。

例えば、先日のエントリでは、下記のコマンドで CentOS の Docker コンテナを使って、コンテナ作成、yum インストール、コンテナ破棄を繰り返しました。vagrant up & destory を繰り返すより、圧倒的に速いので、かなり効率が良いです。

$ sudo docker run -i -t centos /bin/bash
# yum -y install php
# exit

開発環境

Web システムの開発環境としての利用です。

Vagrant と用途としては似ており、環境構築の自動化、VCS でのバージョン管理、共有などが可能です。

OSX で開発を行う場合、開発ツールは OSX のものを使い、コードの実行をコンテナ内にしたいと思うのですが、ファイル共有は Vagrant の synced_folder と docker run の -v オプションを、OSX のブラウザからコンテナ内へのアクセス(通信)も Vagrant の ポートフォワーディングや private_network と docker run の -p オプションを組み合わせることで可能です。

ただ、実用では考えないといけない点が、2 点あります。

まず、プロジェクトごとに VM を作って、そこに Docker コンテナを作るか、ひとつの VM に複数プロジェクトの Docker コンテナを集積させるかについてです。

前者の場合は、従来プロジェクトごとに Vagrantfile を作っていたのと同じ感覚で Dockerfile を管理できるので管理は楽です。こうなると VM は Docker を動かすだけのプラットフォームに過ぎないようになります。つまり VM の OS は Docker さえ動けばどれでも良く、CoreOS などの軽量な OS を使う方向に進みそうです。ただ、プロジェクトごとに VM が起動するので、Vagrant で VM を作って、プロビジョニングするのとそれほど変わらないといえば、そうかもしれません。

後者の場合、一つの VM 上でプロジェクト毎の Docker コンテナを起動するので、OSX 上で動かす VM は一つだけで良くなります。モバイルなどバッテリ駆動での作業を考えると、起動する VM は少ない方が良さそうです。また、一つの VM を共有するので、Docker イメージのキャッシュを生かすことができます。いつも同じイメージをベースにするのなら、キャシュ済イメージからコンテナを生成できるので、高速に起動することができます。

次に、これは開発環境に限らずですが、Web システムを構成するコンポーネント(Web / App / DB等)をそれぞれ独立したコンテナにするか、一つのコンテナに入れてしまうかです。

前者の場合、それぞれのコンテナを部品として扱いやすく、再利用性は高まります。docker run を複数回実行する必要はありますが、Vagrantfile に記述しておけば良いので、それはあまり問題にならないです。本番環境にて、各コンポーネントを分離している場合や、外部サービス(RDSなど)を利用する場合は、そもそも別ノードにあるコンポーネントと協調して動くことが想定されているので、この方がより稼働環境に近くなるとも言えます。

ただ、上述したように、もし一つの VM で複数プロジェクトのコンテナを動かす場合、どのプロジェクトのコンテナなのかを判別して、起動ポートなども調整する必要があり、このあたりの管理が煩雑になりそうです。

後者の場合、プロジェクトで利用するコンポーネントを全て一つのコンテナに収容するので、見た目として分かりやすいです。一つの Dockerfile で収まるので、コンテナ構築のコードも見通しは良いです。(ただ複数コンポーネントをプロビジョニングするコードが内包するので複雑になりがちです。各コンポーネンのコードは別ファイルにするなどが必要。)ただ、本番環境では、多くの場合、何でも入りコンテナ一つで動かすのではなく、少なくとも DB は別ノードになるなど分離することが多いので、そうなるとアプリケーション以外のコンポーネントは不要になるかもしれません。

まだ全てが Docker コンテナで完結するわけではないので、開発環境と割り切れば、一つのコンテナにまとめるのは悪くないと思います。

CI 環境

CI において、テストを実行する環境としての利用です。

ここでも Docker コンテナの起動の速さは生きてきますね。これも構成の悩みは、開発環境と同じですが、いずれにせよ、 コンテナ構築からテスト実行、コンテナ破棄まで自動実行するので、開発環境に合わせた構成で良いと思います。

できれば、CI でテスト実行したコンテナを、そのまま本番環境へデプロイできたりすると美しいです。

コンテナビルド、テスト実行、テスト完了なら、ビルドしたコンテナをそのまま本番環境へデプロイという流れです。CI サーバがアプリケーションを生成して出荷する工場になるイメージですね。

本番環境

CI 環境でも書きましたが、Docker コンテナを利用している PaaS はありますが、Docker コンテナをそのままデプロイする環境というのはまだ無いように思います。(あったら教えて下さいm(_ _)m)

CI 環境で構築したコンテナをどうデプロイするかですが、直接コンテナを送信するのがまず一つです。ただ、できれば docker push で、コンテナリポジトリに push するとそれが本番環境へデプロイされたりすると良いですね。現在は index.docker.io へ push するのみで、さらに index.docker.io では公開コンテナした置けないのですが、外部リポジトリに push できたり、index.docker.io にプライベートなコンテナを置けたりするようになると利便性が上がります。

今のところは、Dockerfile を送信して、本番環境でコンテナをビルドするという形が現実的ですね。

さいごに

Docker をどう使うかを考えてみました。といってもまだアイデアレベルなのですが、試しながら、もやもやと考えている日々です。

まだ模索中なので、こうしてるよ、こうした方が良いよなどアドバイスあれば、教えて頂けると嬉しいです 😀

これから触ってみようという方は、入り口として、検証を行うサンドボックスとして使ってみるのがおすすめです。

  • コメント (Close): 0
  • トラックバック (Close): 0

ざっくり分かる Vagrant 1.4 / Docker Provisioner

この記事の所要時間: 745

Shin x blog Advent Calendar 2013 の 10 日目です。

vagrant

Vagrant 1.4 がリリースされました。Docker Provisioner を中心に新機能をざっくりと見てみました。

ダウンロードページの変更

さあ、1.4 をダウンロードしよう、と今までのダウンロードページに行くと 1.4 のリンクがありません><

新しいダウンロードページからダウンロードしましょう。

Download Vagrant – Vagrant

Docker Provisioner

Docker 対応として Docker Provisioner が追加されました。

このプロビジョナを使うと Docker 自体のインストールが自動で行われ(!)、その後、docker pull や docker run を実行することができます。

下記の Vagrantfile では Docker Provisioner を使って、docker run を実行する例です。

他のプロビジョナ( chef や puppet 等)と一緒に使うことも可能なようです。

precise64 Box ファイルで vagrant up してみました。Docker インストールやコンテナ実行が行われていますね。

$ vagrant up
(snip)
[default] Running provisioner: docker...
[default] Installing Docker (latest) onto machine...
[default] Starting Docker containers...
[default] -- Container: ubuntu
$

vagrant ssh して、VM の中に入りました。Docker は最新の 0.7.1 が入っています。

vagrant@precise64:~$ docker info
Client version: 0.7.1
Go version (client): go1.2
Git commit (client): 88df052
Server version: 0.7.1
Git commit (server): 88df052
Go version (server): go1.2
Last stable version: 0.7.1
Go version (client): go1.2

docker info を見ると aufs が Driver となっています。

vagrant@precise64:~$ docker info
Containers: 1
Images: 3
Driver: aufs
 Root Dir: /var/lib/docker/aufs
  Dirs: 5

docker ps -a で確認すると、Vagrantfile に書いた bash コマンドが実行されていました。

vagrant@precise64:~$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
54ead2bad23d        ubuntu:12.04        bash -l             About a minute ago   Exit 0                                  condescending_albattani

Docker – Provisioning – Vagrant Documentation

CentOS の Box ファイル

CentOS 6.5 の Box ファイルでも試してみました。上記の Vagrantfile から box ファイルを変更しただけです。

$ vagrant up
(snip)
[default] Running provisioner: docker...
[default] Installing Docker (latest) onto machine...
Vagrant attempted to execute the capability 'docker_install'
on the detect guest OS 'redhat', but the guest doesn't
support that capability. This capability is required for your
configuration of Vagrant. Please either reconfigure Vagrant to
avoid this capability or fix the issue by creating the capability.
$

あ、エラーになりました。redhat 系のゲスト OS はサポートしていないようです。。。Docker 自体は、CentOS で動くようになっているので、今後に期待ですね。

private network を設定しているとエラー

private network を設定しているとエラーが発生する場合があるようです。

“Configuring and enabling network interfaces” fails with ssh error Issue #2614 mitchellh/vagrant

他の新機能

Machine-Readable Output

システムが読み込みやすい形式で、vagrant コマンドの実行結果?を出力します。changelog を見ると –machine-readable フラグを使うようなのです。

試しに vagrant up –machine-readable を実行したのですが、何も出力されませんでした。

Machine Readable Output – Command-Line Interface – Vagrant Documentation

Enforcing a Vagrant Version

Vagrant.require_version オプションを Vagrantfile に記述することで、実行する vagrant のバージョンを指定できます。バージョンが合わないために予期せぬ挙動になることを防止します。

Synced Folder Plugins

synced_folder の実装をプラグインで行うことができるようになりました。nfs がプラグインとして提供されています。

すでに、rsync, scp, NFS(ホストがゲストをマウントするパターン))のプラグイン実装が存在するようです。

Box downloading will resume if interrupted

Box ファイルのダウンロードが中断しても、次回再開できるようになりました。

Box checksums

追加した BOX ファイルのチェックサムを検証します。

NFS on VirtualBox no longer requires a static IP

VirtualBox 上の NFS では、static IP が必要なくなりました。

Running multiple “vagrant up” commands in parallel with VirtualBox

VirtualBox での vagrant up を並行して実行できるようになりました。CI 環境などでは有効ですね。( Docker で良いかもしれませんが。)

Multiple SSH keys

複数の SSH Key を指定することが可能になりました。また、プロビジョニングで、安全ではない Vagrant のキーをより安全なキーに置き換えることもできます。

さいごに

synced_folder のプラグイン化や、Box ファイルダウンロードの resume 機能など色々な改良が施されたバージョンですが、今回の目玉は、Docker Provisioner ですね。

これまでもプロビジョニングで Docker インストールや docker コマンドの実行は可能でしたが、Docker Provisioner の登場により、さらに手軽に Docker を利用できます。

Docker を利用するベースとして Vagrant を使うというシーンが増えていきそうです。

Vagrant 1.4 – Vagrant

  • コメント (Close): 0
  • トラックバック (Close): 0

WordPress を Docker で動かす( OSX / Vagrant )

この記事の所要時間: 319

Shin x blog Advent Calendar 2013 の 9 日目です。

wordpress_on_docker

Docker で PHP アプリケーションを動かしてみようということで、WordPress でやってみます。

WordPress 用 Docker コンテナを作る

Docker は現状 Linux 上でしか動かないので、OSX 上では直接動きません。Vagrant で Linux(CentOS)の仮想マシンを作り、その上で Docker を動かします。

さっそく Linux 環境から WordPress が動く Docker コンテナまで、一気に構築できる Vagrantfile を作りました。これを使うだけで環境構築は終わりです。

shin1x1/vagrant-docker-wpdev

まず、GitHub から git clone します。

$ git clone https://github.com/shin1x1/vagrant-docker-wpdev
$ cd vagrant-docker-wpdev
$ ls
wordpress/ Vagrantfile

vagrant up で、仮想マシンを起動します。自動で、Docker のインストール、Docker イメージを生成、コンテナの起動と一連の流れが実行されます。

$ vagrant up
(snip)
Step 29 : ENTRYPOINT ["/usr/bin/supervisord"]
 ---> Running in 43bd85e2cde6
 ---> f846d6a8f9fb
Successfully built f846d6a8f9fb
751f8c8e48519ca624a9167b46b3cbd406b7aeb4ded70b0356992ff3dadc50f0
$ 

vagrant up コマンドが完了したら、OSX のブラウザから http://192.168.33.11/ にアクセスしましょう。

WordPress の初期画面が表示されれば ok です。

docker-wordpress-init

ではウィザードを進んで設定を行いましょう。データベースの設定には、データベース名=「test」、データベースユーザ名=「root」、データベースパスワード=「docker」に設定して下さい。

docker-wordpress

これで Docker で動く WordPress ができました。やったね!

WordPress の編集

WordPress のソースコードは、OSX の wordpress/ ディレクトリにあります。

このディレクトリは Docker コンテナから参照しているので、OSX 上で編集、ブラウザで確認という流れで作業を進めることができます。

docker-wpdev

この Vagrantfile では、WordPress の Docker コンテナとして、docker-wpdev を利用しています。

WordPress の Docker コンテナはいくつか公開されているのですが、docker-wpdev はソースコードのディレクトリをホスト側からマウントする機構になっており、開発環境などでソースコードを頻繁に書き換える用途に向いていますね。

さいごに

Docker は面白い OSS なのですが、Linux 上でしか動かないため、OSX では Vagrant などで Linux 環境を用意する必要があります。

ここでは CentOS を Linux 環境として使いましたが、Docker を動かすだけなら、より軽量な CoreOSboot2docker を使う方が良いかもしれません。(ダウンロードも速いですし)

Docker が OSX 上で動くようになるといいなあ。

  • コメント (Close): 0
  • トラックバック (Close): 0

Docker ストレージドライバによる RHEL/CentOS 対応について

この記事の所要時間: 130

Shin x blog Advent Calendar 2013 の 8 日目です。

docker

これまで Docker を RHEL/CentOS で動かす際に懸案だったのは、AUFS への対応でした。RHEL/CentOS 6.x のカーネルは AUFS へ対応していないので、Docker を動かすには、AUFS 対応のカーネルを入れる必要がありました。

Docker 0.7 では、この対応としてストレージドライバという機構が採用されました。

ここでは、ストレージドライバによる RHEL/CentOS 対応について見てみます。

CentOS 6.5 で利用されているストレージドライバ

Docker 0.7 で採用されたストレージドライバは、Docker コンテナが利用するファイルシステムを選択する機構です。これにより、AUFS 以外のファイルシステムを利用ことが可能になっています。0.7 では、aufs / devicemapper / vfs の 3 つのドライバーが存在します。

この中で、RHEL/CentOS では devicemapper というドライバが利用されています。

どのドライバが利用されているかを確認するのには、docker info コマンドを実行します。

CentOS 6.5 で docker info コマンドで確認すると下記のようになります。Driver: の箇所が devicemapper と表示されており、これがドライバとして利用されているのが分かります。

[vagrant@localhost ~]$ sudo docker info
Containers: 47
Images: 24
Driver: devicemapper // <----
  Pool Name: docker-253:0-1835642-pool
  Data file: /var/lib/docker/devicemapper/devicemapper/data
  Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
  Data Space Used: 1790.1 Mb
  Data Space Total: 102400.0 Mb
  Metadata Space Used: 4.7 Mb
  Metadata Space Total: 2048.0 Mb

ちなみに ubuntu 上で docker info を実行すると、こちらは aufs と表示されます。

vagrant@precise64:~$ sudo docker info
Containers: 2
Images: 1
Driver: aufs
 Root Dir: /var/lib/docker/aufs
  Dirs: 5
  WARNING: No swap limit support

AUFS 以外のストレージドライバ採用の経緯

AUFS 以外のストレージドライバとして何を利用するかの経緯については、community.redhat.com にエントリがあります。

Adventures in Dockerland | Open Source Community

まず、AUFS について。AUFS は、現在の Ubuntu カーネルでは非推奨となっていて、いずれは削除されるようです。

このため、RHEL/CentOS 対応を行うかどうかに関わらず、AUFS 以外のストレージドライバへの対応が必要だったように思います。

そして、AUFS に変わるコピーオンライトなストレージとして、下記の 4 つが検討されていました。

  • overlayfs
  • btrfs
  • lvm snapshots
  • lvm thin provisioning

結果的には、最後の lvm thin provisioning が採用されており、devicemapper ドライバとして実装されています。こうして RHEL/CentOS でも Docker が利用できるようになりました。

件のエントリでは、それぞれの方法についての考察なども書かれていますので、気になる方は読んで見てください。

CentOS 6.4 で Docker を動かす

Docker 0.7 で対応した lvm thin provisioning は、RHEL/CentOS 6.4 からサポートされているので、CentOS 6.4 環境でも Docker が動きそうです。

そこで、Vagrant 上の CentOS 6.4 でも試してみました。インストール方法などは前エントリのままです。

$ cat /etc/redhat-release
CentOS release 6.4 (Final)

$ sudo docker run -i -t centos /bin/bash
bash-4.1#

$ sudo docker info
Containers: 0
Images: 0
Driver: devicemapper
  Pool Name: docker-253:0-262375-pool
  Data file: /var/lib/docker/devicemapper/devicemapper/data
  Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
  Data Space Used: 291.5 Mb
  Data Space Total: 102400.0 Mb
  Metadata Space Used: 0.7 Mb
  Metadata Space Total: 2048.0 Mb

ちゃんと動いてますね。docker info コマンドでは、Driver は、ちゃんと devicemapper になっています。

CentOS 6.3 で Docker を動かない?

では逆に動かないところも見てみたいので、次は CentOS 6.3 でも試してみました。

適当な Box ファイルが手元に無かったので、AWS Marketplace にある CentOS 6.3 の AMI を使いました。

# cat /etc/redhat-release
CentOS release 6.3 (Final)

# docker run -i -t centos /bin/bash
bash-4.1#

# docker info
Containers: 9
Images: 2
Driver: devicemapper
  Pool Name: docker-202:64-9417-pool
  Data file: /var/lib/docker/devicemapper/devicemapper/data
  Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
  Data Space Used: 858.7 Mb
  Data Space Total: 102400.0 Mb
  Metadata Space Used: 1.7 Mb
  Metadata Space Total: 2048.0 Mb

あれ?ちゃんと動いていますね。Driver も devicemapper になっています。コンテナ内で yum など使っていくつかパッケージをインストールしたり、docker commit でイメージを作ったりしましたが、正常に動いているようでした。

調べてみると、lvm thin provisioning は正式採用されたのは 6.4 ですが、6.3 の段階で Technology Preview として実装されていたようです。なるほど。

LVM の Thin Provisioning 型 LV とスナップショット利用

6.2 なら、Driver: vfs となり、違った挙動が見れるのかもしれません。

利用するストレージドライバの決定

Docker が環境に応じてどのようにストレージドライバを決定しているかを見てみました。

利用するストレージドライバの決定は、graphdriver/driver.go にある New メソッドにて行われます。下記が該当ソースです。

まず、環境変数やオプションによるドライバ指定を処理します。すでにドライバが指定されていれば、そのドライバを利用します。

その後に priority 変数の順に利用するドライバを決定します。それぞれのドライバが利用できるかチェックして、利用できるならば、それを使います。priority は、下記のように定義されているので、aufs / devicemapper / vfs の順でチェックが行われます。

このように通常、ストレージドライバは自動で決定されます。

一方、環境変数や -s オプションを使うことで利用するドライバを指定することも可能です。

下記では、docker コマンドに -s オプションに vfs を指定して、docker デーモンを起動しています。docker info を見ると vfs がドライバとして利用されていることが分かります。

$ sudo service docker stop # docker を一旦停止
$ sudo docker -d -s vfs # docker コマンドから、docker デーモンを起動

$ sudo docker info
Containers: 0
Images: 0
Driver: vfs

さいごに

Docker 0.7 でサポートされたストレージドライバによる RHEL/CentOS サポートについて見てみました。

コピーオンライトなストレージは、Docker における重要な技術なので、今後もより良い環境を求めて、他のファイルシステムへの対応が進みそうです。

ここで見たようにストレージドライバに関しては RHEL/CentOS 6.4 環境でも動いているので、6.5 環境がまだ無い人は試してみて下さい。

参考

  • コメント (Close): 0
  • トラックバック (Close): 0

ホーム > Docker

検索
フィード
メタ情報

Return to page top