2015-06-30

Jenkins を Cloud Foundry で動かす

「Cloud Foundry 百日行」第19日目は，皆さんご存知 CI (Continuous Integration) ツール Jenkins です。

実はこの記事を書こうとして検索した時に，以下のような記事を見つけたのですが，

立ち上げるだけであれば，本稿の手順だと，たったの2ステップ／5分程度 (注:ネットワークの速度に依存します) で終わります。記事を書く際は非常に楽でした。

基本情報

手順の概要は以下の通りです。

  1. コードの取得
  2. Cloud Foundry 環境への push
  3. 動作確認

コードの取得

参考情報にも記しましたが，2014年末，Cloud Foundry 開発者のメイリング・リストに， Jenkins のデプロイに関する投稿 があり，そのスレッドで jenkins-buildpack を使うとうまくいったという報告がありました。本稿でもこの方法を使います。

Buildpack の良い点の一つは，このように，他の人が作ったものを，繰り返し可能な手順 (自動化手順) として使わせてもらえるところにあると思います。

jenkins-buildpack の README に従い， Jenkins 公式サイトから 最新安定版の war ファイル を取得します。ちなみに，検証時点でのバージョンは 1.609.1 でした。

$ curl -L http://mirrors.jenkins-ci.org/war-stable/latest/jenkins.war -o jenkins.war

-L は，リダイレクトに従うためのオプションです。

Cloud Foundry 環境への push

先ほどダウンロードした war ファイルを，jenkins-buildpack を使って Cloud Foundry 上に push します。

$ cf push j -p jenkins.war -b https://github.com/Altoros/jenkins-buildpack.git -m 1G -t 180

Creating app j in org nota-ja / space 100 as nota-ja...
OK
.......
requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: j.10.244.0.34.xip.io
last uploaded: Tue Jun 23 10:43:44 +0000 2015
stack: lucid64

     state     since                    cpu    memory         disk      details
#0   running   2015-06-23 07:44:34 PM   0.0%   256.4M of 1G   0 of 1G

スムーズに起動しました。ダウンロードしてpush。これだけです。

ポイントは，

  • メモリ1GB以上を指定すること
    メモリが不足している場合，起動に失敗します
  • タイムアウトを長め(上の例では180秒)に取ること
    war ファイルのサイズ自体が大きく，アップロードに時間がかかるのに加えて，jenkins-buildpack がダウンロード/展開するファイルの量も多いので，長めに取っておくに越したことはありません
    (もっとも，今回実際にかかった時間は1分15秒程度でしたが)

動作確認

ブラウザーでアクセスしてみます。

最初の画面：

ちゃんと起動しています。

ジョブを作ってみます。

ジョブ設定画面：

ジョブ完成：

ビルド結果 (コンソール) ：

問題なく動作しています。

なお，push したままの状態では何のセキュリティもない状態なので，気になる方はユーザーを作って認証をかけても良いと思います。私は この記事 を参考に認証の設定を行いましたが，問題なく動作しました。

さて，今回とても簡単に動いた Jenkins ですが，このままでは実運用には適していません。

最大の問題は， Cloud Foundry 環境のファイルシステムが揮発性である (永続的ではない) ということです。

Cloud Foundry のアプリケーションのインスタンスは，コンテナーの中で動作します。コンテナーはアプリケーションのインスタンスが起動するたびに作成され，停止されたり再起動がかかったりしたら廃棄されます。この時，コンテナー内のファイルも全て消えてしまいます。

Jenkins は通常，設定等をファイルに保存するので，再起動がかかると全て設定が消えてまっさらの状態に戻ってしまいます。これは Jenkins だけでなく，ファイルシステムを利用するアプリケーション全てに共通の問題です。なお，Jenkins の設定の問題に関しては， Database plugin という，設定をデータベースに保存する Jenkins プラグインを使うと解決できる可能性がありますが，今回は試していません。ご要望があれば検証して別に記事を書くかもしれません。

もう一つ，今回は slave を使わない master のみの構成で試したので正確なことはわかっていませんが，Jenkins には master と slave との通信の問題もありそうです。Jenkins では build を本体とは別のマシン (slave) で行う機能がありますが，Cloud Foundry 上で Jenkins の master / slave を動作させる場合，再起動がかかるたびにコンテナーが再作成され，それらは再起動前とは異なるホスト/ポートで待ち受けることになるので，master と slave はお互いが待ち受けるホスト/ポートの情報をなんらかの手段で共有するか，外部に公開されたURL経由でのみアクセスを行うかするなどの考慮が必要になりそうです。この点が実際に問題になるのかどうかもわかっていないのですが，これもご要望があれば試してみるかもしれません。

さて，上述のような制約がある中，いったい Cloud Foundry 上で Jenkins を動かすことにどのような意味があるのでしょうか。個人的には「新しいプラグインを試したい」「新しいジョブを試したい」「Jenkins をアップグレードする前に既存ジョブが動作するかどうか試したい」というような，試しに使う新しいインスタンスを起動する方法として適しているのではないかと思います。

Jenkins は apt や yum などのパッケージ・マネージャーでも簡単に入りますし，DockerHub から Docker Image として起動することもできます。しかし，自分の環境を汚さず，かつ極めて簡単に起動できるという点で，お試し Jenkins を作るための選択肢の一つであると考えています。

今回使用したソフトウェア