Quantcast
Channel: さくらのナレッジ is_page
Viewing all 433 articles
Browse latest View live

Dockerコマンドをラッピングしてくれる「fugu」レビュー

$
0
0

Dockerコマンドを打つ場合には例えば次のように入力します。

docker run --detach --env="VERY=nice" --name="hello-world-nginx" --publish="8080:80" mattes/hello-world-nginx

ちょっと長くて設定をミスするとうまく動かなくて苦戦します。そこでDockerの起動設定をさらにラッピングして分かりやすくしてくれるツールがfuguです。

mattes/fugu

fuguの使い方

今回はさくらのクラウドで Ubuntu 14.04 LTS を使って試しています。

コマンドはバイナリが配布されていますので、パスの通ったディレクトにコピーするだけです。

curl -L https://github.com/mattes/fugu/releases/download/v1.1.1/fugu.v1.1.1.linux.x86_64.tar.gz | tar xvz
mv fugu.v1.1.1.linux.x86_64 /usr/local/bin/fugu
$ chmod +x /usr/local/bin/fugu
$ fugu --version
1.1.1

まず設定ファイル(fugu.yml)を書きます。

$ cat fugu.yml
image:  mattes/hello-world-nginx # mandatory
name:   hello-world-nginx
detach: true
publish:
  - 8080:80

これを実行します。

$ sudo fugu run -e VERY=nice
sudo: unable to resolve host ubuntu
docker run --detach --env="VERY=nice" --name="hello-world-nginx" --publish="8080:80" mattes/hello-world-nginx
Unable to find image 'mattes/hello-world-nginx' locally
Pulling repository mattes/hello-world-nginx
  :
7513295db096: Download complete 
65139809b1dbc597bf38d365a693c05ebcf2ef6f79c7739ea90f552f8e888a8e

これでnginxが起動しているDockerコンテナが起動しています。

$ docker ps
sudo: unable to resolve host ubuntu
CONTAINER ID        IMAGE                             COMMAND             CREATED             STATUS              PORTS                  NAMES
65139809b1db        mattes/hello-world-nginx:latest   nginx               42 seconds ago      Up 41 seconds       0.0.0.0:8080->80/tcp   hello-world-nginx   

publishで指定した8080番ポートが80番に渡るようになっていたり、runを行う際に-eオプションで渡した内容が環境変数として送られるようになっています。

終了する場合は fugu destroy を使います。

$ fugu destroy

終了させるコンテナの情報はfugu.ymlに入っていますので、特に名前を指定する必要もありません。とても簡単です。

その他のコマンドは次のようになっています。

$ fugu
Usage: fugu COMMAND [LABEL] [arg...]

Swiss Army knife for Docker.

Commands:
    build        Build an image from a Dockerfile
    run          Run a command in a new container
    exec         Run a command in a running container
    shell        Open a shell in a running container
    destroy      Kil a running container and remove it
    push         Push an image or a repository to the registry
    pull         Pull an image or a repository from the registry
    images       List images (from remote registry)
    show-data    Show aggregated data for label
    show-labels  Show all labels
    help         Show help

Run 'fugu help COMMAND' for more information on a command.

run/build/exec/destroyなどが可能で、fugu.yml以外のファイルも指定できますので同じディレクトリに起動するDockerコンテナの設定をまとめて管理することもできます。なお、fuguはFigのようなオーケストレーションツールを目指している訳ではなく、起動や終了の設定をシンプルにしたいだけのようです。

Dockerを使うのに慣れてきたらfuguを使って設定をシンプルに管理できるようにしても良さそうです。コマンドラインですべて設定を指定するとミスが発生するかも知れないので、fuguでラッピングすると運用が楽になるでしょう。

mattes/fugu


Dockerを使ったCIサーバ「Drone」レビュー

$
0
0

CI(継続的インテグレーション)をはじめる上で、テストビルドする環境は毎回リセットされる方が都合が良いです。余計なデータが残っていたためにテストに失敗したり、逆に成功したりと言った不正確性のが残るのはよくありません。

そこで登場したCIサーバがDroneです。Dockerを使ってテスト環境を毎回構築、破棄してくれます。しかもDroneのCI環境構築についてもDockerを使って簡単にできます。ぜひ新しいCIサーバとしてチェックしてください。

なおDroneはWebサービスも提供しており、オープンソースのプロジェクトについては無料、5つのプライベートプロジェクトチェックで25ドル/月からとなっています。

Droneのトップページ
Droneのトップページ

Droneのインストール

今回はさくらのクラウドを使ってCoreOSを立ち上げています。

ログインしたら joaodubas/docker-droneio をpullします。

$ git pull https://github.com/joaodubas/docker-droneio.git
$ cd docker-droneio
$ ls -al
total 24
drwxr-xr-x 1 core core  106 Nov 18 17:13 .
drwxr-xr-x 1 core core  126 Nov 18 17:02 ..
drwxr-xr-x 1 core core  122 Nov 18 17:02 .git
-rw-r--r-- 1 core core  706 Nov 18 17:02 Dockerfile
-rw-r--r-- 1 core core 1083 Nov 18 17:02 LICENSE
-rw-r--r-- 1 core core 3336 Nov 18 17:02 README.md
-rw-r--r-- 1 core core   18 Nov 18 17:02 REPOSITORY
-rw-r--r-- 1 core core    9 Nov 18 17:02 TAG
-rw-r--r-- 1 core core  274 Nov 18 17:13 drone.toml

このまま立ち上げるとユーザ登録ができない(open=falseになっています)ので、drone.tomlを編集します。編集後は以下の通りです。

$ cat drone.toml 
[database]
driver="sqlite3"
datasource="/var/lib/drone/drone.sqlite"


[registration]
open=true

[github]
client = "GITHUB_CLIENT_KEY"
secret = "GITHUB_SECRET_KEY"
[worker]
nodes=[
  "unix:///var/run/docker.sock",
  "unix:///var/run/docker.sock"
]

今回は対象になるリポジトリとしてGitHubを指定しています。この場合、クライアントキーとシークレットキーを生成します。

New OAuth Applicationへ飛び、新しいアプリケーションを作成します。

  • Application name は任意です。
  • Homepage URL はサーバのIPアドレスを指定しています。例) http://133.242.21.16:8080
  • Authorization callback URL はHomepage URLと同じにしておきます。例) http://133.242.21.16:8080

これで登録すると、次のように Client ID と Client Secret が生成されますので、drone.toml のclient/secretにそれぞれ設定します。

DroneはGitHubの他、GitHub Enterprise、Gitlab、Gogs、Bitbucketに対応しています。

Droneの立ち上げ

設定ファイルの編集が終わったらDockerをビルドします。

$ docker build -t moongift:drone .

名称(moongift:drone)は適当に設定してください。ビルドが終わるとコンテナイメージが確認できます。

$ docker images
REPOSITORY               TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
moongift                 drone               aa16c298af3a        About an hour ago   333.1 MB

では立ち上げます。hostnameは適当に変更してください。

$ docker run -d --name droneio \
--hostname 133.242.21.16 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
-p 8080:8080 \
moongift:drone

これでサーバのIPアドレス:8080でDroneが立ち上がります。

リポジトリの指定

まず http://サーバのIPアドレス:8080/ にアクセスします。

Droneログイン画面
Droneログイン画面

GitHubと出ていますのでクリックしてOAuth認証してください。

コールバックで戻ってくるとリポジトリの指定になります。ACTIVATEをクリックするとリポジトリがDroneの監視対象になります。

Droneダッシュボード
Droneダッシュボード

一覧からの指定もできます。

リポジトリ一覧
リポジトリ一覧

ここから選択してリポジトリの登録が完了です。この時点でコミットフックなど、必要な設定が完了しています。

リポジトリの登録完了画面
リポジトリの登録完了画面

こちらは詳細設定です。

詳細設定画面
詳細設定画面

設定の中に環境変数の指定があります。パスワードやトークン、シークレットトークンなどはこちらにYAML形式で書いておけるようになっています。そのほかGitHubへアクセスするための公開鍵や、README.mdに記述するビルドステータスバッチのスニペットも表示されています。

Droneの環境変数設定
Droneの環境変数設定

試してみる

まずリポジトリの中に .drone.yml というファイルを作成します。これがDroneの設定ファイルです。例えば以下のような記述になります。

image: go1.3
git:
  path: github.com/drone/drone
env:
  - GOROOT=/usr/local/go
  - PATH=$PATH:$GOROOT/bin:$GOPATH/bin
script:
  - sudo apt-get -y install zip libsqlite3-dev sqlite3 rpm 1> /dev/null 2> /dev/null
  - gem install fpm
  - rbenv rehash
  - make deps
  - make test
  - make test_postgres
  - make test_mysql
  - make packages
services:
  - postgres
  - mysql
notify:
  email:
    recipients:
      - brad@drone.io
  gitter:
    room_id: $$GITTER_ROOM
    token: $$GITTER_KEY
    on_started: false
    on_success: true
    on_failure: true

publish:
  s3:
    acl: public-read
    region: us-east-1
    bucket: downloads.drone.io
    access_key: $$AWS_KEY
    secret_key: $$AWS_SECRET
    source: packaging/output/
    target: $DRONE_BRANCH/
    recursive: true
    when:
      owner: drone

$$ではじまるものは先ほどの設定画面で定義した環境変数が使われます。

まずimageでDockerのコンテナイメージを指定しています。さらにリポジトリ、セットアップ用のスクリプトになります。サービスはデータベースで、MySQL/PostgreSQL/RabbitMQ/Redis/memcached/Cassandra/Couchdb/MongoDBなどが指定できます。これらのシステムと連携する場合に指定します。

さらにnotifyでテスト成功または失敗時の通知先を指定します。メール、Gitter、Slack、HipChat、Flowdock、IRC、WebHookが指定可能です。例えばSlackの指定は次のようになります。

notify:
  slack:
    username: foo
    token: c90f0e53d4973302fe0b6159488423d6
    team: bar
    channel: baz
    on_started: false
    on_success: true
    on_failure: true

publishはテストが成功した時のデプロイ先になります。Amazon S3、Swift、PyPI、NPM、Docker、GitHubが指定可能です。パッケージを作ってリリースと言った形を想定しています。

ビルド結果。新しいビルドが走ると通知されます。
ビルド結果。新しいビルドが走ると通知されます。

ファイルを作ったら後はGitでpushすれば自動的にテストが実行されます。初回はコンテナイメージの取得があるので若干時間がかかります。その結果もDrone上で確認が可能です。

テスト状況が表示されます。
テスト状況が表示されます。

Dockerコンテナ

Droneでは公式Dockerコンテナイメージを配布しています。

  • Dart
  • Erlang
  • Go
  • Haskell
  • Node
  • PHP
  • Python
  • Ruby

が用意されており、今後Java(Clojure、Scala、Groovy)、Perl、Rustなどが追加予定となっています。これらのスクリプトをベースにすればDroneのテストは容易になりますが、設定ファイル(.drone.yml)上でscriptがあまり多いと実行に時間がかかるようになると思われます。公式コンテナイメージをベースとしつつ、カスタマイズしたコンテナイメージを用意するのが良いのではないでしょうか。


テストのたびに環境を構築、破棄するというのはとてもDockerらしい使い方だと思います。データベースとディレクトリを変えるだけでは分からない、余計なライブラリの関連性で不具合を起こしたり、本番環境とテスト環境の差異を最小限にとどめられるようになるのではないでしょうか。

Jenkinsに比べるとまだまだ機能が不足している感はありますが、今後主流になっていくであろう仮想環境を使ったCIサーバとして注目ではないでしょうか。

Continuous Integration · drone.io

簡単にWeb/スマートフォンアプリのバックエンドが構築できる「Deployd」レビュー

$
0
0

Webアプリケーションを作る一般的な手順としては、PHPやRuby、Perlなどのプログラミング言語を使ってサーバサイドを書いて、フロントエンドをJavaScript、スタイルシートで構築するのではないでしょうか。最初こそ疑問もありませんが、様々なWebアプリケーションを作っているとだんだんこの手順が面倒になってきます。

特にサーバサイドで複雑なことを行わず、単にデータを保存する場所くらいの使い方であった場合はそうです。特に最近よく聞くRESTfulなサーバがあれば十分というのであれば、Deploydを使ってみてはいかがでしょう。DeploydはMongoDBをデータベースにしつつ、その管理画面とO/RマッパーからなるJavaScriptライブラリを提供するバックエンドソフトウェアになります。

Deploydの公式サイト
Deploydの公式サイト

Deployd

今回はDeploydを手軽に試すべく、Dockerを使って構築する手順から紹介します。

必要なもの

今回はUbuntu 14.04 LTSをさくらのクラウドで立ち上げています。CentOSやCoreOSでも問題ないはずです。

サーバにログインしてDeploydサーバを立ち上げる

まずサーバを立ち上げたら、ログインしてDockerをインストールします。

$ sudo apt-get update
$ sudo apt-get install docker.io
$ sudo service docker.io start

Dockerを立ち上げたら、Deploydのコンテナイメージをpullします。

$ docker pull sesteva/deployd

これで準備は完了です。ではコンテナを立ち上げます。

$ sudo docker run --name deployd -p 2403:2403 -i -t sesteva/deployd
to start your app:
	$ cd test
	$ dpd
starting deployd v0.7.0...
listening on port 2403
type help for a list of commands
dpd >

これで立ち上がりました。ここでオプションの説明をすると、

-p 2403:2403

ゲストの2403番ポート(Deploydのポート)をそのままホスト側でも使えるようにしています。

Deploydの使い方

まずは http://サーバのIPアドレス:2403/dashboard/ にアクセスします。

Deploydの管理画面
Deploydの管理画面

これが管理画面になります。ここで自由にリソースを作成したり、データをメンテナンスできます。データはコレクションとユーザの2種類が作成できます。ユーザは認証用としてusername/passwordがあらかじめ組み込まれたものになります。暗号化されるので安全です。

コレクションの作成
コレクションの作成

今回は posts というリソースを作成しました。

プロパティの利用
プロパティの利用

プロパティを使ってカラムを定義します。

データのメンテナンス
データのメンテナンス

さらにデータを追加します。

イベントの追加
イベントの追加

イベントはアクションを起こした時のトリガーになります。バリデーションなどに使えると思います。クライアント側でできない処理はここで行えます。例えば name がWebだった場合にはエラーを出して、それ以外の場合は変更したいといった時には次のようになります。

if (this.name == "Web") {
    cancel("Error", 401);
}else{
    this.name = this.name + "1";
}

APIとして、RESTfulにデータの操作ができるようになっています。JavaScript以外の言語から操作する場合はこちらが良さそうです。

DeploydのAPI
DeploydのAPI

例えば /(コレクション名) でアクセスするとデータがJSONで返ってきます。

JSONでの取得例
JSONでの取得例

Webアプリケーションから触ってみよう

では実際にWebアプリケーションを作る時の流れになります。DeploydはWebサーバも兼ねていますので、 http://サーバのIPアドレス:2403/ にアクセスするとHTMLが表示されます。これは /home/ubuntu/deployd/deployd/public/index.html の内容になります。ホスト側でこのファイルを修正すると、リロードした際に反映されているのが分かるはずです。

Deploydのアプリケーション側の画面
Deploydのアプリケーション側の画面

この状態で既にDelopydのJavaScriptライブラリは読み込まれていますので、DevToolsで操作が可能です。

DevToolsで表示したところ
DevToolsで表示したところ

dpd.posts.(get|post|put|delete)でアクセスできるようになります。基本的にレスポンスはコールバックで受け取る形になります。

Web Socketが組み込まれていますので、管理画面を開いている場合データの追加などはリアルタイムに反映されるようになっています。

データの修正はその場で反映されます
データの修正はその場で反映されます

Deploydの使いどころ

Deploydはバックエンドのサービスですが、複数アプリケーションではなく一つのWebアプリケーションに対して手軽に使えると言った立ち位置になります。これまで行っていたようなサーバサイドを作って、UIも作って…といった手間が不要になります。サーバサイドの多少のコードもイベントを使えばフロントエンドはRESTfulの操作とUI側だけに集中することができます。

Web UIはpublicフォルダ以下になりますので、ここをGitで管理するようにすればWebアプリケーション開発がスムーズになることでしょう。ちょっとしたWebアプリケーションであれば、Deploydを使うことですぐに開発できるようになります。フロントエンドエンジニアの方はもちろん、Webエンジニアの方におすすめのソフトウェアです。

Deployd

PHP開発環境をDockerで構築する「phpstack」レビュー

$
0
0

最近は開発環境を仮想化するケースが増えてきました。元々WindowsではPHPの開発時にVMWare Playerを使ってLinuxを動かして開発することが多かったですが、それがMac OSXやLinuxであっても有益に使われています。一つのプロジェクトであれば環境をローカルに作ってしまっても良いのですが、プロジェクトごとに異なる環境を用意したり、LAMPだけに限らないアーキテクチャの場合に開発に携わる人員分、環境を作るのは大変です。

そこで今回はphpstackを紹介します。CoreOS上にDockerを使って様々なサービスをインストールして様々なプロジェクトに対応できるPHP開発環境を構築してくれます。リモートにログインせずとも使えるという利点があります。

必要なもの

オプションとして、

があると便利です。今回はMac OSX + Vagrant/VirtualBoxで構築しています。Windowsの場合はFigが公式サポートされていませんが、Figが動くなら同じように構築できるはずです。

仮想環境立ち上げ

まずphpstackをクローンします。

$ git clone https://github.com/kasperisager/phpstack.git

次にVagrantを立ち上げます。

$ cd phpstack
$ vagrant up

しばらくかかりますが、終わったらDocker Composeを実行します。まずはインストールをします。

$ curl -L https://github.com/docker/compose/releases/download/1.3.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose

次にDOCKER_HOSTを仮想環境内のサーバに向けて設定する必要があります。

$ export DOCKER_HOST=192.168.33.10:2375
$ docker-compose up

これで仮想環境内にPHP開発に必要なソフトウェアが一気にインストールされていきます。

インストールされるサービスは次の通りです。

  • Nginx
  • MySQL
  • MongoDB
  • PHP-FPM
  • HHVM
  • Memcached
  • Redis
  • Elasticsearch

これだけあれば大抵のプロジェクトでは事足りると思います。

さらにShipyardというDocker管理システムがインストールされますので、さらに追加でサービスをインストールすることもできます。Shipyardは http://192.168.33.10:8080/ にアクセスします。

Shipyardの管理画面
Shipyardの管理画面

Webサーバにアクセスする場合は、 http://192.168.33.10/ にアクセスします。これはphpstackの www/default ディレクトになります。

Webサーバにアクセスしたところ
Webサーバにアクセスしたところ
$ cat www/default/index.php
<?php phpinfo();

インストールされるPHPはバージョン5.5.9になります。

パスワード設定されているサービスについては docker-compose.yml を見ると設定が分かるようになっています。

$ cat docker-compose.yml
  :
mysql:
  image: tutum/mysql
  ports:
    - "3306:3306"
  environment:
    MYSQL_PASS: password
  :

phpstackを使えば必要なサービスが揃った状態で開発が開始できます。さらにメンバーの環境も統一できますので、生産性が向上するのではないでしょうか。

kasperisager/phpstack

レコメンドやコンテンツ発見に。オープンソース機械学習サーバ「PredictionIO」レビュー

$
0
0

レコメンドエンジンやスパム判定、音声や文字認識などは機械学習と呼ばれる技術が使われています。大量のデータをベースに新しいデータがなんであるかを判断します。ビッグデータの時代になり、特に注目されている技術になります。

PredictionIOはそのエンジンの一つで、オープンソース・ソフトウェアとして公開されています。Python、PHP、Ruby、Java向けにSDKが公開されているので、様々なサービスから利用できるでしょう。

今回はそのPredictionIOをレビューしたいと思います。インストールも試用もDockerを使って簡単にできますのでぜひチャレンジしてみてください。

必要なもの

  • Ubuntu 14.04 LTS(CoreOS、CentOSでも大丈夫です)
  • Docker
  • オプション:さくらのクラウドのアカウント

PredictionIOのインストール

インストールはDockerさえ入っていれば簡単にできます。

$ git clone https://github.com/mingfang/docker-predictionio.git
$ cd docker-predictionio
$ sudo ./build

ビルドはDockerコンテナのイメージダウンロードやセットアップがあるので時間がかかります。終わったらそのままDockerイメージを立ち上げます。

$ sudo ./shell
root@4a75279b3192:/# 

これでPredictionIOのサーバに接続しました。

PredictionIOの起動

次にPredictionIOを起動します。

# runsvdir-start &

これでしばらく待つとPredictionIOが起動します。問題なければ管理画面のダッシュボードにアクセスできます。http://サーバのアドレス:9000/ にアクセスします。

ダッシュボードの画面
ダッシュボードの画面

続いてレコメンデーションエンジンの単位になるアプリケーションを準備します。

# cd docker/quickstartapp
# pio template get PredictionIO/template-scala-parallel-ecommercerecommendation MyRecommendation
# cd MyRecommendation
# pio app new MyApp2
[INFO] [HBLEvents] The table pio_event:events_2 doesn't exist yet. Creating now...
[INFO] [App$] Initialized Event Store for this app ID: 2.
[INFO] [App$] Created new app:
[INFO] [App$]       Name: MyApp2
[INFO] [App$]         ID: 2
[INFO] [App$] Access Key: vSKHZIWimnRBC5UODnIZMsdxfr9Xl99yRMNI63fSogvecQoWYAoNxEU5KWSwVLsf
# curl https://raw.githubusercontent.com/apache/spark/master/data/mllib/sample_movielens_data.txt --create-dirs -o data/sample_movielens_data.txt
python data/import_eventserver.py --access_key vSKHZIWimnRBC5UODnIZMsdxfr9Xl99yRMNI63fSogvecQoWYAoNxEU5KWSwVLsf
Namespace(access_key='vSKHZIWimnRBC5UODnIZMsdxfr9Xl99yRMNI63fSogvecQoWYAoNxEU5KWSwVLsf', url='http://localhost:7070')
{u'status': u'alive'}
Importing data...
Set user u1
Set user u2
  :
User u10 views item i40
User u10 buys item i40
204 events are imported.
# pio build
[INFO] [Console$] Using existing engine manifest JSON at /docker/quickstartapp/MyRecommendation/manifest.json
  :
# pio train
# pio deploy --ip 0.0.0.0"

ここでも長い処理が実行されますが、Javaがメモリを食うので他のコンテナを立ち上げたりしていてメモリの余裕がないと失敗します。メモリが2GBあるUbuntuで他に特にサービスが立ち上がっていなければ問題ありませんが、もしメモリエラーが起きた場合はホスト側のプロセスを確認してください。

まだ、上記ログのKEYで表示されている文字列(ここではvSKHZIWimnRBC5UODnIZMsdxfr9Xl99yRMNI63fSogvecQoWYAoNxEU5KWSwVLsf)はアクセスキーになります。プログラミングから利用しますのでメモしておきましょう。

問題なく完了したらアプリケーションをデプロイします。

# cd MyRecommendation && pio deploy --ip 0.0.0.0 &

無事立ち上がると http://サーバのアドレス:8000/ にてPredictionIOエンジンの画面が表示できます。

PredictionIOサーバの画面
PredictionIOサーバの画面

テストデータのインポート

まずテストデータをインポートします。先ほどのアクセスキーを使います。

# curl https://raw.githubusercontent.com/apache/spark/master/data/mllib/sample_movielens_data.txt --create-dirs -o data/sample_movielens_data.txt
# python data/import_eventserver.py --access_key (アクセスキー)
Importing data...
1501 events are imported.

この処理によってユーザがアイテムを購入したというイベントが生成されます。同様の処理は次のようにプログラムから書くこともできます。以下はRubyの例です(gem install predictionioを実行してください)。

require "predictionio"
require "net/http"
require "json"
access_key = "アクセスキー"
client = PredictionIO::EventClient.new(access_key, URI.parse("http://localhost:7070/"))

client.create_event(
  'rate',
  'user',
  1, {
    'targetEntityType' => 'item',
    'targetEntityId' => 5,
    'properties' => { 'rating' => 4.0 }
  }
)

データを取り出す際には以下のように書きます。

require "predictionio"
require "net/http"
require "json"
client = PredictionIO::EngineClient.new(URI.parse("http://localhost:8000/"))

response = client.send_query('user' => 1, 'num' => 4)
=> {"productScores"=>[{"product"=>90, "score"=>8.459938376658831}, {"product"=>55, "score"=>7.617306635837063}, {"product"=>59, "score"=>7.543946275321666}, {"product"=>66, "score"=>7.19562319905969}]}

このようにしてユーザ1に対するお勧め商品を4つ得ることができます。見ての通り、レコメンドを取り出す際にはアクセスキーを使いません。そのためJavaScriptでWebベースで取得することもできます。

curl -H "Content-Type: application/json" -d '{ "user": 1, "num": 4 }' http://localhost:8000/queries.json
{"productScores":[{"product":90,"score":8.459938376658831},{"product":55,"score":7.617306635837063},{"product":59,"score":7.543946275321666},{"product":66,"score":7.19562319905969}]}

既存のWebサービスに対して新しくレコメンドエンジンを追加したいという時にも、PredictionIOであればRESTfulなWeb APIを使って簡単にデータ投入ができます。サーバもDockerで立てれば既存の環境を変更することなくはじめることができます。お手軽に機械学習を使ってみたい方はぜひこの方法をお試しください。

PredictionIO Open Source Machine Learning Server

Dockerコンテナへのアクセスをドメインごとに変更する「nginx-proxy」レビュー

$
0
0

Dockerでは一般的に次のようなコマンドを実行します。

$ docker run -d -p 8080:80 wordpress

この場合、ホストマシンへの8080番へのアクセスをコンテナの80番ポートへつなぐという意味になります。そのためURLとしては、

http://ホストのアドレス:8080/

といったポート番号を使ったサーバアクセスになります。しかしこれはコンテナが増えていった場合にあまり格好良くありません。そこで nginx-proxy を使ってドメインを割り当てたアクセスを行うようにしましょう。

jwilder/nginx-proxy

用意するもの

  • Linuxサーバ(今回はさくらのクラウドでUbuntu 14.04 LTSを使ってます)
  • Docker(今回は1.0.1を使っています)

nginx-proxyの実行

まず nginx-proxy を起動します。これはDockerイメージで配布されています。

$ docker run -d -p 80:80 --name nginx -v /tmp/nginx:/etc/nginx/conf.d -t nginx

これは見ての通り、ホストの80番ポートへのアクセスをそのまま受け取る仕組みになっています。

docker-genのインストール

次に docker-gen をインストールします。これはDockerのコンテナ設定を生成するライブラリです。

$ mkdir -p /tmp/templates && cd /tmp/templates
$ curl -o nginx.tmpl https://raw.githubusercontent.com/jwilder/docker-gen/master/templates/nginx.tmpl
$ docker run -d --name nginx-gen --volumes-from nginx \
   -v /var/run/docker.sock:/tmp/docker.sock \
   -v /tmp/templates:/etc/docker-gen/templates \
   -t jwilder/docker-gen:0.3.4 -notify-sighup nginx -watch \
   --only-published /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf

docker-gen はDockerのソケットファイルを監視しており、起動するタイミングや逆にkillされるタイミングで設定を変更します。

WordPressを立ち上げてみる

では実際に試してみたいと思います。利用時のコツとしては、 -e VIRTUAL_HOST=ドメイン名 をつけて実行します。

$ sudo docker run -e VIRTUAL_HOST=dev2.moongift.jp --name wordpress1 -d -p 8080:80 moongift/wordpress

例えばこのコマンドで dev2.moongift.jp にアクセスするとWordPressが立ち上がっています。これは8080番ポートにアクセスするのと同じです。

WordPressを立ち上げた例。dev2.〜でアクセスしています

WordPressを立ち上げた例。dev2.〜でアクセスしています

さらに、

$ sudo docker run -e VIRTUAL_HOST=dev3.moongift.jp --name wordpress2 -d -p 8081:80 moongift/wordpress

のように作ると、 dev3.moongift.jp というアドレスで別なWordPressが立ち上がります。もちろん dev2.moongift.jp / dev3.moongift.jp のどちらもドメイン名が引けるようになっていなければなりません。

別なWordPressを立ち上げ。バーチャルホストでアクセスできます

別なWordPressを立ち上げ。バーチャルホストでアクセスできます

nginx-proxy を使えばVirtual HostベースでアクセスできるようになるのでDockerで作成したコンテナへのアクセスが容易になります。使い方としても VIRTUAL_HOST を指定すれば良いだけです。Herokuのようなサービスも容易に実現できます。これまでのポート番号ごとのアクセスに比べて格段に使い勝手が良くなります。

nginx-proxy の場合、ドメイン名を自由に変えられるので、 dev1.moongift.jp だけでなく dev1.moongift.com や example.example.com のように自由にアドレスを指定できます。Dockerをサービスの中で使っていく際に役立つことでしょう。

さらにはTLSにも対応していますので、ドメインごとに証明書を指定したり、サブドメイン対応の証明書を使ってすべてのコンテナをセキュアに通信させることも可能です。ぜひお試しください。

[jwilder/nginx-proxy](https://github.com/jwilder/nginx-proxy)

非Linux環境でもDockerの実行環境を簡単に構築できる「Docker Machine」

$
0
0

近年普及が進んでいるコンテナ技術「Docker」。しかしDockerはLinux固有の技術を利用しているため、Mac OS XやWindowsといった環境ではそのままでは利用できない。今回紹介する「Docker Machine」は、このような非Linux環境でDockerを利用するための支援ツールだ。

Dockerの実行環境を簡単に構築できる「Docker Machine」

Linux向けのコンテナ技術「Docker」は、仮想マシンなどを利用するよりも少ないオーバーヘッドで隔離されたコンテナ環境を作成できるのが特徴だ。そのため近年では急激に利用者が増加している。いっぽうで運用環境にはLinuxを使っていても、開発環境としてはWindowsやMac OS Xを使っているというケースも少なくない。そういった環境でDockerを利用したい場合、Linuxマシンにリモートログインして操作するか、もしくは仮想化ソフトウェアを使ってLinux環境を用意するケースが多かった。その場合、サーバーや仮想マシンにLinuxをインストールし、さらにDockerなどの設定を行う必要となる。このインストールや設定作業を自動化する仕組みが、今回紹介する「Docker Machine」だ。

Docker Machineのアーキテクチャ

Docker Machineはその本体である「docker-machine」コマンドと、「ドライバ」と呼ばれるプラグインから構成されている(図1)。

図1 Docker Machineのアーキテクチャ
図1 Docker Machineのアーキテクチャ

Docker Machineでは、docker-machineコマンドを使ってDockerを実行させるサーバーや仮想マシンといったホスト(Dockerホスト)の管理を行える。具体的には、仮想マシンやサーバーインスタンスの作成・削除および起動・停止、OSやDockerといった必要なソフトウェアのインストールといった作業が可能だ。

Docker MachineではDockerホストと通信を行う部分をドライバとして本体から分離することで、さまざまなクラウドサービスや仮想化ソフトウェアに対応できるようになっている。Docker Machineにデフォルトで付属するドライバは次の14個だ。

Amazon Web Services
Microsoft Azure
Digital Ocean
Exoscale
Google Compute Engine
Generic
Microsoft Hyper-V
OpenStack
Rackspace
IBM Softlayer
Oracle VirtualBox
VMware vCloud Air
VMware Fusion
VMware vSphere

VirtualBoxやVMware、Hyper-Vといった主要な仮想化ソフトウェアや、Amazon Web Services(AWS)、Microsoft Azure、Google Compute Engine(GCE)といった主要なクラウドサービスは標準でサポートされている。また、「Generic」ドライバはSSHでリモートログインできるLinuxサーバーをDockerホストとして使用するものだ。これにより、専用サーバーやVPSなどをDockerホストとして利用することが可能になる。

これ以外にサードパーティによって開発されているドライバもあり、それらをインストールすることで上記14種以外の仮想化ソフトウェアやクラウドサービスにも対応できるようになっている。たとえば後述する「sakuracloud」ドライバを導入すれば、さくらのクラウドをDockerホストとして利用できるようになる。

また、docker-machineコマンドではDocker向けのオプション設定や環境変数設定を出力する機能も用意されている。これを利用してDockerクライアント(dockerコマンド)を設定することで、ローカルで稼動しているDockerを利用するのとまったく同じ感覚で仮想マシンやクラウド、リモートサーバーなどのDockerホスト上で稼動しているDockerを操作できるようになる。

Docker Machineのインストール

Docker MachineはDockerと同様にオープンソースで開発されており、ソースコードはGitHubで公開されている。ただし、コンパイル型の言語であるGo言語で実装されているため、利用するためにはソースコードのコンパイルが必要だ。GitHub上のリリースページではソースコードだけでなくLinuxやMac OS X、Windows向けのコンパイル済みバイナリも提供されているので、通常はこちらを利用すると良いだろう。ここで配布されているのはインストーラではなく実行ファイル本体そのものなので、ダウンロード後に手動で適当なディレクトリに「docker-machine」というファイル名でコピーし、パーミッション設定などを行う必要がある。

また、Docker MachineにはDocker(Dockerクライアント)は含まれていないため、こちらも別途インストールしておく必要がある。Dockerのバイナリも同じくGitHub上のリリースページから入手が可能だ。

なお、DockerやDocker Machine、VirtualBoxなどをまとめてインストールできるWindowsおよびMac OS X向けインストーラ「Docker Toolbox」も提供されている。このインストーラではDockerクライアントおよびDocker Machine、コンテナ管理ツール「Docker Compose」、GUIフロントエンド「Kitematic」、Git(Git for Windows)、VirtualBoxをまとめてインストールできる。ややファイルサイズが大きいためダウンロードには時間がかかるが、DockerやVirtualBoxが導入されていない環境でDocker Machineをインストールしたい場合はこちらが便利だろう(図2、3)。

図2 Docker関連ツールをまとめてインストールできる「Docker Toolbox」
図2 Docker関連ツールをまとめてインストールできる「Docker Toolbox」
図3 Docker ToolboxではVirtualBoxやGit for Windowsもまとめてインストールできる
図3 Docker ToolboxではVirtualBoxやGit for Windowsもまとめてインストールできる

Docker Machineを使ってローカルのVirtualBox上にDockerホストを構築する

DockerおよびDocker Machine、VirtualBoxが適切にインストールされていれば、次のようにdocker-machineコマンドを実行するだけでDockerがインストールされた仮想マシンの作成と起動を行える。

docker-machine create --driver virtualbox <Dockerホスト名>

たとえば「vbox」という名前のDockerホストを作成する場合、次のようになる。

$ docker-machine create --driver virtualbox vbox
Creating CA: /Users/hylom/.docker/machine/certs/ca.pem
Creating client certificate: /Users/hylom/.docker/machine/certs/cert.pem
Running pre-create checks...
Creating machine...
(vbox) Image cache does not exist, creating it at /Users/hylom/.docker/machine/cache...
(vbox) No default boot2docker iso found locally, downloading the latest release...
(vbox) Latest release for github.com/boot2docker/boot2docker is v1.9.1
(vbox) Downloading https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso to /Users/hylom/.docker/machine/cache/boot2docker.iso...
(vbox) 0%....10%....20%....30%....40%....50%....60%....70%....80%....90%....100%
(vbox) Creating VirtualBox VM...
(vbox) Creating SSH key...
(vbox) Starting VM...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env vbox

このときVirtualBoxはバックグラウンドで稼動し、GUIの管理画面は表示されない。Dockerホストの稼働状況を確認するには、「docker-machine ls」コマンドを使用する。

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   ERRORS
vbox   -        virtualbox   Running   tcp://192.168.99.100:2376

また、Dockerホストを停止させるには「docker-machine stop <Dockerホスト名>」コマンドを、削除するには「docker-machine rm <Dockerホスト名>」コマンドを実行すれば良い。

$ docker-machine stop vbox
(vbox) Stopping VM...
$ docker-machine rm vbox
(vbox) Stopping VM...
Successfully removed vbox

なお、docker-machineコマンドを引数無しで実行すると、利用できるサブコマンドやオプションなどの一覧を確認できる。

Dockerホスト上のDockerを操作する

Dockerクライアントには別ホスト上で稼動しているDockerにネットワーク経由でアクセスして各種操作を行う機能が用意されており、これを利用することでDockerホスト上のDockerをあたかもローカルで稼動しているかのように操作できる。この機能を利用するには、「DOCKER_HOST」や「DOCKER_MACHINE_NAME」、「DOCKER_CERT_PATH」、「DOCKER_TLS_VERIFY」といった環境変数を設定するか、もしくはdockerコマンドの引数でこれらに対応する「-H」オプションや「–tlscert」オプションなどの値を指定すれば良い。

Docker Machineではこの設定を簡便にするため、「env」や「config」といったサブコマンドが用意されている。たとえば「docker-machine env <Dockerホスト名>」コマンドを実行すると、次のようにそのDockerホスト名に対応する設定スクリプトが出力される。

$ docker-machine env vbox
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/hylom/.docker/machine/machines/vbox"
export DOCKER_MACHINE_NAME="vbox"
# Run this command to configure your shell: 
# eval "$(docker-machine env vbox)"

ここで表示されているように、docker-machineコマンドを「$(docker-machine env <Dockerホスト名>)」のように実行することで自動的に環境変数を設定できる仕組みだ。

また、configサブコマンドではdockerコマンドに与える引数の形で設定パラメータが出力される。

$ docker-machine config vbox
--tlsverify --tlscacert="/Users/hylom/.docker/machine/certs/ca.pem" --tlscert="/Users/hylom/.docker/machin
e/certs/cert.pem" --tlskey="/Users/hylom/.docker/machine/certs/key.pem" -H=tcp://192.168.99.100:2376

こちらを利用する場合、次のようにdockerコマンドの引数としてdocker-machineコマンドを指定すれば良いが、やや冗長になるので特に理由が無い限りは環境変数を利用するほうがよいだろう。

$ docker $(docker-machine config vbox)

上記の環境変数を設定したあとは、ローカルの環境でDockerを利用するのと同じようにdockerコマンドでコンテナの作成や各種管理が行える。

リモートにあるLinuxマシンをDockerホストとして使用する

Docker Machineに標準で含まれている「Generic」ドライバを利用することで、リモートにあるLinuxマシンをDockerホストとして利用することが可能だ。ただし、Dockerホストとして利用するLinuxマシンではDocker MachineがサポートするOSが稼動している必要がある(表1)。

表1 Docker MachineがサポートするOS
OS バージョン 備考
Boot2Docker 1.5以上 VirtualBoxでのデフォルト
Ubuntu 12.04以上  
RancherOS 0.3以上  
Debian 8.0以上 実験的サポート
RedHat Enterprise Linux 7.0以上 実験的サポート
CentOS 7以上 実験的サポート
Fedora 21以上 実験的サポート

また、Docker MachineではDockerホストとなるサーバーにSSHでログインし、sudoコマンドを使ってroot権限で各種処理を実行する。そのため、Dockerホストとして使用するサーバーではSSHでのログインに使用するユーザーがパスワードなしでsudoコマンドを実行できるように設定しておこう。

genericドライバによるDockerホストの作成

Dockerホストとして使用するLinuxサーバーを用意したら、次のように「generic」ドライバを指定して「docker-machine create」コマンドを実行することで、そのホストをDockerホストとして利用するための各種設定が自動で行われる。

docker-machine create --driver generic --generic-ip-address <対象とするホストのIPアドレス> --generic-ssh-user <ログインに使用するユーザー> <ホスト名>

次の例はホストのIPアドレスとして「192.168.1.10」、ログインに使用するユーザー名として「hylom」、ホスト名として「sakuravps」を指定した場合の例だ。

$ docker-machine create --driver generic --generic-ip-address 192.168.1.10 --generic-ssh-user hylom sakuravps
Running pre-create checks...
Creating machine...
(sakuravps) Importing SSH key...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with ubuntu(upstart)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env sakuravps

これにより、自動的にDockerなど必要となるソフトウェアがインストールされ、リモートからdockerコマンドでそのホスト上のDockerを操作できるようになる。このとき、hostnameコマンドや/etc/hostnameファイルの書き換えなどが実行され、ホスト名が指定したものに変更される。

なお、Mac OS X環境ではOSが提供するキーチェーン機構によりパスフレーズの入力がバイパスされるが、Windows環境では複数回に渡って繰り返しパスフレーズの入力が求められるので注意したい。

以上の手順でDockerホストを作成後、前述の「docker-machine env」コマンドなどを使って環境変数の設定を行えば、リモートホスト上のDockerをあたかもローカルホスト上にあるDockerのように操作できるようになる。

$ eval "$(docker-machine env vbox)"
$ docker-machine ls

「sakuracloud」ドライバを利用してさくらのクラウドをDockerホストとして使用する

Docker Machineでは環境に応じたドライバを用意することで、標準でサポートされている以外の環境をDockerホストとして利用できる。GitHub上のDocker Machineリポジトリ上で利用できるドライバの一覧が公開されているが、今回はこのうちさくらのクラウド向けドライバ「sakuracloud」の利用例を紹介する。

sakuracloudドライバはKazumichi Yamamoto氏によって開発されたドライバで、GitHub上のdocker-machine-sakuracloudリポジトリでソースコードおよびバイナリが公開されている。Docker MachineのドライバはDockerやDocker Machineと同様Go言語で記述されているので、特に理由がなければリリースページで公開されているバイナリを利用するのが良いだろう。配布されているZIPファイルにはバイナリファイル(Windowsの場合.exeファイル)が含まれているので、これをDocker Machineのインストールディレクトリ(Docker Toolboxを利用してインストールした場合はWindowsの場合C:\Program Files\Docker Toolbox\ディレクトリ、Mac OS Xの場合は/usr/local/bin/ディレクトリ)にコピーすれば良い。

また、sakuracloudドライバではさくらのクラウドのAPIを利用している。このAPIを利用するには、事前にアクセストークンおよびアクセストークンシークレットの取得が必要だ。取得方法についてはさくらのクラウドAPIを使ってみよう(1)——コマンドラインツール「sacloud」から使う記事で紹介しているので、詳しくはこちらを参照して欲しい。

さて、sakuracloudドライバを使ってさくらのクラウドを利用してDockerホストを作成するには、次のようにアクセストークンやアクセストークンシークレットを指定して「docker-machine create」コマンドを実行する。

docker-machine create --driver sakuracloud --sakuracloud-access-token <アクセストークン> --sakuracloud-access-token-secret <アクセストークンシークレット> --sakuracloud-region <ホスト名>

なお、デフォルトでは石狩第1ゾーンにホストが作成されるが、これ以外のゾーンを利用したい場合は「–sakuracloud-region」オプションで使用するリージョンを指定できる。また、作成する仮想マシンのスペックをオプションで指定することも可能だ。sakuracloud固有のオプションについてはリポジトリ上にあるREADME.mdファイルで確認できる。

アクセストークンなどを適切に指定して「docker-machine create」コマンドを実行すると、次のようにクラウド上にサーバーインスタンスが作成され、Dockerなど必要なソフトウェアのインストールが自動的に行われる。

$ docker-machine create --driver sakuracloud --sakuracloud-access-token <アクセストークン> --sakuracloud-access-token-secret <アクセストークンシークレット> sakuracloud
Running pre-create checks...
Creating machine...
(sakuracloud) Build host spec &sakuracloud.Server{Name:"sakuracloud", Description:"", ServerPlan:sakuracloud.Resource{ID
:"1001"}, Tags:[]string(nil), ConnectedSwitches:[]map[string]string{map[string]string{"Scope":"shared"}}}
(sakuracloud) Creating SSH key...
(sakuracloud) password is not set, generated password:xlzvnqsc1fwl
(sakuracloud) Created Server ID: 112701066850
(sakuracloud) Build disk spec &sakuracloud.Disk{Name:"disk001", Plan:sakuracloud.Resource{ID:"4"}, SizeMB:20480, Connect
ion:"virtio", SourceArchive:sakuracloud.Resource{ID:"112700954421"}}
(sakuracloud) Created Disk ID: 112701066853
(sakuracloud) Waiting for disk to become available
(sakuracloud) Build disk edit spec &sakuracloud.DiskEditValue{Password:"************", SSHKey:sakuracloud.SSHKey{PublicKey:"ssh-rsa *******************"}, Notes:[]sakuracloud.Resource{sakuracloud.Resource{ID:"112701066852"}}}
(sakuracloud) Editted Disk Id: 112701066853
(sakuracloud) Waiting for disk to become available
(sakuracloud) Waiting for server to become Running
(sakuracloud) Waiting for server to become Stopped
(sakuracloud) Waiting for server to become Running
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with ubuntu(upstart)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env sakuracloud

サーバーインスタンスの作成が完了すると、「docker-machine ls」コマンドでその状態を確認できる。

$ docker-machine ls
NAME          ACTIVE   DRIVER        STATE     URL                         SWARM   ERRORS
sakuracloud   -        sakuracloud   Running   tcp://***.***.**.***:2376

あとはVirtualBoxやgenericドライバを利用する場合と同様に環境変数の設定などを行えば、さくらのクラウドで作成したホスト上のDockerでコンテナの実行などを行えるようになる。

また、作業が終了してDockerホストが不要になった場合、docker-machine rmコマンドでそのホストを削除すればさくらのクラウド上のサーバーインスタンスも削除される。

$ docker-machine rm sakuracloud
(sakuracloud) Stopping VM...
Successfully removed sakuracloud

GUIでDocker Machineを利用できる「Kitematics」

最後に、WindowsおよびMac OS Xで利用できるDocker MachineおよびDockerのGUIクライアント「Kitematics」についても紹介しておこう。

Kitematicsは、GUIでDocker MachineおよびDockerの操作を行えるツールだ。現時点ではDockerホストとしてローカルで実行されているVirtualBox仮想マシンのみが利用できるが、簡単な操作でDockerホストの作成やコンテナのデプロイ、実行といった操作を行える(図4)。

図4 GUIでDockerやDocker Machineを操作できる「Kitematics」
図4 GUIでDockerやDocker Machineを操作できる「Kitematics」

KitematicsはDockerコンテナのホスティングサイトDockerHubと連動するようになっており、起動時にはDockerHubへのログインが求められる。これにより自作したコンテナの利用などが容易になる仕組みだが、公開されているコンテナを利用するだけであればログインは不要だ。

Kitematicsを起動すると、DockerHub上で公開されているコンテナが表示され、ここから作成するコンテナを選択できる。コンテナを選択して「CREATE」ボタンをクリックすると、DockerHubからそのコンテナがダウンロードされ、Dockerホスト上へのデプロイが行われる(図5)。

図5 選択したコンテナを1クリックでダウンロードしてデプロイできる
図5 選択したコンテナを1クリックでダウンロードしてデプロイできる

コンテナが起動すると、画面上にそのログが表示される(図6)。また、画面右側にはコンテナにアクセスするためのポート情報が表示される。たとえばこの例の場合、「192.168.99.100」というIPアドレスの32771版ポートがコンテナの3306番ポートに対応する。

図6 コンテナが起動するとログが画面上に表示される
図6 コンテナが起動するとログが画面上に表示される

さらに、ツールバーでは停止や再起動などの操作が行えるほか、「EXEC」ボタンをクリックするとコンテナにSSHログインした状態でコンソールが起動する(図7)。

図7 「EXEC」ボタンをクリックするとコンテナ内のシェルにアクセスできる
図7 「EXEC」ボタンをクリックするとコンテナ内のシェルにアクセスできる

コンテナによっては利用する際に環境変数やポートの設定が必要な場合がある。これらは「Settings」タブで設定できる(図8)。

図8 「Settings」タブで各種設定が行える
図8 「Settings」タブで各種設定が行える

なお、Kitematicsでは起動時に自動的にDockerホストとなる仮想マシンを起動するが、Kitematicsを終了してもその仮想マシンは終了されない。この仮想マシンには「default」という名前が付けられているので、Dockerホストを停止/削除させたい場合はこれを手動で停止/削除する必要がある。

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   ERRORS
default   -        virtualbox   Running   tcp://192.168.99.100:2376
$ docker-machine rm default
(default) Stopping VM...
Successfully removed default

MacやWindowsを使って開発している環境でも手軽にLinux環境を利用可能に

昨今ではサービスを運用するマシンがLinuxでも、開発にはWindowsやMacマシンを利用する例が少なくない。そのような場合、テスト環境に別途Linuxマシンを用意する必要があった。しかしDocker Machineを利用することで、容易にテスト環境を仮想マシン上に構築できる。また、DockerHub上にはあらかじめ主要なソフトウェアがインストールされているコンテナが用意されているため、これらを活用することでテスト環境を含むコンテナを迅速に用意できる。

ローカルの仮想マシン上だけでなく、クラウドやリモートサーバー上にDocker環境を構築できるのも便利だ。これにより、マシンパワーの少ないPCやMacでもDockerを気軽に利用できるようになる。Dockerの入門としても使いやすい。

開発やデプロイにDockerを利用していないという場合でも、開発環境構築ツールとしてもDocker Machineは非常に有用だ。今までDockerを使っていなかったWindowsやMac OS Xユーザーも、ぜひ試してみてはいかがだろうか。

これから始める「DockerでかんたんLAMP環境 for CentOS」

$
0
0

昨年からImmutable Infrastructureという言葉が出始めて、サーバーを簡単に作って壊すという潮流が出始めました。また、サーバー管理を簡単にするツールとしてDockerというものが脚光を浴びており、いまどきのサーバー管理者に受け入れられてきました。
今回は、そのDockerをインストールしてLAMP環境を構築するステップを見ていきたいと思います。

Immutable Infrastructureとは?

IaaS型のクラウドやVPSの台頭によって、簡単に仮想サーバーが立ち上げられる環境が整ってきました。
とはいえ、サーバーの立ち上げをするのはシステム構築時と、システム規模を大きくする時に限られ、サーバーの動作を変えたり、アプリケーションのアップデートをするときは、稼働しているサーバーの中身を修正するというのが従来のやり方でした。
しかしImmutable Infrastructureの考え方では、一度作成したサーバーの中身は変更しないというのが原則で、アプリケーションのデプロイメントや、サーバー設定の修正などのたびに、新しいサーバー群を用意して毎回いちから構築を行い、前段にあるロードバランサーで”えいやっ”と丸ごと切り替えるという手順に変わります。
なので、本番環境とは全く別のテスト環境を作り、そのテスト環境をそのまま本番環境に切り替えすることができますし、切り替えした後で問題が発覚したとしてもすぐに元の環境へ切り戻しができます。

以下の例では、10/25にアプリケーションの修正を反映させたServer 4とServer 5という新しいサーバを用意し、1/15にはセキュリティパッチを適用させたServer 6という新しいサーバーを用意し、そして3/1にアプリサーバの設定変更と増設を行うために Server 7、Server 8、Server 9という新しいサーバを用意しています。
これらの切り替えはロードバランサーで行い、使わなくなったサーバーは一定期間経た後で削除してしまいます。

docker-immutable-infrastructure-1

このように、何かサーバー内の変更をしたい時には、新しいサーバーを作って、古いサーバーは壊すというのが、Immutable Infrastructureの考え方です。

DockerとLXCについて

さて、ここまでImmutable Infrastructureの話をしてきましたが、簡単にサーバーを作ったり壊したりということを実現するためのソフトウェアとして最近注目されているのがDockerです。
Dockerは、LXC(Linux Container)というLinuxのコンテナ技術を用いて、サーバー上に独立したOS環境を作れるもので、OS環境を保存しておいたり、他のサーバーで稼働させたりと、柔軟なサーバー構築を実現できます。

ちなみに、コンテナ技術は仮想化技術と同列視されますが、KVMやXenなどの完全仮想化とは全く異なるものです。KVMやXenなどがハードウェアのエミュレーションを行ってホストとは異なるOS空間になっているのに対して、コンテナの場合は単一のOSを見かけ上分割しているだけで、ホスト側でpsを行うとゲストのプロセスも含めて全てのプロセスが表示されます。

docker-immutable-infrastructure-2

Dockerでサーバーを起動すると、dockerの起動時に指定したlinuxのコマンドを新しいLXCコンテナの中で実行します。
Dockerにおいて別々に起動されたサーバーは、お互いのファイルシステムやプロセス空間にはアクセスできず、見かけ上仮想化されたような形となります。

CentOSにDockerをインストールする

それでは、CentOSにDockerをインストールしてみましょう。
なお、DockerのサポートはCentOS 6.5からですので、CentOS 6系でなければインストールができません。CentOS 6系であれば、6.5未満であってもyum updateをすれば問題ありません。

手順は簡単です。
yum update で最新バージョンにアップデートし、dockerのリポジトリをダウンロードして、yum installするだけです。

$ sudo yum update -y
$ sudo wget -P /etc/yum.repos.d http://www.hop5.in/yum/el6/hop5.repo
$ sudo yum install xz docker-io -y
$ sudo service docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:                                           [  OK  ]

これでインストールが完了しました。
とても簡単でしたね。

Dockerを使ってみる

それでは、さっそくDockerを使ってみましょう。
Dockerをインストールするとdockerというコマンドが作成されますので、このコマンドを使ってDockerを操作します。
起動するにはrunというオプションを付け、-tで使用するコンテナイメージのタグを指定します。
そして、その後ろのオプションで、コンテナ内で実行するコマンドを指定します。
以下の例では、bash経由で、ホスト名の取得、プロセス一覧、インターフェース一覧を表示しています。

$ sudo docker run -t centos /bin/bash -c "hostname && ps aux && ifconfig"
[sudo] password for tanaka:
Unable to find image 'centos' (tag: latest) locally
Pulling repository centos
539c0211cd76: Download complete
15cb2a03c788
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  11296  1296 ?        S    04:11   0:00 /bin/bash -c hostname && ps aux && ifconfig
root         8  0.0  0.0  13368  1064 ?        R    04:11   0:00 ps aux
eth0      Link encap:Ethernet  HWaddr 3E:AB:5B:67:F6:8E
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::3cab:5bff:fe67:f68e/64 Scope:Link
          UP BROADCAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90 (90.0 b)  TX bytes:90 (90.0 b)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
$

表示されたでしょうか?
上記のコマンドを実行すると、CentOSのコンテナイメージをダウンロードし、指定されたコマンドをコンテナ内で実行します。
ホスト名は 15cb2a03c788 で、プロセス一覧ではbashとpsの2つのプロセスが、ネットワークインターフェースのeth0には172.17.0.2が割り振られていることが分かります。
つまり、ホストOSとは別にコンテナが作成され、ホスト名も、プロセス空間も、ネットワークも、完全に別になっていることが分かりました。

現在、実行しているDockerのコンテナ一覧を表示するには、docker psを利用します。

$ sudo docker ps
CONTAINER ID  IMAGE    COMMAND   CREATED   STATUS   PORTS   NAMES

しかし、何も表示されませんね。

Dockerでは、指定されたコマンドを実行し終わると、コンテナを破棄します。
通常のLinuxであれば、プロセス番号1のプロセスは/sbin/initであり、デーモンプロセスの起動などを行い常駐しますが、先ほど起動したコンテナのps結果ではPIDが1のプロセスは/bin/bashでした。
Dockerの場合には引数に指定されたコマンドを最初のプロセスとして実行しますので、サーバーを起動するというよりコンテナ内でコマンドを実行すると言ったほうが適切です。
先ほどのコンテナも、/bin/bashの実行が終了した時点で破棄されました。

なお、Dockerで作成されたコンテナの中にファイルを書き込んだとしても、再度実行したときには無くなっていることを意味しており、実行したあとのコンテナを再度利用するには、後述するコミットを実行しなければなりません。

コンテナイメージをコミットする

先ほど実行したコンテナは破棄されましたが、docker psを実行するときに -aオプションを指定することで、過去に実行したコンテナの一覧を見ることができます。

$ sudo docker ps -a
CONTAINER ID IMAGE      COMMAND             CREATED      STATUS PORTS   NAMES
15cb2a03c788 centos:6.4 /bin/bash -c hostnam 13 minutes ago Exit 0     stic_alni

これを見ると、15cb2a03c788という先ほど実行していたコンテナが出てきました。
もう一度、このコンテナを使用するには、docker commitを実行します。

$ sudo docker commit 15cb2a03c788 centos:test
b8b6e3abbed608181cd2bebcf952bb6e47c072d1095a3784fa5b1343c1f01305

これで、先ほど実行したコンテナがイメージ化されました。

docker-immutable-infrastructure-5

イメージの一覧は、docker imagesを実行することで表示されます。
testというタグでイメージが作成されました。

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED         VIRTUAL SIZE
centos              test               b8b6e3abbed6        39 seconds ago      300.6 MB
centos              6.4                 539c0211cd76        11 months ago       300.6 MB
centos              latest              539c0211cd76        11 months ago       300.6 MB

作成したイメージから新たなDockerコンテナを起動するには、-t オプションの後ろにタグを指定します。
ちなみに、今回はbashを実行して実際にコンテナ内で作業をしてみます。この場合、-iオプションを付けて対話モードにしなければならないことに注意して下さい。

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

これで、コンテナ内での作業が可能です。
コンテナを終了させるには、exitと打ち込むか^Dを押して下さい。

DockerfileでLAMP環境を一発作成

ここまで、Dockerコンテナの立ち上げを見てきました。
ただ、さきほど作成したコンテナはまっさらな状態であり、初期設定は一切されていません。
初期設定されたイメージの作成方法には、先ほど起動したbash経由で行いcommitしてイメージ化するという方法がありますが、それとは別にDockerfileという定義ファイルを使ってDockerイメージを作成する方法もあります。
docker-immutable-infrastructure-4
ここからは、Dockerfileを使って、LAMP環境がセットアップされたDockerイメージを作成してみます。

今回作成するイメージは、monitというサーバープロセスの監視ツールを使って、Apache、fluentd、sshdを実行するものです。
これで、Docker経由でmonitさえ起動させてしまえば、普通のサーバーと同じようにssh経由でログインの出来るウェブサーバが完成します。
docker-immutable-infrastructure-3

ちなみに、Dockerでmonitを稼働させるにあたり、以下のブログを参考とさせていただきました。
Dockerfile の書き方「私的」なベストプラクティス(3)〜サービスの起動について〜 – ようへいの日々精進

今回使用するDockerfileと、それにまつわる設定ファイル群については、私のgithubよりcloneして下さい。

$ git clone https://github.com/kunihirotanaka/docker-centos-lamp.git
Initialized empty Git repository in /home/tanaka/docker-centos-lamp/.git/
remote: Counting objects: 32, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 32 (delta 11), reused 26 (delta 8)
Unpacking objects: 100% (32/32), done.
$ cd docker-centos-lamp/
$ ls
Dockerfile  README.md        monit.conf   monit.mysqld  monit.td-agent  td.repo
LICENSE     authorized_keys  monit.httpd  monit.sshd    td-agent.conf

githubからクローンが完了すると、ローカルディレクトリにdocker-centos-lampというディレクトリが作成され、Dockerfileと関連する設定ファイルが作成されます。

Dockerfileには、RUNとかADDとかといったDockerfile用のコマンドが列挙されており、RUNはコンテナ内でのlinuxコマンド実行を、ADDはローカルディレクトリのファイルをコンテナ内にコピーすることを示しています。
これからDockerfileを元にイメージを作成したいと思いますが、ENVでIPアドレスやパスワードを指定するため、ファイルの中を少し修正頂く必要があります。
IPは、monitやphpMyAdminへアクセスを許可する接続元IPアドレスを、PWはMySQLやログインのためのパスワードを、LOGSERVERはfluentdでログを転送する先のIPアドレスを示します。

変更前

FROM centos
MAINTAINER Kunihiro Tanaka 

ENV IP __YOUR_IP_ADDRESS_HERE__
ENV PW __YOUR_PASSWORD_HERE__
ENV LOGSERVER __YOUR_LOG_SERVER_HERE__

変更例

FROM centos
MAINTAINER Kunihiro Tanaka 

ENV IP 192.168.50.3
ENV PW Jhd30Kwj
ENV LOGSERVER logserver.example.jp

また、authorized_keysというファイルもありますので、適宜sshの公開鍵を登録しておいて下さい。

ここまでくれば、あとはコマンド一発です。docker buildをすれば構築が開始されます。
※最後のドットを忘れないようにしてください。

$ sudo docker build -t centos:lamp .
~略~
Successfully built c94a7828a3a9
$ sudo docker images
[sudo] password for tanaka:
REPOSITORY        TAG             IMAGE ID         CREATED              VIRTUAL SIZE
centos            lamp            c94a7828a3a9     About a minute ago   1.156 GB

docker imagesで、作成したイメージが表示されれば、構築完了です。

作成したLAMP環境を起動させる

これで、新しいイメージが完成しました。
さっそく起動してみましょう。
/usr/bin/monitを起動すれば、SSH、MySQL、Apache、fluentd(td-agent)が起動されます。

$ sudo docker run -d -t -p 12812:2812 -p 10080:80 -p 10022:22 centos:lamp /usr/bin/monit -I
65d63382ebac74066290024a096fc291cf054435e1d10331ee1a03ac7e5e0c65
$

docker psをすると、monitが起動しているのが分かります。

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                                                                   NAMES
65d63382ebac        b3f874bbbd97        /usr/bin/monit -I   49 seconds ago      Up 48 seconds       0.0.0.0:10022->22/tcp, 0.0.0.0:10080->80/tcp, 0.0.0.0:12812->2812/tcp   prickly_lovelace

この状態で、ブラウザからアクセスしてみましょう。
各サーバの起動には少し時間がかかるので、アクセスできない時は少し待ってみましょう。

URLは、dockerの動いているサーバの12812番ポートですので、192.168.1.1というサーバで動いてたとすると、http://192.168.1.1:12812/ と入力するとアクセス可能です。
ユーザ名はadmin、パスワードはmonitで、これはmonit.confの中で変更することが可能です。
docker-immutable-infrastructure-6

次に、phpMyAdminへもアクセスしてみます。
URLは、dockerの動いているサーバの10080番ポートですので、192.168.1.1というサーバで動いてたとすると、http://192.168.1.1:10080/phpmyadmin/ と入力するとアクセス可能です。
docker-immutable-infrastructure-7

sshを行う場合は、10022番ポートへアクセスすれば可能です。
ログインするときは、ユーザ名lampで、先ほど指定したパスワードで可能です。

起動したLAMP環境を終了するときはkillを、その環境を引き続き利用する場合にはcommitしてからrunして下さい。

コンテナの終了

$ sudo docker kill 65d63382ebac
$ sudo docker ps 
CONTAINER ID   IMAGE      COMMAND    CREATED     STATUS    PORTS        NAMES

コミットして、再度起動してみる

$ sudo docker commit 65d63382ebac
$ sudo docker run -d -t -p 12812:2812 -p 10080:80 -p 10022:22 fa55a6cebb12 /usr/bin/monit -I

これで、終了した時点から再開することが可能です。

無事に構築できましたでしょうか?

Dockerはまだバージョンが1.0になっておらず、これからのソリューションといえますが、サーバーをドカドカたてるという言葉がブームになるほど、サーバーインフラ業界では注目されています。
皆さんもぜひ活用してみてください。

ちなみに、Dockerやるなら「さくらのクラウド」「さくらのVPS」をぜひどうぞ。
大事なことなのでもういちど。

Dockerやるなら「さくらのクラウド」「さくらのVPS」をぜひどうぞ!

【関連記事】
>>レッツトライ!夏休みに覚えるDocker
>>Dockerコンテナをクラウドサービス上で共有できる「Docker Hub」を使ってみる
>>15分で分かるLXC(Linux Containers)の仕組みと基本的な使い方a>
>>LXCを使った権限分離とテンプレートのカスタマイズ

おしらせ

banner_vps

banner_cloud

banner_writer


Dockerコンテナをクラウドサービス上で共有できる「Docker Hub」を使ってみる

$
0
0

近年注目されているコンテナ作成ツール「Docker」向けに、作成したコンテナを公開するための「Docker Hub」というサービスが開始された。今回はDockerで作成したコンテナをこのDocker Hubにて公開する方法を紹介する。

Dockerとは

前回/前々回の記事ではLinux上でコンテナ環境を構築するためのツール「LXC」(Linux Container)について紹介した(15分で分かるLXC(Linux Containers)の仕組みと基本的な使い方LXCを使った権限分離とテンプレートのカスタマイズ)。LXCでは比較的容易にコンテナの作成や運用ができるいっぽうで、独自のコンテナを作成したり、また作成したコンテナを別のマシンに複製する、といった機能についてはあまり注力されていない。そのため注目されているのが、「Docker」というツールだ。

DockerはLXCで不足しているコンテナの管理機能を実装したもので、当初はLXCと組み合わせて利用するツールだったが、徐々にLXCへの依存関係を減らし、最新バージョンではLXCなしでも動作する、独立したコンテナ管理ソフトウェアとなっている。さらに、WindowsやMac OS Xで仮想化ソフトウェア「VirtualBox」経由でDockerを利用するための「Boot2Docker」というツール(厳密にはLinuxディストリビューション)も提供され、マルチプラットフォームで動作するソフトウェアとなっている。

DockerとDocker Hub

2014年6月9日にリリースされたDocker 1.0とともにDocker向けのコンテナ共有サービス「Docker Hub」も発表された。Docker Hubは従来「docker index」(index.docker.io)という名前で提供されていたものだが、Docker 1.0のリリースとともにGitHub風のインターフェイスを備えたサービスにリニューアルされるとともに、名称も変更された(図1)。

図1 Docker Hubのユーザーページ
図1 Docker Hubのユーザーページ

 Docker Hubはユーザーが作成したコンテナをアップロードして公開・共有できるサービスで、ここで公開されているコンテナは自由にダウンロードして自分のサーバーに簡単にデプロイできる。公開されているコンテナは「リポジトリ」という単位で管理され、タグを使ったバージョン管理も可能だ。

Docker HubはDockerを開発するDocker社が営利目的で開発・運営しているサービスだが、無料ですべての機能が利用可能だ。無制限に作成できる公開リポジトリ(パブリックリポジトリ)のほか、一般公開されないプライベートリポジトリも作成できる。無料ユーザーの場合作成できるプライベートリポジトリは1つだけだが、有料プランを利用することで作成できるプライベートリポジトリの数を増やすことができる(図2)。

図2 Docker Hubの有料プラン
図2 Docker Hubの有料プラン

 今回は、このDocker Hubに独自に作成したコンテナをアップロードして利用する方法について紹介しよう。なお、Dockerの基本的な使い方やコンテナの作成方法については、『これから始める「DockerでかんたんLAMP環境 for CentOS」』記事が詳しいので、そちらをぜひご参照願いたい。

Docker Hubのアカウント作成

Docker Hubを利用するには、Docker Hubのアカウントが必要だ。これはDocker HubのWebサイト上で行えるので、事前に実行しておこう。Docker Hub(https://hub.docker.com/)にWebブラウザでアクセスするとアカウント登録画面(「Create your Docker account」画面)が表示されるので、ここにユーザー名およびパスワード、メールアドレスを入力して「Sign up」をクリックする(図3)。

図3 Docker Hubのアカウント作成画面
図3 Docker Hubのアカウント作成画面

 すると登録したメールアドレス宛に確認用のメールが届くので、そこに記載されているURL、もしくは「Confirm Your Email」リンクをクリックすることで認証が完了する。

Docker Hubのアカウントには、ユーザーのフルネームや所属企業、所在地といったプロフィールも設定できるので、必要に応じて設定しておこう。

Docker Hubを使う

Docker Hubへのコンテナのアップロードやダウンロードなどは、すべてdockerコマンドを使って実行する。たとえばコンテナをアップロードするには「docker push」コマンドを、ダウンロードするには「docker pull」コマンドを使用する。また、「docker search」コマンドでDocker Hubに登録されているコンテナを検索することが可能だ。

Docker Hubに作成したコンテナをアップロードする

それでは、まずはDocker Hubに自分で作成したコンテナをアップロードする例を紹介しよう。今回は、nodejs環境を構築したコンテナ「centos:nodejs」というコンテナをアップロードするという前提でその手順を紹介する。

コンテナをアップロードするには、まずコンテナをアップロードするリポジトリ名を決める必要がある。リポジトリはDocker Hub上でコンテナを管理する単位となる。リポジトリ名に利用できるのは英小文字と数字、「_」「-」「.」のみで、最小3文字、最大30文字の文字列だ。今回は、「nodejs」というリポジトリ名を使用することとする。

コンテナ名を決めたら、アップロードするコンテナに「<Docker Hubのアカウント名>/<リポジトリ名>:<タグ名>」というタグを付与する。タグ名については任意だが、そのコンテナの最新バージョンについては「latest」とするのが慣例となっている。今回はアカウント名が「hylom」、リポジトリ名が「nodejs」なので、「hylom/nodejs:latest」というタグ名を付けることにする。

アップロードするコンテナにこのタグを付与するには、まず「docker images」コマンドでこのコンテナに対応するイメージIDを調べる。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
centos              nodejs              7ca04c054d89        About a minute ago   328.7 MB
centos              latest              0c752394b855        4 weeks ago          124.1 MB

ここで、「centos:nodejs」に対応するイメージIDは「7ca04c054d89」であることが分かるので、このイメージに対し「docker tag」コマンドでタグを設定する。

# docker tag 7ca04c054d89 hylom/nodejs:latest

設定後、「docker images」コマンドを実行すると、リポジトリ名に「hylom/nodejs」、タグ名に「latest」が指定されていることが確認できる。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
centos              nodejs              7ca04c054d89        12 minutes ago      328.7 MB
hylom/nodejs        latest              7ca04c054d89        12 minutes ago      328.7 MB
centos              latest              0c752394b855        4 weeks ago         124.1 MB

タグを付与したら、そのタグ名を引数として与えて「docker push」コマンドを実行し、コンテナをアップロードする。ちなみに、Docker Hubのユーザー個別ページに「Add Repository]ボタンがあるが、公開リポジトリを作成する場合は事前にリポジトリ作成を行っておく必要は無い。pushコマンドの実行時に自動的にリポジトリが作成される。

# docker push hylom/nodejs:latest
The push refers to a repository [hylom/nodejs] (len: 1)
Sending image list
Please login prior to push:
Username: hylom
Password:
Email: ******@********
Login Succeeded
The push refers to a repository [hylom/nodejs] (len: 1)
Sending image list
Pushing repository hylom/nodejs (1 tags)
511136ea3c5a: Image already pushed, skipping
34e94e67e63a: Image already pushed, skipping
0c752394b855: Image already pushed, skipping
674a51d2b85b: Image successfully pushed
 
 
7ca04c054d89: Image successfully pushed
Pushing tag for rev [7ca04c054d89] on {https://registry-1.docker.io/v1/repositories/hylom/nodejs/tags/latest}

なお、初回実行時にはDocker Hubのアカウント情報の入力が求められるので、登録したユーザー名とパスワード、メールアドレスを入力する。ここで入力した情報は実行したユーザーのホームディレクトリの「.dockercfg」ファイル内に保存される。

アップロードが完了すると、Docker Hubにもその情報が反映される(図4)。

図4 Docker Hubの「hylom/nodejs」リポジトリ
図4 Docker Hubの「hylom/nodejs」リポジトリ

Docker Hubリポジトリからコンテナを作成する

Docker Hubにコンテナをアップロードすると、任意のマシンからそのコンテナをダウンロードしてデプロイできるようになる。たとえば、先ほどコンテナの作成とアップロードを行ったマシンとは別のマシンで「hylom/nodejs」コンテナを実行してみると、自動的にコンテナのイメージがDocker Hubからダウンロードされてデプロイが行われる。

# docker run -t hylom/nodejs /bin/bash
Unable to find image 'hylom/nodejs' locally
Pulling repository hylom/nodejs
7ca04c054d89: Download complete
  
  
a7518581ccd7: Download complete
bash-4.1#

Docker Hubリポジトリで公開されているコンテナを検索する

Docker Hubの公開リポジトリにアップロードされたコンテナは、誰もがダウンロードして利用できる。ほかのユーザーがアップロードしたコンテナは、「docker search」コマンドで検索できる。たとえば、「nodejs」というキーワードで検索すると、以下のように先ほどアップロードしたコンテナを含む多くの結果が表示される。

# docker search nodejs
NAME                                      DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
dockerfile/nodejs                         Trusted Node.js (http://nodejs.org/) Build...   30                   [OK]
google/nodejs-runtime                                                                     16                   [OK]
fedora/nodejs                                                                             14                   [OK]
phusion/passenger-nodejs                  An image meant to serve as a good base for...   5           
google/nodejs                                                                             5                    [OK]
barbuza/django-builder                    ubuntu with ssh, postgresql, nginx, memcac...   2                    [OK]
jprjr/stackbrew-node                      A stackbrew/ubuntu-based image for Docker,...   2                    [OK]
shykes/nodejs                                                                             2           
zhesto/nodejs                             Image with nvm managed node.js installations.   2           
misho1kr/nginx-nodejs                                                                     2                    [OK]
google/nodejs-hello                                                                       1                    [OK]
 :
 :
hylom/nodejs                                                                              0           
 :
 :

ちなみに、「STARS」はDocker Hub上で「お気に入り」された数で、AUTOMATEDが「OK」となっているのはDocker Hubの自動ビルド機能が使われているものだ。

公開リポジトリを利用する際の注意点

このように、公開リポジトリにアップロードしたコンテナは不特定多数がダウンロード可能になるため、アップロードの際には公開したくない/公開してはいけないファイルなどが含まれていないか、注意してほしい。問題となりそうなものとしては、オープンソースでないソフトウェアや、ライセンス的にクリアではないファイルなどがある。クラウドサービスのアカウント情報などが含まれるファイルや認証用のファイルなどにも注意したい。

また、公開されているコンテナを利用する際にも注意が必要だ。たとえばコンテナ内にSSH公開鍵が含まれており、SSHサーバーが稼働するようになっている場合、対応するSSH秘密鍵を持つユーザーからログインされてしまう可能性がある。また、悪意のあるユーザーがマルウェアやバックドアを仕込んでいる可能性もある。自分が作成したコンテナや、Dockerが公式に用意しているコンテナ以外を利用する場合は、その出元を十分に確認してから利用してほしい。

【関連記事】
>>これから始める「DockerでかんたんLAMP環境 for CentOS」 by 田中邦裕

おしらせ

banner_vps

Docker向けのコンテナをゼロから作ってみよう

$
0
0

Docker向けのコンテナを公開するDocker Hubでは多数のコンテナが公開されており、これらをベースにして独自のコンテナを作成できる。しかし、新規に独自のコンテナを作成したい場合もあるだろう。今回は、新規にコンテナを作成するのに必要な作業手順を紹介する。

Dockerにおける一般的なコンテナ作成手順

Dockerではよく使われるOS環境を含むコンテナがあらかじめ用意されており、それをベースに独自のコンテナを作成できる。たとえば、『これから始める「DockerでかんたんLAMP環境 for CentOS」』記事では、既存のCentOSコンテナをベースに、独自の環境を構築する手順を紹介している。

しかし、公開されているコンテナではなく、ゼロからコンテナを構築したいという場合もある。たとえばDocker Hubで提供されている公式のCent OSのコンテナでは、ファイル容量削減のためか一部のファイルが削除された状態になっており、それらのファイルを参照する処理を実行するとエラーが発生することがある。また、公式には公開されていないようなOS環境のコンテナが必要というケースも考えられる。

こういった場合に向け、Dockerでは「docker import」というコマンドが用意されている。このコマンドは、指定したtarファイルから「Base Image」を作成する処理を行うものだ。

DockerにおけるコンテナとBase Image

「Base Image」という用語は聞き慣れないかもしれないが、これはその名の通りコンテナのベースとなるイメージファイルを指す言葉だ。Dockerのドキュメントの「Image」ページに掲載されている図が分かりやすいが、DockerではUnion File Systemという機構を使い、複数のディスクイメージを組み合わせてコンテナが使用するルートディレクトリを用意している。

(注:一般的にはディスクイメージというとファイルシステムをその構造や制御情報までも含めてファイル化したものを指すが、DockerのImageは単にディレクトリおよびファイルだけを含むもので、厳密にはディスクイメージとは異なるものである)

図1 Dockerのドキュメントで説明されているコンテナのイメージ
図1 Dockerのドキュメントで説明されているコンテナのイメージ

 Dockerのコンテナに格納されているファイルやディレクトリはベースとなる「Base Image」と、コンテナに対する変更が差分の形で記録されている「Image」と呼ばれるものに記録されている。Base Imageにはコンテナのルートディレクトリとなる完全なディレクトリツリーが含まれており、これに差分が含まれるImageを順次適用したものが、コンテナの実際のルートディレクトリとなる。

Dockerではコンテナを終了するたびにコンテナに加えた変更が破棄され、もし加えた変更を恒久的に反映させたい場合はコミット処理を実行する必要があるが、このコミットというのは新しいImageを作成することに相当する。こういった構造を取ることで、Dockerではコンテナが変更されたあとも任意のコミット時の状態にすぐに復帰させたり、また過去の任意のコミットの状態から別の状態に分岐させたり、といったことが簡単に行えるようになっている。

「docker import」コマンドでBase Imageを作成する

前述のように、DockerでBase Imageを作成するには、「docker import」コマンドを使用する。詳しくはこのコマンドのmanページを見てほしいが、docker importコマンドはtarでアーカイブ化されたディレクトリツリーをBase Imageに変換するツールだ。たとえば、「container_root」というディレクトリを用意し、これに対し次のように実行すると、このディレクトリをルートディレクトリとするBase Imageとコンテナが作成される。

# mkdir container_root
  
  <ここでcontainer_rootディレクトリに必要なファイルやディレクトリをコピーする>
  
# cd container_root
# tar -c . | docker import - <イメージ名>:<タグ名>

なお、このときタグ名は省略可能だ。

とはいえ、この説明だけでは実際にどういった手順で作業を行えば良いか分かりにくいだろう。そこで、続いては具体的にさまざまなディストリビューション向けのイメージを作成する実例を紹介しよう。

DebianのBase Imageを作成する

まずはDebianやUbuntuといった、Debian系ディストリビューションのBase Image作成方法について説明しよう。Debian系ディストリビューションでは、OSの稼動に最低限必要なファイルなどを指定したディレクトリにインストールする「debootstrap」というコマンドが用意されており、これを使ってOS環境を構築できる。まずはこのdebootstrapをインストールする。

# apt-get install debootstrap

debootstrapでは、引数としてインストールするディストリビューションのリリース名とインストール先ディレクトリ、そしてパッケージのダウンロード先を指定する。

たとえばDebian 7.0のBase Imageを作成したい場合、リリース名は「wheezy」となる。また、パッケージのダウンロード先はミラーサイトなどのURLを指定する。たとえばさくらインターネットが提供しているDebianのミラーサイトを使用する場合、そのURLは「http://debian-mirror.sakura.ne.jp/debian/」となる。この場合、実際に実行するコマンドは次のようになる。

# mkdir debian-wheezy  ←インストールするディレクトリを作成する
# debootstrap wheezy ./debian-wheezy http://debian-mirror.sakura.ne.jp/debian/
W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
I: Retrieving Release
I: Retrieving Packages
 g[:]
 g[:]
I: Configuring tasksel-data...
I: Base system installed successfully.

debootstrapコマンドを実行すると必要となるパッケージがダウンロードされ、続いて指定したディレクトリにインストールされる。

正しく環境が構築できているかは、chrootコマンドを使ってそのディレクトリをルートディレクトリとしたシェルを実行することで確認できる。

# chroot debian-wheezy /bin/bash
# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var
# cat /etc/debian_version
7.6
# exit

最後に、Debian環境をインストールしたディレクトリに移動してdocker importコマンドを実行することで、Base Imageとそれを使用するコンテナが作成される。

# cd debian-wheezy
# tar -c . | docker import - debian-wheezy
67221db56e0b3f031e999968eaf1a3220501b72e09413f46aa3634e6efab3438

UbuntuのBase Imageを作成する

UbuntuはDebianから派生したディストリビューションであるため、ディストリビューションのリリース名とダウンロード先URLが異なるだけで、Debianとほぼ同じ流れでBase Imageを作成できる。たとえばUbuntu 14.04(Trusty Tahr)のBase Imageを作成したい場合、次のようにdebootstrapを実行すれば良い。

# mkdir ubuntu-trusty
# debootstrap trusty ./ubuntu-trusty http://ftp.jaist.ac.jp/pub/Linux/ubuntu/
# cd ubuntu-trusty
# tar -c . | docker import - ubuntu-trusty

Red Hat Linux系のBase Imageを作成する

Red Hat Enterprise Linux(RHEL)やその互換ディストリビューションであるCentOS、FedoraといったRed Hat Linux系のディストリビューションの場合、debootstrapのような最低限のOS環境に必要なファイルを簡単にインストールするツールは用意されていない。ただし、代わりにyumコマンドを使って似たような作業を行うことは可能だ。具体的には、インストール先のディレクトリを指定するための「–installroot」オプションを使ってインストール先ディレクトリを指定し、また指定したグループに含まれるパッケージをまとめてインストールする「groupinstall」コマンドを使用して「Core」グループのパッケージをインストールすることで、debootstrapと似たような作業を実行できる。

Red Hat Linux系のディストリビューションであればyumコマンドはほぼ標準で含まれているが、Debianなどのディストリビューションの場合は別途インストールしておく必要がある。apt-getコマンドでインストールが可能なので、インストールしておこう。

# apt-get install yum

また、yumコマンドを使ってパッケージのダウンロード元を指定するための設定ファイルも必要だ。Red Hat Linux系ディストリビューションを作業するホストとし、ホストと同一の環境を持つコンテナを作成する場合はホスト側の設定ファイルを流用できるが、ホストとは異なる環境のコンテナを作成したい場合や、Debian系ディストリビューション上で作業する場合などは、作成する環境を明示的に指定するためにも設定ファイルが必要となる。

たとえばx86_64版のCentOS 6.5の場合、設定ファイルは以下のようになる。また、CentOSの別のバージョンのBase Imageを作りたい場合はバージョン番号を表す「6.5」の部分を適宜ほかのものに差し替えることで対応できる。

[main]
cachedir=/var/cache/yum/x86_64/6.5
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=0
plugins=1

[base]
name=CentOS-6 - Base
baseurl=http://ftp.jaist.ac.jp/pub/Linux/CentOS/6.5/os/x86_64/

[updates]
name=CentOS-6 - Updates
baseurl=http://ftp.jaist.ac.jp/pub/Linux/CentOS/6.5/updates/x86_64/

これを、適当な名前(今回はmy.yum.confとした)で作業用のディレクトリに保存しておく。続いて、「–installroot」オプションでインストール先ディレクトリを指定してyumコマンドを実行する。たとえば/var/tmp/centos6というディレクトリにインストールを行う場合、次のように実行する。

# mkdir /var/tmp/centos6
# yum -c my.yum.conf --installroot=/var/tmp/centos6 -y groupinstall Core

なお、–installrootオプションではフルパスでインストール先ディレクトリを指定する必要がある。このオプションを間違えると、実行中の環境に指定したOS環境が上書きされてしまうので注意したい。

コマンドを実行すると、必要なパッケージがダウンロードされて指定したディレクトリ以下にインストールされる。また、yumコマンドではデバイスファイルの作成は行わないので、それらについては以下のように手動で行う必要がある。

# cd /var/tmp/centos6/dev
# mknod -m 666 null c 1 3
# mknod -m 666 zero c 1 5
# mknod -m 666 random c 1 8
# mknod -m 666 urandom c 1 9
# mkdir -m 755 pts
# mkdir -m 1777 shm
# mknod -m 666 tty c 5 0
# mknod -m 666 tty0 c 4 0
# mknod -m 666 tty1 c 4 1
# mknod -m 666 tty2 c 4 2
# mknod -m 666 tty3 c 4 3
# mknod -m 666 tty4 c 4 4
# mknod -m 600 console c 5 1
# mknod -m 666 full c 1 7
# mknod -m 600 initctl p
# mknod -m 666 ptmx c 5 2

以上で、./centos6ディレクトリ以下にOS環境に必要となるファイルが揃ったことになる。確認のため、chrootコマンドでこのディレクトリをルートディレクトリに変更してシェルを起動してみて、正しく動作するか確認してみよう。

$ chroot /var/tmp/centos6 /bin/bash

最後に、ルートディレクトリとするディレクトリに移動してdocker importコマンドを実行してBase Imageを作成する。

# cd /var/tmp/centos6
# tar -c . | docker import - centos6

作成したコンテナをDocker Hubにアップロードする

以上の手順で作成したコンテナは、Docker Hubからダウンロードしたコンテナと同様に起動したり、またコミットを行ってカスタマイズしたり、Docker Hubにアップロードすることが可能だ。Docker Hubに作成したコンテナをアップロードする手順は前回記事(Dockerコンテナをクラウドサービス上で共有できる「Docker Hub」を使ってみる)で解説しているので、そちらを参照して欲しい。

さらに、Dockerfileを使ってこれらコンテナをベースとする独自コンテナを自動作成させることもできる。ただしDockerfileを利用する場合、Docker Hubに作成したコンテナをアップロードしておく必要がある。

Docker付属のシェルスクリプトを使う

ここまでdocker importコマンドを使ってBase Imageを作成する方法を説明してきたが、DockerのソースコードにはCentOSやDebian、UbuntuなどのBase Imageを作成するためのスクリプトが含まれている。Docker Hubで公開されているCentOSなどの公式イメージはこれらのスクリプトを使って作成されているようだ。

これらは配布されているソースコードのcontribディレクトリ以下に「mkimage-*.sh」という名称で格納されているので、興味のある方は確認してみてほしい。

【関連記事】
>>Dockerコンテナをクラウドサービス上で共有できる「Docker Hub」を使ってみる
>>これから始める「DockerでかんたんLAMP環境 for CentOS」
>>LXCを使った権限分離とテンプレートのカスタマイズ
>>15分で分かるLXC(Linux Containers)の仕組みと基本的な使い方

おしらせ

banner_vps

レッツトライ!夏休みに覚えるDocker

$
0
0

こんにちは。MOONGIFTというサイトを運営している中津川と言います。MOONGIFTは10年くらい前からオープンソース・ソフトウェアを紹介しているのですが、昨年よりサーバのホスティング先をさくらさんに変更しています。そんなご縁もあって、今回からさくらのナレッジにて記事を書かせてもらうことになりました。オープンソース・ソフトウェアのレビューやクラウド周りの最新情報発信などを行っていきますのでよろしくお願いします!


8月と言えば夏休みです。サーバ管理者の方もひと時の心休まるひと時を過ごされているのではないでしょうか。サーバルームの方が涼しいとか、いつ電話が鳴るか分からないなんてことは今は忘れましょう。

せっかくの夏休み、日頃の疲れを癒すべくゆったりと南国の空のもとで過ごすのも良いですが、ITエンジニアたるもの日々の精進は欠かせませんよね。ということで忙しい日々の業務に追われてなかなかトレンドをキャッチアップできていないという方向けに最近話題のDockerに関してまとめて情報をお届けしたいと思います。

Dokcerのページ

Dockerとは?

昨年、今年とサーバ界隈でたびたび話題にあがっているのがDockerです。Linuxコンテナを使ってアプリケーションの配置を自動化し、複雑化するサーバアプリケーションをシンプルなものにしてくれます。

Docker – Build, Ship, and Run Any App, Anywhere

よくある問題として、アプリケーションごとの依存するライブラリやプログラミング言語のバージョン問題や、多数のサーバで同じ環境を整えなければならないといったことがあります。1台セットアップして終わり、であれば関係ないでしょうが複数台をセットアップしたり、ライブラリをバージョンアップした時のテストなどを考えると頭の痛い問題です。

そういった問題の解決策として考えられているのがDockerです。開発環境のスクラップ&ビルドとしてよくきかれましたが、6月に1.0がリリースされたこともあって、実際の運用の中で使われるケースも増えています。

そこでまずはDockerを試すまでをステップを踏んで説明していきたいと思います。Linuxに限らず、手元のマシンでさくっと試せますのでぜひチャレンジしてみてください。

Windowsでの始め方

WindowsではWindows 7以上、かつ64bit版に対応したBoot2Dockerがリリースされています。GitHubからインストーラーがダウンロードできるようになっています。

Docker for Windowsのインストーラー
Windowsはインストーラー付属です

インストーラーは VirtualBoxやGitクライアントも含んでいますので、他に用意するものはありません。既に環境があればそちらを利用することもできます。

Docker for Windowsのアイコン
アイコンをダルブクリックでDockerが開始します

インストールすると、 Boot2Docker Start というショートカットが作成されますので、それをダブルクリックするとコマンドプロンプトが開いてDockerが開始されます。 初期パスワードはtcuserです。

Docker for Windowsの起動
Windows版での起動画面

Dockerとは言っても、実際のところ CoreOSがインストールされたVirualBoxイメージが立ち上がるので、Windows上で動いているというのとは若干違うかも知れません。とは言えVirualBox上ではCoreOSが動いていますので普通にdockerコマンドが使えます。

$ docker run ubuntu /bin/echo hello world

などとコマンドを打てば、初回は数十MBのUbuntuイメージをダウンロード後、 hello world と出力されます。その後からはすぐにレスポンスが返るようになるはずです。

Mac OSXでの始め方

Mac OSXもそのまま動くのではなく、VirtualBox上のイメージを使って動作します。Mac OSXの場合、専用のインストーラーとHomebrewを使ったインストールの2種類が用意されます。Homebrewを使う場合、以下のコマンドでインストールできます。

$ brew tap homebrew/binary
$ brew install docker boot2docker

インストールが終わったら、まず初期化をします。

$ boot2docker init

初期化のタイミングで公開鍵を生成したりします。次に起動です。

$ boot2docker up

VMが起動後、最後に

export DOCKER_HOST=tcp://192.168.59.103:2375

のようなメッセージが出ますので、これを環境変数として設定します。そうするとDockerのサーバにSSHでログインしたりすることなく、

$ docker run ubuntu /bin/echo hello world
hello world

のように結果が得られるようになります。VMを介してはいますが、Windowsよりも本当のDockerっぽいと言えるでしょう。

クラウドでの始め方

さて、ここからが本番です。Dockerを使うのはやはり素のLinux上が一番すっきりしていると思います。今回は当社のさくらのクラウドを使ったDockerの始め方を紹介します。実際のところ、5分もかからずにはじめられるはずです。

必要なもの

<さくらのクラウドのアカウント>

さくらのクラウド
さくらのクラウド

アカウントはさくらのクラウドトップページからできます。

<クラウドサーバを追加する>

サーバ追加
サーバ追加はここをクリックしてください

管理画面に入りましたら、サーバの追加を選択します。追加画面では、サーバの名前、メモリ数、ディスクプランなどを決めていきます。大事なのはアーカイブ選択の中にある CoreOS 367.1.0 (stable) を選択することです(バージョン番号は2014年08月現在です)。これだけで必要なものが揃います。

アーカイブ選択
アーカイブ選択でCoreOSを選択します

後はパスワードや公開鍵の入力などを行ってください。この状態で起動してみます。

<サーバに接続する>

Webベースのコンソールもありますが、今回はターミナルからつないでみます。公開鍵認証が優先なので、先ほど設定していれば、

$ ssh core@server_ip_address

で接続できます(server_ip_addressは各自読み替えてください)。IPアドレスはサーバ一覧のインタフェースで確認してもらえます。

IPアドレス確認
IPアドレスはここで確認できます

<実行>

ログインできたら、

$ docker run ubuntu /bin/echo hello world

と打ってみます。回線の速度も速いので、30秒もあれば初回のイメージダウンロード&実行が行われるのではないでしょうか。その後の実行については待たされるようなことありません。

コンソールではじめてのDocker実行
最初の実行とその結果

試してみる

環境が整ったところで、Dockerを試してみましょう。今回はよくありそうなケースとして、WordPressを設定してみることにしましょう。

とりあえず使ってみる

といっても特に作業する訳ではありません。既にDockerfileを用意してくれている方がいますので(ここがDockerの強みですね!)、それを利用します。

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

(your_name) は自由に設定してください。これを実行すると、必要なイメージがダウンロードされてビルドが開始されます。終わったら、

$ docker run --name wordpress -d -p 8080:80 -p 2022:22 (your_name)/wordpress

のように実行します。(your_name) は先ほど決めたものを指定してください。80番(HTTP)、22番(SSH)のポートをホストのどこにルーティングするかも設定しています。この例の場合、80番を8080に、22番を2022に指定しています。

この起動は一瞬で終わるはずです。終わったら、 http://(さくらのクラウドのIPアドレス):8080/ にアクセスしてみてください。WordPressのインストール開始画面が表示されるはずです。

WordPressのインストール
WordPressのインストール画面

使い終わったら、

$ docker stop wordpress

で終了します。これは8080にもアクセスできなくなります。もう一度再開するには、

$ docker start wordpress

と入力します。

なお、このWordPressのDockerfileの場合、SSHやMySQLのパスワードはログファイル中に書き出されています。

$ docker logs wordpress
ssh user password: hogehoge // <- ここ
140731 07:47:57 mysqld_safe Can't log to error log and syslog at the same time.  Remove all --log-error configuration options for --syslog to take effect.
140731 07:47:57 mysqld_safe Logging to '/var/log/mysql/error.log'.
140731 07:47:57 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
mysql root password: hugahuga // <- ここ
wordpress password: testtest // <- ここ
140731 07:48:08 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

のような感じです。

別なコンテナを作ってみる

先に作ったWordPressを終了します。

$ docker stop wordpress

そして再度、今度は名前を変えて実行してみます。

$ docker run --name wp2 -d -p 8080:80 -p 2022:22 (your_name)/wordpress

これで再度ブラウザでアクセスすると、またインストールから開始になります。最初に作ったWordPressとは別物です。

変更した内容を保存しておく

コンテナは基本的に実行後に破棄されます。しかし実行した状態を呼び出したいという場合は多いと思います。そんな時にはまず、 $ docker ps -a を実行します。

$ docker ps -a
CONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS                       PORTS               NAMES
75ccdd14edde        moongift/wordpress:latest   /bin/bash /start.sh    3 minutes ago       Exited (-1) 47 seconds ago                       wp3                 
5639dc9af0b5        moongift/wordpress:latest   /bin/bash /start.sh    5 minutes ago       Exited (-1) 3 minutes ago                        wp2                 
31a1145c2146        moongift/wordpress:latest   /bin/bash /start.sh    35 minutes ago      Exited (-1) 4 minutes ago                        wordpress           
ab7ef4cc2467        ubuntu:latest               /bin/echo hello worl   53 minutes ago      Exited (0) 53 minutes ago                        drunk_archimedes    
b6b436f12593        ubuntu:latest               /bin/echo hello worl   53 minutes ago      Exited (0) 53 minutes ago                        berserk_wilson      

そうするとこのように一覧が出ますので、この中から使いたいコンテナIDをコピーして状態をコミットします。

$ docker commit 31a1145c2146 wp:test

これでコンテナがコミットされ、イメージ化されます。

$ docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
wp                   test                9dfde4e6f5c7        34 seconds ago      499.4 MB
moongift/wordpress   latest              4f14d0b090bd        39 minutes ago      474.7 MB
ubuntu               latest              ba5877dc9bec        9 days ago          192.7 MB

こうやって既存のイメージから自分のカスタマイズを行っていくことができるようになります。

コンテナと仮想化の違い

Dockerは古くからあるコンテナ技術を今風にしたもので、昔であればchrootやjailといった技術で知られていました。ある領域以下を囲んで(コンテナ化して)、外部から触れなくしたり、逆に内部からも外部を触れなくすることでセキュアな環境を用意します。とは言え仮想化とは異なり、同じOS上で動いているものになるのでバーチャルマシンのように毎回の実行に数十秒かかるといったことはありません。突き詰めればプロセスの一つです。

コンテナはCPUやメモリなどのリソースも分割して管理されますので、一つのコンテナがCPUをマックスまで使ってしまっても他のコンテナが影響を受けることはありません。そういった独立性も大事な技術です。また、コンテナ内部からホストの環境に直接触れないということもあって、万一セキュリティインシデントがあってもコンテナを破棄するだけという安心もあります。

他のDockerを探す

他の方が作ったDockerを探すにはDocker Hubを使うのが一番です。Docker Hubについては当ブログの記事、Dockerコンテナをクラウドサービス上で共有できる「Docker Hub」を使ってみるを参考にしてください。

GitHub風のUIで、有名なソフトウェアを使えるDockerリポジトリが並んでいます。ここを探すだけでも大抵のものが手に入りそうです。

Docker Hub

自作コンテナの作り方

DockerはDockerfileという設定ファイルを記述してコンテナを作成できるのですが、ゼロから全て記述して作っていくというのは意外と骨が折れる作業です。個人的にはベースになるコンテナを取ってきて、そこに必要なライブラリを入れつつコミットしていくのが早いのかなと思います。

一度UbuntuやCentOSでコンテナを作成し、bashで接続します。

$ docker run -i -t ubuntu /bin/bash

後はこの状態から必要なライブラリをインストールしていきます。終わったらexitします。

$ exit

Dockerを実行しているshellに戻ったら、イメージの一覧を表示します。-a をつけて、終了しているコンテナも出します。

$ docker ps -a

その中(恐らく一番上)に今作業したコンテナが出ると思いますので、それをコミットしてイメージにします。

$ docker commit COMMIT_ID (your_name)/(image_name)

これで作業状態がコミットされます。こうやって段階的に作っていくのが一番手軽だと思います。作業が終わればプッシュすることでDocker Hubなどに保存されます。

Dockerfileを作成する

Dockerfileを使った場合、ベースになるUbuntu/CentOSなどのイメージからコマンドを実行してコンテナを作っていきます。まっさらから作りますので環境が綺麗に整います。

ROM ubuntu
MAINTAINER Your name <example@example.com>


RUN echo "Hello World"

この形がDockerfileの基本形になります。後はDockerfileのあるディレクトリで、

docker build -t (your_name)/(your_image_name)  .

と実行するとイメージが作成(ビルド)されます。

Dockerコンテナをゼロから作成する

さらにDocker Hubからだけでなく、自分でゼロからコンテナを作ることもできます。当ブログの記事、Docker向けのコンテナをゼロから作ってみようを参考にしてください。

Dockerホスト/ゲストでファイル共有

Dockerのホストとゲストで特定のディレクトリを共有できます。こうすることで複数コンテナ間でファイルを共有したり、コミットしなくともデータの永続化を実現できます。

$ docker run -v /host_path:/guest_path -i -t (your_name)/(your_image_name) /bin/bash

このように host_path と guest_path を指定するだけで共有できます。

便利なサービスたち

Web UI

Dockerを自動化する場合はコマンドラインで操作していくのが良いですが、その管理となるとWebブラウザ上で行いたいと考えるでしょう。そこで幾つかのDocker管理UIがリリースされています。

<Shipyard>

Shipyard
Shipyard

ShipyardをインストールするのもDockerでできます。こういう所も便利ですね。

docker run -i -t -v /var/run/docker.sock:/docker.sock shipyard/deploy setup

立ち上がったら、 http://docker_ip:8000/ へアクセスして、 admin/shipyard でログインできます。

Shipyard Project

<DockerUI>

DockerUI
DockerUI

DockerUIは以下のようなコマンドでインストール、実行できます。

$ docker build -t crosbymichael/dockerui github.com/crosbymichael/dockerui
$ docker run -d -p 9000:9000 -v /var/run/docker.sock:/docker.sock crosbymichael/dockerui -e /docker.sock

これで完了です。 http://docker_ip:9000/ へアクセスするとDockerUIの管理画面が表示されます。

便利なライブラリ

その他にもDocker周辺には様々なサービスが立ち上がっています。ここではその一例を紹介します。

<Flynn>

Flynn
Flynn

DockerをHeroku風に使おうという試みです。つまりDockerをPaaSにしてしまうということです。Go言語で書かれています。

Flynn – The product that ops provides to developers

<CoreOS>

CoreOS
CoreOS

Dockerのために作られたごく小さなLinuxディストリビューションです。元々DockerはCentOSやUbuntuなどで動いていましたが、今度はCoreOSをベースにしていくのが一番速そうです。

CoreOS is Linux for Massive Server Deployments

<Using etcd with CoreOS>

etcd
etcd

Dockerでetcdを使う方法です。etcdを使うことで設定ファイルを共有できるようになりますので、Dockerが複雑化したり、複数のコンテナ間で設定を共有できるようになります。

Using etcd with CoreOS

<Deis>

Deis
Deis

Docker/CoreOSを使った軽量PaaSです。Herokuと同じような使い方でDockerコンテナ上で動作するアプリケーションがデプロイできます。

Deis | Your Paas. Your Rules.

<Shippable>

Shippable
Shippable

ShippableはGitHub/Bitbucketに対応したCIサービスを提供しています。その際、Dockerを使ってセキュアに実行できるようになっています。

Shippable: Hosted continuous integration and deployment platform

ホスティング

Dockerを使ったホスティングは実に数多いです。元々コンテナ技術を使ったホスティングサービスは幾つかあったのですが、Dockerによってより手軽に、自動スケーリングできるようになったということかも知れません。

<Orchard>

Orchard
Orchard

メモリは512MB〜8GB、ディスクはSSDで20GB〜60GBまで選べます。コア数も1〜4コアとなっています。価格は月額10ドル(または1.34セント/時間)〜月額160ドル(または21.44セント/時間)となっています。

Orchard | Instant Docker hosts in the cloud

<Tutum>

Tutum
Tutum

月額4ドル(256MBメモリ)から月額64ドル(4GBメモリ)となっています。フリートライアルも用意されています。

Docker Hosting – Run Docker Containers in the Cloud – Tutum

<Stackdock>

Stackdock
Stackdock

価格は3段階で、1〜12GBのメモリ、ディスクはSSDで20〜100GB、コア数は1〜4コアとなっています。最低月額5ドルから100ドルと幅広くなっています。

Stackdock – Docker hosting on blazing fast dedicated infrastructure

<Quay.io>

Quay.io
Quay.io

こちらはDockerリポジトリをホスティングするサービスになります。月額12ドルで5つのリポジトリを管理できます。チームであれば10リポジトリが25ドルからとなっています。

Hosted Private Docker Registry · Quay.io

<Docker Hub>

Docker Hub
Docker Hub

Dockerでもプライベートリポジトリホスティングサービスを提供しています。月額7ドルで5つのプライベートリポジトリが利用できます。

Docker Hub – Content, Collaboration, Workflows, and More

その他

<The Docker Book>

The Docker Book
The Docker Book

Dockerに関する書籍(英語)を販売しています。価格は9.99ドルです。PDF/ePub/Kindle版などがあります。日本でもKindle本を中心に幾つか解説書が出てきていますね。


いかがだったでしょうか。Dockerはファイルシステム、環境をポータブルにし、差分の管理を使ってサーバ設定を自動化できます。サーバ管理者がテスト環境を構築していく以外にも用途が増えていっています。

本番環境での利用は怖くとも、社内の開発部署内で使ってみるのはいかがでしょう。RedmineやJenkins、WikiエンジンなどもDockerを使って一発構築できますし、WordPressなどの環境も簡単に構築できますのでデザイナーの方にとっても便利ではないでしょうか。

Dockerはテスト時にはローカルでも良いですが、やはりCoreOSを使って高速なネットワークを使って素早くコンテナを作り出すところに気持ちよさがあります。ぜひ1時間9円から使えるさくらのクラウドでDockerの面白さを体感してください!

【関連記事】
>>これから始める「DockerでかんたんLAMP環境 for CentOS」
>>Dockerコンテナをクラウドサービス上で共有できる「Docker Hub」を使ってみる
>>Docker向けのコンテナをゼロから作ってみよう

おしらせ

banner_cloud

「Packer」でDocker用のイメージファイルを作ってみよう

$
0
0

KVMやXen、VMware、VirtualBoxといった仮想化ソフトウェアやDockerなどのコンテナ管理ツールを利用する際には、それら仮想マシンやコンテナを起動するためのディスクイメージファイルが必要となる。今回はさまざまな仮想化ソフトウェア/コンテナ管理ソフトウェアで利用できるディスクイメージファイルを作成できる「Packer」というツールを紹介する。

複数の形式のディスクイメージを統一的な操作で作成できる

KVMやXen、VMware、VirtualBoxといった仮想化ソフトウェアやDockerなどのコンテナ管理ツールではそれぞれ独自のディスクイメージ形式が採用されており、その作成には専用のツールを利用する。そのため、複数の仮想化ソフトウェアを併用している場合、各ツールごとに設定ファイルを作成したり、対応するコマンドを実行して個々のディスクイメージを作成する必要があった。こういった作業を効率化できるツールが、今回紹介するPackerである(図1)。

図1 PackerのWebサイト
図1 PackerのWebサイト

Packerはユーザーが用意した設定ファイルに従って、指定された仮想マシン/コンテナ向けのディスクイメージや仮想マシンイメージ、コンテナイメージ(以下、まとめて「イメージファイル」と呼ぶ)の作成とプロビジョニングを行うツールだ。

Packerの特徴として、「builder」と呼ばれるイメージファイルの作成処理を行う部分や「provisioner」と呼ばれるプロビジョニング処理を行う部分がモジュール化されている点がある。これらを分離することで、異なる仮想化ソフトウェアやコンテナ管理ツールに対し、同一のプロビジョニング処理を容易に実行できるようになっているのだ(図1)。

図1 Packerのアーキテクチャ
図1 Packerのアーキテクチャ

デフォルトではDockerやQEMU(KVMやXen)、VirtualBox、VMwareなどに対応するbuilderが用意されており、またprovisonerとしてはシェルスクリプトを実行するものや任意のファイルをコピーするもの、そしてChefやPuppet、Ansibleといった設定ツールを実行するものが用意されている。これにより、さまざまな仮想化ソフトウェアやコンテナ管理ツールに対し、同じ環境を含むイメージファイルを作成できる。

こういったアーキテクチャを見ると、以前紹介した仮想環境構築ツール「Vagrant」に似ていると思った人もいるだろう。実はPackerはVagrantと同じ開発者が開発を行っており、そのため設定ファイルやその使い方が似通っている。ただしPackerはVagrantと組み合わせても利用できるが、Vagrant専用のツールではない。そのため、ほかの仮想化ソフトウェアやツールを利用しているユーザーにとっても有用だ。

Packerではできないこと

「さまざまな仮想化ソフトウェアやコンテナ管理ツール向けのイメージファイルを作成できる」と聞くと、汎用的な万能ツールのようにも聞こえるが、Packerは実際には各仮想化ソフトウェアやコンテナ管理ツールのコマンドを内部的に実行してイメージファイルを作成する処理を行うだけなので、制約も多い。

たとえば、VirtualBoxやQEMU向けのbuilderではISOイメージからのイメージファイル作成が可能だが、これはVirtualBoxやQEMUを実行して仮想環境を作成し、そのうえでISOイメージからインストーラを起動することで実現されている。そのため、インストール作業を完全に自動化するにはKickstartなどの自動インストール技術の知識が必要だ。

また、既存のイメージファイルをベースに新たなイメージファイルを作成することは可能だが、イメージファイルをほかの仮想化/コンテナ技術向けに変換する機能などは用意されていない。

Packerを利用するメリット

Packerにはある程度の制約があるのだが、その上でPackerを利用するメリットとしては、インストール後に自動的にあらかじめ指定しておいたプロビジョニング処理を実行できるという点がある。また、一度設定ファイルを作成すれば、その後は同一の環境や似たような環境を容易に構築できるのも利点だ。

特にPackerの利点が生きるのは、provisionerを活用する場合だろう。環境構築をできるだけprovisioner側で行うように設定しておくことで、少ない手間でさまざまな仮想化ソフトウェアやコンテナ管理ツールに対応できるようになる。

Packerでのイメージファイル作成の流れ

Packerでイメージファイルを作成するには、イメージファイル作成の手順などを記載した設定ファイルが必要となる。設定ファイルはJSON形式で記述し、次のような構成になっている。設定ファイル内には複数のbuilderやprovisioner向けの設定を同時に記述することが可能で、これを利用して1つの設定ファイルで複数の仮想化ソフトウェア/コンテナ管理ツール向けのイメージを作成できる。

{
  "description": "<ここにテンプレートの説明文を記述する>",
  "min_packer_version": "<ここで必要とするPackerのバージョンを指定する>",
  "variables": {
    <このテンプレート内で使用する変数を定義する>
    
    
  },
  "builders": [
    {
      <1つ目のbuilderに対する設定を記述する>
    },
    {
      <2つ目のbuilderに対する設定を記述する>
    },
    
    
  ],
  "provisioners": [
    {
      <1つ目のprovisionersに対する設定を記述する>
    },
    {
      <2つ目のprovisionersに対する設定を記述する>
    },
    
    
  ],
  "post-processors": [
    {
      <イメージファイルの作成後に行う1つ目の処理を記述する>
    },
    {
      <イメージファイルの作成後に行う2つ目の処理を記述する>
    },
    
    
  ]
}

なお、「builder」以外の項目はオプションなので、不必要な場合は省略が可能だ。

Packerのインストール

Packer公式Webサイトのダウンロードページでは、Mac OS XおよびLinux、Windows、FreeBSD、OpenBSD向けのバイナリが配布されている。また、ソースコードはGitHubで公開されているが、コンパイルにはGo言語環境が必要であるため、通常はバイナリをダウンロードして使用するほうが良いだろう。

配布されているバイナリはZIP形式で圧縮されており、中にはDockerの実行ファイルがそのまま入っている。適当なディレクトリにこれを展開するだけでインストールは完了だ。なお、以下では「~/packer/」ディレクトリに展開したものとして作業を進めている。

PackerでDocker用のイメージファイルを作成する

それでは、実際にPackerを使ってイメージファイルを作成する流れを見てみよう。まずはシンプルなものとして、Docker向けのイメージファイルを作成する例を紹介する。この場合、設定ファイルにはDocker用のbuilderである「docker」用の設定を記述すれば良い。なお、Docker用のイメージファイルを作成するには、Packerrを実行する環境にDockerがインストールされている必要がある。Docker向けイメージファイルの作成やについては「Docker向けのコンテナをゼロから作ってみよう」という記事で紹介しているので、そちらも参照して欲しい。

設定ファイルを作成する

docker builderで必要となる設定項目についてはドキュメントのDocker Builderページに記載されているが、最低限必要となるのはdocker builderを利用することを指定する「type」と、出力先ファイルを指定する「export_path」、ベースとするDockerのイメージファイルを指定する「image」という項目だ。今回はDockerが提供しているCentOS 7イメージを使用し、作成したイメージファイルは「packer-centos7-docker.tar」というファイルに保存することとした。この場合、設定ファイルは以下のようになる。

{
  "builders": [
    {
      "type": "docker",
      "image": "centos:centos7",
      "export_path": "packer-centos7-docker.tar"
    }
  ]
}

このファイルを「centos7.json」というファイルに保存し、packer buildコマンドを実行すると、DockerHubからCentOS 7環境が含まれたイメージがダウンロードされ、その中身が展開されてtarファイルとして保存される。

$ sudo ~/packer/packer build centos7.json
docker output will be in this color.

==> docker: Creating a temporary directory for sharing data...
==> docker: Pulling Docker image: centos:centos7
    docker: Pulling repository centos
==> docker: Starting docker container...
    docker: Run command: docker run -d -i -t -v /tmp/packer-docker698088109:/packer-files centos:centos7 /bin/bash
    docker: Container ID: d9a0f879085b9d04d046eb8a3e43dde3a342327c90006fa684a2d6bd828d3079
==> docker: Exporting the container
==> docker: Killing the container: d9a0f879085b9d04d046eb8a3e43dde3a342327c90006fa684a2d6bd828d3079
Build 'docker' finished.

==> Builds finished. The artifacts of successful builds are:
--> docker: Exported Docker file: packer-centos7-docker.tar

なお、Dockerの各コマンドの実行にはroot権限が必要であるため、この場合packerもroot権限で実行する必要がある。

ここで作成されたtarファイルは、docker importコマンドでローカルのdockerにインポートできる。

$ sudo docker import - mycentos7 < packer-centos7-docker.tar
ad6d0a32d9fc973ee7fe450716e3f09eee9d0cfaffad6bdfcdf24c5cf4d028b6
# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
mycentos7           latest              ad6d0a32d9fc        29 seconds ago      243.7 MB

provisionerと組み合わせて使う

Packerを使ってDocker用イメージファイルを作成してみたが、これだけではdockerの機能を使ってイメージファイルを作成するのと何ら変わりがない。そこで、続いてはprovisionerを使い、chef-soloを使ってプロビジョニング処理を実行した上でイメージファイル化する、という処理を行ってみよう。

これを実現するには、設定ファイルにprovisionerに関する項目を追加すれば良い。作成した設定ファイルは次のようになる。

{
  "builders": [
    {
      "type": "docker",
      "image": "centos:centos7",
      "export_path": "packer-centos7-docker.tar"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": ["yum install -y hostname"]
    },
    {
      "type": "chef-solo",
      "cookbook_paths": ["cookbooks"],
      "run_list": ["webserver"],
      "prevent_sudo": true
    }
  ]
}

ここでは、「shell」および「chef-solo」という2つのprovisionerの設定を追加している。shell provisionerの設定項目についてはShell Provisionerドキュメント、chef solo用provisionerの設定項目については、Chef Solo Provisionerドキュメントにまとめられているので、詳しくはこれらを参照してほしいが、shell provisionerは指定したコマンドを実行するもの、chef-solo provisionerはchef soloの実行を行うものだ。

まず、shell provisionerでは「yum install -y hostname」というコマンドを実行させている。Dockerが公式に用意しているCentOS 7イメージにはhostnameコマンドが含まれておらず、そのためchef-soloコマンドの実行に失敗するため、これを回避するための処理だ。

続いてのchef-solo provisionerでは、packerを実行したディレクトリ内の「cookbook」ディレクトリ内にあるChefのCookbookをイメージ側にコピーし、その中の「webserver」というRecipeを実行する、という処理を行わせている。

なお、chef-solo provisionerではchef-soloのインストール作業についても自動的に実行してくれる。そのため、あらかじめイメージ内にchef-sollをインストールしておく必要は無い。

また、これらファイルに加えて使用するChefのCookbookやRecipeも用意しておく。Chefについては以前『サーバー設定ツール「Chef」の概要と基礎的な使い方』という記事で説明しているので、詳しくはこちらを参照してほしいが、今回は次のように「knife cookbook create」コマンドでCookbookを作成し、Recipeを編集している。

$ mkdir cookbook
$ knife cookbook create webserver -o cookbooks/
** Creating cookbook webserver
** Creating README for cookbook: webserver
** Creating CHANGELOG for cookbook: webserver
** Creating metadata for cookbook: webserver
$ vi cookbooks/webserver/recipes/default.rb  # defualt.rbにRecipeを記述する

Recipeの内容は次のように「httpd」パッケージをインストールするだけというシンプルなものとした。

#
# Cookbook Name:: webserver
# Recipe:: default
#
# install apache http server
yum_package "httpd" do
  action :install
end

これら設定ファイルを用意した上でpacker buildコマンドを実行すると、イメージファイルの作成や、コンテナの起動、hostnameパッケージのインストールやchef-soloのインストールおよび実行といった処理が自動的に行われ、そのコンテナがイメージファイル化される。

$ sudo ~/packer/packer build centos7.json
docker output will be in this color.
  ↓イメージのダウンロード(Pull)
==> docker: Creating a temporary directory for sharing data...
==> docker: Pulling Docker image: centos:centos7
    docker: Pulling repository centos
==> docker: Starting docker container...
  ↓コンテナの起動
    docker: Run command: docker run -d -i -t -v /tmp/packer-docker549661982:/packer-files centos:centos7 /bin/bash
    docker: Container ID: 6d98246a2284f8241b7b926c468ca9c74993dc7251d0f57628b80228da87d278
==> docker: Provisioning with shell script: /tmp/packer-shell419395520
  ↓hostnameパッケージのインストール
    docker: Loaded plugins: fastestmirror
    docker: Determining fastest mirrors
  
  
    docker: Installed:
    docker: hostname.x86_64 0:3.13-3.el7
    docker:
    docker: Complete!
  ↓chef-soloのインストール
==> docker: Provisioning with chef-solo
    docker: Installing Chef...
  
  
    docker: Thank you for installing Chef!
  ↓cookbookをコンテナ内にコピー
    docker: Creating directory: /tmp/packer-chef-solo
    docker: Creating directory: /tmp/packer-chef-solo/cookbooks-0
    docker: Creating configuration file 'solo.rb'
    docker: Creating JSON attribute file
  ↓cookbookの実行
    docker: Executing Chef: chef-solo --no-color -c /tmp/packer-chef-solo/solo.rb -j /tmp/packer-chef-solo/node.json
  
  
    docker: [2014-08-11T10:43:41+01:00] INFO: Processing yum_package[httpd] action install (webserver::default line 11)
    docker: [2014-08-11T10:43:42+01:00] INFO: yum_package[httpd] installing httpd-2.4.6-18.el7.centos from updates repository
    docker: [2014-08-11T10:44:18+01:00] INFO: Chef Run complete in 37.576576759 seconds
  
  
  ↓コンテナのエクスポート
==> docker: Exporting the container
==> docker: Killing the container: 6d98246a2284f8241b7b926c468ca9c74993dc7251d0f57628b80228da87d278
Build 'docker' finished.

==> Builds finished. The artifacts of successful builds are:
--> docker: Exported Docker file: packer-centos7-docker.tar

次回に続く

さて、今回はDockerのイメージ作成を例にPackerによるイメージ作成方法を紹介したが、Packerを利用することで、このようにコンテナのプロビジョニング作業が非常に簡単に実行できる。ChefやPuppet、Ansibleなどのデプロイツールを使っているなら、これだけでもPackerを導入する価値があるだろう。

さらに、Packerではbuilderに関する設定を追加するだけで、同様のプロビジョニングを異なる仮想化ソフトウェア/コンテナ管理ツールに対しても実行できるようになる。これについては、次回VirtualBoxやQEMU(Xen/KVM)向けイメージの作成を例に紹介する。

おしらせ

banner_vps

Dockerで使うサーバサイドソフトウェア(エンジニア編)

$
0
0

Linuxコンテナを使った仮想化ソフトウェアDocker。興味はありつつも、実際の運用の中で活かす機会は意外と多くないのではないでしょうか。さらに1.0となったとは言え、実運用のサーバの中で活用していくというのは勇気が出ないかも知れません。

そこで今回はあくまでも開発の部署内だけでDockerを使っていくという方法を提案したいと思います。Dockerのメリットの一つ、外部の人たちが作ってくれているコンテナを使ってサービスを立ち上げてみましょう。今回は特にエンジニアがよく使いそうなソフトウェアにフォーカスを当てています。

必要なもの

さくらのクラウドのアカウント

さくらのクラウドトップページ
さくらのクラウドトップページ

アカウントはさくらのクラウドトップページから作成できます。

クラウドサーバを追加する

サーバ追加画面
サーバ追加画面

管理画面に入りましたら、サーバの追加を選択します。追加画面では、サーバの名前、メモリ数、ディスクプランなどを決めていきます。大事なのはアーカイブ選択の中にある CoreOS 367.1.o0 (stable) を選択することです(バージョン番号は2014年08月現在です)。

CoreOSを選択!
CoreOSを選択!

後はパスワードや公開鍵の入力などを行ってください。この状態で起動してみます。

サーバに接続する

Webベースのコンソールもありますが、今回はターミナルからつないでみます。公開鍵認証が優先なので先ほど設定していれば、

$ ssh core@server_ip_address

で接続できます(server_ip_addressは各自読み替えてください)。IPアドレスはサーバ一覧のインタフェースで確認してもらえます。

さくらのクラウドでIPアドレスを確認
さくらのクラウドでIPアドレスを確認

実行

ログインできたら、

$ docker run ubuntu /bin/echo hello world

と打ってみます。回線の速度も速いので、30秒もあれば初回のイメージダウンロード&実行が行われるのではないでしょうか。その後の実行については待たされるようなことありません。

初回実行
初回実行

では下準備は完了したのでさっそく行ってみましょう!

Redmineをインストールしよう!

では早速一つ目、Redmineをインストールしてみましょう。コマンドは1行です。

$ docker run --name redmine -d -p 80:80 sameersbn/redmine

コンテナの名前をredmineとしています。-dはバックグラウンドで実行するためのオプションです。-pはゲストOSのポート番号をフォワードしています。今回はホストへの80番ポートアクセスをそのままゲストコンテナに流しています。

Docker経由で立てたRedmineの画面
Docker経由で立てたRedmineの画面

起動したらadmin/adminでログインできます。

データの永続化

コンテナは仮想化されたデータなので、落とすと消えてしまいます(コミットすれば保存されますが)。そこでホストOS側のディレクトリを共有化するようにします。

$ sudo mkdir -p /opt/redmine/files

としてフォルダを作成した上でコンテナ起動時に指定するようにします。

$ docker run --name redmine -d  -p 80:80 \
  -v /opt/redmine/files:/redmine/files sameersbn/redmine

外部のデータベースに接続する

さらにデータベースもコンテナ内部のものではなく外部のものを使うようにすればデータが維持されるようになります。そのためにはまずMySQL側でRedmineのデータベースを作成します。

$ mysql -uroot -p
> CREATE USER 'redmine'@'%.%.%.%' IDENTIFIED BY 'password';
> CREATE DATABASE IF NOT EXISTS `redmine_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `redmine_production`.* TO 'redmine'@'%.%.%.%';

その上でコンテナ起動時にデータベースの接続先を指定します。

$ docker run --name redmine -it --rm \
  -e "DB_HOST=192.168.1.100" -e "DB_NAME=redmine_production" \
  -e "DB_USER=redmine" -e "DB_PASS=password" \
  -v /opt/redmine/files:/redmine/files sameersbn/redmine app:db:migrate

なおこれは初回起動時で、次回からは次のように指定します。

$ docker run --name redmine -d \
  -e "DB_HOST=192.168.1.100" -e "DB_NAME=redmine_production" \
  -e "DB_USER=redmine" -e "DB_PASS=password" \
  -v /opt/redmine/files:/redmine/files sameersbn/redmine

さらに同様の操作で別途MySQLのDockerコンテナを用意して、そちらとリンクさせる方法もあります。

$ docker run --name redmine -it --rm --link mysql:mysql \
  -e "DB_USER=redmine" -e "DB_PASS=password" \
  -e "DB_NAME=redmine_production" \
  -v /opt/redmine/files:/redmine/files \
  sameersbn/redmine app:db:migrate

こちらの方法で安全に運用できるでしょう。

sameersbn/docker-redmine

Jenkinsをインストールしよう!

継続的インテグレーションができる環境を構築する上でJenkinsは欠かせません。Dockerを使えばJenkins環境も簡単に構築できます。

Jenkinsについては公式イメージが用意されていますのでさらに安心して利用できるでしょう。

Docker Hubに登録されています
Docker Hubに登録されています
$ docker run -p 8080:8080 jenkins

さらにデータの永続化を考えるならば、

$ sudo mkdir -p /opt/jenkins_home
$ docker run -p 8080:8080 -d -v /opt/jenkins_home:/var/jenkins_home jenkins

といった形で起動します。この場合、ホストの /opt/jenkins_home にデータが保存されます。

日本語も使えます
日本語も使えます

jenkins Repository | Docker Hub Registry – Repositories of Docker Images

Gitlabをインストールしよう!

最後にGitlabをインストールしてみます。Gitlabを使えば開発時のソースコード管理がとても楽になりますし、GitHubなどの外部リポジトリサービスが使えない環境でも容易にGitリポジトリサーバが立てられるようになります。

$ docker run --name='gitlab' -it --rm \
  -p 10022:22 -p 10080:80 \
  -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022'\
  sameersbn/gitlab:latest

起動したら http://localhost:10080 へアクセスします。

ログインは root/5iveL!fe となっています。

最初の画面。ログイン後にパスワードを変更します
最初の画面。ログイン後にパスワードを変更します

データの永続化

Gitlabの場合もデータの永続化が大事です(リポジトリになりますので特にそうですね)。そこで次のようにします。

$ sudo mkdir -p /opt/gitlab/data

これで /opt/gitlab/data を共有して起動すればOKです。

$ docker run --name='gitlab' -it --rm \
  -p 10022:22 -p 10080:80 \
  -v /opt/gitlab/data:/home/git/data \
  -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022'\
  sameersbn/gitlab:latest

同様にMySQLについても永続化しなければなりません。データだけであれば、

$ sudo mkdir -p /opt/gitlab/mysql
$ docker run --name='gitlab' -it --rm \
  -p 10022:22 -p 10080:80 \
  -v /opt/gitlab/data:/home/git/data \
  -v /opt/gitlab/mysql:/var/lib/mysql \
  -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022'\
  sameersbn/gitlab:latest

でOKです。

初期IDとパスワードは root/5iveL!fe です。初回ログイン時に変更します。

SSHは10022になっていますので、例えばリポジトリへのアクセスは次のようになります。

$ git remote add origin ssh://git@153.120.83.76:10022/root/testproject.git
リポジトリ。push/pullが普通にできます。
リポジトリ。push/pullが普通にできます。

これで実際にpushしたり、pullしたりとGitリポジトリが使えるようになります。Gitlabをセットアップしようと思うとそれなりに苦労が伴うものですが、Dockerを使えばわずか数分で(しかもそのほとんどはダウンロードです!)設置が完了してしまいます。

sameersbn/gitlab Repository | Docker Hub Registry – Repositories of Docker Images


いかがでしたか。

Dockerをサーバエンジニアとしてばりばり使っていくのは理想的ですが、まだまだ現実的に難しかったり、運用しているサーバの台数はそこまで多くないという方もいるかと思います。しかしサーバサイドのソフトウェアをインストール、立ち上げるのに使うのであれば用途は多いのではないでしょうか。

他にも社内開発用途で使いそうなソフトウェアは多いと思います。Docker Hubではそういったソフトウェアが多数登録されていますので、ぜひ探してください。そして試される際にはさくらのクラウドのCoreOSを使ってみてくださいね!

おしらせ

banner_cloud

第1回さくナレ勉強会「Dockerハンズオン」を開催します!

$
0
0

まだまだ暑い日が続きますね。サーバエンジニアの方はうるさくも涼しいサーバルーム内でこの記事を読んでいるんじゃないかと思います。さて今回はまだDockerに触れたことがない、でも興味はあると言う方に向けてDockerハンズオン開催のお知らせです。

main_01

テーマ

先日掲載したレッツトライ!夏休みに覚えるDockerは読んでいただけたでしょうか。大きな反響をいただき、このお盆休みの間に試してみたという方もいらっしゃったと期待しています。

しかしそうはいっても多少なりとも環境の構築があるので、最初の一歩が踏み出しづらいという方もいるかと思います。そんな方々を対象に、さくナレで初の勉強会「Dockerハンズオン」を企画しました。

お誘いあわせの上、ぜひご参加ください!

日時

9月3日(水)18時半会場。19時開始。21時終了予定

場所

さくらインターネット セミナールーム
東京都新宿区西新宿4-33-4 住友不動産西新宿ビル4号館 6F

定員

20名

持ち物

  • ノートPC(ターミナルが動けばMac OSX/Windows/Linuxは問いません)
  • 公開/秘密鍵(公開鍵認証に使います)
  • ゆるくDockerを触ってみたいという気持ち

対象

Dockerを試してみたい方

内容

先日公開したレッツトライ!夏休みに覚えるDockerDockerで使うサーバサイドソフトウェア(エンジニア編)をベースに、Dockerの基礎を実際に手を動かしながら学んでいきます。

Dockerサーバはさくらのクラウド上に立てますので、環境を用意する必要はありません。アカウントはさくら側でご用意します。

スピーカー

MOONGIFT 中津川篤司(@moongiftid:moongift

タイムスケジュール

  • 18時30分:受付開始
  • 19時00分:開始/ご挨拶
  • 19時00分:Dockerの紹介、ハンズオンの説明(MOONGIFT 中津川)
  • 19時45分:ハンズオン
  • 21時ごろ:終了

参加費

無料

注意事項

  • タイムテーブルやコンテンツは当日のノリで変わってしまうことがあります。
  • ネット環境は無線LANになりますので対応したノートPCをお持ちください
  • 電源についてはご自由にお使いいただけますが、周りの方と譲りあってご利用下さい。

参加はこちらから

下記のお問い合わせフォームに「氏名」「メールアドレス」を記載の上、「お問い合わせ件名」に【第1回さくナレ勉強会参加希望】と記載ください。「お問い合わせ内容」の欄には「レッツトライ!夏休みに覚えるDocker」の感想や、参加の意気込み、スピーカーに聞きたいことなどを自由に記載ください。

【9月1日】このイベントは参加受付を終了いたしました。

※参加希望者数が定員を超えた場合は、さくナレ編集部にて抽選とさせていただきます。抽選の結果につきましては9月1日(月)PM17時までに当選者の方へのご連絡を持って変えさせていただきます。予めご了承下さい。

Packerを使ったISOイメージからの仮想マシン自動デプロイ

$
0
0

PackerにはVirtualBoxやQEMU(KVMおよびXen)などの仮想マシンイメージを作成する機能が用意されており、仮想マシン作成を自動化できる。今回は、Packerを使ってVirtualBoxおよびQEMU(KVM)用の仮想マシンにOSをインストールしてディスクイメージを作成する例を紹介する。

Packerを使って各種仮想マシン用のディスクイメージを作る

前回記事ではPackerを使ってDocker用のイメージを作成する方法を紹介した。今回はそれに続き、別の仮想化ソフトウェア向けのイメージを作成する方法を紹介していこう。

Packerではさまざまな仮想マシンやクラウドインフラ向けのディスクイメージを作成できるが、今回はCentOS 7のインストールISOイメージを元に、VirtualBoxとQEMU(KVM)向けのディスクイメージを作成する流れを紹介する。

VirtualBox向けのディスクイメージを作成する

まずはVirtualBox向けのディスクイメージの作成について説明しよう。PackerではVirtualBox向けのbuilderとして、「virtualbox-iso」と「virtualbox-ovf」の2つが用意されている。

virtualbox-ovfは前回紹介したDocker向けbuilderと似たような動作を行うもので、既存のVirtualBox用の仮想マシンファイル(OVFファイル)やディスクイメージを使って仮想マシンを起動し、指定されたprovisionerでプロビジョニングを実行したのち仮想マシンをエクスポートする、というものだ。

いっぽう、virtualbox-isoは次のような一連の流れを自動的に実行するものになる。

1. 新規に仮想マシンを作成する
2. 指定されたインストールCD/DVDのISOイメージファイルからインストーラを起動してインストールを行う
3. プロビジョニングを実行する
4.プロビジョニング後の環境を仮想マシンファイルとしてエクスポートする

ただし、インストーラによる作業についてはPackerでは自動化できない。もしこれらの作業を完全に自動したい場合、kickstartなどの自動インストール機能を別途利用する必要がある。

今回は、このvirtualbox-iso builderを使ってVirtualBox向けの仮想ファイルを作成することにする。なお、virtualbox-isoもしくはvirtualbox-ovf builderを利用する場合、Packerを実行するマシン上にVirtualBoxがインストールされている必要がある。また、後述するheadlessインストールを行わない場合は、VirtualBoxのGUIが利用できるようになっている必要もある。それぞれ事前に準備をしておこう。

VirtualBox用ディスクイメージを作成する設定を追加する

それでは、まずはvirtualbox-iso builder用の設定を前回作成した設定ファイルに追加していこう。今回追加したのは、下記の太字で示している部分だ。

{
  "builders": [
    {
      "type": "docker",
      "image": "centos:centos7",
      "export_path": "packer-centos7-docker.tar"
    },
    {
      ↓「virtualbox-iso」builderの設定であることを宣言する
      "type": "virtualbox-iso",
      ↓使用するISOイメージのチェックサム
      "iso_checksum": "96de4f38a2f07da51831153549c8bd0c",
      ↓使用するチェックサムの形式
      "iso_checksum_type": "md5",
      ↓ISOイメージのダウンロード元URL
      "iso_url": "http://test01.office.osdn.jp/packer/CentOS-7.0-1406-x86_64-NetInstall.iso",
      ↓プロビジョニングに使用するユーザー名
      "ssh_username": "root",
      ↓プロビジョニング実行時に仮想マシンにログインするために使用するパスワード
      "ssh_password": "SSH_Password",
      ↓インストール作業のタイムアウト時間
      "ssh_wait_timeout": "40m",
      ↓作成する仮想マシンのディスクサイズ
      "disk_size": "8000",
      ↓作成する仮想マシンのタイプ
      "guest_os_type": "RedHat_64",
      ↓仮想マシンをシャットダウンする際に使用するコマンド
      "shutdown_command": "/sbin/shutdown -h now",
      ↓シャットダウンコマンドを実行してから完了するまでの待機時間
      "shutdown_timeout": "20s",
      ↓作成する仮想マシンの名称
      "vm_name": "packer-centos7-vbox"
    },
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": ["yum install -y hostname"]
    },
    {
      "type": "chef-solo",
      "cookbook_paths": ["cookbooks"],
      "run_list": ["webserver"],
      "prevent_sudo": true
    }
  ]
}

追加したそれぞれのパラメータについてはPackerのドキュメントを参照してほしいが、ここでは「iso_url」パラメータでインストール用ISOファイルのダウンロード元を指定している。ISOイメージを配布しているミラーサーバーなどのURLを直接指定しても良いのだが、今回はダウンロードを高速化するため、ローカルネットワーク(office.osdn.jp)内にあるサーバーにISOイメージファイルを置き、そこからダウンロードを行っている。「iso_checksum」および「iso_checksum_type」パラメータはそのISOイメージファイルのチェックサムとその形式を指定するものだ。チェックサムについては多くの場合ISOイメージの配布元で公開されている。たとえばCentOSの場合、md5sum.txtにMD5形式のチェックサムを確認できる。

「ssh_username」および「ssh_password」はインストールの完了後にPackerがプロビジョニングに使用するアカウント名とそのログインパスワードを指定するものだ。今回はrootユーザーでプロビジョニングを実行するように設定した。

また、注意したいのが「ssh_wait_timeout」設定だ。Packerは仮想マシンを実行後、「ssh_username」で指定したアカウントを使って仮想マシンに対しログインを試みる。インストール作業中は当然ながらログインを行えないため、Packerは定期的に仮想マシンに対してログインを試行し続け、ログインに成功したら仮想マシンへのインストールが完了したと判断する仕組みになっている。このとき、ログインに成功しないまま「ssh_wait_timeout」で指定した時間が経過すると、Packerはインストール時に問題が発生したと判断して作業を中断してしまう。そのため、ここでは十分な時間を指定しておく必要がある。今回は「40m」(40分)を指定している。

設定ファイルの編集後にpacker buildコマンドを実行すると、図1のようにVirtualBoxが起動し、インストール画面が表示される。

$ ~/packer/packer build --only=virtualbox-iso centos7.json
図1 packer buildコマンドを実行するとVirtualBoxが起動する
図1 packer buildコマンドを実行するとVirtualBoxが起動する

ここでは「–only=virtualbox-iso」を新たに追加しているが、これは使用するbuilderを選択するためのオプションだ。今回は「virtualbox-iso」を指定している。このオプションが省略された場合、Packerは設定ファイル内のすべてのbuilderを順に実行してイメージの作成を実行する。

さて、今回はインストールの自動化に関する設定は行っていないので、ここではインストーラの起動画面のみが表示され、その後はなにも起こらない。そのため、続けて手動でインストーラを操作し、インストール作業を進めていく。このときrootパスワードにはPackerの設定ファイル内で「ssh_password」として指定したものを設定することに注意したい。

インストールの完了後に仮想マシンを再起動すると、PackerがSSHで仮想マシンにログインし、プロビジョニング作業を実行する(図2)。

図2 インストール後に仮想マシンを再起動すると、プロビジョニング処理が開始される
図2 インストール後に仮想マシンを再起動すると、プロビジョニング処理が開始される

プロビジョニング作業が正常に修了すると、イメージファイルのエクスポートが行われ、「output-virtualbox-iso」というディレクトリ内に保存される。「.vmdk」という拡張子のものがディスクイメージ、「.ovf」のものが仮想マシンの設定ファイルだ。

$ ls output-virtualbox-iso/
packer-centos7-vbox-disk1.vmdk  packer-centos7-vbox.ovf

kickstartを使ったインストール作業の自動化

さて、Packerを使ってVirtualBox用のディスクイメージを作成することはできたが、この例ではOSのインストール作業自体は手動で行っており、イメージを作り直すたびに同様の作業を行わなければならない。そこで、続いてはCentOSなどRed Hat Linux系ディストリビューションで利用できる自動インストール機能「kickstart」を使ってインストール作業を自動化してみよう。

kickstartは、インストール内容を記述した設定ファイルを指定してインストーラを起動することで、自動的にインストール作業を進める機能だ。Red Hat Linux系ディストリビューションでは、OSのインストール後にkickstart用の設定ファイル(kickstartファイル)を「/root/anaconda-ks.cfg」という名前で保存する。このファイルを利用することで、それと同じ環境を自動インストールできるようになる。また、このファイルを編集することで、インストール内容をカスタマイズすることも可能だ。

今回はPacker作成されたanaconda-ks.cfgファイルを若干修正して使用した。使用した設定ファイルは次のとおりで、修正した個所は太字で示している。

#version=RHEL7
# System authorization information
auth --enableshadow --passalgo=sha512

# Use network installation
url --url="http://ftp.jaist.ac.jp/pub/Linux/CentOS/7/os/x86_64/"
# Run the Setup Agent on first boot
#firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=jp106 --xlayouts='jp'
# System language
lang ja_JP.UTF-8

# Network information
network  --bootproto=dhcp --device=enp0s3 --ipv6=auto --activate
network  --hostname=localhost.localdomain
# Root password
rootpw --iscrypted <ハッシュ化されたパスワード>
# System timezone
timezone Asia/Tokyo --isUtc
user --groups=wheel --name=hylom --password=<ハッシュ化されたパスワード> --iscrypted --gecos="hylom"
# System bootloader configuration
bootloader --location=mbr --boot-drive=sda
autopart --type=lvm
# Partition clearing information
clearpart --none --initlabel 
# Skip EULA
eula --agreed
# auto reboot
reboot

%packages
@core

%end

具体的な修正個所は以下の3点だ。

  • インストール後に初めて起動した際に設定画面を表示する「firstboot」を無効する(「firstboot –enable」をコメントアウト)
  • ソフトウェア利用許諾契約(EULA)についての同意画面を表示させず、自動的に同意したことにする(「eula –agreed」)
  • インストール完了後、自動的に再起動を行う(「reboot」)

これらを指定することで、インストーラの起動後に入力を行うことなくインストール作業を進行させることが可能になる。

また、今回作成したファイルはPackerの設定ファイルと同じディレクトリ内に「kickstart」というディレクトリを作成し、そこに「anaconda-ks.cfg」というファイル名で保存している。

続いて、用意したkickstartファイルをインストーラに読み込ませるための設定を行う。こちらについては、Packerの設定ファイルに記述する。具体的に必要となる設定項目は次の2つだ。

  • HTTP経由でインストーラにkickstartファイルを渡すための「http_directory」
  • ブート時にインストーラに文字列を渡すための「boot_command」と「boot_wait」

kickstartを使ってインストールを行うには、作成したkickstartファイルを何らかの形でインストーラに渡す必要がある。これにはいくつかの手段が利用できるが、Packerには内部的にHTTPサーバーを起動して指定したディレクトリ内のファイルを公開する機能があり、これを利用するのが簡単だ。この機能を利用するには、「http_directory」という設定項目を追加し、その値に公開するファイルが含まれるディレクトリを指定すれば良い。今回は「kickstart」というディレクトリ内にkickstartファイルを格納しているので「./kickstart/」という値を指定する。

また、kickstartを使って自動インストールを行う場合、インストーラを起動した後にインストールオプションとしてkickstarterファイルを指定する必要がある。この入力処理を自動で行うためのオプションが「boot_command」と「boot_wait」オプションだ。これらのオプションを指定すると、仮想マシンを起動してからboot_waitオプションで指定した時間だけ待機し、続いてboot_commandオプションで指定した文字列を仮想マシンに対しキーボードイベントとして送信する、という処理が実行される。

今回は、先に作成した設定ファイルにさらに次のような項目を追加した。

“boot_command”: [
” text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/anaconda-ks.cfg ”
],
“boot_wait”: “10s”,
“http_directory”: “./kickstart/”

ここで指定している「{{ .HTTPIP }}」および「{{ .HTTPPort }}」という文字列はそれぞれ「HTTPIP」および「HTTPPort」という変数を参照することを示しており、これらはPackerの起動後、HTTPサーバーのIPアドレスとポート番号に自動的に置き換えられる。

これらの設定を追加した後に同じようにしてpacker buildコマンドを実行すると、仮想マシンの起動やインストーラの起動、インストール、プロビジョニングといった作業が全自動で行われてディスクイメージが生成される。

なお、この場合VirtualBoxの画面がデスクトップ上に表示されてしまうが、Packerの設定ファイル内に「”headless”: “true”」という設定項目を追加することで、画面を表示せずにインストール作業を実行することも可能になる。これは「headlessインストール」と呼ばれており、リモートのマシンにSSHでログインして作業を行う場合などに便利だ。ただしこの場合エラーが発生した場合に何が起こっているのか判別しにくくなるので、利用前にインストール作業が正しく行えるかをチェックしてから使うことをおすすめする。

QEMU用のディスクイメージを作成する

続いては、QEMU用のディスクイメージファイルを作成してみよう。QEMUはオープンソースの仮想化ソフトウェアだが、KVMやXenと組み合わせて利用する例が多い。たとえばRed Hat Enterprise LinuxやFedora、CentOSなどで採用されている仮想環境管理ツールであるlibvirtではKVMを利用する場合、QEMUと組み合わせて利用するようになっている。Dockerでは、「qemu」builderを利用することでKVMおよびXen用の仮想マシンイメージを作成できる。

qemu builderではvirtualbox-iso builderと同様、インストールCD/DVDのISOイメージから仮想マシンイメージを作成できる。必要な設定項目もvirtualbox-iso builderとほぼ同じなので、virtualbox-iso builderの設定を流用することが可能だ。

必要な設定項目について詳細はqemu buildのドキュメントを参照してほしいが、今回は次のような設定を追加した。これは先のvirtualbox-iso向け設定項目とほぼ同じで、追加/変更したのは太字の部分のみだ。

{
  "builders": [
 
 
    {
      "type": "qemu",
      "iso_checksum": "96de4f38a2f07da51831153549c8bd0c",
      "iso_checksum_type": "md5",
      "iso_url": "http://test01.office.osdn.jp/packer/CentOS-7.0-1406-x86_64-NetInstall.iso",
      "ssh_username": "root",
      "ssh_password": "TakeTheTime",
      "ssh_wait_timeout": "40m",
      "disk_size": "8000",
      "shutdown_command": "/sbin/shutdown -h now",
      "shutdown_timeout": "20s",
      "vm_name": "packer-centos7-qemu",
      "boot_command": [
        "<tab> text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/anaconda-ks-qemu.cfg <enter>"
      ],
      "boot_wait": "10s",
      "http_directory": "./kickstart/",
      ↓仮想化エンジンとしてKVMを使用
      "accelerator": "kvm",
      ↓使用する仮想ネットワークデバイスを指定
      "net_device": "virtio-net",
      ↓使用する仮想ディスクデバイスを指定
      "disk_interface": "virtio",
      ↓使用するQEMUコマンドの実行ファイルを指定
      "qemu_binary": "/usr/local/bin/qemu-system-x86_64",
      ↓QUIを使用しない
      "headless": true,
       ↓QEMUに与える引数を指定
      "qemuargs": [
        [ "-m", "512M"]
      ]
    }
  ],
 
 

kickstart用の設定ファイルについてはvirtualbox-iso builderで使ったもの(anaconda.cfg)とは異なるファイル(anaconda-ks-qemu.cfg)を指定している。具体的には、anaconda.cfg内でディスクデバイス関連の設定項目で指定されている「sda」という値を、すべて「vda」に置き換えている。QEMU+KVMの環境でディスクドライバにvirtioを利用する場合、仮想マシン上のOSからはディスクデバイスが「/dev/sda」ではなく「/dev/vda」として認識されるという違いがあるためだ。

また、今回はCentOS 6.5環境上でテストを行っているが、CentOS 6.5において標準で提供されているQEMUはバージョンが古く、そのままではPackerで利用できなかった。そのため、本記事執筆時点での最新安定版であるQEMU 2.1.0をソースコードからビルドして導入し使用している。

設定ファイルを用意した後に次のようにpacker buildコマンドを実行すると、virtualbox-iso builderを利用した場合と同様に仮想マシンの作成やインストール、プロビジョニングが実行されて仮想マシンイメージが出力される。

$ ~/packer/packer build -only=qemu centos7.json

利用には各仮想化技術に対する一定の知識が必要

さて、2回にわたってPackerについて紹介してきたが、Packerの設定ファイル作成などの際には対象とする仮想化ソフトウェアやコンテナ管理ツール、プロビジョニングツールなどについての知識が必要で、必ずしも「お手軽」なツールではない。ただ、一度設定ファイルを作成できてしまえば、それらを容易に使い回せるため、その後の管理作業については簡単になる。

複数の仮想化ソフトウェアやコンテナ管理ツールを併用している場合や、プロビジョンツールを使っている場合などは活用する価値があるのではないだろうか。

おしらせ

banner_cloud


PuppetとDockerで構成管理してみる

$
0
0

Dockerではコンテナの設定をDockerfileで行ったり、Docker Hubなどに保存された情報からコンテナを作成しますが、ターミナルでサーバに接続して操作しているのでは手間に感じられることでしょう。

そこで試してみたいのがPuppetやChefを使ったDocker操作です。設定を行えば自動的な構成管理に近づくのではないでしょうか。今回はPuppetを使ってDockerを操作してみます。

Puppet自体についてはPuppetを使ったLinuxシステムの設定自動管理を参考にしてください。

PuppetのWebサイト
PuppetのWebサイト

さくらのクラウドでUbuntuサーバを立てる

追加をクリックします
追加をクリックします

まずはPuppetのインストール先になるUbuntuサーバを立てます。もちろんさくらのクラウドを使って行います。アーカイブ選択にてUbuntu Server 14.04 LTS 64bit(基本セット)を選択します。

Ubuntu Server 14.04 LTS 64bit (基本セット)を選択してください
Ubuntu Server 14.04 LTS 64bit (基本セット)を選択してください

後は公開鍵を登録して、サーバを起動します。数分でサーバが立ち上がるはずです。

サーバが立ち上がったらSSHでログインします。公開鍵を登録してあるので、

$ ssh ubuntu@server_ip_address

でログインできます。server_ip_addressは適宜読み替えてください。

Puppetをインストール

まずはPuppetをインストールしましょう。apt-getでインストールできます。

$ sudo apt-get update
$ sudo apt-get install puppet puppetmaster
$ sudo apt-get install docker

インストールが終わったら設定ファイルを保存する場所を作成します。

$ sudo mkdir -p /etc/puppet/manifests

これで準備は完了です。

PuppetのDockerモジュールをインストール

続いてDockerモジュールをインストールします。

$ sudo puppet module install garethr/docker

これでDockerを扱う準備ができました。

設定ファイルを書いてみる

では実際に試してみましょう。 /etc/puppet/manifests/site.pp に以下のような記述をしてみましょう。

$ sudo vi /etc/puppet/manifests/site.pp
node default {
  include 'docker'
  docker::run { 'helloworld':
    image   => 'ubuntu',
    command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
  }
}

これは

$ sudo docker run ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"

を実行したのと同じことになります。

Puppet経由で実行する場合は次のようにコマンドを打ちます。

$ sudo puppet apply /etc/puppet/manifests/site.pp

きちんと立ち上がっていれば、dockerコマンドで確認できます。

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
8f91e086ad82        ubuntu:14.04        "/bin/sh -c 'while t   17 minutes ago      Up 17 minutes                           jolly_ptolemy

なお、初回の起動時は ubuntu のコンテナを取得する時点で終わってしまうようです。2回目の実行から確認できるはずです。

さらに複雑な設定であれば次のように記述できます。

docker::run { 'helloworld':
  image        => 'ubuntu',
  command      => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
  ports        => ['4444', '4555'],
  volumes      => ['/var/lib/couchdb', '/var/log'],
  volumes_from => '6446ea52fbc9',
  memory_limit => 10485760, # bytes
  username     => 'example',
  hostname     => 'example.com',
  env          => ['FOO=BAR', 'FOO2=BAR2'],
  dns          => ['8.8.8.8', '8.8.4.4'],
}

DNS、ユーザ名、マウントするボリューム、ポート、環境変数も渡せるようになっています。より複雑なDockerコンテナの設定もPuppetを使うことでシンプルに運用できるようになりそうですね。

via Using Puppet – Docker Documentation

おしらせ

banner_cloud

第1回 さくナレ勉強会「Docker ハンズオン」レポート

$
0
0

9月3日、西新宿にてDockerハンズオンが開催されました。多数のご応募をいただいた中から抽選で約20名の方向けにDockerを体験していただくという勉強会です。

きっかけ

一番最初のきっかけは当さくらのナレッジで書いたレッツトライ!夏休みに覚えるDockerです。こちらの記事が幸いにしてはてなブックマーク数が300を越え、多数の方に見ていただきました。そのはてブコメントの中で、

はてなブックマークより
はてなブックマークより

というのがあり、それを踏まえて筆者が

と書いたら、さくナレ編集長に見つかり、

Facebookメッセンジャーでの会話
Facebookメッセンジャーでの会話

という流れで決まっていった次第です。はてなブックマーク→Twitter→Facebookで勉強開催の流れなんて実に今風じゃないですか?

なぜハンズオン?

Dockerというキーワード自体は2013年くらいから何度も何度も取り上げられてきてエンジニアであれば一度は耳にしたキーワードだと思うのですが、とは言え実際に自分の手で触った経験というのは多くないんじゃないかというのが私の推測です。またはちょっと触ってみて、それで終わっているという方も押印じゃないかと思います。

勉強会形式でDockerとは何ぞといった説明をする時期は旬を過ぎています。次のステージとしては実際に触れてみる段階でしょう。その中で面白さを知ったり、自分たちの業務にどう活かせるのかを考えていくべき段階にきているのだと思います。

もちろん個人でも、普段使っているWindowsやMac OSXでboot2dockerをインストールして遊んでみることはできますが、それだとなかなか面白さが体感できません。その点、さくらのクラウドを利用すればセットアップもいらず、Docker本来の楽しさ、魅力を感じていただけるんじゃないかと考えた次第です。

当日の流れ

当日の流れを簡単に触れておきます。勉強会開催の参考になれば。

さくらのナレッジ編集長のご挨拶

さくらのナレッジについて
さくらのナレッジについて

最初に今回の企画の趣旨、さくらのナレッジについて説明がありました。

男性9割のメディアとのことで、今回の勉強会もそのくらいの率でした。

Dockerに関する簡単な説明

Dockerや他の仮想化技術との違いを説明
Dockerや他の仮想化技術との違いを説明

Dockerと他の仮想化技術との違いを紹介しました。この辺りは既に語り尽くされている感がありますが、先日VMWare社が新しい仮想化技術を発表したこともあって、まだまだホットで革新の続いている技術だと思います。

ハンズオンの説明

今回のハンズオンでは事前に資料を作成し、それに沿って進めてもらえるようにしてありました。個々人で進み方が違いますので皆がそろってコマンドを打っているよりも理解度が深まると考えました。

ちなみに資料はGitHub上にアップロードしてありますので、CoreOSさえ用意していただければ同じように進めることができます(その際にはぜひさくらのクラウドを使ってください!)。

またWebチャットを用意していましたので、あえて手を上げて質問しづらい場合や、コマンドを確認したい時などはそちらを使ってもらえるようにしていました。

Webチャットの様子
Webチャットの様子

ハンズオン開始

前述の通り、資料に沿って進めてもらうようになっていましたのでハンズオンが開始してしまうと筆者はやることがほぼなくなっていました。そのため、質問や不明点(実際ドキュメントも幾つか不備が見つかっています…)に多く答えられました。

ピザもぐもぐ
ピザもぐもぐ

ハンズオン中は飲み物とピザ、ポテトチップをつまみつつDockerコマンドを打ち込んでいくという流れでした。その中で各テーブルを回りつつ、雑談して邪魔しつつハンズオンが進んでいきます。

もぐもぐ、そしてターーン!
もぐもぐ、そしてターーン!

ステップとしては次のようになっています。

  1. DockerでHello World
  2. WordPressを立ち上げる(1コンテナ版)
  3. WordPressを立ち上げる(リンク版)
  4. Dockerfileを作る

実際に手を動かす時間としては1時間ちょっととなっていましたので、だいたい3ステップ目くらいまでは試してもらえたようです。ステップを踏むごとに皆さんの質問の内容が徐々に高度になっていくのが面白いですね。

皆さん自分のペースで体験中
皆さん自分のペースで体験中

また予めドキュメントを用意したことで、それぞれ自分のペースで思い思いに進められたのが良かったかと思います。作業中においてけぼりになったり、逆に待ち時間が長くなることもありません。最後の方ではDockerfileを編集したり、コミットを使いながら実際にイメージを作っている方もいました。

スムーズにいく時も、または行かない時も…。
スムーズにいく時も、または行かない時も…。

最後に記念写真

今回は第一回ということもあり、記念にみなさんで写真を撮りました。実はさくらのクラウドのチケットは裏に桜葉愛ちゃんの目が描かれています。それを目元にかざせば誰でも愛ちゃん!な訳です。ということでパシャリ。

これはヒドい!(褒め言葉
これはヒドい!(褒め言葉

皆さんの感想など

最後に皆さんからいただいた感想を紹介したいと思います。全体の感想としては、

  • 10票:良かった
  • 7票:とても良かった
  • 1票:まぁまぁ

となっており、好評だったのかなと。なお内容については、

  • 13票:優しかった
  • 5票:難しかった

とのことで、この辺りのバランスはなかなか難しいですが最初の一歩としては優しかったと思えるくらいのが良かったのかと思っています。

では以下感想のサマリーです。

  • 実際に自分で操作しながら学べるのは純粋に楽しめた反面、目の前の操作に集中してしまって周囲やチャットでのコミュニケーションを取る余裕がなくなってしまった。
  • 説明も完結で分かりやすくドキュメントも整備されており、また合間の質問にもすぐに答えていただけてハンズオンもスムーズに進みました。
  • Dockerに対してもう少し勉強したいと思います。
  • ハンズオンというよりも、もくもく会みたいな感じではありましたが、楽しかったです。
  • GitHubに手順書があるのは良かったのですが、コマンドオプションなど一部分からないものがあったので、そのあたりの解説があるとなお良かった。
  • 何気に初めてさくらのクラウドを触りました。どういう感じか知ることが出来たのはすごく良かったです。
  • はじめて触るのですがすごく素直に動かすことができました!!
  • 適度な内容で楽しかったです。
  • チャットでも対面でも質問しやすい空気でとてもやりやすかったです。
  • 資料はいいんだけど、どこがターミナルで作業していて、どこがdocker内かわかりにくいので、色分けとかされていると読みやすいかも。
  • 技術的な面で言うとCoreOSを使用しているのでクラスタリングなど冗長構成(etcdとかとか)の話等もしてほしかった感じがあります。

などなど。ポジティブな感想をたくさんいただけました。

反省点、改善点

もちろん第一回ということもあって、すべてが成功裏に終わった訳ではありません。ここからは反省点であり、次回以降の改善点になります。

お箸必須

手が汚れてしまうこともあってポテトチップスが残りがちに…(美味しいですけどね)
手が汚れてしまうこともあってポテトチップスが残りがちに…(美味しいですけどね)

今回、ピザとポテトチップスだったのですが手が汚れる系と言うこともあってウェットティッシュを用意していました。しかし普段の開発現場を考えるとお箸を用意しておけば良かったです。

ネットワーク

今回利用した無線LANネットワークが15名を越えた辺りから突然重たくなってしまいました。半数近くの方が、個人持ち込みのポータブルルータまたはテザリングをしていたようです。これは要改善ポイントですね。

ドキュメントの不備

一応確認はしていたのですがドキュメントに不備が幾つかありました。コンソールで実行する系統の場合、結果が確認しづらいこともあるので(固まったのか、処理中なのかなど)きちんと確認しないといけないですね。

さーて次回の勉強会は?

今回は第一回!と銘打っている訳で次回に期待がかかるところなのですが、まだ全くの未定となっています。アンケートの結果からは、

  • Docker
  • OpenStack
  • Zabbix
  • Vagrant
  • Chef
  • Fig
  • Kubernetes
  • Serf
  • Fluentd

などが最近の気になる技術キーワードに上がっています。この辺りを取り上げてまたハンズオン形式で体験できると面白いのかなと思ったりしています。

前述の通り、当ブログにてヒットした記事から勉強会のテーマを決めていく流れになっています。なのでぜひ当ブログをお読みいただき、興味深い記事だと思ったらソーシャルでシェアしていただければ次回の勉強会につながるかも知れません。後はこのレポート記事をはてブしていただき、その中に取り上げて欲しいキーワードをコメントしてもらっても次回につながると思います。

なおハンズオンレポをあげていただいた方もいらっしゃいますので、ぜひ生の声をご覧ください!

さくナレ勉強会レポート ~Dockerハンズオン~ – Qiita

今回ご参加いただきました皆さん、ありがとうございました!

おしらせ

banner_writer

boot2dockerを使わない。「Remote API」でローカルからクラウドのDockerを実行

$
0
0

Dockerはコンテナ型の仮想化技術なので、実行できる環境がLinuxに限定されるのが難点です。一般的にはCoreOS、CentOS、Ubuntu上でDockerを動かすのですが、普段使っているWindowsやMac OSXでも使いたいと考える人はとても多いです。

そこで使われているのがboot2dockerなのですが、これはVirtualBox上にTiny Core Linuxを用意して、その上でDockerを動かすという仮想化のために仮想環境を用意するという、強引な解決手段となっています。軽量な仮想環境なはずなのに、VirtualBoxの立ち上げに時間がかかるのは勿体ないですよね。

そこで使ってみたいのがDockerのRemote APIを使って外部にあるDockerサーバを操作するという方法です。今回はその設定方法を紹介します。

必要なもの

クライアントマシン

今回はMac OSXを使っています。予めdockerコマンドを用意しておきます。Homebrewを使っている場合は、

$ brew install docker 

でインストールできます。

さくらのクラウドのアカウント


アカウントはさくらのクラウドトップページからできます。

クラウドサーバを追加する


管理画面に入りましたら、サーバの追加を選択します。追加画面では、サーバの名前、メモリ数、ディスクプランなどを決めていきます。大事なのはアーカイブ選択の中にある CoreOS 379.3.0 (alpha) を選択することです(バージョン番号は2014年08月現在です)。これだけで必要なものが揃います。


後はパスワードや公開鍵の入力などを行ってください。この状態で起動してみます。

サーバに接続する

Webベースのコンソールもありますが、今回はターミナルからつないでみます。公開鍵認証が優先なので、先ほど設定していれば、

$ ssh core@server_ip_address

で接続できます(server_ip_addressは各自読み替えてください)。IPアドレスはサーバ一覧のインタフェースで確認してもらえます。


Dockerのバージョンを確認する

ここが大事なのですが、クライアント(Mac OSXやWindows)とサーバ(CoreOS)でDocker APIのバージョンを合わせておく必要があります。

$ docker version
Client version: 1.1.1
Client API version: 1.13
Go version (client): go1.2
Git commit (client): dc62f3c
Server version: 1.1.1
Server API version: 1.13
Go version (server): go1.2
Git commit (server): dc62f3c

CoreOS 367.1.0 (stable) ではDocker APIが1.12のため、今回はCoreOS 379.3.0 (alpha)を使っています。逆にクライアント側のdockerのバージョンを下げる方法もあります。CoreOSではパッケージ管理のような機能はなく、全体を入れ替える方法をとっているため、Dockerだけのバージョンをあげるのは大変そうです。

リモート接続を有効にする

CoreOSにログインしたら、設定ファイルを作成します。

# vi /etc/systemd/system/docker-tcp.socket

内容は次の通りです。

[Unit]
Description=Docker Socket for the API

[Socket]
ListenStream=2375
BindIPv6Only=both
Service=docker.service

[Install]
WantedBy=sockets.target

入力したらファイルを閉じ、Dockerを再起動します。

# systemctl enable docker-tcp.socket
# systemctl stop docker
# systemctl start docker-tcp.socket
# systemctl start docker

これで準備は完了です。うまく設定できている場合は、次のコマンドでレスポンスが返ってきます(CoreOS上で実行しています)。

$ docker -H tcp://127.0.0.1:2375 ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

クライアント側の設定

クライアントでの設定はとても簡単です。DockerのURLを環境変数に設定するだけです。

$ export DOCKER_HOST=tcp://server_ip_address:2375

server_ip_addressは各自読み替えてください。これで準備は完了です。

実行してみる

では早速実行してみましょう。実行はクライアント側から行います。

$ docker run ubuntu echo 'Hello World'
Unable to find image 'ubuntu' locally
Pulling repository ubuntu
c4ff7513909d: Download complete 
511136ea3c5a: Download complete 
1c9383292a8f: Download complete 
9942dd43ff21: Download complete 
d92c3c92fa73: Download complete 
0ea0d582fd90: Download complete 
cc58e55aa5a5: Download complete 
Hello World

こんな感じにレスポンスがあるはずです。CoreOS側を見てみます。

$ docker ps -a 
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS                     PORTS               NAMES
4b2a03b2df71        ubuntu:latest       echo 'Hello World'   9 seconds ago       Exited (0) 9 seconds ago                       prickly_ritchie     

ちゃんと実行されていることが分かります。


この方法を使えば、さくらのクラウドにSSHなどでログインすることなく、手元のターミナルからDockerが使えます。VMを使っていないのでCPUを浪費したり、ノートPCのバッテリーを心配することもありません(VMを使っているとどんどん減っていくんですよね)。さらにクラウドはネットワークも速いので、Dockerコンテナイメージのダウンロードが高速に行われます。

ぜひお試しください!

via Customizing docker

おしらせ

banner_cloud

DockerでUbuntuデスクトップを使おう

$
0
0

Linuxをサーバ用途ではなく、デスクトップで使いたいと思っている人は少なからずいます。しかし仕事や家庭でもどうしても必要なソフトウェアがあって、まるっと乗り換えるのが難しいというのも事実です。とは言え仮想マシンを使って用意してもなかなか使わないかも知れません。

そこでDockerを使ってみるのはいかがでしょう。docker-ubuntu-vnc-desktopを使うと、あっという間にUbuntuのデスクトップ環境が手に入ります。

CoreOSを用意する

まずはさくらのクラウドを使ってサーバを準備します。OSはCoreOSになります。サーバの追加を行う際にアーカイブ選択で CoreOS 367.1.0 (stable) #112600559854 を選択します。

サーバ追加画面。アーカイブからCoreOSを選びます。
サーバ追加画面。アーカイブからCoreOSを選びます。

CoreOSに接続

サーバが立ち上がったら ssh で接続します。

$ ssh core@server_ip_address

server_ip_address はサーバのIPに読み替えてください。

Dockerコマンドを実行

まずはpullでコンテナイメージを取得します。

$ docker pull dorowu/ubuntu-desktop-lxde-vnc

終わったら起動します。6080番ポートをそのままホストに渡しています。

$ docker run -i -t -p 6080:6080 dorowu/ubuntu-desktop-lxde-vnc
User: ubuntu Pass: ubuntu

パスワードは覚えておきましょう。実行完了したら、

http://server_ip_address:6080/vnc.html

にアクセスできるようになります。

最初にログイン画面。前述のパスワードを入力します。
最初にログイン画面。前述のパスワードを入力します。

ログインするとメニューが出ます。この辺りはもう普通に操作可能です。レスポンスは多少ゆっくりですが、操作できないというほどではありません。

メニュー。LibreOfficeが入っています。
メニュー。LibreOfficeが入っています。

日本語入力はできませんが、表計算で簡単な計算式程度は入力できます。

LibreOfficeを使っているところ。
LibreOfficeを使っているところ。

日本語フォントが入っていないため文字化けしてしまっています。ちなみにFirefoxではなぜか文字入力自体できませんでした。

Firefoxでブラウジングしているところ。
Firefoxでブラウジングしているところ。

使っているのはnoVNCで、Web SocketsとCanvasを使っているWebベースのVNCクライアントになります。HTML5なのでデスクトップに限らず、iOSやAndroidからも操作できるのが魅力になります。

サーバ用途以外でもDockerが便利ですね。

fcwu/docker-ubuntu-vnc-desktop

おしらせ

banner_cloud

複数のDockerサーバで独自ネットワークを構築する「Weave」を試す!

$
0
0

Dockerはコンテナ型の仮想化ソフトウェアで、一台のサーバの中にコンテナを複数立ち上げることができます。そのためDockerサーバ1台で何でもこなせそうに思いますが、やはり大きなシステムになると複数のサーバ内で動作するDockerコンテナ同士を連携させたいと思うのではないでしょうか。

そうなると問題になりそうなのがネットワークです。リンクを使う方法もありますが、より大きなネットワーク構造を作り上げるのにはWeaveが使えそうです。WeaveはDockerコンテナ向けの仮想化ネットワークソフトウェアになります。

用意するもの

Dockerが動けば良いのですが、他にも幾つか必要なのでCoreOSは向かなそうです。今回は Ubuntu Server 14.04 LTS 64bit を使っています。さくらのクラウドでサーバを立ち上げる際に、アーカイブとして Ubuntu Server 14.04 LTS 64bit を選択します。今回はそのサーバを2台用意しました。

Ubuntu 14.04 LTSを2台用意しています
Ubuntu 14.04 LTSを2台用意しています

サーバに接続、Dockerのインストール

まずはサーバに接続します。

$ ssh ubuntu@server_ip_address

server_ip_address は立ち上がったサーバのものに読み替えてください。接続したらDockerをインストールします。

$ sudo apt-get update
$ apt-get install docker.io

これで準備は完了です。

Weaveのインストール

weaveのインストールはとても簡単で、次のコマンドを打つだけです。

$ sudo wget -O /usr/local/bin/weave \
  https://raw.githubusercontent.com/zettio/weave/master/weaver/weave
$ sudo chmod a+x /usr/local/bin/weave

これで完了です。

1台目のサーバで実行

まず1台目のサーバ(サーバ1とします)でWeaveを立ち上げます。root権限で行ってください。

# weave launch 10.0.0.1/16

完了したら、DockerでUbuntuを立ち上げます。

# C=$(weave run 10.0.1.1/24 -t -i ubuntu)

これで $C の中にコンテナIDが入ります。

2台目のサーバで実行

次に2台目のサーバ(サーバ2とします)です。こちらはサーバ1のWeaveに接続する指定を行います。

# weave launch 10.0.0.2/16 server1_ip_address

server1_ip_address はサーバ1のIPアドレスになります。終わったらサーバ1と同じようにDockerコンテナを立ち上げます。

# C=$(weave run 10.0.1.2/24 -t -i ubuntu)

サーバ1からサーバ2へpingを打つ

ではサーバ1のDockerコンテナからサーバ2のDockerコンテナへの疎通確認を行います。

# docker attach $C

root@97a26833e25f:/# ping -c 1 -q 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.

--- 10.0.1.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.272/16.272/16.272/0.000 ms

ちゃんとpingが飛んで、疎通確認ができています。コンテナを抜ける場合は Ctrl + P / Ctrl + Q で行ってください。この逆にサーバ2からサーバ1への疎通も可能です。

# docker attach $C
root@fc91dc9c2cab:/# 
root@fc91dc9c2cab:/# ping -c 1 -q 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.

--- 10.0.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 14.521/14.521/14.521/0.000 ms

仮想ネットワークが構築されて、サーバ1とサーバ2のコンテナ同士がつながっているのが分かります。

アプリケーションの隔離

では次にアドレスを分けてみます。

# D=$(weave run 10.0.2.1/24 -t -i ubuntu) # サーバ1
# D=$(weave run 10.0.2.2/24 -t -i ubuntu) # サーバ2

このように10.0.1.xと10.0.2.xで分離します。この場合はもちろんパケットは通りません。

# docker attach $D
root@1b001316fcf8:/# 
root@1b001316fcf8:/# ping -c 1 -q 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.

--- 10.0.2.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.244/1.244/1.244/0.000 ms
root@1b001316fcf8:/# ping -c 1 -q 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.

--- 10.0.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

サーバ1から実行した場合、10.0.2.2へのpingは通っていますが、10.0.1.1へのpingは100%ロスしています。当たり前ですが仮想ネットワークでもきちんと動いています。

ホストネットワークからのアクセス

デフォルトのままですと、ホストであってもコンテナのネットワークとはつながることはできません。

# ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.

--- 10.0.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

ですが、exposeオプションによって解放ができます。

# weave expose 10.0.1.102/24
# ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=0.068 ms
64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=0.050 ms

これはもちろんサーバ内だけでなく、同じ仮想ネットワークにつながっている他のコンテナでも接続できます。

# ping 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=2.05 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=0.798 ms

これまではコンテナのポート単位で解放する方法しかなかったのですが、Weaveを使うとほぼサーバと同じように見えてしまいます。複数台サーバの中で多数のコンテナを立ち上げて、それらを必要に応じて仮想ネットワークで組み上げる、そんな大型なDocker活用が考えられそうな面白いソフトウェアですね。

zettio/weave

おしらせ

banner_cloud

Viewing all 433 articles
Browse latest View live