Folder Structure

Kuberise.io

Kuberise.io is an open-source project that leverages Kubernetes for deploying and managing both platform tools and business applications. The configuration for these services are managed by multiple values.yaml files.

Architecture

The architecture of Kuberise is designed to be modular and scalable, allowing for the deployment of a variety of services into multiple clusters.

app-of-apps

This folder contains the ArgoCD app of the apps application which basically defines what applications are going to be install in each platform or application cluster.

templates

This folder contains the templates and helm charts that are the same for all platform clusters or environments.

values

This folder contains the configuration for the templates that are different for each platform cluster or environment.

The services are divided into two main categories:

1. Platform Services:

These are common services that are used across different applications, such as Keycloak, Cloudnative-pg and Grafana. Usually these services are deployed once and used for multiple environments. For example applications that are deployed in different environments (like dev, tst, prd) use the same Grafana that is deployed in platform cluster. Or platform services can be deployed twice, once for non production environments and once dedicated to production environment to be safer in production.

The folder structure for platform services is values/platform_name/platform/service_name/values.yaml. For example if you deploy your platform services in a cluster called minikube and you have a gitea service then the values for that service is in values/minikube/platform/gitea/values.yaml file. Assume you want to have one platform cluster for non-prod environments and one platform cluster for prod and your platform name is minikube. Then you need to copy the whole values/minikube folder and call them values/minikube-nonprod and values/minikube-prod

2. Applications:

These are business applications developed by you or your team for example the backend service. The values folder for these services are separated from the values folder of the platform services. The folder structure is values/platform_name/applications/application_name/values.yaml, for example values/minikube/applications/backend/values.yaml and then you will add all values for that application here. You can change the structure of applications value folder but you have to fix the address of values in app-of-apps/values-platformName.yaml for each application.

Configuration

Here is an example of how to configure a platform service (Gitea) defaults and an application (todolist-frontend) defaults in `app-of-apps/values.yaml:

gitea:
  enabled: false
  repoURL: https://dl.gitea.io/charts
  namespace: gitea
  targetRevision: 10.1.1
  chart: gitea

backend:
  enabled: false
  path: templates/generic-deployment
  valuesFolder: applications

Then you can overwrite those default values for each platform cluster. For example assume that I have a minikube platform cluster in my local computer for dev environment and an azure platform cluster for production. I would like to enable gitea in my local minikube and disable it in my production platform cluster in azure. I would like to deploy all applications in the same cluster as platform (They could be deployed to separate cluster as well). Then I will add two more values file in my app-of-apps folder for each platform cluster.

values-PlatformMinikube.yaml for the local minikube cluster as my dev environment:

gitea:
  enabled: true

backend:
  enabled: true

You can see that the enabled value in default file is false, it means that I need to enable them for each platform I want. Here I need to enable gitea and backend.

values-PlatformAzure.yaml for the Azure AKS cluster as my production environment:

backend:
  enabled: true

For production I don't need gitea, so I don't enable it and I just need to enable my applications for production.