Moodify-Emotion-Music-App

Moodify Kubernetes Guide

Moodify relies on Kubernetes as the consistent deployment substrate across local development clusters, AWS Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE). The manifests in this directory provide the baseline workloads for the frontend and backend; the cloud-specific guides in ../aws/ and ../gcp/ extend the same primitives with managed ingress, data stores, and platform automation.

Role in the Overall Platform

Repository Layout

File Purpose Notes
frontend-deployment.yaml React single-page app deployment Uses moodify-frontend image; replace hostPath volume with a persistent volume in production.
frontend-service.yaml Service that exposes the frontend Default NodePort for local clusters; switch to LoadBalancer or ingress in managed clouds.
backend-deployment.yaml Django/REST backend deployment Consumes moodify-backend image and ConfigMap values; update environment variables per environment.
backend-service.yaml Internal service for backend traffic ClusterIP for intra-cluster access from the frontend and workers.
configmap.yaml Shared non-secret configuration Overrides runtime settings without rebuilding images.

Reference Architecture

flowchart TB
    User((End Users))
    subgraph Cluster[Kubernetes Cluster]
        direction TB
        subgraph Ingress[Ingress Layer]
            IngressCtrl[Ingress Controller / L7 LB]
        end
        subgraph Services[Service Plane]
            FEsvc[frontend-service\nNodePort/LoadBalancer]
            BEsvc[backend-service\nClusterIP]
            Config[ConfigMap / Secrets]
        end
        subgraph Workloads[Deployments]
            subgraph Frontend
                FE1[Frontend Pod]
                FE2[Frontend Pod]
            end
            subgraph Backend
                BE1[Backend Pod]
                BE2[Backend Pod]
            end
            subgraph Optional[Optional Workloads]
                AI[AI/ML Pods]
                Workers[Celery Workers]
            end
        end
        subgraph External[Managed Data Services]
            Redis[(Redis / ElastiCache / Memorystore)]
            Mongo[(MongoDB / DocumentDB / Firestore)]
            Storage[(Object Storage: S3 / Cloud Storage)]
        end
    end
    User -->|HTTPS| IngressCtrl
    IngressCtrl --> FEsvc
    FEsvc --> Frontend
    Frontend --> BEsvc
    BEsvc --> Backend
    Backend --> External
    Optional --> External
    Config --> Frontend
    Config --> Backend
    class Optional optional;
    class External external;

    classDef optional stroke-dasharray:5 5,fill:#f4f6fb;
    classDef external stroke:#1b5e20,fill:#e8f5e9;

Target Environments

Environment Cluster Provisioning Obtaining kubeconfig Reference
Local development Kind / Minikube / Docker Desktop kind get kubeconfig or minikube kubectl -- get pods Maintain parity with production for quick iteration.
AWS Production EKS via Terraform modules aws eks update-kubeconfig --name moodify-production-eks See ../aws/README.md for Terraform and ECR bootstrap.
GCP Production GKE via Terraform modules gcloud container clusters get-credentials moodify-production-gke --region us-central1 See ../gcp/README.md for node pool and Artifact Registry guidance.

Prerequisites

Quick Start (Local Baseline)

  1. Build images locally 
    docker build -t moodify-frontend:latest ../frontend
docker build -t moodify-backend:latest ../backend
  2. Switch context and namespace 
    kubectl config use-context kind-moodify
kubectl create namespace moodify-local
  3. Apply shared configuration 
    kubectl -n moodify-local apply -f configmap.yaml
  4. Deploy workloads 
    kubectl -n moodify-local apply -f backend-deployment.yaml
kubectl -n moodify-local apply -f backend-service.yaml
kubectl -n moodify-local apply -f frontend-deployment.yaml
kubectl -n moodify-local apply -f frontend-service.yaml
  5. Verify rollout 
    kubectl -n moodify-local get pods,svc
kubectl -n moodify-local port-forward svc/frontend-service 3001:3001

Tip: The provided deployments mount code via hostPath to accelerate local development. Replace these with persistent volumes or baked images before running in managed clusters.

Production Deployment Workflow

AWS (EKS) Notes

GCP (GKE) Notes

Configuration and Secrets

  1. ConfigMap: Update configmap.yaml or create environment-specific overlays. 
    kubectl -n moodify-production apply -f configmap.yaml
  2. Secrets: Store credentials outside source control. 
    kubectl -n moodify-production create secret generic moodify-secrets \
  --from-literal=DJANGO_SECRET_KEY=changeme \
  --from-literal=SPOTIFY_CLIENT_ID=... \
  --from-literal=SPOTIFY_CLIENT_SECRET=...
  3. Mounting: Reference the secret in your deployment with envFrom or explicit valueFrom. Extend the existing deployment manifests as needed.

Storage Considerations

Scaling and Observability

CI/CD Hand-off

sequenceDiagram
    participant Dev as Developer
    participant Git as Git Provider
    participant CI as Jenkins Pipeline
    participant Registry as Container Registry
    participant EKS as AWS EKS
    participant GKE as GCP GKE

    Dev->>Git: Push feature / tag
    Git->>CI: Trigger pipeline
    CI->>CI: Build, lint, test
    CI->>Registry: Push versioned frontend & backend images
    CI->>EKS: kubectl apply -f kubernetes/ (staging ➜ production)
    CI->>GKE: kubectl apply -f kubernetes/ (staging ➜ production)
    EKS-->>CI: Rollout status
    GKE-->>CI: Rollout status
    CI-->>Dev: Notify via Slack/Email

Day-2 Operations Cheat Sheet

Additional References

Keeping the Kubernetes manifests aligned with these guides ensures Moodify behaves consistently across clouds, environments, and release cadence.

This site is open source. Improve this page.