Kubernetes

Installeer AnsibleForms en de bijbehorende MySQL-database met de Helm-chart

  1. Vereisten
  2. 1. Haal de chartwaarden op
  3. 2. Configureer de opslag
  4. 3. Stel de inloggegevens in
  5. 4. Kies de RTE-image
  6. 5. Installeer de chart
  7. 6. Controleer de installatie
  8. 7. Open AnsibleForms
  9. 8. Meld je aan
  10. Een Runner op Kubernetes
  11. Volgende stappen

De Helm-chart deployt AnsibleForms met MySQL en de RTE die de playbooks uitvoert (zie de referentie van de values). Het installatieprogramma installeert de chart ook, op basis van een paar vragen, en upgradet een release die het niet zelf heeft geïnstalleerd. Dezelfde chart installeert ook een losse Runner, voor een AnsibleForms dat elders draait (zie Een Runner op Kubernetes).


Vereisten

Voordat je begint, heb je nodig:

  • Kubernetes-cluster : met kubectl zo geconfigureerd dat het het cluster bereikt
  • Helm 3 : om de chart te installeren en te upgraden
  • Opslag : een StorageClass voor dynamische provisioning, of vooraf aangemaakte PersistentVolumes
  • Ingress-controller : alleen als je AnsibleForms via een ingress wilt aanbieden

1. Haal de chartwaarden op

Haal de standaardwaarden van de chart op in een eigen bestand, uit de chartrepository of uit de OCI-registry:

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

2. Configureer de opslag

Zowel AnsibleForms als MySQL slaan hun gegevens op een persistent volume op. Stel voor elk de StorageClass en de grootte in:

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

Een lege className gebruikt de standaard-StorageClass van het cluster. De toegangsmodus is standaard ReadWriteMany, wat veel storage- klassen niet bieden; ReadWriteOnce is prima met één replica. Voor vooraf aangemaakte PersistentVolumes, zie de README van de chart.


3. Stel de inloggegevens in

AnsibleForms heeft een beheerdersaccount nodig, een databasewachtwoord en een ENCRYPTION_SECRET, de sleutel die de referenties versleutelt die in AnsibleForms zijn opgeslagen. Om die sleutel later te wijzigen, zet je ENCRYPTION_SECRET_PREVIOUS voor één start op de oude: elk opgeslagen secret wordt dan opnieuw versleuteld met de nieuwe sleutel. Lever ze op een van drie manieren aan:

Zet ze in my_values.yaml. De chart bewaart ze in een Secret met de naam <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. Kies de RTE-image

AnsibleForms 7 voert zelf geen playbook uit: dat doet de RTE (runtime-omgeving). De chart draait hem als tweede container in de serverpod, op hetzelfde volume, en registreert hem als de standaardrunner rte, zodat playbookformulieren zonder enige instelling werken. Sinds 7.3.0 belt de app hem aan op 127.0.0.1 en houdt één WebSocket open (RTE_MODE=inbound, zie Modi): de RTE krijgt geen database-instellingen en geen versleutelingssleutel. De config seed van de chart declareert een RTE-referentie met het token en dat adres, en de runner, modus inbound, die zich daarmee aanmeldt.

De standaardimage, ghcr.io/ansibleforms/ansibleforms-rte-full, bevat ansible met de bijbehorende collections en de Python-bibliotheken die de 6.5-image had. Wil je meer, of minder, bouw dan je eigen image op een van de drie RTE-lagen (ansibleforms-rte-base, -rte-core of -rte-full, zie De RTE-images) en laat de chart ernaar wijzen:

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

Het token tussen de app en de RTE, en de sleutel die de sessies ondertekent, worden bij de eerste installatie gegenereerd in de Secret <release>-keys en bij elke upgrade behouden. Met een eigen config seed voeg je die referentie en runner daaraan toe: de notes die Helm na de installatie toont laten zien hoe (zie de README van de chart).


5. Installeer de chart

Installeer de chart in een eigen namespace met je waarden:

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

Met de OCI-registry gebruik je oci://ghcr.io/ansibleforms/charts/ansibleforms als chart. In alles wat zonder toezicht draait, pin je de chartversie met --version, zodat er nooit vanzelf een nieuwe release wordt geïnstalleerd.


6. Controleer de installatie

De chart bevat een test die zowel de webserver als de databaseverbinding controleert:

helm test ansibleforms --namespace ansibleforms --logs

De test eindigt met OK als AnsibleForms antwoordt en de database verbindingen accepteert.


7. Open AnsibleForms

Hoe je AnsibleForms bereikt, hangt af van hoe de server wordt aangeboden:

Met de standaardservice ClusterIP en zonder ingress wordt niets buiten het cluster aangeboden. Forward een lokale poort om even te kijken:

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

Open daarna http://127.0.0.1:8080/.


8. Meld je aan

Meld je aan als de beheerder, standaard admin. Zo lees je het wachtwoord uit de Secret:

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

Met secrets.existingSecret lees je het in plaats daarvan uit je eigen Secret.


Een Runner op Kubernetes

Met runner.enabled installeert de chart alleen een RTE: een Runner voor een AnsibleForms dat elders is geïnstalleerd, in een andere namespace, een ander cluster of op een VM. Hij belt de app aan en houdt één WebSocket open (RTE_MODE=outbound, zie Modi), dus hij heeft geen database, geen versleutelingssleutel en geen inkomende poort nodig. Hij rendert geen app, geen MySQL, geen Service en geen 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_...
Waarde Wat het doet
runner.enabled Installeert alleen de Runner: geen app, geen MySQL, geen Service, geen Ingress
runner.appUrl Het adres van de app zoals mensen het openen, met de eventuele BASE_URL. Verplicht
runner.name De runnernaam waarmee hij aansluit (RTE_NAME). Leeg: de naam van de release
runner.joinToken Een jointoken gemaakt in de app, gelezen bij de eerste start om de Runner meteen goed te keuren
runner.appTlsVerify false accepteert het zelfondertekende certificaat van de app (APP_TLS_VERIFY=0), alleen binnen één vertrouwd netwerk

Zonder jointoken vraagt de Runner om aan te sluiten en wacht hij tot een beheerder hem goedkeurt onder Verbindingen > Runners. Eenmaal goedgekeurd meldt hij zich aan met zijn eigen RTE_TOKEN, bewaard in de Secret <release>-keys: bewaar die Secret samen met de release. Het installatieprogramma installeert deze runnermodus ook, als je de rol Runner en Kubernetes kiest.


Volgende stappen

De README van de chart behandelt de rest van de configuratie:

  • Je eigen database : zet mysql.enabled: false en laat AnsibleForms naar een bestaande MySQL-server wijzen
  • Formulieren uit ConfigMaps : lever config.yaml en de formulierbestanden aan via ConfigMaps
  • HTTPS achter een ingress, resources, plaatsing op nodes en private registries
  • De RTE : het token, een eigen RTE-image, of helemaal geen RTE

Om naar een nieuwere release te gaan, zie Upgraden op Kubernetes.