バックアップツールとしてのjenkins

今やCI(Continuous Integration)の定番ツールとなりつつあるjenkins。構築、テスト、デプロイ等を自動化で安定させることで生産性を大幅に上げてくれる。
弊社でも様々なプロジェクトで使用しており、もはや必須のツールとなった。

Jenkinsの柔軟性が高く、Maven、AntだけでなくPhing等のビルドツールだけでなくシェルスクリプトも使える。（もちろんUNIXベースだが）

• シェルスクリプトが使える。
• それぞれのジョブの作業場所（ワークスペース）が使える。
• ジョブの成功・失敗の判定処理が行える。
• 失敗時のアラート処理
• ジョブの成果物を管理できる。

これらの機能を考えるとJenkinsはバックアップツールとしても非常に有用である。

実際、稼動しているサーバーのバックアップに以下のシナリオを適用している。

前提

• 対象となるホストはバックアップ用のアカウントで鍵認証によるSSH接続。
• バックアップのスクリプトはSubversionで管理。

シナリオ

1. ジョブでスクリプトをSubversionからワークスペースに展開
2. ジョブのタスクにスクリプトの実行を設定
3. スクリプト内でrsyncで対象ホストからバックアップの対象となるファイルをワークスペースにコピー。
4. tarコマンドで1つのアーカイブに圧縮。
5. ジョブのビルド後のタスクに、作成したアーカイブを成果物として指定
6. 失敗時はアラートでメールを送信

生成したアーカイブをジョブの成果物として登録することでローテートと同じ機能を実現できる。Jenkinsではジョブの設定でビルド数（または成果物）の保存日数またはその個数を指定することができる。また、成果物をJenkinsの画面からすぐにダウンロードできることも便利だ。

データベースのバックアップ等、当該ホストで処理が必要なバックアップはJenkinsからscpを使って当該ホストへバックアップ用のスクリプトを送信した後、ssh経由で実行させ出来上がったファイルをワークスペースにコピーしている。
これにより当該ホストでの処理とジョブの処理を同期させることが可能となる。

また、スクリプトを使う場合、Jenkins側で以下のような有用な環境変数が自動的に設定される。

BUILD_NUMBER

当該ビルドの番号。例 "153"

BUILD_ID

当該ビルドID。例 "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)

JOB_NAME

ビルドのプロジェクト名。例 "foo"

BUILD_TAG

文字列 "jenkins-${JOB_NAME}-${BUILD_NUMBER}"。簡易な識別子として、リソースファイルやjarファイルなどに付与するのに便利です。

EXECUTOR_NUMBER

このビルドを実行している現在のエグゼキューターを識別する(同一マシンの中で)ユニークな番号。"ビルド実行状態"に表示されている数字ですが、1ではなく0から始まる数字です。

NODE_NAME

ビルドが実行されるスレーブの名称。マスターで実行される場合は"master"。

NODE_LABELS

ノードに設定されたラベルのリスト（スペース区切り)。

WORKSPACE

ワークスペースの絶対パス。

JENKINS_HOME

The absolute path of the directory assigned on the master node for Jenkins to store data.

JENKINS_URL

JenkinsのURL。例 http://server:port/jenkins/

BUILD_URL

このビルドのURL。 例 http://server:port/jenkins/job/foo/15/

JOB_URL

このジョブのURL。 例 http://server:port/jenkins/job/foo/

SVN_REVISION

Subversion revision number that's currently checked out to the workspace, such as "12345"

SVN_URL

Subversion URL that's currently checked out to the workspace.

Jenkinsは使い方次第で様々な用途に使える。優秀なバックアップツールとしてもぜひ活用してみてはどうだろうか？

daemontoolsのインストール

daemontoolsとは

daemontoolsとはD.J.Bernstein氏が開発したUNIX向けのsupervise monitorツール。要は特定のプログラムをデーモン化させるツール。

今となってはいささか古いが、シンプルかつ軽量で根強い人気を誇る。

パッケージの入手

場所はどこでもいいが、今回は/usr/local/src配下でインストール。まず以下のコマンドでパッケージを入手。その後tarコマンドで展開。

$PACKAGE_HOME=/usr/local/src

# cd $PACKAGE_HOME
# wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
# tar zxvf daemontools-0.76.tar.gz

パッチの適用

glibc-2.3.2以降ではコンパイル時にエラーが出るので以下のパッチを作成・適用

$PACKAGE_HOME/admin/daemontools-0.76/daemontools-0.76.errno.patch

diff -ur daemontools-0.76.old/src/error.h daemontools-0.76/src/error.h
--- daemontools-0.76.old/src/error.h 2001-07-12 11:49:49.000000000 -0500
+++ daemontools-0.76/src/error.h 2003-01-09 21:52:01.000000000 -0600
@@ -3,7 +3,7 @@
 #ifndef ERROR_H
 #define ERROR_H
 
-extern int errno;
+#include 
 
 extern int error_intr;
 extern int error_nomem;

以下のコマンドでパッチを適用

# cd $PACKAGE_HOME/admin/daemontools-0.76
# patch -p1 < ./daemontools-0.76.errno.patch

インストール

$PACKAGE_HOME/admin/daemontools-0.76で以下のコマンドを実行。

# package/install

CentOS6.xでの修正

OSのレイアウトも変わりデフォルトのままでは正しく自動起動が行われない。

正しく動作させるため、以下のファイルの内容をコメントアウトする。

/etc/inittab

# SV:123456:respawn:/command/svscanboot

以下のファイルを作成

/etc/init/svscan.conf

initctl reload-configuration
initctl start svscan

OSの再起動後、自動起動が行われるようになる。

Wordpressを全てSSL化する

リバースプロキシ（Pound)の背後に内部向けのCMSを配備する必要があったので、WordPressをSSL化する必要があった。
管理者サイトだけ、もしく入力フォームだけというような部分的なSSLの方法はネットにいろいろ情報があったが、今回はリバースプロキシから当該サーバーまではIPで縛ったHTTP通信のため、URL判定ではなく強制的にSSL化する必要がある。

最も簡単な方法は以下のとおり。

$WP_HOME/wp-include/function.php

function is_ssl() {
        return true;
//        if ( isset($_SERVER['HTTPS']) ) {
//                if ( 'on' == strtolower($_SERVER['HTTPS']) )
//                        return true;
//                if ( '1' == $_SERVER['HTTPS'] )
//                        return true;
//        } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
//                return true;
//        }
//        return false;
}

is_sslの関数の内容を全てコメントアウトし、return true;で強制的にSSLとして判定させる。