Po pewnym czasie po napisaniu pierwszego artykułu, w którym sprawnie radziłem sobie z jsonnet i GitLabem, zrozumiałem, że pipeline'y są oczywiście dobre, ale zbytnio skomplikowane i niewygodne.

W większości przypadków wymagana jest typowa задача: "wygenerować YAML i umieścić go w Kubernetes". I tym właśnie zajmuje się Argo CD doskonale.

Argo CD pozwala podłączyć repozytorium Git i synchronizować jego stan z Kubernetes. Domyślnie obsługuje kilka rodzajów aplikacji: Kustomize, Helm Charty, Ksonnet, surowy Jsonnet lub po prostu katalogi z manifestami YAML/JSON.

Dla większości użytkowników tego zestawu to wystarczy, ale nie dla wszystkich. Aby zaspokoić potrzeby wszystkich, w Argo CD możliwe jest korzystanie z niestandardowych narzędzi.

W pierwszej kolejności interesuje możliwość dodania wsparcia dla qbec i git-crypt, które zostały w pełni omówione w poprzednim artykule.

Zanim przystąpimy do konfiguracji, musimy najpierw zrozumieć, jak dokładnie działa Argo CD.

Dla każdej dodanej aplikacji ma dwie fazy:

init — początkowe przygotowanie przed wdrożeniem, tutaj może być wszystko: pobieranie zależności, rozpakowywanie sekretów i inne.
generate — wykonanie bezpośrednio polecenia generowania manifestów, wynik powinien być ważnym strumieniem YAML, to właśnie zostanie zastosowane w klastrze.

Ciekawym jest to, że Argo stosuje to podejście do każdego typu aplikacji, w tym do Helm. To znaczy, że w Argo CD Helm nie zajmuje się wdrażaniem wersji w klastrze, a jest używany tylko do generowania manifestów.

Ze swojej strony Argo potrafi natywnie obsługiwać haki Helm, co pozwala nie naruszać logiki stosowania wersji.

QBEC

Qbec umożliwia wygodne opisanie aplikacji za pomocą jsonnet, a ponadto ma możliwość renderowania Helm chartów, a ponieważ Argo CD potrafi poprawnie obsługiwać haki Helm, wykorzystanie tej możliwości z Argo CD pozwala osiągnąć jeszcze bardziej precyzyjne wyniki.

Aby dodać wsparcie qbec w argocd, potrzebne są dwie rzeczy:

w konfiguracji Argo CD musi być zdefiniowany twój niestandardowy plugin oraz polecenia do generowania manifestów.
potrzebne binarki muszą być dostępne w obrazie argocd-repo-server.

Pierwsze zadanie rozwiązuje się dość prosto:

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

(polecenie init nie jest używane)

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

Aby dodać binarki, proponuje się zbudować nowy obraz, lub użyć sztuczki z init-kontenerem:

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

Teraz spójrzmy, jak będzie wyglądać manifest naszej aplikacji:

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

W zmiennej ŚRODOWISKO przekazujemy nazwę środowiska, dla którego należy generować manifesty.

zastosujemy i zobaczymy, co nam wyszło:

aplikacja została wdrożona, świetnie!

git-crypt

Git-crypt pozwala na skonfigurowanie przezroczystego szyfrowania repozytorium. To prosty i bezpieczny sposób przechowywania danych wrażliwych bezpośrednio w gicie.

Z wdrożeniem git-crypt okazało się trudniej.

Teoretycznie moglibyśmy wykonać git-crypt unlock na etapie init naszego niestandardowego wtyczki, ale to nie jest zbyt wygodne, ponieważ nie pozwalałoby na użycie natywnych metod wdrożenia. Na przykład w przypadku Helm i Jsonnet tracimy elastyczny interfejs GUI, który upraszcza konfigurację aplikacji (pliki values i inne).

Dlatego chciałbym przeprowadzić rozpakowanie repozytorium jeszcze na wcześniejszym etapie, podczas klonowania.

Tak jak w tej chwili Argo CD nie oferuje możliwości opisania jakichkolwiek haków do synchronizacji repozytorium, musiałem obejść to ograniczenie sprytnym skryptem powłoki, który zastępuje polecenie 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 wykonuje git fetch za każdym razem przed operacją wdrożenia. To na to polecenie przypniemy wykonanie git-crypt unlock aby odblokować repozytorium.

na testy możesz użyć mojego obrazu dockera w którym jest już wszystko, co potrzebne:

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

Teraz musimy pomyśleć o tym, jak Argo będzie deszyfrować nasze repozytoria. A mianowicie wygenerować klucz gpg dla niego:

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

Zapiszemy nazwę klucza 8CB8B24F50B4797D do dalszych kroków. Eksportujemy sam klucz:

$ 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

I dodamy go w formie osobnego sekretu:

# 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

Jedyną rzeczą, która nam pozostała, jest przekazanie go do kontenera argocd-repo-server, w tym celu edytujemy deployment:

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

I zastąpimy istniejący gpg-keys wolumenem na projected, gdzie wskażemy nasz sekret:

   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 automatycznie ładuje klucze gpg z tego katalogu podczas uruchamiania kontenera, w ten sposób załadował i nasz klucz prywatny.

sprawdźmy:

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

Świetnie, klucz załadowany! Teraz wystarczy, że dodamy Argo CD do naszego repozytorium jako współpracownika, a on będzie mógł automatycznie go odszyfrować w locie.

Importujemy klucz na lokalny komputer:

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

Ustawimy poziom zaufania:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Dodamy argo jako współpracownika do naszego projektu:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Linki w temacie:

Źródło: habr.com

Zagłębiamy się w Custom Tooling w Argo CD

QBEC

git-crypt