Build End-to-End CI/CD with Jenkins, SonarQube, and Docker

This milestone creates the network rules, IAM roles, three EC2 instances and the ECR repository that the rest of the project depends on.

Jenkins, SonarQube and the app each run on their own server so a crash or memory spike in one cannot take down the others. Instead of storing AWS access keys inside Jenkins, you attach an IAM role to the instances. The role gives the instance temporary credentials automatically, so there is no long-lived secret to leak.

Create the three security groups, then open only what each server needs:

Create the two IAM roles. Jenkins can push images; the app server can only pull them:

Launch the instances and create the registry. Tags in ECR are set to immutable so a pushed version can never be overwritten, which is what makes rollbacks trustworthy:

Tip

The SonarQube server gets no instance profile at all, because it never calls AWS APIs. Giving each server only the access it needs keeps one compromised machine from reaching the registry.

Note the public and private IP of each instance. You will use public IPs to reach the web interfaces and private IPs for server-to-server traffic:

Security

Never open 8080 or 9000 to 0.0.0.0/0. Both dashboards can run code or expose source, and automated scanners find open ones within hours. This setup allows your own IP, the GitHub webhook ranges, and the other servers by security group.

Common Mistake

Restricting Jenkins to your IP only, then wondering why the GitHub webhook never fires. GitHub calls Jenkins from its own ranges. The api.github.com/meta loop above adds them. GitHub changes that list over time, so refresh it if webhooks stop working.

This milestone turns the Jenkins server into a build machine with everything the pipeline calls: Java, Jenkins, Docker, the AWS CLI and Trivy.

Jenkins is a Java application, so it needs a Java runtime first. Jenkins also runs docker build and trivy as shell commands, so those tools must exist on the same machine and the jenkins user must be allowed to use Docker.

On the server:

Open http://JENKINS_PUBLIC_IP:8080 and unlock Jenkins with the initial password:

Choose Install suggested plugins, create an admin user, then add these plugins under Manage Jenkins, Plugins, Available plugins:

• SonarQube Scanner
• Docker Pipeline
• SSH Agent

Security

Membership of the docker group is effectively root on that machine, because anyone who can start containers can mount the host filesystem. That trade-off is normal for a single-purpose lab build server. In production, use ephemeral build agents so a compromised build cannot touch the controller.

Common Mistake

Fixing permission denied on the Docker socket with chmod 777 /var/run/docker.sock. It works until the next reboot and lets every user on the box control Docker. Add the jenkins user to the docker group and restart Jenkins instead.

This milestone starts SonarQube and its PostgreSQL database as containers on the second server, then creates the access token and callback webhook Jenkins needs.

SonarQube analyses source code for bugs, vulnerabilities, code smells and test coverage, then applies a quality gate, a pass or fail rule such as "new code must have at least 80 percent coverage". Running it in Docker Compose keeps the install to one file, avoids a manual Java and database setup, and makes upgrades a one-line change. The Community Build needs a recent JDK, and the official image already includes it.

Create /opt/sonarqube/docker-compose.yml:

Open http://SONARQUBE_PUBLIC_IP:9000 and sign in as admin with password admin. SonarQube forces you to change it immediately. Then:

• Go to My Account, Security, and generate a Global Analysis Token named jenkins-token. Copy it now, because it is shown once
• Go to Administration, Configuration, Webhooks, and create one named jenkins with the URL http://JENKINS_PRIVATE_IP:8080/sonarqube-webhook/ (keep the trailing slash)

The webhook is how SonarQube tells Jenkins the quality gate result. Without it, the pipeline waits until its timeout and then fails, even when the code is fine.

Tip

sonarqube:community follows the current Community Build, which has no long-term-support line. For a stable lab, pin an exact version tag from Docker Hub and upgrade deliberately.

Common Mistake

Starting SonarQube without raising vm.max_map_count. The container exits with an Elasticsearch bootstrap error in the logs. Apply the sysctl settings first, then restart the stack with docker compose up -d.

This milestone creates a small Node.js service with tests, a Dockerfile and a SonarQube configuration, so the pipeline has something real to build.

Use your own application if you have one. This app is deliberately tiny so the focus stays on the pipeline. It exposes a home route and a /health route, and its tests produce a coverage report that SonarQube reads.

Create a new GitHub repository named ci-demo-app, clone it, and add these files.

package.json:

src/app.js:

src/server.js:

tests/app.test.js:

Dockerfile:

.dockerignore:

sonar-project.properties:

Install, test locally and commit. The lock file is required, because the pipeline uses npm ci:

Tip

The image runs as the non-root node user and installs only production dependencies. Smaller, less privileged images give Trivy less to complain about.

Common Mistake

Forgetting to commit package-lock.json. npm ci fails immediately without it. Run npm install once locally and commit the lock file.

This milestone gives Jenkins the credentials, SonarQube connection and SSH access it needs, and installs Docker on the app server.

Jenkins stores secrets in its credentials store and injects them into a build only when a step asks for them, so they never appear in the Jenkinsfile or the logs.

Prepare the app server first. It needs Docker and the AWS CLI to pull from ECR, and a dedicated deploy key so Jenkins can log in:

Let the jenkins user trust the app server's host key, so SSH never needs host checking turned off:

In the Jenkins UI, go to Manage Jenkins, Credentials, System, Global credentials, and add:

Then configure the two tools:

• Manage Jenkins, System, SonarQube servers: tick environment variables, add a server named sonarqube with URL http://SONARQUBE_PRIVATE_IP:9000 and the sonarqube-token credential
• Manage Jenkins, Tools, SonarQube Scanner installations: add one named sonar-scanner and let it install automatically

Security

Delete deploy_key from your laptop after pasting it into Jenkins, and treat that Jenkins credential as production access. Anyone who can edit a Jenkinsfile can use it, so protect the main branch with required reviews.

Common Mistake

Using the SonarQube public IP in the Jenkins server settings. It works for you, but the public path is closed to Jenkins by design. Use the private IP, which the security group allows.

This milestone writes the pipeline definition. It lives in the repository next to the code, so the delivery process is versioned and reviewed like any other change.

A Jenkinsfile describes the pipeline as stages. Two choices here matter. Tests run inside a node:24-alpine container, so the build server needs no Node.js install and every run uses the same runtime. And the image tag combines the build number and short commit hash, so each deployed version can be traced and rolled back.

Create Jenkinsfile in the repository root. Replace ACCOUNT_ID and APP_PRIVATE_IP:

Commit and push the file:

Tip

--ignore-unfixed makes Trivy report only vulnerabilities that have a fix available. That keeps the gate actionable, because you cannot patch a flaw nobody has patched yet.

Common Mistake

Using when { branch 'main' } in a plain Pipeline job. That condition only works in a Multibranch Pipeline, so the deploy stage is silently skipped on every run. This Jenkinsfile checks GIT_BRANCH instead, which works in both setups.

This milestone creates the Jenkins job and the webhook, so a push to GitHub starts the pipeline without anyone clicking Build.

A webhook is GitHub calling a URL when an event happens. Polling would also work, but it wastes requests and adds delay.

In Jenkins, choose New Item, name it ci-demo-app, select Pipeline, then set:

• Build Triggers: tick GitHub hook trigger for GITScm polling
• Pipeline: Pipeline script from SCM
• SCM: Git, with your repository URL and the github-pat credential if the repo is private
• Branch Specifier: */main
• Script Path: Jenkinsfile

In GitHub, open the repository's Settings, Webhooks, Add webhook:

• Payload URL: http://JENKINS_PUBLIC_IP:8080/github-webhook/
• Content type: application/json
• Events: Just the push event

Run the job once manually with Build Now, because the first run lets Jenkins download the scanner tool and the Node image. GitHub shows a green tick next to the webhook once a delivery succeeds.

Security

This lab uses plain HTTP, so webhook payloads and the Jenkins login travel unencrypted. For a real setup, put Jenkins behind an Application Load Balancer or reverse proxy with an ACM or Let's Encrypt certificate, and enable webhook secrets.

Common Mistake

Leaving the trailing slash off /github-webhook/. Jenkins answers with a redirect or a 404 and GitHub marks the delivery as failed.

This final step proves that the pipeline deploys good code, and that it blocks bad code. Work through the checks in order.

In SonarQube, open the ci-demo-app project and confirm the quality gate shows Passed.

Prove the gate blocks bad code

Add a file with a hardcoded credential and no tests:

Confirm the running version did not change with curl http://APP_PUBLIC_IP/, then remove the file and push again to get back to green.

For an optional Trivy test, temporarily change the first line of the Dockerfile to an old image such as FROM node:18-alpine. The Trivy stage is likely to fail on fixable HIGH findings, which shows the scan is a real gate. Revert the change afterwards.

Clean up

Common Mistake

Terminating only the instances and leaving the ECR repository, security groups and IAM roles behind. Instances stop billing quickly, but forgotten resources clutter the account and security groups cannot be deleted until the instances using them are gone.

Keep screenshots of the green run, the passed and failed quality gates, and the ECR image list. Together with the repository, they are your portfolio evidence for this project.