cuelang with argocd

[vinvli]

I noticed cuelang as a templating engine for kubernetes manifests is getting more traction.
Are there any plans on introducing it in argo cd as an option next to helm and kustomize?

[mausch]

Has anyone written a ConfigManagementPlugin for cue ?

[dd84ai]

Some person did it 5 years ago https://github.com/zoetrope/argocd-cue
Looks like a potential source of inspiration to make it happen once again
I'll try to poke this code and give a try to make.. cleaner and up to date for its workability
looks like not a big problem to rewrite it to modern example

• https://argo-cd.readthedocs.io/en/stable/operator-manual/config-management-plugins/
• https://github.com/argoproj/argo-cd/tree/master/examples/plugins/helm

[yevvhen]

Recently at Profisea Labs, we faced the challenge of developing this functionality by ourselves.

The first step we took was to familiarize ourselves with Cuelang through the following tutorial:
https://github.com/cue-lang/cue/blob/v0.6.0/doc/tutorial/kubernetes/README.md

This guide is incredibly helpful as it covers the entire process: transitioning your Kubernetes configurations to Cuelang and, crucially, introducing a dump tool capable of converting Cuelang configurations into YAML format. This will be essential for our integration with ArgoCD.

Then we implemented ArgoCD Config Management Plugin according to the official docs:
https://argo-cd.readthedocs.io/en/stable/operator-manual/config-management-plugins/

The process is straightforward - you simply need to adjust your ArgoCD Helm values as follows:

repoServer:
  initContainers:
    - name: cuelang-get-binary
      command:
        - "/bin/bash"
      args:
        - "-c"
        - "apt update;
          apt install -y wget;
          wget -q https://github.com/cue-lang/cue/releases/download/v0.7.0/cue_v0.7.0_linux_arm64.tar.gz;
          tar -xzf cue_v0.7.0_linux_arm64.tar.gz -C /cue"
      image: ubuntu:22.04
      volumeMounts:
        - mountPath: /cue
          name: cmp-cuelang-binary
  extraContainers:
    - name: cmp-cuelang
      command:
        - "/var/run/argocd/argocd-cmp-server"
      image: busybox:1.36
      securityContext:
        runAsNonRoot: true
        runAsUser: 999
      volumeMounts:
        - mountPath: /var/run/argocd
          name: var-files
        - mountPath: /home/argocd/cmp-server/plugins
          name: plugins
        - mountPath: /home/argocd/cmp-server/config/plugin.yaml
          subPath: cuelang.yaml
          name: argocd-cmp-cm
        - mountPath: /tmp
          name: cmp-tmp
        - mountPath: /cue
          name: cmp-cuelang-binary
  volumes:
    - name: argocd-cmp-cm
      configMap:
        name: argocd-cmp-cm
    - name: cmp-tmp
      emptyDir: {}
    - name: cmp-cuelang-binary
      emptyDir: {}

And:

configs:
  cmp:
    create: true
    plugins:
      cuelang:
        generate:
          command: ["sh", "-c"]
          args: ["/cue/cue cmd -t {your-parameters} dump ./..."]
        discover:
          fileName: "./*.cue"

Based on the last line, any Applications stored in folders with Cuelang files will automatically be managed by this plugin.
You have the flexibility to adjust the args field to inject custom values or utilize specific tools as needed. The main point of this line is that the command should output all resources in YAML format.

To keep this explanation from getting too complex, I suggest starting with a basic Kubernetes tutorial. Try managing a simple Application using Cuelang and the ArgoCD CMP. After that, you'll be in a better position to consider how to structure your Applications.

We do it in the next way:

cue/
├─ settings/
│  ├─ options.cue
│  ├─ versions.json
├─ template/
│  ├─ template.cue
├─ tools/
│  ├─ *_tool.cue
├─ microservice1.cue
├─ microservice2.cue
├─ microservice3.cue
├─ ... 

Our project structure includes a template/ folder for holding templates of each Kubernetes resource type. We have a tools/ folder for keeping utilities, such as YAML exporter. Additionally, there's a fascinating settings/ folder dedicated to storing configurations specific to different environments, like image versions, environment types, and mappings of Kubernetes resources to ArgoCD Applications. This settings/ folder acts as a central hub for global configurations that affect all our microservices.

Folders are organized into Cuelang packages based on their names, with the root package being named "microservices".

[dd84ai]

Wrote my version, here it is full version including which argocd is used

• it is in customize format with pinned all dependencies
• using cue 0.7.1, argocd v2.8.11, kubectl v1.29.1 at the moment of this writing
• and added script to use amd64 or arm64 cue binary depending on host cpu arch
• deploy with kubectl apply -k ./plugin
  • see all commands in Taskfile
• added sample application to try it on, with command in Taskfile described too
• tested on
  • local Kind cluster for amd64 cpu arch, kind v0.22.0, kube v1.29.2
  • microk8s with arm64 cpu architecture too, microk8s 1.28.7
• written very close according to official guide and their helm example plugin

[dd84ai]

Got excited with this topic. Now this cue plugin is in its own repository in Golang with unit tests

Thus i present argocd-cue with release v0.4.0

• it can still deploy cue manifests
• and it also has added ability to deploy helm charts written in cue ^_^
  • see folder examples in argocue
  • and extra examples for deployment in infra repo
• went with building docker image in multiarch arm64/amd64 support

• cleaned up code for version v0.4.0, to make a room for next features
  simplified passing of Application parameters

Made a plan of what can be done later