Kubernetes

Instala AnsibleForms y su base de datos MySQL con el chart de Helm

  1. Requisitos previos
  2. 1. Obtén los valores del chart
  3. 2. Configura el almacenamiento
  4. 3. Define las credenciales
  5. 4. Elige la imagen del RTE
  6. 5. Instala el chart
  7. 6. Comprueba la instalación
  8. 7. Abre AnsibleForms
  9. 8. Inicia sesión
  10. Un Runner en Kubernetes
  11. Siguientes pasos

El chart de Helm despliega AnsibleForms con MySQL y el RTE que ejecuta los playbooks (consulta la referencia de valores). El instalador también instala el chart a partir de unas pocas preguntas, y actualiza una release que no instaló él. El mismo chart instala también un Runner por sí solo, para un AnsibleForms que se ejecuta en otro sitio (consulta Un Runner en Kubernetes).

Requisitos previos

Antes de empezar, necesitas:

  • Clúster de Kubernetes : con kubectl configurado para acceder a él
  • Helm 3 : para instalar y actualizar el chart
  • Almacenamiento : una StorageClass con aprovisionamiento dinámico, o PersistentVolumes creados de antemano
  • Controlador de ingress : solo si quieres exponer AnsibleForms a través de un ingress

1. Obtén los valores del chart

Descarga los valores predeterminados del chart a un archivo propio, desde el repositorio de charts o desde el registro OCI:

helm repo add ansibleforms https://ansibleforms.com/helm-charts/
helm repo update
helm show values ansibleforms/ansibleforms > my_values.yaml

2. Configura el almacenamiento

Tanto AnsibleForms como MySQL guardan sus datos en un volumen persistente. Indica la StorageClass y el tamaño de cada uno:

storages:
  server:
    className: longhorn
    size: 5Gi
    accessMode: ReadWriteOnce
  mysql:
    className: longhorn
    size: 5Gi
    accessMode: ReadWriteOnce

Un className vacío usa la StorageClass predeterminada del clúster. El modo de acceso es ReadWriteMany de forma predeterminada, y muchas clases de almacenamiento no lo ofrecen; ReadWriteOnce basta con una sola réplica. Para PersistentVolumes creados de antemano, consulta el README del chart.

3. Define las credenciales

AnsibleForms necesita una cuenta de administrador, una contraseña de base de datos y un ENCRYPTION_SECRET, la clave que cifra las credenciales guardadas en AnsibleForms. Para cambiar esa clave más adelante, pon la antigua en ENCRYPTION_SECRET_PREVIOUS durante un arranque: todos los secretos guardados se vuelven a cifrar con la clave nueva. Puedes proporcionarlos de tres maneras:

Defínelas en my_values.yaml. El chart las guarda en un Secret llamado <release>-secrets:

applications:
  server:
    env:
      ADMIN_USERNAME: admin
      ADMIN_PASSWORD: a-strong-password
      ENCRYPTION_SECRET: a-random-string-of-32-characters
  mysql:
    password: a-strong-database-password

4. Elige la imagen del RTE

AnsibleForms 7 no ejecuta ningún playbook por sí mismo: lo hace el RTE (entorno de ejecución). El chart lo ejecuta como un segundo contenedor en el pod del servidor, sobre el mismo volumen, y lo registra como el runner predeterminado rte, así que los formularios de playbook funcionan sin configurar nada. Desde la 7.3.0, la aplicación lo llama en 127.0.0.1 y mantiene abierto un WebSocket (RTE_MODE=inbound, consulta Modos): el RTE no recibe ajustes de base de datos ni clave de cifrado. La semilla de configuración del chart declara una credencial de RTE con el token y esa dirección, y el runner, en modo inbound, que inicia sesión con ella.

La imagen predeterminada, ghcr.io/ansibleforms/ansibleforms-rte-full, contiene ansible con sus colecciones y las bibliotecas de Python que tenía la imagen 6.5. Para más, o para menos, construye la tuya sobre una de las tres capas del RTE (ansibleforms-rte-base, -rte-core o -rte-full, consulta Las imágenes del RTE) y apunta el chart a ella:

containers:
  rte:
    image: registry.example.com/my-rte:7.0.0
applications:
  rte:
    env:
      ANSIBLE_PATH: /app/dist/persistent/playbooks

El token entre la aplicación y el RTE, y la clave que firma las sesiones, se generan en la primera instalación en el Secret <release>-keys y se conservan en cada actualización. Con una semilla de configuración propia, añade a ella esa credencial y ese runner: las notas que Helm muestra tras la instalación indican cómo (consulta el README del chart).

5. Instala el chart

Instala el chart en su propio namespace con tus valores:

helm upgrade --install ansibleforms ansibleforms/ansibleforms \
  --namespace ansibleforms --create-namespace \
  --values my_values.yaml

Con el registro OCI, usa oci://ghcr.io/ansibleforms/charts/ansibleforms como chart. En todo lo que se ejecute de forma desatendida, fija la versión del chart con --version, para que nunca se instale una nueva release por su cuenta.

6. Comprueba la instalación

El chart incluye una prueba que comprueba tanto el servidor web como la conexión con la base de datos:

helm test ansibleforms --namespace ansibleforms --logs

La prueba termina con OK cuando AnsibleForms responde y su base de datos acepta conexiones.

7. Abre AnsibleForms

Cómo llegas a AnsibleForms depende de cómo esté expuesto el servidor:

Con el servicio ClusterIP predeterminado y sin ingress, no hay nada expuesto fuera del clúster. Redirige un puerto local para echar un vistazo:

kubectl -n ansibleforms port-forward svc/ansibleforms-server 8080:80

Después abre http://127.0.0.1:8080/.

8. Inicia sesión

Inicia sesión como el usuario administrador, admin de forma predeterminada. Para leer la contraseña del Secret:

kubectl -n ansibleforms get secret ansibleforms-secrets \
  -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d

Con secrets.existingSecret, léela de tu propio Secret.

Un Runner en Kubernetes

Con runner.enabled, el chart instala solo un RTE: un Runner para un AnsibleForms instalado en otro sitio, en otro namespace, otro clúster o en una VM. Llama a la aplicación y mantiene abierto un WebSocket (RTE_MODE=outbound, consulta Modos), así que no necesita base de datos, ni clave de cifrado, ni puerto de entrada. No renderiza ni aplicación, ni MySQL, ni Service, ni Ingress:

helm install runner1 ansibleforms/ansibleforms \
  --namespace runners --create-namespace \
  --set runner.enabled=true \
  --set runner.appUrl=https://forms.example.com \
  --set runner.name=zone-a \
  --set runner.joinToken=afj_...
Valor Qué hace
runner.enabled Instala solo el Runner: sin aplicación, sin MySQL, sin Service, sin Ingress
runner.appUrl La dirección de la aplicación tal como la abren los usuarios, con su BASE_URL si lo hay. Obligatorio
runner.name El nombre de runner con el que se une (RTE_NAME). Vacío: el nombre de la release
runner.joinToken Un token de unión creado en la aplicación, que se lee en el primer arranque para aprobar el Runner al momento
runner.appTlsVerify false acepta el certificado autofirmado de la aplicación (APP_TLS_VERIFY=0), solo dentro de una red de confianza

Sin token de unión, el Runner pide unirse y espera a que un administrador lo apruebe en Conexiones > Runners. Una vez aprobado, inicia sesión con su propio RTE_TOKEN, guardado en el Secret <release>-keys: conserva ese Secret junto con la release. El instalador también instala este modo runner, cuando eliges el rol Runner y Kubernetes.

Siguientes pasos

El README del chart cubre el resto de la configuración:

  • Tu propia base de datos : pon mysql.enabled: false y apunta AnsibleForms a un servidor MySQL existente
  • Formularios desde ConfigMaps : proporciona config.yaml y los archivos de formulario mediante ConfigMaps
  • HTTPS detrás de un ingress, recursos, ubicación en nodos y registros privados
  • El RTE : su token, una imagen de RTE propia, o ningún RTE

Para pasar a una release más reciente, consulta Actualizar en Kubernetes.