Kubernetes
Fare il provisioning di AnsibleForms da una ConfigMap e da dei Secret
Monta il seed da una ConfigMap e i suoi segreti da un Secret:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ansibleforms
spec:
# AF_ROLE unset : the web app and the worker in one pod. See the note below.
replicas: 1
strategy:
type: Recreate
selector:
matchLabels: { app: ansibleforms }
template:
metadata:
labels: { app: ansibleforms }
spec:
terminationGracePeriodSeconds: 120
containers:
- name: ansibleforms
image: ghcr.io/ansibleforms/ansibleforms:7
env:
- name: CONFIG_SEED_PATH
value: /seed/seed.yaml
# a ConfigMap edited in git is remounted here within about a minute and
# applied from there, so changing the seed does not roll the pod
- name: CONFIG_SEED_RELOAD_SECONDS
value: "60"
# the environment is declared here, so the settings pages must not
# write persistent/.env behind this manifest's back
- name: ALLOW_ENV_EDIT
value: "0"
envFrom:
- secretRef:
name: ansibleforms-seed-secrets # SEED_AWX_TOKEN, SEED_LDAP_PW, SEED_CHAT_API_KEY, ...
- secretRef:
name: ansibleforms-secrets # DB_PASSWORD, ENCRYPTION_SECRET, ...
volumeMounts:
- name: seed
mountPath: /seed
readOnly: true
- name: persistent
mountPath: /app/dist/persistent
livenessProbe:
# answers as long as the process runs, without asking the database
httpGet: { path: /api/v2/live, port: 8000 }
readinessProbe:
# 503 until the database answers and the schema is complete, and while stopping
httpGet: { path: /api/v2/ready, port: 8000 }
volumes:
- name: seed
configMap:
name: ansibleforms-seed
- name: persistent
persistentVolumeClaim:
claimName: ansibleforms-persistent
Un solo pod, con
AF_ROLEnon impostato. Questo pod esegue l’app web e il worker in un solo processo. Le pianificazioni, il backup notturno e il resto del lavoro in background girano solo nel processo che detiene il lock del worker nel database, il blocco del designer è una tabella del database, e i playbook girano su un RTE, non in questo pod. Mantieni comunquereplicas: 1con la strategiaRecreate: in un aggiornamento il nuovo pod attende che il worker applichi le patch allo schema, e il vecchio pod detiene il lock del worker finché non si ferma. Per eseguire più nodi web, suddividili in nodiAF_ROLE=appe un worker, come descrive Scalabilità.
ENCRYPTION_SECRET deve essere impostato prima di inserire qualsiasi credenziale. Una volta che le credenziali arrivano dal seed, il database è di fatto una cache, quindi ruotarlo significa riapplicare il seed invece di reinserire tutto a mano.
Le due probe non richiedono accesso. Sotto un BASE_URL i loro percorsi iniziano con esso, e Monitoraggio descrive cosa verifica ciascuna.