The Certification Preparation Question Bank is an open-source question bank project designed to help learners practice for various certification exams. Currently, it is in beta mode, and I’ll try to actively expand the question sets.

Unlike traditional exam simulations, this platform focuses on practice mode, allowing users to go through questions at their own pace, review answers, and learn effectively.

Currently Available Certification Exams

We are continuously adding new certifications, but as of now, the following exams are included in the question bank:

• AWS AI Practitioner
• (More to come – stay tuned!)

If you are preparing for these certifications, you can start practicing right away!

How to Contribute

This project is open-source, and contributions from the community are highly encouraged! You can help by adding new questions, improving existing ones, or expanding the explanations.

Steps to Contribute:

1. Visit the GitHub repository: Certification Preparation Question Bank
2. Follow the contribution guidelines in the README.md file.
3. Add new questions to the relevant JSON files. You can use This Tool to make life easier.
4. Create a new question bank by creating a JSON file for a Cert.
5. Submit a Pull Request (PR) for review.

Your contributions will help build a valuable learning resource for many aspiring professionals.

Supporting the Project

If you find this project useful, consider supporting it in the following ways:

• Contribute Questions – Help expand the question bank!
• Spread the Word – Share it with others who are preparing for certifications.
• Donate – Your donations will help sustain and grow the project.

Sponsor Me

## What's Next? Since this is an evolving project, we plan to: - Expand the list of certification exams. - Enhance the user experience. - Introduce more features based on user feedback. If you have suggestions, feel free to open an issue in the GitHub repository. Stay tuned for updates, and happy learning!

1. Simplifies Application Deployment

• Helm charts provide a single, versioned package for deploying complex applications.

• Instead of managing multiple YAML files, you can deploy an application with a single command:

  helm install my-app ./my-chart
  

2. Reusability

• Helm charts are reusable across environments (e.g., dev, staging, production).

• You can create a chart once and use it for multiple deployments with different configurations.

3. Parameterization

• Helm charts support values.yaml files, which allow you to customize deployments without modifying the chart itself.

• Example:

  # values.yaml
  replicaCount: 3
  image:
    repository: my-app
    tag: latest
  

• You can override these values during installation:

  helm install my-app ./my-chart --set replicaCount=5
  

4. Versioning

• Helm charts are versioned, making it easy to roll back to a previous version if something goes wrong:

  helm rollback my-app 1.0.0
  

5. Dependency Management

• Helm charts can define dependencies on other charts, simplifying the deployment of multi-component applications.

• Example: A web application chart might depend on a Redis or PostgreSQL chart.

6. Community and Ecosystem

• Helm has a large community and a rich ecosystem of prebuilt charts available in the Artifact Hub.

• You can use these charts to deploy popular applications (e.g., Prometheus, Grafana, WordPress) with minimal effort.

7. Standardization

• Helm provides a standardized way to package and deploy applications, making it easier for teams to collaborate and share configurations.

8. Lifecycle Management

• Helm supports lifecycle hooks (e.g., pre-install, post-upgrade) to execute custom logic during deployment.

Usability

Example Workflow with Helm

1. Develop a Helm chart for your application.

2. Store the chart in a version control system (e.g., Git).

3. Use Helm to deploy the application to different environments (e.g., dev, staging, production) with environment-specific configurations.

4. Monitor and update the application using Helm’s upgrade and rollback features.

Challenges of Not Using Helm Charts

1. Manual YAML Management:

   • Without Helm, teams must manually manage multiple YAML files for deployments, services, config maps, etc.

   • This can be error-prone and time-consuming, especially for complex applications.

2. Lack of Standardization:

   • Each team might use its own approach to deploying applications, leading to inconsistencies and inefficiencies.

3. Difficulty in Reusability:

   • Without Helm, reusing configurations across environments or applications becomes challenging, leading to duplication of effort.

4. No Versioning:

   • Without Helm, there’s no built-in versioning for application configurations, making it harder to track changes and roll back to previous versions.

5. Complex Dependency Management:

   • Managing dependencies (e.g., databases, message queues) becomes more complex without Helm’s dependency management features.

6. Limited Ecosystem Integration:

   • Without Helm, companies miss out on the rich ecosystem of prebuilt charts and community support.

Example Workflow Without Helm

1. Manually create and manage YAML files for each Kubernetes resource.

2. Copy and modify YAML files for different environments, increasing the risk of errors.

3. Deploy applications using kubectl apply:

   kubectl apply -f deployment.yaml -f service.yaml -f configmap.yaml
   

4. Manually track changes and roll back deployments if necessary.

When Should a Company Use Helm Charts?

• Complex Applications: If your application has multiple components (e.g., microservices, databases, message queues), Helm simplifies deployment and management.

• Multi-Environment Deployments: If you deploy applications to multiple environments (e.g., dev, staging, production), Helm ensures consistency and reusability.

• Frequent Updates: If your application requires frequent updates, Helm’s versioning and rollback features are invaluable.

• Team Collaboration: If multiple teams are involved in deploying and managing applications, Helm provides a standardized approach.

Hands-on

Step 1: Install Helm

Ensure Helm is installed before proceeding.

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Verify the installation:

helm version

Step 2: Create a Helm Chart

Let’s create a Helm chart for a simple Node.js app with PostgreSQL.

helm create myapp cd myapp

This creates a folder structure like:

myapp/
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── _helpers.tpl
│   ├── NOTES.txt
├── values.yaml
├── Chart.yaml

Step 3: Define Application Configuration

Modify Chart.yaml with details:

Chart.yaml

apiVersion: v2
name: myapp
description: A Helm chart for deploying a Node.js app with PostgreSQL
version: 1.0.0
appVersion: "1.0"

values.yaml (customizable settings)

replicaCount: 2

image:
  repository: mydockerhub/myapp
  tag: latest
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false

postgresql:
  enabled: true
  username: admin
  password: secret
  database: myappdb

Step 4: Define Kubernetes Resources

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: -app
spec:
  replicas: 
  selector:
    matchLabels:
      app: 
  template:
    metadata:
      labels:
        app: 
    spec:
      containers:
      - name: myapp
        image: ":"
        ports:
        - containerPort: 3000

templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: -service
spec:
  type: 
  selector:
    app: 
  ports:
    - protocol: TCP
      port: 
      targetPort: 3000

Step 5: Deploy the Helm Chart

1️⃣ Package the Chart

helm package myapp

2️⃣ Install the Chart

helm install myapp ./myapp

3️⃣ List Deployed Charts

helm list

4️⃣ Check Running Services

kubectl get pods
kubectl get svc

5️⃣ Uninstall the Chart

helm uninstall myapp

Step 6: Helm Repositories & Chart Distribution

1️⃣ Add a Helm Repository

helm repo add bitnami https://charts.bitnami.com/bitnami
helm search repo bitnami

2️⃣ Upgrade a Helm Release

helm upgrade myapp ./myapp

3️⃣ Rollback to a Previous Version

helm rollback myapp 1

Remarks

Using Helm charts for Kubernetes application deployment offers significant advantages in terms of simplicity, reusability, parameterization, versioning, and standardization.

Companies that adopt Helm can streamline their deployment processes, reduce errors, and improve collaboration. On the other hand, not using Helm can lead to manual, error-prone, and inconsistent deployment workflows, especially for complex applications.

For most organizations, especially those managing large-scale or complex Kubernetes deployments, Helm is a highly recommended tool.

Key Takeaways:
✅ Helm simplifies Kubernetes deployments with reusable templates.
✅ It provides versioning, rollback, and environment-based configurations.
✅ Helm Charts can package complex applications with dependencies.

What’s Next?
🔹 Day 37: Kubernetes Security Best Practices
🔹 Day 38: Scaling Kubernetes Applications with Horizontal Pod Autoscaler

GitHub Actions for CI (Continuous Integration)

GitHub Actions is a robust CI/CD platform integrated directly into GitHub repositories. It excels at automating build, test, and packaging workflows. Here’s why it’s great for CI:

a. Tight Integration with GitHub

• GitHub Actions is natively integrated into GitHub, making it easy to trigger workflows based on repository events (e.g., push, pull request, release).

• No need for external CI tools; everything is managed within GitHub.

b. Extensive Ecosystem

• GitHub Actions has a large marketplace of prebuilt actions for common tasks (e.g., building Docker images, running tests, deploying to cloud providers).

• You can easily extend workflows with custom actions.

c. Scalability

• GitHub Actions supports parallel jobs and matrix builds, enabling efficient testing across multiple environments or configurations.

d. Artifact Management

• GitHub Actions can build and push Docker images to container registries (e.g., Docker Hub, GitHub Container Registry, AWS ECR).

• It can also generate and store build artifacts (e.g., binaries, Helm charts).

Why Combine GitHub Actions and Argo CD?

a. Separation of Concerns

• GitHub Actions handles the CI part: building, testing, and packaging applications.

• Argo CD handles the CD part: deploying and managing applications in Kubernetes.

• This separation ensures that each tool focuses on its strengths.

b. End-to-End Automation

• GitHub Actions can trigger Argo CD to deploy applications after a successful build.

• This creates a fully automated pipeline from code commit to production deployment.

c. GitOps Workflow

• GitHub Actions pushes changes (e.g., Docker images, Helm charts) to Git repositories.

• Argo CD picks up these changes and deploys them to Kubernetes, ensuring a GitOps workflow.

d. Scalability and Flexibility

• GitHub Actions scales well for CI tasks, while Argo CD scales for managing complex Kubernetes deployments.

• Both tools are highly flexible and can be customized to fit your workflow.

e. Auditability and Traceability

• All changes are tracked in Git, providing a clear audit trail and enabling rollbacks.

• GitHub Actions logs and Argo CD’s synchronization history provide visibility into the pipeline.

4. Example Workflow: GitHub Actions + Argo CD

Here’s how the two tools can work together in a CI/CD pipeline:

1. Code Push:

   • A developer pushes code to the main branch in GitHub.

2. GitHub Actions CI:

   • GitHub Actions triggers a CI workflow:

     • Builds the application.

     • Runs tests.

     • Builds and pushes a Docker image to a container registry.

     • Updates the Kubernetes manifests (e.g., Helm chart) in the Git repository with the new image tag.

3. Argo CD CD:

   • Argo CD detects changes in the Git repository.

   • It syncs the new application state to the Kubernetes cluster.

   • The application is deployed to the desired environment (e.g., staging or production).

Alright, now, let’s set up both for an example Kubernetes environment.

Set up CI/CD Pipeline

Step 1: Set Up Your Kubernetes & ArgoCD Environment

Before starting, ensure you have:

✅ A Kubernetes cluster (Minikube, Kind, EKS, GKE, AKS, etc.)
✅ ArgoCD installed in your cluster (Day 34 Guide)
✅ A GitHub repository with Kubernetes manifests

Step 2: Create a GitHub Actions Workflow for CI

** Create .github/workflows/ci.yaml**

This CI pipeline will:

• Build and tag a Docker image
• Push it to GitHub Container Registry (GHCR) or Docker Hub

.github/workflows/ci.yaml

name: CI - Build & Push Docker Image

on:
  push:
    branches:
      - main
    paths:
      - "app/**"  # Only trigger when app code changes

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Log in to GitHub Container Registry
        run: echo "$" | docker login ghcr.io -u $ --password-stdin

      - name: Build Docker Image
        run: docker build -t ghcr.io/$/myapp:$ -f app/Dockerfile .

      - name: Push Image to GHCR
        run: docker push ghcr.io/$/myapp:$

Set up GitHub Secrets:

• GHCR_PAT: GitHub Container Registry Personal Access Token
• DOCKERHUB_USERNAME, DOCKERHUB_PASSWORD: (if using Docker Hub instead)

Step 3: Automate Kubernetes Deployment with CD

** Create .github/workflows/cd.yaml**

This workflow:

• Updates Kubernetes manifests with the new image tag
• Pushes changes to the GitOps repository
• ArgoCD automatically syncs and deploys the new version

.github/workflows/cd.yaml

name: CD - Deploy to Kubernetes via ArgoCD

on:
  workflow_run:
    workflows: ["CI - Build & Push Docker Image"]
    types:
      - completed

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout GitOps Repository
        uses: actions/checkout@v3
        with:
          repository: <your-gitops-repo>
          token: $

      - name: Update Kubernetes Deployment YAML
        run: |
          sed -i "s|image: .*|image: ghcr.io/$/myapp:$|" k8s/deployment.yaml

      - name: Commit and Push Changes
        run: |
          git config --global user.name "GitHub Actions"
          git config --global user.email "actions@github.com"
          git add k8s/deployment.yaml
          git commit -m "Update deployment image to $"
          git push

How It Works?

1. CI Workflow builds & pushes the Docker image.
2. CD Workflow updates deployment.yaml with the new image tag.
3. ArgoCD auto-syncs the changes and deploys the updated version.

Step 4: Create an ArgoCD Application for GitOps

ArgoCD watches your Git repository and applies changes automatically.

argocd-application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/<your-gitops-repo>.git
    targetRevision: main
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Apply it:

kubectl apply -f argocd-application.yaml

Step 5: Test the Pipeline

1️⃣ Make a Code Change

Modify app/main.py and push changes to main:

git commit -am "Update application logic" git push origin main

2️⃣ Observe CI/CD Pipeline

• GitHub Actions runs the CI workflow → Builds & pushes Docker image
• GitHub Actions runs the CD workflow → Updates deployment.yaml
• ArgoCD auto-syncs & deploys the updated application

3️⃣ Verify Deployment

kubectl get pods
kubectl get svc

Check your ArgoCD UI → The new version is deployed automatically!

Final Thoughts

Key Takeaways
✅ CI/CD with GitHub Actions + ArgoCD enables fully automated Kubernetes deployments
✅ GitOps approach ensures consistency, security, and easy rollbacks
✅ ArgoCD eliminates manual kubectl apply commands
✅ Scalable CI/CD for cloud-native applications

Alternatives While GitHub Actions and Argo CD are a great combination, here are some alternatives:

• Jenkins + Argo CD: Use Jenkins for CI and Argo CD for CD.

• GitLab CI/CD + Argo CD: Use GitLab CI/CD for CI and Argo CD for CD.

• Tekton + Argo CD: Use Tekton for CI and Argo CD for CD.

Combining GitHub Actions for CI and Argo CD for CD is a proper choice for Kubernetes-based CI/CD pipelines. It provides a seamless, automated, and GitOps-driven workflow that ensures consistency, scalability, and visibility. This combination is particularly well-suited for teams already using GitHub and looking to adopt modern DevOps practices.

What’s Next?
🔹 Day 36: Kubernetes Helm Charts 🔹 Day 37: Kubernetes Deployment using Terraform

1. GitOps Principles

• Declarative Configuration: Argo CD uses YAML manifests stored in Git repositories to define the desired state of applications.

• Version Control: All changes are tracked in Git, providing a clear audit trail and enabling rollbacks.

• Automation: Argo CD continuously monitors the Git repository and automatically syncs the cluster state with the desired state.

2. Continuous Delivery

• Argo CD ensures that the Kubernetes cluster is always in sync with the desired state defined in Git.

• It supports automated deployments, reducing manual intervention and human error.

3. Multi-Environment Support

• Argo CD can manage applications across multiple environments (e.g., dev, staging, production) using the same Git repository.

4. Self-Healing

• If the cluster state drifts from the desired state (e.g., due to manual changes), Argo CD can automatically correct it.

5. User Interface

• Argo CD provides a web-based UI for visualizing applications, their status, and synchronization state.

6. Integration with Kubernetes Ecosystem

• Argo CD integrates seamlessly with Helm, Kustomize, and other Kubernetes tools.

• It supports multi-cluster deployments and can manage applications across multiple Kubernetes clusters.

Today, we’ll set up ArgoCD, deploy an app using GitOps, and automate Kubernetes deployments.

Step 1: Install ArgoCD in Kubernetes

Deploy ArgoCD in the argocd namespace:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Wait for the pods to be ready:

kubectl get pods -n argocd

Expose the ArgoCD UI:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Now, access ArgoCD UI at: https://localhost:8080

Step 2: Login & Change ArgoCD Admin Password

Fetch the default admin password:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

Login to ArgoCD CLI:

argocd login localhost:8080 --username admin --password <your-password>

Change the password:

argocd account update-password

Step 3: Deploy an App Using GitOps

1️⃣ Prepare the Git Repository

Create a GitHub repository (e.g., k8s-gitops-demo) with the following structure:

k8s-gitops-demo/
├── manifests/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
└── .gitignore

2️⃣ Define Kubernetes Manifests

manifests/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx:latest
        ports:
        - containerPort: 80

manifests/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

3️⃣ Push Code to Git

git init
git add .
git commit -m "Initial Kubernetes manifests" git branch -M main
git remote add origin https://github.com/<your-username>/k8s-gitops-demo.git
git push -u origin main

Step 4: Create an ArgoCD Application

Create an ArgoCD Application that syncs with your Git repository.

argocd-application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/<your-username>/k8s-gitops-demo.git
    targetRevision: main
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Apply it:

kubectl apply -f argocd-application.yaml

Check the app status:

argocd app list

Verify deployment:

kubectl get pods
kubectl get svc

Step 5: Automate Deployments with GitOps

1️⃣ Make a Change in Git
Modify deployment.yaml to use a different image (e.g., nginx:1.23).
Commit & push the change:

git commit -am "Updated image version" git push origin main

2️⃣ ArgoCD Auto-Syncs Changes
Check the ArgoCD UI—your deployment will automatically update!

Step 6: Rollback with ArgoCD

If a deployment breaks, rollback easily:

argocd app history myapp
argocd app rollback myapp 2

Now, the app is restored to version 2.

Remarks

Key Takeaways
✅ ArgoCD automates Kubernetes deployments using Git
✅ GitOps ensures consistency, auditability, and automation
✅ Auto-sync eliminates manual kubectl apply commands
✅ Rollback instantly using ArgoCD commands

While GitHub Actions and Argo CD are a great combination, here are some alternatives:

• Jenkins + Argo CD: Use Jenkins for CI and Argo CD for CD.

• GitLab CI/CD + Argo CD: Use GitLab CI/CD for CI and Argo CD for CD.

• Tekton + Argo CD: Use Tekton for CI and Argo CD for CD.

What’s Next?
🔹 Day 35: Kubernetes CI/CD Pipeline with GitHub Actions & ArgoCD
🔹 Day 36: Securing Kubernetes Workloads with Network Policies

• Detect performance bottlenecks before they impact users
• Visualize metrics such as CPU, memory, and request rates
• Set up alerts for failures or resource exhaustion
• Improve system reliability and proactively respond to issues

Today, we’ll install, configure, and visualize Kubernetes metrics using Prometheus & Grafana on Minikube.

Step 1: Enable Monitoring Addons in Minikube

Minikube provides a built-in Prometheus-Grafana stack. To enable it:

minikube addons enable metrics-server
minikube addons enable prometheus
minikube addons enable grafana

Check running pods:

kubectl get pods -n monitoring

Step 2: Access Prometheus & Grafana

Access Prometheus Dashboard

Forward the Prometheus service to your local machine:

kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090

Now, open http://localhost:9090 in your browser.

Access Grafana Dashboard

Forward Grafana service:

kubectl port-forward -n monitoring svc/grafana 3000:3000

Now, open http://localhost:3000
(Default login: admin / prom-operator)

Step 3: Configure Prometheus to Collect Metrics

Prometheus scrapes metrics from Kubernetes using ServiceMonitors. Let’s define one.

prometheus-servicemonitor.yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
  namespace: myapp
spec:
  selector:
    matchLabels:
      app: backend
  endpoints:
  - port: http
    interval: 15s

Apply it:

kubectl apply -f prometheus-servicemonitor.yaml

Now, Prometheus will scrape metrics every 15 seconds from the backend service.

Step 4: Expose Application Metrics

By default, Prometheus expects an endpoint like /metrics to collect data. Let’s modify our backend to expose metrics.

backend/app.py

from flask import Flask
from prometheus_client import start_http_server, Counter

app = Flask(__name__)
REQUESTS = Counter('http_requests_total', 'Total number of HTTP requests')

@app.route("/")
def home():
    REQUESTS.inc()
    return "Hello, Kubernetes Monitoring!"

if __name__ == "__main__":
    start_http_server(8000)  # Expose metrics on /metrics
    app.run(host="0.0.0.0", port=5000)

Rebuild and restart the backend:

docker build -t my-backend .
kubectl rollout restart deployment backend

Verify metrics:

curl http://backend:8000/metrics

Step 5: Visualize Metrics in Grafana

Import Prometheus as a Data Source

1. Open Grafana (http://localhost:3000)
2. Go to Configuration > Data Sources > Add Data Source
3. Select Prometheus
4. Enter http://prometheus-k8s.monitoring.svc:9090 as the URL
5. Click Save & Test

Import a Prebuilt Dashboard

1. Go to Dashboards > Import
2. Use ID: 3119 (Kubernetes Cluster Monitoring)
3. Click Load and Import

Now we can see real-time Kubernetes metrics!

Please, note that Grafana provides a variety of prebuilt dashboard templates that you can import and use directly. These templates are often available in the Grafana Dashboards library or shared by the community.

Some other example dashboards for Kubernetes are:

• Kubernetes Cluster Monitoring - ID: 315

• Kubernetes Node Monitoring - ID: 6417

Step 6: Set Up Alerts with Prometheus Alertmanager

Well, now, let’s define an Alert Rule:

# alert-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: high-cpu-alert
  namespace: monitoring
spec:
  groups:
  - name: instance-rules
    rules:
    - alert: HighCPUUsage
      expr: rate(container_cpu_usage_seconds_total[2m]) > 0.5
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "High CPU Usage Detected"
        description: "CPU usage is above 50% for more than 2 minutes."

Apply it:

kubectl apply -f alert-rules.yaml

Prometheus will now trigger an alert if CPU usage exceeds 50% for 2 minutes.

Remarks

Key Takeaways
✅ Prometheus collects metrics from Kubernetes workloads
✅ Grafana visualizes metrics in real-time dashboards
✅ ServiceMonitors configure scraping rules for Prometheus
✅ Alerts notify teams when performance degrades

What’s Next?
🔹 Day 34: Automating Kubernetes Deployments with ArgoCD & GitOps
🔹 Day 35: Building a Kubernetes CI/CD Pipeline

✅ Ingress Controller for external access
✅ ConfigMaps & Secrets for secure configuration
✅ Helm Charts for easier deployment management

Step 1: Add an Ingress Controller for External Access

By default, Kubernetes services are only accessible inside the cluster. Instead of using NodePort, we will configure an Ingress Controller to route requests.

Install Ingress Controller on Minikube

minikube addons enable ingress

Define an Ingress Resource

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  namespace: myapp
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.local
    http:
      paths:
      - path: /backend
        pathType: Prefix
        backend:
          service:
            name: backend
            port:
              number: 5000
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend
            port:
              number: 3000

Apply the Ingress Configuration

kubectl apply -f ingress.yaml

Test the Ingress

Update /etc/hosts (Linux/macOS) to map myapp.local to Minikube’s IP:

echo  "$(minikube ip) myapp.local" | sudo tee -a /etc/hosts

Now, visit http://myapp.local/ for the frontend and http://myapp.local/backend for the backend!

Step 2: Use ConfigMaps & Secrets for Secure Configuration

Instead of hardcoding environment variables, we will use ConfigMaps and Secrets.

Create a ConfigMap for Database URL

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: myapp
data:
  DATABASE_URL: "postgresql://user:password@postgres:5432/mydatabase"

Create a Secret for Database Credentials

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
  namespace: myapp
type: Opaque
data:
  POSTGRES_USER: dXNlcg==  # Base64 encoded 'user'
  POSTGRES_PASSWORD: cGFzc3dvcmQ=  # Base64 encoded 'password'

Modify Backend Deployment to Use ConfigMap & Secret

backend-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: python:3.10
        env:
        - name: DATABASE_URL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: DATABASE_URL
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: POSTGRES_USER
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: POSTGRES_PASSWORD
        ports:
        - containerPort: 5000

Apply ConfigMaps & Secrets

kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl apply -f backend-deployment.yaml

Step 3: Use Helm Charts for Deployment Management

Manually managing Kubernetes YAML files is tedious. Instead, we can use Helm, the package manager for Kubernetes.

Install Helm

brew install helm # macOS 
choco install kubernetes-helm # Windows

Create a Helm Chart

helm create myapp-chart

Modify Helm Chart to Deploy the App

Inside myapp-chart/values.yaml, update the service and deployment values.

myapp-chart/values.yaml

backend:
  image: python:3.10
  service:
    type: ClusterIP
    port: 5000

frontend:
  image: node:18
  service:
    type: ClusterIP
    port: 3000

database:
  image: postgres:15
  service:
    type: ClusterIP
    port: 5432
  env:
    POSTGRES_USER: user
    POSTGRES_PASSWORD: password
    POSTGRES_DB: mydatabase

Deploy the Application using Helm

helm install myapp ./myapp-chart

Check the Helm Deployment

helm list
kubectl get pods -n myapp

Upgrade the Helm Release

If you modify the configuration:

helm upgrade myapp ./myapp-chart

Uninstall the Helm Release

helm uninstall myapp

Final Thoughts

Key Takeaways
✅ Ingress Controllers expose applications externally with routing rules
✅ ConfigMaps & Secrets store environment variables securely
✅ Helm simplifies Kubernetes deployments with reusable charts

What’s Next?
🔹 Day 33: Monitoring Kubernetes Apps with Prometheus & Grafana
🔹 Day 34: CI/CD Pipelines for Kubernetes Deployments

Stay tuned for more Kubernetes posts in the #100DaysOfSRE series!

✅ Define a Docker-Compose setup with a Python backend, frontend, and PostgreSQL
✅ Convert it into Kubernetes manifests (YAML files)
✅ Deploy the Kubernetes setup on Minikube

Docker-Compose Setup

Well, in my previous posts, we have already seen how to set up docker-compose to deploy a full-stack service. Let’s revise that first before we start learning how to write kubernetes manifest files.

Here’s how we can define our docker-compose.yml for a simple Python backend, frontend, and a PostgreSQL database.

docker-compose.yml

version: "3.8"

services:
  db:
    image: postgres:15
    container_name: postgres_db
    restart: always
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydatabase
    ports:
      - "5432:5432"

  backend:
    image: python:3.10
    container_name: backend
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://user:password@db:5432/mydatabase
    ports:
      - "5000:5000"
    command: ["python", "-m", "http.server", "5000"]

  frontend:
    image: node:18
    container_name: frontend
    depends_on:
      - backend
    ports:
      - "3000:3000"
    command: ["npx", "http-server", "-p", "3000"]

How to run this?

docker-compose up -d

This works great in development, but for production, we need Kubernetes.

Convert Docker-Compose to Kubernetes Manifest Files

The major config difference between docker-compose and kubernetes is, we write everything on a single manifest file when using docker-compose.

However, on Kubernetes, we need to create Kubernetes YAML files for each component:

✅ Deployments (for backend, frontend, database)
✅ Services (to expose them inside Kubernetes)
✅ Persistent Volume for PostgreSQL

Project Structure

So, this is what a similar full-stack service with three components project structure would look like if we wanna deploy on Kubernetes.

k8s-app/
│── db/
│   ├── db-deployment.yaml
│   ├── db-service.yaml
│── backend/
│   ├── backend-deployment.yaml
│   ├── backend-service.yaml
│── frontend/
│   ├── frontend-deployment.yaml
│   ├── frontend-service.yaml
│── namespace.yaml

Database Deployment (PostgreSQL)

db/db-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_USER
          value: "user"
        - name: POSTGRES_PASSWORD
          value: "password"
        - name: POSTGRES_DB
          value: "mydatabase"
        ports:
        - containerPort: 5432

db/db-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: myapp
spec:
  selector:
    app: postgres
  ports:
    - protocol: TCP
      port: 5432
      targetPort: 5432

Backend Deployment

backend/backend-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: python:3.10
        env:
        - name: DATABASE_URL
          value: "postgresql://user:password@postgres:5432/mydatabase"
        ports:
        - containerPort: 5000
        command: ["python", "-m", "http.server", "5000"]

backend/backend-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: myapp
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 5000
      targetPort: 5000

Frontend Deployment

frontend/frontend-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: node:18
        ports:
        - containerPort: 3000
        command: ["npx", "http-server", "-p", "3000"]

frontend/frontend-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: frontend
  namespace: myapp
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
  type: NodePort

Namespace File

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: myapp

Deploy the Application on Minikube

1️⃣ Start Minikube

minikube start

2️⃣ Apply Kubernetes manifests

kubectl apply -f namespace.yaml
kubectl apply -f db/db-deployment.yaml
kubectl apply -f db/db-service.yaml
kubectl apply -f backend/backend-deployment.yaml
kubectl apply -f backend/backend-service.yaml
kubectl apply -f frontend/frontend-deployment.yaml
kubectl apply -f frontend/frontend-service.yaml

3️⃣ Check the status

kubectl get all -n myapp

4️⃣ Get frontend service URL

minikube service frontend -n myapp

Now we have deployed your full-stack app on Minikube!

Remarks

Key Takeaways
✅ Docker-Compose is great for local development.
✅ Kubernetes manifests provide scalability, high availability, and production readiness.
✅ Minikube helps us test Kubernetes locally before deploying to the cloud.

Next Steps

• Add a Kubernetes Ingress Controller
• Implement ConfigMaps & Secrets for better security
• Use Helm Charts to manage deployment configurations

This post provides a cheatsheet of essential commands followed by scenario-based examples to simulate real-world Kubernetes tasks.

Kubernetes Command Cheatsheet

🔹 Minikube Management

🔹 Cluster & Node Information

🔹 Managing Pods

🔹 Managing Deployments

🔹 Exposing Services

Scenario-Based Kubernetes Operations in Minikube

Scenario 1: Deploy a Simple Web Application

Goal: Deploy an Nginx web server and expose it via a service.

Steps:

1️⃣ Create a deployment for Nginx

kubectl create deployment nginx --image=nginx --replicas=2

2️⃣ Expose the deployment as a NodePort service

kubectl expose deployment nginx --type=NodePort --port=80

3️⃣ Get the external service URL using Minikube

minikube service nginx --url

4️⃣ Open the application in a browser

minikube service nginx

Scenario 2: Scale an Application Dynamically

Goal: Scale the Nginx deployment from 2 to 5 replicas.

Steps:

1️⃣ Check current pods

kubectl get pods

2️⃣ Scale deployment

kubectl scale deployment nginx --replicas=5

3️⃣ Verify the scaling

kubectl get pods

Scenario 3: Rolling Update & Rollback

Goal: Update the Nginx version and roll it back if something goes wrong.

Steps:

1️⃣ Check the current deployment

kubectl get deployments

2️⃣ Update the deployment to use nginx:1.23

kubectl set image deployment/nginx nginx=nginx:1.23

3️⃣ Check the rollout status

kubectl rollout status deployment/nginx

4️⃣ If the new version is unstable, rollback

kubectl rollout undo deployment/nginx

Scenario 4: Debugging a Failing Pod

Goal: Troubleshoot a pod that is stuck in CrashLoopBackOff.

Steps:

1️⃣ List pods and find the problematic one

kubectl get pods

2️⃣ Check pod logs

kubectl logs <pod-name>

3️⃣ Describe the pod for detailed information

kubectl describe pod <pod-name>

4️⃣ Get into the pod’s shell (if running)

kubectl exec -it <pod-name> -- /bin/sh

5️⃣ Delete and restart the pod

kubectl delete pod <pod-name>

Scenario 5: Deploying a Multi-Tier App with Minikube

Goal: Deploy a frontend and backend in Kubernetes.

Steps:

1️⃣ Deploy a backend API

kubectl create deployment backend --image=python:3.10-slim

2️⃣ Expose backend via a ClusterIP

kubectl expose deployment backend --port=5000 --type=ClusterIP

3️⃣ Deploy a React frontend

kubectl create deployment frontend --image=node:18-alpine

4️⃣ Expose frontend as a LoadBalancer

kubectl expose deployment frontend --port=3000 --type=LoadBalancer

5️⃣ Get the service URL

minikube service frontend

Now we have a full-stack app running in Kubernetes!

Remarks

Minikube is a powerful tool for learning and testing Kubernetes commands in a local environment.

By practicing these scenario-based tasks, we can become comfortable with real-world Kubernetes operations before deploying in production.

Key Takeaways

• Minikube helps you test Kubernetes locally.
• You can create, scale, and troubleshoot applications easily.
• Kubernetes commands allow rolling updates, service exposure, and debugging in a structured way.

Next Steps

• Try deploying stateful applications with Persistent Volumes.
• Experiment with Ingress controllers in Minikube.
• Learn about Kubernetes Helm Charts for app deployment automation.

Stay tuned for more Kubernetes posts in the #100DaysOfSRE series!

Kubernetes (K8s) is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications.

It helps organizations deploy applications at scale, handle failures gracefully, and manage hundreds or thousands of containers efficiently.

Key Features of Kubernetes:

✅ Self-healing – Restarts failed containers automatically
✅ Auto-scaling – Adjusts resources based on real-time demand
✅ Service discovery & load balancing – Built-in traffic management
✅ Rolling updates & rollbacks – Ensures zero-downtime deployments
✅ Multi-cloud & hybrid-cloud support – Runs on AWS, GCP, Azure, on-prem, etc.

🐳 Kubernetes vs. Docker Compose – Why Kubernetes for Production?

While Docker Compose is great for local development, Kubernetes is the preferred solution for enterprise production deployments.

💡 TL;DR: Docker Compose is great for testing and development, but Kubernetes is the industry standard for production because it provides better automation, scalability, resilience, and multi-cloud support.

Why Enterprises Choose Kubernetes

1️⃣ Handles Large-Scale Deployments

For companies running thousands of microservices, Kubernetes makes scaling effortless with Horizontal Pod Autoscaling (HPA).

Example:

• Netflix, Uber, and Airbnb use Kubernetes to manage thousands of microservices across cloud regions.

2️⃣ Built-In High Availability

Kubernetes runs applications in multiple replicas across different nodes, ensuring zero downtime even if a node fails.

3️⃣ Cloud-Native & Multi-Cloud Ready

With AWS EKS, GCP GKE, and Azure AKS, enterprises can deploy Kubernetes clusters without vendor lock-in.

Example:

• Spotify migrated from on-prem servers to Google Kubernetes Engine (GKE) for better cloud scalability.

4️⃣ DevOps & GitOps Friendly

Kubernetes integrates seamlessly with CI/CD pipelines using ArgoCD, GitHub Actions, and Jenkins for automated deployments.

Example:

• Adobe uses Kubernetes with ArgoCD for GitOps, ensuring secure and automated deployments.

5️⃣ Secure & Policy-Driven

With tools like Kubernetes RBAC (Role-Based Access Control), Istio (Service Mesh), and Open Policy Agent (OPA), enterprises can enforce strict security policies.

Getting Started with Kubernetes Locally

Option 01: Running Minikube on Host

You can install a lightweight Kubernetes cluster on your local machine using Minikube or Kind.

• Install Minikube

  $ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
  $ sudo install minikube-linux-amd64 /usr/local/bin/minikube
  $ minikube start
  

• Deploy a Sample Application

$ kubectl create deployment my-app --image=nginx
$ kubectl expose deployment my-app --type=LoadBalancer --port=80
$ minikube service my-app

Option 02: Testing Minikube inside docker

Running Minikube inside a Docker container is not straightforward because Minikube itself requires a virtualization layer (such as Docker, VirtualBox, or KVM) to create a Kubernetes cluster. However, you can run Minikube inside a Docker container using the none driver, which runs Kubernetes components directly on the host.

Here’s a Dockerfile that sets up a containerized environment to run Minikube using Docker as the driver:

Dockerfile for Running Minikube

FROM ubuntu:22.04

# Set environment variables
ENV KUBECTL_VERSION=v1.27.3 \
    MINIKUBE_VERSION=v1.30.1

# Install dependencies
RUN apt-get update && apt-get install -y \
    curl \
    ca-certificates \
    conntrack \
    iptables \
    socat \
    ebtables \
    ethtool \
    sudo \
    docker.io \
    && apt-get clean

# Install kubectl
RUN curl -Lo /usr/local/bin/kubectl https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl && \
    chmod +x /usr/local/bin/kubectl

# Install Minikube
RUN curl -Lo /usr/local/bin/minikube https://storage.googleapis.com/minikube/releases/${MINIKUBE_VERSION}/minikube-linux-amd64 && \
    chmod +x /usr/local/bin/minikube

# Create a non-root user
RUN useradd -m minikube && echo "minikube:minikube" | chpasswd && adduser minikube sudo
USER minikube
WORKDIR /home/minikube

# Start Minikube inside the container
CMD ["minikube", "start", "--driver=docker"]

Build & Run Instructions

1. Build the Docker image

   docker build -t minikube-container .
   

2. Run the container with proper privileges

   docker run --privileged -v /var/run/docker.sock:/var/run/docker.sock -it minikube-container
   

Explanation

• Installs Minikube and kubectl: Necessary for running Kubernetes.
• Uses Docker as a driver: Minikube will run its Kubernetes cluster inside Docker.
• Non-root user setup: Helps prevent permission issues.
• Maps Docker socket (/var/run/docker.sock): Allows Minikube to create Docker containers inside the host.

When Should You Use Kubernetes?

How Kubernetes is Replacing Traditional Infrastructure

Kubernetes is revolutionizing IT infrastructure by shifting organizations from traditional physical servers and IaaS (Infrastructure-as-a-Service) to modern, container-based deployments. Here’s how:

1️⃣ From Monolith to Microservices:

• Legacy applications are being refactored into microservices using Kubernetes, allowing faster development, deployment, and scaling.

2️⃣ Replacing Physical Servers & VMs:

• Instead of managing dedicated physical servers or virtual machines (VMs), companies are deploying applications in lightweight, scalable Kubernetes pods.

3️⃣ Auto-Scaling & Dynamic Resource Allocation:

• Unlike traditional IaaS where resources are statically allocated, Kubernetes uses Horizontal Pod Autoscaling (HPA) to adjust based on demand, optimizing costs.

4️⃣ Cloud-Agnostic Deployments:

• Kubernetes abstracts the underlying infrastructure, enabling seamless workload portability across AWS, GCP, Azure, and on-prem.

5️⃣ Modernizing Legacy Apps Without Rewriting:

• Using Kubernetes and containerization (Docker), enterprises can package legacy applications into containers, eliminating dependencies on outdated OS or hardware.

6️⃣ Enhanced Reliability & Zero Downtime Deployments:

• Kubernetes’ rolling updates, automatic failover, and self-healing capabilities ensure applications remain available without manual intervention.

💡 The Future: Traditional infrastructure is being phased out as Kubernetes becomes the de facto standard for managing cloud-native, scalable, and resilient applications in modern enterprises.

Remarks

Docker Compose is great for local development and small projects, but Kubernetes is the best choice for production, especially for enterprise-scale applications.

✅ Kubernetes is built for automation, scalability, and reliability.
✅ It’s cloud-native and supports multi-cloud & hybrid-cloud deployments.
✅ Enterprises trust Kubernetes for mission-critical workloads.

When I first develop a backend or frontend, docker-compose is my go-to solution. You will find many docker-compose projects on my GitHub. However, when it comes to production, we definitely need to use Kubernetes. I have collected some templates from high-starred github repos and putting in one on Kubernetes Template Collections.

In this post, we explore how Docker Compose simplifies the deployment of an AI-powered Retrieval-Augmented Generation (RAG) chatbot. This system:

• Uses Ollama to run local LLMs (no cloud dependency)
• Implements FAISS for vector search to retrieve documents efficiently
• Provides a modern chat UI using Chainlit
• Utilizes FastAPI for a high-performance backend
• Is fully containerized, making it easy to deploy

Since this project is quite big, I’ll not go through the frontend or backend codes. I’ll just go through how I utilized docker-compose to build and run the project efficiently on my macbook pro.

Please, check out the whole project on my Github Repository.

System Architecture

        
User ───────────────▶ Chainlit UI       Documents (txt/md/pdf)
                           │                     │
                           │                     │
                    Query  │                     │ Retrieve
                           │                     │ Documents
                           ▼                     ▼
                       FastAPI ◄───────────  RAG Model ◄─────── Local Ollama
                       Backend                   │
                           │                     │
                           └─────────────────────┘
                                Return Answer

The chatbot takes a user’s query, retrieves relevant information from stored documents, and generates a response using a local LLM.

Getting Started

Prerequisites

• Docker & Docker Compose
• Ollama (for running local models)
• Python 3.10+

Step 1: Install Ollama

Ollama is required to run local LLM models efficiently.

MacOS

brew install ollama
brew services start ollama

Linux

curl -fsSL https://ollama.com/install.sh | sh

Windows

Download and install Ollama from the official Ollama website.

Step 2: Download Required LLM Models

Run the following commands to ensure you have the required models:

ollama run mistral
ollama run nomic-embed-text

These models handle document embeddings and language generation for accurate responses.

Step 3: Clone the Chatbot Repository

git clone https://github.com/shantoroy/rag-chatbot-python-fullstack-template.git
cd rag-chatbot-python-fullstack-template

Step 4: Configure the Environment

Copy .env.example to .env and modify it as needed.

cp .env.example .env

Step 5: Deploy with Docker Compose

Build and start the containers:

docker-compose build
docker-compose up -d

How It Works

Once the containers are running:

1. Access the chatbot interface at http://localhost:8505.
2. Upload your documents (txt, md, pdf) to the /documents directory.
3. Ask questions in natural language.
4. The system retrieves relevant information and generates an AI response.

Project Structure

I wanted to have the project as structured as possible. So, you’ll find the backend and frontend application/api codes on corresponding folders.

The folder docker includes the Dockerfiles for the backend and the frontend. Since, both backend and frontend is developed in python, there are two requirements.txt files under the folder requirements.

This is a RAG-based AI chatbot and I’ve added functionalities to add three types of files under the documents folder: txt files, pdf files, and markdown files.

rag-chatbot-python-fullstack-template/
├── backend/
│   ├── model.py          # RAG model implementation
│   └── api.py            # FastAPI backend
├── frontend/
│   └── app.py            # Chainlit chat interface
├── docker/
│   ├── backend.Dockerfile
│   └── frontend.Dockerfile
├── requirements/
│   ├── backend_requirements.txt
│   └── frontend_requirements.txt
├── documents/            # Put/organize your documents here
│   ├── test_file_1.txt 
│   └── test_file_2.md
├── .env.example          # Example file, rename to .env
├── docker-compose.yml    # Service orchestration
└── README.md

Docker Compose File

I included the backend and the frontend on the docker-compose file. Now, I was running this on my macbook pro and I heard somewhere that the ollama models cannot utilize the GPUs if run within a container.

So, here, you’ll not see ollama service on the dockerfile. But, you can actually run or test it on container. Ollama is properly optimized to run on personal computers. So, shouldn’t be an issue.

services:

  backend:
    build:
      context: .
      dockerfile: docker/backend.Dockerfile
    environment:
      - OLLAMA_URL=http://host.docker.internal:11434
    ports:
      - "8000:8000"
    volumes:
      - ./documents:/app/documents
    user: "${UID:-1000}:${GID:-1000}"
    restart: unless-stopped

  frontend:
    build:
      context: .
      dockerfile: docker/frontend.Dockerfile
    ports:
      - "8505:8505"
    environment:
      - BACKEND_URL=http://backend:8000
      - CHAINLIT_AUTH_SECRET=${CHAINLIT_AUTH_SECRET}
    volumes:
      - ./frontend/src:/app/frontend/src
      - ./frontend/public:/app/frontend/public
    depends_on:
      - backend
    restart: unless-stopped

Dockerfiles

Frontend Dockerfile

The frontend dockerfile is fairly simple. You install requirements, copy the codes, and run the frontend based on chainlit.

FROM python:3.10-slim

WORKDIR /app

# Copy requirements and install dependencies
COPY requirements/frontend_requirements.txt .
RUN pip install --no-cache-dir -r frontend_requirements.txt

# Copy application code and Chainlit config
COPY frontend /app/frontend
COPY chainlit.md /app/chainlit.md

# Command to run the frontend
CMD ["chainlit", "run", "frontend/app.py", "--host", "0.0.0.0", "--port", "8505"]

Backend Dockerfile

The backend dockerfile is a bit challenging since it requires many prerequisites steps to run the underlying natural language processing tasks.

First, we need to install necessary linux packages installed. Then we install necessary modules from the requirements.txt file. Then we have to download nltk packages or libraries and set the environment variables.

On this project, I’m keeping the documents under backend. But, you can declare a separate volume space to store the documents you want your model to go through. You can define that volume on the docker-compose file.

FROM python:3.10-slim

# Set the working directory
WORKDIR /app

# Install system dependencies
RUN apt-get update && apt-get install -y \
    build-essential \
    libmagic1 \
    file \
    unzip \
    wget \
    poppler-utils \
    tesseract-ocr \
    pandoc \
    libxml2-dev \
    libxslt1-dev \
    python3-dev \
    && rm -rf /var/lib/apt/lists/*

# Copy requirements first (to leverage Docker layer caching)
COPY requirements/backend_requirements.txt .

# Install Python dependencies
RUN pip install --no-cache-dir -r backend_requirements.txt

# Download all necessary NLTK data
RUN python -m nltk.downloader -d /usr/local/share/nltk_data all
# Alternatively, if you want to download only specific packages:
# RUN python -c "import nltk; \
#     nltk.download('punkt', download_dir='/usr/local/share/nltk_data'); \
#     nltk.download('averaged_perceptron_tagger', download_dir='/usr/local/share/nltk_data'); \
#     nltk.download('punkt_tab', download_dir='/usr/local/share/nltk_data'); \
#     nltk.download('tokenizers', download_dir='/usr/local/share/nltk_data')"

# Set environment variable for NLTK data
ENV NLTK_DATA=/usr/local/share/nltk_data

# Copy application code
COPY backend /app/backend

# Create necessary directories
RUN mkdir -p /app/documents /app/vector_store

# Set permissions for appuser
RUN useradd -m appuser && \
    chown -R appuser:appuser /app/documents && \
    chown -R appuser:appuser /app/vector_store && \
    chown -R appuser:appuser /app/backend && \
    chown -R appuser:appuser /usr/local/share/nltk_data

# Switch to non-root user
USER appuser

# Set the working directory inside backend
WORKDIR /app/backend

# Expose the port
EXPOSE 8000

# Run the backend
CMD ["uvicorn", "api:app", "--host", "0.0.0.0", "--port", "8000"]

Stopping & Cleaning Up

To stop the chatbot services:

docker-compose down

To remove all associated containers, volumes, and images:

docker-compose down -v
docker system prune -a

Remarks

Deploying an AI Chatbot using Docker Compose makes it easier to manage, deploy, and scale.
💡 No need to manually configure dependencies
💡 Works on any system with Docker installed
💡 Leverages local LLMs for privacy and performance

Please, check out the whole project on my Github Repository.