2026年5月28日

Jenkinsのインストールと初期設定方法（Ubuntuへの導入から安全な公開まで）

バックアップ・監視

Jenkins は、Ubuntu などの Linux サーバーに公式の APT リポジトリから入れ、ブラウザの初期セットアップ画面で管理者を作れば使い始められます。ただし、そのままポート 8080 をインターネットに公開するのは危険です。この記事では、Java の準備からインストール、初回ロック解除、プラグインの選び方、Nginx 経由での HTTPS 公開、最初にやっておきたいセキュリティ設定までを順に解説し、安全に運用を始められる状態をつくります。

インストール前に確認すること

Jenkins は Java で動くアプリケーションです。対応する Java のバージョンは Jenkins のバージョンとともに変わり、最近の LTS では Java 17 または Java 21 が求められます（2026年10月現在）。古い手順に従って Java 11 を入れると、新しい Jenkins は起動しません。導入前に公式ドキュメントの Java 要件のページを確認してください。

リリースには、毎週出る「Weekly」と、安定性を重視した「LTS（Long-Term Support）」があります。業務用やサイト運用のビルドサーバーなら、更新頻度が低く検証された LTS を選ぶのが一般的です。

サーバーのスペックは、何をビルドするかで大きく変わります。公式ドキュメントでは小規模なチーム向けに数 GB 以上のメモリと十分なディスクを推奨しています。ビルドの成果物やログはディスクを消費し続けるので、容量には余裕を持たせてください。

Java と Jenkins をインストールする

以下は Ubuntu / Debian 系の例です。コマンドは公式手順をもとにしたもので、署名鍵のファイル名やパッケージ名は更新されることがあるため、実行前に公式のインストールページと照らし合わせてください。

# Java（ここでは OpenJDK 21）
sudo apt-get update
sudo apt-get install -y fontconfig openjdk-21-jre
java -version

# Jenkins LTS リポジトリの署名鍵とリポジトリを登録
sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" \
  | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

# Jenkins 本体
sudo apt-get update
sudo apt-get install -y jenkins
sudo systemctl status jenkins

apt-get update で NO_PUBKEY や署名エラーが出る場合は、登録した鍵が古い、または URL が変わっている可能性があります。エラーを無視するオプションで回避せず、公式ページの最新の鍵に差し替えてください。

インストールが終わると jenkins という systemd サービスが登録され、自動で起動します。データはホームディレクトリ /var/lib/jenkins に保存されます。ジョブ設定、プラグイン、認証情報などがすべてここに入るので、後でバックアップ対象にします。

Docker が使える環境なら、公式イメージ jenkins/jenkins の LTS タグでコンテナとして動かす方法もあります。その場合は /var/jenkins_home をボリュームにして、コンテナを作り直してもデータが残るようにします。

待ち受けアドレスとポートを調整する

既定では全インターフェースのポート 8080 で待ち受けます。リバースプロキシの裏で動かすなら、ローカルホストだけで待ち受けるようにしておくと、ファイアウォールの設定漏れがあっても外部から直接アクセスされません。

sudo systemctl edit jenkins

開いたエディタに次の内容を書きます。

[Service]
Environment="JENKINS_LISTEN_ADDRESS=127.0.0.1"
Environment="JENKINS_PORT=8080"

保存後に sudo systemctl daemon-reload と sudo systemctl restart jenkins で反映し、ss -tlnp | grep 8080 で 127.0.0.1:8080 になっているかを確認します。設定できる環境変数はサービスの unit ファイルにコメントで記載されているので、systemctl cat jenkins で確認できます。古い記事にある /etc/default/jenkins を編集する方法は、systemd に移行した現在のパッケージでは使われていません。

初回のロック解除と管理者の作成

ブラウザで Jenkins にアクセスすると、初期パスワードの入力を求められます。この段階ではまだ管理者が作られていないので、公開前の作業は SSH のポートフォワード（ssh -L 8080:127.0.0.1:8080 user@server）で手元から接続して行うと安全です。

初期パスワードはサーバー上のファイルに書かれています。

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

ロック解除の後は、プラグインの導入方法を選ぶ画面になります。推奨プラグインをまとめて入れる選択肢と、自分で選ぶ選択肢があります（画面の表記はバージョンで変わります）。初めてなら推奨セットで問題ありませんが、プラグインは数が増えるほど更新や脆弱性対応の手間が増えます。使わないものは後で無効化・削除し、必要なものだけ残す方針にしておくと運用が楽になります。

続いて最初の管理者ユーザーを作成します。admin のような推測されやすい名前は避け、長く一意なパスワードを設定してください。最後に Jenkins の URL を入力する画面があります。ここには後で公開する HTTPS の URL（例: https://jenkins.example.com/）を設定します。この URL はメール通知のリンクなどに使われ、間違っているとリンク切れの原因になります。

Nginx で HTTPS 化して公開する

Jenkins 自体に HTTPS を設定することもできますが、Nginx をリバースプロキシにして TLS を終端させる構成が扱いやすく、証明書の更新も Let's Encrypt の Certbot に任せられます。

server {
    listen 443 ssl;
    server_name jenkins.example.com;

    ssl_certificate     /etc/letsencrypt/live/jenkins.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/jenkins.example.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_request_buffering off;
    }
}

X-Forwarded-Proto などのヘッダーが欠けていると、Jenkins が自分を HTTP で動いていると判断し、リダイレクトのループや「リバースプロキシの設定が壊れている」という趣旨の警告が管理画面に表示されます。警告が出たら、まずヘッダーの設定と、初期設定で入力した Jenkins の URL が一致しているかを確認してください。公式ドキュメントには WebSocket 対応を含む Nginx の設定例があるので、エージェントを WebSocket で接続する場合はそちらを参照します。

ファイアウォール（ufw など）では 80 / 443 と SSH だけを開け、8080 は外部に開けないようにします。

最初にやっておきたいセキュリティ設定

Jenkins はビルドのためにソースコードやデプロイ用の鍵を扱うため、侵入されたときの影響が大きいサーバーです。初期設定の直後に次の点を見直してください。

権限の設定: 既定の「ログインしたユーザーは何でもできる」に近い状態のままにせず、Matrix Authorization Strategy プラグインなどで、ユーザーごとに閲覧・ビルド・管理の権限を分けます。匿名ユーザーには閲覧も許可しない設定が基本です。
ユーザー登録: 管理画面から誰でもアカウントを作れる設定になっていないか確認します。
コントローラーでビルドしない: 公式ドキュメントは、Jenkins 本体（コントローラー）の組み込みノードの実行数を 0 にし、ビルドは別のエージェントで実行する構成を推奨しています。ビルドスクリプトが Jenkins のホームディレクトリに触れられる状態を避けるためです。
認証情報の管理: SSH 鍵や API トークンは Credentials 機能に登録し、パイプラインからは ID で参照します。Jenkinsfile やジョブ設定に直接書かないようにします。
更新: Jenkins 本体とプラグインのセキュリティアドバイザリは定期的に公開されます。管理画面に表示される警告を放置せず、LTS の更新とプラグインの更新を定期作業に組み込みます。更新前には /var/lib/jenkins のバックアップを取っておきます。

動作確認のための最初のパイプライン

設定が終わったら、パイプライン型のジョブを 1 つ作り、動作を確認します。リポジトリに Jenkinsfile を置く方法が、設定をコードで管理できるのでおすすめです。

pipeline {
    agent any
    stages {
        stage('PHP Lint') {
            steps {
                sh 'find . -name "*.php" -not -path "./vendor/*" -print0 | xargs -0 -n1 php -l'
            }
        }
    }
}

agent any は利用可能なエージェントのどれかで実行する指定です。組み込みノードの実行数を 0 にしている場合、エージェントを 1 台以上接続するまでジョブは待機状態のままになります。「ビルドが始まらない」ときは、まずエージェントの接続状態を確認してください。また、php コマンドはエージェント側にインストールされている必要があります。

まとめ

Jenkins の LTS を公式 APT リポジトリから入れ、対応する Java のバージョンを事前に確認します。
systemctl edit jenkins で待ち受けを 127.0.0.1 に限定し、8080 を外部に公開しないようにします。
初期パスワードは /var/lib/jenkins/secrets/initialAdminPassword にあり、初期設定は SSH のポートフォワード経由で行うと安全です。
Nginx で HTTPS を終端し、X-Forwarded-Proto などのヘッダーと Jenkins の URL 設定をそろえます。
権限の分離、コントローラーでビルドしない構成、認証情報の管理、定期的な更新とバックアップを最初に整えておきます。