## 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) ```bash 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) ```bash 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: ```groovy 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.