DevOpsナレッジハブ
DevOpsナレッジハブ

Jenkinsインスタンスのバックアップと復元方法

Jenkinsのバックアップと復元を習得し、CI/CDパイプラインを保護しましょう。このガイドでは、最も信頼性の高いバックアップ戦略であるファイルシステム方式について、専門家レベルのステップバイステップチュートリアルを提供します。`$JENKINS_HOME` ディレクトリ内の重要なデータ（設定、ジョブ、セキュリティキーなど）を特定してアーカイブする方法を学びますが、大きなビルド成果物は除外します。また、インスタンスを復元するための必須手順（重要なファイル権限の修正を含む）についても説明し、Jenkins環境の迅速かつシームレスな災害復旧を保証します。

39 ビュー

Jenkinsインスタンスのバックアップと復元方法

Jenkinsは、継続的インテグレーションおよび継続的デリバリー（CI/CD）の中心的な自動化ハブとして機能します。ジョブ定義、ユーザー認証情報、プラグイン設定、ビルド履歴などの構成データは、組織にとって重要な投資を意味します。ハードウェア障害、構成エラー、または移行によりこのデータが失われると、開発パイプライン全体が停止する可能性があります。

この包括的なガイドでは、信頼性の高いファイルシステムスナップショット方式に焦点を当て、堅牢なJenkinsバックアップ戦略の不可欠な要素を詳しく説明します。インスタンスを安全にバックアップするための段階的な手順と、それをシームレスに復元するための対応する手順を提供し、ビジネスの継続性と安心を確保します。

コアの理解: $JENKINS_HOME ディレクトリ

すべてのJenkinsインスタンスは、単一のルートディレクトリに依存しており、これは $JENKINS_HOME と呼ばれます。このディレクトリには、すべての構成ファイル、プラグイン、ログ、ジョブデータが含まれています。Jenkinsのバックアップとは、基本的にこのディレクトリの内容をバックアップすることを意味します。

インストール方法（例：Linuxパッケージ、Dockerコンテナ）に応じて、$JENKINS_HOME の場所は通常異なります。

  • Linux（パッケージインストール）: /var/lib/jenkins
  • Docker: ボリュームにマウントされることが多く、例：/var/jenkins_home
  • スタンドアロンJAR: 環境変数で指定されていない限り、Jenkinsプロセスが開始されたディレクトリ。

重要なデータコンポーネントの特定

$JENKINS_HOME ディレクトリ全体をバックアップするのが最も簡単なアプローチですが、ビルド履歴やワークスペースデータが含まれている場合、非常に大きなアーカイブになる可能性があります。迅速かつ効率的な障害復旧バックアップのためには、次のディレクトリとファイルが確実にキャプチャされるようにする必要があります。

コンポーネント $JENKINS_HOME 内のパス 目的
グローバル構成 config.xml Jenkinsルートインスタンスの主要な構成ファイル。
ジョブ定義 jobs/ 構成されたすべてのジョブのサブディレクトリを含み、それぞれが独自の config.xml を持っています。
ユーザーと認証情報 users/ および credentials.xml ユーザーアカウント、セキュリティレルム設定、および保存されたシークレット。
セキュリティキー secrets/ 保存された認証情報などの機密データを復号化するために不可欠な暗号化キー。
プラグインリスト plugins/ インストールされているすべてのプラグインの .hpi ファイルが含まれています。
ノード定義 nodes/ 接続されているすべてのビルドエージェントの構成（定義されている場合）。

方法1: ファイルシステムバックアップ（推奨）

Jenkinsをバックアップする最も信頼性の高い方法は、サービスを一時的に停止している間に、必要なファイルの一貫性のある圧縮アーカイブを作成することです。

ステップ1: Jenkinsサービスの停止

データの整合性を確保し、バックアッププロセス中の部分的なファイル書き込みを防ぐために、Jenkinsプロセスを停止する必要があります。サービスを停止しないと、不完全または破損したバックアップになるリスクがあります。

# systemdを使用するシステムの場合（ほとんどの最新のLinuxディストリビューション）
sudo systemctl stop jenkins

# または、serviceコマンドを使用するシステムの場合
sudo service jenkins stop

ステップ2: バックアップアーカイブの作成

$JENKINS_HOME の親ディレクトリに移動し、tar を使用して圧縮アーカイブを作成します。容量と時間を節約するために、大きなビルドアーティファクトを除外することを強く推奨します。

$JENKINS_HOME が /var/lib/jenkins であると仮定します:

JENKINS_HOME="/var/lib/jenkins"
BACKUP_TARGET="/mnt/backups/jenkins"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
ARCHIVE_NAME="jenkins_backup_${TIMESTAMP}.tar.gz"

# ターゲットディレクトリが存在しない場合は作成
mkdir -p $BACKUP_TARGET

# ビルド履歴とワークスペースを除外してアーカイブを作成
sudo tar -czvf $BACKUP_TARGET/$ARCHIVE_NAME \n    --exclude="${JENKINS_HOME}/workspace" \n    --exclude="${JENKINS_HOME}/caches" \n    --exclude="${JENKINS_HOME}/jobs/*/builds" \n    $JENKINS_HOME

ヒント: ビルド履歴を含める場合

ビルド履歴（jobs/*/builds）の保持が不可欠な場合は、対応する --exclude フラグを削除できます。ただし、アーカイブサイズが数百ギガバイトに達する可能性があることに注意してください。

ステップ3: 検証とオフサイトへの保存

アーカイブが作成されたら、その整合性をテストし、サイト全体にわたる障害から保護するために、すぐに外部の地理的に離れたストレージ（例: S3バケット、ネットワークドライブ）に転送します。

ステップ4: Jenkinsの再起動

sudo systemctl start jenkins

方法2: Jenkinsバックアッププラグインの利用（部分的解決策）

ThinBackupやBackup Pluginのようなプラグインは存在しますが、これらは構成ファイル（config.xml）のみをキャプチャすることが多く、大きなファイルやすべての必要なセキュリティ要素を堅牢に処理できない場合があります。これらは通常、ジョブ構成のバックアップ のみ に適しており、完全で安全な障害復旧戦略のために頼るべきではありません。

Jenkinsインスタンスの復元

復元では、バックアップされたデータをターゲットマシンの $JENKINS_HOME ディレクトリにコピーし、サービスを開始する前にファイルのアクセス許可が正しいことを確認する必要があります。

ステップ1: ターゲット環境の準備

ターゲットシステム（または修復されたシステム）にJenkinsがインストールされていることを確認しますが、サービスは停止したままにしておきます。

sudo systemctl stop jenkins

ステップ2: 既存のJenkinsデータのクリア（オプションですが推奨）

以前Jenkinsをホストしていたマシンに復元する場合、環境をクリーンにするために既存の $JENKINS_HOME の内容をクリアします。

# 'rm -rf' コマンドの使用には注意してください！
sudo rm -rf /var/lib/jenkins/*

ステップ3: バックアップアーカイブの展開

圧縮アーカイブ（jenkins_backup_latest.tar.gz）をターゲットマシンにコピーし、それを $JENKINS_HOME ディレクトリに展開します。-C フラグは展開先のターゲットディレクトリを指定します。

# アーカイブが /tmp にあり、JENKINS_HOME が /var/lib/jenkins であると仮定
sudo tar -xzvf /tmp/jenkins_backup_latest.tar.gz -C /var/lib/

# 注: tarコマンドに親ディレクトリがアーカイブに含まれていた場合は、パスを調整してください。
# 結果として、アーカイブの内容が /var/lib/jenkins の内容を置き換える必要があります

ステップ4: アクセス許可の検証と修正

これは復元後の 最も重要な ステップです。ファイルの所有権が正しくないと、Jenkinsは起動に失敗するか、安全に動作しません。Jenkinsサービスが実行されるユーザーとグループ（通常は jenkins:jenkins）に所有権を再帰的に設定する必要があります。

JENKINS_HOME="/var/lib/jenkins"
JENKINS_USER="jenkins"
JENKINS_GROUP="jenkins"

sudo chown -R $JENKINS_USER:$JENKINS_GROUP $JENKINS_HOME
sudo chmod -R 755 $JENKINS_HOME

ステップ5: Jenkinsの起動と検証

サービスを開始し、ログを監視して起動が成功したことを確認します。

sudo systemctl start jenkins

# 起動ログの監視
sudo tail -f /var/log/jenkins/jenkins.log

起動が成功したら、すべてのジョブ、ユーザー、インストールされたプラグインが存在し、正しく機能していることを検証します。

自動バックアップのベストプラクティス

手動バックアップを超えて、システムツールと外部構成管理を使用して自動化を実装します。

1. Cronジョブの活用

バックアップスクリプト（方法1のステップ1および2）を cron または同様のスケジューラを使用して毎日または夜間に実行するようにスケジュールします。cronジョブが、Jenkinsサービスを停止および開始し、$JENKINS_HOME ディレクトリへの読み取り/書き込みに適したアクセス許可を持つユーザーとして実行されることを確認してください。

2. Configuration as Code (CasC)

Jenkins Configuration as Code (CasC) の採用を検討してください。CasCは、宣言的なYAMLファイルを使用してJenkinsの設定、ジョブ、プラグインを定義します。これらのYAMLファイルを個別のソース管理リポジトリ（Gitなど）に保存することで、構成がポータブルになり、バージョン管理され、コアのバックアップ要件を劇的に簡素化します。

警告: 認証情報の保護

インスタンスを復元する際は、secrets/ ディレクトリが存在し、正しいことを確認してください。Jenkinsが認証情報（APIキーやパスワードなど）の暗号化に使用されたキーを見つけられない場合、これらの認証情報は使用できなくなり、手動で再入力する必要があります。