Comprensión de las herramientas personalizadas en Argo CD

Comprensión de las herramientas personalizadas en Argo CD

Algún tiempo después de escribir primer artículo, donde administré hábilmente jsonnet y gitlab, me di cuenta de que las canalizaciones son ciertamente buenas, pero innecesariamente complicadas e inconvenientes.

En la mayoría de los casos, se requiere una tarea típica: "generar YAML y ponerlo en Kubernetes". En realidad, esto es lo que el Argo CD hace extraordinariamente bien.

Argo CD te permite conectar un repositorio Git y enviar su estado a Kubernetes. De forma predeterminada, hay soporte para varios tipos de aplicaciones: Kustomize, Helm charts, Ksonnet, Jsonnet simple o simplemente directorios con manifiestos YAML/JSON.

Este conjunto será suficiente para la mayoría de los usuarios, pero no para todos. Para satisfacer las necesidades de todos, Argo CD tiene la capacidad de utilizar herramientas personalizadas.

Primero que nada, me interesa la posibilidad de agregar soporte. qbec и git-cripta, que fueron discutidos en detalle en el artículo anterior.

Antes de comenzar la configuración, primero debe comprender exactamente cómo funciona Argo CD.

Para cada aplicación agregada, tiene dos fases:

  • init — preparación inicial antes de la implementación, aquí puede pasar cualquier cosa: descargar dependencias, descomprimir secretos y más.
  • generar — Al ejecutar directamente el comando de generación de manifiesto, la salida debe ser una secuencia YAML válida, esto es exactamente lo que se aplicará al clúster.

Lo destacable es que Argo aplica este enfoque a cualquier tipo de aplicación, incluido Helm. Es decir, en Argo CD Helm no implementa versiones en el clúster, sino que se utiliza únicamente para generar manifiestos.

Por su parte, Argo puede procesar ganchos Helm de forma nativa, lo que le permite no violar la lógica de aplicación de versiones.

QBEC

Qbec le permite describir aplicaciones cómodamente utilizando jsonnet y, además, tiene la capacidad de representar gráficos de Helm y, dado que Argo CD normalmente puede procesar ganchos de Helm, el uso de esta función con Argo CD le permite lograr resultados aún más correctos.

Para agregar soporte qbec a argocd necesita dos cosas:

  • En la configuración del CD de Argo, se deben definir su complemento personalizado y los comandos para generar manifiestos.
  • Los binarios necesarios deben estar disponibles en la imagen. servidor-repo-argocd.

Primera tarea está decidido bastante simple:

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

(equipo init no utilizado)

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

Para agregar binarios se sugiere recoger una nueva imagen, o usar truco del contenedor inicial:

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

Ahora veamos cómo se verá el manifiesto de nuestra aplicación:

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 una variable MEDIO AMBIENTE Pasamos el nombre del entorno para el cual necesitamos generar manifiestos.

apliquémoslo y veamos qué obtenemos:

Comprensión de las herramientas personalizadas en Argo CD

La aplicación ha sido implementada, ¡genial!

git-cripta

Git-crypt le permite configurar un cifrado transparente para su repositorio. Es una forma sencilla y segura de almacenar datos confidenciales directamente en git.

La implementación de git-crypt resultó ser más complicada.

Teóricamente podríamos hacer git-crypt unlock en la etapa de inicio de nuestro complemento personalizado, pero esto no es muy conveniente, ya que no permitiría el uso de métodos de implementación nativos. Por ejemplo, en el caso de Helm y Jsonnet, perdemos una interfaz GUI flexible que nos permite simplificar la configuración de la aplicación (archivos de valores, etc.).

Por eso quería imprimir el repositorio en una etapa anterior, durante la clonación.

Dado que por el momento Argo CD no ofrece la posibilidad de describir ningún gancho para sincronizar el repositorio, tuvimos que sortear esta limitación con un complicado script de shell que reemplaza el comando 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 actúa git fetch cada vez antes de la operación de implementación. Es este comando al que le asignaremos ejecución. git-crypt unlock para desbloquear el repositorio.

para pruebas puedes usar mi imagen acoplable que ya tiene todo lo que necesitas:

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

Ahora debemos pensar en cómo Argo descifrará nuestros repositorios. Es decir, genere una clave gpg para ello:

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

Guardemos el nombre de la clave. 8CB8B24F50B4797D para pasos adicionales. Exporte la clave en sí:

$ 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

Y agréguelo como un secreto separado:

# 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

Ya sólo nos queda tirarlo al contenedor. servidor-repo-argocd, para hacer esto, edite la implementación:

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

Y reemplazaremos el existente. teclas-gpg volumen encendido projected, donde indicamos nuestro secreto:

   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 carga automáticamente las claves gpg de este directorio cuando se inicia el contenedor, por lo que también cargará nuestra clave privada.

vamos a revisar:

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

¡Genial, la llave está cargada! Ahora sólo necesitamos agregar Argo CD a nuestro repositorio como colaborador y podrá descifrarlo automáticamente sobre la marcha.

Importe la clave a la computadora local:

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

Establezcamos el nivel de confianza:

$ gpg --edit-key 8CB8B24F50B4797D
trust
5

Agreguemos argo como colaborador a nuestro proyecto:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

Ссылки по теме:

Fuente: habr.com

Compre alojamiento confiable para sitios con protección DDoS, servidores VPS VDS 🔥 Compra alojamiento web fiable con protección DDoS, servidores VPS VDS | ProHoster