Aviva Financial Services – Jenkins CI/CD on AWS EKS

This repository captures how I designed and implemented a CI/CD and Kubernetes platform for Aviva Financial Services using Jenkins, AWS EKS, Docker, and Prometheus/Grafana.

The goal of this setup is to:

• Build and test a Java-based Aviva API using Jenkins pipelines.
• Package the application as a Docker image and store it in a container registry (ECR/JFrog).
• Deploy the application onto an Amazon EKS cluster using Kubernetes manifests (and optionally Helm).
• Expose the application securely via AWS Load Balancer Controller and Ingress.
• Monitor the platform with Prometheus and Grafana.
• Keep the infrastructure repeatable using Terraform, Packer, Ansible, and eksctl.

The code and structure are based on hands-on lab work I performed, refactored into a clean GitHub project that aligns with real-world DevOps practices.

---

1. High-level architecture

At a high level, the flow is:

• Source Control: Git repository aviva-jenkins-eks-platform
• CI/CD Engine: Jenkins (Declarative multistage, multibranch)
• Application: Java / Spring Boot style “Aviva API” packaged as a JAR, then Docker image
• Container Registry: ECR and/or JFrog Docker registry (configurable)
• Orchestration: Kubernetes on Amazon EKS
• Ingress: AWS Load Balancer Controller + ALB Ingress (TLS + host-based routing)
• Monitoring: Prometheus + Grafana (deployed as Helm charts)
• Infra as Code:
  • Terraform + Packer + Ansible for EC2 / Swarm (legacy path from my practice)
  • eksctl + IAM policies + AWS-auth ConfigMap for EKS cluster provisioning

---

2. Tools and technologies

CI/CD & Build

• Jenkins (Declarative pipelines, multibranch)
• Maven
• SonarQube (optional SAST integration)
• Trivy (Docker image scanning)
• JFrog Artifactory / Docker registry

Cloud & Infra

• AWS (VPC, EC2, EKS, IAM, ALB, CloudWatch)
• Terraform (network + instances – Swarm path)
• Packer (AMI baking)
• Ansible (configuration and Swarm automation)
• eksctl (EKS cluster provisioning)

Kubernetes & Monitoring

• Amazon EKS
• AWS Load Balancer Controller (ALB Ingress)
• Prometheus
• Grafana

---

3. Repository layout

• Jenkins/ – Jenkins Declarative pipelines:

  • Jenkinsfile-ci: build, test, SonarQube, Trivy, Docker build, push.
  • Jenkinsfile-cd-eks: deploy to EKS using kubectl (or Helm), promote across namespaces/environments.
  • Jenkinsfile-infra-swarm: optional – uses Packer + Terraform + Ansible to build Docker Swarm clusters (kept as part of my earlier infra automation practice).
  • Jenkinsfile-infra-eks: optional – helper for running eksctl and basic EKS operations from Jenkins.

• app/ – Aviva API application:

  • pom.xml: Maven configuration (Java 11+).
  • Dockerfile: builds a lightweight JAR-based image.
  • src/: sample controller and health endpoints to demonstrate CI/CD and monitoring.

• infra/aws-eks/ – EKS cluster definition:

  • eksctl-ipv4-cluster.yaml: cluster configuration (name, region, nodegroups).
  • aws-auth.yaml: ConfigMap for node and admin access.
  • create-alb-controller.sh: script to install AWS Load Balancer Controller using Helm.
  • iam_policy.json: IAM policy required by the ALB controller.

• k8s/eks/ – Kubernetes manifests:

  • aviva-api-deployment.yaml: Deployment for the Aviva API (replicas, env vars, probes).
  • aviva-api-service.yaml: Service to expose the pods inside the cluster.
  • aviva-api-ingress.yaml: ALB Ingress with TLS and host-based routing.
  • aviva-fastapi-demo.yaml: optional extra microservice used during EKS practice.
  • voting-app.yaml: optional voting example stack used for EKS feature testing.

• monitoring/:

  • prometheus-values.yaml: Helm values tuned for EKS.
  • grafana-values.yaml: Grafana configuration (admin credentials, datasources).
  • grafana-dashboard.json: example dashboard for API latency, error rates, and pod usage.

• ansible/:

  • docker-swarm.yml, docker-swarm-setfacttesting.yml: kept as reference for earlier Swarm-based automation work.
  • templates/index.j2, ansible.cfg: Jinja2 template and basic configuration.

• security/:

  • sonar-project.properties: SonarQube project metadata.
  • trivy/: template + documentation for exporting Trivy results from Jenkins.

• docs/:

  • architecture-diagram.png: shows Jenkins → ECR → EKS → Prometheus/Grafana flow.
  • ci-cd-pipeline.png: depicts the CI and CD stages from commit to deployment.

---

4. CI/CD flow (Jenkins + EKS)

CI (Jenkinsfile-ci)

Typical steps:

1. Checkout code.
2. Run Maven build and unit tests.
3. Optionally run SonarQube analysis and enforce quality gate.
4. Build Docker image for the Aviva API.
5. Scan image with Trivy and publish the report.
6. Push the image to the configured registry (ECR / JFrog).

CD (Jenkinsfile-cd-eks)

Typical steps:

1. Fetch the latest image tag.
2. Update K8s manifests or Helm values with the new tag.
3. Ensure kubeconfig is updated for the target EKS cluster.
4. Apply manifests:
   • Deployment, Service, Ingress.
5. Run a simple smoke test (curl the Ingress URL).
6. Optionally annotate Prometheus / Grafana for new releases.

---

5. How I use this project

This repository is primarily:

• A portfolio piece to demonstrate my experience with Jenkins, EKS, and monitoring.
• A reference for common patterns: Jenkins pipelines, EKS Ingress, Prometheus+Grafana setup.
• A starting point for future enhancements (HPA, canary releases, external secrets, etc).

It reflects the kind of work I performed as a DevOps Engineer for Aviva Financial Services, with a focus on CI/CD, Kubernetes on AWS, and operational observability.