ProHoster > Blog > Administracija > Razumemo Custom Tooling v Argo CD

Razumemo Custom Tooling v Argo CD

Razumemo Custom Tooling v Argo CD

Nekaj časa po pisanju prvega članka, kjer sem veščino upravljanja s jsonnetom in gitlabom obvladoval, sem spoznal, da so delovni tokovi vsekakor dobri, toda preveč kompleksni in nepraktični.

V večini primerov je potrebna tipična naloga: "ustvari YAML in ga postavi v Kubernetes". Takšno nalogo Argo CD odlično opravi.

Argo CD omogoča povezavo z Git repozitorijem in sinhronizacijo njegovega stanja v Kubernetes. Privzeto podpira več vrst aplikacij: Kustomize, Helm karte, Ksonnet, goli Jsonnet ali preprosto imenike z YAML/JSON manifesti.

Večina uporabnikov tega skupa bo zadovoljna, a ne vsi. Da bi zadovoljili vse potrebe, Argo CD ponuja možnost uporabe prilagodljivih orodij.

Najprej me zanima možnost dodajanja podpore qbec in git-crypt, ki so že v celoti obravnavane v prejšnjem članku.

Preden se lotimo konfiguracije, se moramo najprej seznaniti s tem, kako Argo CD deluje.

Za vsako dodano aplikacijo ima dve fazi:

  • init — začetna priprava pred nalaganjem, kjer je lahko vse: prenos odvisnosti, razpakiranje skrivnosti in še več.
  • generate — neposredno izvajanje ukaza za generiranje manifestov, izhod mora biti veljaven YAML tok, točno to bo uporabljeno v klasterju.

Zanimivo je, da Argo uporablja ta pristop za vse vrste aplikacij, vključno s Helm. To pomeni, da Argo CD ne izvaja nalaganja izdaj v klaster, temveč se uporablja izključno za generiranje manifestov.

Argo sam po sebi lahko natančno obdeluje Helm-hooke, kar omogoča ohranjanje logike pri uporabi izdaj.

QBEC

Qbec omogoča enostavno opisovanje aplikacij s pomočjo jsonneta, poleg tega pa ima možnost renderiranja Helm kart, in ker Argo CD zmore pravilno obdelovati Helm-hooke, uporaba te možnosti z Argo CD prinaša še natančnejše rezultate.

Za dodajanje podpore qbec v argocd sta potrebni dve stvari:

  • v konfiguraciji Argo CD mora biti določen vaš prilagojeni vtičnik in ukazi za generiranje manifestov.
  • potrebni binarki morajo biti dostopni v sliki argocd-repo-server.

Prva naloga se reši dokaj enostavno:

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

(ukaz init se ne uporablja)

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

Za dodajanje binarkov se predlaga ustvariti novo sliko, ali uporabiti trik s init-kontejnerom:

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

Zdaj pogledajmo, kako bo izgledal manifest naše aplikacije:

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

OLD_RMQ ENVIRONMENT tu predajamo ime okolja, za katerega je treba generirati manifeste.

uporabimo in poglejmo, kaj smo dobili:

Razumemo Custom Tooling v Argo CD

aplikacija je bila uspešno nameščena, odlično!

git-crypt

Git-crypt omogoča nastavitev preglednega šifriranja repozitorija. To je preprost in varen način za shranjevanje zaupnih podatkov neposredno v gitu.

Z implementacijo git-crypt se je izkazalo, da je nekoliko bolj zapleteno.

Teoretično bi lahko izvajali git-crypt unlock v init-fazi našega custom vtičnika, vendar to ni najbolj priročno, saj ne bi omogočilo uporabe naravnih metod nameščanja. Na primer, v primeru Helma in Jsonneta izgubljamo prilagodljiv GUI, ki poenostavi nastavitev aplikacije (values-datoteke in druge).

Zato smo želeli izvesti dešifriranje repozitorija še v zgodnejši fazi, pri kloniranju.

Ker trenutno Argo CD ne nudi možnosti za opisovanje kakršnihkoli hookov za sinhronizacijo repozitorija, smo morali to omejitev obiti s spretno skripto v sheli, ki nadomešča ukaz 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 izvede git fetch vsakič pred operacijo nameščanja. Na to ukaz namestimo izvajanje git-crypt unlock za dešifriranje repozitorija.

za teste lahko uporabite mojo docker-sliko v kateri je že vse potrebno:

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

Zdaj moramo razmisliti o tem, kako bo Argo dešifriral naše repozitorije. Konkretno, kako ustvariti gpg-ključ zanj:

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

Shrani ime ključa 8CB8B24F50B4797D za nadaljnje korake. Izvažamo sam ključ:

$ 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 
sub   rsa3072 2020-09-04 [E]

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

In dodamo to kot ločeno skrivnost:

# 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

Edina stvar, ki jo moramo storiti, je, da jo preusmerimo v kontejner argocd-repo-server, zato uredimo deployment:

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

In nadomestimo obstoječo gpg-keys delenje z projected, kjer bomo navedli našo skrivnost:

   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 samodejno naloži gpg ključe iz te imenika ob zagonu vsebnika, tako da bo naložil tudi naš zasebni ključ.

preverimo:

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

sec   rsa3072 2020-09-03 [SC]
      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D
uid           [ultimate] YOUR NAME 
ssb   rsa3072 2020-09-03 [E]

Odlično, ključ je naložen! Zdaj nam je dovolj, da dodamo Argo CD v naš repozitorij kot sodelavca in lahko ga bo samodejno dešifriral v realnem času.

Uvozimo ključ na lokalni računalnik:

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

Nastavimo raven zaupanja:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Dodamo argo kot sodelavca v naš projekt:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Povezave o temi:

Izvor: habr.com

Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki 🔥 Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki | ProHoster