Job deploy (ansible)

C’est le job qui fait la transition entre le monde de l’infrastructure géré par Terraform et le monde de la configuration logicielle géré par Ansible.

🔍 Décryptage du job ansible-deploy (L’étape configure)

  ansible-deploy:
  stage: configure
  image: alpine:latest
  before_script:
    # On installe SSH et l'AWS CLI dans le runner GitLab
    - apk add --no-cache openssh-client aws-cli
    - mkdir -p ~/.ssh
    # On récupère la clé pour que le Runner puisse se connecter à l'instance Ansible
    - aws secretsmanager get-secret-value --secret-id ansible-ssh-key --region eu-central-1 --query SecretString --output text > ~/.ssh/id_rsa
    - chmod 400 ~/.ssh/id_rsa
  script:
    # On se connecte à l'instance Ansible et on lance le playbook
    - ssh -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa ubuntu@${ANSIBLE_SERVER_IP} "cd ~/ansible && ansible-playbook -i inventory.ini playbooks/wordpress.yml"
  only:
    - main

 

Voici exactement ce qui se passe point par point dans les coulisses de GitLab :

1. 🏎️ Phase de préparation (before_script)

Au lieu d’utiliser l’image Terraform, GitLab démarre ici un conteneur Alpine Linux (alpine:latest), un OS ultra-léger (quelques Mo) pour aller très vite.

apk add --no-cache openssh-client aws-cli

    : Le conteneur Alpine est initialement « vide ». GitLab y installe les deux seuls outils dont il a besoin : le client SSH (pour parler à ta VM) et l’AWS CLI (pour parler aux services AWS).

    La récupération du secret AWS : C’est la ligne la plus importante pour la sécurité :

    

 aws secretsmanager get-secret-value --secret-id ansible-ssh-key ... > ~/.ssh/id_rsa   

    Le conteneur utilise l’API AWS pour aller chercher la clé privée SSH générée par Terraform au job précédent et stockée dans le Secrets Manager. Il l’écrit directement dans son dossier temporaire ~/.ssh/id_rsa.

    chmod 400 : Linux interdit par sécurité d’utiliser une clé SSH privée si elle est lisible par d’autres utilisateurs. Cette commande restreint les droits au strict minimum (lecture seule pour le propriétaire).

2. 🚀 Le grand saut : L’exécution du script (script)

Le conteneur Docker de GitLab ouvre d’abord un tunnel SSH sécurisé vers l’IP publique de mon Ansible Control Node pour nettoyer les anciens répertoires.

Ensuite, il utilise la commande scp pour transférer tout le dossier de configuration et la clé SSH du dépôt GitLab vers la VM :

scp -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa -r ./ansible/* ubuntu@${ANSIBLE_BASTION_IP}:~/ansible/

            -o StrictHostKeyChecking=no : Cette option évite que le script ne s’arrête en demandant « Êtes-vous sûr de vouloir faire confiance à cette machine ? », ce qui ferait planter la CI/CD puisqu’il n’y a personne pour valider.

Une fois les fichiers copiés sur ma VM Ansible, le conteneur exécute une commande à distance pour installer automatiquement les outils manquants sur la VM ( Ubuntu, Ansible, et les collections AWS et Kubernetes).

Enfin, le playbook se lance. Mais au lieu de lire un fichier fixe inventory.ini, la VM utilise un inventaire dynamique (aws_ec2) : elle scanne mon compte AWS en direct, trouve la VM WordPress privée grâce à ses tags, et lance la configuration de K3s.

Retour en haut