Enkele tijd na het schrijven eerste artikel, waar ik handig met jsonnet en gitlab omging, kwam ik erachter dat pipelines natuurlijk goed zijn, maar onnodig ingewikkeld en onhandig.

In de meeste gevallen bestaat de typische taak uit het 'genereren van een YAML en deze in Kubernetes plaatsen'. Dit is precies wat Argo CD opmerkelijk goed doet.

Met Argo CD kunt u verbinding maken met een Git-repository en de status synchroniseren met Kubernetes. Standaard is er ondersteuning voor verschillende typen applicaties: Kustomize, Helm-grafieken, Ksonnet, kale Jsonnet of alleen mappen met YAML/JSON-manifesten.

Voor de meeste gebruikers is deze set voldoende, maar niet voor iedereen. Om aan de behoeften van iedereen te kunnen voldoen, kan Argo CD gebruikmaken van aangepaste gereedschappen.

In de eerste plaats ben ik geïnteresseerd in de mogelijkheid om ondersteuning toe te voegen qbec и git-crypt, die in het vorige artikel uitgebreid zijn besproken.

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

Voor elke toegevoegde toepassing zijn er twee fasen:

init — eerste voorbereiding vóór de implementatie. Dit kan van alles zijn: afhankelijkheden downloaden, geheimen uitpakken, etc.
voortbrengen - de opdracht voor het genereren van het manifest rechtstreeks uitvoeren. De uitvoer moet een geldige YAML-stroom zijn. Dit is precies wat op het cluster wordt toegepast.

Het opmerkelijke is dat Argo deze aanpak toepast op elk type toepassing, dus ook op Helm. Dat wil zeggen dat CD Helm in Argo geen releases naar het cluster implementeert, maar alleen wordt gebruikt om manifesten te genereren.

Argo kan daarentegen Helm-hooks native verwerken, waardoor de logica van het toepassen van releases niet wordt geschonden.

QBEC

Met Qbec kunt u op een handige manier toepassingen beschrijven met behulp van JSONNET. Ook kunt u met Qbec Helm-grafieken weergeven. En omdat Argo CD op de gebruikelijke manier met Helm-hooks overweg kan, kunt u met deze functie in combinatie met Argo CD nog nauwkeurigere resultaten behalen.

Om qbec-ondersteuning aan argocd toe te voegen, heb je twee dingen nodig:

De Argo CD-configuratie moet uw aangepaste plug-in en opdrachten voor het genereren van manifesten definiëren.
de vereiste binaire bestanden moeten beschikbaar zijn in de afbeelding argocd-repo-server.

Eerste taak wordt besloten best makkelijk:

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

(team init niet gebruikt)

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

Om binaire bestanden toe te voegen wordt voorgesteld een nieuw beeld samenstellen, of gebruik init container truc:

# 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 eens kijken hoe ons applicatiemanifest 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

Variabel MILIEU We geven de naam door van de omgeving waarvoor we manifesten moeten genereren.

Laten we het toepassen en kijken wat het oplevert:

De applicatie is geïmplementeerd, geweldig!

git-crypt

Met Git-crypt kunt u transparante encryptie van uw repository instellen. Dit is een eenvoudige en veilige manier om gevoelige gegevens rechtstreeks in Git op te slaan.

Het implementeren van git-crypt bleek lastiger.

Theoretisch gezien zouden we dit kunnen doen git-crypt unlock in de init-fase van onze aangepaste plugin, maar dit is niet erg handig omdat het niet mogelijk is om native implementatiemethoden te gebruiken. In het geval van Helm en Jsonnet verliezen we bijvoorbeeld de flexibele GUI-interface waarmee we de configuratie van de applicatie kunnen vereenvoudigen (waardenbestanden, enz.).

Dat is precies de reden waarom ik de repository al in een eerder stadium wilde ontzegelen, namelijk tijdens het klonen.

Omdat Argo CD momenteel niet de mogelijkheid biedt om hooks te beschrijven voor het synchroniseren van een repository, moesten we deze beperking omzeilen met een slimme shell-scriptwrapper 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 treedt op git fetch elke keer vóór de implementatiebewerking. Het is aan dit bevel dat wij de uitvoering zullen toewijzen git-crypt unlock om de repository te ontgrendelen.

voor tests die u kunt gebruiken mijn docker-image die al alles heeft wat je nodig hebt:

$ 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 gaat decoderen. Genereer er namelijk een gpg-sleutel voor:

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

Laten we de sleutelnaam opslaan 8CB8B24F50B4797D voor verdere stappen. We exporteren de sleutel zelf:

$ gpg --list-keys
gpg: WARNING: unsafe ownership on homedir '/home/argocd/.gnupg'
/home/argocd/.gnupg/pubring.kbx
-------------------------------
pub   rsa3072 2020-09-04 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] YOUR NAME <YOUR EMAIL@example.com>
sub   rsa3072 2020-09-04 [E]

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

En laten we het als een apart geheim toevoegen:

# 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 ons nu nog rest is het in de container te gooien. argocd-repo-serverOm dit te doen zullen we de implementatie bewerken:

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

En we zullen de bestaande vervangen gpg-sleutels volume aan projected, waar we ons geheim zullen aangeven:

   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 de gpg-sleutels uit deze directory wanneer de container start. Hierdoor wordt ook onze persoonlijke sleutel geladen.

Laten we eens kijken:

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

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

Geweldig, de sleutel is geladen! Nu hoeven we alleen nog maar Argo CD als medewerker aan onze repository toe te voegen. Vervolgens kan Argo CD de bestanden automatisch en direct decoderen.

We importeren de sleutel naar 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 toevoegen als medewerker aan ons project:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Gerelateerde links:

Bron: www.habr.com

Aangepaste gereedschappen begrijpen in Argo CD

QBEC

git-crypt

ProHoster