Kubernetes

Zainstaluj AnsibleForms i jego bazę danych MySQL za pomocą chartu Helm

  1. Wymagania wstępne
  2. 1. Pobranie wartości chartu
  3. 2. Konfiguracja pamięci masowej
  4. 3. Ustawienie poświadczeń
  5. 4. Wybór obrazu RTE
  6. 5. Instalacja chartu
  7. 6. Sprawdzenie instalacji
  8. 7. Otwarcie AnsibleForms
  9. 8. Logowanie
  10. Runner na Kubernetes
  11. Następne kroki

Chart Helm wdraża AnsibleForms z MySQL i RTE, które uruchamia playbooki (zobacz opis wartości). Instalator również instaluje chart, na podstawie kilku pytań, i aktualizuje wydanie, którego sam nie zainstalował. Ten sam chart instaluje też samodzielny Runner, dla AnsibleForms działającego gdzie indziej (zobacz Runner na Kubernetes).

Wymagania wstępne

Zanim zaczniesz, potrzebujesz:

  • Klastra Kubernetes : ze skonfigurowanym kubectl, który ma do niego dostęp
  • Helm 3 : do instalowania i aktualizowania chartu
  • Pamięci masowej : StorageClass do dynamicznego przydzielania lub wcześniej utworzonych PersistentVolumes
  • Kontrolera ingress : tylko jeśli chcesz udostępnić AnsibleForms przez ingress

1. Pobranie wartości chartu

Pobierz domyślne wartości chartu do własnego pliku, z repozytorium chartów lub z rejestru OCI:

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

2. Konfiguracja pamięci masowej

Zarówno AnsibleForms, jak i MySQL przechowują dane na wolumenie trwałym. Ustaw StorageClass i rozmiar każdego z nich:

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

Pusty className używa domyślnej StorageClass klastra. Tryb dostępu ma domyślnie wartość ReadWriteMany, której wiele klas pamięci masowej nie oferuje; ReadWriteOnce wystarcza przy jednej replice. W przypadku wcześniej utworzonych PersistentVolumes zobacz README chartu.

3. Ustawienie poświadczeń

AnsibleForms potrzebuje konta administratora, hasła do bazy danych i ENCRYPTION_SECRET, klucza, który szyfruje poświadczenia przechowywane w AnsibleForms. Aby później zmienić ten klucz, ustaw ENCRYPTION_SECRET_PREVIOUS na stary klucz na czas jednego uruchomienia: każdy zapisany sekret zostanie wtedy ponownie zaszyfrowany nowym kluczem. Podaj je na jeden z trzech sposobów:

Ustaw je w my_values.yaml. Chart przechowuje je w Secrecie o nazwie <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. Wybór obrazu RTE

AnsibleForms 7 sam nie uruchamia żadnego playbooka: robi to RTE (runtime environment). Chart uruchamia je jako drugi kontener w podzie serwera, na tym samym wolumenie, i rejestruje je jako domyślny runner rte, więc formularze playbooków działają bez żadnej konfiguracji. Od wersji 7.3.0 aplikacja łączy się z nim pod 127.0.0.1 i utrzymuje otwarty jeden WebSocket (RTE_MODE=inbound, zobacz Tryby): RTE nie dostaje ustawień bazy danych ani klucza szyfrowania. Config seed chartu deklaruje poświadczenie RTE z tokenem i tym adresem oraz runner, w trybie inbound, który się nim loguje.

Domyślny obraz, ghcr.io/ansibleforms/ansibleforms-rte-full, zawiera ansible z jego kolekcjami i biblioteki Pythona, które miał obraz 6.5. Jeśli potrzebujesz więcej lub mniej, zbuduj własny na jednej z trzech warstw RTE (ansibleforms-rte-base, -rte-core lub -rte-full, zobacz Obrazy RTE) i wskaż go chartowi:

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

Token między aplikacją a RTE oraz klucz podpisujący sesje są generowane przy pierwszej instalacji do Secretu <release>-keys i zachowywane przy każdej aktualizacji. Przy własnym config seed dodaj do niego to poświadczenie i runner: uwagi, które Helm wypisuje po instalacji, pokazują, jak to zrobić (zobacz README chartu).

5. Instalacja chartu

Zainstaluj chart we własnej przestrzeni nazw ze swoimi wartościami:

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

W przypadku rejestru OCI użyj oci://ghcr.io/ansibleforms/charts/ansibleforms jako chartu. We wszystkim, co działa bez nadzoru, przypnij wersję chartu przez --version, aby nowe wydanie nigdy nie zainstalowało się samo.

6. Sprawdzenie instalacji

Chart zawiera test, który sprawdza zarówno serwer webowy, jak i połączenie z bazą danych:

helm test ansibleforms --namespace ansibleforms --logs

Test kończy się wynikiem OK, gdy AnsibleForms odpowiada, a jego baza danych przyjmuje połączenia.

7. Otwarcie AnsibleForms

Sposób dostępu do AnsibleForms zależy od tego, jak udostępniony jest serwer:

Przy domyślnej usłudze ClusterIP i bez ingress nic nie jest udostępniane poza klastrem. Przekieruj lokalny port, aby się rozejrzeć:

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

Następnie otwórz http://127.0.0.1:8080/.

8. Logowanie

Zaloguj się jako użytkownik administrator, domyślnie admin. Aby odczytać hasło z Secretu:

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

Przy secrets.existingSecret odczytaj je zamiast tego z własnego Secretu.

Runner na Kubernetes

Przy runner.enabled chart instaluje tylko RTE: Runner dla AnsibleForms zainstalowanego gdzie indziej, w innej przestrzeni nazw, innym klastrze lub na maszynie wirtualnej. Łączy się on z aplikacją i utrzymuje otwarty jeden WebSocket (RTE_MODE=outbound, zobacz Tryby), więc nie potrzebuje bazy danych, klucza szyfrowania ani portu przychodzącego. Nie renderuje aplikacji, MySQL, Service ani 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_...
Wartość Co robi
runner.enabled Instaluje tylko Runner: bez aplikacji, MySQL, Service i Ingress
runner.appUrl Adres aplikacji, pod którym otwierają ją ludzie, z jej BASE_URL, jeśli jest. Wymagane
runner.name Nazwa runnera, pod którą dołącza (RTE_NAME). Puste: nazwa wydania
runner.joinToken Token dołączenia utworzony w aplikacji, odczytywany przy pierwszym uruchomieniu, aby od razu zatwierdzić Runner
runner.appTlsVerify false akceptuje certyfikat samopodpisany aplikacji (APP_TLS_VERIFY=0), tylko wewnątrz jednej zaufanej sieci

Bez tokenu dołączenia Runner prosi o dołączenie i czeka, aż administrator go zatwierdzi w Połączenia > Runnery. Po zatwierdzeniu loguje się własnym RTE_TOKEN, przechowywanym w Secrecie <release>-keys: zachowaj ten Secret razem z wydaniem. Instalator również instaluje ten tryb runnera, gdy wybierzesz rolę Runner i Kubernetes.

Następne kroki

README chartu opisuje resztę konfiguracji:

  • Własna baza danych : ustaw mysql.enabled: false i wskaż AnsibleForms istniejący serwer MySQL
  • Formularze z ConfigMap : dostarcz config.yaml i pliki formularzy przez ConfigMap
  • HTTPS za ingress, zasoby, rozmieszczenie na węzłach i prywatne rejestry
  • RTE : jego token, własny obraz RTE lub całkowity brak RTE

Aby przejść na nowsze wydanie, zobacz Aktualizacja na Kubernetes.