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.
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'"
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]
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.
Il n'y a pas de changement particulier dans 1.9.1.
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.
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 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?
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.
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