Skip to main content

Command Palette

Search for a command to run...

Launch Jenkins on Amazon Linux 2 and Build Your First Pipeline

In the previous post, we covered what Jenkins is and how it fits into a CI/CD pipeline. Now it is time to get Jenkins actually running on a server. We will install it on an Amazon Linux 2 EC2 instance, access the dashboard for the first time, and create a simple job to make sure everything works.

Updated
7 min read
Launch Jenkins on Amazon Linux 2 and Build Your First Pipeline
S
Passionate about Cloud and DevOps engineering. I write structured technical notes and beginner-friendly articles on AWS, Linux, CI/CD, networking, system architecture and modern software delivery workflows.

Before You Start: Launch Your EC2 Instance

For learning Jenkins, spin up a fresh Amazon Linux 2 EC2 instance. A t2.micro is fine for the exercises in this post.

Once it is up and you are connected over SSH, let us jump straight into the installation.


Step 1: Add the Jenkins Repository

Amazon Linux 2 does not know about Jenkins out of the box. Before you can install it, you need to tell your package manager where to find Jenkins by adding the official Jenkins repository.

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

The first command downloads the Jenkins repository definition file. The second imports the GPG key so the package manager can verify the downloaded packages are legitimate.


Step 2: Install Java and Jenkins

Jenkins is a Java application. Without Java, Jenkins will not start. We are installing Java 21 here (Amazon Corretto is Amazon's distribution of OpenJDK):

sudo yum install java-21-amazon-corretto -y

Now install Jenkins itself:

yum install jenkins -y

Because we added the Jenkins repository in Step 1, the package manager now knows exactly where to pull Jenkins from and will install it without any confusion.

You may also want to install Git and Maven at this point, since they are commonly needed:

yum install git maven -y

Step 3: Remount /tmp with More Space

Sometimes builds fail because the /tmp partition runs out of space. Remounting it with 2GB prevents this issue:

sudo mount -o remount,size=2G /tmp

Step 4: Start Jenkins and Check the Status

By default, after installation, Jenkins is in a stopped state. Start it manually:

systemctl start jenkins.service

Verify it is running:

systemctl status jenkins.service

You should see Active: active (running) in the output. That means Jenkins is up and listening.


Step 5: Enable Jenkins to Auto-Start

If the EC2 instance stops and starts again, you want Jenkins to come back up automatically without you having to SSH in and run a start command manually.

chkconfig jenkins on

This registers Jenkins as a service that starts on boot. Highly recommended for any environment where you are not terminating the instance every time.


The Complete Installation Script

All the steps above are combined in the jenkins.sh script:

#!/bin/bash

# Install Git and Maven
yum install git maven -y

# Add the Jenkins repository
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

# Install Java 21 and Jenkins
sudo yum install java-21-amazon-corretto -y
yum install jenkins -y

# Expand /tmp size
sudo mount -o remount,size=2G /tmp

# Start Jenkins and check status
systemctl start jenkins.service
systemctl status jenkins.service

# Enable Jenkins to auto-start on reboot
chkconfig jenkins on

You can copy this script to your server, make it executable, and run it:

chmod +x jenkins.sh
sudo bash jenkins.sh

Step 6: Access the Jenkins Dashboard

Take the public IP address of your EC2 instance and open it in a browser with port 8080:

http://<your-ec2-public-ip>:8080

You should see a page asking for an initial administrator password.

To get this password, run:

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

Copy that long string of characters, paste it into the browser, and click Continue.


Step 7: Install Suggested Plugins

Jenkins will now ask you whether to install suggested plugins or select plugins manually. Choose Install suggested plugins.

This installs a sensible set of default plugins including Git integration, pipelines, Maven support, and more. The installation takes a few minutes. Let it run.

A critical thing to understand here: Jenkins itself does not know how to talk to GitHub, Maven, Docker, or any other tool out of the box. Everything Jenkins can do with external tools depends on having the right plugin installed. Plugins are how Jenkins extends itself.


Step 8: Create Your Admin User

After plugin installation, Jenkins prompts you to create an admin user. Fill in:

  • Username (for example, admin)

  • Password

  • Full name

  • Email address

Set a Jenkins URL if prompted (the default using your IP address is fine), then click Save and Finish followed by Start using Jenkins.


Welcome to the Jenkins Dashboard

You are now looking at the Jenkins dashboard. Let us quickly orient ourselves:

  • New Item - this is where you create jobs (also called builds or projects)

  • Manage Jenkins - this is the control panel for all global configuration, plugin management, security, credentials, nodes, and system settings

  • Build Executor Status - shows how many builds Jenkins can run in parallel at any given time

The weather icon you see next to each job on the dashboard is Jenkins' way of showing overall job health. A sunny icon means most recent builds succeeded. A rainy or stormy icon means there have been a lot of failures. It is a quick visual health indicator.


Creating Your First Jenkins Job

Let us create a simple job to confirm everything is working.

  1. Click New Item.

  2. Enter a name, for example, my-first-job.

  3. Select Freestyle project.

  4. Click OK.

You will land on the job configuration screen. For now, scroll down to the Build Steps section. Click Add build step and select Execute shell.

In the text box that appears, type:

echo "Welcome to Jenkins!"

Click Save. You are back on the job's dashboard page.


Running the Job

Click Build Now on the left sidebar. You will see a build appear in the Build History section at the bottom left. Click on the build number, then click Console Output to see the result.

You should see:

[my-first-job] $ /bin/sh -xe /tmp/jenkins-sh.sh
+ echo 'Welcome to Jenkins!'
Welcome to Jenkins!
Finished: SUCCESS

A green circle (or "SUCCESS") means the job ran without errors. This is your first successful Jenkins build.


Understanding the Job Workspace

Every job gets its own workspace directory under the Jenkins workspace path. For a job named my-first-job, its workspace lives at:

/var/lib/jenkins/workspace/my-first-job

Any files the job creates, downloads, or generates end up here. If you create a file inside an Execute Shell step, you will find it in this directory after the build runs.

For example, if your build step contains:

echo "This is a test" > /tmp/output.txt

You can verify after the build:

cat /tmp/output.txt

Running a Shell Script from a Jenkins Job

Jenkins jobs can also run existing shell scripts on the server. If you have a script at /tmp/myscript.sh, your build step simply calls it:

sh /tmp/myscript.sh

This is powerful because you can pre-write complex automation scripts and invoke them from Jenkins without putting all the logic directly in the job configuration.


Summary

Here is what you accomplished in this post:

  1. Added the Jenkins repository to Amazon Linux 2.

  2. Installed Java 21 and Jenkins.

  3. Started the service and configured auto-start.

  4. Accessed the Jenkins dashboard via the browser.

  5. Installed suggested plugins.

  6. Created a first job using the Freestyle project type.

  7. Ran the job and confirmed a successful build.

In the next post, we will explore job configuration in depth, including parameters, variables, and build triggers, the features that make Jenkins jobs truly powerful and dynamic.

More from this blog

Stop Writing Repetitive Playbooks: Ansible Tags, Variables, Loops, Handlers and Conditions Decoded

Once you have written your first few Ansible playbooks, installed some packages, and started a couple of services, a natural question comes up: what else can Ansible do? The answer is quite a lot. This article walks through six features that turn a basic Ansible setup into something genuinely powerful: the Setup module, Tags, Variables, Loops, Handlers, and Conditional tasks. Each one builds on what you already know, and together they give you the tools to manage complex, real-world server environments cleanly and efficiently. Before going further, the environment being used here has one Ansible master and multiple worker nodes. Two are grouped as prod and two as dev inside /etc/ansible/hosts. SSH key-based authentication is already configured between the master and all worker nodes. If any of that is not set up yet, revisit passwordless SSH setup and inventory configuration before continuing.

Jun 21, 202615 min read
Stop Writing Repetitive Playbooks: Ansible Tags, Variables, Loops, Handlers and Conditions Decoded

Ansible Playbooks Explained: From First YAML File to Managing Real Servers

If you have already run a few Ansible ad hoc commands and seen how they work, you already understand the core idea: one command, many servers. But ad hoc commands only take you so far. When you need to install software, start services, create users, copy files, and print confirmation messages, all in one automated run across multiple servers, that is when you move to playbooks. Playbooks are where Ansible truly earns its place in a DevOps workflow. Everything you do in Ansible at scale, you do through playbooks.

Jun 19, 202613 min read
Ansible Playbooks Explained: From First YAML File to Managing Real Servers

You Have 400 Servers to Configure. Now What? Let Ansible Do the Work.

Picture this. You have four EC2 instances running in your AWS account, and someone asks you to install Apache on all four of them. What do you do? The obvious answer most people go with is SSH into each machine, run the install command, repeat. Simple enough when it is four servers. But what happens when it is forty? Or four hundred? In a real enterprise environment, that number is not exaggerated at all. That is exactly the problem that Ansible was built to solve. And once you understand what it does and how it thinks, you will wonder how anyone managed large infrastructure without it.

Jun 18, 202612 min read
You Have 400 Servers to Configure. Now What? Let Ansible Do the Work.

Building Production-Ready Docker Deployments with Secrets, Stacks, and Distroless Images

This post wraps up the core Docker Swarm curriculum by covering four important topics that complete the picture of production-ready containerized deployments. We start with Docker Secrets, which solves the real-world problem of passing sensitive credentials into containers without hardcoding them. We then look at Docker Stack, which is how you run multi-service Docker Compose files across a Swarm cluster instead of a single host. After that we cover the distinction between replicated and global services, which is a concept that appears in Kubernetes as well. We close with a look at Portainer for those who prefer a visual interface, and a brief introduction to distroless images. Each of these topics builds on everything covered so far. If you have your Swarm cluster running, you can follow along with every command shown here.

Jun 17, 202614 min read
Building Production-Ready Docker Deployments with Secrets, Stacks, and Distroless Images

Beyond One Server: Solving Docker Scaling with Swarm and Container Networks

This post covers three separate but deeply connected topics. We start by finishing what was started with Docker Hub, pushing all four bank service images to a remote registry so they survive beyond any single machine. From there, we identify a real architectural problem with single-host Docker deployments and introduce Docker Swarm as the solution. Finally, we close with Docker networking, explaining how containers communicate with each other both on the same host and across different hosts. By the end of this article, you will understand how to push and pull images from Docker Hub, how to set up a multi-node Docker Swarm cluster, how to create and scale services across that cluster, what self-healing means in practice, and how Docker networking works under the hood.

Jun 17, 202618 min read
Beyond One Server: Solving Docker Scaling with Swarm and Container Networks
S

Sai Praneeth's Blogs

38 posts

From SDLC and Agile to DevOps and CI/CD, this blog is where I share structured technical notes, concepts and practical insights in Cloud and DevOps engineering.