Dopo un po' di tempo dalla scrittura del primo articolo, dove gestivo abilmente jsonnet e GitLab, ho capito che le pipeline sono sicuramente utili, ma eccessivamente complesse e scomode.

Nella maggior parte dei casi è necessaria un'attività standard: "generare YAML e metterlo in Kubernetes". Proprio ciò con cui Argo CD eccelle.

Argo CD consente di collegare un repository Git e sincronizzarne lo stato in Kubernetes. Di default supporta diversi tipi di applicazioni: Kustomize, chart Helm, Ksonnet, jsonnet puro o semplicemente cartelle con manifesti YAML/JSON.

La maggior parte degli utenti di questo set sarà soddisfatta, ma non tutti. Per soddisfare le esigenze di ogni singolo utente, Argo CD offre la possibilità di utilizzare strumenti personalizzati.

In primo luogo, ci interessa la possibilità di aggiungere supporto qbec e git-crypt, che sono stati esaminati nel dettaglio nell'articolo precedente.

Prima di iniziare la configurazione, è necessario comprendere come funziona Argo CD.

Per ogni applicazione aggiunta, ha due fasi:

init — preparazione iniziale prima del deploy, qui può esserci di tutto: download delle dipendenze, sblocco dei segreti e altro.
generate — esecuzione della vera e propria generazione dei manifesti, l'output deve essere un flusso YAML valido, è proprio questo che sarà applicato nel cluster.

È interessante notare che Argo applica questo approccio a qualsiasi tipo di applicazione, incluso Helm. Quindi in Argo CD Helm non gestisce il deploy delle release nel cluster, ma è utilizzato solo per la generazione dei manifesti.

Dal canto suo, Argo è in grado di gestire nativamente i hook di Helm, permettendo di non compromettere la logica di applicazione delle release.

QBEC

Qbec consente di descrivere facilmente le applicazioni utilizzando jsonnet, e inoltre ha la possibilità di renderizzare chart Helm. Poiché Argo CD è in grado di gestire adeguatamente i hook di Helm, l'uso di questa possibilità con Argo CD consente di ottenere risultati ancora più corretti.

Per aggiungere supporto a qbec in argocd sono necessarie due cose:

nel config di Argo CD deve essere definito il tuo plugin personalizzato e i comandi per generare i manifesti.
i binari necessari devono essere disponibili nell'immagine argocd-repo-server.

La prima attività si risolve piuttosto semplicemente:

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

(il comando init non è utilizzato)

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

Per aggiungere i binari si propone di costruire una nuova immagine, oppure utilizzare un trucco con un 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)"

Ora vediamo come apparirà il manifesto della nostra applicazione:

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

Nella variabile ENVIRONMENT stiamo passando il nome dell'ambiente per il quale devono essere generati i manifesti.

applichiamo e vediamo cosa abbiamo ottenuto:

l'applicazione è stata deployata, ottimo!

git-crypt

Git-crypt consente di impostare una crittografia trasparente del repository. È un modo semplice e sicuro per memorizzare dati riservati direttamente in git.

Con l'implementazione di git-crypt è stato più complesso.

Teoricamente potremmo eseguire git-crypt unlock nella fase di inizializzazione del nostro plugin personalizzato, ma non è molto comodo, poiché non permetterebbe di utilizzare i metodi di deploy nativi. Ad esempio, nel caso di Helm e Jsonnet, perdiamo un'interfaccia GUI flessibile che semplifica la configurazione dell'applicazione (file values e altro).

Per questo motivo, volevamo eseguire lo sblocco del repository ancora in una fase precedente, durante il cloning.

Poiché attualmente Argo CD non fornisce la possibilità di descrivere alcun hook per la sincronizzazione del repository, abbiamo dovuto aggirare questa limitazione con un ingegnoso script shell che sostituisce il comando git:

#!/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 esegue git fetch ogni volta prima dell'operazione di deploy. È proprio su questo comando che ci attaccheremo git-crypt unlock per sbloccare il repository.

per i test puoi utilizzare la mia immagine docker in cui c'è già tutto il necessario:

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

Ora dobbiamo pensare a come Argo decripterà i nostri repository. Ovvero, generare una chiave gpg per esso:

$ 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'

Salveremo il nome della chiave 8CB8B24F50B4797D per i passaggi successivi. Esporteremo la chiave stessa:

$ gpg --list-keys
gpg: ATTENZIONE: proprietà non sicura sulla home directory '/home/argocd/.gnupg'
/home/argocd/.gnupg/pubring.kbx
-------------------------------
pub   rsa3072 2020-09-04 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] IL TUO NOME <IL TUO EMAIL@example.com>
sub   rsa3072 2020-09-04 [E]

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

E lo aggiungeremo come segreto separato:

# 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

L'unica cosa che ci resta da fare è passarla nel contenitore argocd-repo-server, per questo modifichiamo il deployment:

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

E sostituiamo l'attuale gpg-keys volume con projected, dove specificheremo il nostro segreto:

   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 carica automaticamente le chiavi gpg da questa directory all'avvio del contenitore, quindi caricherà anche la nostra chiave privata.

Controlliamo:

$ kubectl -n argocd exec -ti deploy/argocd-repo-server -- bash
$ GNUPGHOME=/app/config/gpg/keys gpg --list-secret-keys
gpg: ATTENZIONE: proprietà non sicura sulla home directory '/app/config/gpg/keys'
/app/config/gpg/keys/pubring.kbx
--------------------------------
sec   rsa2048 2020-09-05 [SC] [scade: 2021-03-04]
      ED6285A3B1A50B6F1D9C955E5E8B1B16D47FFC28
uid           [ultimate] Anon Ymous (chiave di firma ArgoCD) <noreply@argoproj.io>

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

Ottimo, la chiave è stata caricata! Ora dobbiamo semplicemente aggiungere Argo CD al nostro repository come collaboratore e potrà automaticamente decrittarla al volo.

Importiamo la chiave sul computer locale:

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

Impostiamo il livello di fiducia:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Aggiungiamo argo come collaboratore nel nostro progetto:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Link utili:

Fonte: habr.com

Esploriamo il Custom Tooling in Argo CD

QBEC

git-crypt