【入門編】Jenkinsで生成されたアーティファクトをS3へ自動同期：ライフサイクルポリシーを活用した低コスト保管術 – バージョン管理・CI/CD活用バイブル

こんにちは！現場のインフラや自動化に日々頭を悩ませているあなたへ。
今回は、多くの開発現場で必ずと言っていいほどぶつかる壁、「Jenkinsサーバーのディスク容量圧迫問題」をスマートに、そして圧倒的な低コストで解決する知見をシェアします。

「ビルドのたびに増える成果物（Artifacts）で、気づけばJenkinsのディスクがパンパン……」
「古いビルドを手動で消すのも限界だし、そもそも消し忘れてサーバーが落ちたことがある……」

これを読んでいるあなたも、そんな冷や汗をかいた経験があるのではないでしょうか。

今回は、Jenkinsで生成された大切なビルド成果物をAWS S3へ自動転送するパイプラインの構築と、S3の「ライフサイクルポリシー」を組み合わせた、ディスク管理から完全に解放される極限のコストカット術を優しく紐解いていきます。

これをマスターすれば、あなたのJenkinsサーバーは常にクリーンな状態を保ち、ストレージ費用も最小限に抑えられるようになりますよ。一緒に見ていきましょう！

—

1. なぜJenkinsの成果物はS3へ逃がすべきなのか？

まず、私たちが向かうべきゴールを共有させてください。

Jenkinsはデフォルトの設定のままだと、ビルド成果物をローカルのディスク（`/var/lib/jenkins/jobs/…` など）に保存し続けます。これが原因で、以下のようなトラブルが頻発します。

ディスク枯渇による突然のビルド失敗
サーバーのバックアップサイズが肥大化し、リストアに時間がかかる
不要なデータのために、高いローカルストレージ（SSDなど）の容量を払い続ける

これを「AWS S3」という無限にスケールする安価なオブジェクトストレージに逃がし、古いものはS3側で自動的に消去（ライフサイクル管理）させます。
Jenkinsは「ビルドしてS3に放り込む場所」、S3は「安全かつ安価な長期保管庫」と役割をスパッと分けるのが、モダンなCI/CDの鉄則です。

—

2. 全体像の把握：今回作る仕組み

やることは非常にシンプルです。

1. Jenkinsでのビルド: ソースコードをコンパイルし、成果物（例: `app.zip`）を作る。
2. AWS CLIでのS3転送: Jenkinsのパイプライン内からAWS CLIを叩き、生成物をS3バケットへアップロードする。
3. S3ライフサイクルポリシー: 「30日経ったファイルは自動削除」「90日経ったら安いストレージクラスへ移行」といったルールをAWS側にお任せする。

それでは、具体的な手順をステップ・バイ・ステップで進めていきましょう。

—

3. ステップ1：AWS側の準備（S3バケットとIAM設定）

まずは成果物を迎え撃つAWS側の準備です。

① S3バケットの作成

AWSマネジメントコンソールから、適当な名前のS3バケットを作成します。

バケット名例: `my-company-jenkins-artifacts-bucket`
リージョン: 開発チームが近い場所（例: `ap-northeast-1`）

② 権限（IAM）の設定

JenkinsサーバーからこのS3バケットにアクセスするための認証情報を用意します。
セキュリティのベストプラクティスとして、「特定のバケットへのPut（アップロード）権限のみを持つIAMユーザー（またはIAMロール）」を作成してください。

付与するIAMポリシーの最小権限の例はこちらです。

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:PutObject”,
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”: [
“arn:aws:s3:::my-company-jenkins-artifacts-bucket”,
“arn:aws:s3:::my-company-jenkins-artifacts-bucket/”
]
}
]
}

作成したアクセスキー（`AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY`）は、Jenkinsの「認証情報（Credentials）」に登録しておきましょう（IDは `aws-s3-credentials` などにしておくと後々ラクです）。

—

4. ステップ2：Jenkinsサーバーの環境準備

次に、JenkinsがAWSと会話できるようにします。Jenkinsが稼働しているOS（通常はLinuxが多いでしょう）に、AWS CLI（v2）がインストールされている必要があります。

Jenkinsのマスター（またはエージェント）の端末にSSH等でログインし、以下を実行してインストールを確認してください。

aws –version
aws-cli/2.x.x から始まるバージョンが表示されればOKです

もし入っていなければ、公式ドキュメントに従ってサクッとインストールしておきましょう。

—

5. ステップ3：実践！S3同期パイプライン（Jenkinsfile）の構築

さあ、ここからが本番です。モダンな開発に欠かせない「Declarative Pipeline（Jenkinsfile）」を使って、ビルドからS3への自動同期までをコード化します。

以下の `Jenkinsfile` をあなたのリポジトリのルートに配置してください。

pipeline {
agent any

// ステップ間で共有する環境変数
environment {
AWS_CREDENTIALS_ID = ‘aws-s3-credentials’ // Jenkinsに登録した認証情報のID
S3_BUCKET = ‘s3://my-company-jenkins-artifacts-bucket’
BUILD_NAME = “build-${env.BUILD_NUMBER}”
}

stages {
// 1. ビルドステージ（例として適当な成果物ファイルを作る）
stage(‘Build’) {
steps {
echo ‘ビルドを実行しています…’
sh ”’
# ダミーの成果物ディレクトリとファイルを作成
mkdir -p dist
echo “Hello Jenkins Artifacts – Build #${BUILD_NUMBER}” > dist/app.zip
”’
}
}

// 2. S3への転送ステージ
stage(‘Upload to S3’) {
steps {
echo ‘AWS S3へ成果物を同期しています…’

// JenkinsのwithCredentialsブロックで安全にAWS認証情報を環境変数にロード
withCredentials([aws(credentialsId: “${AWS_CREDENTIALS_ID}”,
variable: ‘AWS’)]) {
sh ”’
# AWS CLIを使用して、ビルド成果物をS3のビルド番号別フォルダへ転送
# –deleteオプションを使うと同期先の整合性が保てますが、今回はシンプルにアップロード
aws s3 cp dist/ ${S3_BUCKET}/${JOB_NAME}/${BUILD_NAME}/ –recursive

echo “S3へのアップロードが完了しました: ${S3_BUCKET}/${JOB_NAME}/${BUILD_NAME}/”
”’
}
}
}
}

// 3. クリーンアップ処理
post {
always {
echo ‘ワークスペースをクリーンアップします…’
cleanWs() // Jenkinsサーバー上のローカルファイルを綺麗に掃除
}
success {
echo ‘パイプラインが成功裏に完了しました！’
}
failure {
echo ‘パイプラインが失敗しました…’
}
}
}

このパイプラインの美しいポイント

`withCredentials` の活用: パスワードやキーをログに露出させず、安全にAWS CLIに渡しています。
ジョブ名とビルド番号の階層化: `s3://bucket/job_name/build-123/` のように整理して保存するため、後から「どのビルドの成果物か」が一目瞭然です。
`post { always { cleanWs() } }`: これにより、ビルドが終わったらJenkinsサーバー上のローカルファイルは速やかに削除され、ディスク圧迫を防ぎます。

—

6. ステップ4：ライフサイクルポリシーで「究極の放置プレイ」を実現する

S3にファイルを送り込めるようになりましたが、これだけでは「無限にS3の容量を食いつぶす未来」が待っています。ここでAWS S3の真骨頂、「ライフサイクルポリシー」を適用しましょう。

マネジメントコンソールから、先ほど作ったS3バケットの「管理（Management）」タブを開き、「ライフサイクルルールを作成（Create lifecycle rule）」をクリックします。

おすすめの設定値はこちらです：

1. ルール名: `delete-old-jenkins-artifacts`
2. ルールのスコープ: バケット全体、または特定のプレフィックス（例: 開発環境の成果物だけ短くするなど）を指定。
3. ライフサイクルルールの移行アクション:

古いバージョンの削除 や オブジェクトの有効期限切れ（Expiration） を設定します。
例: 「オブジェクト作成後、30日経過したら自動的に削除する」

たったこれだけの設定で、「古いビルド成果物は、エンジニアが何もしなくても勝手に消えていく世界」が完成します。もう夜中にディスク容量のアラートで叩き起こされることはありません！

—

まとめ

今回は、Jenkinsのビルド成果物でサーバーのディスクが悲鳴を上げる問題を解決すべく、以下の内容を駆け足で見てきました。

Jenkinsサーバー内に成果物を溜め込むリスクと、S3へ退避させる設計思想
最小限の権限で安全に連携するIAMとAWS CLIのセットアップ
`Jenkinsfile` を用いたスマートなアップロードと、ローカルの自動クリーンアップ
S3ライフサイクルポリシーによる、完全自動のコスト＆容量最適化

この構成を取り入れるだけで、インフラ管理のストレスが驚くほど軽減され、本来の開発業務に集中できるようになります。

「これをマスターすれば、毎日の作業が劇的に楽になりますよ」。
ぜひ、あなたのプロジェクトのJenkinsにも導入してみてくださいね。それでは、快適なCI/CDライフを！