Open laszlocph opened 1 year ago
Currently we refer to helm charts in the chart
field and we store the values
for it
We introduce a new section where we can reference compositions and tf modules with their input parameters.
app: test-app
env: random6
namespace: default
chart:
repository: https://chart.onechart.dev
name: onechart
version: 0.41.0
values:
gitRepository: gimlet-io/test-app
gitSha: '{{ .SHA }}'
replicas: 2
strategicMergePatches: ""
json6902Patches: []
manifests: ""
+ dependencies:
+- name: my-db
+ composition: https://github.com/gimlet-io/compositions?tag=v1.0.0&path=aws/rds
+ values:
+ size: 10GB
+- name: my-redis
+ tfmodule: https://github.com/gimlet-io/tfmodules?tag=v1.0.0&path=aws/elasticache
+ values:
+ size: 1GB
GitOps everything
Git should also serve as the single source of truth for all cloud infrastructure changes. Implementing GitOps for cloud infrastructure management will lead to enhanced visibility and change tracking, automated provisioning, improved teams collaboration, increased security, and easier maintenance.
It's common for applications to have dependencies on various cloud infra components. These dependencies can include databases, message queues, caches, storage systems, and other services. Using a shared manifest for applications and infrastructure changes through GitOps can improve the overall collaboration, consistency and traceability, it simplifies the CI/CD workflow and can also improve disaster recovering since all the changes are tracked into a single place.
Considerations:
env
, all the infra cloud resources should follow and be organized and based on this🤔
You are spot on @tcrst!
- all the infrastructure changes and plan outputs must be shown in the PR approval review and will be applied on the merge of the PR
good thinking, agreed
- every tfmodule should have his own statefile ( inherite backend configuration from env )
I was not thinking any of the specifics of TF, but this seems like a good idea. Let's adopt this for the first version.
applications should be able to access manifest deps outputs or general infra env outputs
Good point. We should see how the Terraform controller for Flux works. I suspect there is a CRD and the state of the CRD will hold this info.
https://github.com/gimlet-io/gimlet/pull/504 introduced basic Terraform support in the Gimlet manifest
The goal of this issue is to develop support of provisioning cloud resources through the Gimlet manifest file.
The scope of cloud resources are limited to items that developers care about:
The technical implementation will be Crossplane compositions and / or Terraform modules.
The vision
Considerations
Cloud resources must work well with existing cloud resources. Project placement, networking is custom for every Gimlet user. Therefore the cluster administrator should be the one who enables the allowed cloud resources that can be created. Gimlet provides the workflow for creation, and management of these cloud resources, the cluster admin is the one who provides the organizational knowledge.
Practically these cloud resources will be in a form of Crossplane compositions and / or Terraform modules. A supported list of these resources will be made available as public git repositories. The cluster admin will be able to decide to use them as is, or if she needs to maintain a private fork. The crossplane / terraform components thus have to be referred to in git repositories and folders.
The delivery of the Crossplane compositions and / or Terraform modules will happen through gitops as with everything else.
Gimlet must develop a CrossplaneUI and TerraformUI components like we have with HelmUI.