DevOps & Cloud Interview Guide: MediBot CI/CD Setup

Here is the complete sequence of how this production-grade, GitOps-driven deployment workflow is designed, structured from start to finish.

---

1. Architectural Foundations (GitOps Pattern)

• Two-Repository Git Structure:
  • We use a decoupled repository pattern to avoid CI/CD commit loops:
    • Application Repo (medibot-app): Contains only the application source code, unit tests, Dockerfile, and Jenkins pipeline configuration (Jenkinsfile).
    • Manifests Repo (medibot-manifests): Contains only the environment-specific Kubernetes YAML files (Deployment, Service, ConfigMap, Ingress, HPA).

---

2. Infrastructure as Code (IaC) Phase

• Terraform Provisioning:
  • We use Terraform to provision the entire cloud environment in AWS. This ensures repeatability and avoids drift:
    • Network: A custom VPC with Public Subnets and Route Tables.
    • Compute: Three standalone EC2 instances hosting the supporting DevOps tools (Jenkins, SonarQube, Nexus).
    • Database: An Amazon RDS MySQL database instance.
    • Kubernetes: An Amazon EKS (Elastic Kubernetes Service) cluster (medibot-cluster) with a managed node group.

---

3. Continuous Integration (CI) Phase (Jenkins)

• Trigger: A developer pushes code changes to the main branch of the medibot-app repository. GitHub fires a Webhook to trigger the Jenkins build pipeline.
• Jenkins Pipeline Execution (Jenkinsfile):
  1. Git Checkout: Pulls the application source code from GitHub.
  2. Code Compilation & Tests: Compiles the Spring Boot code and runs Java unit tests using Maven.
  3. Trivy Source Code Scan: Runs a static vulnerability scan on the filesystem to detect security flaws in dependencies.
  4. SonarQube Quality Gate: Sends the source code to SonarQube for static analysis (checking for bugs, vulnerabilities, and code duplication). The pipeline halts if it fails the pre-configured Quality Gate.
  5. Artifact Publishing (Nexus): Packages the code into a JAR file and uploads it to the Nexus Repository Manager as a central artifact repository.
  6. Containerization (Docker Build): Builds a lightweight Docker image containing the application JAR.
  7. Trivy Image Scan: Scans the compiled Docker image layer-by-layer for vulnerabilities before publishing.
  8. ECR Registry Push: Authenticates using IAM credentials and pushes the verified Docker image to Amazon Elastic Container Registry (ECR) with an updated tag (e.g., v3).
  9. Manifest Tag Update: Updates the new image tag (e.g., changing the image from medibot:v2 to medibot:v3) directly inside deployment.yaml in the local clone of the medibot-manifests repo, commits, and pushes the change back to the GitHub manifests repository.

---

4. Continuous Delivery (CD) Phase (ArgoCD GitOps)

• Git Watch: ArgoCD is installed in the EKS cluster and continuously monitors the medibot-manifests repository.
• Drift Detection & Reconciliation:
  • As soon as Jenkins pushes the image tag update to the manifests repository, ArgoCD detects a "drift" between the desired state in Git and the actual state in EKS.
  • ArgoCD automatically pulls the new manifests and applies them (kubectl apply) to the EKS cluster under the webapps namespace.
  • EKS triggers a rolling update deployment: it pulls the new Docker container from Amazon ECR, boots the new pods, and gracefully terminates the older versions.

---

5. Security & IAM Integration (IRSA)

• IAM Roles for Service Accounts (IRSA):
  • Instead of using static access keys (which are security risks) or allowing EKS nodes excessive permissions, we use IRSA to securely connect the app to Amazon Bedrock (for AI patient triage):
    1. OIDC Provider: We associate an IAM OpenID Connect (OIDC) identity provider with the EKS cluster.
    2. IAM Role: We create a dedicated IAM role (medibot-bedrock-sa-role) with a trust policy that permits sts:AssumeRoleWithWebIdentity only if requested by the EKS OIDC provider for the specific Kubernetes ServiceAccount (system:serviceaccount:webapps:medibot-sa).
    3. IAM Policy: We attach a permission policy to the role allowing model invocation (bedrock:InvokeModel*).
    4. ServiceAccount Annotation: We annotate the Kubernetes ServiceAccount in the cluster with the IAM Role ARN.
  • When the application starts, EKS automatically mounts a web identity token. The AWS SDK reads this token to assume the IAM role and authenticate with Bedrock securely.

---

6. Exposure and Day-2 Operations

• Application Ingress:
  • An AWS Load Balancer Controller runs in the cluster. When ArgoCD deploys the Kubernetes Ingress resource, the controller automatically provisions an AWS Application Load Balancer (ALB).
• SSL & Route 53:
  • AWS Certificate Manager (ACM) validates the domain and generates an SSL certificate. Amazon Route 53 maps a custom domain (medibot.kirandevops.xyz) to the ALB for secure HTTPS entry.
• Observability:
  • Prometheus and Grafana are installed using Helm to collect and serialize metrics (cluster resource utilization, node health, and pod statistics) via pre-configured Grafana dashboards.