gimlet-io
Provisioning cloud resources
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:
- Managed database instance
- Logical database in a managed database instance
- Queue
- Redis
- Storage buckets
The technical implementation will be Crossplane compositions and / or Terraform modules.
The vision
- Developers should be able to provision a managed database when they deploy their service.
- They should be able to do this on the env config screen and they should be able to reference this cloud resource's output (host, user, password) in their environment variables.
- The configuration should be written to the Gimlet manifest file and should follow the same properties as we have today.
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.
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:
- at the top Gimlet manifest level is the
env, all the infra cloud resources should follow and be organized and based on this - Gimlet manifest should be able to pick and automate the rollout of any new changes to the dependencies if not fixed version is found on this
- 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
- every tfmodule should have his own statefile ( inherite backend configuration from env )
- applications should be able to access manifest deps outputs or general infra env outputs
🤔
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