Installing Jenkins LTS

Overview

Install Jenkins Long-Term Support (LTS) for labs using Docker Compose, complete the initial setup wizard, and know what lives under JENKINS_HOME.

Package and WAR installs exist for bare metal and virtual machines; this course standardises on the official jenkins/jenkins:lts image so every learner shares the same controller baseline. You will create an admin user, set the Jenkins URL, and install the suggested plugin set once — then keep the volume for later modules.

This is a core tutorial in Module 2 · Installing Jenkins LTS of the REBASH Academy Jenkins for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.

Prerequisites

• Completed prior modules in this track where linked in frontmatter
• Git and Docker for lab workflows
• Running Jenkins LTS from Installing Jenkins LTS when a live controller is required

Learning Objectives

By the end of this tutorial, you will be able to:

• Bring up Jenkins LTS with Docker Compose and a persistent volume
• Complete the setup wizard (unlock, plugins, admin, URL)
• Locate and explain JENKINS_HOME
• Stop and restart the controller without losing configuration

Architecture

This topic’s control points and relationships are shown below.

Theory

What it is

Jenkins publishes LTS and weekly lines. Production controllers should track LTS. The official Docker image jenkins/jenkins:lts runs the controller process; you map port 8080 (and optionally 50000 for inbound agents) and mount a volume at /var/jenkins_home — that directory is JENKINS_HOME.

First boot prints an initialAdminPassword. The setup wizard unlocks Jenkins, offers Install suggested plugins, creates the first admin user, and asks for the instance URL. Alternatives (Debian/RPM packages, generic WAR + Java) follow the same wizard concepts; Compose is the REBASH lab default.

Why it matters

A disposable container without a volume teaches nothing about upgrades: all jobs vanish on recreate. Persisting JENKINS_HOME mirrors how platform teams backup, restore, and migrate controllers. Pinning the LTS tag (or digest) prevents surprise major jumps during a casual docker compose pull.

How it works

1. Write a Compose file with image, ports, and volume.
2. Start the stack; read the unlock password from logs or the volume file.
3. Open http://localhost:8080, unlock, install suggested plugins, create admin.
4. Confirm Manage Jenkins → System Information shows a sensible home path.
5. docker compose down then up -d — configuration and jobs remain.

Official install guides cover packages and WAR; see Installing Jenkins.

Key concepts and comparisons

Method	When to use
Docker Compose LTS	Labs and many self-hosted starts
Package (deb/rpm)	Dedicated VMs with OS lifecycle
WAR + JDK	Custom servlet hosting (advanced)

Path / item	Role
/var/jenkins_home	JENKINS_HOME in the container
secrets/initialAdminPassword	First unlock only
Plugin Manager	Adds features after wizard

Common pitfalls

• Exposing 8080 on the public internet without TLS and auth hardening.
• Using latest instead of lts or a pinned LTS minor tag.
• Deleting the volume thinking “containers are ephemeral” — you delete the controller state.
• Skipping suggested plugins then wondering why Pipeline and Git are missing.

Hands-on Lab

Create a workspace for this tutorial.

mkdir -p ~/rebash-jenkins/module-02 && cd ~/rebash-jenkins/module-02

Focus: bring up Jenkins LTS with Compose and prove JENKINS_HOME persists

Step 1 – Primary exercise

cat > docker-compose.yml << 'EOF'
services:
  jenkins:
    image: jenkins/jenkins:lts
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
    restart: unless-stopped
volumes:
  jenkins_home:
EOF
docker compose up -d
sleep 5
docker compose exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Complete the setup wizard in the browser at http://localhost:8080 (unlock → suggested plugins → admin user → Jenkins URL).

Step 2 – Prove persistence

docker compose exec jenkins ls /var/jenkins_home | head
curl -sf -o /dev/null -w "%{http_code}\n" http://localhost:8080/login

Final cleanup

# Keep ~/rebash-jenkins/ for later tutorials; stop Compose only if you are done with the controller
# docker compose -f ~/rebash-jenkins/module-02/docker-compose.yml down   # optional; omit -v to keep JENKINS_HOME

Validation

• Lab commands run under ~/rebash-jenkins/module-02/
• You can explain each Theory section in your own words
• You used current Jenkins LTS / Pipeline practices where they apply
• You can describe one production failure mode for this topic

Code Walkthrough

Production practice for Installing Jenkins LTS always combines:

1. Inspect before you change (status, plan, logs, dry-run)
2. Prefer reversible, documented changes (Git, Jenkinsfile, JCasC)
3. Capture evidence (console logs, plan artefacts) for handovers
4. Prefer current LTS and supported plugins over legacy shortcuts
5. Least privilege — escalate credentials only when required

Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.

Security Considerations

• Treat Jenkins credentials and cloud tokens as privileged — never commit them
• Keep builds off the built-in node; isolate untrusted pull requests
• Prefer short-lived auth (OIDC-style patterns, scoped RBAC) over long-lived keys
• Validate blast radius before apply/deploy/delete operations
• Collect audit logs; limit who can administer the controller

Common Mistakes

Publishing Jenkins on 0.0.0.0 without a reverse proxy

Use localhost for labs; production needs TLS termination and network controls.

Losing the volume

Never docker compose down -v unless you intend to wipe JENKINS_HOME.

Leaving the initial admin password in shared logs

Rotate after wizard; do not paste unlock secrets into tickets.

Best Practices

• Encode Installing Jenkins LTS changes as code and review them in pull requests
• Prefer Jenkins LTS and pinned agent/tool versions
• Keep builds off the controller; use labelled agents
• Least privilege for credentials and cluster/cloud access
• Destroy or stop lab resources; keep ~/rebash-jenkins/ notes for the track

Troubleshooting

Symptom	Likely cause	Fix
Job stuck in queue	No matching agent/label or executors busy	Check nodes, labels, and executor counts
Checkout / SCM failure	Credentials, URL, or permissions	Verify credential ID and repository access
Pipeline CPS / script error	Syntax, sandbox, or library mismatch	Read error line; validate Jenkinsfile; pin library version
Plugin / UI broken after update	Incompatible plugin set	Restore backup; disable suspect plugin on test controller
Disk full on agent/controller	Workspaces or old builds	Clean workspaces; trim build retention

Summary

Installing Jenkins LTS is essential for Cloud and DevOps engineers operating Jenkins. Practise the lab until the inspection and change path is muscle memory, then continue the track.

Interview Questions

1. What is JENKINS_HOME and why must it be persisted?
2. How do you unlock a fresh Jenkins controller?
3. Why pin jenkins/jenkins:lts instead of latest?
4. Which ports does a typical Docker Jenkins expose and why?
5. What does the setup wizard configure beyond plugins?

Sample answer — question 1

JENKINS_HOME holds jobs, plugins, credentials metadata, and build history. Without a volume or disk, every container recreate is a factory reset.

Sample answer — question 3

latest can jump major lines unexpectedly. LTS (or a specific LTS tag/digest) keeps upgrades intentional and testable.

Related Tutorials

• Course overview
• Introduction to Jenkins and CI/CD
• Using Jenkins — Jobs, Views, and Folders

References

• Installing Jenkins
• Docker install
• Jenkins LTS download