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

Jenkinsでの設定

 続いて、Jenkins側でDockerを利用できるよう設定を行う。まず、「Jenkinsの管理」内の「システムの設定」をクリックする(図12)。

図12 「Jenkinsの管理」内にある「システムの設定」をクリックする
図12 「Jenkinsの管理」内にある「システムの設定」をクリックする

 続いて、表示される「システムの設定」画面内にある「クラウド」以下の「追加」をクリックし、「Docker」を選択する(図13)。

図13 「システムの設定」画面内の「クラウド」で「追加」をクリックし「Docker」を選択する
図13 「システムの設定」画面内の「クラウド」で「追加」をクリックし「Docker」を選択する

 すると、Docker向けの設定項目が表示されるので、ここに各種設定内容を追加して行く(図14)。

図14 Docker向けの設定項目が表示される
図14 Docker向けの設定項目が表示される

 最低限入力が必要なのは、「Name」と「Docker URL」だ。「Name」は何でも良いが、ここでは分かりやすいよう「docker」とした。「Docker URL」は、Dockerの操作に使うエンドポイントをURI形式で指定する。今回はホスト上の/var/run/docker.sockファイルをエンドポイントとして使用するので、「unix:///var/run/docker.sock」とした。

 ちなみに、Jenkinsが稼動しているホスト以外で稼動するDockerを利用することも可能だ。その場合、ここでは「http://<DockerサーバーのURL>:<ポート>」のような形で、Docker APIを受け付けるURIを指定することになる。これを利用して、以前の記事で紹介したDocker Swarmを使ったDockerクラスタを利用してビルドを行う、といったことも可能だ。

 「Connection Timeout」と「Read Timeout」はDockerへの接続時やDockerの出力を読み取る際のタイムアウト時間を指定するものだ。「0」ではタイムアウトなしになってしまうので、適当な値を設定しておいたほうが良いだろう。

 続いて、「Add Docker Template」→「Docker Template」をクリックすると「Docker Template」という項目が追加されるので、ここで使用するコンテナを指定する(図15)。

図15 「Docker Template」以下で使用するコンテナの情報を追加する
図15 「Docker Template」以下で使用するコンテナの情報を追加する

 ここで設定が必要なのは以下の項目だ。

  • 「Docker Image」:使用するイメージ名を入力する
  • 「Remote Filing System Root」:Jenkinsが各種作業に使用するディレクトリを入力する
  • 「Labels」:ノードを指定する際などに利用するラベルを設定する
  • 「用途」:このノードを利用するための条件を指定する
  • 「Launch method」:Jenkinsとコンテナがどのように通信を行うかを指定する。通常は「Docker SSH computer launcher」を指定し、SSH経由で接続するようにする
  • 「認証情報」:JenkinsがコンテナにSSHでアクセスする際に使用する認証情報を指定する
  • 「Pull strategy」:コンテナの実行前に自動的にコンテナリポジトリからpull操作を行うかどうかを選択する

 なお、「Remote Filing System Root」で指定したディレクトリでは「認証情報」で指定したユーザーに対し読み書きアクセスできる権限が与えられている必要がある。

 また、今回は特に設定していないが、「Container settings…」をクリックするとコンテナ起動時の設定をより詳しく設定することが可能だ(図16)。

図16 「Container settings...」でより詳細なコンテナ起動設定を行える
図16 「Container settings…」でより詳細なコンテナ起動設定を行える

 以上の設定が完了したら、「保存」をクリックして設定内容を保存する。これで指定したコンテナをノードとしてビルドに利用できるようになる。

 なお、「Add Docker Template」→「Docker Template」をクリックして設定内容を指定する作業を繰り返すことで、複数のコンテナが登録可能だ。

パイプラインの設定

 ここまでの作業で登録したコンテナはJenkinsからはスレーブノードとして扱われ、ビルドスクリプト側でコンテナに設定したラベルを「node」命令で指定することで、そのコンテナ内でのビルドが可能になる。

 たとえば先に追加したコンテナでは「slash-build」というラベルを指定しているので、ビルドスクリプトの「node」部分を次のようにすることでコンテナでのビルドを実行できる(図17)。

node('slash-build') {
図17 ビルドスクリプトの「node」命令に使用するノードを指定する
図17 ビルドスクリプトの「node」命令に使用するノードを指定する

 以上の設定が完了すれば、Dockerコンテナを使ったビルドやテストが可能になる。実際にビルドを実行し、正しくビルドが実行できるか確認してみよう。なお、ビルドに使用されたコンテナは作業が完了した時点で自動的に停止される。また、ビルドログ等は実サーバーをスレーブとして利用した場合と同様の手順で確認できる。

マスター/スレーブ構成を取ることでより柔軟な設定が可能に

 本記事ではJenkinsのマスター/スレーブ構成について解説を行ったが、このような構成を取ることで、より柔軟にビルド環境を構築できるようになる。また、今回紹介したDocker Plugin以外にも、たとえばクラウドサービス上のホストをスレーブとして利用できる様にするプラグインなども公開されている。

 最近ではTravis CIのようなクラウド型のCIツールも広く使われているが(参考記事:GitHubと連携できる継続的インテグレーションツール「Travis CI」入門)、Jenkinsの最大の特徴はさまざまな環境や構成に適用できる柔軟性だ。また、フリーソフトウェアなので導入がしやすく、クローズドなリポジトリと組み合わせても利用しやすいというメリットもある。

 サーバーやJenkins自体の管理を自前でやらなければならない、というデメリットはあるものの、一度セットアップを行ってしまえばその後は非常に手軽に自動ビルドなどが利用可能だ。CIを利用してみたいという方は、ぜひ一度使ってみてはいかがだろうか。