ProHoster > Blogg > Administration > Vi gÄr igenom Custom Tooling i Argo CD

Vi gÄr igenom Custom Tooling i Argo CD

Vi gÄr igenom Custom Tooling i Argo CD

Efter en tid efter att jag skrev den första artikeln, dÀr jag smidigt hanterade jsonnet och GitLab, insÄg jag att pipelines visserligen Àr bra, men det Àr onödigt komplicerat och ohandigt.

I de flesta fall behövs en typisk uppgift: "generera YAML och lÀgga den i Kubernetes". Det Àr just vad Argo CD hanterar pÄ ett utmÀrkt sÀtt.

Argo CD lÄter dig ansluta ett Git-repo och synkronisera dess tillstÄnd med Kubernetes. Som standard stöder den flera typer av applikationer: Kustomize, Helm-diagram, Ksonnet, ren Jsonnet eller bara kataloger med YAML/JSON-manifester.

För de flesta anvÀndare av detta paket Àr det tillrÀckligt, men inte för alla. För att tillgodose behoven hos alla och envar finns det möjlighet att anvÀnda anpassade verktyg i Argo CD.

Det som intresserar först och frÀmst Àr möjligheten att lÀgga till stöd för qbec och git-crypt, som fullstÀndigt har diskuterats i den tidigare artikeln.

Innan vi gÄr vidare till konfigurationen mÄste vi först förstÄ hur Argo CD fungerar.

För varje tillagd applikation har den tvÄ faser:

  • init – inledande förberedelse före distribueringsfasen, hĂ€r kan det vara allt möjligt: nedladdning av beroenden, avpackning av hemligheter och sĂ„ vidare.
  • generate – utförande av kommandot för att generera manifester, utdata mĂ„ste vara en giltig YAML-ström, vilket Ă€r just det som kommer att tillĂ€mpas i klustret.

Det som Àr vÀrt att notera Àr att Argo tillÀmpar detta tillvÀgagÄngssÀtt för alla typer av applikationer, inklusive Helm. SÄ i Argo CD hanterar Helm inte distribution av versioner i klustret, utan anvÀnds bara för att generera manifester.

Å sin sida kan Argo hantera Helm-hooks nativt, vilket gör att logiken för tillĂ€mpning av versioner inte störs.

QBEC

Qbec gör det möjligt att enkelt beskriva applikationer med hjÀlp av jsonnet och har dessutom möjlighet att rendera Helm-diagram. Eftersom Argo CD kan hantera Helm-hooks korrekt, gör anvÀndningen av denna funktion tillsammans med Argo CD att man kan uppnÄ Ànnu mer korrekta resultat.

För att lÀgga till stöd för qbec i argocd behövs tvÄ saker:

  • i Argo CDs konfiguration mĂ„ste din anpassade plugin och kommandon för att generera manifester definieras.
  • de nödvĂ€ndiga binĂ€rerna mĂ„ste finnas tillgĂ€ngliga i bilden argocd-repo-server.

Det första problemet löses ganska enkelt:

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

(kommandot init anvÀnds inte)

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

För att lÀgga till binÀrerna föreslÄs det att bygga en ny bild, eller anvÀnd tricket med init-behÄllaren:

# 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)"

LÄt oss nu se hur manifestet för vÄr applikation kommer att se ut:

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 variabeln ENVIRONMENT överlÀmnar vi namnet pÄ miljön för vilken vi behöver utföra generationen av manifest.

LÄt oss tillÀmpa och se vad vi har fÄtt:

Vi gÄr igenom Custom Tooling i Argo CD

applikationen har deployats, utmÀrkt!

git-crypt

Git-crypt gör det möjligt att konfigurera transparent kryptering av repository. Det Àr ett enkelt och sÀkert sÀtt att lagra konfidentiella uppgifter direkt i git.

Implementeringen av git-crypt har visat sig vara mer komplicerad.

Teoretiskt skulle vi kunna köra git-crypt unlock under init-fasen av vÄr anpassade plugin, men det Àr inte sÄ bekvÀmt, eftersom det inte skulle tillÄta oss att anvÀnda de inhemska deploymetoderna. Till exempel för Helm och Jsonnet förlorar vi det flexibla GUI-grÀnssnittet som förenklar konfigurationen av applikationen (values-filer och sÄ vidare).

Det Àr dÀrför vi ville utföra avvecklingen av repositoryn Ànnu tidigare, vid kloning.

Eftersom Argo CD för nÀrvarande inte erbjuder möjligheter att beskriva nÄgra hooks för synkronisering av repository, var vi tvungna att kringgÄ denna begrÀnsning med ett smart shell-script-wrapper som ersÀtter git-kommandot:

#!/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 kör git fetch varje gÄng före deploy-operationen. Det Àr pÄ detta kommando vi kommer att hÀnga utförandet git-crypt unlock för att lÄsa upp repositoryn.

För tester kan du anvÀnda min docker-image dÀr allt nödvÀndigt redan finns:

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

Nu mÄste vi tÀnka pÄ hur Argo kommer att avkoda vÄra repository. Det handlar om att generera en gpg-nyckel för den:

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

$ printf "%sn" 
    "%no-protection" 
    "Key-Type: default" 
    "Subkey-Type: default" 
    "Name-Real: DITT NAMN" 
    "Name-Email: DIN 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'

LÄt oss spara namnet pÄ nyckeln 8CB8B24F50B4797D för vidare steg. Vi exporterar sjÀlva nyckeln:

$ gpg --list-keys
gpg: VARNING: osÀkert Àgarskap av homedir '\/home\/argocd\/.gnupg'
\/home\/argocd\/.gnupg\/pubring.kbx
-------------------------------
pub   rsa3072 2020-09-04 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] DITT NAMN <DIN EPOST@example.com>
sub   rsa3072 2020-09-04 [E]

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

Och vi lÀgger till den som en separat hemlighet:

# 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 enda som ÄterstÄr Àr att föra in den i behÄllaren argocd-repo-server, för detta redigerar vi deployment:

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

Och vi ersÀtter den befintliga gpg-keys volymen med projected, dÀr vi anger vÄr hemlighet:

   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 laddar automatiskt gpg-nycklar frÄn denna katalog vid start av behÄllaren, sÄ den kommer att ladda Àven vÄr privata nyckel.

LĂ„t oss kontrollera:

$ kubectl -n argocd exec -ti deploy\/argocd-repo-server -- bash
$ GNUPGHOME=\/app\/config\/gpg\/keys gpg --list-secret-keys
gpg: VARNING: osÀkert Àgarskap av homedir '\/app\/config\/gpg\/keys'
\/app\/config\/gpg\/keys\/pubring.kbx
--------------------------------
sec   rsa2048 2020-09-05 [SC] [utgÄr: 2021-03-04]
      ED6285A3B1A50B6F1D9C955E5E8B1B16D47FFC28
uid           [ultimate] Anon Ymous (ArgoCD nyckelsigneringsnyckel) <noreply@argoproj.io>

sec   rsa3072 2020-09-03 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] DITT NAMN <DIN EPOST@example.com>
ssb   rsa3072 2020-09-03 [E]

UtmÀrkt, nyckeln har laddats! Nu rÀcker det med att lÀgga till Argo CD som medarbetare i vÄrt repo sÄ kan den automatiskt dekryptera den i realtid.

Vi importerar nyckeln till den lokala datorn:

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

Vi stÀller in tillitsnivÄn:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Vi lÀgger till argo som medarbetare i vÄrt projekt:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Relaterade lÀnkar:

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster