Advent Calendar 2013 Archive

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

最近話題の 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 をどう使うかを考えてみました。といってもまだアイデアレベルなのですが、試しながら、もやもやと考えている日々です。

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

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

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

Cent OS 5, 6 / Amazon Linux にて、PHP の各バージョンを yum でインストールする方法をまとめてみました。

• CentOS 6
• CentOS 5
• Amazon Linux

CentOS 6

PHP 5.3

CentOS 6 では、公式パッケージが PHP 5.3.3 なので、公式のリポジトリからインストールできます。

$ sudo yum -y install php
(snip)

$ php -v
PHP 5.3.3 (cli) (built: Dec 11 2013 03:29:57)

パッケージバージョンは 5.3.3–27 となっています。これは主にセキュリティ上の問題が発生した場合にパッチが提供されているためで、最新のビルドは、2013/12/10 になっています。

$ sudo rpm -qi php
Name        : php                          Relocations: (not relocatable)
  Version     : 5.3.3                             Vendor: CentOS
  Release     : 27.el6_5                      Build Date: Tue Dec 10 22:38:18 2013
  Install Date: Sat Dec 14 22:01:49 2013         Build Host: c6b10.bsys.dev.centos.org
  Group       : Development/Languages         Source RPM: php-5.3.3-27.el6_5.src.rpm
  Size        : 3702221                          License: PHP
  Signature   : RSA/SHA1, Wed Dec 11 04:24:11 2013, Key ID 0946fca2c105b9de
  Packager    : CentOS BuildSystem 
  URL         : http://www.php.net/
  Summary     : PHP scripting language for creating dynamic web sites

PHP 5.4

CentOS のリポジトリでは PHP 5.4 は提供されていないので、外部のリポジトリからインストールします。

ここでは、PHP 5.4 を提供しているリポジトリのうち、remi / IUS を利用します。

remi

remi リポジトリは、Fedora プロジェクトのコントリビュータでもある Remi Collet 氏が運営しているリポジトリです。

PHP の新バージョンがリリースされるごとに該当バージョンの RPM を作成し、配布しています。旧 php.net サイトから、外部リポジトリとしてリンクされていたので、PHP ユーザにはお馴染みですね。

まず、remi リポジトリを有効にするために RPM をインストールします。remi リポジトリには epel リポジトリが必要なので、こちらもインストールしておきます。

$ sudo rpm -Uvh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/i386/epel-release-6-8.noarch.rpm
$ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

PHP 5.4 を remi リポジトリからインストールします。パッケージ名は php です。remi リポジトリはデフォルトでは有効にならないので、–enablerepo オプションで指定します。

リリースされたばかりの PHP 5.4.23 がインストールされました。ビルド日時は、2013/12/11 となっています。

$ sudo yum -y install php --enablerepo=remi
(snip)

$ php -v
PHP 5.4.23 (cli) (built: Dec 11 2013 06:48:07)

IUS

IUS は、Rackspace が運営しているリポジトリです。

「Rackspace RPM の Fedora」と書かれているとおり、新しいパッケージは、まず IUS で公開し、プロダクション環境での利用が検証できた後に、Rackspace 顧客用のエンタープライズパッケージとして提供しているようです。

IUS リポジトリを利用するために ius-release と epel-release パッケージをインストールします。

$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/epel-release-6-5.noarch.rpm
$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/ius-release-1.0-11.ius.centos6.noarch.rpm

PHP 5.4 を IUS リポジトリからインストールします。パッケージ名は php54 です。IUS リポジトリはデフォルトでは有効にならないので、–enablerepo オプションで指定します。

最新版の 5.4.23 ではなく、5.4.22 がインストールされました。ビルド日時は、2013/11/15 となっています。

$ yum -y install php54 --enablerepo=ius
(snip)

$ php -v
PHP 5.4.22 (cli) (built: Nov 15 2013 10:13:25)

IUS では、新しいパッケージは、まず ius-testing リポジトリで検証を行い、その後 ius リポジトリへ展開される流れになっているので、isu-testing リポジトリを見てみると、最新の 5.4.23 が公開されていました。検証環境などで、すぐに新しいバージョンを使いたい場合は、ius-testing を利用すると良いでしょう。

$ sudo yum info php54 --enablerepo=ius-testing
(snip)
Available Packages
Name        : php54
Arch        : x86_64
Version     : 5.4.23
Release     : 3.ius.centos6
Size        : 2.7 M
Repo        : ius-testing
(snip)

PHP 5.5

PHP 5.5 も公式リポジトリでは提供されていないので、remi / IUS からインストールします。

remi

remi の PHP 5.5 は、remi-php55 というリポジトリにて提供されていますので、–enablerepo では、remi-php55 を指定します。パッケージ名は php になります。

最新版の 5.5.7 がインストールされました。ビルド日時は、2013/12/11 です。

$ sudo yum -y install php --enablerepo=remi-php55
(snip)

$ php -v
PHP 5.5.7 (cli) (built: Dec 11 2013 07:13:20)

IUS

IUS では、ius リポジトリにて PHP 5.5 が提供されているので、パッケージ名を php55u に変更します。

最新版から一つ前の 5.5.6 がインストールされました。ビルド日時は、2013/12/04 です。

$ sudo yum -y isntall php55u --enablerepo=ius
(snip)

$ php -v
PHP 5.5.6 (cli) (built: Dec  4 2013 17:19:08)

なお、5.4 と同じく ius-testing リポジトリを見ると、最新版の 5.5.7 が提供されていました。

$ sudo yum info php55u --enablerepo=ius-testing
(snip)
Name        : php55u
Arch        : x86_64
Version     : 5.5.7
Release     : 1.ius.centos6
Size        : 2.6 M
Repo        : ius-testing
(snip)

CentOS 5

PHP 5.1

CentOS 5 では、ベンダー提供の標準 RPM が、PHP 5.1.6 なので、公式 yum リポジトリから yum install でインストールできます。

5.1.6 はかなり古いバージョンですが、現在もパッチの提供が続けられています。最新ビルドは、2013/12/10 となっていました。

$ sudo yum -y install php
(snip)

$ php -v
PHP 5.1.6 (cli) (built: Dec 10 2013 22:08:48)

PHP 5.3

公式リポジトリにて PHP 5.3 パッケージも配布されています。パッケージ名は php53 となっています。

CentOS 6 と同じく、PHP 5.3.3 がインストールされます。ビルド日時は、2013/12/10 です。

$ sudo yum -y install php53
(snip)

$ php -v
PHP 5.3.3 (cli) (built: Dec 10 2013 22:12:52)

PHP 5.4, 5.5

CentOS 6 と同じく、外部リポジトリを利用してインストールします。

remi / IUS 共に、CentOS 5 用の release パッケージが提供されていますので、こちらをインストールします。各 PHP のインストールは、CentOS 6 と同じです。

remi

epel-release と remi-release パッケージをインストールします。

$ sudo rpm -Uvh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/i386/epel-release-6-8.noarch.rpm
$ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

IUS

epel-release と ius-release パッケージをインストールします。なお IUS では、PHP 5.4 は提供されていますが、PHP 5.5 は提供されていませんでした。

$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/5/x86_64/epel-release-5-4.noarch.rpm
$ sudo rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/CentOS/5/x86_64/ius-release-1.0-11.ius.centos5.noarch.rpm

Amazon Linux

Amazon Linux では、公式リポジトリにて、PHP 5.3, 5.4, 5.5 が提供されています。

同じリポジトリで提供されているので、パッケージ名にてインストールするバージョンを指定します。

PHP 5.3

パッケージ名を php でインストールします。最新版一つ前の 5.3.27 が提供されています。ビルド日時は、2013/07/12 です。

$ sudo yum -y install php
(snip)

$ php -v
PHP 5.3.27 (cli) (built: Jul 12 2013 22:04:28)

PHP 5.4

パッケージ名を php54 でインストールします。最新版一つ前の 5.4.22 が提供されています。ビルド日時は、2013/12/09 です。

$ sudo yum -y install php54
(snip)

$ php -v
PHP 5.4.22 (cli) (built: Dec  9 2013 18:19:32)

PHP 5.5

パッケージ名を php55 でインストールします。最新版一つ前の 5.5.6 が提供されています。ビルド日時は、2013/12/09 です。

$ sudo yum -y install php55
(snip)

$ php -v
PHP 5.5.6 (cli) (built: Dec  9 2013 18:09:49)

さいごに

CentOS / Amazon Linux にて PHP を yum でインストールする方法を見てきました。現在は、PHP 5.3, 5.4, 5.5 どのバージョンにおいても yum でインストールすることが可能です。

検証は、CentOS 6 は Vagrant + VirtualBox + Docker 、CentOS 5 は Vagrant + VirtualBox で、Amazon Linux は AWS で行いました。こういった類の検証では、Docker コンテナの起動の速さは便利ですね。Vagrant ですら昨年の今頃はまだ触った程度だったのに、ここ一年の進化は早いものです。

参考

• Repositories — IUS Community Project 0.1 documentation
• English : Repository Configuration – Les RPM de Remi – Blog

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

PHP の高速な実行環境として知られる HHVM の新しいバージョン 2.3.0 がリリースされました。

今回のリリースでは、オープンソースプロジェクトの CI サービスとして人気の Travis CI へのサポートが発表されました。以前から Travis CI では、PHP 5.2 から PHP 5.5 の実行環境がサポートされていたのですが、ここに HHVM 環境が新たに加わることになります。

さっそく、Travis CI の HHVM 環境を試してみました。

Travis CI の設定

Travis CI 上で HHVM 環境でのテストを行う設定は簡単です。.travis.yml の php: に hhvm を追加するだけです。

php:
  - hhvm

これで、次回のテストから hhvm 環境で実行されます。

Travis CI の HHVM 環境でテスト

簡単な PHP プロジェクトをテストしてみます。ソースコードは下記になります。

shin1x1/travis-ci-sample

ここでは足し算を行う TravisCISample\Calculator クラスを作り、そのテストを PHPUnit で書きました。ローカルで phpunit を実行するとテストが通ります。

$ ./vendor/bin/phpunit --colors test
PHPUnit 3.7.28 by Sebastian Bergmann.

.

Time: 23 ms, Memory: 2.25Mb

OK (1 test, 1 assertion)

Travis CI の設定を .travis.yml に書きました。PHP 5.3 から 5.5、そして HHVM を実行環境として設定しています。

language: php

php:
- 5.3
- 5.4
- 5.5
- hhvm

before_install:
- composer install

script:
- phpunit --colors --coverage-text test

このコードを GitHub に push します。あらかじめ Travis CI では、このプロジェクトを CI の対象として設定しているので、push するとテストが実行されます。

テスト結果が下記です。PHP のバージョンとして、HHVM 環境で実行されています。今回のテストに関しては、HHVM 上でも動作することが分かりました。

https://travis-ci.org/shin1x1/travis-ci-sample/builds/15438927

つまづいた点

HHVM 環境を試してみて、つまづいた点を。

Composer インストール

.travis.yml の before_install に curl -sS https://getcomposer.org/installer | php を入れていたのですが、下記のエラーが出てビルドが停止しました。HHVM では、標準入力による PHP スクリプト実行はサポートされていないのかもしれません。

そもそも Travis CI の環境では、composer コマンドが用意されており composer.phar をインストールする必要が無かったので、この処理は省きました。

HipHop Notice: Nothing to do. Either pass a .php file to run, or use -m server

The command "php" failed and exited with 1 during before_install.

https://travis-ci.org/shin1x1/travis-ci-sample/jobs/15438538

php -q オプション

これは CakePHP のコードを HHVM で動かした時に発生したのですが、内部で php コマンドに -q オプションを付けて実行している箇所があり、このオプションを HHVM が対応していないためにエラーとなりました。

ためしに -q オプションを削除して実行してみると、その箇所は動作するようになりました。（また別のエラーが出ていますが。）

Error in command line: unknown option -q

https://travis-ci.org/shin1x1/cakephp/jobs/15436509

2.3 のリリースを見ると、HHVM 環境では HHVM_VERSION という定数が定義されるようなので、これ使えば、HHVM 固有の処理を記述ことができそうです。

if (defined('HHVM_VERSION')) {
    // HHVM 環境のみの処理
}

さいごに

Travis CI で簡単に HHVM 環境を使えることが分かりました。

本番環境として HHVM を使うようになるかどうかは分かりませんが、Travis CI なら自分で環境を作ること無く試すことができるのが良いです。

今回は簡単なスクリプトでしたが、PHP の実行速度を問われるようなコードであれば、HHVM の性能を測る手段としても使えそうですね。

HHVM 2.3.0 and Travis CI « HipHop Virtual Machine

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

Web 制作においては、黒い画面を使うことで利用できる便利なツールがいくつかあります。ただ、日頃から「黒い画面」を使っていない人にとっては中々馴染みが無いものです。

そうしたツールを学ぶにも、まずは「黒い画面」を出してみないことには始まりません。ここでは「黒い画面」の出し方について書いてみます。

黒い画面を出す

黒い画面というのは通称で、Mac の場合は「ターミナル」というソフトがそれにあたります。

ターミナルは、Finder から開くことができますので、実際に起動してみましょう。

まず、Finder を起動して、「アプリケーション」フォルダを開きます。そして、中にある「ユーティリティ」フォルダを開きます。

（「ユーティリティ」フォルダは、Finder を起動して Command ＋ Shift ＋ u で開くこともできます。 @msng さん、ありがとう！）

「ユーティリティ」フォルダの中に「ターミナル」というソフトがあります。これが黒い画面を開くソフトです。

では、「ターミナル」をダブルクリックして起動してみましょう。下記のようなウィンドウが出てきます。

これでターミナルが起動しました。

黒い画面にする

うん？黒い画面じゃないぞ？はい、そうです。実は Mac のターミナルはデフォルトでは白い画面になっています。これはただの見た目だけなので、このまま利用しても問題ありません。

ただ、どうせなら「黒い画面」を体験したいということなら、設定を変更して黒い画面にしてみましょう。

ターミナルの設定は「環境設定」で行います。

起動時に開くにある「次の設定の新しいウィンドウ」を「Basic」から「Pro」に変更します。これで次に起動したときから、黒い画面が出るようになります。

いったんターミナルを終了して、再度起動すると「黒い画面」が出ました！

さいごに

日頃は iTerm2 をターミナルとして利用しているのですが、ときおり他人のMacを触る際にターミナルがどこにあるのかを迷う時がありました。（自分環境ではランチャーで起動しているので。）

ハンズオンイベントなどでも、このターミナルに辿り着くまででつまづく人が多かったので、この手順で黒い画面を開いてみてください。

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

写真の本は「MSXマシン語入門講座」という本です。この本を買ったのはもう 20 年以上前のことになります。

私にとっては、プログラムを学ぶ上で、また、何かにチャレンジする上で良い教訓を得た一冊です。

BASIC でゲームを作る

中学生の頃、ファミコンのゲームが好きだったので、その延長線上で MSX2（FS-A1）というパソコンを購入しました。

当初は、ファミコンとは違うゲームができるもの程度の認識しか持っていなかったのですが、なんとなくプログラムには興味があったので、付属していたBASICの入門書を片手にプログラムを作るようになりました。

サンプルソースを入力して、動かしてを繰り返す内に、少しづつBASICが分かるようになったきたので、次はBASICでゲーム作りにチャレンジするようになりました。

Z80 アセンブラへの挑戦

BASICで小さなゲーム（ほんと小さなゲーム）が作れるようになると、もっとちゃんとしたゲーム、販売されているようなゲームが作りたくなってきます。

そこで次にチャレンジしたのが、Z80アセンブラです。

当初触っていたBASICはインタプリタ型の言語（コンパイル不要の言語。まあPHPとかもそうですね。）で、書いてすぐ動かせるのが特徴です。入門としてはすごく良いのですが、いかんせん当時のMSXはリソースが少なく（メインメモリが64KBしかない。MB じゃないですよ。ちなみにこれ書いてる MacBook Air は、8GB です。）、凝ったことをするとBASICでは厳しくなります。

そこで、より速いプログラムが書けるように Z80（MSXのCPU）のマシン語を覚えたいと思うようになりました。

まずは勉強を、と思って買ったのが冒頭にある本です。

ワクワクして本を開いてみると、

「全く分からん。。。」

びっくりするくらい分からない。書いてある事自体はなんとなく理解できますが、それがどうなってゲームが作れるのかが全く分からない。

その後、何度か通読してみましたが、やっぱり分からない。最後には「ああ、自分にはプログラムの才能が無いんだ。」などと思い、半ば諦めて放置していました。

氷解、そして専門誌への掲載

諦めたものの、何だか分からないままというのは悔しい。しかも買ってきたのは入門の本。そして、やっぱりゲームは作りたい。

期間は開けながらですが、たまに開いて、諦めてを繰り返す内に、ある日からだんだんとうっすらとですが、イメージができるようになってきました。

何がきっかけだったかは、もう忘れてしまったのですが、いつしかすんなりと理解できるようになり、Z80マシン語（というかアセンブラですが）でゲームが作れるようになりました。

その後はゲーム作りに没頭して、またまた何度かの挑戦を経て、当時あったMSX専門誌へ掲載されるゲームが作れるようになりました。（読者投稿のコーナーがあって、みんながこぞって自作ゲームを送るのが流行りだった。掲載料も出たので、プログラムを書いてお金を貰ったのは、これが初めて。）

あとで分かったのですが、あれだけ理解できなかった冒頭の本は、本当に入門の本で、書けるようになったあとは逆に読み返さないような内容でした。

さいごに

これは無理！と思っていた事にチャレンジしてみて、やっぱり上手くいかず、でも諦めず何度もチャレンジして、そしていつか成し遂げる。

どんな事柄（難易度は主観）でも、一度でもそういった経験を持っていると、次の困難に遭遇した時も「いつかはできるようになるかも」と思って立ち向かうことができます。

その後、何度もこういった場面がありましたが、いくつかの事は実際にできるようになりました。考えてみると、いま普通にやっているようなことも、はじめはできなかったことばかりです。

まだまだできないことだらけですが、少しづつ、少しづつで良いので、やっていきたいものです。

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

日常が忙しく、新しい技術なんか追ってられない。わかります。

そんなの使うかどうかも分からないのに今やる必要無いよね。困った時に探せば良いでしょ。それもわかります。

そんな忙しい毎日だからこそ、技術の「種」くらいは蒔いておきましょうという話です。

技術の種

「技術の種」とは何でしょう。

私がイメージしているのは、その技術のイメージをざっくりと朧気ながらで良いので掴んでおくということです。（ユースケースもあるとより良いです。）

きちんと土を掘って、一つ一つ植えられれば良いのですが、じっくりと植える時間はなかなか無いと思うので、とりあえずバサッとで良いので、撒き散らしておきます。

そうしておいた種は、何かのきっかけで芽を出すことがあります。

多くは解決すべき問題に直面した時です。この問題は手元の技術では解決できないものだったり、解決できても効率が悪いものだったりします。

その時に種がひょこっと芽を出します。「これ、あるよ！」って。

もしかしたら、あれが使えるかも。そう思って、あらためて調べ直し、試して、実行することで芽は育ち、いずれは成果という果実をもたらします。

しかし、種が無ければ、芽は育ちません。

「問題に直面したからで良いんじゃない？」

そうかもしれません。ただ私達が対峙する問題は Google で検索してすぐに答えが見つかるようなものでしょうか。そこから種を探すのはなかなか大変だったりします。

問題はそれぞれ固有のものです。似た部分があっても、そのままずばりの解決策がインターネットで見つかるわけではありません。

技術の使い方は見つかりますが、どの技術をどう使うかは自分で考えなければいけないのです。

知りもしない技術を使うことができるでしょうか。

技術の種を蒔く

では、どうやって技術の種を蒔けば良いでしょう。

情報収集

まずは情報収集です。技術の存在すら知らなければどうしようも無いです。

インターネット上には技術の情報は溢れています。特にはてブや SNS などを見ていれば、日々色々な技術を（名前だけでも）知ることができます。

一つ一つの内容をじっくり見て咀嚼するのは時間がかかるので、全体の傾向だけでも良いです。「あーこんなのが流行ってるんだね。」でも良いです。流行ってるものは大抵何か理由があります。

ここで何となくで良いので、何に使うものかを一緒にちらっとでも良いので考えておくと芽を出すきっかけ（フック）になります。

勉強会

勉強会などエンジニアが集まるコミュニティに参加してみるのも良いでしょう。

セッションでは色々な話題が登場して、知らない内容だと必死に理解しなきゃという気持ちになるかもしれませんが、これも「種を蒔く」感覚で、あーこう使うのかをおさえるくらいで聴くと気疲れせずに良いと思います。

懇親会などで話が聞けるチャンスは特に良いですね。出る話題はトレンドのものが多いですし、実際の問題を解決した話などが出るので、いっぱい種を拾いましょう。

人から聞くというのは、ネット上の情報をただ読むのとは異なる刺激なので、より理解が深まることが多いです。

rebuild.fm

情報収集するの面倒だし、勉強会とか忙しくていけない、という人に良いのが、ポッドキャストです。

なかでも rebuild.fm がオススメです。

情報感度高い人はすでに聴いてるとは思うのですが、今どき流行りの技術に関する話題がてんこ盛りです。

内容が全て理解できなくても問題ありません。ただ聞き流して、あー、Immutable Infrastructure がアツいのねと認識しておくだけでも良いです。

何かの機会に Immutable Infrastructure について触れることがあれば、あーあの時聴いたあれだ、となるわけです。（進研ゼミメソッド）

他の方法に比べると、通勤や夜寝る前など、すき間時間を活用することができます。また、ながら聴くことができるので、じっくり情報収集できない人にもおすすめできます。

（まあ情報収集というより、単に面白いから聴いてるわけですけど:D）

さいごに

エンジニアという仕事は、技術を使って、何かの問題を解決することだと思います。技術だけがあってもしょうがないですが、技術が無ければ解決することができません。

そう、技術というのはまさに飯の種なんです。これを大切にせずに何をするのでしょうか。

最後に私の好きな格言で締めたいと思います。技術の種、今日はどれくらい撒きましたか。

毎日をその日の収穫高で判断せずに、まいた種で判断しなさい。（ロバート・ルイス・スティーブンソン）

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

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

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

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 です。

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

これで 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 を動かすだけなら、より軽量な CoreOS や boot2docker を使う方が良いかもしれません。（ダウンロードも速いですし）

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

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

これまで 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 環境がまだ無い人は試してみて下さい。

参考

• Docker 0.7 runs on all Linux distributions – and 6 other major features | Docker Blog
• aufsRootFileSystemOnUsbFlash - Community Ubuntu Documentation

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

いよいよ CentOS 6.5 から Docker がサポートされたということで、実際にインストールしてみました。

Vagrant で CentOS 6.5 環境

Vagrant で CentOS 6.5 環境を作ります。（ CentOS 6.5 環境がある場合は不要です。）

CentOS 6.5 の Box ファイルには、Opscode が提供している Bento プロジェクトのものを利用しました。

$ vagrant init opscode-centos65 http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box
$ vagrant up
$ vagrant ssh

Docker インストール

では、CentOS に Docker をインストールします。

Docker は、EPEL リポジトリで配布されているので、追加しておきます。あとは yum で、docker-io パッケージを入れるだけです。docker の起動設定なども行っていきます。

[vagrant@localhost ~]$ rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
[vagrant@localhost ~]$ yum -y install docker-io
[vagrant@localhost ~]$ chkconfig docker on
[vagrant@localhost ~]$ service docker start

Docker で Hello World

ではさっそく Docker を試してみましょう。Docker 公式の centos イメージを使って、コンテナ内で echo を実行してみます。

[vagrant@localhost ~]$ sudo docker run centos /bin/echo "Hello World"
Hello World

centos イメージのバージョンを見てみました。まだ 6.4 のようです。

[vagrant@localhost ~]$ sudo docker run centos /bin/echo /etc/redhat-release
CentOS release 6.4 (Final)

/bin/bash を実行すれば、コンテナ内でシェルが起動できます。

[vagrant@localhost ~]$ sudo docker run -i -t centos /bin/bash
bash-4.1#

Vagrantfile

CentOS 6.5 で Docker をインストールする Vagrantfile を書いています。ご参考まで。

さいごに

ついに CentOS で Docker が来ましたね。これで Docker 探索が捗ります:D

ちなみに AWS でも試そうとしたのですが、Amazon Linux ではインストールはできたもの動作が不安定でした（たまたまかもですが）。CentOS は公式も AMI はまだ 6.4 のままだったので、まだ試していません。

あ、公式サイトでも RHEL/CentOS のインストール手順が掲載されましたね。（昨晩は無かった。。。）

Requirements and Installation on Red Hat Enterprise Linux / CentOS – Docker Documentation

参考

Docker Documentation – Docker Documentation
Docker: Linuxコンテナを使ってアプリケーションの配置を支援する
仮想環境構築に docker を使う – apatheia.info