Checkpoint Lab — Jenkins LTS Installation, Java 21/25 Runtime Planning, Packages, Containers, and Initial Setup

1. Checkpoint mission

You will perform two installation attempts. Attempt A is intentionally rejected during preflight because its runtime/storage plan does not meet the chapter contract. Attempt B uses the correct Jenkins LTS/Java/runtime/storage design and must survive container replacement.

2. Fixed assumptions and resource names

3. Predict before you execute

Write down your predictions before running commands:

1. If a controller is created without a mounted home and then deleted, will setup state survive? Why?
2. If the same named volume is mounted into a replacement container, which identity changes and which state should remain?
3. What will a Java 17 preflight tell you about current Jenkins LTS compatibility?
4. Which command output will prove the exact pulled image content beyond the tag?

Keep this prediction note; it is part of the evidence packet.

4. Attempt A — reject the plan during preflight

Use a Java 17 container only to demonstrate an incompatible runtime candidate. Do not launch Jenkins on it:

mkdir -p jenkins-ch02-evidence

docker run --rm eclipse-temurin:17-jre java -version 2>&1 | \
  tee jenkins-ch02-evidence/attempt-a-java17.txt

# Also describe the bad storage plan: 'run Jenkins with no /var/jenkins_home mount'.
printf '%s\n' 'REJECTED: Java 17 is unsupported for current Jenkins LTS; ephemeral home would not meet persistence requirement.' \
  > jenkins-ch02-evidence/attempt-a-decision.txt

Expected decision: stop. The Java candidate is incompatible, and the no-volume plan cannot satisfy restart/replacement persistence. A strong operator catches both before creating controller state.

5. Attempt B — prove the supported baseline

docker version > jenkins-ch02-evidence/docker-version.txt

docker pull jenkins/jenkins:2.568.3-jdk21
docker image inspect jenkins/jenkins:2.568.3-jdk21 \
  --format 'Id={{.Id}} RepoDigests={{json .RepoDigests}}' | \
  tee jenkins-ch02-evidence/jenkins-image.txt

docker run --rm jenkins/jenkins:2.568.3-jdk21 java -version 2>&1 | \
  tee jenkins-ch02-evidence/jenkins-java.txt

Verify that the Java output shows major version 21 and that RepoDigests is populated. If either check fails, do not continue blindly.

6. Create the durable home and start Jenkins

docker volume create jenkins-ch02-checkpoint-home

docker run --name jenkins-ch02-checkpoint --detach \
  --publish 127.0.0.1:8080:8080 \
  --volume jenkins-ch02-checkpoint-home:/var/jenkins_home \
  jenkins/jenkins:2.568.3-jdk21

docker inspect jenkins-ch02-checkpoint \
  --format 'Image={{.Image}} User={{.Config.User}} Mounts={{json .Mounts}} Ports={{json .HostConfig.PortBindings}}' | \
  tee jenkins-ch02-evidence/container-inspect.txt

docker logs --timestamps jenkins-ch02-checkpoint 2>&1 | \
  sed -E 's/[A-Za-z0-9]{20,}/[REDACTED-POSSIBLE-SECRET]/g' \
  > jenkins-ch02-evidence/startup-log-redacted.txt

7. Complete local setup, then record the non-secret baseline

1. Read the initial password locally with docker exec jenkins-ch02-checkpoint cat /var/jenkins_home/secrets/initialAdminPassword. Do not redirect it to a file.
2. Open http://127.0.0.1:8080.
3. Install suggested plugins for the training controller.
4. Create a disposable administrator with a unique throwaway password.
5. Record the exact core version from the UI/system information and the installed plugin names/versions. Do not record credential values.

8. Replace the container and prove persistence

First confirm you can sign in and that setup is complete. Then replace only the controller process:

docker stop jenkins-ch02-checkpoint
docker rm jenkins-ch02-checkpoint

docker run --name jenkins-ch02-checkpoint --detach \
  --publish 127.0.0.1:8080:8080 \
  --volume jenkins-ch02-checkpoint-home:/var/jenkins_home \
  jenkins/jenkins:2.568.3-jdk21

docker inspect jenkins-ch02-checkpoint \
  --format 'ContainerId={{.Id}} Image={{.Image}} Mounts={{json .Mounts}}' | \
  tee jenkins-ch02-evidence/recreated-container.txt

Expected: the container ID is different, but Jenkins does not return to the initial setup wizard. Your disposable administrator and plugin baseline remain because the same home volume is attached.

9. Independent verification checklist

• Core: UI reports Jenkins 2.568.3.
• Release line: 2.568.3 appears in the LTS changelog, not merely a local label.
• Java: container reports Java 21.
• Image: evidence includes image ID and resolved RepoDigest.
• Service identity: container configuration/user is recorded; no host-root workaround was introduced.
• Network: host binding is loopback-only on 8080.
• Home: named volume mounts at /var/jenkins_home.
• Persistence: setup/admin/plugin state survives container deletion and replacement.
• Secrets: evidence packet contains no bootstrap/admin password.
• Plugins: actual installed plugin versions are captured separately from the phrase “suggested plugins.”

10. Required evidence packet

11. What this checkpoint does not prove

This lab does not prove production readiness. It does not configure TLS, reverse proxy behavior, enterprise authentication/authorization, backup/restore, external secret management, dynamic agents, plugin governance, monitoring, or disaster recovery. It proves a narrower and valuable foundation: the chosen Jenkins/Java/image baseline is explicit, bootstrap is local, controller state is deliberately persistent, and replacement behavior is observed rather than assumed.

12. Safe teardown

# Verify exact disposable identities first.
docker ps -a --filter name=jenkins-ch02-checkpoint
docker volume ls --filter name=jenkins-ch02-checkpoint-home

# Remove the known disposable controller.
docker stop jenkins-ch02-checkpoint
docker rm jenkins-ch02-checkpoint

# DESTRUCTIVE: removes all persisted Jenkins state for this checkpoint only.
docker volume rm jenkins-ch02-checkpoint-home

# Keep jenkins-ch02-evidence/ if you want the non-secret evidence packet.

13. Summary

• A good installation process rejects incompatible runtime/storage plans before controller startup.
• The successful baseline explicitly records Jenkins LTS, Java, image identity, service/container identity, port binding, persistent home, and plugin inventory.
• Replacing the controller container while keeping the home volume demonstrates process-vs-state separation.
• Secrets are deliberately excluded from evidence; version and topology evidence is retained.
• The next chapter can now study JENKINS_HOME contents and global configuration on a controller whose installation boundary is understood.

Knowledge check

Official references and version notes

• Installing Jenkins — official entry point for supported installation methods and new-installation scope.
• Docker installation — official Jenkins container image, persistent /var/jenkins_home, ports, and setup-wizard workflow.
• Linux installation — current Debian/Ubuntu, Fedora, and RHEL-family package instructions and service management.
• Windows installation — MSI/service-account guidance, Java selection, port configuration, and setup.
• WAR-file installation — standalone Java launch, port selection, and JENKINS_HOME override.
• Java Support Policy — authoritative controller/agent/CLI Java runtime matrix.
• Jenkins LTS changelog — exact LTS release dates, fixes, and tested JDKs.
• Jenkins LTS Upgrade Guide — mandatory reading before upgrades or skipped LTS lines.
• Jenkins Security Advisories — current core/plugin security fixes and affected versions.