Iom da tempo post skribado unua artikolo, kie mi lerte administris jsonnet kaj gitlab, mi konstatis, ke duktoj estas certe bonaj, sed nenecese komplikaj kaj maloportunaj.

Plejofte, tipa tasko estas postulata: "geniru YAML kaj metu ĝin en Kubernetes." Efektive, ĉi tion la Argo KD faras rimarkinde bone.

Argo KD permesas vin konekti Git-deponejon kaj sendi ĝian staton al Kubernetes. Defaŭlte, ekzistas subteno por pluraj specoj de aplikoj: Kustomize, Helm-diagramoj, Ksonnet, nuda Jsonnet, aŭ nur dosierujoj kun YAML/JSON manifestoj.

Ĉi tiu aro sufiĉos por plej multaj uzantoj, sed ne por ĉiuj. Por renkonti la bezonojn de ĉiuj, Argo KD havas la kapablon uzi kutimajn ilojn.

Antaŭ ĉio, mi interesiĝas pri la ebleco aldoni subtenon qbec и git-crypt, kiuj estis plene diskutitaj en la antaŭa artikolo.

Antaŭ ol vi komencas la agordon, vi unue devas kompreni precize kiel funkcias Argo CD.

Por ĉiu aldonita aplikaĵo, ĝi havas du fazojn:

• en ĝi — komenca preparo antaŭ deplojo, ĉio povas okazi ĉi tie: elŝuti dependecojn, malpaki sekretojn, kaj pli.
• generi — rekte efektivigante la manifest-generacian komandon, la eligo devas esti valida YAML-rivereto, tio estas ĝuste kio estos aplikita al la areto.

Kio estas rimarkinda estas, ke Argo aplikas ĉi tiun aliron al ajna tipo de aplikaĵo, inkluzive de Helm. Tio estas, en Argo CD Helm ne deplojas eldonojn al la areto, sed estas uzata nur por generi manifestojn.

Siaflanke, Argo povas prilabori Helm-hokojn denaske, kio permesas al ĝi ne malobservi la logikon apliki ĵetojn.

QBEC

Qbec permesas vin oportune priskribi aplikaĵojn uzante jsonnet, kaj krome havas la kapablon bildigi Helm-diagramojn, kaj ĉar Argo KD povas normale prilabori Helm-hokojn, uzi ĉi tiun funkcion kun Argo KD permesas atingi eĉ pli ĝustajn rezultojn.

Por aldoni qbec-subtenon al argocd vi bezonas du aferojn:

• En la agordo de Argo KD, via kutima kromaĵo kaj komandoj por generi manifestojn devas esti difinitaj.
• la necesaj binaroj devas esti disponeblaj en la bildo argocd-repo-servilo.

Unua tasko estas decidita sufiĉe simpla:

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

(teamo en ĝi ne uzata)

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

Por aldoni binarojn ĝi estas sugestita kolekti novan bildon, aŭ uzi init ujo truko:

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

Nun ni vidu kiel aspektos nia aplika manifesto:

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

En variablo AMBIENTO ni pasas la nomon de la medio por kiu ni bezonas generi manifestojn.

ni apliku ĝin kaj vidu, kion ni ricevas:

La aplikaĵo estis deplojita, bonege!

git-crypt

Git-crypt permesas al vi agordi travideblan ĉifradon por via deponejo. Ĝi estas simpla kaj sekura maniero stoki sentemajn datumojn rekte en git.

La efektivigo de git-crypt montriĝis pli malfacila.

Teorie ni povus fari git-crypt unlock en la init-fazo de nia kutima kromaĵo, sed ĉi tio ne estas tre oportuna, ĉar ĝi ne permesus la uzon de denaskaj disfaldaj metodoj. Ekzemple, en la kazo de Helm kaj Jsonnet, ni perdas flekseblan GUI-interfacon, kiu ebligas al ni simpligi aplikaĵan agordon (valoraj dosieroj, ktp.).

Jen kial mi volis presi la deponejon en pli frua etapo, dum klonado.

Ĉar nuntempe Argo KD ne disponigas la kapablon priskribi iujn ajn hokojn por sinkronigi la deponejon, ni devis ĉirkaŭiri ĉi tiun limigon per delikata ŝela skripto, kiu anstataŭigas la komandon 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 KD rezultas git fetch ĉiufoje antaŭ la deploja operacio. Estas ĉi tiu komando al kiu ni asignos ekzekuton git-crypt unlock por malŝlosi la deponejon.

por provoj vi povas uzi mia docker-bildo kiu jam havas ĉion, kion vi bezonas:

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

Nun ni devas pensi pri kiel Argo malĉifris niajn deponejojn. Nome, generu gpg-ŝlosilon por ĝi:

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

Ni konservu la ŝlosilan nomon 8CB8B24F50B4797D por pliaj paŝoj. Eksportu la ŝlosilon mem:

$ 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

Kaj aldonu ĝin kiel apartan sekreton:

# 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

Restas nur al ni ĵeti ĝin en la ujon argocd-repo-servilo, por fari tion, redaktu la deplojon:

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

Kaj ni anstataŭigos la ekzistantan gpg-klavoj volumo sur projected, kie ni indikas nian sekreton:

   spec:
     template:
       spec:
         volumes:
         - name: gpg-keys
           projected:
             defaultMode: 420
             sources:
             - secret:
                 name: argocd-gpg-keys-secret
             - configMap:
                 name: argocd-gpg-keys-cm

Argo KD aŭtomate ŝargas gpg-ŝlosilojn de ĉi tiu dosierujo kiam la ujo komenciĝas, do ĝi ankaŭ ŝargos nian privatan ŝlosilon.

ni kontrolu:

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

Bonege, la ŝlosilo estas ŝarĝita! Nun ni nur bezonas aldoni Argo KD al nia deponejo kiel kunlaboranto kaj ĝi povos aŭtomate deĉifri ĝin sur la flugo.

Importu la ŝlosilon al la loka komputilo:

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

Ni agordu la fidnivelon:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Ni aldonu argo kiel kunlaboranton al nia projekto:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Rilataj ligiloj:

• GitHub: deponejo kun modifita bildo
• Argo KD: Propra Ilaro
• Argo KD: Agordaj Administraj Kromaĵoj
• GitHub Gist: generu gpg-ŝlosilojn sen pasvorto en ne-interaga reĝimo

fonto: www.habr.com