TP4 - Orchestration, Serveur de contrôle et Cloud

Cloner le projet modèle

  • Pour simplifier le démarrage, clonez le dépôt de base à l’adresse https://github.com/e-lie/ansible_tp_corrections.
  • Renommez le clone en tp4.
  • ouvrez le projet avec VSCode.
  • Activez la branche tp4_correction avec git checkout tp4_correction.

Facultatif: Infrastructure dans le cloud avec Terraform et Ansible

Facultatif :

Infrastructure multi-tiers avec load balancer

Pour configurer notre infrastructure:

  • Installez les roles avec ansible-galaxy install -r roles/requirements.yml -p roles.

  • Si vous n’avez pas fait la partie Terraform:

    • complétez l’inventaire statique (inventory.cfg)
    • changer dans ansible.cfg l’inventaire en ./inventory.cfg comme pour les TP précédents
    • Supprimez les conteneurs app1 et app2 du TP précédent puis lancez le playbook de provisionning lxd : sudo ansible-playbook provisionner/provision_lxd_infra.yml
  • Lancez le playbook global site.yml

  • Utilisez la commande ansible-inventory --graph pour afficher l’arbre des groupes et machines de votre inventaire

  • Utilisez la de même pour récupérer l’ip du balancer0 (ou balancer1) avec : ansible-inventory --host=balancer0

  • Ajoutez hello.test et hello2.test dans /etc/hosts pointant vers l’ip de balancer0.

  • Chargez les pages hello.test et hello2.test.

  • Observons ensemble l’organisation du code Ansible de notre projet.

    • Nous avons rajouté à notre infrastructure un loadbalancer installé à l’aide du fichier balancers.yml
    • Le playbook upgrade_apps.yml permet de mettre à jour l’application en respectant sa haute disponibilité. Il s’agit d’une opération d’orchestration simple en les 3 serveurs de notre infrastructure.
    • Cette opération utilise en particulier serial qui permet de d’exécuter séquentiellement un play sur un fraction des serveurs d’un groupe (ici 1 à la fois parmis les 2).
    • Notez également l’usage de delegate qui permet d’exécuter une tache sur une autre machine que le groupe initialement ciblé. Cette directive est au coeur des possibilités d’orchestration Ansible en ce qu’elle permet de contacter un autre serveur ( déplacement latéral et non pas master -> node ) pour récupérer son état ou effectuer une modification avant de continuer l’exécution et donc de coordonner des opérations.
    • notez également le playbook exclude_backend.yml qui permet de sortir un backend applicatif du pool. Il s’utilise avec des variables en ligne de commande
  • Désactivez le noeud qui vient de vous servir la page en utilisant le playbook exclude_backend.yml:

ansible-playbook --extra-vars="backend_name=<noeud a desactiver> backend_state=disabled" playbooks/exclude_backend.yml
  • Rechargez la page: vous constatez que c’est l’autre backend qui a pris le relais.

  • Nous allons maintenant mettre à jour

Falcultatif : ajoutons un serveur de control AWX (/ Ansible Tower)

Facultatif :

Explorer AWX

  • Identifiez vous sur awx avec le login admin et le mot de passe précédemment configuré.

  • Dans la section modèle de projet, importez votre projet. Un job d’import se lance. Si vous avez mis le fichier requirements.yml dans roles les roles devraient être automatiquement installés.

  • Dans la section crédentials, créez un crédential de type machine. Dans la section clé privée copiez le contenu du fichier ~/.ssh/id_ssh_tp que nous avons configuré comme clé ssh de nos machines. Ajoutez également la passphrase que vous avez configuré au moment de la création de cette clé.

  • Créez une ressource inventaire. Créez simplement l’inventaire avec un nom au départ. Une fois créé vous pouvez aller dans la section source et choisir de l’importer depuis le projet, sélectionnez inventory.cfg que nous avons configuré précédemment. Bien que nous utilisions AWX les ip n’ont pas changé car AWX est en local et peut donc se connecter au reste de notre infrastructure LXD.

  • Pour tester tout cela vous pouvez lancez une tâche ad-hoc ping depuis la section inventaire en sélectionnant une machine et en cliquant sur le bouton executer.

  • Allez dans la section modèle de job et créez un job en sélectionnant le playbook site.yml.

  • Exécutez ensuite le job en cliquant sur la fusée. Vous vous retrouvez sur la page de job de AWX. La sortie ressemble à celle de la commande mais vous pouvez en plus explorer les taches exécutées en cliquant dessus.

  • Modifiez votre job, dans la section Plannifier configurer l’exécution du playbook site.yml toutes les 15 minutes.

  • Allez dans la section plannification. Puis visitez l’historique des Jobs.