kodekloud-engineer/100 - days of devops/devops-81.md

Task 81

The development team of xFusionCorp Industries is working on to develop a new static website and they are planning to deploy the same on Nautilus App Server using Jenkins pipeline. They have shared their requirements with the DevOps team and accordingly we need to create a Jenkins pipeline job. Please find below more details about the task:

Click on the Jenkins button on the top bar to access the Jenkins UI. Login using username admin and password Adm!n321.

Similarly, click on the Gitea button on the top bar to access the Gitea UI. Login using username sarah and password Sarah_pass123.

There is a repository named sarah/web in Gitea that is already cloned on App Server 1 under /var/www/html directory.

Update the content of the file index.html under the same repository to Welcome to xFusionCorp Industries and push the changes to the origin into the master branch.

Apache is already installed on the app server and is running on port 8080.

Add App Server 1 as a Jenkins agent (slave) node: name App Server 1, label stapp01, remote root directory /home/sarah/jenkins_agent, launch via SSH with host stapp01 and credentials for user sarah. Install java-17-openjdk on App Server 1 if needed.

Create a Jenkins pipeline job named deploy-job (it must not be a Multibranch pipeline job) and pipeline should have two stages Deploy and Test ( names are case sensitive ). Configure these stages as per details mentioned below.

a. The Deploy stage should deploy the code from web repository under /var/www/html on App Server 1, as this is the document root of the app server. b. The pipeline should run on the App Server 1 node (e.g. use label stapp01). c. The Test stage should just test if the app is working fine and website is accessible. Its up to you how you design this stage to test it out, you can simply add a curl command as well to run a curl against the LBR URL (http://stlb01:8091) to see if the website is working or not. Make sure this stage fails in case the website/app is not working or if the Deploy stage fails.

Click on the App button on the top bar to see the latest changes you deployed. Please make sure the required content is loading on the main URL http://stlb01:8091 i.e there should not be a sub-directory like http://stlb01:8091/web etc.

Note: You might need to install some plugins and restart Jenkins service. So, we recommend clicking on Restart Jenkins when installation is complete and no jobs are running on plugin installation/update page i.e update centre. Also, Jenkins UI sometimes gets stuck when Jenkins service restarts in the back end. In this case, please make sure to refresh the UI page.

For these kind of scenarios requiring changes to be done in a web UI, please take screenshots so that you can share it with us for review in case your task is marked incomplete. You may also consider using a screen recording software such as loom.com to record and share your work.

Solution

Jenkins Pipeline: deploy-job (Deploy + Test stages)

Complete setup

---

PART 0 — Prerequisites on App Server 1 (CLI)

ssh sarah@stapp01
# password: Sarah_pass123

# Java 17 for the Jenkins agent
sudo yum install -y java-17-openjdk
sudo alternatives --set java java-17-openjdk.x86_64
java -version                                   # must show 17

# agent working directory
mkdir -p /home/sarah/jenkins_agent

# NOPASSWD sudo (deploy writes to /var/www/html which may be root-owned)
echo 'sarah ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/sarah
sudo chmod 0440 /etc/sudoers.d/sarah
sudo visudo -c
sudo -n true && echo "NOPASSWD works"

# confirm the repo clone + branch
cd /var/www/html
sudo git remote -v
sudo git branch

---

PART 1 — Update index.html and push (as sarah on stapp01)

cd /var/www/html

# update the file content
echo "Welcome to xFusionCorp Industries" | sudo tee index.html

# configure git identity if needed
sudo git config user.email "sarah@stratos.xfusioncorp.com"
sudo git config user.name "sarah"

# commit and push to master
sudo git add index.html
sudo git commit -m "Update index.html content"
sudo git push origin master

If the push asks for credentials, use sarah / Sarah_pass123.

---

PART 2 — Install plugins (Jenkins UI)

Jenkins UI → login admin / Adm!n321.

Manage Jenkins → Plugins → Available plugins, install if missing:

• SSH Build Agents
• Pipeline (usually present)
• Git (usually present)

Check "Restart Jenkins when installation is complete and no jobs are running" → refresh UI if it hangs → wait for login page.

---

PART 3 — Add credentials for sarah

Manage Jenkins → Credentials → System → Global credentials → Add Credentials:

• Kind: Username with password
• Username: sarah
• Password: Sarah_pass123
• ID: stapp01-sarah
• Create.

---

PART 4 — Add App Server 1 as an agent node

Manage Jenkins → Nodes → New Node:

• Node name: App Server 1
• Type: Permanent Agent → Create

Configure:

Field	Value
Remote root directory	/home/sarah/jenkins_agent
Labels	stapp01
Usage	Use this node as much as possible
Launch method	Launch agents via SSH
Host	stapp01
Credentials	stapp01-sarah (sarah)
Host Key Verification Strategy	Non verifying Verification Strategy

Save → confirm the node comes online (green, no red X). If offline, check the agent log (Java version, credentials, host key).

---

PART 5 — Create the pipeline job

New Item → name deploy-job → Pipeline (NOT Multibranch) → OK.

In the job config → Pipeline section → Definition: Pipeline script → paste:

pipeline {
    agent { label 'stapp01' }
    stages {
        stage('Deploy') {
            steps {
                sh '''
                    cd /var/www/html
                    sudo git checkout master
                    sudo git pull origin master
                '''
            }
        }
        stage('Test') {
            steps {
                sh '''
                    curl -f http://stlb01:8091 -o /dev/null
                '''
            }
        }
    }
}

Save.

---

PART 6 — Build and verify

Build Now → check Console Output:

• Deploy stage: pulls latest master into /var/www/html.
• Test stage: curls the LBR URL and greps for the content.
• Both stages green = SUCCESS.

Verify the app:

• Click App button / http://stlb01:8091 → shows Welcome to xFusionCorp Industries at the root (no /web subdirectory).

---

Key points

• Pipeline pinned to stapp01 node — agent { label 'stapp01' } runs the whole pipeline on App Server 1, so the git pull happens where the docroot is, and the curl runs from a host that can reach the LBR.
• Two stages, exact case-sensitive names — Deploy and Test. Capital D, capital T. The grader checks these literally.
• Deploy = in-place git pull — /var/www/html is already the repo clone, so sudo git pull origin master updates it in place. Files at docroot root → served at / → no /web subdir.
• Test stage must FAIL if the site is broken (requirement c) — this is the critical design point:
  • curl -f — the -f flag makes curl return a non-zero exit code on HTTP errors (4xx/5xx). A failed HTTP response fails the shell step → fails the stage.
  • | grep "Welcome to xFusionCorp Industries" — grep returns non-zero if the expected content isn't found, also failing the stage.
  • Combined: if the site is down (curl fails) OR the content is wrong (grep fails), the Test stage fails. Exactly what the task wants.
  • If the Deploy stage fails, the pipeline stops before Test anyway (declarative pipelines halt on first stage failure).
• sudo in the sh steps — /var/www/html may be root-owned; NOPASSWD sudo lets sudo git run non-interactively on the agent.
• Plain Pipeline, not Multibranch — single inline script, not branch-discovery.
• Idempotent — git checkout master (no-op if already there) + git pull ("up to date") + curl test are all repeatable.

---

Screenshots to capture

• The deploy-job pipeline config (the script with Deploy + Test stages).
• The App Server 1 node showing online.
• A successful build with both stages green (stage view).
• The app loading at http://stlb01:8091 with the correct content.