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

これから始める「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

Dockerを使って軽くConsulを触ってみる

$
0
0

サーバ界隈の技術革新が激しい今日この頃ですが、名前は知っていつつもなかなか触る機会がないなんて状態ではないでしょうか。特に複数台のサーバを予め用意しなければならないソフトウェアは準備だけでも大変で、なかなか手出ししづらいかと思います。

そこで使ってみたいのがDockerです。Dockerを使うことで1台のサーバでも仮想的に複数台サーバ構成を試すことができます。今回は最近登場したConsulをDocker上で簡単に試してみたいと思います。あくまでも触れる程度なので、本格的な運用とは別でお考えください。

サーバを立てる

さくらのクラウドを使ってサーバを準備します。OSはCoreOSになります。サーバの追加を行う際にアーカイブ選択で CoreOS 367.1.0 (stable) #112600559854 を選択します。

サーバ追加画面。アーカイブからCoreOSを選びます。
サーバ追加画面。アーカイブからCoreOSを選びます。

CoreOSに接続

サーバが立ち上がったら ssh で接続します。

$ ssh core@server_ip_address

server_ip_address はサーバのIPに読み替えてください。

Consulを用意する

サーバに接続したらConsulを用意します。

$ docker pull progrium/consul

少し時間がかかりますが、終わったらまず1つ目のノードを立ち上げます。

$ docker run -d --name node1 -h node1 progrium/consul -server -bootstrap-expect 3

2台目のノードからは、この1台目のノードに接続する形になりますので、IPアドレスを取得します。

$ JOIN_IP="$(docker inspect -f '{{ .NetworkSettings.IPAddress }}' node1)"

これで $JOIN_IP にIPアドレスが入ります。では続けてノードを立ち上げます。

$ docker run -d --name node2 -h node2 progrium/consul -server -join $JOIN_IP
$ docker run -d --name node3 -h node3 progrium/consul -server -join $JOIN_IP

これでサーバ同士はつながったのですが、外部からその状態を見ることはできません。ということで4台目はサーバではなくクライアントとして立ち上げます。

$ docker run -d -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node4 progrium/consul -join $JOIN_IP

これで8400、8500番ポートを使ってConsulの状態を見られるようになりました。例えばcurlで次のように入力します。

$ curl localhost:8500/v1/catalog/nodes
[{"Node":"node4","Address":"172.17.0.9"},{"Node":"node1","Address":"172.17.0.5"},{"Node":"node2","Address":"172.17.0.6"},{"Node":"node3","Address":"172.17.0.7"}]

ノードがつながっているのが分かります。

Consulクライアントを使う

今回はDockerなのでConsulコマンドがインストールできません。ということで Mac OSX側から使ってみることにします。使うのはHomebrewです。

$ brew install caskroom/cask/brew-cask
$ brew cask install consul
$ consul members  -rpc-addr=server_ip_address:8400
Node    Address          Status  Type    Build  Protocol
node4   172.17.0.9:8301  alive   client  0.4.0  2
node3   172.17.0.7:8301  alive   server  0.4.0  2
node1   172.17.0.5:8301  alive   server  0.4.0  2
node2   172.17.0.6:8301  alive   server  0.4.0  2

このように外部からもノードの状態が見られるようになっています。

データを送ってみる

ConsulはシンプルなKVSでもあるので、

$ curl -XPUT -d 'hello, world!' http://server_ip_address:8500/v1/kv/hello/key

のようにしてデータを登録し、

$ curl -s http://server_ip_address:8500/v1/kv/hello/key | jq . 
  {
    "CreateIndex": 26,
    "ModifyIndex": 26,
    "LockIndex": 0,
    "Key": "hello/key",
    "Flags": 0,
    "Value": "aGVsbG8sIHdvcmxkIQ=="
  }
]

としてデータの取得ができるようになっています。


Consulの主な利用法としてはサービスの登録と、そのヘルスチェックにあると思いますのでこのまま使うという訳ではないと思いますが、Consulがどういった感じなのか触ってみるのであれば、こんな感じに簡単に体験できるようになっています。

Dockerの使い方として面白いですね。

progrium/docker-consul

おしらせ

banner_cloud

Mac OSX × Dockerな環境が手軽に管理できる「Panamax」レビュー

$
0
0

DockerはLinuxコンテナを扱う仕組みなので、カーネルがLinuxでないといけません。そのためMac OSXやWindowsでDockerを利用する場合、boo2dockerというソフトウェアを使って、VirtualBox上に立ち上がったCoreOSの上でDockerを扱うのが一般的です。

また、Dockerを扱うためにはターミナル上で操作する必要があり、エンジニアであればまだしもデザイナーの方などにとっては何となく使い勝手悪く感じてしまっていたことも確かでしょう。

そこで使ってみたいのがPanamaxというWebベースのDocker管理ソフトウェアです。2014年8月現在ではベータであり、Mac OSXとUbuntuのみサポートという状態ですが、今後に期待できそうなソフトウェアとなっています。

必要なもの

VirtualBox

4.2以上となっています。VirtualBox公式サイトよりダウンロード、インストールしてください。

Vagrant

1.6以上となっています。こちらもVagrant公式サイトよりダウンロード、インストールしてください。

Panamaxのインストール

Panamaxのインストールは簡単で、ターミナルから

$ brew install http://download.panamax.io/installer/brew/panamax.rb && panamax init // Mac OSXの場合
$ curl http://download.panamax.io/installer/ubuntu.sh | bash // Ubuntuの場合

となっています。インストールが終わると自動的に http://localhost:8080/ が開きます。

Panamaxのインストール中
Panamaxのインストール中

なおUbuntuへのインストールの場合でもVirtualBoxのインストールが必須になります。またVagrantはaptで入るものはバージョンが低いため、debをダウンロードする必要があります。そういった手間を考えると、Panamaxを使わずに直接Dockerをインストールする方が手軽と言えます。

Panamaxレビュー

Panamaxのメイン画面
Panamaxのメイン画面

PanamaxではDockerのリポジトリを検索できるようになっています。今回は予め用意されているWordPressをインストールしてみます。上記のアイコンが並んでいるWordPressをクリックします。

検索結果画面
検索結果画面

そうするとDockerイメージが一覧されますので、使いたいイメージを選択します。

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

Run TemplateまたはRun Imageを選ぶとビルドが開始します。なお、ベータ版ということもあってか、うまく立ち上がりきらないこともありました。その場合はPanamaxを再起動して再度実行するとうまくいきました。

$ panamax restart
Web側のコンテナ詳細
Web側のコンテナ詳細

コンテナ詳細を見ると分かりますが、DB_1というサービスがリンクしています。DB_1はその名の通りデータベースのコンテナです。また、そのデータベースにつなぐためのパスワードを環境設定にしていたり、ポートの設定ができたりとコンテナの設定をWeb上から自由に変更できるようになっています。

サービスのログ
サービスのログ

ログはリアルタイムに表示されていきます。ただし複数のコンテナを立ち上げている場合、全て一つの画面に出てしまうので判別しづらいかも知れません。

WordPressを使う上での設定
WordPressを使う上での設定

コンテナによってはこのように設定が書かれています。この場合はポートフォワードに関する指定が書かれていますので、別途ホストOS側のコンソールで実行する必要があります。

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

無事コンテナが立ち上がればWebブラウザからアクセスしてWordPressのインストールができます。基本的な操作はすべてWebブラウザ上で行えるので簡単ですね。


最後にPanamaxのコマンドです。

 init:          First time installing Panamax! - Downloads CoreOS VM and installs latest Panamax version. 
 pause:         Stops Panamax 
 up:            Starts Panamax 
 restart:       Stops and Starts Panamax. 
 reinstall:     Deletes your applications and CoreOS VM; reinstalls to latest Panamax version. 
 info:          Displays version of your local panamax install. 
 check:         Checks for available updates for Panamax. 
 download:      Updates to latest Panamax version. 
 delete:        Uninstalls Panamax, deletes applications and CoreOS VM. 
 ssh:           Ssh into Panamax CoreOS VM. 
 help:          Show this help

VirtualBoxやVagrantを予め用意しておく必要はありますが、Webブラウザ上からコンテナイメージを探してインストールするといった一通りの操作ができるのはエンジニア以外の方にとっては便利ではないでしょうか。社内で立てておいて、みんなが自由にコンテナを立ち上げられる環境としても面白そうです。

Webブラウザからの操作だけでは満足できない場合は、SSHを使って直接CoreOSやDockerを操作することもできます。Mac OSXではboot2dockerを使うのが一般的ですが、もう一つの選択肢としてPanamaxもありですね。

Panamax: Docker Management for Humans


Dockerを使ったミニPaaSのdokkuをパワーアップさせた「Dokku Alternative」を試す

$
0
0

自分でHerokuライクなシステムを立ち上げられるdokkuというソフトウェアがありますが、そこにさらに機能追加することで実用性を増したDokku Alternativeを試してみました。

Dokku Alternativeの主な特徴としては、

  • Git対応
  • データベース対応
  • Dockerfile/Procfile対応
  • Web画面なしのアプリが作成可能
  • サブドメインおよびポート指定のアプリ作成
  • TLSおよびワイルドカード証明書対応
  • 永続的ボリューム作成
  • ダウンタイムゼロデプロイ
  • 動作中コンテナへの接続
  • Basic認証サポート
  • SPDY/HSTS対応

などとなっています。Herokuほどクライアントから全て操作できるという訳ではありませんが、自分でサーバを立てていますのでサーバにつなぎつつちょっとした操作を行っていくだけで十分なWebアプリケーション動作環境(PaaS)を作り上げられるようになっています。

では早速試していきます。

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

Dokku Alternativeは現時点ではUbuntuにのみ対応しています。ということでアーカイブ選択時にUbuntu Server 14.04 LTS 64bitを選択してサーバを立ち上げます。

アーカイブ選択時にUbuntu Server 14.04 LTS 64bitを選択します。
アーカイブ選択時にUbuntu Server 14.04 LTS 64bitを選択します。

サーバが立ち上がったら、

$ ssh ubuntu@server_ip_address

にて接続します(server_ip_addressは読み替えてください)。

Dokku Alternativeのインストール

サーバに接続したら以下のコマンドでDokku Alternativeをインストールします。Dokku AlternativeはGitコマンドでサーバにつなぐので、Shellshock対策を忘れず行っておきましょう。といってもapt-getでupgradeするだけです。

$ sudo apt-get update
$ sudo apt-get -y upgrade
$ sudo bash -c "$(curl -fsSL https://raw.githubusercontent.com/dokku-alt/dokku-alt/master/bootstrap.sh)"
  :
cat: /root/.ssh/authorized_keys: No such file or directory
[2014-09-30 15:19:26] INFO  WEBrick 1.3.1
[2014-09-30 15:19:26] INFO  ruby 1.9.3 (2013-11-22) [x86_64-linux]
== Sinatra/1.4.3 has taken the stage on 2000 for production with backup from WEBrick
[2014-09-30 15:19:26] INFO  WEBrick::HTTPServer#start: pid=7419 port=2000

Dokku Alternativeのインストールが終わると、そのままセットアップサーバが立ち上がります。ちなみに今回は openservice.jp というドメインを割り当てたという想定になっています。

Dokku Alternativeのセットアップ画面です。
Dokku Alternativeのセットアップ画面です。
VirtualHostに対応させます。
VirtualHostに対応させます。

これで Finish Setup ボタンを押すと、セットアップ処理が実行されて、その後GitHubにあるサンプルアプリケーションの立ち上げ説明画面になります。

GitHubにあるサンプルアプリケーションの説明。
GitHubにあるサンプルアプリケーションの説明。

基本的にはこの流れのままに実行すればOKです。ドメイン名は読み替えてください。これはクライアントのデスクトップ側からの実行です。

$ git clone https://github.com/heroku/node-js-sample
$ cd node-js-sample
$ git remote add dokku dokku@openservice.jp:dev
$ git push dokku master
Counting objects: 378, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (304/304), done.
Writing objects: 100% (378/378), 209.95 KiB | 0 bytes/s, done.
Total 378 (delta 45), reused 378 (delta 45)
remote: Cloning into '/tmp/tmp.DafPiIAfix'...
remote: warning: You appear to have cloned an empty repository.
  :
remote:        
remote: =====> Application deployed:
remote:        http://dev.openservice.jp
remote: -----> Cleaning up ...
To dokku@openservice.jp:dev
 * [new branch]      master -> master
ちゃんとサーバが立ち上がりました。
ちゃんとサーバが立ち上がりました。

初回はDockerでコンテナイメージをダウンロードしてきますので若干時間がかかります。2回目以降はすぐにデプロイが終わります。 openservice.jp:dev で dev と指定されている部分がアプリケーション名で、サブドメインとして使われます。

Herokuと違って予めアプリケーションを作成しておく必要はありません。初回のプッシュのタイミングで自動的に作成されます。

アプリに接続する

Dokku Alternativeが立ち上がっているサーバではアプリに接続してコマンドが実行できます。例えばこんな感じです。

$ dokku run dev ls -alh
total 56K
drwxr-xr-x  8 root root 4.0K Sep 30 06:24 .
drwxr-xr-x 89 root root 4.0K Sep 30 06:33 ..
-rw-r--r--  1 root root    0 Sep 30 06:24 .env
-rw-r--r--  1 root root   13 Sep 30 06:24 .gitignore
drwxr-xr-x  2 root root 4.0K Sep 30 06:24 .heroku
drwxr-xr-x  2 root root 4.0K Sep 30 06:24 .profile.d
-rw-r--r--  1 root root   37 Sep 30 06:24 .release
-rw-r--r--  1 root root   15 Sep 30 06:24 Procfile
-rw-r--r--  1 root root 1.3K Sep 30 06:24 README.md
-rw-r--r--  1 root root  254 Sep 30 06:24 app.json
-rw-r--r--  1 root root  339 Sep 30 06:24 index.js
drwxr-xr-x  3 root root 4.0K Sep 30 06:24 node_modules
-rw-r--r--  1 root root  575 Sep 30 06:24 package.json
drwxr-xr-x  2 root root 4.0K Sep 30 06:24 public
drwxr-xr-x  3 root root 4.0K Sep 30 06:24 vendor

devというのがアプリケーション名です。これはコマンドを実行して完了ですが、以下のようにすれば普通にシェルが使えます。/bin/bash なども使えます。

$ dokku run dev /bin/sh
# ls
Procfile  README.md  app.json  index.js  node_modules  package.json  public  vendor

データベースをつなぐ

Dokku Alternativeは以下の4つのデータベースが利用できます。

  • MariaDB(MySQL)
  • PostgreSQL
  • MongoDB
  • Redis

例えばMariaDBの場合、以下のように操作します。

$ dokku mariadb:create test-db
-----> MariaDB database created: test-db
$ dokku mariadb:link dev test-db
-----> Releasing dev ...
  :       
=====> Application deployed:

http://dev.openservice.jp

適当な名前でデータベースを作成し、既存のアプリとリンクさせます。そうすると一旦アプリは立ち上げ直しになります。リンクした後、configコマンドでデータベースの接続情報が確認できます。

$ dokku config dev
=== dev config vars ===
DATABASE_URL: mysql2://dev:dAHqRdqvahzONP8G@mariadb:3306/test-db

この情報を使ってデータベースに接続を行うという仕組みになります。

データの永続化

アプリを立ち上げ直すとローカルのデータは消えてしまいます。それを防ぐためにボリュームを設定します。

$ dokku volume:create shared-test-volume /app/logs /app/tmp /app/uploads
-----> Volume created: volume_data_shared-test-volume
$ dokku volume:link dev shared-test-volume
-----> Volume shared-test-volume linked to an aplication: dev
  :
=====> Application deployed:

http://dev.openservice.jp

この場合も一旦アプリがデプロイし直しになります。作成したボリュームは /home/dokku/.volumes 以下に作成されます。Herokuではアップロードしたファイルなどを保存できませんが、Dokku Alternativeでは手軽に保存できるようです。

Basic認証

作成したアプリに簡単にBasic認証をかけられます。

$ dokku htpasswd:add dev myuser
New password: 
Re-type new password: 
Adding password for user myuser

devはアプリ名です。これだけでBasic認証を追加できますので手軽ですね。

Basic認証の例。
Basic認証の例。

その他のオプション

Dokku Alternativeには他にも色々な機能があります。コマンドオプションは次の通りです。

$ dokku help
    access:add                                      Add admin user
    access:info <fingeprint>                        Show information about the key
    access:list                                     List all SSH keys: admins and deployments
    access:remove <fingerprint>                     Revoke all permissions for specific SSH key
    apps:disable <app>                              Disable specific app
    apps:enable <app>                               Re-enable specific app
    apps:list                                       List app
    apps:restart <app>                              Restart specific app (not-redeploy)
    apps:start <app>                                Stop specific app
    apps:status <app>                               Status of specific app
    apps:stop <app>                                 Stop specific app
    apps:top <app> [args...]                        Show running processes
    backup:export [file]                            Export dokku configuration files
    backup:import [file]                            Import dokku configuration files
    config <app>                                    display the config vars for an app
    config:get <app> KEY                            display a config value for an app
    config:set <app> KEY1=VALUE1 [KEY2=VALUE2 ...]  set one or more config vars
    config:unset <app> KEY1 [KEY2 ...]              unset one or more config vars
    create <app>                                    Create shallow app
    delete <app>                                    Delete an application
    deploy:allow <app>                              Allow push-access (aka. deployment) to an app
    deploy:list <app>                               List all push-acccesses for an application
    deploy:revoke <app> <fingerprint>               Revoke push-access for an application
    domains:get <app>                               Get domains for an app
    domains:redirect:get <app>                      Get redirect domains for an app
    domains:redirect:set <app> <domains...>         Set redirect app domains
    domains:set <app> <domains...>                  Set app domains
    enter <app>                                     Enter into currently running container
    exec <app> <cmd>                                Execute command in currently running container
    help                                            Print the list of commands
    htpasswd:add <app> <user>                       Add http-basic auth user
    htpasswd:disable <app>                          Remove http-basic Auth
    htpasswd:remove <app> <user>                    Remove user
    logs <app> [-t] [-f]                            Show the last logs for an application (-t or -f follows)
    mariadb:console <app> <db>                      Launch console for MariaDB container
    mariadb:create <db>                             Create a MariaDB database
    mariadb:delete <db>                             Delete specified MariaDB database
    mariadb:dump <app> <db>                         Dump database for an app
    mariadb:info <app> <db>                         Display application informations
    mariadb:link <app> <db>                         Link database to app
    mariadb:list <app>                              List linked databases
    mariadb:unlink <app> <db>                       Unlink database from app
    mongodb:console <app> <db>                      Launch console for MongoDB container
    mongodb:create <db>                             Create a MongoDB database
    mongodb:delete <db>                             Delete specified MongoDB database
    mongodb:dump <app> <db> <collection>            Dump database collection in bson for an app
    mongodb:export <app> <db> <collection>          Export database collection for an app
    mongodb:import <app> <db> <collection>          Import database collection for an app
    mongodb:info <app> <db>                         Display application informations
    mongodb:link <app> <db>                         Link database to app
    mongodb:list <app>                              List linked databases
    mongodb:unlink <app> <db>                       Unlink database from app
    plugins-install                                 Install active plugins
    plugins                                         Print active plugins
    postgresql:console <app> <db>                   Launch console for PostgreSQL container
    postgresql:create <db>                          Create a PostgreSQL database
    postgresql:delete <db>                          Delete specified PostgreSQL database
    postgresql:dump <app> <db>                      Dump database for an app
    postgresql:info <app> <db>                      Display application informations
    postgresql:link <app> <db>                      Link database to app
    postgresql:list <app>                           List linked databases
    postgresql:unlink <app> <db>                    Unlink database from app
    preboot:cooldown:time <app> <secs>              Re-enable specific app
    preboot:disable <app>                           Stop specific app
    preboot:enable <app>                            Stop specific app
    preboot:status <app>                            Status of specific app
    preboot:wait:time <app> <secs>                  Restart specific app (not-redeploy)
    rebuild:all                                     Rebuild all apps
    rebuild <app>                                   Rebuild an app
    redis:create <app>                              Create a Redis database
    redis:delete <app>                              Delete specified Redis database
    redis:info <app>                                Display application information
    run <app> <cmd>                                 Run a command in the environment of an application
    ssl:certificate <app>                           Pipe signed certifcate with all intermediates for an APP
    ssl:forget <app>                                Wipes certificate for an APP
    ssl:generate <app>                              Generate certificate signing request for an APP
    ssl:info <app>                                  Show info about certifcate and certificate request
    ssl:key <app>                                   Pipe private key for an APP
    tag:add <app> <tag>                             Tag latest running image using specified name
    tag:list <app>                                  List all image tags
    tag:rm <app> <tag>                              Tag latest running image using specified name
    url <app>                                       Show the URL for an application
    version                                         Print dokku's version
    volume:create <name> <paths...>                 Create a data volume for specified paths
    volume:delete <name>                            Delete a data volume
    volume:info <name>                              Display volume information
    volume:link <app> <name>                        Link volume to app
    volume:list:apps <name>                         Display apps linked to volume
    volume:list                                     List volumes
    volume:unlink <app> <name>                      Unlink volume from app

Herokuのようにクライアントサイドから全ての操作ができるという訳でもありませんし、Webベースの管理画面が整っているという訳でもありません。しかしサーバサイドの自由度が高いので自分で管理しているサーバの状態を把握しながら使っていけるというのは面白そうです。

ベースになっているdokkuはDockerを使うことでわずか100行程度のBashスクリプトで小さなPaaSを実現していますが、そこに機能追加することでより可用性を増し、個人用途であれば十分な機能を備えています。PaaSをサービス提供するという訳ではなく、自社や個人で使っているアプリをより手軽にデプロイできる場所としては面白いと思います。

ぜひさくらのクラウドとともにお試しください!

dokku-alt/dokku-alt

おしらせ

banner_cloud

DockerでミニHeroku!「Dokku」をさくらのクラウドで試す

$
0
0

シンプルなPaaSで知られるHerokuは使っていますか?ちょっとしたWebアプリを作って試すには便利ですが、もっとマシンパワーが必要になったり、もっと自由に使ってみたいと思うこともあるでしょう。

そんな要望を叶えるためのソフトウェアがDokkuです。DockerをベースにしたHerokuクローンになります。Dockerなので任意のクラウド、VPSサーバ上に立てることができます。今回はさくらのクラウドを使ってDokkuを実行する手順を紹介します。

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

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

DokkuはUbuntu 12.04 x64または14.04 x64をサポートしています。LTSとは言え、ここは14.04を選択することとします。アーカイブにUbuntu Server 14.04 LTS 64bit(基本セット)が登録されていますので、ここから選ぶだけでOKです。

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

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

Dokkuをインストール

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

$ ssh ubuntu@server_ip_address

でログインできます。server_ip_addressは適宜読み替えてください。サーバにログインしたら以下のコマンドを実行します。

$ wget -qO- https://raw.github.com/progrium/dokku/v0.2.3/bootstrap.sh | sudo DOKKU_TAG=v0.2.3 bash

なお、なぜか1回ではうまくいかず、2回実行するとセットアップが完了しました。

アドレスを決める

Dokkuではapp1というアプリをデプロイすると、http://app1.example.com といった感じでサブドメインで動くようになります。そのため、予めドメインを決めておく必要があります。設定は、 /home/dokku/VHOST を書き換えれば良いので、例えば dokku.moongift.jp を使うとすれば、

# echo "dokku.moongift.jp" > /home/dokku/VHOST

のように設定します。

公開鍵を設定する

リポジトリへアクセスするための公開鍵を設定します。GitHubでアカウントを持っているのであれば、docker – Dokku 入れた && モリモリ使える感じにした – Qiitaで紹介されている方法を使うのが便利です。

# curl https://github.com/GITHUB_USERNAME.keys | sudo sshcommand acl-add dokku DESC

GITHUB_USERNAMEは自分のユーザ名を、DESCは適当な説明を指定します。

ここまでで準備は完了です。

nodeアプリをデプロイしてみる

ではデモをしましょう。ここではheroku/node-js-sampleを使ってみます。以下は自分のローカルでの操作です。

$ git clone git@github.com:heroku/node-js-sample.git
$ cd node-js-sample
$ git remote add progrium dokku@server_address:node-js-app
$ git push progrium master

server_address は先ほど VHOST に指定したアドレスを指定してください。pushすると自動的に /home/dokku 以下にGitリポジトリが作られ、デプロイされます。ログは以下のようになります。

$ git push progrium master
Counting objects: 378, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (304/304), done.
Writing objects: 100% (378/378), 209.77 KiB | 0 bytes/s, done.
Total 378 (delta 45), reused 378 (delta 45)
-----> Cleaning up ...
remote: Cloning into '/tmp/tmp.NO73c0jCC6'...
-----> Building node-js-app ...
remote: warning: You appear to have cloned an empty repository.
remote: done.
remote: HEAD is now at 97a7c5c... wording
       Node.js app detected
-----> Requested node range:  0.10.x
-----> Resolved node version: 0.10.30
-----> Downloading and installing node
-----> Writing a custom .npmrc to circumvent npm bugs
-----> Installing dependencies
       express@4.8.3 node_modules/express
       ├── utils-merge@1.0.0
         :
       └── send@0.8.1 (ms@0.6.2, mime@1.2.11, finished@1.2.2)
-----> Caching node_modules directory for future builds
-----> Cleaning up node-gyp and npm artifacts
-----> No Procfile found; Adding npm start to new Procfile
-----> Building runtime environment
-----> Discovering process types
       Procfile declares types -> web
-----> Releasing node-js-app ...
-----> Deploying node-js-app ...
=====> Application deployed:

http://node-js-app.dokku.moongift.jp

To dokku@dokku.moongift.jp:node-js-app
 * [new branch]      master -> master

デプロイしたら、表示されているURLにアクセスできるようになります。

見事実行されました!
見事実行されました!

Docker

アプリがデプロイされているのはdockerコマンドで確認できます。

$ sudo docker ps
CONTAINER ID        IMAGE                      COMMAND                CREATED             STATUS              PORTS                     NAMES
e1cdd1502e87        dokku/node-js-app:latest   /bin/bash -c '/start   2 hours ago         Up 2 hours          0.0.0.0:49153->5000/tcp   suspicious_nobel 

イメージも確認できます。

$ sudo docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
dokku/node-js-app    latest              780d7dcbbb19        2 hours ago         885.3 MB
progrium/buildstep   latest              47f25c200541        2 hours ago         866.4 MB

デプロイするアプリ単位でDockerコンテナが立ち上がる形になっているのが分かります。これによりセキュアでリソースが適切に管理された状態で運用ができるようになっているのが分かりますね。

まとめ

現在のところ、Node/Ruby/Pythonを基本としつつ、Heokuのbuildpackに対応しているのでJava/Scala/Clojure/Gradle/Grails/PHP/Go/Meteor/Perl/Dartなど多彩な言語をデプロイできるようになっています。Heroku向けに作ったWebアプリケーションがそのまま使えるのも利点です。

GitリポジトリをpushするだけでデプロイしてWebサーバが立ち上がるところまでできてしまうのが良いです。さらにHerokuと違ってサブドメインが分かりやすいので管理がしやすいかと思います。ただし管理画面などはありませんので注意してください。

自由に使えるPaaS(Platform as a Service)が簡単に実現できてしまうDokku、ぜひさくらのクラウドと一緒に試してみてください。

progrium/dokku

おしらせ

banner_cloud

SeleniumサーバもDockerで。「Docker Selenium」レビュー

$
0
0

DockerはIT界隈で広まりつつも、なかなか実践的に使うことができないという人は多いのではないかとかと思います。しかし何もサーバ運用環境として使わずとも、使いどころはあります。その一つがサーバソフトウェアのインストールです。

サーバソフトウェアはインストールの手間と、その後のバージョンアップや他のソフトウェアで使っている共通ライブラリのコンフリクトなど、とかく運用が面倒です。基幹系システムが入っているサーバに他のソフトウェアをインストールするのは躊躇しますよね。

そういったときにDockerを使えばそれぞれのソフトウェアの環境が分けられるのでセキュリティ、運用的に安心できます。今回はその一つとしてDocker Selenium、Dockerを使ったSeleniumサーバを紹介します。

Docker Seleniumのインストール

インストールはとても簡単です。なおDockerはインストールされているものとします。今回はさくらのクラウドでCoreOSを立ち上げています。

ログインしたらdockerコマンドを実行します。

$ sudo docker run --privileged -p 4444:4444 -p 5900:5900 elgalu/docker-selenium

後は待っていれば終わりです。 /etc/hosts 書き込む処理が行われるところでエラーになるのですが、動作には影響がないようです。

VNCで接続

コンテナが立ち上がると、5900番ポートでVNCが立ち上がります(4444はSelenium Server用です)。RealVNCなどから接続が可能です。なお初期設定のパスワードはsecretになります。これはDockerfileに記述されていますのでフォークして修正するのが良さそうです。

接続後の画面
接続後の画面

Docker Seleniumにはfluxboxという軽量なWindowマネージャがインストールされますので、このようにGUIで画面が確認できます。

Seleniumを試す

この時点ですでにSelenium Serverが立ち上がっていますので、http://IPアドレス:4444 を指定して実行が可能です。

たとえば次のようなコードが実行できます(Rubyで実行しています。gem install selenium-webdriver を行ってください)。

require "selenium-webdriver"

@driver = Selenium::WebDriver.for :remote, :url => "http://IPアドレス:4444/wd/hub", :desired_capabilities => :firefox

@driver.navigate.to "http://knowledge.sakura.ad.jp/" 

sleep(10) 

puts @driver.title

@driver.find_elements(:css, "h2 a").first.click

sleep(10) 

puts @driver.current_url

@driver.save_screenshot('./firefox.png')

@driver.quit

たとえばこれでさくらのナレッジにアクセスして、一番上にある記事をクリックすると言ったスクリプトになります。あらかじめFirefoxとGoogle Chromeは入っていますので、

# Firefox
@driver = Selenium::WebDriver.for :remote, :url => "http://IPアドレス:4444/wd/hub", :desired_capabilities => :firefox

# Google Chrome
@driver = Selenium::WebDriver.for :remote, :url => "http://IPアドレス:4444/wd/hub", :desired_capabilities => :chrome

と指定ができます。

Firefoxで実行中。タイトルは文字化けしていますがコンテンツは読めます。
Firefoxで実行中。タイトルは文字化けしていますがコンテンツは読めます。
クリックもでき、画面遷移しました。スリープは適当に調整が必要です。
クリックもでき、画面遷移しました。スリープは適当に調整が必要です。
Google Chrome版。レンダリングはこちらのが高速かも。
Google Chrome版。レンダリングはこちらのが高速かも。

スクリーンショットはGoogle Chrome/Firefoxともに可能ですが、Google Chromeの場合は見えている範囲のみ、Firefoxの場合はスクロールも含めて全体と言った違いがあるようです。

Google Chromeのスクリーンショット保存。
Google Chromeのスクリーンショット保存。
Firefoxのスクリーンショット保存。縦長なので一部だけ。
Firefoxのスクリーンショット保存。縦長なので一部だけ。

Selenium Serverの多くはローカルで立てて、開発用途に使うかと思いますが、Docker Seleniumの場合はクラウド上でも簡単に立てられるので本番環境の動作チェックにも使いやすいです。何より環境の構築がとても簡単なので、テストを書く前の苦労が大幅に軽減されるでしょう。

Docker Seleniumを試す際にはぜひさくらのクラウドとともに!

elgalu/docker-selenium Repository | Docker Hub Registry – Repositories of Docker Images

elgalu/docker-selenium

おしらせ

banner_cloud

Dockerの構成管理「Fig」で開発環境を整備しよう

$
0
0

Dockerに対する注目がどんどん高まっています。GoogleやMicrosoftもDockerを積極的に採用して自社クラウドサービスに組み込んでいますし、Dockerを使ったコンテナベースのクラウドサービスも増えています。

Dockerでは各コンテナではあまり複雑な構成をせず、1コンテナ1アプリケーションとして、コンテナ間をリンクして使うのがお勧めです。それによってコンテナ間の依存度を下げつつ保守性を維持できるのがメリットになります。

逆にデメリットとしては構成が複雑になるためにアプリケーションをまとめあげ、構成する仕組みが必要になります。今回はそのためのツールとしてリリースされたFigを紹介します。元々Orchard Labsが開発していましたがDocker社に買収され、2014年10月にリリースされたツールになります。Docker本体が買収したとあって、需要は高いツールと言えるでしょう。

Figは開発環境を柔軟に管理、運用するツールになります(開発環境用オーケストレーションツールです)。Linux上またはMac OSX上(boot2docker利用)が想定されているようです。今回はこのFigの使い方を紹介します。なおOSはUbuntu 14.04 LTSを使っています。

Figのインストール

FigはDockerの最新版である1.3以上で動作します。CoreOSや通常のaptなどでインストールできるバージョンは低いので最新版にします。こちらのコマンドを実行します。

$ curl -sSL https://get.docker.io/ubuntu/ | sudo sh
$ docker -v
Docker version 1.3.1, build 4e9bbfa

Dockerをインストールしたら、設定ファイルを編集した後でサービスとして起動します。

$ cat /etc/default/docker
  :
# DOCKER_OPTSをこのように編集します。
#DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4" (元)
# ↓
DOCKER_OPTS="-H tcp://127.0.0.1:4243 -H unix:///var/run/docker.sock --dns 8.8.8.8 --dns 8.8.4.4"
  :

設定を編集したらサービスとして起動し、DOCKER_HOSTを環境変数に設定します。

$ sudo restart docker # Dockerをサービス起動します
$ export DOCKER_HOST=tcp://localhost:4243 # DockerのURIを設定します

次にFigのインストールです。次のコマンドでインストールできます。

# curl -L https://github.com/docker/fig/releases/download/1.0.1/fig-`uname -s`-`uname -m` > /usr/local/bin/fig; chmod +x /usr/local/bin/fig

バイナリがGitHubで公開されていますので、それを /usr/local/bin/fig としてコピーしています。なおMac OSX版もあるのですが、こちらはboot2dockerをインストールすれば同梱されるようです。

$ fig --version
fig 1.0.1

これで準備は完了です。

Ruby on Rails環境を構築する

まずRuby on Railsの開発環境を構築する例になります。構成としては、Web(Ruby on Rails)とDB(PostgreSQL)という構成になります。

作業用ディレクトリを作成します。

$ mkdir rails
$ cd rails

Dockerfileを次の内容で作成します。

$ cat Dockerfile
FROM ruby
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev
RUN mkdir /myapp
WORKDIR /myapp
ADD Gemfile /myapp/Gemfile
RUN bundle install
ADD . /myapp

Rubyがあらかじめ入ったコンテナイメージをベースに、aptで必要なものをインストールしています。さらに myapp というディレクトリを作成し、そこにGemfileを入れています。とてもシンプルで、PostgreSQLに関する記述はありません。

次に同じディレクトリにGemfileを作成します。こちらはまず最低限です。

$ cat Gemfile
source 'https://rubygems.org'
gem 'rails', '4.0.2'

最後に fig.yml を作成します。これがFigが使う構成管理に関する設定ファイルです。

$ cat fig.yml
db:
  image: postgres
  ports:
    - "5432"
web:
  build: .
  command: bundle exec rackup -p 3000
  volumes:
    - .:/myapp
  ports:
    - "3000:3000"
  links:
    - db

リンクするデータベース(db)のイメージファイルやポート番号、さらにWebアプリケーション(web)の実行コマンドやポート、リンクに関する設定が記述されています。これまでDockerfile内で記述されていたような内容ですが、分離することでfig.ymlが構成管理に関する記述だけにまとめられるようになっています。

ここまでの記述が終わったら、figコマンドを実行します。

$ fig run web rails new . --force --database=postgresql --skip-bundle

fig run というコマンドで指定したコンテナ(ここではweb)に対して任意のコマンドが実行できます。ここでは rails new . --force --database=postgresql --skip-bundle が実行されると言うことで、Gemfileに記述した内容と同じくRuby on Railsがインストールされます。このときPostgreSQLのコンテナイメージも取得するのでしばらくかかります。

終わると次のようにRailsアプリケーションの基本構成がカレントディレクトリに展開されます。

$ ls
app  config     db          fig.yml  Gemfile.lock  log     Rakefile     test  vendor
bin  config.ru  Dockerfile  Gemfile  lib           public  README.rdoc  tmp

今後、GemfileやDockerfileをアップデートした際には fig build コマンドを実行する必要があるようです。

最後にRailsアプリケーションのデータベース設定を編集します。

$ cat config/database.yml
  :
development:
  adapter: postgresql
  encoding: unicode
  database: postgres
  pool: 5
  username: postgres
  password:
  host: db

hostがdbと簡単な表記になっているのが特徴です。これでFigで設定しているdbと連携してくれるようになります。

ではRailsアプリケーションを実行します。

$ fig up
Recreating rails_db_1...
Recreating rails_web_1...
Attaching to rails_db_1, rails_web_1
db_1  | LOG:  database system was interrupted; last known up at 2014-11-07 08:25:16 UTC
db_1  | LOG:  database system was not properly shut down; automatic recovery in progress
db_1  | LOG:  record with zero length at 0/1782A80
db_1  | LOG:  redo is not required
db_1  | LOG:  database system is ready to accept connections
db_1  | LOG:  autovacuum launcher started
web_1 | [2014-11-07 12:42:49] INFO  WEBrick 1.3.1
web_1 | [2014-11-07 12:42:49] INFO  ruby 2.1.4 (2014-10-27) [x86_64-linux]
web_1 | [2014-11-07 12:42:49] INFO  WEBrick::HTTPServer#start: pid=1 port=3000
Ruby on Rails実行結果
Ruby on Rails実行結果

コンソールに入る場合は次のようになります。

$ fig run web rails c
Loading development environment (Rails 4.0.2)
irb(main):001:0> 

figというコマンドを介しているものの、ローカルで開発しているのと変わらないくらいの感覚でDockerが使えるようになるのではないでしょうか。仮想化がされているので開発環境の可搬性があがり、メンテナンスはとてもしやすいでしょう。

WordPressを立ち上げる

次にWordPressをFigを使って立ち上げてみます。

$ mkdir wordpress
$ cd wordpress

まず、WordPressをダウンロードして解凍します。

$ curl https://wordpress.org/latest.tar.gz | tar -xvzf -

そうするとwordpressというディレクトリができます。

続いてDockerfile、fig.ymlを作成します。

$ cat Dockerfile
FROM orchardup/php5
ADD . /code
$ cat fig.yml
web:
  build: .
  command: php -S 0.0.0.0:8000 -t /code
  ports:
    - "8000:8000"
  links:
    - db
  volumes:
    - .:/code
db:
  image: orchardup/mysql
  environment:
    MYSQL_DATABASE: wordpress

こちらもまたDockerfileはとてもシンプルに保たれていることが分かるかと思います。

そして wordpress/wp-config-sample.phpをベースに設定ファイルを作成します。

define('DB_NAME', 'wordpress');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', "db:3306");
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

データベースの接続情報について編集します。こちらもホスト設定がdb:3306とシンプルなものになっているのが分かるかと思います。

最後にPHPのビルトインWebサーバ用にファイルを作成します。

$ cat router.php
<?php

$root = $_SERVER['DOCUMENT_ROOT'];
chdir($root);
$path = '/'.ltrim(parse_url($_SERVER['REQUEST_URI'])['path'],'/');
set_include_path(get_include_path().':'.__DIR__);
if(file_exists($root.$path))
{
    if(is_dir($root.$path) && substr($path,strlen($path) - 1, 1) !== '/')
        $path = rtrim($path,'/').'/index.php';
    if(strpos($path,'.php') === false) return false;
    else {
        chdir(dirname($root.$path));
        require_once $root.$path;
    }
}else include_once 'index.php';

これで準備は完了です。Figを実行します。初回はイメージをとってくるので時間がかかります。

$ fig up
WordPress実行画面
WordPress実行画面

Dockerfileを使って設定を記述するとはいっても、実際には単体では難しく、別途Shellスクリプトを実行するケースはとても多かったです。さらに複雑化すれば記述内容が増えたり、メンテナンス性が悪くなります。それではDockerの持ち味が活かせなくなるでしょう。

Figは構成を分かりやすくできるほか、例えば

$ fig scale web=2 worker=3

のように実行することでWebというコンテナの数を増やすこともできます。Dockerを使った運用が柔軟になりそうです。開発環境でこういった複数構成を試せるのが良いですね。これまでVagrantで構築していたのをboot2docker + Figにすることで複数のプロジェクトを切り替えたり、多くのVMイメージファイル管理から解放されるのではないでしょうか。

ぜひFigを使って開発、運用負荷を軽減してください!

Fig | Fast, isolated development environments using Docker

DockerをWebブラウザで管理できる「Seagull」レビュー

$
0
0

Dockerを本格的に使い始めると、どのコンテナが動いていて、イメージは何があるのかなどの管理が煩雑になります。ターミナルで操作はできるものの、実際に運用を行っていく中ではやはり管理用のインタフェースが欲しくなるのではないでしょうか。

そこで使ってみて欲しいのがSeagullです。コンテナやイメージの状態を一覧表示したり、起動や停止と言った操作もできるDocker管理用のWebシステムとなっています。

今回はこのSeagullをさくらのクラウドを使って試してみました。

用意するもの

  • Ubuntu 14.04 LTS(CentOSやCoreOSでも動くと思いますが)
  • Docker(apt-get install docker.io)

Seagullのインストール

SeagullのインストールはDockerコマンドでできます。

$ docker run -d -p 10086:10086 -v /var/run/docker.sock:/var/run/docker.sock tobegit3hub/seagull

-vオプションで分かる通り、Dockerのsockファイルをわたしています。これを使ってDockerの状態をコントロールしています。

立ち上がったら、 http://サーバのIPアドレス:10086/ でSeagullにアクセスできます。

Seagullのトップページ
Seagullのトップページ

Seagullの機能

メニューは4つで、コンテナ、イメージ、設定、GitHubとなっています。

コンテナメニュー

コンテナの画面
コンテナの画面

コンテナでは既に登録されているコンテナが一覧表示できます。このコンテナは終了しているものも含めて表示されます。なお、ここから新しいコンテナを作ることはできません。

イメージメニュー

イメージの画面
イメージの画面

イメージメニューはDockerイメージの一覧表示です。ここでも新規作成はなく、既にあるイメージを一覧できるだけとなっています。イメージの削除は可能です。

設定メニュー

設定の画面
設定の画面

設定メニューはDockerやGoの設定状態を確認できる画面になります。特に編集することはできず、設定を確認するだけとなっています。

DockerHubメニュー

DockerHubの画面
DockerHubの画面

この画面では今のところSeagullの情報を確認できるだけとなっています。

その他の機能

Seagullはローカルだけでなく、外部のDockerサーバに対しても操作ができます。サーバを追加すれば、リモートのDockerサーバに対しても操作ができます。

追加する場合は、右上にあるLocalメニューにあるAdd Serverを選択します。

メニューよりAdd Serverを選択

メニューよりAdd Serverを選択

Add Serverを選択すると、モーダルウィンドウが開くので、そこでDockerサーバのIPアドレスを入力します。

サーバ追加

サーバ追加

使い方

実際のDokcer利用についてはこれまで通りターミナルで行います。その結果がSeagullで確認できる仕組みです。

コンテナを立ち上げたところ
コンテナを立ち上げたところ

一旦コンテナを作ってしまえば、その後の起動や終了、削除はSeagull上から行える仕組みです。

コンテナの詳細情報を確認すると、走っているプロセスも表示されます。

コンテナの詳細情報
コンテナの詳細情報

アクセス制限

SeagullはそのままだとIPアドレス+ポート番号で誰でもアクセスできるようになります。そこで例えばローカルからだけアクセスできるように、次のように起動コマンドを実行します。

$ docker run -d -p 127.0.0.1:10086:10086 -v /var/run/docker.sock:/var/run/docker.sock tobegit3hub/seagull

そしてnginxなどのWebサーバをプロキシとしてSeagullにアクセスするようにし、nginx側でIPアドレスベースやBasic認証などの制限を設けるのが推奨されています。

Seagullは手作業でDockerを試しているときよりも、実際の運用フェーズの中で自動化している際、その状況を確認する目的に良いのではないでしょうか。いくつのコンテナが立ち上がっているのかなど、Seagullを使えばすぐに把握できます。わざわざサーバにログインしなくても良いので手軽です。

今後Dockerを本格的に運用していこうと考えた際にはSeagullの導入を検討してください。

tobegit3hub/seagull

Viewing all 433 articles
Browse latest View live