Jenkins is an open-source automation server written in Java. It is widely used to automate tasks such as building, testing, and deploying applications.

Before using Jenkins, we learned about Maven, Tomcat, and Nexus.

• Maven builds the application.

• Tomcat deploys and runs the application.

• Nexus stores and manages application artifacts.

• Jenkins can automate the steps involved in this process.

For example, instead of manually running build commands every time a developer changes the code, Jenkins can run the build automatically when configured to do so.

This is why Jenkins is an important tool in DevOps.

Why do we use Jenkins?

Jenkins helps teams automate repetitive tasks in software development and delivery.

Some advantages of Jenkins are:

• It is open source.

• It has a web-based interface.

• It supports many plugins to connect with other tools.

• It can automate builds, tests, and deployment tasks.

• It provides build results and logs that help with troubleshooting.

• It supports integration with tools such as GitHub, Maven, SonarQube, Nexus, and deployment platforms.

You can explore available plugins here: https://plugins.jenkins.io/

What is Continuous Integration (CI)?

Continuous Integration means developers frequently push code changes to a shared repository. Jenkins can automatically build the code and run tests to find problems early.

Advantages of CI:

• Finds bugs early.

• Gives quick feedback.

• Reduces integration problems.

What is Continuous Delivery?

Continuous Delivery means the application is built, tested, and kept ready for release. Production deployment may require manual approval.

Flow: Code → Build → Test → Approval → Production

What is Continuous Deployment?

Continuous Deployment means every code change that passes the required automated checks is automatically deployed to production without separate manual approval.

Flow: Code → Build → Test → Automatic Production Deployment.

Simple difference:

Continuous Integration: Build and test the code.

Continuous Delivery: The application is ready to release, but production deployment may require approval.

Continuous Deployment: Successful changes are automatically deployed to production after passing the required checks.

Jenkins Installation on AWS EC2

Prerequisites

Before installing Jenkins, we need:

• An AWS EC2 instance

• Amazon Linux 2023 or another supported Red Hat-based Linux distribution

• Java 21

• An EC2 security group that allows access to port 8080

• An instance type such as t2.medium for this hands-on practice

1. Launch and Connect to EC2

1. Launch an EC2 instance from the AWS Console.

2. Select the required Linux AMI and instance type.

3. Connect to the instance using EC2 Instance Connect or SSH.

Switch to the root user:

sudo su -

2. Update Packages and Install Java

Update the system packages:

dnf update -y

Install Java 21 and the required font configuration package:

dnf install -y java-21-amazon-corretto fontconfig wget

Verify the Java installation:

java -version

Why do we need Java?

Jenkins is a Java-based automation server, so a supported Java runtime is required to run it.

3. Add the Jenkins LTS Repository

Jenkins provides a Long-Term Support (LTS) release for users who prefer a stable release line with regular fixes.

Add the official Jenkins LTS repository:

wget -O /etc/yum.repos.d/jenkins.repo \
https://pkg.jenkins.io/rpm-stable/jenkins.repo

Import the Jenkins signing key:

rpm --import https://pkg.jenkins.io/rpm-stable/jenkins.io-2026.key

Update the package metadata:

dnf upgrade -y

4. Install Jenkins

Install Jenkins:

dnf install -y jenkins

Reload the systemd configuration:

systemctl daemon-reload

5. Enable and Start Jenkins

Enable Jenkins to start automatically when the EC2 instance boots:

systemctl enable jenkins

Start the Jenkins service:

systemctl start jenkins

Check its status:

systemctl status jenkins

Look for:

Active: active (running)

Press q to exit the status screen.

6. Verify Jenkins

Check whether Jenkins is listening on port 8080:

ss -lntp | grep 8080

You can also check the local HTTP response:

curl -I http://localhost:8080

If Jenkins is starting for the first time, it may take a few minutes before the web interface becomes available.

7. Allow Port 8080 in AWS

Open the AWS EC2 Console -> Select your EC2 instance -> Open its Security Group -> Select Edit inbound rules -> Add the 8080 Port(Jenkins default port)

For a public learning environment, restrict access to your own IP instead of allowing access from everywhere.

8. Open Jenkins in Your Browser

Find the current public IPv4 address of your EC2 instance.

Open this URL in your browser:

http://YOUR-EC2-PUBLIC-IP:8080

Replace YOUR-EC2-PUBLIC-IP with your actual EC2 public IP address.

The Jenkins unlock page should appear.

9. Get the Initial Administrator Password

Run this command on your EC2 instance:

cat /var/lib/jenkins/secrets/initialAdminPassword

Copy the generated password and enter it on the Jenkins unlock page.

10. Install Jenkins Plugins

After unlocking Jenkins:

1. Select Install suggested plugins.

2. Wait for the plugins to install.

   

3. Create your first administrator account.

4. Enter a username, a strong password, your full name, and email address if requested.

1. Click Save and Continue.

2. Click Save and Finish.

3. Select Start using Jenkins.

Use your own practice credentials. Do not reuse example passwords in a real environment.

11. Verify Jenkins Installation

After logging in, you should see the Jenkins dashboard.

Jenkins is now ready for your initial configuration and practice.

What We Learned

In this setup, we installed Java and Jenkins on an EC2 instance, started Jenkins as a system service, configured network access, and completed the initial web-based setup.

In the next step, we can explore the Jenkins dashboard and create our first job.

Nexus is a repository manager used to store and manage build artifacts. When we build a Java application using Maven, it creates files such as:

• JAR

• WAR

• EAR

These files are called artifacts.

• Nexus provides a central place to store these artifacts so that developers and build servers can upload, download, and manage them.

• Nexus can also be used to store other types of artifacts, such as Docker images and libraries.

• Nexus is an open-source repository management tool developed by Sonatype.

• It is Java-based, which means Nexus is developed using Java.

Why do we need Nexus?

Nexus is used to store and maintain different versions of our application artifacts, such as WAR and JAR files.

For example, suppose we release version 1.0 of an application. Later, we release version 1.1.

If the new version has an issue and it affects users, we should be able to quickly go back to the previous working version.

Nexus keeps these versions safely, so we can use a previous version when needed.

This is especially useful during deployments because we always have a known version that we can go back to if something goes wrong.

Repository Tools

There are different tools available for managing repositories.
Two commonly used tools are:

1. Sonatype Nexus Repository

2. JFrog Artifactory

In this article, we are working with Sonatype Nexus Repository.

1. Install Java

Tomcat requires Java to run because Tomcat is developed using Java.

sudo dnf search java

sudo dnf install java-21-amazon-corretto-devel -y

java -version
javac -version

If Java is installed correctly, we can see the Java version

2. Install required tools

I need wget to download Tomcat, unzip to extract it and tree to see the directory structure.

sudo dnf install wget unzip tree -y

3. Download and install Nexus

For the Nexus installation, always get the download link from the Sonatype Nexus Documentation. Older Nexus versions may not be compatible with newer Java versions.

Tip: Choose the required version from the official page instead of using an old download link from a tutorial.

Go to /opt and download Nexus.

Download the Nexus archive.

wget https://download.sonatype.com/nexus/3/nexus-3.96.4-01-linux-x86_64.tar.gz
tar -xvzf nexus-3.96.4-01-linux-x86_64.tar.gz
mv nexus-3.96.4-01 nexus

Now our Nexus installation directory is:

/opt/nexus

NOTE: As a good security practice, Nexus is not advised to run nexus service as a root user, so create a new user called nexus and grant sudo access to manage nexus services as follows.

4. Create a Nexus User

We should not run Nexus as the root user.
Instead, we create a separate user called nexus.

useradd --create-home nexus

Now we have a separate user for running the Nexus service.

5. Create the Sonatype work directory

mkdir -p /opt/sonatype-work

This directory is used for Nexus working data.

6. Change ownership and permissions

Give the nexus user ownership of the Nexus directories.

chown -R nexus:nexus /opt/nexus
chown -R nexus:nexus /opt/sonatype-work
chmod -R 775 /opt/nexus
chmod -R 775 /opt/sonatype-work

Now the Nexus user can access these directories.

7. Configure the Nexus user

Open Nexus configuration file /opt/nexus/bin/nexus.rc and uncomment run_as_user parameter and set as nexus user.

vi /opt/nexus/bin/nexus.rc

Add:

run_as_user="nexus"

This tells Nexus to run using the nexus user instead of root.

8. Create the service file

vi /etc/systemd/system/nexus.service

Add the following:

[Unit]
Description=Nexus Repository
After=network.target

[Service]
Type=forking
LimitNOFILE=65536
User=nexus
Group=nexus
ExecStart=/opt/nexus/bin/nexus start
ExecStop=/opt/nexus/bin/nexus stop
Restart=on-abort
TimeoutStartSec=600

[Install]
WantedBy=multi-user.target

Here we are telling Linux how to start and stop Nexus.
The important parts are:

User=nexus
Group=nexus

Nexus will run as the nexus user.

ExecStart=/opt/nexus/bin/nexus start

This starts Nexus.

ExecStop=/opt/nexus/bin/nexus stop

This stops Nexus.

8. Create nexus as a service

ln -s /opt/nexus/bin/nexus /etc/init.d/nexus

9. Reload & start the nexus service

After creating the service file, reload systemd.

su - nexus
systemctl daemon-reload
systemctl enable nexus
systemctl start nexus
systemctl status nexus

Check port 8080:

ss -lntp | grep 8081

If Nexus is running, port 8081 should be listening.
We can also test Nexus locally:

curl -I http://localhost:8081

If Nexus is running correctly, we should get an HTTP response.

10. Access Nexus from the Browser

Open the browser:

http://<EC2-PUBLIC-IP>:8081

You should see the Sonatype Nexus page.
Note: Enable port 8081 in the Security Group inbound rules.

Get the Initial Admin Password

When we open Nexus for the first time, we need the initial admin password.

The password is stored in:

/opt/sonatype-work/nexus3/admin.password

Run:

cat /opt/sonatype-work/nexus3/admin.password

The command displays the initial password.
Use the initial password to login For example:

admin
<initial-password>

Set a New Admin Password

After logging in for the first time, Nexus asks us to change the initial password.

Set a new password for the admin user.

After setting the password, continue to the Nexus interface.

Nexus Dashboard

After logging in, we can see the Nexus Repository Manager dashboard.

From here, we can manage repositories and other Nexus settings.

Nexus Repositories

Nexus repositories are commonly separated based on the stage of the application.

• Snapshot repository is used for development, testing, and staging builds.

• Release repository is used for stable versions that are ready for production.

So the simple flow is:

Development → Testing/Staging → Release → Production

If a production release causes a problem, we can use the previously stored stable version instead of building the application again from the beginning.

Create a Snapshot Repository

Now let's create our first repository.
We will create a Maven hosted repository for snapshot artifacts.
login as a admin --> settings --> create repository --> maven2(hosted)

give name as jio-snapshot --> select version policy [snapshot] --> scroll down ---> create repository.

During development, developers may build the application many times.

For example:

1.0-SNAPSHOT

The application is still under development, so we can store these development artifacts in a snapshot repository.

• For each project we are going to create two types of repositories.

  1. jio-snapshot
  2. jio-release

Create the Release repository same as Snapshot

A release repository is used for stable versions of an application.

settings --> create repository --> maven2(hosted)--> give name as jio-release --> select version policy [release] --> scroll down ---> create repository.

Nexus Repository URLs

Each repository has its own URL. For example, we have two repositories:

Release repository

http://15.207.116.105:8081/repository/jio-release/

Snapshot repository

http://15.207.116.105:8081/repository/jio-snapshot/

These URLs are used when we connect Maven with Nexus.

How to Integrate Nexus with Maven?

Now that Nexus is ready, we can connect it with Maven.

The Maven server and Nexus server are two different servers.

The Java project and Maven are available on the Maven server, while Nexus is running on the Nexus server.

The basic flow is:

Java Project → Maven Build → Nexus Repository

Step 1: Go to the Maven server

First, connect to the server where the Java project is available.

Go to the project directory where the pom.xml file is present.

Step 2: Add Nexus repository details

We need to tell Maven where it should upload the generated artifact.

For this, we add the Nexus repository details in the project's pom.xml.

Add:

<repository>
    <id>nexus</id>
    <name>Releases Nexus Repository</name>
    <url>http://15.207.116.105:8081/repository/jio-release/</url>
</repository>

<snapshotRepository>
    <id>nexus</id>
    <name>Snapshot Nexus Repository</name>
    <url>http://15.207.116.105:8081/repository/jio-snapshot/</url>
</snapshotRepository>

Here we are providing two repository URLs:

• repository → Release repository

• snapshotRepository → Snapshot repository

So Maven knows where to upload release and snapshot versions.

Step 3: Configure Nexus credentials

Now Maven also needs credentials to connect to Nexus.

We don't keep the Nexus password directly in pom.xml.

The Nexus credentials are configured in Maven's settings.xml.

On the Maven server,
open:

vi /opt/apache-maven-3.9.10/conf/settings.xml

Add: nexus admin password

The important point here is that the must match the ID in pom.xml.

So:

pom.xml → Repository details

settings.xml → Nexus credentials

The settings.xml file is configured on the Maven server, not on the Nexus server.

Step 4: Deploy the artifact to Nexus

Now go to the project directory where pom.xml is available.

Run:

mvn clean deploy

Maven will build the project and deploy the generated artifact to the configured Nexus repository.

For a snapshot version, the artifact will be uploaded to the Snapshot repository.

If we run:

mvn clean deploy

multiple times with a snapshot version, Maven can upload updated snapshot builds to the snapshot repository.

Simple Flow

The complete process is:

 👨‍💻 Developer
       |
       | Push Code
       v
   ┌─────────┐
   │ GitHub  │
   └─────────┘
       |
       | git clone
       v
   ┌─────────┐
   │ Maven   │
   └─────────┘
       |
       | mvn clean package
       |
       +------------------------+
       |                        |
       v                        |
 ┌───────────────┐              |
 │ WAR/JAR/EAR   │              |
 │ Generated     │              |
 └───────────────┘              |
       |                        |
       | mvn deploy             |
       v                        |
 ┌───────────────┐              |
 │ Nexus         │◄-------------+
 │ Repository    │
 │ Store Artifact│
 └───────────────┘
       |
       | Download Artifact
       v
 ┌───────────────┐
 │ Apache Tomcat │
 │ Deploy WAR    │
 └───────────────┘

This is the basic integration between Maven and Nexus.

Conclusion

As of now, we are manually running the Maven goal when we need to build and deploy the application.

For example:

mvn clean deploy

This builds the application and uploads the artifact to the Nexus repository.

In the next blogs, we will start automating this process so that we don't have to manually run these commands every time.

We will move towards Jenkins and CI/CD automation, where the build and deployment process can be triggered automatically.

Maven is a build tool mainly used for Java projects. It helps us to:

• Build the Java project

• Download and manage dependencies

• Run tests

• Create the final WAR or JAR file

Maven is an open-source tool developed by the Apache Software Foundation.

Why do we need Maven?

Maven helps developers manage dependencies, compile code, run tests, and generate WAR/JAR files.

When a developer writes Java code, we need to convert that source code into a package that can be used or deployed.

For example:

Developer
   ↓
Java Code
   ↓
Maven
   ↓
WAR / JAR
   ↓
Tomcat ->Deploy

Instead of doing the build steps manually, Maven does them for us.

1. Install Java

Maven requires Java to run because Maven is developed using Java.

sudo dnf search java

sudo dnf install java-21-amazon-corretto-devel -y

java -version
javac -version

If Java is installed correctly, we can see the Java version.

2. Install required tools

I need wget to download Maven, unzip to extract it and tree to see the directory structure.

sudo dnf install wget unzip tree -y

3. Download and install Maven

For the Tomcat installation, always get the download link from the official Apache Tomcat documentation. Older Tomcat versions may not be compatible with newer Java versions.

You can find the latest Tomcat 9 downloads here:

Apache Maven 3 Downloads

Tip: Choose the required version from the official page instead of using an old download link from a tutorial.
Go to /opt and download Tomcat.

sudo su -

wget https://dlcdn.apache.org/maven/maven-3/3.9.16/binaries/apache-maven-3.9.16-bin.zip

unzip apache-maven-3.9.16-bin.zip

4. Set the Maven environment variables.

Open the ~/.bash_profile file

vi ~/.bash_profile

Add:

export M2_HOME=/opt/apache-maven-3.9.16
export PATH=$PATH:$M2_HOME/bin

Load the changes:

source ~/.bash_profile

Check Maven:

mvn -version

You should see the Maven version.

5. Maven Directory Structure

We can use the tree command to see the Maven directories.

cd /opt/apache-maven-3.9.16

tree -L 2

The important directories are:

bin/
boot/
conf/
lib/

bin/ contains binary files [mvn, etc]

boot/ contains jar files used at runtime

conf/ contains Maven configuration files such as settings.xml.

lib/ contains Maven libraries[jars files]

default xml file names for build scripts

pom.xml ----> maven
build.xml --->ant
build.gradle[we can not use xml for gradle] --->gradle

6. Maven Lifecycle

Maven has three main lifecycles:

clean
default
site

6.1 Clean

The clean lifecycle handles project cleaning. It consists of the following phases:
pre-clean:
clean: It will delete the build history --> delete the target dir.
post-clean:
Ex:

mvn clean

It removes the target directory.

6.2 Site

The site lifecycle handles the creation of the project's site documentation. It consists of the following phases:

pre-site: Executes processes needed before the actual project site generation.
site: Generates the project's site documentation.
post-site: Executes processes needed to finalize the site generation.
site-deploy: Deploys the generated site documentation to the specified web server.
Ex:

mvn site

NOTE: Now a days developers are using Swagger instead of site goal.

6.3 Default

validate - validate the project is correct and all necessary information is available like directory structure, etc
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework[junit] and checks the unit test cases.

NOTE: These tests should not require the code be packaged or deployed

package - take the compiled code and and generate the package, such as a jar/war/ear.
install - install the package[jar/war/ear] into the local repository, for use as a dependency in other projects locally.
deploy - done in the build environment, copies the final package[jar/war/ear] to the remote repository for sharing with other developers and projects.
Ex:

mvn clean
mvn validate
mvn compile
mvn test
mvn package
mvn verify
mvn install
mvn deploy

Is it possible to pass two goals at a time?

mvn clean package

First it will clean (delete the previous target directory) then build the package again.

7. Maven Repositories

Maven repositories are locations where Maven artifacts (JAR files, plugins, and other project dependencies) are stored and can be retrieved from.

There are three repositories we need to understand.

7.1 Local Repository

The local repository is a directory on your local machine where Maven stores downloaded artifacts. By default, it is located in the .m2 directory within the user's home directory.
By default:

~/.m2/repository

Maven stores downloaded dependencies here.

To change the default location:
step 1:
open /opt/apache-maven-3.9.10/conf/settings.xml

step 2:
update under settings tag

<localRepository>
/root/commonrepo
<localRepository>

7.2 Central Repository

Maven Central is a public repository that contains many commonly used Java libraries. hosted by the Maven community

If Maven cannot find a dependency in the local repository, it can download it from Maven Central.

7.3 Remote Repository

In a organization, We have 5 war files, every one Don't keep in the central repo, an access, so we are keeping in remote repo so company people can access.

Nexus
JFrog

These are used to store the organization's WAR, JAR and other artifacts.

We will discuss Nexus in the next blog.

8. Build the Application

Now clone the project and go to the directory where pom.xml is present.

pom.xml is the main Maven configuration file for the project.

Run:

mvn clean package

Maven builds the project and creates the target directory.

Inside the target directory, we can see the generated WAR file.

For example:

target/
└── maven-web-application.war

This WAR file can then be deployed to Tomcat.

Later, we can use Jenkins to automate the Maven build whenever new code is pushed.

A simple flow is:

Developer → Git → Maven → SonarQube → Nexus → Tomcat

Later, we use Jenkins to automate this complete process.
Before automation, I want to understand how Tomcat works manually. So in this blog, let's install Tomcat and understand its basic directory structure, users, deployment and port configuration.

What is Tomcat?

Apache Tomcat is a Java application server used to deploy and run Java web applications (.war files).

In many organizations, developers build applications and deploy them to Tomcat servers.
Today, let's install and understand Tomcat.

1. Install Java
Tomcat requires Java to run because Tomcat is developed using Java.

sudo dnf search java

sudo dnf install java-21-amazon-corretto-devel -y

java -version
javac -version

If Java is installed correctly, we can see the Java version.

2. Install required tools

I need wget to download Tomcat, unzip to extract it and tree to see the directory structure.

sudo dnf install wget unzip tree -y

3. Download and install Tomcat

For the Tomcat installation, always get the download link from the official Apache Tomcat documentation. Older Tomcat versions may not be compatible with newer Java versions.

You can find the latest Tomcat 9 downloads here:

Apache Tomcat 9 Downloads

Tip: Choose the required version from the official page instead of using an old download link from a tutorial.

Go to /opt and download Tomcat.

sudo su -

cd /opt

wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.122/bin/apache-tomcat-9.0.122.zip

unzip apache-tomcat-9.0.122.zip

cd apache-tomcat-9.0.122/bin

Give execute permission to the shell scripts:

chmod u+x *.sh

4. Start Tomcat

Start Tomcat using:

sh catalina.sh start

Check whether Tomcat is running:

ps -ef | grep tomcat

Check the Tomcat logs:

tail -f /opt/apache-tomcat-9.0.122/logs/catalina.out

Check port 8080:

ss -lntp | grep 8080

If Tomcat is running, port 8080 should be listening.

5. Tomcat directory structure

The tree command helps us understand the Tomcat folders.

cd /opt/apache-tomcat-9.0.122

tree -L 2

The important directories are:

apache-tomcat-9.0.122/
│
├── bin/
├── conf/
├── lib/
├── logs/
├── temp/
├── webapps/
└── work/

What are these folders?

bin/
Contains scripts used to start and stop Tomcat.

startup.sh
shutdown.sh
catalina.sh

catalina.sh is the main script used to control Tomcat.

conf/
Contains Tomcat configuration files.

server.xml
tomcat-users.xml

server.xml → server and port configuration.

tomcat-users.xml → users and roles.

lib/
Contains Tomcat .jar files.

logs/
Contains Tomcat log files.

webapps/
This is where web applications are deployed.

For example:

ROOT
manager
host-manager

temp/
Used for temporary files.

work/
Contains files generated while Tomcat processes applications.

6. Access Tomcat

Open the browser:

http://<EC2-PUBLIC-IP>:8080

You should see the Tomcat page.
Note: Enable port 8080 in the Security Group inbound rules.

7. Tomcat Manager App

Tomcat provides a Manager App to manage applications.

Click:

Manager App

Initially, it may ask for username and password.

To enable access, go to:

cd /opt/apache-tomcat-9.0.122/webapps/manager/META-INF

vi context.xml

In context.xml, comment the relevant RemoteAddrValve lines.

:se nu => comment 21st and 22nd lines.

<!--
...(21st and 22nd line)
-->

Screenshot: context.xml before/after commenting

8. Create Tomcat user

Now go to:

cd /opt/apache-tomcat-9.0.122/conf

vi tomcat-users.xml

Add a user and required roles before the closing tomcat-users tag.

Example:

<user username="mamatha" password="password" roles="manager-gui,admin-gui"/>
<user username="tomcat" password="password" roles="manager-gui,admin-gui"/>

Save the file.

Now open the Manager App again and enter the username and password.

For a real production server, use a strong password and follow your organization's access/security rules. Don't use simple demo credentials.

Manager App after successful login
Tomcat UI shows the message ok

9. Host Manager

We can configure the Host Manager in a similar way.

Go to:

cd /opt/apache-tomcat-9.0.122/webapps/host-manager/META-INF

ls

You will see:

context.xml

Edit it:

vi context.xml

Comment the relevant access restriction lines.
Then open:

Host Manager
and provide the Tomcat credentials.

10. Check Tomcat logs

Tomcat creates log files under:

cd /opt/apache-tomcat-9.0.122/logs

ls

Some important files are:

catalina.out
localhost_access_log...

When troubleshooting Tomcat, logs are one of the first places to check.

When troubleshooting Tomcat, logs are one of the first places I check.

Deploy a WAR file

One common way to deploy a Java web application is using a .war file.

We can copy the WAR file into:

/opt/apache-tomcat-9.0.122/webapps/

For example:

cp myapp.war /opt/apache-tomcat-9.0.122/webapps/

Tomcat detects the WAR file and deploys the application.

We can also deploy a WAR using the Manager App.

Go to:

Manager App → Deploy → WAR file to deploy → Choose File → Deploy

This is useful for understanding manual deployment.

Later, instead of manually uploading the WAR file, Jenkins can do this automatically.

What if Tomcat and Jenkins use the same port?

This is an important situation.

Suppose:

Tomcat → 8080
Jenkins → 8080

Both applications cannot listen on the same port on the same server.

We will get a port conflict such as:

java.net.BindException

So we need to change one of the ports.

For example:

Tomcat → 8081
Jenkins → 8080

Change Tomcat port

Go to:

cd /opt/apache-tomcat-9.0.122/conf

Open:

vi server.xml

Find the connector port:

<Connector port="8080" ... />

Change it to:

<Connector port="8081" ... />

Stop Tomcat and start it again:

cd /opt/apache-tomcat-9.0.122/bin

sh catalina.sh stop

sh catalina.sh start

Now access:

http://<EC2-PUBLIC-IP>:8081

Important: If this is an AWS EC2 instance, make sure the new port is allowed in the Security Group.

Conclusion:

In this blog we installed Apache Tomcat and understood how it works. This blog covers:

• Installing Java and Tomcat

• Understanding the important Tomcat directories

• Starting and stopping Tomcat

• Accessing the Manager App and Host Manager

• Creating users and roles

• Deploying a WAR file

• Checking Tomcat logs

• Changing the Tomcat port

• Understanding basic port conflicts.

This gives us a basic understanding of Tomcat before moving to the next tools in the DevOps process.

In the next blog, we will set up Maven and understand how it is used to build a Java application.

Then we will continue with SonarQube, Nexus and Jenkins and finally connect them together for automation.