How to Install Jenkins 2 on Ubuntu 16.04

This is about installing Jenkins 2 on Linux. (the process is similar for Windows installs).

Our Jenkins2 Installation

Before installing Jenkins2 – glance at our Jenkins2 Continuous Integration Server.


What Jenkins is Made Of

The Jenkins Continuous Integration Server
Jenkins is a continuous integration server and needs everything a middleware service needs. It’s a JAVA web application so in theory you can drop a Jenkins WAR file into any application server (like JBoss) and it should work. In practise it is bound to Tomcat but you don’t need to install Tomcat, the Jenkins installer does that seamlessly.


Do I Need Jenkins

Windows7 is so good, many (including yours truly) see no reason to upgrade. If you already use plain Jenkins, you want to know whether to up sticks and migrate. What (good or bad) is in it for you? The key new features are

  1. access controls – to ease its passage into cloud services portfolios
  2. a polished clean comprehensive interface (the good just got better)
  3. a REST API to create build projects, update them, and kick-start them
  4. pipelines – you do know that pipelines are the next big thing

Jenkins2 – One Eye in the Clouds

Why is Jenkins2 so security aware? Its user base is still development teams behind firewalls, so why the heavy-handed access control features?

Jenkins2 is built with one eye in the clouds. You can still install it but Jenkins2 wants cloud providers like AWS (Amazon Web Services) to add it to their middleware services portfolio. So Jenkins2 has a “credentials” feel, even read access requires login, until you configure it otherwise.


The Jenkins2 Server Installation Steps

Its time to install Jenkins2 onto your Linux Debian system (Ubuntu preferred).

What are the pre-install needs? What happens on Step Zero? And what are the steps?

Jenkins2 Pre-Install Needs

Jenkins2 is 100% pure Java so any environment with a JRE (even a watch), should be able to run it. In order for it to build JAVA projects, it needs to find a JDK (Java Development Kit). So Jenkins needs you to

  1. install Java8 (both the JDK and the JRE)
  2. install Maven2 (or other) build tool before or after the install
  3. check that a system port (by default 8080) is available

Aside from Maven, the other popular build tools are SBT( for Scala and Play2 applications ), Gradle and the now outdated, but still popular, ANT.

You do not need to install MySQL – Jenkins uses the file-system to manage its (XML) configuration and build output.

Step Zero

What happens if we just run sudo apt-get install jenkins (as per usual)?

Unfortunately the reply will say

Package jenkins is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'jenkins' has no installation candidate


The 7 Jenkins2 CI Server Install Steps

3 steps are required prior to the ubiquitous sudo apt-get install command. And 3 steps after.

Step 1 = Add Jenkins Apt-Get Repository Key

To add the key run this command.

wget -q -O - | sudo apt-key add -

OK is the solitary (but stoic) reply.

Step 2 = Add Jenkins to the Sources List

To add the list of Jenkins continuous integration server sources to the repository, run this command.

sudo sh -c 'echo deb binary/ > /etc/apt/sources.list.d/jenkins.list'

This time the command returns nothing.

Step 3 = Update Your Local apt-get Repository

sudo apt-get update

You can expect a long list of text lines should come out ending ( after 11 seconds in this case ), with something like this.

Fetched 5,123 kB in 11s (447 kB/s)
Reading package lists... Done

Step 4 = sudo apt-get install jenkins

The command we’ve all been waiting for is here. Install Jenkins2 with

sudo apt-get install jenkins

You will be asked whether you want to continue?

On completion the Jenkins2 service will have been started, ready for the web configuration phase that is now all the rage.

Step 5 = Log into Jenkins on Port 8080

The service should be running on port 8080 so use your domain name (or localhost if installed locally) to access it.


Soon, we will use the Apache web server to route HTTP and HTTPS traffic to Jenkins. This helps us to

  1. use URLs that lack the pesky port tag
  2. receive external port 80 or 443 traffic

An example is the Build Business Websites Jenkins2 Server that uses the simple URL format.

Internet facing websites rarely open up the larger non-standard ports making the Apache redirect mapping priceless.

Step 6 = The Administrator Password

An administrator password is required the minute you connect to Jenkins for the first time on the web. This command retrieves it.

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

Copy and paste it in. Once done, the above file will be deleted so don’t go looking a second time.

Step 7 = The General Jenkins2 Configuration

The web configuration part is straightforward. It asks you to create an administrator account. After a few brief questions – you are in. Lights out, away we go.

How to Upgrade Jenkins

To upgrade Jenkins you need just two commands.

  1. sudo apt-get update
  2. sudo apt-get install jenkins

Your configuration will be maintained although it is a good idea to backup the config.xml files for each job.


Apache as a Reverse Proxy for Jenkins

If Jenkins is part of your toolset, it pays to run it behind Apache.

1. You do not want
2. So change it to

The clutch of tools in the domain all share the “behind Apache” middleware pattern.

Configure Apache as a reverse proxy for Jenkins even on your sandbox and behind firewalls. It is mandatory if Jenkins is internet visible – do not open up port 8080 and do not make others connect with :8080.


Other Jenkins2 Configuration HowTo Pages

Once you are into Jenkins2, you will very likely want to know

  1. How to enable Jenkins2 read access without login
  2. How to install Maven2, or perhaps SBT, or Gradle
  3. How to configure Apache as a reverse proxy for Jenkins
  4. How to redirect Jenkins HTTPS (SSL protocol) traffic
  5. How to setup a Jenkins2 project
  6. Why you need a Jenkins2 pipeline?
  7. How to configure a Jenkins2 pipeline
  8. How to configure Jenkins through an API
  9. How to use the Jenkins2 Rest API to Manage Projects
  10. How to use Jenkins2 slaves
  11. How to monitor Jenkins2 traffic with AWStats
  12. How to install Jenkins2 when Tomcat already exists

Introduction to Jenkins

Jenkins is an enterprise class continuous integration server that runs as a service on Windows and Linux.

Core Use Case – After you create a Jenkins project and configure the SCM and build settings, you are ready to experience the core use case. The core Jenkins use case

  1. polls an SCM like Git or Subversion
  2. checks out a Java or Scala project
  3. builds it using Maven, Ant or SBT
  4. executes the unit tests and
  5. dashboards the build result

You can think of Jenkins as a “job runner”. As well as building software projects it can run shell scripts which is handy for backups, log rotation and such tasks.

You should retire CRON once you have 3 or 4 jobs to run. Jenkins gives you a dashboard, the ability to add plugins, and it displays the output logs in a polished manner.

If you have large mission critical jobs with complex dependency requirements, Jenkins is not for you. Queues, monitors and software like Akka is better suited. However for developers who buy into the Continuous Delivery (and Continuous Integration) concepts, Jenkins is one of the best.

It’s competitors are Hudson (owned by Oracle), Atlassian tools (especially Confluence), Rational Suite tools and Git itself – which provides an end to end software build, integrate, test, quality assure and release pipeline. Jenkins is biting back with a pipeline of its own – but it doesn’t need to – it is the best out there at doing what it does best.

Related Articles


How to Install Jenkins 2.2 on Ubuntu 15.04 and 14.04

Where Does Continuous Integration Sit

Continuous Integration is the at the beginning of the Continuous Delivery pipeline.

The continuous integration process begins with writing and changing software, writing unit tests, running unit tests locally and frequent check-ins into an SCM (source code management) tool.

A continuous integration server then checks-out ALL the software, compiles and builds each software package, and runs the unit tests against each software package.

If all is good, the CI server now integrates a collection of packages (typically JAR files), thus creating an EAR (enterprise archive) or a WAR (web archive) file. It now runs the integration and black box system tests against this amalgam, typically called a release candidate.

Failures at any stage are reported through a dashboard. If the software passes every check, the CI Server makes the package available to a local or central repository.

Continuous Delivery

Continuous Integration ends with the delivery of a release candidate to repository managers such as Nexus. But continuous delivery carries on.

Continuous Delivery encompasses continuous integration and sees the packages through various staging environments, right through to the production systems.


The Core Continuous Integration Concepts

What principles underpin continuous integration and continuous delivery?

The Core Continuous Integration Concepts

What principles underpin continuous integration and continuous delivery?

1. Every checkin is a release candidate.
2. Continous Feedback – fail fast and early.
3. Employ unit, integration and system tests.

The Release Candidate

The agile way subscribes to this notion of release candidate. A check-in adds to a pool that already exists and the sum total is a release candidate.

If a failure is going to happen you want it to happen as early as possible (in the delivery pipeline) and as soon as possible after software artifacts are written.

Continuous Feedback and Automated Tests

A developer uses unit tests to for local feedback. That’s early. On check in and integration – many other bugs make themselves known – so the feedback arrives within half an hour. Bigger integration and system tests are executed at night (hence the now ubiquitous “nightly build”).

Failures disqualify the artefact set (the build) from being released. After the nightly build you have software that has made it through a rough journey. The deployment process itself is tested (further bugs can arise) – also quality assurance can now happen with end users and a QA team.

Continuous Delivery

Instead of a long waterfall process – agile espouses frequent delivery. The earlier you deliver – the earlier you get feedback (whether from tests, deployment, testers, or users). This early feedback reduces waste – developing for 2 weeks without feedback can be horribly wasteful.

The end result is software that is enterprise (perhaps even military) grade. Agile methodologies champion the key principles in order to release high quality software every week and in some cases every single day.

MediaWiki is a must-have for any start-up, any fast-paced project, any documentation effort.

MediaWiki vs WordPress

If you are not sure you need a Wiki – or are undecided as to whether WordPress is better suited to managing your content than MediaWiki, then read the article on when and how to use MediaWiki.

Leave a Reply

Your email address will not be published. Required fields are marked *