C'est un chouette outils, il est simple d'utilisation et le workflow proposé me parait très acceptable !
Il n'y a rien à installé côté serveur à part ssh ?
Y a de chouettes programmes en Rust sur LinuxFR ces derniers temps c'est chouette !
Il n'y a rien à installé côté serveur à part ssh ?
Nope, comme ansible c'est "agent-less". C'est ce que j'appréciais grandement à propos de Ansible d'ailleurs.
En plus les bindings de libssh2 en Rust sont vraiment agréable à utiliser. Mais j'ai volontairement restraint à me reposer sur ssh-agent parce que :
avoir un prompt pour le mot de passe dans un script d'automatisation c'est pas top
avoir un prompt pour la passphrase de la clé ssh c'est pas top non plus
Et puis, dans un principe KISS, je délègue l'authent à un autre outil (ssh-agent) et je fais uniquement ce que j'ai besoin de faire : exécuter des commandes sur des remote.
On est d'accord si tu ne le demandes pas toi-même. :-)
Maintenant que tu découvres sshpass, tu vois qu'il n'y a pas de raison de ne prendre que la moitié de la lib (enfin c'est caricatural mais tu vois ce que je veux dire.) ;-) Faut juste bien insister que l'outil ne gère pas le prompt et doit fonctionner sans cette interruption.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
je suis en plein dans l'automatisation en ce moment et après avoir bricolé un peu avec Ansible, je me suis intéressé à Salt et je trouve que ton projet s'en rapproche pas mal sur certains points.
Ça fonctionne en client-serveur avec un agent et un équivalent des playbooks d'Ansible, en yaml également. Mais ça peut fonctionner aussi sans agent et sans master avec salt-ssh. Il y a un inventaire à constituer également.
Du coup on retrouve un fonctionnement similaire à ton projet, en oneliner et sans écrire de yaml (même si ça reste possible).
Pour reprendre les exemples de ton README :
$ salt-ssh '*' cmd.run 'echo "run on all hosts"'
$ salt-ssh 'backend' cmd.run 'echo "run on specific host"'
Là c'est un exemple avec le module cmd.run, mais Salt propose tout un ensemble de modules permettant de faire tout un tas de choses sans passer par une commande shell.
Sauf que Salt c'est pas KISS du coup. Ca fait beaucoup de choses (c'est pas forcément un défaut).
De plus l'output de salt-ssh est difficilement exploitable dans un script shell ou autre programme.
Ici il s'agit de filer un outil et de pas rester dans tes pattes. Tu fais ce que tu veux comme tu veux par la suite.
Après, d'ici à ce que je fasse réellement concurrence à Ansible, Chef, Puppet, Salt, … il va falloir que je constitue un costaud écosystème.
Je prévois potentiellement de faire un système de plugin à la kubectl: tricorder-<plugin name> dans le PATH? alors tu as tricorder subcommand de disponible. Ce qui te laisserait faire des plugins dans n'importe quel langage.
$ salt-ssh '*' cmd.run 'echo "run on all hosts"'$ salt-ssh 'backend' cmd.run 'echo "run on specific host"'
équivaut en fait à
$ ansible '*' -m command -a 'echo "run on all hosts"'$ ansible 'backend' -m command -a 'echo "run on specific host"'
Après, l'utilisation du module command/cmd.run est une forme très basique qui se rapproche de ([pd]?s|d)sh évoqué récemment avec juste en prime une sortie familière quand on utilise déjà l'outil. C'est un poil plus intéressant quand on peut utiliser les autres modules.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Le module "shell" de Ansible n'est pas idempotent non plus.
En fait, beaucoup de modules de Ansible ne sont pas idempotent.
Ce qui permet d'implémenter l'idempotence dans Ansible c'est la possibilité d'interoger le remote sur son état et d'exécuter conditionnellement la tâche.
Par exemple, avec tricorder ça donnerait quelque chose comme :
# idempotent car si le service est déjà démarré, ça ne fait rien
tricorder -i inventory -- systemctl start nginx.service
res=$(tricorder -i inventory -- test -f $FILE)host_ids=$(echo$res| jq "some request to get all hosts with non zero exit code")for host_id in $host_idsdo
tricorder -i inventory -H $host_id -- sh -c "echo $host_id > $FILE"done
Alors oui, c'est verbeux pour le moment, parce qu'il faut le faire à la main, mais on pourrait très bien imaginer un plugin dans le futur qui fait ce genre de choses.
Donc pour te répondre, non pas d'idempotence dans cette brique élémentaire.
Je plussoie pour dire que Ansible se dit idempotent et souvent on lit que l'on décrit l'état plus que le processus, mais en pratique ce n'est pas vrai du tout. Quelques briques font effectivement ça, mais plein de brique ne le font pas du tout. Par exemple la suppression d'une ligne ajouté par un run précédent du programme n'est pas forcément géré (suivant la directive utilisé).
Je ne jette pas la pierre à Ansible, ça reste un outil correct, mais en pratique il faut tester les scripts ansible, tout comme le code, et Docker, avec son redémarrage de la feuille blanche à chaque fois, est plus prédictible (ce n'est toutefois pas le même scope que ansible, on est d'accord).
Posté par cg .
Évalué à 3.
Dernière modification le 26 mars 2022 à 15:03.
Pour ce genre de besoin simple, j'utilise soit clusterssh, soit parallel, selon les cas. (Pour les trucs pour complexes/plus régulier, j'ai Puppet en place, mais ce n'est pas le sujet).
Mais je verrai si ton outil peut couvrir d'autres cas d'usage, ça a l'air assez chouette !
Ce que j'apprécie avec parallel et clusterssh, c'est que l'inventaire est un simple fichier avec une liste de machines. Ainsi, j'ai tendance à les générer à la volée pour les cas spécifiques.
Par exemple cette commande m'ouvre un xterm sur chaque machine d'un réseau dont le nom commence par dev (les machines de l'équipe de développement), et me donne une fenêtre en plus qui tape la commande dans tous les xterms en question :
Je prévois de rajouter par la suite des fonctionnalités du type :
système de plugin
"gather facts" à la ansible
API Rust/Go/Typescript/Python pour intégrer ça dans ton langage de script favoris (parce que bash c'est quand même bof), imagine distribuer un setup.exe qui te déploie l'infra complète :D
J'ai commencé petit dans le but de voir comment cela pourrait être utilisé. Après tout exécuter des commandes sur des hôtes distant c'est le coeur du projet, le MVP si j'ose dire.
Posté par Alex G. .
Évalué à 2.
Dernière modification le 28 mars 2022 à 16:53.
Moi j'ai bien aimé le projet pyinfra (sans l'avoir testé sur de gros projets).
C'est KISS là aussi, et perso mon expérience (plusieurs années) avec Ansible, m'a fait penser qu'à la fin c'est mieux de pouvoir programmer… (avec Ansible je me retrouvais souvent à utiliser les boucles, et des siouxeries de manipulation des variables, qui auraient été bien plus simple en python).
# Discussion HackerNews
Posté par David Delassus (site web personnel) . Évalué à 4.
https://news.ycombinator.com/item?id=30806615
https://link-society.com - https://kubirds.com
# Longue vie et prospérité
Posté par Aldebaran (site web personnel) . Évalué à 3. Dernière modification le 25 mars 2022 à 22:18.
C'est un chouette outils, il est simple d'utilisation et le workflow proposé me parait très acceptable !
Il n'y a rien à installé côté serveur à part ssh ?
Y a de chouettes programmes en Rust sur LinuxFR ces derniers temps c'est chouette !
[^] # Re: Longue vie et prospérité
Posté par David Delassus (site web personnel) . Évalué à 4.
Merci pour le retour :)
Nope, comme ansible c'est "agent-less". C'est ce que j'appréciais grandement à propos de Ansible d'ailleurs.
En plus les bindings de libssh2 en Rust sont vraiment agréable à utiliser. Mais j'ai volontairement restraint à me reposer sur ssh-agent parce que :
Et puis, dans un principe KISS, je délègue l'authent à un autre outil (ssh-agent) et je fais uniquement ce que j'ai besoin de faire : exécuter des commandes sur des remote.
https://link-society.com - https://kubirds.com
[^] # Re: Longue vie et prospérité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Faut rien présupposer et juste déléguer à SSH :) Y a(ura) toujours des solutions et c'est aux usagers/admins de faire leurs choix.
ssh-agentsshpass“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Longue vie et prospérité
Posté par David Delassus (site web personnel) . Évalué à 3.
Ce que je voulais dire c'est "implémenter moi même un prompt qui demande un secret alors que des outils dédiés existent pour ça" c'est pas top.
Je connaissais pas sshpass :)
https://link-society.com - https://kubirds.com
[^] # Re: Longue vie et prospérité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
On est d'accord si tu ne le demandes pas toi-même. :-)
Maintenant que tu découvres sshpass, tu vois qu'il n'y a pas de raison de ne prendre que la moitié de la lib (enfin c'est caricatural mais tu vois ce que je veux dire.) ;-) Faut juste bien insister que l'outil ne gère pas le prompt et doit fonctionner sans cette interruption.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# salt(-ssh)
Posté par madhatter (site web personnel) . Évalué à 2.
Salut,
je suis en plein dans l'automatisation en ce moment et après avoir bricolé un peu avec Ansible, je me suis intéressé à Salt et je trouve que ton projet s'en rapproche pas mal sur certains points.
Ça fonctionne en client-serveur avec un agent et un équivalent des playbooks d'Ansible, en yaml également. Mais ça peut fonctionner aussi sans agent et sans master avec salt-ssh. Il y a un inventaire à constituer également.
Du coup on retrouve un fonctionnement similaire à ton projet, en oneliner et sans écrire de yaml (même si ça reste possible).
Pour reprendre les exemples de ton README :
$ salt-ssh '*' cmd.run 'echo "run on all hosts"'
$ salt-ssh 'backend' cmd.run 'echo "run on specific host"'
Là c'est un exemple avec le module
cmd.run, mais Salt propose tout un ensemble de modules permettant de faire tout un tas de choses sans passer par une commande shell.Belle initiative en tout cas.
There is no spoon...
[^] # Re: salt(-ssh)
Posté par David Delassus (site web personnel) . Évalué à 4.
Sauf que Salt c'est pas KISS du coup. Ca fait beaucoup de choses (c'est pas forcément un défaut).
De plus l'output de salt-ssh est difficilement exploitable dans un script shell ou autre programme.
Ici il s'agit de filer un outil et de pas rester dans tes pattes. Tu fais ce que tu veux comme tu veux par la suite.
Après, d'ici à ce que je fasse réellement concurrence à Ansible, Chef, Puppet, Salt, … il va falloir que je constitue un costaud écosystème.
Je prévois potentiellement de faire un système de plugin à la kubectl:
tricorder-<plugin name>dans le PATH? alors tu astricorder subcommandde disponible. Ce qui te laisserait faire des plugins dans n'importe quel langage.Merci pour le retour en tout cas :)
https://link-society.com - https://kubirds.com
[^] # Re: salt(-ssh)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
À noter que le même exemple
équivaut en fait à
Après, l'utilisation du module
command/cmd.runest une forme très basique qui se rapproche de([pd]?s|d)shévoqué récemment avec juste en prime une sortie familière quand on utilise déjà l'outil. C'est un poil plus intéressant quand on peut utiliser les autres modules.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Idempotence
Posté par barmic 🦦 . Évalué à 5.
Plus kiss, mais sans idempotence ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Idempotence
Posté par David Delassus (site web personnel) . Évalué à 8.
Le module "shell" de Ansible n'est pas idempotent non plus.
En fait, beaucoup de modules de Ansible ne sont pas idempotent.
Ce qui permet d'implémenter l'idempotence dans Ansible c'est la possibilité d'interoger le remote sur son état et d'exécuter conditionnellement la tâche.
Par exemple, avec tricorder ça donnerait quelque chose comme :
Alors oui, c'est verbeux pour le moment, parce qu'il faut le faire à la main, mais on pourrait très bien imaginer un plugin dans le futur qui fait ce genre de choses.
Donc pour te répondre, non pas d'idempotence dans cette brique élémentaire.
https://link-society.com - https://kubirds.com
[^] # Re: Idempotence
Posté par Alex G. . Évalué à 2.
Je plussoie pour dire que Ansible se dit idempotent et souvent on lit que l'on décrit l'état plus que le processus, mais en pratique ce n'est pas vrai du tout. Quelques briques font effectivement ça, mais plein de brique ne le font pas du tout. Par exemple la suppression d'une ligne ajouté par un run précédent du programme n'est pas forcément géré (suivant la directive utilisé).
Je ne jette pas la pierre à Ansible, ça reste un outil correct, mais en pratique il faut tester les scripts ansible, tout comme le code, et Docker, avec son redémarrage de la feuille blanche à chaque fois, est plus prédictible (ce n'est toutefois pas le même scope que ansible, on est d'accord).
# Je testerai
Posté par cg . Évalué à 3. Dernière modification le 26 mars 2022 à 15:03.
Pour ce genre de besoin simple, j'utilise soit clusterssh, soit parallel, selon les cas. (Pour les trucs pour complexes/plus régulier, j'ai Puppet en place, mais ce n'est pas le sujet).
Mais je verrai si ton outil peut couvrir d'autres cas d'usage, ça a l'air assez chouette !
Ce que j'apprécie avec parallel et clusterssh, c'est que l'inventaire est un simple fichier avec une liste de machines. Ainsi, j'ai tendance à les générer à la volée pour les cas spécifiques.
Par exemple cette commande m'ouvre un
xtermsur chaque machine d'un réseau dont le nom commence par dev (les machines de l'équipe de développement), et me donne une fenêtre en plus qui tape la commande dans tous lesxtermsen question :Je fais beaucoup le même genre de trucs avec
parallel. Faudra que je fasse un journal sur le sujet un de ces jours.[^] # Re: Je testerai
Posté par David Delassus (site web personnel) . Évalué à 3.
La différence, c'est l'ambition :)
Je prévois de rajouter par la suite des fonctionnalités du type :
setup.exequi te déploie l'infra complète :DJ'ai commencé petit dans le but de voir comment cela pourrait être utilisé. Après tout exécuter des commandes sur des hôtes distant c'est le coeur du projet, le MVP si j'ose dire.
https://link-society.com - https://kubirds.com
# pyinfra
Posté par Alex G. . Évalué à 2. Dernière modification le 28 mars 2022 à 16:53.
Moi j'ai bien aimé le projet pyinfra (sans l'avoir testé sur de gros projets).
C'est KISS là aussi, et perso mon expérience (plusieurs années) avec Ansible, m'a fait penser qu'à la fin c'est mieux de pouvoir programmer… (avec Ansible je me retrouvais souvent à utiliser les boucles, et des siouxeries de manipulation des variables, qui auraient été bien plus simple en python).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.