# Automated Cloud Orchestration

### **Overview:**

Modern software delivery is no longer just about writing code; it's about the precision of the delivery pipeline. In this project, we explore a robust "Push-Button" deployment architecture that automates the journey of a Java-based Petstore application from a Git repository to a production-ready Kubernetes (K8s) cluster on AWS.

## The Architectural Blueprint

The goal of this project is to eliminate manual intervention in the deployment process. We use a "Double-Automation" strategy:

1. **Infrastructure Automation:** Terraform provisions the networking (VPC), security groups, and EC2 instances for Jenkins, Ansible, and our K8s nodes.
    
2. **Pipeline Automation:** A Jenkins shared library manages the build/test cycle, while Ansible handles the final deployment logic on the K8s cluster.
    

### The Technology Stack

* **Provisioning:** Terraform (IaC)
    
* **CI/CD:** Jenkins (Pipeline-as-Code)
    
* **Configuration Management:** Ansible
    
* **Orchestration:** Kubernetes (kubeadm)
    
* **Security Scanning:** SonarQube, Trivy, and OWASP Dependency Check
    

## Phase 1: Laying the Foundation (Terraform)

Before we can deploy an app, we need a home for it. Using Terraform, we create a specialized environment in AWS. This includes a Jenkins server, an Ansible controller, and a two-node Kubernetes cluster (Master and Worker).

One critical piece of this phase is the **Application Load Balancer (ALB)**. The ALB acts as the "front door," receiving traffic on port 80 and routing it to the Kubernetes Worker nodes on a specific `NodePort`.

## Phase 2: The Jenkins "Quality Shield" Pipeline

Once the infrastructure is live, the Jenkins pipeline takes over. This isn't just a build script; it’s a security and quality gate.

1. **Code Analysis:** The pipeline pulls the code and runs **SonarQube** to check for "code smells" and bugs.
    
2. **Security Scans:** \* **OWASP:** Checks for vulnerable third-party libraries.
    
    * **Trivy:** Scans the filesystem and the final Docker image for OS-level vulnerabilities.
        
3. **Containerization:** After passing all tests, the app is packaged into a Docker image and pushed to DockerHub.
    

## Phase 3: The Ansible Handoff

The final stage of the Jenkins pipeline doesn't talk to Kubernetes directly. Instead, it triggers **Ansible**.

Why Ansible? It allows for clean, idempotent configuration. The Jenkins pipeline SSHs into the Ansible server and executes a playbook. This playbook copies the Kubernetes deployment manifests to the K8s Master and runs `kubectl apply`.

This ensures that our desired state (e.g., "Run 2 replicas of the Petstore app") is realized by the cluster.

## Why This Approach Works

* **Separation of Concerns:** Jenkins handles the "Process" (Build/Test), while Ansible handles the "State" (Deployment).
    
* **Visibility:** With integration into SonarQube and OWASP, the team has immediate visibility into the security posture of the application before it ever hits production.
    
* **Scalability:** Since the infrastructure is defined in Terraform, scaling from one worker node to ten is a simple variable change.
    

## Conclusion:

By integrating **Terraform, Jenkins, Ansible, and Kubernetes**, we’ve created a pipeline that is both fast and secure. This setup demonstrates how DevOps engineers can move away from manual server "babysitting" and toward a world where the entire lifecycle of an application is managed through code.