Docker - 削除系のTips2題

Docker でいろいろ試行錯誤をしていると、さて。。となることがよくあります。
そんなときの軽いTips2題。

$ docker imgaes
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
<none> 　<none> 　c395172a74e5 　8 hours ago 　1.151 GB
<none> 　<none> 　05a17381460b 　8 hours ago 　1.151 GB
<none> 　<none> 　eb3ce0796961 　8 hours ago

と、こんな状況に陥ることがまれにあります。
そんなときは、以下のコマンドで <none> のイメージをきれいに削除できます。

$ docker images | awk '/<none/{print $3}' | xargs docker rmi

では、すべてのイメージを一気に片付けたい場合は

$ docker images | awk '{print $3}' | xargs docker rmi

で、一気にきれいになくなります。
必ず使うコマンドなので、メモしておくとよいです。

最近のWebの潮流

さて、いまどきのフロントエンド開発は恐ろしいことになっていて、シーンから少し遠ざかっただけで、取り返すのが大変な状況に陥ってしまうことも少なくはない。
わかりやすい例でいえば、Webの要とも言っても過言ではないJavaScriptが実は、扱うのに大変な苦労を強いられる。細心の注意を払わないと、あるいは、ちょっと手を抜くとたちまちスパゲティコードになってしまうという致命傷的な特性を持っている。
これをいかに解決するか？という観点でさまざまなフレームワークなり、ツールなりが考えられて使われてきたわけだが、その中でもおもしろいのが、CoffeeScriptの立場だ。
これは言語ではなく、あくまでシンタックスシュガーという位置づけで、規定は実装者自身に委ねられる。

つまり、オブジェクト指向で書きなさいと。

当然ながら、JSではクラスの概念をサポートしているわけではないので、なんとか工夫をしながら書いてきた歴史がある。この部分を乗り越えたのが CoffeeScript の功績だとも言えるのかもしれない。

はっきりいって面倒なものです。

独自のシンタックス感で CoffeScript を記述し、gulpやGrantでコンパイルする。さらにCSSをSassから変換して、のちほど散らかったファイル群を統合する。
しかし、JSの世界にクラスの概念を持ち込み･･･ 正確に言うとJSで実装する部分にオブジェクトアプローチの世界観をもたらしたことのメリットは実は大きいのです。

そして、当然のように面倒な部分は自動化し、極力、人の手の介在を避け、設計にこそ頭を使おうとこんなところを目指すのです。

Dockerfile から Dockerコンテナを生成しよう

今回は、Dockerfileを記述して、Dockerコンテナを生成するプロセスを体験します。
目指すのは、Webサーバを起動して動作を確認する、です。

まず、任意のディレクトリに Dockerfile という名前のファイルを作成して、以下のような記述をします。

FROM ubuntu:14.04
MAINTAINER kenny <kenny@mail.com>
RUN apt-get install -y nginx
ADD index.html /usr/share/nginx/html/

FROM で コンテナを作るにあたりベースになる環境として、Ubuntu14.04を使います。
MAINTAINER は見てのとおり作成者です。
コンテナをビルドするときに、上から順番に命令が走るわけですが、RUN でコマンドを実行します。
上の例では、nginxをインストールしています。非対話モードで走らせなければならないため -y オプションを追加しておきます。
次の ADD コマンドで、/usr/share/nginx/html に index.html を配置します。

たったこれだけです。
もちろん、必要最小限のコードしか記述していませんが、基本はこんな感じです。
これだけで、index.html を表示するWebを起動することができるわけです。

さて、index.html の中は空なので、このままでは結果を確認できません。

$ echo 'Hello!' > index.html

これでOK!

では、コンテナをビルドしてイメージを作ります。
$ docker build -t kenny/nginx:0.5 .

名前は適当でも構いませんが、慣習として <username>/<imagename> のように付与するのが推奨されます。
-t オプションでタグをつけます。上の例では 0.5 です。
注意点をひとつ。
最後の .（ドット）は忘れやすいので、注意です。最後の引数は、Dockerfileの配置したパスを指定します。つまり、このコード例では、カレントディレクトリで作業していることになります。

結果をリストします。
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
kenny/nginx 0.5 　f5468aac82bb 　18 seconds ago 　206.9 MB
ubuntu 14.04 　91e54dfb1179 　5 weeks ago 　188.4 MB

ここまできたらあとは起動してコンテナを生成します。
docker run -d -p 80:80 --name nginx1 kenny/nginx:0.5 /usr/sbin/nginx -g 'daemon off;' -c /etc/nginx/nginx.conf
18c2ceb92246540662d390550334b0c1f75e4437aa7fd66766ca2ffec25c6f8e

--name で nginx1 という名前をつけて、-d でバックグランドで動作します。
-p で80番ポートを常時リッスンして、ホスト側で80番でアクセスできます。

ためしに、curlコマンドで確認してみます。
$ curl localhost:80
Hello!

想定したとおり Hello! が得られました。
ブラウザで localhost:80 でアクセスしても、当然、同じ結果が得られます。

nodebrew で Node.js を管理する

先日は、Node.js を nvm で管理する方法を書きましたが、今回は、nodebrew を使ってみます。
特徴はこんな感じです。

1）perl で作られているため、Macなどに入っている可能性が高い
2）curl や wget で入れるため、git が入ってなくても構わない
3）パスを指定すれば、nodebrewコマンドが実行可能（.bashrc .zshrc に記述）
　 つまり、sudo 指定がいらない
4）ls-remote、clean など、機能はひととおり網羅

こんなところです。
では、インストールいきます。

$ wget git.io/nodebrew

$ perl nodebrew setup
fetching nodebrew...
install nodebrew in $HOME/.nodebrew

========================================
Add path:

export PATH=$HOME/.nodebrew/current/bin:$PATH
========================================

こんな指示が出ると思うので、従う。

$ vi ~/.bashrc
で、オープンする。
vim のタイプが苦手だ！ という方は
$ sudo gedit ~/.basrc
これで、WondowsライクにGUIエディタでOKです。

で、指示にあるとおり、下記の行を追加します。

export PATH=$HOME/.nodebrew/current/bin:$PATH

追加したら、設定ファイルをリロードします。

$ source .bashrc

この状態で nodebrew コマンドを実行すると

$ nodebrew
nodebrew 0.9.0

Usage:
    nodebrew help                         Show this message
    nodebrew install <version>            Download and install a <version> (compile from source)
    nodebrew install-binary <version>     Download and install a <version> (binary file)
    nodebrew uninstall <version>          Uninstall a version
    nodebrew use <version>                Use <version>
    nodebrew list                         List installed versions
    nodebrew ls                           Alias for `list`
    nodebrew ls-remote                    List remote versions
    nodebrew ls-all                       List remote and installed versions
    nodebrew alias <key> <version>        Set alias to version
    nodebrew unalias <key>                Remove alias
    nodebrew clean <version> | all        Remove source file
    nodebrew selfupdate                   Update nodebrew
    nodebrew migrate-package <version>    Install global NPM packages contained in <version> to current version
    nodebrew exec <version> -- <command>  Execute <command> specified <version>

Example:
    # install from binary
    nodebrew install-binary v0.10.22

    # use a specific version number
    nodebrew use v0.10.22

    # io.js
    nodebrew install-binary io@v1.0.0
    nodebrew use io@v1.0.0

これで、あとは察しがつくと思いますが…
利用可能な Node.js と io.js のバージョンをリストする
$ nodebrew ls-remote

使用する Node.js をインストールしてやる
$ nodebrew install-binary v0.11.13
もちろん、npm もいっしょに入ります。

使用する Node.js を確定する。これを忘れないように。
$ nodebrew use v0.11.13
use v0.11.13

最後に確認します。
$ node -v
v0.11.13
$ npm -v
1.4.9

いかがでしたか？
とても簡単です。そしてわかりやすいと思います。

Vagrantで仮想環境構築の自動化を目指す

今回は仮想環境を自動で構築する方法を試してみます。
あらかじめ VirtualBox がインストールされていることが前提になります。
なに？ 自動構築と思えば、なんだそういうことか･･･ と言わずに、これには多大なメリットが得られます。
たとえば、何名かのメンバーでチーム開発を始めることを想像してみてください。それぞれのホストOSはバラバラなので、仮想環境を構築して開発環境を揃えるという方針をとります。
しかし、各々が、バラバラに開発環境を構築した場合のデメリットはあまりにも大きすぎます。非常にシビアな開発プラットホームをメンバー全員が共有できるでしょうか？ とても難しい問題です。
今回は、その問題を簡単に、そして、シンプルに解決するソリューションのご紹介です。

では、VirtualBox がインストールされていない方は、早速導入します。
次に、今回の軸となるツール Vagrant をインストールします。
これは、各々の環境に応じたものをダウンロードすればよいでしょう。

インストール自体はとても簡単です。
終了したら次のコマンドでインストール結果を確認します。

$ vagrant -v
Vagrant 1.7.4

では、開発環境の構築をするための手続きを実施します。
まずは Box と呼ばれるものを追加します。Boxとは、仮想環境を構築するにあたりベースになるテンプレートと考えてよいと思います。
このテンプレートに対してさまざまなパッケージを導入するなりして、仮想環境を整備します。このベースになる部分はたとえば、
Vagrantbox.es などのようなサイトに集積されてるので、はじめはそれを利用するのがベストな選択だと言えるでしょう。
Boxを追加するコマンドは以下のとおりです。

$ vagrant box add [name] [url]

[name] はこれから作成する仮想環境の名前を付与します。どんな名前をつけても構いません。
[url] の部分には、テンプレートとなるboxイメージをダウンロードするURLを指定します。
たとえば、以下のようになります。

$ vagrant box add centos_6_3_32bit http://tom.davidson.me.uk/dev/vagrant/centos63-32.box

コマンドを実行します。

http://tom.davidson.me.uk/dev/vagrant/centos63-32.box
Downloading box from vagrant box add centOS63_32 http://tom.davidson.me.uk/dev/vagrant/centos63-32.box
Extracting box...ate: 642k/s, Estimated time remaining: --:--:--)
Successfully added box 'centOS63_32' with provider 'virtualbox'!

Successfully added box･･･ と表示されたら完了です。
では、結果をリストしてみます。

$ vagrant box list
centos_6_3_32bit (virtualbox)

次にたったいまダウンロードしたテンプレートを元に初期化します。
適当なディレクトリを作成して、その場所をカレントとします。

cd C:\Users\username\Cent_OS_6_3_32

では、さきほどのBoxを名前を指定して初期化します。

$ vagrant init centos_6_3_32bit

初期化が完了したら、SSHでアクセスできるように設定ファイルを書き換えます。
カレントディレクトリに Vagrantfile が生成されているはずなので、config.vm.network セクションを変更します。
IPアドレスの部分のコメントアウトを外します。

# Create a private network, which allows host-only access to the machine
# using a specific IP.
config.vm.network :private_network, ip: "192.168.33.10"

これで、192.168.33.10 が仮想マシンに割り当てられました。
これで起動できる状態になったので、起動します。

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 4.3.16
    default: VirtualBox Version: 5.0
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /vagrant => C:/Users/username/Cent_OS_6_3_32
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

起動しました。
終わりから3行目に共有フォルダの設定が表示されていますが、この内容はVirtualBoxからでも参照できます。

仮想マシンへの接続は TeraTerm などを使ってSSH接続します。Windows以外であれば vagrant ssh というコマンドを使えます。
SSH接続は

ホスト： 192.168.33.10
ポート： 22
ユーザ： vagrant
パスフレーズ： vagrant

でログインします。

さて、ベースになる仮想マシンができあがったので、あとは開発に必要なパッケージを適宜導入して、メンバ間でこの仮想環境をシェアすれば、環境の差異という問題を解決することが可能になります。
もうひとつ、大きなメリットは仮想環境をひとつ作成すれば、ほかのメンバーに共有することにより、それぞれが環境を構築するという煩わしさから開放されます。

ぜひ、試してみてください。

nvmでインストールされたNode.jsを管理する

nvm を使用すると、複数の Node.js を管理できるようになります。
ちょうど Ruby における RVM と同じ思想ですね。強い影響下にあることがわかります。

では、早速 nvm をインストールしますが、ソースパッケージをビルドするにあたり必要なパッケージを前もってインストールしておき ます。

$ sudo apt-get update
$ sudo apt-get install build-essential libssl-dev

次に GitHub からインストールスクリプトを取得して実行します。
$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.26.1/install.sh | bash

profleのいずれかが更新されるので、ターミナルを開きなおします。
これで、nvmコマンドを発行することができるようになりました。
次のコマンドで、インストールが可能なNodeを確認することができます。

$ nvm ls-remote

上記のコマンドの結果、導出されたリストから適宜、選択したNodeをインストールします。
最新のv4.1.1をインストールします。

$ nvm install 4.1.1

~/.nvm 配下に指定したバージョンのNodeがインストールされます。
同時に、npmもインストールされます。

インストールされたバージョンのNodeを明示的に指定しなければなりません。
$ nvm use 4.1.1

結果を確認します。
$ node -v
v4.1.1
$ npm -v
2.14.4

管理下にあるバージョンをリストするには次のコマンドを実行します。

$ nvm ls

デフォルトで使用するバージョンを指定します。

$ nvm alias default x.x.x
default -> x.x.x (-> vx.x.x)

また、現在選択されているバージョンを明示的に設定するには、次のコマンドを実行します。

$ nvm use default Now using node vx.x.x (npm vx.x.x)

これで、適宜必要なNode.jsのバージョンを指定できるようになりました。

DockerでWordPressを起動してみる

ubuntu に Docker をインストールしてある前提で話を進めます。
Dockerイメージではなく、Dockerfileを使ってビルドする方法をとってみます。

$ docker build --rm -t (name)/wordpress git://github.com/jbfink/docker-wordpress.git

(name)の部分は適当な名前を付与して構いません。
これを実行することにより必要なイメージをダウンロードしてビルドします。

次に、以下のコマンドを実行します。
$ docker run --name wordpress1 -d -p 8080:80 -p 2022:22 (name)/wordpress

(name)は適当に付与した名前です。たとえば、sample という名前をつけたなら、sample/wordpress というDockerイメージができあがるわけです。
そして、wordpress1という名前をコンテナに付与しています。
加えて、80番（HTTP）と、22番（SSH）のポートをホストの　8080番に、2022番に、それぞれルーティングするように設定します。

これで完了です。
では、http://localhost:8080/ にアクセスしてみてください。

WordPress のインストール画面が表示されます。
簡単ですね。

では、WordPressをインストールしちゃいます。

サクッと完了です。

では、Dockerコンテナを終了してみます。
$ docker stop wordpress

これで、さきほどのURLにアクセスしてみてください。画面は表示できないはずです。
もう一度、再開するには
$ docker start wordpress

さて、ここからがポイントです。
コンテナは終了すると破棄されます。つまり、インスタンスを失い次に起動したときは新しいインスタンスで立ち上がります。
したがって、コンテナの中で設定された内容は永続化されません。
それでは困ってしまうので、現在の状況を別のコンテナとして記録します。

$ docker ps -a

上記のコマンドで現在のコンテナプロセス（起動しているもの、停止しているものも共に）がリストされます。その中から、さきほど停止したコンテナのIDに注目します。
そのうえで、以下のコマンドを実行します。

$ docker commit (CONTAINER ID) wordpress2:test

これで、さきほどのWordPressコンテナをコミットしました。
その上で、コンテナのイメージをリストします。

$ docker images

REPOSITPRYが wordpress2、TAGが test というイメージがリストされたでしょうか。
これで、さきほど停止、または　中断したときの状態からコンテナを起動することができるようになります。