Crea un recurso GitRepo

Crea una instancia de GitRepo

Los repositorios Git se registran creando un recurso GitRepo en Kubernetes. Consulta el tutorial de creación de un despliegue para ejemplos.

Contenidos del Repositorio Git tiene detalles sobre el contenido del repositorio Git.

Los campos disponibles del recurso personalizado GitRepo están documentados en la referencia del recurso GitRepo Añadiendo un Repositorio Git Privado

SUSE® Rancher Prime Continuous Delivery no soporta la autenticación del servidor proxy SSH al clonar añadiendo-un-repositorio-git-privado o Usando Repositorios Helm Privados . Utiliza autenticación HTTPS con un nombre de usuario y contraseña o un token de acceso personal.

Espacio de Nombres Correcto

Los repositorios Git se añaden al gestor SUSE® Rancher Prime Continuous Delivery utilizando el tipo de recurso personalizado GitRepo. El tipo GitRepo está en un espacio de nombres. Por defecto, Rancher creará dos espacios de trabajo SUSE® Rancher Prime Continuous Delivery:

fleet-default contiene todos los clústeres en sentido descendente que ya están registrados a través de Rancher.
fleet-local contendrá el clúster local por defecto.

Si estás utilizando SUSE® Rancher Prime Continuous Delivery en un estilo de clúster único, el espacio de nombres siempre será fleet-local. Consulta registro de clúster para más información sobre el espacio de nombres fleet-local.

Para un estilo multi-clúster, asegúrate de utilizar el repositorio correcto que se mapeará a los clústeres de destino adecuados.

Sobrescribir el Espacio de Nombres de la Carga de Trabajo

El campo targetNamespace sobrescribirá cualquier espacio de nombres en el paquete. Si el despliegue contiene recursos de ámbito de clúster, fallará.

Toma precedencia sobre todas las demás definiciones de espacio de nombres:

gitRepo.targetNamespace > fleet.yaml namespace > namespace in workload’s manifest > fleet.yaml defaultNamespace

Las definiciones de espacio de nombres de carga de trabajo pueden ser restringidas con allowedTargetNamespaces en el recurso GitRepoRestriction.

Añadiendo un repositorio Git privado

SUSE® Rancher Prime Continuous Delivery admite los siguientes mecanismos de autenticación para repositorios privados: * Autenticación básica HTTP * Claves de autenticación SSH * Aplicaciones de Github

Para usar cualquiera de ellos, tienes que crear un secreto en el espacio de nombres de GitRepo.

Por ejemplo, para generar una clave SSH privada:

ssh-keygen -t rsa -b 4096 -m pem -C "user@email.com"

El formato de la clave privada tiene que estar en EC PRIVATE KEY, RSA PRIVATE KEY o PRIVATE KEY y no debe contener una frase de paso.

Pon tu clave privada en el secreto, usa el espacio de nombres en el que se encuentra el GitRepo:

kubectl create secret generic ssh-key -n namespace-of-your-gitrepo --from-file=ssh-privatekey=/file/to/private/key  --type=kubernetes.io/ssh-auth

Ahora el clientSecretName debe ser especificado en la definición del repositorio:

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: sample-ssh
  # This namespace is special and auto-wired to deploy to the local cluster
  namespace: fleet-local
spec:
  # Everything from this repo will be run in this cluster. You trust me right?
  repo: "git@github.com:rancher/fleet-examples"
  # or
  # repo: "ssh://git@github.com/rancher/fleet-examples"
  clientSecretName: ssh-key
  paths:
  - simple

No se admite clave privada con frase de paso.

La clave tiene que estar en formato PEM.

Hosts conocidos

SUSE® Rancher Prime Continuous Delivery admite poner known_hosts en el secreto SSH. Aquí hay un ejemplo de cómo añadirlo:

Obtén el hash de la clave pública (toma Github como ejemplo)

ssh-keyscan -H github.com

Y añádelo al secreto:

apiVersion: v1
kind: Secret
metadata:
  name: ssh-key
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: <private-key>
  known_hosts: |-
    |1|YJr1VZoi6dM0oE+zkM0do3Z04TQ=|7MclCn1fLROZG+BgR4m1r8TLwWc= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

Comprobaciones estrictas de claves de host

El valor del gráfico insecureSkipHostKeyChecks define cómo se comporta Fleet con respecto a known_hosts al establecer conexiones SSH.

Cuando ese valor se establece en false, Fleet aplicará comprobaciones estrictas de claves de host, lo que significa que fallará al establecer cualquier conexión SSH a hosts para los cuales no se puede encontrar una entrada known_hosts coincidente.

Este es el comportamiento predeterminado de Fleet a partir de la versión 0.13.

Las entradas known_hosts se obtienen prioritariamente de los secretos referenciados en los recursos GitRepo, por ejemplo, helmSecretName para acceder a gráficos de Helm o clientSecretName para clonar repositorios de git.

Tenga en cuenta que esto es compatible con Fleet buscando un secreto gitcredential si no se referencia ningún secreto en el GitRepo.

Si no existe tal secreto, o no hay entradas known_hosts disponibles en ese secreto, entonces Fleet utiliza su propio mapa de configuración known-hosts, creado recientemente en el momento de la instalación con entradas estáticas para los proveedores de git más utilizados.

Más detalles aquí sobre dónde provienen las entradas predeterminadas y cómo poblar entradas adicionales en el momento de la instalación.

La ausencia del mapa de configuración, si no hay secreto disponible, se considera un síntoma de un despliegue incompleto de Fleet, y se informa como tal.

Fleet solo utiliza una única fuente de entradas known_hosts a la vez. Esto significa que, incluso si un secreto contiene entradas inválidas (o insuficientes), entonces Fleet no buscará entradas válidas en el mapa de configuración. Esto se aplica a un secreto referenciado en un GitRepo así como a un posible secreto gitcredential, si no se referencia ningún secreto en el GitRepo.

Usando autenticación HTTP

Cree un secreto que contenga el nombre de usuario y la contraseña. Puede reemplazar la contraseña con un token de acceso personal si es necesario. También vea secretos HTTP en Github.

kubectl create secret generic basic-auth-secret -n namespace-of-your-gitrepo --type=kubernetes.io/basic-auth --from-literal=username=$user --from-literal=password=$pat

Al igual que con SSH, haga referencia al secreto en su recurso GitRepo a través de clientSecretName.

 spec:
   repo: https://github.com/fleetrepoci/gitjob-private.git
   branch: main
   clientSecretName: basic-auth-secret

Al usar BitBucket y tokens de acceso, el nombre de usuario debe ser x-token-auth.

Usando una aplicación de GitHub

Los siguientes campos son necesarios para habilitar SUSE® Rancher Prime Continuous Delivery para autenticar a GitHub usando una aplicación de GitHub:

Nombre Nombre del campo secreto Dónde encontrarlo

Nombre	Nombre del campo secreto	Dónde encontrarlo
ID de la aplicación	`github_app_id`	En la página de configuración de tu aplicación, bajo `App ID` (valor numérico).
ID de instalación de la aplicación	`github_app_installation_id`	En la URL de la página de instalación de la aplicación. Por ejemplo, si has instalado la aplicación en un repositorio `foo/bar`, navega a la configuración → Integraciones → Aplicaciones de ese repositorio, abre la página de la aplicación; su URL se verá como `https://github.com/settings/installations/<digits>;`: esos dígitos son tu ID de instalación de la aplicación.
clave privada	`github_app_private_key`	Generado al crear la aplicación de GitHub, o desde la página de configuración de la aplicación, donde hay un botón `Generate a private key` disponible.

ID de la aplicación

github_app_id

En la página de configuración de tu aplicación, bajo App ID (valor numérico).

ID de instalación de la aplicación

github_app_installation_id

En la URL de la página de instalación de la aplicación. Por ejemplo, si has instalado la aplicación en un repositorio foo/bar, navega a la configuración → Integraciones → Aplicaciones de ese repositorio, abre la página de la aplicación; su URL se verá como https://github.com/settings/installations/<digits>;: esos dígitos son tu ID de instalación de la aplicación.

clave privada

github_app_private_key

Generado al crear la aplicación de GitHub, o desde la página de configuración de la aplicación, donde hay un botón Generate a private key disponible.

Consulta la documentación de GitHub para más detalles sobre cómo crear una aplicación de GitHub.

Con los datos necesarios a mano, crea un secreto que contenga esos campos:

kubectl -n namespace-of-your-gitrepo create secret generic github-app-secret \
    --from-literal=github_app_id=<app-id> \
    --from-literal=github_app_installation_id=<installation-id> \
    --from-literal=github_app_private_key="<private-key>"

Usar un literal en lugar de un archivo para la clave privada puede ayudar a prevenir errores de decodificación PEM en el momento de la ejecución. Antes de crear el secreto, la clave privada puede obtenerse de un archivo que exporte la variable de entorno, para evitar que la clave misma aparezca en el historial de la shell.

Rodear el valor, o el nombre de la variable de entorno (por ejemplo, --from-literal=github_app_private_key="$MY_VAR") con comillas dobles asegura que se tenga en cuenta su contenido completo, incluidos posibles saltos de línea.

Asegúrate de hacer referencia a ese secreto en tu recurso GitRepo a través de clientSecretName.

Usando paquetes CA personalizados

Validar un repositorio utilizando un certificado firmado por una Autoridad Certificadora personalizada se puede hacer especificando un campo cabundle en un GitRepo.

Usando repositorios Helm privados

Las credenciales se utilizarán incondicionalmente para todos los repositorios Helm referenciados por el recurso GitRepo. Asegúrate de no filtrar credenciales mezclando repositorios públicos y privados. Usa credenciales Helm diferentes para cada vía, o divídelas en diferentes GitRepos, o usa helmRepoURLRegex para limitar el alcance de las credenciales a ciertos servidores.

Para un repositorio Helm privado, los usuarios pueden referenciar un secreto con las siguientes claves:

username y password para autenticación http básica si el repositorio HTTP de Helm está detrás de autenticación básica.
cacerts para un paquete CA personalizado si el repositorio de Helm está utilizando un CA personalizado.

ssh-privatekey para la clave privada SSH si el repositorio está utilizando el protocolo SSH. Actualmente no se admite la clave privada con frase de paso.

Por ejemplo, para añadir un secreto en kubectl, ejecuta

kubectl create secret -n $namespace generic helm --from-literal=username=foo --from-literal=password=bar --from-file=cacerts=/path/to/cacerts --from-file=ssh-privatekey=/path/to/privatekey.pem

Una vez creado el secreto, especifícalo en gitRepo.spec.helmSecretName. Asegúrate de que el secreto se crea en el mismo espacio de nombres que el GitRepo.

Utiliza diferentes credenciales de helm para cada vía

SUSE® Rancher Prime Continuous Delivery te permite definir credenciales únicas para cada vía de chart de Helm en un repositorio Git utilizando el campo helmSecretNameForPaths.

gitRepo.spec.helmSecretName será ignorado si se proporciona gitRepo.spec.helmSecretNameForPaths

Crea un archivo llamado secrets-path.yaml que especifique credenciales para cada vía en tu GitRepo. Cada clave puede ser ya sea:

una vía exacta, que debe coincidir con la vía completa a un directorio de paquetes (una carpeta que contiene un archivo fleet.yaml). La vía puede tener más segmentos que la entrada bajo paths:.
un glob que coincida con una o más vías, útil cuando las credenciales necesitan ser reutilizadas en múltiples vías/paquetes.

Consulta documentación de Go filepath.Match para ejemplos de la sintaxis admitida.

Si más de un glob coincide con una vía dada en un repositorio Git, SUSE® Rancher Prime Continuous Delivery ordenará los globs léxicamente y utilizará las credenciales de la primera coincidencia.

Ejemplo: Para la vía del repositorio world-domination/ui_charts y un secreto que contiene las siguientes claves, se utilizarán las credenciales bajo el glob segundo:

world-domination/*_charts: # will not be used
  username: fleet-ci
  password: foo
  insecureSkipVerify: true
world-domination/*: # will be used, as `/*` will be sorted before `/*_charts`
  username: fleet-ci
  password: foo
  insecureSkipVerify: true

Si una vía listada en el GitRepo no está incluida en este archivo, ya sea a través de vías exactas o coincidencias glob, SUSE® Rancher Prime Continuous Delivery no utiliza credenciales para ella.

El archivo debe llamarse secrets-path.yaml; de lo contrario, SUSE® Rancher Prime Continuous Delivery no podrá utilizarlo.

Recurso de ejemplo GitRepo

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: gitrepo
  namespace: fleet-local
spec:
  helmSecretNameForPaths: test-multipasswd
  repo: https://github.com/0xavi0/fleet-examples
  branch: helm-multi-passwd
  paths:
  - single-cluster/test-multipasswd

Ejemplo secrets-path.yaml

single-cluster/test-multipasswd/passwd:
  username: fleet-ci
  password: foo
  insecureSkipVerify: true

Otro ejemplo con dos vías distintas

path-one: # path path-one must exist in the repository
  username: user
  password: pass
path-two: # path path-two must exist in the repository
  username: user2
  password: pass2
  caBundle: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCiAgICBNSUlEblRDQ0FvV2dBd0lCQWdJVUNwMHB2...
  sshPrivateKey: ICAgIC0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQogICAgTUlJRFF6Q0NBaXNDRkgxTm5Y...

Campos soportados por vía:

Campo Descripción

Campo	Descripción
`username`	Nombre de usuario del registro o repositorio
`password`	Contraseña del registro o repositorio
`caBundle`	Paquete de certificados de la CA codificado en Base64
`sshPrivateKey`	Clave privada SSH codificada en Base64
`insecureSkipVerify`	Valor booleano para omitir la verificación TLS

username

Nombre de usuario del registro o repositorio

password

Contraseña del registro o repositorio

caBundle

Paquete de certificados de la CA codificado en Base64

sshPrivateKey

Clave privada SSH codificada en Base64

insecureSkipVerify

Valor booleano para omitir la verificación TLS

Para crear el secreto, ejecuta:

kubectl create secret generic test-multipasswd -n fleet-local --from-file=secrets-path.yaml

El secreto debe ser creado en el mismo espacio de nombres que el GitRepo recurso.

kubectl label secret path-auth-secret -n fleet-local resources.cattle.io/backup=true

Asegúrate de que la copia de seguridad esté cifrada para proteger credenciales sensibles.

Almacenando Credenciales en Git

Se recomienda no almacenar credenciales en Git. Incluso si el repositorio está debidamente protegido, los secretos están en riesgo durante la clonación, etc. Como solución alternativa, herramientas como SOPS pueden cifrar credenciales.

En su lugar, referencia secretos en el clúster de sentido descendente. Para paquetes de estilo manifiesto y estilo kustomize, haz esto en los manifiestos, por ejemplo, montando los secretos o referenciándolos como variables de entorno. Los paquetes de estilo Helm pueden usar valuesFrom para leer valores de un secreto en el clúster de sentido descendente.

Al utilizar Kubernetes encriptación en reposo y almacenar credenciales en Git, configura el clúster de sentido ascendente para incluir varios SUSE® Rancher Prime Continuous Delivery CRD en la lista de recursos de encriptación:

- secrets
- bundles.fleet.cattle.io
- bundledeployments.fleet.cattle.io
- contents.fleet.cattle.io

Realizando copias de seguridad y restauración

Al realizar copias de seguridad y restaurar SUSE® Rancher Prime Continuous Delivery con cargas de trabajo existentes, ya sean GitRepos o HelmOps, considera:

Disponibilidad del servidor API de Kubernetes

Un SUSE® Rancher Prime Continuous Delivery agente en un clúster de sentido descendente monitoriza un espacio de nombres específico del clúster en el clúster de sentido ascendente. Durante una operación de restauración, los cambios realizados en el clúster de sentido ascendente pueden afectar a las ampliaciones en los clústeres de sentido descendente, que podrían ser actualizadas o eliminadas en función de un estado incompleto del sentido ascendente.

Para prevenir esto, haz que el servidor API de Kubernetes sea inaccesible para los clústeres de sentido descendente mientras se está ejecutando una restauración. Los agentes no deben acceder al clúster de sentido ascendente hasta que todos los recursos sean recreados.

Pausando

Un pausado GitRepo pausará los paquetes y las ampliaciones de paquetes. Esto significa:

Eliminar una ampliación de paquete de un GitRepo pausado: SUSE® Rancher Prime Continuous Delivery no recreará la ampliación de paquete hasta que el GitRepo sea despausado.
Eliminar un paquete de un GitRepo pausado: SUSE® Rancher Prime Continuous Delivery eliminará las ampliaciones de paquetes provenientes de ese paquete, y no recreará el paquete (ni las ampliaciones de paquetes) hasta que el GitRepo sea despausado.

Pausar un GitRepo solo impide que se creen o actualicen paquetes y ampliaciones de paquetes. Solo afecta a las operaciones de controlador, no a las operaciones de SUSE® Rancher Prime Continuous Delivery agente. Para evitar que los recursos de usuario en un paquete sean eliminados al eliminar una ampliación de paquete, utiliza mantenerRecursos.

Solución de problemas

Consulta la SUSE® Rancher Prime Continuous Delivery sección de solución de problemas documentación de solución de problemas.