Na een tijdje na het schrijven van het eerste artikel, waarin ik handig omging met jsonnet en GitLab, realiseerde ik me dat pipelines natuurlijk goed zijn, maar te ingewikkeld en onhandig.

In de meeste gevallen is er een standaardtaak vereist: "genereer YAML en zet het in Kubernetes". Daarin blinkt Argo CD echt in uit.

Argo CD maakt het mogelijk om een Git-repository aan te sluiten en de status ervan te synchroniseren met Kubernetes. Standaard zijn er meerdere soorten applicaties ondersteund: Kustomize, Helm charts, Ksonnet, pure Jsonnet of gewoon directories met YAML/JSON-manifesten.

Voor de meeste gebruikers van deze set zal dit voldoende zijn, maar niet voor iedereen. Om aan de behoeften van iedereen te voldoen, biedt Argo CD de mogelijkheid om custom tooling te gebruiken.

Als eerste willen we de mogelijkheid om ondersteuning toe te voegen qbec en git-crypt, die uitgebreid zijn behandeld in het vorige artikel.

Voordat we met de configuratie beginnen, moeten we eerst begrijpen hoe Argo CD precies werkt.

Voor elke toegevoegde applicatie heeft het twee fasen:

, wat erg handig is. Bovendien kunnen meerdere configuraties worden geschreven: ontwikkelen op de standaardconfiguratie, en daarna implementeren met het commando — initiële voorbereiding vóór de deployment, hier kan van alles gebeuren: het downloaden van afhankelijkheden, het uitpakken van secrets en meer.
genereer — het daadwerkelijk uitvoeren van de opdracht voor het genereren van manifesten, de output moet een valide YAML-stream zijn, dat is precies wat in de cluster zal worden toegepast.

Het opmerkelijke is dat Argo deze aanpak voor elk type applicatie gebruikt, inclusief Helm. In Argo CD houdt Helm dus niet bezig met het deployen van releases in de cluster, maar wordt alleen gebruikt voor het genereren van manifesten.

Aan de andere kant kan Argo native Helm-hooks verwerken, wat de logica van het toepassen van releases niet verstoort.

QBEC

Qbec maakt het gemakkelijk om applicaties met jsonnet te beschrijven, en het heeft ook de mogelijkheid om Helm-charts te renderen. Aangezien Argo CD Helm-hooks goed kan verwerken, stelt het gebruik van deze functie met Argo CD ons in staat om nog betere resultaten te behalen.

Om ondersteuning voor qbec in argocd toe te voegen, zijn er twee dingen nodig:

In de Argo CD-configuratie moet uw custom plugin en de commando's voor het genereren van manifesten gedefinieerd zijn.
De benodigde binaire bestanden moeten beschikbaar zijn in de afbeelding argocd-repo-server.

De eerste taak wordt redelijk eenvoudig opgelost:

# cm.yaml
data:
  configManagementPlugins: |
    - name: qbec
      generate:
        command: [sh, -xc]
        args: ['qbec show "$ENVIRONMENT" -S --force:k8s-namespace "$ARGOCD_APP_NAMESPACE"']

(commando , wat erg handig is. Bovendien kunnen meerdere configuraties worden geschreven: ontwikkelen op de standaardconfiguratie, en daarna implementeren met het commando wordt niet gebruikt)

$ kubectl -n argocd patch cm/argocd-cm -p "$(cat cm.yaml)"

Voor het toevoegen van binaire bestanden wordt voorgesteld een nieuwe afbeelding te bouwen, of gebruik te maken van truc met een init-container:

# deploy.yaml
spec:
  template:
    spec:
      # 1. Define an emptyDir volume which will hold the custom binaries
      volumes:
      - name: custom-tools
        emptyDir: {}
      # 2. Use an init container to download/copy custom binaries into the emptyDir
      initContainers:
      - name: download-tools
        image: alpine:3.12
        command: [sh, -c]
        args:
        - wget -qO- https://github.com/splunk/qbec/releases/download/v0.12.2/qbec-linux-amd64.tar.gz | tar -xvzf - -C /custom-tools/
        volumeMounts:
        - mountPath: /custom-tools
          name: custom-tools
      # 3. Volume mount the custom binary to the bin directory (overriding the existing version)
      containers:
      - name: argocd-repo-server
        volumeMounts:
        - mountPath: /usr/local/bin/qbec
          name: custom-tools
          subPath: qbec
        - mountPath: /usr/local/bin/jsonnet-qbec
          name: custom-tools
          subPath: jsonnet-qbec

$ kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"

Laten we nu kijken hoe het manifest van onze applicatie eruit zal zien:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: qbec-app
  namespace: argocd
spec:
  destination: 
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source: 
    path: qbec-app
    plugin: 
      env: 
        - name: ENVIRONMENT
          value: default
      name: qbec
    repoURL: https://github.com/kvaps/argocd-play
  syncPolicy: 
    automated: 
      prune: true

In de variabele ENVIRONMENT geven we de naam van de omgeving door waarvoor de manifestgeneratie moet plaatsvinden.

laten we het toepassen en kijken wat we hebben bereikt:

de applicatie is succesvol gedeployd, geweldig!

git-crypt

Git-crypt maakt transparante encryptie van de repository mogelijk. Dit is een eenvoudige en veilige manier om vertrouwelijke gegevens direct in git op te slaan.

Met de implementatie van git-crypt bleek het lastiger.

Theoretisch zouden we kunnen uitvoeren git-crypt unlock in de init-fase van onze custom plugin, maar dat is niet heel praktisch, omdat het native deploy-methoden zou uitsluiten. Bijvoorbeeld in het geval van Helm en Jsonnet verliezen we de flexibele GUI-interface die het gemakkelijker maakt om de applicatie in te stellen (values-bestanden en meer).

Daarom wilden we de repository al eerder uitpakken, tijdens het klonen.

Aangezien Argo CD op dit moment geen mogelijkheid biedt om hooks voor repository-synchronisatie te beschrijven, moesten we deze beperking omzeilen met een slimme shell-script-wrapper die de git-opdracht vervangt:

#!/bin/sh
$(dirname $0)/git.bin "$@"
ec=$?
[ "$1" = fetch ] && [ -d .git-crypt ] || exit $ec
GNUPGHOME=/app/config/gpg/keys git-crypt unlock 2>/dev/null
exit $ec

Argo CD voert git fetch elke keer uit vóór de deployment operatie. Precis daarop zullen we de uitvoering koppelen git-crypt unlock voor het ontgrendelen van de repository.

Voor tests kun je gebruiken mijn docker-image waarin alles al aanwezig is:

$ kubectl -n argocd set image deploy/argocd-repo-server argocd-repo-server=docker.io/kvaps/argocd-git-crypt:v1.7.3

Nu moeten we nadenken over hoe Argo onze repositories zal ontsleutelen. Namelijk het genereren van een gpg-sleutel voor hem:

$ kubectl exec -ti deploy/argocd-repo-server -- bash

$ printf "%sn" 
    "%no-protection" 
    "Key-Type: default" 
    "Subkey-Type: default" 
    "Name-Real: JOUW NAAM" 
    "Name-Email: JOUW EMAIL@example.com" 
    "Expire-Date: 0" 
    > genkey-batch 

$ gpg --batch --gen-key genkey-batch
gpg: WAARSCHUWING: onveilige eigendom op homedir '/home/argocd/.gnupg'
gpg: keybox '/home/argocd/.gnupg/pubring.kbx' aangemaakt
gpg: '/home/argocd/.gnupg/trustdb.gpg': trustdb aangemaakt
gpg: key 8CB8B24F50B4797D gemarkeerd als uiteindelijk vertrouwd
gpg: map '/home/argocd/.gnupg/openpgp-revocs.d' aangemaakt
gpg: herroepingscertificaat opgeslagen als '/home/argocd/.gnupg/openpgp-revocs.d/9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D.rev'

Laten we de naam van de sleutel opslaan 8CB8B24F50B4797D voor verdere stappen. We exporteren de sleutel:

$ gpg --list-keys
gpg: WAARSCHUWING: onveilige eigendom op homedir '⁄home⁄argocd⁄.gnupg'
⁄home⁄argocd⁄.gnupg⁄pubring.kbx
-------------------------------
pub   rsa3072 2020-09-04 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] JOUW NAAM <JOUW EMAIL@example.com>
sub   rsa3072 2020-09-04 [E]

$ gpg --armor --export-secret-keys 8CB8B24F50B4797D

En we voegen deze toe als een aparte geheim:

# argocd-gpg-keys-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: argocd-gpg-keys-secret
  namespace: argocd
stringData:
  8CB8B24F50B4797D: |-
    -----BEGIN PGP PRIVATE KEY BLOCK-----

    lQVYBF9Q8KUBDACuS4p0ctXoakPLqE99YLmdixfF/QIvXVIG5uBXClWhWMuo+D0c
    ZfeyC5GvH7XPUKz1cLMqL6o/u9oHJVUmrvN/g2Mnm365nTGw1M56AfATS9IBp0HH
    O/fbfiH6aMWmPrW8XIA0icoOAdP+bPcBqM4HRo4ssbRS9y/i
    =yj11
    -----END PGP PRIVATE KEY BLOCK-----

$ kubectl apply -f argocd-gpg-keys-secret.yaml

Het enige wat we nog moeten doen, is deze doorgeven aan de container argocd-repo-server, hiervoor bewerken we de deployment:

$ kubectl -n argocd edit deploy⁄argocd-repo-server

En vervangen de bestaande gpg-keys volume met projected, waar we ons geheim zullen opgeven:

   spec:
     template:
       spec:
         volumes:
         - name: gpg-keys
           projected:
             defaultMode: 420
             sources:
             - secret:
                 name: argocd-gpg-keys-secret
             - configMap:
                 name: argocd-gpg-keys-cm

Argo CD laadt automatisch gpg-sleutels uit deze directory bij het starten van de container, zodat het ook onze privé-sleutel zal laden.

Laten we het controleren:

$ kubectl -n argocd exec -ti deploy⁄argocd-repo-server -- bash
$ GNUPGHOME=⁄app⁄config⁄gpg⁄keys gpg --list-secret-keys
gpg: WAARSCHUWING: onveilige eigendom op homedir '⁄app⁄config⁄gpg⁄keys'
⁄app⁄config⁄gpg⁄keys⁄pubring.kbx
--------------------------------
sec   rsa2048 2020-09-05 [SC] [verloopt: 2021-03-04]
      ED6285A3B1A50B6F1D9C955E5E8B1B16D47FFC28
uid           [ultimate] Anon Ymous (ArgoCD key signing key) <noreply@argoproj.io>

sec   rsa3072 2020-09-03 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] JOUW NAAM <JOUW EMAIL@example.com>
ssb   rsa3072 2020-09-03 [E]

Geweldig, de sleutel is geladen! Nu hoeven we Argo CD alleen maar als collaborator aan onze repository toe te voegen, en dan kan het deze automatisch op de vlucht decoderen.

We importeren de sleutel op de lokale computer:

$ gpg --armor --export-secret 8CB8B24F50B4797D > 8CB8B24F50B4797D.pem
$ gpg --import 8CB8B24F50B4797D.pem

Laten we het vertrouwensniveau instellen:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Laten we argo als collaborator aan ons project toevoegen:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Links over het onderwerp:

Bron: habr.com

We gaan aan de slag met Custom Tooling in Argo CD

QBEC

git-crypt