【Jenkinsを使った自動テスト環境を作る】Dockerコンテナを使って自動ビルドを実行する 2ページ

松島浩道
シェア

指定したノードを使用してビルドを行う

　続いて、ビルドを行うジョブを開き、追加したノードを指定してビルドを行うように設定を変更しよう。まずジョブの設定画面を開き、ビルドスクリプト内で「node { 」と記述されていた部分を以下のように変更する。

node('＜ビルドに使用するノード名もしくはラベル＞') {

　たとえば先ほど登録した「centos7」というノード上で処理を行うには「node(‘centos7’)」のように指定すれば良い（図7）。

図7 「node」部分に使用するノード名を指定する
図7 「node」部分に使用するノード名を指定する

　スレーブを利用する設定は以上で完了だ。「保存」をクリックし、続いて「ビルド実行」をクリックして正しくビルドが行えるかどうかを確認してみよう。なお、どのノードを使用してビルドが実行されたかは、各ステージの実行結果右下に表示される（図8）。

図8 どのノードでビルドが実行されたかは、各ステージの実行結果右下に表示される
図8 どのノードでビルドが実行されたかは、各ステージの実行結果右下に表示される

　もしビルドに失敗した場合、画面左に表示されるビルド結果の「#＜数字＞」横の「▼」をクリックしてドロップダウンメニューを開き、「コンソール出力」をクリックすると、詳細なログを確認できる（図9、10）。これを参考に原因を調べると良いだろう。

図9 ビルド結果一覧のドロップダウンメニュー
図9 ビルド結果一覧のドロップダウンメニュー
図10 コンソール出力画面
図10 コンソール出力画面

　なお、今回実行したビルドスクリプトは前回紹介したものと同一だ。この中には「SSH Agent」プラグインを使ってSCPでファイルをコピーする処理が含まれているが、このとき使われる認証情報はスレーブ上のものではなくマスター上のものである点には注意したい（マスターに登録されている秘密鍵がスレーブに一時的に送信されて使用される）。そのため、マスター上で適切に認証情報および秘密鍵が登録されていれば、スレーブ上で秘密鍵を用意しておく必要はない。また、ファイルのコピー先サーバーに登録しておく公開鍵もスレーブのものではなくマスター上のものになる。ただし、ホスト鍵のチェックについてはスレーブ上で行われるため、必要に応じてscpコマンドにホスト鍵のチェックを省略する「-o “StrictHostKeyChecking no”」オプションを追加しておくと良いだろう。

「Docker Plugin」を利用したコンテナ内でのビルド

　さて、このようにJenkinsでは簡単に別のマシン上でのビルドが実行できるが、これを応用し、Dockerコンテナ上でビルドを行えるようにするプラグインが「Docker Plugin」だ。このプラグインを利用するにはDocker Pluginの導入に加えて、Dockerの設定やビルドに使用するコンテナの準備などが必要となる。続いてはこれらを説明していこう。

　なお、DockerとJenkinsを組み合わせる際、Jenkins自身をDockerコンテナ内で稼動させることも可能ではあるが、今回はそれを利用せず、Jenkinsがホスト上で直接稼動している環境を前提とする。

Docker Pluginのインストール

　Docker Pluginは、Jenkinsのプラグインマネージャからインストールできる。プラグインマネージャを開き、「利用可能」タブを選択すると利用できるプラグインが一覧表示されるので、「Docker Plugin」にチェックを入れ、「再起動せずにインストール」もしくは「ダウンロードして再起動後にインストール」をクリックすればインストールが行われる。このとき、「フィルター」に「docker」と入力すると探しやすい（図11）。

図11 Docker PluginはJenkinsのプラグインマネージャからインストールできる
図11 Docker PluginはJenkinsのプラグインマネージャからインストールできる

Dockerの設定

　Docker Pluginを利用するには、Jenkinsをインストールしているホスト上でDockerが利用できるだけでなく、Jenkinsを稼動させているユーザー（一般的には「jenkins」ユーザー）に対し、Dockerを操作できるようにするための権限を与えておく必要がある。

　一般的な環境では、dockerコマンドが使用する「/var/run/docker.sock」ファイルに対しパーミッション設定を行うことで、Dockerを操作できるユーザーを制限している。通常、以下のようにrootユーザーおよびdockerグループに属するユーザーのみがこのファイルにアクセスできるようになっているはずだ。

# ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0  6月  9 19:32 /var/run/docker.sock

　この場合、次のようにしてjenkinsユーザーをdockerグループに追加することで、jenkinsユーザーがdockerコマンド経由でDockerを操作できるようになる。

# usermod -a -G docker jenkins

　なお、docker.sockファイルへのアクセス権限を与えると、そのホスト上のすべてのファイル/ディレクトリへのアクセス権限を与えることになる（ホストのルートパーティションをコンテナ内にマウントすることで、コンテナ経由でroot権限ですべてのファイル/ディレクトリへのアクセスが可能になる）。そのため、サーバーのセキュリティには十分注意してほしい。

ビルドに使用するコンテナの準備

　ビルドに使用するコンテナはどのようなものでも構わないが、下記の条件を満たしている必要がある。

  • Java 7以上の実行環境がインストールされている
  • sshd（sshサーバー）がインストールされている

　DockerのコンテナイメージをホスティングしているDockerHubではCentOSやUbuntu、Debianなどの公式イメージを提供しているので、こちらをベースとしても良いし、Packerなどを利用して一からイメージを作成しても良いだろう（Packerに関する過去記事）。

　コンテナの作成については本記事の範囲外なので解説は割愛するが、たとえばDebianをベースとする環境であれば、以下のようなDockerfileを使用してコンテナを作成すれば良い。

FROM debian:jessie
RUN apt-get update -y && apt-get upgrade -y

↓Jenkinsスレーブとしての動作に必要なJava実行環境およびsshdをインストールする
RUN apt-get install -y openjdk-7-jdk openssh-server

↓SSH接続で22番ポートを使用することを明示
EXPOSE 22

↓Jenkinsが各種処理の実行に使用する「jenkins」ユーザーを作成する
RUN groupadd jenkins && useradd -d /home/jenkins -g jenkins -m jenkins

↓jenkinsユーザーでログインするための公開鍵をコピー
※あらかじめfiles/id_jenkins.pubとして公開鍵を準備しておく
RUN mkdir /home/jenkins/.ssh
COPY files/id_jenkins.pub /home/jenkins/.ssh/authorized_keys
RUN chown -R jenkins:jenkins /home/jenkins/.ssh \
 && chmod 700 /home/jenkins/.ssh \
 && chmod 600 /home/jenkins/.ssh/*

↓sshdの権限分離に使用するためのディレクトリを作成しておく
RUN mkdir -p /run/sshd

：
続けてソフトウェアのビルドやテストに必要なパッケージのインストールや設定を記述する
：

　コンテナを作成したらそのコンテナが正常に起動するか、また実際にSSHでログインできるかどうかを確認しておこう。たとえば作成したコンテナに「osdn/slash-build」というタグを付けておいた場合、以下のようにする。

# su jenkins ←jenkinsユーザーでテストを行う
$ docker run -ti --name slash-build osdn/slash-build /usr/sbin/sshd -D

　これで問題なくコンテナが立ち上がれば、続いて別のコンソールからSSHでログインできるかを確認してみよう。

# su jenkins ←jenkinsユーザーでテストを行う
$ docker inspect -f {{.NetworkSettings.IPAddress}} slash-build
192.168.0.2 ←コンテナのIPアドレスが表示される
$ ssh 192.168.0.2

　また、この時点でコンテナ内でビルド処理を手動で実行してみて、実際に実行できるかを確認しておくことをおすすめする。