Nioyatech LLC · Spring PetClinic
Spring PetClinic CI/CD on AWS EKS
Jenkins pipelines that build once and promote the same versioned Helm chart through nightly, QA, staging and production on AWS.
- Discipline
- CI/CD · Containers
- Services
- Spring microservices
- Target
- AWS EKS
- Jenkins
- AWS EKS
- Helm
- ECR
- Rancher
- Terraform
- Ansible
- Maven
- Docker
- Selenium
- Prometheus
- Grafana
Sheet B
Specification
What it is
Spring PetClinic decomposed into microservices, with a Jenkins pipeline that takes a commit through build, test, image publication, and rollout to Kubernetes on AWS.
The application is based on Spring PetClinic. The work covered the delivery side end to end, from build and test through promotion and monitoring.
The pipeline
Maven builds each service and runs its unit tests. Images are tagged with the build number and pushed to AWS ECR, and the Helm chart is versioned and published to an S3-backed chart repository.
The nightly pipeline builds a disposable kubeadm cluster on EC2 with Terraform and Ansible and runs the Selenium suite against it. The weekly QA pipeline deploys to Amazon EKS, staging runs on a Rancher-managed cluster, and production receives the same chart version (see note 1).
Observability
Prometheus scrapes the cluster and the services; Grafana carries the dashboards. The pipeline can report a green build, but a green build that produces a service failing its readiness probe is not a successful delivery. Having the metrics in the same place as the rollout closes that gap.
Sheet C
Notes
2 items
Sheet D
Revisions
What I would change
- 01Move the pipeline to GitHub Actions. Jenkins worked well for this setup, but a self-hosted controller is one more piece of infrastructure to patch and maintain.
- 02Store the Helm charts as OCI artefacts in ECR instead of a separate S3 chart repository, so images and charts live in one registry.