Matrix generator enterprise

Example

The matrix generator doesn't generate by itself, it combines the results of generating from other generators e.g.:

apiVersion: templates.weave.works/v1alpha1
kind: GitOpsSet
metadata:
  name: matrix-sample
spec:
  generators:
    - matrix:
        generators:
          - gitRepository:
              repositoryRef: go-demo-repo
              files:
                - path: examples/generation/dev.yaml
                - path: examples/generation/production.yaml
                - path: examples/generation/staging.yaml
          - list:
              elements:
                - cluster: dev-cluster
                  version: 1.0.0

Given the files mentioned all have the following structure:

examples/generation/dev.yaml

env: dev
team: developers

This will result in three sets of generated parameters, which are a combination of the maps in the files in the gitRepository, and the elements in the list generator, this can result in a combinatorial explosion of resources being created in your cluster.

- env: dev
  team: developers
  cluster: dev-cluster
  version: 1.0.0
- env: staging
  team: staging-team
  cluster: dev-cluster
  version: 1.0.0
- env: production
  team: production-team
  cluster: dev-cluster
  version: 1.0.0

These can be referenced in the templates, note that all keys in the merged generators from the Matrix are contained in the element scope.

apiVersion: templates.weave.works/v1alpha1
kind: GitOpsSet
metadata:
  name: matrix-sample
spec:
  generators:
    - matrix:
        generators:
          - gitRepository:
              repositoryRef: go-demo-repo
              files:
                - path: examples/generation/dev.yaml
                - path: examples/generation/production.yaml
                - path: examples/generation/staging.yaml
          - list:
              elements:
                - cluster: dev-cluster
                  version: 1.0.0
  templates:
    - content:
        kind: Kustomization
        apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
        metadata:
          name: "{{ .element.env }}-demo"
          labels:
            app.kubernetes.io/name: go-demo
            app.kubernetes.io/instance: "{{ .element.env }}"
            com.example/team: "{{ .element.team }}"
            com.example/cluster: "{{ .element.cluster }}"
            com.example/version: "{{ .element.version }}"
        spec:
          interval: 5m
          path: "./examples/kustomize/environments/{{ .element.env }}"
          prune: true
          sourceRef:
            kind: GitRepository
            name: go-demo-repo

caution

To run this example you will need extra RBAC

This particular example creates kustomizations, so you will need to add the below RBAC to the gitopssets-controller-manager service account to allow it to create kustomizations.

Check out the Security section for more information.

However this will change in the next release with impersonation. Instead you can choose a service account for each GitOpsSet that has the required permissions for creating the rendered resources in the templates section.

Additional RBAC for the gitopssets-controller-manager service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: demo-role
rules:
- apiGroups:
  - kustomize.toolkit.fluxcd.io
  resources:
  - kustomizations
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: demo-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: demo-role
subjects:
- kind: ServiceAccount
  name: gitopssets-controller-manager
  namespace: flux-system