Tools for Deployment Pipeline
In order to automate the various stages of your deployment pipeline, you will need
multiple tools. For example:
A version control system such as Git to store your source code.
A Continuous Integration (CI) tool such as Jenkins to run automated
builds.
Test frameworks such as xUnit, Selenium, etc., to run various test
suites.
A binary repository such as Artifactory to store build artifacts.
Configuration management tools such as Ansible.
A single dashboard to make the progress visible to everyone.
Frequent feedback in the form of emails, or Slack notifications.
And that’s not all. You will also need a single tool that can bring all these tools together
to achieve CI/CD goals which is to automate software delivery.
Download jenkins
Using this method, Jenkins runs as a standalone application in its own process with its
embedded Java servlet container, Jetty. This standalone application can be downloaded
as a Java WAR (Web Application Archive) file with .war extension. This WAR file can run
on any operating system, Linux, Windows, Mac OS, etc.
Here are the steps to launch Jenkins as a standalone war:
Download the [Link] file from the Jenkins download and
deployment.
Launch a terminal window, and run the following command:
java -jar [Link]
By default, Jenkins uses port 8080. Your Jenkins application will be available at
[Link] IP Address>:8080. You can pass additional JVM arguments by
specifying JENKINS_OPTS and JAVA_OPTS to the Java call as shown below:
java ${JAVA_OPTS} -jar [Link] ${JENKINS_OPTS}
Here is an example of using startup flags:
java -[Link]=[Link] -jar [Link] \
--httpPort=8083 --prefix=/ci --httpListenAddress=[Link]
In this example:
setting the Java system property (JAVA_OPTS) -
[Link]=[Link] will change the
default footer on the Jenkins UI to [Link]
--httpPort, --prefix, and --httpListenAddress are the
flags provided as JENKINS_OPTS
--httpPort=8083 will set the Jenkins port to 8083 instead of
the default 8080
--prefix=/ci will add a prefix to the end of the Jenkins URL
--httpListenAddress=[Link] binds Jenkins to the IP
address.
Finally, a Jenkins service launched by above command will be reachable
only on [Link]
Installation Channels: Linux
Package Managers
Linux package managers provide a stable and automated way to install, and manage a
variety of programs. You can use Linux package managers, such as RPM, DEB,
OpenSUSE, etc., to install Jenkins.
The standalone WAR file ([Link]) still forms the basis for the package manager
installation. However, it has some added benefits such as automatic creation of Jenkins
user, start-up scripts, log rotation, etc.
Here is an example of how you can install Jenkins LTS (Long Term Support) on Ubuntu
using the APT package manager. You will need to import the GPG key for the APT repo,
add the repo to the list of sources, update the package index, and install.
Import the GPG key for Jenkins repo
curl -fsSL [Link] | sudo tee \
/usr/share/keyrings/[Link] > /dev/null
# Add the repo to the list of sources
echo deb [signed-by=/usr/share/keyrings/[Link]] \
[Link] binary/ | sudo tee \
/etc/apt/[Link].d/[Link] > /dev/null
#Update package index
sudo apt-get update
#Install Jenkins
sudo apt-get install jenkins
You can start, stop, and check the status of Jenkins by running the systemctl command:
systemctl start|stop|status jenkins
Note that a Jenkins settings file is created at /etc/default/jenkins. This is where you
will modify many of the Java and Jenkins options. For example, if you want to change the
Jenkins port from 8080 to 8083, this is where you would make the change.
Few other things to note are the locations of Jenkins home directory, startup scripts, and
log file.
The startup script is located at /etc/init.d/jenkins.
By default, Jenkins home directory is set to /var/lib/jenkins, and the log file is located
under /var/log/jenkins. These can be changed in the Jenkins settings file to a location
of your preference.
Installation Channels:
Application Containers
Since Jenkins is distributed as an ordinary WAR file, it is easy to deploy it on any standard
Java application server such as Tomcat, Jetty, or GlassFish. Running Jenkins on an
application server is arguably more complicated to set up and maintain. You also lose
certain nice administration features such as the ability to upgrade Jenkins or restart the
server directly from within Jenkins. On the other hand, your system administrators might
be relieved from the overhead of managing multiple servers.
Installation Channels: Docker
Container
In order to run Jenkins as a container, you first need to install Docker on your operating
system. Visit Docker website and click the Docker Community Edition box which is
suitable for your operating system or cloud service. Follow installation instructions
provided on the Docker website.
The next step is to download the Jenkins Docker image, either LTS or weekly. Follow the
instructions provided on jenkinsci/docker GitHub to launch as a container.
Application container install is a two step process:
1. Copy [Link] to webapps directory
2. Restart application web container
Installation Channels:
Kubernetes
To run Jenkins in Kubernetes, you can make use of Helm charts. Helm is the package
manager used to find, share and use software built for Kubernetes. You can find the
official Helm chart for Jenkins on GitHub.
You are now ready to access Jenkins home page at http:<YOUR IP ADDRESS>:<PORT>.
Dashboard
Dashboard Sections: All View for
Jobs
Dashboard Sections: Monitoring
Builds
What Exactly Are Plugins?
Jenkins uses plugins to provide much of the user-needed functionality. Many Jenkins
features such as integrating source code management tools, build tools, reporting tools,
code coverage, static analysis, notifications are all implemented as plugins.
Essentially, all the Jenkins plugins are Java Archive (JAR) files with either
an .hpi or .jpi extension. For example, Git plugin ([Link]), Maven plugin (maven-
[Link]).
They may have optional or required dependencies on other plugins, and they can be
upgraded or downgraded (although this is generally not recommended).
ou might want to note that the Plugin Manager leverages the open source update site. An
update site is similar to a package manager. It stores all the plugins and plugin
metadata. This enables plugin installation from within Jenkins. So, how does Jenkins know
which update center it is pointing to? Click the Advanced settings link on the Plugin
Manager page.
What if your Jenkins is behind a firewall, and does not have direct access to the Internet?
In that case, you will need to configure an HTTP proxy server.
You can do it on the Advanced settings page. Enter the HTTP proxy server name, proxy
port, and username used to authenticate with the proxy, and the password to configure
your proxy settings. Click the Advanced button on the bottom right to enable the Test
URL to validate proxy configuration fields. Finally, click the Submit button to submit the
configuration.
Git Host Key Verification
Configuration
A
Authetication
Authentication is an act of validating that users are who they claim to be, essentially
confirming the identity of users. Usernames and passwords are the most basic form of
authentication.
Jenkins supports many different authentication systems through security realms. A
security realm tells Jenkins which referential to use for authentication.
There are four security realms which are supported out of the box. These are:
Delegate to servlet container
Jenkins' own user database
LDAP
Unix user/group database
Security Realm
Delegate to servlet container
This realm delegates authentication to the servlet engine running Jenkins. For instance,
Tomcat, JBoss, websphere, etc., have their own authentication mechanisms. If using this
realm, you will need to look into the servlet container’s authentication documentation.
Example: Apache Tomcat 9 configuration documentation "Realm Configuration How-To".
Jenkins’ own user database
This security realm uses Jenkins local database and is enabled by default when you
initially install Jenkins.
If you select this security realm, you do have the option of letting your users sign up.
However, please refrain from assigning any significant privileges, such as edit,
administrator, etc., to authenticated users, as this can pose a big security risk.
Jenkins’ Own User Database
Note that if you deselect the sign up option, only users with overall administrator
privileges can create users.
LDAP
This realm delegates authentication to an external LDAP service. Most companies already
have a Directory Service for authentication. This option is more common for larger
installations in organizations which already have configured an external identity provider
such as LDAP. This also supports Active Directory, OpenLDAP installations.
Key features of LDAP include:
It is highly tunable.
Its binding can be sub-authenticated.
You can take advantage of the caching mechanism to leverage load
on LDAP servers.
There's support available for LDAP replicas.
There are various other security realms available through plugins such as Github
Authentication, Active Directory, BitBucket OAuth, and Azure AD, to name a few. You can
search these on the plugins page.
Unix user/group database
This realm delegates authentication to the underlying Unix/Linux machine, and it only
works if you are running Jenkins on a Unix server.
If you enable this realm, your end users will have to login to Jenkins by entering their
operating system username and password.
What Is a Jenkins Job?
A Jenkins job is a sequential set of tasks that are defined by a user. Typical steps include
retrieving the latest source code from version control, compiling it, running unit tests,
building and storing the artifacts, and notifying the end users of the outcome of the build.
On the Jenkins UI, the term "job" is used synonymously with "project" (although "project"
is now deprecated). Note that both of these are runnable tasks controlled and monitored
by Jenkins.
Jenkins Job Types
There are many different job types available in Jenkins including:
Freestyle Project
This is the default type, most flexible to configure, and is included
as part of the core Jenkins.
Pipeline and Multibranch Pipeline
These are useful for creating end-end CI/CD pipelines. They
require Pipeline and Multibranch plugins to be installed.
Multi-Configuration Project
This is useful for jobs with a large number of configurations. It
requires the Matrix Project plugin to be installed.