CTT DevOps Engineer — A practice

This github repository will be available after 11/20. thstasy/k8s-webapp-helm-gitops

This is an interview task given by Cloud Transformation Team(CTT) from Swisscom.
The task is to create a Helm chart and automation for standardizing the deployment of simple web applications across Kubernetes clusters using a GitOps approach. The objective is to ensure flexible and consistent deployments across environments, simplifying management and maintenance.

Requirements

The Helm chart must support the following features:

  • Configurable deployment name, namespace, port, and ingress hostnames.
  • Additional enhancements are encouraged.
  • Furthermore, automation should be implemented to manage custom values files across environments, enabling updates to defaults or environment-specific settings.

Deliverables

• Helm Chart: Meets the above requirements.

• Live Environment: Demonstrates deployment of a simple web application, either on a local or cloud-based Kubernetes cluster. (Web app development is out of scope.)

• Automation Script: Tool or script to update custom values files for different environments (e.g., shell, Python).

Expectations

• Interpret requirements and assumptions clearly.

• Create a private GitHub repository and version control your code.

• Provide simple documentation on how to use the module.

How I tackled it in 12 hours:

Overview

This Helm chart provides a standard deployment template for a simple web application on Kubernetes. It supports customizable features such as deployment name, namespace, port, ingress hostname, and a simple automation script for deploying to different environments.

This solution focuses on Kubernetes directly. Kubernetes resources were managed through Helm and kubectl commands due to time constraint.

Project Structure

  • Chart.yaml: Chart metadata (name, version, description).
  • values.yaml: Default configuration that can be overridden per environment.
  • templates/: Kubernetes resource templates (deployment.yaml, service.yaml, ingress.yaml).
  • deploy.sh: Automation script to deploy to multiple environments.

Features

  • Configurable deployment name, namespace, port, and ingress hostname.
  • Environment-specific configurations for development, staging, and production.
  • Automation script (deploy.sh) to deploy the application to different environments using the respective values file.

Deliverables

  1. Helm Chart:
    • Located in charts/my-web-app/
    • Includes Chart.yaml, values.yaml, and templates in templates/
  2. Live Environment:
    • Deploy the app to a Kubernetes cluster using the Helm chart.
    • Example:helm install my-web-app ./charts/my-web-app -f ./charts/my-web-app/values.yaml
  3. Automation Script:
    • deploy.sh automatically selects the correct values file for each environment:./deploy.sh dev # Deploy to development ./deploy.sh staging # Deploy to staging ./deploy.sh prod # Deploy to production

Installation

Run the deploy.sh script to install or upgrade the application in the specified environment:

./deploy.sh dev     # Deploy to development
./deploy.sh staging # Deploy to staging
./deploy.sh prod    # Deploy to production

Configuration

Modify values.yaml for default settings or use environment-specific files (values-dev.yaml, values-staging.yaml, values-prod.yaml) to override settings like replica count, ingress hostnames, and namespaces.

Conclusion

This Helm chart provides flexible, environment-specific deployment for a web application using Kubernetes, with automation for simplified management across multiple clusters and environments.

Clear Interpretation of Requirements and Assumptions

1. Helm Chart Requirements:

  • Deployment Name: The Helm chart must allow users to set a custom deployment name. This can be achieved by defining a variable for the deployment name in the values.yaml file.
  • Namespace: The Helm chart should support deploying the application to a specific namespace. This will also be a configurable value in the values.yaml file.
  • Port: The Helm chart must allow the configuration of a port for the web application. This port should be customizable via the values.yaml file.
  • Ingress Hostnames: The Helm chart must support ingress configurations with customizable hostnames, allowing different hostnames for different environments (e.g., dev, staging, prod).

2. Automation:

  • Environment-Specific Values: The Helm chart must allow easy customization of values based on the environment (e.g., dev, staging, production). This can be done by using separate values files like values-dev.yaml, values-prod.yaml, etc.
  • Automation Script: A script (deploy.sh, for example) will be used to automate the deployment process by applying the appropriate environment-specific values file.

3. Deployment Environment:

  1. Kubernetes Cluster: The application will be deployed to a Kubernetes cluster, which can either be local (using tools like Minikube or Docker Desktop) or cloud-based (e.g., AWS EKS, Google GKE, Azure AKS).
  2. Simple Web Application: The application itself can be any simple web application (e.g., an Nginx server, a Node.js app, or any pre-existing simple app), as development of the application is not in scope.

4. Assumptions:

  • Kubernetes Cluster Setup: It’s assumed that the user has a running Kubernetes cluster (local or cloud-based) where the application can be deployed.
  • Helm Knowledge: It is assumed that the user has a basic understanding of how Helm works, including creating and applying Helm charts.
  • Docker: It is assumed that Docker is used for containerizing the application, and that the Docker image is available either locally or pushed to a container registry (Docker Hub, AWS ECR, etc.).
  • GitOps vs. CI/CD: While the GitOps approach is suggested, it is assumed that a manual or scripted deployment (using kubectl and Helm commands) will be acceptable if a fully automated CI/CD pipeline is not implemented.