Skip to content

README.md

Latest commit

 

History

History
172 lines (124 loc) · 6.58 KB

README.md

File metadata and controls

172 lines (124 loc) · 6.58 KB

RTalk - Real-time Chat Application DevOps Solution

This project implements a complete DevOps solution for RTalk, a modern, web-based chat application with user authentication. The solution focuses on containerized deployment, orchestration, and continuous delivery.

📌 Project Overview

RTalk is built with a microservices-inspired architecture:

Component Technology
Frontend React.js
Backend Node.js/Express with Socket.io
Database MongoDB
Data Store Redis

The core DevOps solution leverages the following technologies:

  • Containerization: Docker
  • Orchestration: Kubernetes (using Docker Desktop for local setup)
  • Package Management: Helm

🚀 Key DevOps Achievements

✅ Portable & Consistent Deployment

We ensure a consistent environment from development to production through Docker containers. This approach eliminates "it works on my machine" issues and provides a reliable foundation for our application.

  • Multi-stage builds: Used to create optimized, lightweight production images.
  • Helm charts: Provide version-controlled, declarative deployments to Kubernetes, making our application's configuration repeatable and manageable.

✅ Scalable Orchestration

Kubernete manages the application's microservices, ensuring high availability and efficient resource utilization.

Horizontal Pod Autoscaling (HPA): Automatically scales backend pods based on CPU and memory usage, allowing the application to handle varying traffic loads without manual intervention. Version-Controlled Deployments: Helm charts ensure that every deployment is a traceable and repeatable event. Real-time Communication: Redis is used as a Pub/Sub message broker, enabling Socket.IO to broadcast messages across multiple backend pods, ensuring the chat functionality remains consistent and scalable.

✅ Progressive Delivery & Automation

Our deployment strategy enables a safe and automated delivery process.

  • Canary releases: Implemented with Helm to gradually roll out new versions to a small subset of users, allowing us to monitor performance and stability before a full rollout.
  • Automated rollbacks: Our Helm-based deployment strategy includes built-in rollback capabilities, allowing us to quickly revert to a previous stable version if issues are detected.
  • Health checks: Readiness and liveness probes are configured to ensure that traffic is only sent to healthy pods.

🛠️ Implementation & Getting Started

Prerequisites

  • Docker Desktop with Kubernetes: Ensure Kubernetes is enabled in the Docker Desktop settings.
  • Helm v3+: The package manager for Kubernetes.
  • Node.js 16+: For local development.

1. Local Development with Docker Compose

For a quick local setup, use Docker Compose to spin up all the services.

# 1. Clone the repository
git clone https://github.com/G-OrdiaD/RTalk.git
cd rtalk

# 2. Start the services
docker-compose up -d

# 3. Access the application
# Open your browser to http://localhost:3000

2. Kubernetes Local Setup

Before deploying with Helm, ensure your local Kubernetes cluster is running. The files for the Kubernetes resources are located in the k8s/ directory.

# Verify your Kubernetes context
kubectl get nodes

# You can apply the manifests directly for testing purposes
kubectl apply -f k8s/

3. Deploying to Kubernetes with Helm

Once your local Kubernetes cluster is running, you can deploy the application using the provided Helm chart.

# 1. Install the Helm chart
helm install rtalk ./chart

# 2. To upgrade a deployment (e.g., a new version)
helm upgrade rtalk ./chart

# 3. To perform a canary release
# This command deploys a new version alongside the stable one,
# directing a small portion of traffic to it.
helm upgrade rtalk ./chart --set canary.enabled=true --set canary.replicaCount=1

# 4. To promote the canary version after successful testing
helm upgrade rtalk ./chart --set canary.enabled=false

Project Structure

rtalk/
├── backend/
├── frontend/
├── k8s/
│   ├── config/
│   │   ├── ingress.yaml
│   │   └── namespace.yaml
│   ├── deployments/
│   │   ├── backend-deployment.yaml
│   │   ├── frontend-deployment.yaml
│   │   ├── mongodb-deployment.yaml
│   │   └── redis-deployment.yaml
│   ├── services/
│   │   ├── backend-service.yaml
│   │   ├── frontend-service.yaml
│   │   ├── mongodb-service.yaml
│   │   └── redis-service.yaml
│   └── volumes/
│       └── mongodb-pvc.yaml
├── chart/
│   ├── Chart.yaml
│   ├── values.yaml
│   └── templates/
│       ├── backend/
│       │   ├── deployment.yaml
│       │   └── service.yaml
│       ├── frontend/
│       │   ├── deployment.yaml
│       │   └── service.yaml
│       ├── mongodb/
│       │   ├── deployment.yaml
│       │   └── service.yaml
│       ├── redis/
│       │   ├── deployment.yaml
│       │   └── service.yaml
│       └── _helpers.tpl
├── docker-compose.yaml
└── README.md

📈 Future Roadmap

  1. Enhanced Monitoring: Implement a robust monitoring solution with Prometheus for metrics collection and Grafana for visualization, providing detailed dashboards for application and infrastructure health.
  2. Centralized Logging: Integrate an ELK Stack (Elasticsearch, Logstash, Kibana) to aggregate and analyze logs from all services, enabling faster troubleshooting and deeper insights.
  3. Automated CI/CD: Set up a Jenkins pipeline to automate the build, test, and deployment process, enabling true continuous delivery.
  4. Persistent Storage: Implement persistent volume claims for MongoDB to ensure data survives pod restarts and migrations.
  5. Security Hardening: Introduce network policies and pod security contexts to secure the cluster.

✍️ Contributors

We welcome contributions! Please feel free to open a pull request or issue.

[Ordia David Gbakena] - Initial project setup and DevOps implementation.

📜 License

This project is licensed under the MIT License. See the LICENSE file for details.