Automation

Installer AWX est simple. L'exploiter proprement l'est moins.

Note d’exploitation orientée production autour d’AWX avec l’operator, incluant namespace, persistance, exposition, execution environments, validation, sauvegarde et défauts qui apparaissent après le premier login.

20 avr. 2026 awxansiblekubernetesautomationoperator

Un premier login AWX ne prouve pas que la plateforme est prête pour un usage réel. Les installations fragiles échouent plus tard, quand il faut gérer la persistance des projets, des execution environments propres, une exposition réseau maîtrisée, une stratégie de sauvegarde et des upgrades prévisibles.

Cet article part d’AWX Operator sur Kubernetes et garde volontairement un périmètre limité. Le but n’est pas de lister tous les champs du custom resource. Le but est de déployer une instance AWX capable de tenir face aux premières vraies questions d’exploitation.

Ce que cet article suppose

Les exemples ci dessous partent d’un cluster Kubernetes déjà en place, de storage classes fonctionnelles, d’une gestion TLS réalisée par la couche ingress ou par ta stratégie de reverse proxy, et d’administrateurs qui préfèrent des versions figées à des commandes flottantes.

Le design de référence reste volontairement simple.

Un namespace dédié à AWX
L’operator installé dans ce namespace
Une exposition via ingress plutôt qu’un LoadBalancer brut vers Internet
La persistance des projets activée, car beaucoup d’équipes dépendent encore de la synchronisation de projets et de contenu local
Des execution environments préparés tôt, plutôt que d’accepter une dérive de dépendances plus tard
Des objets de sauvegarde et de restauration testés avant de considérer la plateforme comme exploitable

Figer la version de l’operator avant toute installation

Il ne faut pas utiliser une cible mouvante. Fige la version de l’operator validée dans ton lab ou en préproduction.

bash 00-variables.sh

export AWX_NAMESPACE=awx
export AWX_NAME=awx-prod
export AWX_OPERATOR_VERSION=2.19.1

Commence par créer le namespace.

bash 01-namespace.sh

kubectl create namespace ${AWX_NAMESPACE}

Installe ensuite l’operator à partir d’une release figée.

bash 02-install-operator.sh

kubectl apply -n ${AWX_NAMESPACE} -f https://github.com/ansible/awx-operator/releases/download/${AWX_OPERATOR_VERSION}/awx-operator.yaml

Vérifie que l’operator est réellement opérationnel avant de créer le custom resource AWX.

bash 03-check-operator.sh

kubectl get pods -n ${AWX_NAMESPACE}
kubectl get deployments -n ${AWX_NAMESPACE}
kubectl logs deployment/awx-operator-controller-manager -n ${AWX_NAMESPACE}

Si cette validation est sautée, tu ne gagnes que du bruit dans les logs et les événements. Il faut partir d’un operator sain.

Créer un custom resource AWX qui reflète un vrai choix de plateforme

Beaucoup de démos utilisent la ressource la plus courte possible et acceptent les valeurs par défaut. C’est souvent là que commencent les problèmes d’exploitation.

Cet exemple garde le service privé dans le cluster, active la persistance des projets, pose un nom d’hôte explicite et évite de faire comme si l’image d’exécution par défaut suffisait durablement.

yaml awx-prod.yaml

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx-prod
namespace: awx
spec:
service_type: ClusterIP
ingress_type: ingress
hostname: awx.naxaya.internal

projects_persistence: true
projects_storage_access_mode: ReadWriteOnce
projects_storage_size: 20Gi

admin_user: admin

web_resource_requirements:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: 1
    memory: 2Gi

task_resource_requirements:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: 2
    memory: 4Gi

Applique la ressource.

bash 04-apply-awx.sh

kubectl apply -f awx-prod.yaml

Puis surveille le déploiement au lieu de supposer qu’il se stabilisera correctement.

bash 05-watch-awx.sh

kubectl get awx -n ${AWX_NAMESPACE}
kubectl get pods -n ${AWX_NAMESPACE} -w

Une validation réaliste n’est pas seulement “les pods sont Running”. Il faut que les composants web, task, migration, Redis et PostgreSQL convergent sans redémarrages répétés.

Récupérer le mot de passe admin et confirmer l’état de l’objet

La procédure d’installation de base est utile, mais elle doit être traitée comme un point de contrôle, pas comme un état final.

bash 06-admin-password.sh

kubectl get secret ${AWX_NAME}-admin-password -n ${AWX_NAMESPACE} -o jsonpath='{.data.password}' | base64 --decode && echo

Récupère aussi l’état détaillé de l’objet.

bash 07-awx-status.sh

kubectl describe awx ${AWX_NAME} -n ${AWX_NAMESPACE}
kubectl get svc -n ${AWX_NAMESPACE}
kubectl get ingress -n ${AWX_NAMESPACE}

Si le mot de passe fonctionne mais que l’état reste instable, l’installation n’est pas terminée. Le premier login n’est que le début de la validation.

Dans beaucoup d’environnements internes, ClusterIP derrière un ingress maîtrisé est plus propre qu’un LoadBalancer public exposé directement. Cela garde la frontière réseau explicite et permet d’aligner AWX avec le modèle TLS, reverse proxy et contrôle d’accès déjà en place.

Au minimum, il faut valider ces points.

bash 08-ingress-checks.sh

kubectl get ingress -n ${AWX_NAMESPACE}
kubectl describe ingress ${AWX_NAME}-ingress -n ${AWX_NAMESPACE}
curl -Ik https://awx.naxaya.internal

Si l’ingress termine le TLS, vérifie que le certificat présenté correspond bien au nom choisi et que le comportement websocket n’est pas cassé par une politique proxy intermédiaire.

La persistance des projets n’est pas optionnelle si le modèle d’exploitation s’appuie encore dessus

Beaucoup d’installations AWX restent “correctes” tant qu’elles servent de démo. Dès que les équipes attendent du contenu local, des synchronisations de projets ou des données qui doivent survivre aux redémarrages de pods, l’absence de stockage devient visible.

Inspecte les PVC créées.

bash 09-storage-checks.sh

kubectl get pvc -n ${AWX_NAMESPACE}
kubectl describe pvc -n ${AWX_NAMESPACE}

Si le cluster a un comportement de stockage fragile ou des reclaim policies mal comprises, AWX le rendra vite visible. C’est précisément pour cela qu’un login réussi est un mauvais indicateur de succès.

Les execution environments doivent être voulus, pas subis

Beaucoup d’équipes repoussent ce sujet et laissent la dérive de dépendances s’installer. Cela fonctionne pendant quelque temps, puis chaque job template devient une loterie de dépendances.

Il vaut mieux construire et publier une image d’exécution testée.

yaml execution-environment.yml

version: 3
images:
base_image:
  name: quay.io/ansible/awx-ee:latest

dependencies:
galaxy: requirements.yml
python: requirements.txt
system: bindep.txt

Puis construire cette image avec ansible-builder.

bash 10-build-ee.sh

ansible-builder build --tag registry.internal.example.com/ee/netops:1.0.0

Ensuite il faut pousser l’image et l’enregistrer dans AWX comme execution environment. Il ne faut pas attendre qu’un job en échec révèle qu’un template attend pywinrm, qu’un autre dépend d’un SDK cloud, et qu’un troisième réclame un paquet système jamais documenté.

Le design des organisations et credentials doit être visible dès le départ

Une installation propre d’AWX implique aussi un modèle d’autorisations propre.

Crée au minimum une organisation, une équipe et un ensemble borné de credentials, au lieu de laisser tout le modèle reposer sur le compte admin initial.

L’API AWX est utile pour valider rapidement cette discipline.

bash 11-api-health.sh

curl -sk -u admin:'<admin-password>' https://awx.naxaya.internal/api/v2/ping/

curl -sk -u admin:'<admin-password>' https://awx.naxaya.internal/api/v2/config/

Ces appels sont simples, mais ils confirment que l’API applicative répond, que l’authentification fonctionne et que la plateforme est joignable par le même chemin que celui utilisé ensuite par les équipes et l’automatisation.

Les sauvegardes font partie de la qualité d’installation, pas d’un projet futur

L’operator fournit des objets de sauvegarde et de restauration. C’est important, car une plateforme n’est pas crédible en exploitation tant que l’on ne sait pas ce qui peut être restauré et sous quelles contraintes.

Un objet de sauvegarde minimal peut ressembler à ceci.

yaml awx-backup.yaml

apiVersion: awx.ansible.com/v1beta1
kind: AWXBackup
metadata:
name: awx-prod-backup
namespace: awx
spec:
deployment_name: awx-prod

Applique le fichier puis contrôle le résultat.

bash 12-run-backup.sh

kubectl apply -f awx-backup.yaml
kubectl get awxbackup -n ${AWX_NAMESPACE}
kubectl describe awxbackup awx-prod-backup -n ${AWX_NAMESPACE}

Le point important n’est pas seulement de pouvoir créer un objet de backup. Il faut aussi savoir où la donnée est stockée, quels secrets et paramètres sont inclus, et quelles hypothèses de namespace doivent être respectées lors d’une restauration.

Un objet de restauration simple peut ressembler à ceci.

yaml awx-restore.yaml

apiVersion: awx.ansible.com/v1beta1
kind: AWXRestore
metadata:
name: awx-prod-restore
namespace: awx
spec:
deployment_name: awx-prod-restored
backup_name: awx-prod-backup

Il n’est pas nécessaire de lancer une restauration à chaque déploiement, mais il faut prouver le processus hors production avant de considérer la plateforme comme fiable.

Les contrôles post installation qui méritent vraiment d’être conservés

Une bonne séquence de validation après installation peut ressembler à ceci.

bash 13-post-install-checks.sh

kubectl get awx -n ${AWX_NAMESPACE}
kubectl get pods -n ${AWX_NAMESPACE}
kubectl get pvc -n ${AWX_NAMESPACE}
kubectl get ingress -n ${AWX_NAMESPACE}
kubectl logs deployment/awx-operator-controller-manager -n ${AWX_NAMESPACE} --tail=200
curl -sk https://awx.naxaya.internal/api/v2/ping/
curl -sk -u admin:'<admin-password>' https://awx.naxaya.internal/api/v2/me/

Il faut garder ces contrôles près de la procédure de déploiement. Ils ont plus de valeur que des captures d’écran.

Ce qui casse le plus souvent après une installation apparemment réussie

Les défauts récurrents sont prévisibles.

La synchronisation des projets fonctionne jusqu’au moment où la storage class se comporte mal sous redémarrage.

Les job templates tournent jusqu’à ce que différentes équipes dépendent silencieusement de paquets Python, de SDK ou de binaires système différents parce que les execution environments n’ont jamais été pensés proprement.

L’ingress fonctionne pour le login, mais casse certains comportements applicatifs parce que le proxy, le TLS ou la gestion des websockets n’ont jamais été validés de bout en bout.

La plateforme survit à quelques redémarrages de pods, mais pas à un vrai incident parce que sauvegarde et restauration ont été traitées comme un sujet pour plus tard.

Les autorisations dérivent parce que le compte admin initial est resté trop longtemps au centre du modèle d’exploitation.

Aucun de ces problèmes ne se corrige en réinstallant AWX. Ils se corrigent en décidant tôt quel type de plateforme doit être construit.

Les décisions à prendre avant d’élargir l’usage

Il faut décider si AWX ne sert qu’à une petite équipe interne ou s’il devient un service partagé.

S’il devient un service partagé, il faut figer les versions, maîtriser l’exposition réseau, définir la fréquence de sauvegarde, standardiser les execution environments, séparer les organisations et credentials, et documenter la séquence de validation attendue après chaque changement d’operator ou de plateforme.

C’est cette frontière qui sépare une démo qui fonctionne par chance d’une plateforme d’automatisation sur laquelle on peut réellement s’appuyer.