Java 11 End of Life in Jenkins: Haven’t You Upgraded Your HA Jenkins Java 11 Server to 17 Yet?

Here’s the process for upgrading your Java 11 High Availability Jenkins server to Java 17 with zero downtime.

First of all, let me explain what a High Availability Jenkins server means. If you’re planning to set up a Jenkins server, you will need to manage all the configurations yourself since these are self-hosted servers.

As you know, Jenkins manages its main directory at the /var/lib/jenkins path. To manage the Jenkins state in real-time, we’re going to mount an EFS on the /var/lib/jenkins directory. You can also mount it to any custom directory if you wish. Let me share a sample diagram related to this architecture. Here, I’m not going to add any deeper network elements like VPCs, subnets, etc., just the most important elements.

In my scenario, Jenkins was running on Java 11, and when I wanted to upgrade to Java 17, I had to consider two key aspects:

1. How to migrate all the data without any loss.
2. How to ensure that the same data is available after the Java 17 migration, given that the Java 11-compatible Jenkins version is unfortunately incompatible with the Java 17 Jenkins version. Therefore, we also need to upgrade the Jenkins version.

The success of this migration largely depends on the EFS storage. I planned to replicate my existing EFS to another EFS by going to the AWS console, selecting the relevant EFS, and navigating to the Replication section as shown below.

Click on the button to create replication and set it to a new EFS. Select the region of your choice as shown below.

Completing this replication will take considerable time based on the EFS storage size; in my case, it took 24 hours.

Note: Once you start the replication, ensure you do not make any changes to your Jenkins server that you plan to upgrade.

After the replication is complete, you should see that both EFS storages have the same capacity levels. Then, you can remove the replication from your existing EFS and make the new EFS independent.

Now that we have completed the prerequisites for this upgrade, we need to spin up a new EC2 server and install Java 17, Jenkins, and other relevant packages.

Let’s see how I plan to execute this migration using the architecture shown below.

Let me explain the above architecture by dividing it into two sides: left and right. As you can see, the left side explains the process before the upgrade, and the right side explains the process after the upgrade.

On the left side, we need to replicate the EFS before the upgrade process. Then, I created a fresh EC2 instance (Amazon Linux 2023) and installed Java 17, Jenkins, and other relevant packages.

Here’s the basic command list I used for that process:

sudo dnf update
sudo dnf install java-17-amazon-corretto -y
java -version
sudo wget -O /etc/yum.repos.d/jenkins.repo \
    https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo dnf install jenkins -y
sudo systemctl enable jenkins

Task 1: Temporarily mount your new EFS to /var/lib/jenkins or any other relevant custom directory.

sudo mount -t efs -o tls fs-xxxxxxxxxxxx:/ efs #update your efs ids and directories accordingly.

Task 2: If it works, let’s mount it permanently using fstab.

sudo vi /etc/fstab #Edit fstab

---------------------

#Put this part on fstab

fs-xxxxxxxxxxxxx:/ /var/lib/jenkins efs tls,_netdev #update with your efs id accordingly.

---------------------

#Save the file :wq!

---------------------

sudo mount -a #Mount permanently

---------------------

df -h #Check whether if it's successfully mount or not.

Task 3: Navigate to the /var/lib/jenkins directory and check if there is a directory called aws-backup-restore-xxxxxxx. If it exists, replace all the items from the aws-backup-restore-xxxxxxx directory to the /var/lib/jenkins directory using the following commands. (This may take considerable time depending on your EFS storage.)

#Dry Run (Optional)
sudo rsync -avh --dry-run /var/lib/jenkins/aws-backup-restore_xxxxxxxxxxxx/ /var/lib/jenkins/

#Actual Sync
sudo rsync -avh /var/lib/jenkins/aws-backup-restore_xxxxxxxxxxxx/ /var/lib/jenkins/

Here’s a breakdown of the rsync options used:

-a: Archive mode, which preserves permissions, timestamps, symbolic links, etc.

-v: Verbose mode, which gives detailed information about what rsync is doing.

-h: Human-readable output.

Task 4: Restart or start the Jenkins service.

sudo systemctl start jenkins 

#or 

sudo systemctl restart jenkins

Task 5: Browse Jenkins and check if all pipelines, user accounts, etc., are intact. Then, go to the Plugin Manager, update all the plugins, and restart Jenkins by clicking the button below.

Task 6 (Optional): Once the restart is complete, you may experience considerable slowness on your new Jenkins server while moving between pipelines. To resolve this, go to Configure System and update the Jenkins URL according to your new IP address and port, then click Save as shown below.

Congratulations! You have successfully upgraded your Jenkins server to Java 17 with zero downtime and without losing any data.

Later, you can stop and terminate your Java 11 Jenkins server and also remove the aws-backup-restore_xxxxxxxxxxxx directory.

If you have any questions, please feel free to drop them in the comments section.