https://github.com/shalb/cdev-examples

https://github.com/shalb/cdev-examples

Last synced: about 1 month ago
JSON representation

• Host: GitHub
• URL: https://github.com/shalb/cdev-examples
• Owner: shalb
• License: apache-2.0
• Created: 2023-09-21T08:59:32.000Z (over 1 year ago)
• Default Branch: main
• Last Pushed: 2024-04-28T10:58:52.000Z (8 months ago)
• Last Synced: 2024-04-28T11:39:22.715Z (8 months ago)
• Language: Jupyter Notebook
• Size: 912 KB
• Stars: 3
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# cdev-examples

Welcome! In this repository you will find code samples for different use cases of Cluster.dev, including: 

* Creating a static website hosting on different clouds: [AWS](https://docs.cluster.dev/get-started-cdev-aws/), [Azure](https://docs.cluster.dev/get-started-cdev-azure/) and [GCP](https://docs.cluster.dev/get-started-cdev-gcp/)

* [Deploying an application with Helm and Terraform to Kubernetes](https://docs.cluster.dev/get-started-cdev-helm/)

* Bootstrapping cloud infrastructures with Cluster.dev’s ready-made templates [AWS-EKS](https://docs.cluster.dev/examples-aws-eks/), [AWS-K3s](https://docs.cluster.dev/examples-aws-k3s/), [GCP-GKE](https://docs.cluster.dev/examples-gcp-gke/), and [DO-K8s](https://docs.cluster.dev/examples-do-k8s/)

* [Deploying the Prometheus monitoring stack to a K3s cluster](https://docs.cluster.dev/examples-aws-k3s-prometheus/).  

## Advantages of using cluster.dev for DevOps engineers

Platform engineering. A small, understandable configuration that is passed to developers/testers. Only those elements that need to be changed are abstracted.

Unified GitOps process for different technologies.

Global project variables and secrets that can be shared across different technologies.

Separation of infrastructure by layers, ex: data, orchestration, monitoring.

Accelerates development significantly through:

* Cluster.dev has its own state and does not require validating everything that Terraform validates. Helm, Shell, etc., are also in a shared state.

* Separation of states by units, automatic generation of state files, less impact in case of problems in any module or state issues.

* "Light" state which is not critical to loss, as it can be fully regenerated.

* Clear definition of the execution sequence of dependencies between modules and provider configuration.

Helm/Kubernetes manifests are stored in native format, there is no need to rewrite them in HCL, and they have clear diffs.

Passing to Helm/Kubernetes variables that are generated by Terraform.

Full configuration of variables through Go template and its functions.

Integration testing between versions of Terraform modules and Helm charts.