【入門編】大規模環境のJenkins運用者が陥る「ディスク肥大化問題」を解決するログローテーションと古いビルドの自動アーカイブ戦略 – バージョン管理・CI/CD活用バイブル

こんにちは!現場のインフラや自動化と日々格闘している先輩エンジニアです。

今回は、多くの開発チームがJenkinsの運用歴が長くなるにつれて必ず直面する、「あれ、気づいたらサーバーのディスク容量がパンパンになっている……!」という悪夢の解決策についてお話しします。

「ビルドが急に失敗するようになった」「Jenkinsの動作がやけにもっさりする」。その原因のほとんどは、過去のビルド履歴や成果物(アーティファクト)がサーバーのストレージを無慈悲に圧迫していることによるものです。

これをマスターすれば、ディスク容量の不安から解放され、Jenkinsサーバーを常に軽快に保つことができるようになりますよ。さあ、一緒にその具体的なノウハウを見ていきましょう!

—

そもそも「Jenkins」って何をするもの?(超基礎)

初めてJenkinsに触れる方のために、その役割をサクッと整理しておきましょう。

Jenkinsは、いわば「あなたのチーム専属の優秀なロボット作業員」です。
人が手動で行っていた「ソースコードのコンパイル」「テストの実行」「本番サーバーへのデプロイ」といった退屈でミスしやすい一連の作業(CI/CDパイプライン)を、コードがプッシュされたトリガーノック一つで自動実行してくれます。

最速のインストールとHelloWorld(動作確認)

まずは手元でJenkinsを動かしてみましょう。一番簡単なのはDockerを使う方法です。以下のコマンドをターミナルに打ち込んでみてください。

JenkinsのLTS(長期サポート)版をDockerで起動する
docker run -d \
–name jenkins-server \
-p 8080:8080 -p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
jenkins/jenkins:lts

起動したらブラウザで `http://localhost:8080` にアクセスします。
初回起動時にパスワードを聞かれるので、以下のコマンドでコンテナ内から取得して入力してください。

docker exec jenkins-server cat /var/jenkins_home/secrets/initialAdminPassword

画面の指示に従って「推奨プラグインのインストール」を完了させたら、いよいよ最初のジョブ(HelloWorld)を作ります。

1. 左メニューの 「新規ジョブ作成」 をクリック。
2. ジョブ名に `hello-world-job` と入力し、「フリースタイル・プロジェクトのビルド」 を選択してOK。
3. ジョブの設定画面の下の方にある 「ビルド」 セクションへ移動。
4. 「シェルの実行」 を追加し、以下のコマンドを入力します。

echo “====================================”
echo ” Hello, Jenkins! 自动化の世界へようこそ!”
echo “====================================”

5. 「保存」を押した後、左メニューの 「ビルド実行」 をクリック!
6. 左下の「ビルド履歴」から最新の番号をクリックし、「コンソール出力」 を覗いてみてください。

無事にメッセージが表示されましたか?おめでとうございます。これがJenkinsの基本の「Hello World」です。

—

大規模環境の罠:なぜJenkinsのディスクは爆発するのか?

先ほど作ったジョブ、実は動かすたびに「ビルドの歴史(ログ、成果物、メタデータ)」がすべてサーバー内の `/var/jenkins_home/jobs/hello-world-job/builds/` というディレクトリに保存されていきます。

小規模なうちは問題ありませんが、数十二〜数百のジョブが毎日何十回も動く大規模環境になると、このディレクトリが数100GB、下手をすると数TBに膨れ上がります。

ここから先は、この「ディスク肥大化問題」を根本から解決する3つの戦略を解説します。

—

戦略1:ビルド履歴の「保持ポリシー」を最適化する

まずは、Jenkinsがデフォルトで持っている機能を使って、「古い不要なゴミを自動で掃除するルール」を徹底的に設定します。

すべてのジョブで手動設定するのは不可能なため、「Pipeline (Jenkinsfile)」 を使うか、「Global Configuration」 またはジョブテンプレートでポリシーを強制します。

例えば、Declarative Pipelineを使う場合は、以下のように `options` ブロックで保持数を明示的に絞り込みます。

pipeline {
agent any
options {
// 成功したビルドも含めて、最新の10個しか残さない!
buildDiscarder(logRotator(numToKeepStr: ’10’, artifactNumToKeepStr: ‘5’))
}
stages {
stage(‘Build’) {
steps {
echo “Building the application…”
}
}
}
}

  • `numToKeepStr: ’10’`: 履歴を最新10件までにする。
  • `artifactNumToKeepStr: ‘5’`: 成果物はさらに厳しく、最新5件だけ残す。

これだけでも、野放図に肥大化するのを劇的に防げます。

—

戦略2:重い成果物は「S3や外部ストレージ」へ自動転送する

ビルド成果物(jarファイル、zipファイル、Dockerイメージなど)をJenkinsのローカルディスクにいつまでも置いておくのはアンチパターンです。

ビルドが成功した瞬間に、AWS S3やGoogle Cloud Storageなどのオブジェクトストレージへアップロードし、Jenkins本体からは速やかに削除するのがプロの作法です。

Pipeline内でAWS CLIを使ってS3に転送する例を見てみましょう。

pipeline {
agent any
stages {
stage(‘Build & Archive’) {
steps {
// 何らかのビルド処理(例: jarの生成)
sh ‘echo “compiled binary” > app.jar’

// AWS S3へ成果物を転送(事前にJenkinsにAWS認証情報が設定されている前提)
sh ‘aws s3 cp app.jar s3://my-company-jenkins-artifacts/releases/${BUILD_NUMBER}/app.jar’
}
}
}
post {
always {
// ローカルに残った大きな成果物は潔く削除(ディスク節約!)
cleanWs()
}
}
}

`cleanWs()`(Workspace Cleanup Plugin)を `post` セクションに挟むことで、ビルドが終わった瞬間にワークスペースが綺麗に掃除されます。

—

戦略3:cronと連携した「定期メンテナンススクリプト」の実装

どれだけ気をつけても、プラグインのバグや孤立したジョブによって、ゴミデータは少しずつ溜まっていきます。最終防衛ラインとして、OS側の `cron` と連携した自動クリーンアップスクリプトを導入しましょう。

以下は、Jenkinsのホームディレクトリを監視し、「30日以上アクセスがない古いビルドフォルダ」を根こそぎ削除する安全なBashスクリプトです。

!/bin/bash
/opt/jenkins/scripts/purge_old_builds.sh
意図しない削除を防ぐため、実行時は慎重にテストしてください

JENKINS_HOME=”/var/jenkins_home”
JOBS_DIR=”${JENKINS_HOME}/jobs”

echo “=== Jenkins ログクリーンアップ開始: $(date) ===”

各ジョブの builds ディレクトリを対象に、30日以上変更のないビルドフォルダを削除
※注意: Jenkinsが起動中にこれをやると整合性が崩れることがあるため、
理想的には Jenkins CLI経由で安全に削除するか、停止深夜帯に実行します。

find “${JOBS_DIR}” -type d -path “/builds/” -mtime +30 -exec rm -rf {} +

echo “=== 掃除完了: $(date) ===”

これをホストOSのcrontabに登録し、毎週日曜日の深夜3時に実行するように設定します。

crontab -e で設定する例
0 3 0 /bin/bash /opt/jenkins/scripts/purge_old_builds.sh > /var/log/jenkins_cleanup.log 2>&1

※注意点: データベースやインデックスの整合性を保つため、大規模環境では直接 `rm` するよりも、Jenkins公式の「Jenkins CLI」や、GroovyスクリプトをJenkinsのスクリプトコンソール経由で実行して安全に削除する方式を推奨します。

—

まとめ:快適なCI/CDライフは「引き算の美学」から

今回は、大規模Jenkins運用における永遠の課題である「ディスク肥大化問題」に対して、以下の3つのアプローチを解説しました。

1. 保持ポリシー(Log Rotator)の徹底: 残す数を最初から絞る。
2. 外部ストレージへのオフロード: 成果物はS3等へ逃がし、ローカルは `cleanWs()` で常にクリーンに保つ。
3. 定期メンテナンスの自動化: cronとスクリプトでゾンビデータを許さない。

自動化ツールは「いかに楽をするか」だけでなく、「いかに健全な状態を維持し続けるか」という運用設計(Ops)の視点が不可欠です。

ディスクがパンパンになって深夜に呼び出される悲劇を避けるために、ぜひ今日の環境から取り入れてみてください。あなたの毎日の開発ライフが、より快適でスピーディーになることを応援しています!

タイトルとURLをコピーしました