View Full Architecture Diagram
👨‍💻 DEVELOPER
  • Action: Edit code, commit
  • Trigger: git push

→ View API source code

Step 1: Code Development

Developer makes changes to the .NET API source code and commits to the local Git repository. Running git push uploads the changes to GitHub, which automatically triggers the CI/CD pipeline.

GITHUB: app-source-code REPOSITORY

Source Repository containing:

  • API Code (Program.cs)
  • Docker Build File (Dockerfile)
  • CI/CD Workflow (build-and-push.yml)

→ View app-source-code folder

Step 2: Source Repository

GitHub repository stores the application source code, Dockerfile for containerization, and GitHub Actions workflow files. When code is pushed, webhooks trigger the automated build pipeline.

(Push Triggers CI/CD Workflow)
GITHUB ACTIONS CI/CD
Build Job:
  1. Login to Azure & ACR
  2. docker build (e.g., signin-api:abc123)
  3. docker push to ACR (Flow 1)
Manifest Update Job:
  1. Checkout app-manifests repo
  2. Update image tag in deployment.yaml (sed command)
  3. git commit and git push (Flow 2)

→ View workflow code

Step 3: Automated CI/CD

GitHub Actions runs two sequential jobs: (1) Build the Docker image and push to Azure Container Registry, (2) After build completes, update the Kubernetes manifest with the new image tag and commit to the manifests repo. This ensures the code and configuration stay in sync.

AZURE CONTAINER REGISTRY (ACR)
Image Stored:
signin-api:main-abc123

→ View build & push code

Step 4a: Container Storage

Azure Container Registry stores the built Docker images. Each image is tagged with a unique identifier (commit SHA) for version tracking. AKS pulls images from here during deployment.

(AKS pulls image from here)
GITHUB: app-manifests REPOSITORY
Kubernetes Manifests Updated:
deployment.yaml has NEW TAG

→ View update code

Step 4b: Manifest Update

Kubernetes manifests repository stores deployment configurations. GitHub Actions automatically updates the image tag in deployment.yaml to match the newly built image, keeping infrastructure as code.

(Flux polls every 1 min)
FLUX CD (GitOps Operator in AKS)
GitRepository Source:
  • Detects new commit in app-manifests repo.
Kustomization:
  • Executes kubectl apply -f deployment.yaml.
  • Triggers a rolling update in the cluster.

→ View Flux installation code

Step 5: GitOps Sync

Flux CD runs inside AKS and continuously monitors the manifests repository. When it detects changes, it automatically applies them to the cluster using kubectl, ensuring the cluster state matches Git (GitOps principle).

AZURE KUBERNETES SERVICE (AKS)
  • Deployment: Pulls new image from ACR.
  • Rolling Update: New Pods (v1.1) replace old Pods (v1.0).
  • Service: LoadBalancer provides access via External IP: 20.30.40.50.

→ View deployment.yaml

Step 6: Kubernetes Deployment

AKS pulls the new Docker image from ACR and performs a rolling update, gradually replacing old pods with new ones to ensure zero downtime. The LoadBalancer service exposes the API to external traffic.

END USER
curl http://20.30.40.50/api/signin
New Version v1.1 Received!

→ View service.yaml

Step 7: User Access

End users access the API through the LoadBalancer's external IP address. They automatically receive responses from the newly deployed version with zero downtime during the update process.