La synchronisation avec le serveur qui a porté ssh sur localhost échoue [Résolu]

Aperçu

Chose que tu veux faire

La solution d'abord

Même si le numéro de port est différent, il fonctionnera mal si la partie du nom d'hôte est la même.

Au lieu d'écrire l'adresse IP directement dans le fichier d'inventaire, spécifiez quelque chose comme host1 ansible_ssh_host = 127.0.0.1 pour que la partie du nom d'hôte ne soit pas couverte.

Motif qui a échoué

Définition écrite

main.yml


- name: sync source code
  synchronize:> 
    dest=/var/ma2saka/myapp
    src=/Users/ma2saka/ansible/work/myapp/ 
    recursive=yes
    links=yes
    rsync_opts="--exclude='.git'"

Dans l'inventaire

inventory.ini


[dev]
127.0.0.1

[dev:vars]
ansible_ssh_user=vagrant
ansible_ssh_port=2222

Le serveur mis en place par vagrant attend au 2222 local.

La clé publique est enregistrée à l'avance comme suit.

ssh-add -D
ssh-add ~/.ssh/id_rsa
ssh-copy-id -p 2222 [email protected]

Obtenez une erreur

TASK: [deploy | sync source code] *********************************************
failed: [127.0.0.1 -> 127.0.0.1] => {"cmd": "rsync --delay-updates -FF --compress --archive --rsh 'ssh  -S none -o StrictHostKeyChecking=no -o Port=2222' --exclude='.git' --out-format='<<CHANGED>>%i %n%L' \"/Users/ma2saka/ansible/work/myapp/\" \"/var/ma2saka/myapp\"", "failed": true, "rc": 23}
msg: rsync: change_dir "/Users/ma2saka/ansible/work/myapp/" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]


FATAL: all hosts have already failed -- aborting

Non, même si vous dites msg: rsync: change_dir" / Users / ma2saka / ansible / work / myapp / "a échoué: aucun fichier ou répertoire de ce type (2). Parce qu'il y a ce répertoire. Peu importe comment vous le regardez.

Je l'ai mis dans le breuvage 1.8.2 Je soupçonnais que c'était parce que j'ai essayé de le remettre avec pip

Il n'y a pas de changement particulier dans 1.9.1.

Fonctionne bien avec Amazon ou un autre serveur

inventory.ini


[dev]
myapp1.amazon.example.com
myapp2.amazon.example.com
myapp3.amazon.example.com

[dev:vars]
ansible_ssh_user=ec2-user
ansible_ssh_port=22

Cela fonctionne comme prévu sans aucun problème.

Cela a fonctionné lorsque j'ai donné à 127.0.0.1 un alias dans / etc / hosts

127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost
127.0.0.1 this.is.it

inventory.ini


[dev]
this.is.it

[dev:vars]
ansible_ssh_user=vagrant
ansible_ssh_port=2222

Lorsque vous l'exécutez avec ça.

 ..Abréviation..

TASK: [deploy | sync source code] *********************************************
changed: [this.is.it -> 127.0.0.1]

 ..Abréviation..

Ça marche ... Cela fonctionne comme prévu, donc c'est bien, mais il y a encore des choses qui ne sont pas surprenantes.

Si le nom d'hôte est localhost, il ne se connectera pas en premier lieu

Si vous ne pouvez pas spécifier l'adresse IP, pourquoi n'utilisez-vous pas localhost?

TASK: [deploy | sync source code] *********************************************
failed: [localhost -> 127.0.0.1] => {"cmd": "rsync --delay-updates -FF --compress --archive --rsh 'ssh  -S none -o StrictHostKeyChecking=no -o Port=2222' --exclude='.git' --out-format='<<CHANGED>>%i %n%L' \"/Users/ma2saka/ansible/work/myapp/\" \"/var/ma2saka/myapp\"", "failed": true, "rc": 12}
msg: ssh: connect to host localhost port 2222: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

Bien.

En d'autres termes, en réalité, le "nom" de l'hôte est le problème?

Résolu en définissant ansible_ssh_host

C'est exactement ce phénomène qui a été capturé.

Lors de la connexion avec ansible à un hôte qui redirige le port sur l'hôte local, il semble judicieux de donner un alias approprié dans le fichier d'inventaire.

[dev]
# lvh.moi ou ça.is.Vous n'êtes pas obligé de l'écrire
host1 ansible_ssh_host=127.0.0.1

[dev:vars]
ansible_ssh_user=vagrant
ansible_ssh_port=2222

J'ai également vérifié le code du module de synchronisation et le script qui a été transféré à l'exécution, j'ai donc compris le comportement, mais c'est un piège. La plupart du temps, le message d'erreur est trop hostile. Tout en se plaignant. Cela fait du bien parce que cela a été résolu.

Réflexion

Si vous regardez attentivement -vvvv, vous pouvez voir" où le script s'exécute ". Lorsque j'ai écrit 127.0.0.1 et que j'ai échoué, le script s'exécutait en fait sur un serveur distant. Cependant, le répertoire est introuvable car le chemin relatif de la machine locale est écrit dans la spécification source.

Quand j'ai remarqué cela, j'aurais pu immédiatement deviner qu'il ne s'agissait pas d'un bogue dans un module spécifique mais de la logique de résolution du nom d'hôte d'ansible, mais je passais du temps à retracer la partie égarée. C'est assez difficile.

Recommended Posts

La synchronisation avec le serveur qui a porté ssh sur localhost échoue [Résolu]
Modifiez le fichier du serveur de destination de la connexion SSH sur le serveur avec VS Code
Connectez-vous à un serveur distant avec SSH
Conseils de dessin avec matplotlib côté serveur
Accédez au serveur SQL de l'hôte avec python27 / pyodbc sur le conteneur
Remarque sur la façon de vérifier la connexion au port du serveur de licences
Paramètres de démarrage du projet Dango sur le serveur avec Pycharm
Paramètres de redirection de port ssh Linux (tunnel)
Remarques sur l'utilisation de matplotlib sur le serveur
Obtenez la largeur du div côté serveur avec Selenium + PhantomJS + Python
Connectez-vous au VPN avec votre smartphone et éteignez / rallumez le serveur