Open dbones opened 2 years ago
we can setup a separate Repo that is controlled by lab.dev
, it has all the metadata, this can then be registered with all clusters and push the correct updates (via fleet)
lab.dev
can checkin changes
this would minimise the
however we need to handle git and also have a dedicated Repo, created when the org is setup in Github.
the service account needs alot of access to default
consider a controller to ensure the resources are correct for each tennet
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: lab-ds
namespace: fleet-default
spec:
branch: main
clientSecretName: github-credentials
insecureSkipTLSVerify: false
paths: []
repo: https://github.com/fox-in-the-lab/lab.git
serviceAccount: tenancy1
targets:
- clusterGroup: downstream
---
apiVersion: fleet.cattle.io/v1alpha1
kind: ClusterGroup
metadata:
name: downstream
namespace: fleet-default
spec:
selector:
matchExpressions: []
matchLabels: {}
use special folders to control deployment to sub-cluster assets
targetCustomizations:
- name: bob
clusterSelector:
matchExpressions:
- key: lab.dev/name2
Operator: In
values:
- aqua
yaml:
overlays:
- deploy
This looks correct :)
note that billing is not in the following
(and galaxy does not exist in this cluster)
note that he graph does not filter out clusters it does not deploy a bundle too (in this case only aqua would be listed)
the service account is applied :)
this is allowed :)
not allows - as expected
now we need a good mechanism to allow the company to supply the default namespace bindings
MORE NOTES
deployment rbac
Rancher require
namespaces to have an annotation
then rancher can manage the rbac in the project for all the namespaces.
fleet requires (for a secure setup)
to limit where a tenancy can deploy too
serviceaccounts are not linked to projects
so the contecpt of a
tenancy
will need to be controlled by namepaces, not by projects for this part