Efter en periode efter at have skrevet den første artikel, hvor jeg dygtigt arbejdede med jsonnet og GitLab, indså jeg, at pipelines er bestemt gode, men alt for komplekse og besværlige.

I de fleste tilfælde er der behov for en standardopgave: "generere YAML og lægge det i Kubernetes". Det er netop det, som Argo CD klarer fremragende.

Argo CD gør det muligt at tilslutte et Git-repositorium og synkronisere dets tilstand i Kubernetes. Som standard understøtter det flere typer applikationer: Kustomize, Helm charts, Ksonnet, ren Jsonnet eller blot mapper med YAML/JSON-manifester.

De fleste brugere af dette værktøjssæt vil finde det tilstrækkeligt, men ikke alle. For at imødekomme behovene hos alle og enhver har Argo CD mulighed for at bruge tilpassede værktøjer.

Først og fremmest interesserer jeg mig for muligheden for at tilføje support for qbec og git-crypt, som blev grundigt gennemgået i den tidligere artikel.

Før vi går i gang med konfigurationen, skal vi først forstå, hvordan Argo CD faktisk fungerer.

For hver tilføjet applikation har den to faser:

init — indledende forberedelse inden deployment, her kan der være alt muligt: download af afhængigheder, udpakning af hemmeligheder og andet.
generate — udførelse af selve kommandoen til generering af manifester, outputtet skal være en gyldig YAML-strøm, det er netop det, der vil blive anvendt i klyngen.

Det bemærkelsesværdige er, at Argo anvender denne tilgang til enhver type applikationer, herunder Helm. Det vil sige, at Argo CD ikke er ansvarlig for at deploye releases i klyngen, men kun til at generere manifester.

Argo kan natively håndtere Helm-hooks, hvilket gør det muligt ikke at forstyrre logikken i release-applikationen.

QBEC

Qbec gør det nemt at beskrive applikationer ved hjælp af jsonnet, og derudover har det mulighed for at renderere Helm-charts. Da Argo CD kan håndtere Helm-hooks korrekt, gør det mulig brugen af denne funktion i Argo CD det muligt at opnå endnu mere præcise resultater.

For at tilføje support for qbec i argocd kræves der to ting:

i konfigurationen af Argo CD skal din custom plugin og kommandoer til generering af manifester defineres.
de nødvendige binære filer skal være tilgængelige i billedet argocd-repo-server.

Den første opgave løses ganske enkelt:

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

(kommandoen init anvendes ikke)

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

For at tilføje binære filer anbefales det at samle et nyt billede, eller brug trik med 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)"

Lad os nu se, hvordan manifestet for vores applikation vil se ud:

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

I variablen MILJØ vi sender navnet på miljøet, for hvilket vi skal generere manifesterne.

lad os anvende det og se, hvad vi har fået:

applikationen er blevet deployet, fantastisk!

git-crypt

Git-crypt gør det muligt at opsætte gennemsigtig kryptering af repository. Det er en enkel og sikker måde at gemme fortrolige oplysninger direkte i git.

Implementeringen med git-crypt viste sig at være sværere.

Teoretisk set kunne vi udføre git-crypt unlock i init-fasen af vores custom-plugin, men det er ikke særlig praktisk, da det ikke ville tillade brug af native deploymetoder. For eksempel i tilfælde af Helm og Jsonnet, mister vi det fleksible GUI, der gør det nemmere at konfigurere applikationen (values-filer og andet).

Netop derfor ville vi gerne udføre udpakning af repository allerede i et tidligere trin, under kloning.

Da Argo CD på nuværende tidspunkt ikke giver mulighed for at beskrive nogen hooks til synkronisering af repository, måtte vi omgå denne begrænsning med et smart shell-script, der fungerer som en wrapper, som erstatter git-kommandoen:

#!/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 udfører git fetch hver gang før deployment-operationen. Det er på denne kommando, vi vil hænge udførelsen git-crypt unlock for at låse repository op.

til testformål kan du bruge mit docker-image hvor alt det nødvendige allerede er inkluderet:

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

Nu skal vi tænke over, hvordan Argo vil dekryptere vores repositories. Det vil sige generere en gpg-nøgle til det:

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

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

$ gpg --batch --gen-key genkey-batch
gpg: WARNING: unsafe ownership on homedir '/home/argocd/.gnupg'
gpg: keybox '/home/argocd/.gnupg/pubring.kbx' created
gpg: /home/argocd/.gnupg/trustdb.gpg: trustdb created
gpg: key 8CB8B24F50B4797D marked as ultimately trusted
gpg: directory '/home/argocd/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/argocd/.gnupg/openpgp-revocs.d/9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D.rev'

Lad os gemme nøglens navn 8CB8B24F50B4797D til de næste skridt. Vi eksporterer nøglen:

$ gpg --list-keys
gpg: ADVARSEL: usikker ejerskab på hjemmemappe '\/home\/argocd\/\.gnupg'
\/home\/argocd\/\.gnupg\/pubring.kbx
-------------------------------
pub   rsa3072 2020-09-04 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] DIT NAVN <DIN EMAIL@example.com>
sub   rsa3072 2020-09-04 [E]

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

Og vi tilføjer det som en separat hemmelighed:

# 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

Det eneste vi har tilbage, er at passe det ind i containeren argocd-repo-server, for at gøre dette redigerer vi deployment:

$ kubectl -n argocd edit deploy\/argocd-repo-server

Og vi erstatter den eksisterende gpg-keys volumen med projected, hvor vi angiver vores hemmelighed:

   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 indlæser automatisk gpg-nøgler fra denne mappe, når containeren startes, således at den også indlæser vores private nøgle.

lad os tjekke:

$ kubectl -n argocd exec -ti deploy\/argocd-repo-server -- bash
$ GNUPGHOME=\/app\/config\/gpg\/keys gpg --list-secret-keys
gpg: ADVARSEL: usikker ejerskab på hjemmemappe '\/app\/config\/gpg\/keys'
\/app\/config\/gpg\/keys\/pubring.kbx
--------------------------------
sec   rsa2048 2020-09-05 [SC] [udløber: 2021-03-04]
      ED6285A3B1A50B6F1D9C955E5E8B1B16D47FFC28
uid           [ultimate] Anon Ymous (ArgoCD nøgle signering nøgle) <noreply@argoproj.io>

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

Fremragende, nøglen er indlæst! Nu skal vi bare tilføje Argo CD som en samarbejdspartner i vores repository, og så kan den automatisk dekryptere den.

Importer nøglen til den lokale computer:

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

Lad os indstille tillidsniveauet:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Vi tilføjer argo som samarbejdspartner i vores projekt:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Links til emnet:

Kilde: habr.com

La oss se nærmere på Custom Tooling i Argo CD

QBEC

git-crypt