Comment copier des fichiers entre des hôtes distants dans ansible

Comment copier des fichiers entre des serveurs distants dans Ansible ?. est le but derrière cet article. Chaque article que je suis allé et lu me donnait des suggestions mais rien de pratique. Je voulais simplement faire un ansible rsync. Je voulais exécuter rsync entre les hôtes distants et copier des fichiers entre les hôtes distants.

So here is the example oriented article. Dans ce post, nous allons discuter des deux principales options disponibles pour copier les fichiers entre les serveurs distants ou de distant à distant.

Lorsque nous voulons copier des fichiers d’un hôte à un autre hôte, en général, la première chose qui nous vient à l’esprit est SCP et ansible a un module dédié pour le même nom COPY

Si vous voulez copier un fichier à partir d’un maître de contrôle Ansible vers des hôtes distants, le module COPY (scp) serait très bien. Mais nous avons besoin de quelque chose de plus lorsque nous voulons copier les fichiers entre les hôtes distants ou pour copier des fichiers de distant à distant.

Nous allons utiliser certains des modules ansible comme copy, fetch, synchronize pour accomplir l’exigence de copier les fichiers entre les hôtes dans ansible.

Alors que nous savons déjà à quoi sert le module Ansible Copy.

Voici l’introduction simple à Ansible Fetch et Ansible Synchronize.

Ansible Fetch consiste à tirer les fichiers du serveur distant vers la machine de contrôle.

Ansible Synchronize est utilisé pour copier les fichiers entre les serveurs distants (ou) les hôtes cibles. Cela revient plus à exécuter RSYNC avec l’aide d’Ansible.

L’index

1. Le plan / Le besoin
2. Méthode1 : Copier les fichiers entre les hôtes distants en utilisant le module fetch
3. Méthode2 : Copier le fichier entre les hôtes distants en utilisant le module synchronize
   1. Synchronize Push
   2. Synchronize Pull
4. La sortie de l’exécution
5. Références et autres articles connexes.

Le plan / L’exigence

Pour commencer, définissons nous-mêmes une certaine exigence afin que, nous puissions nous relier et être sur la même page.

Nous avons deux serveurs nommés comme suit

1. mwiappi01
2. mwiapp02

Le besoin est de copier un fichier de mwiapp01 à mwiapp02. Avant de continuer, voici le diagramme d’infrastructure de notre installation.

Ne soyez pas confus par le nom Master. C’est juste une machine de contrôle. Rappelez-vous que Ansible est sans agent. donc il n’y a pas de maître et d’esclave.

Méthode1 : Copier de app01 à app02 en utilisant le module fetch

Aucune authentification SSH requise entre les nœuds distants pour cette méthode

C’est la meilleure et la plus simple option pour transférer des fichiers entre les nœuds distants Lorsque vous n’avez pas d’authentification basée sur une clé SSH activée entre les nœuds distants. Bien que, ce n’est pas le chemin le plus court (ou) beeline. Il fonctionne bien lorsque notre objectif principal est de faire le travail, quelle que soit l’approche.

C’est un processus en deux étapes quand il s’agit de cette méthode.

Etape1 : Récupérer le fichier du serveur distant (source) vers le maître ansible

Etape2 : Pousser (Copier) le fichier du maître ansible vers le serveur distant ( destination)

Ici le maître agit comme un tampon où les fichiers sont temporairement stockés puis transférés.

Considérez le playbook suivant qui effectue les deux tâches mentionnées ci-dessus.

--- - hosts : app tasks : - name : Fetch the file from the mwiapp01 to master run_once : yes fetch : src=/tmp/app01-to-app02.jar dest=buffer/ flat=yes when : "{{ inventory_hostname == 'mwiapp01' }}" - name : Copier le fichier du maître vers mwiapp02 copy : src=buffer/app01-to-app02.jar dest=/tmp/ when : "{{ inventory_hostname == 'mwiapp02' }}"

ici nous utilisons "when" pour effectuer l’exécution basée sur les conditions et inventory_hostname est la variable intégrée ansible qui pointera le nom d’hôte distant d’exécution actuel.

Parfois, vous pourriez avoir besoin d’utiliser ansible_hostname à la place de inventory_hostname

Nous donnons essentiellement l’instruction à l’Ansible d’exécuter la tâche Fetch uniquement sur le serveur mwiapp01 et la tâche copy uniquement lorsque le mwiapp02 est l’hôte d’exécution distant actuel.

Méthode 2 : Copier de l’app01 à l’app02 en utilisant le module synchronize

L’authentification basée sur une clé SSH doit être activée entre les hôtes distants

Pour que le module Synchronize fonctionne sans problème,l’authentification basée sur une clé SSH doit être activée entre les nœuds distants. Sinon, la tâche de synchronisation sera bloquée et votre jeu Ansible aussi.

En d’autres termes, les nœuds distants doivent être en mesure de se connecter les uns aux autres sans avoir à entrer le mot de passe manuellement. Nous réalisons cela principalement avec l’aide de la clé SSH.

Comme dit précédemment. Ansible Synchronize est plus comme Ansible RSYNC. la fonctionnalité rsync typique de Linux.

Pour savoir comment activer l’authentification basée sur la clé juste en quelques secondes, Reportez-vous à l’article suivant

Enable SSH Key based authentication using Ansible

Une fois que nous sommes prêts avec l’authentification basée sur la clé SSH. Nous sommes prêts à jouer la pièce. ( playbook).

Il existe deux méthodes pour copier des fichiers en utilisant le module Synchronize

1. Synchronize Pull
2. Synchronize Push

Considérez les playbooks suivants qui copient le fichier de mwiapp01 à mwiapp02 en utilisant à la fois la méthode Synchronize Pull et Synchronize Push

Synchronize Pull

Ciblé sur : Serveur source (mwiapp01)

Délégué à et exécuté sur : Serveur de destination (mwiapp02)

Explication : Comme il est exécuté dans le serveur de destination où le fichier doit arriver. La tâche consiste à tirer le fichier du serveur d’origine (ou) source.

Voici le playbook qui s’exécute sur le serveur de destination mwiapp02 à l’aide de la délégation et pulls le fichier de mwiapp01 à mwiapp02

---- nom : tâche Sync Pull - Exécuté sur l'hôte de destination "{{groupes}}" hôtes : "{{groupes}}" user : wlsusr tasks : - name : Copy the file from mwiapp01 to mwiapp02 using Method Pull tags : sync-pull synchronize : src : "{{ item }}" dest : "{{ item }}" mode : pull delegate_to : "{{groups}}" register : syncfile run_once : true with_items : - "/tmp/app01-to-app02.jar"

On pourrait penser que le playbook est configuré pour s’exécuter sur le premier serveur puisque la directive hosts cible le premier serveur. hosts: "{{group}}" mwiapp01

Mais vous devez remarquer que nous exécutons en fait cette tâche sur le second serveur mwiapp02 à l’aide de delegate_to

Regardez l’enregistrement d’écran suivant pour mieux comprendre cela.

Synchronize Push

Targeted to : Serveur de destination (mwiapp02)

Délégué à et exécuté sur : Serveur source (mwiapp01)

Explication : Comme il est exécuté dans le serveur source où le fichier est déjà présent. La tâche consiste à pousser le fichier vers le serveur de destination

Voici le playbook qui s’exécute sur le serveur source mwiapp01 et pushesle fichier de 01 à 02

- name : Sync Push task - Executed on source host "{{groups}}" hosts : "{{groupes}}" user : wlsusr tasks : - name : Copy the file from mwiapp01 to mwiapp02 using Method Push tags : sync-push synchronize : src : "{{ item }}" dest : "{{ item }}" mode : push delegate_to : "{{groups}}" register : syncfile with_items : - "/tmp/app01-to-app02.jar"

On pourrait penser que le playbook est configuré pour s’exécuter sur le deuxième serveur puisque la directive hosts cible le premier serveur. hosts: "{{group}}" mwiapp02

Mais vous devez remarquer que nous exécutons en fait cette tâche sur le premier serveur mwiapp01 avec l’aide de delegate_to

Le Playbook est composé de deux listes de tâches basées sur l’hôte. La première s’exécute en utilisant Synchronize Pull sera exécutée sur mwiapp02et la seconde avec Synchronize Push sera exécutée sur mwiapp01

Bien que le playbook soit intelligible ( facile à comprendre). Je pense qu’il y a quelques lignes particulières qui nécessitent plus d’explications, comme "{{groups}}"

Il représente le premier élément (ou) serveur du groupe d’hôtes nommé « app » tout comme un tableau

J’espère que l’image suivante rendra les choses plus claires.

Les deux autres lignes importantes du fichier sont les suivantes

• mode Il représente le modèle de la Synchronize. Soit Synchronize pull ou Synchronize push
• delegate_to Il indique à ansible, où la tâche (ou) la commande doit réellement être exécutée.

J’espère que vous l’avez peut-être compris maintenant. delegate_to et le hosts avec mode dans ansible-playbook, travaillent ensemble pour rendre possible l’exécution à distance (ou) la copie entre les nœuds distants.

Sortie de l’exécution

Dans la capture d’écran précédente, nous avons exécuté 3 commandes. La première et la dernière est une commande Ansible ad-hoc pour vérifier la disponibilité du fichier sous le /tmprépertoire dans mwiapp02serveur

nous utilisons --limit pour exécuter la commande dans un seul serveur, bien que nous utilisions le groupe d’hôtes qui contient deux serveurs.

nous avons réussi à copier un fichier de mwiapp01 à mwiapp02 en utilisant les modules Fetch et Synchronize.

Conclusion

Dans ce post, nous avons appris et exécuté avec succès comment copier des fichiers entre des hôtes distants en utilisant les modules ansible copy et fetch. Nous avons appris deux méthodes pour copier les fichiers entre les hôtes en utilisant ansible.

J’espère que vous trouverez cet article utile.

1. Référence du module Ansible Copy
2. Référence du module Ansible Fetch
3. Référence du module Ansible Synchronize
4. Comment copier ou échanger une clé SSH entre plusieurs hôtes – Ansible
5. Comment échanger l’IP et mettre à jour le fichier /etc/hosts dans plusieurs hôtes – Ansible

J’espère que cet article vous aidera. Si vous aimez cet article, veuillez le partager

.