Au vu de la mention d'ansible, du pluriel et de l'usage de serveurs, je dirais que le problème que l'OP cherche a résoudre est la gestion de correctifs sur un parc, chose qu'apt-get ou autres ne font pas.
Du coup, oui, ansible est une possibilité, mais personnellement je ne pense pas qu'il s'agisse de la solution la plus efficace, du fait qu'ansible est "sans agent", tout comme rexify ou drist.
Ces solutions sont pratiques dans le cas ou il n'est pas possible d'installer un outil ou si l'on veut éviter de faire tourner un agent H24 (pour des raisons de performances), avec l'inconvénient que si une machine tombe ou est injoignable pour une raison X ou Y, l'indisponibilité ne se résoudra pas toute seule.
Je pense que les solutions a base d'agent, du type cfengine, chef, puppet (flemme de mettre tous les liens) et bien d'autres sont plus pertinentes, mais ça requiert d'installer des logiciels sur les machines cibles ainsi qu'une (ou plusieurs) machine centrales, ce qui implique un impact de performances et une complexité supérieure.
En échange, les machines cibles vont se maintenir "toutes seules", c'est à dire que leur configuration se dirigera vers la configuration voulue, sans intervention manuelle. Bon, évidemment, il reste en pratique à mettre en place le système ainsi qu'a maintenir les configurations.
En terme d'impact sur les performances systèmes, cfengine est le plus léger dans la catégorie des systèmes à agents, étant écrit en C. Il ne nécessite aussi aucune dépendance, et est packagé dans debian, à minima (qui en empaquète d'autres, hein!).
Dans la liste des outils sans agents, rex est en perl, et donc ne nécessite aussi que peu de dépendance, mais celui qui gagne est clairement drist, étant écrit en shell posix, sa portabilité est maximale. Drist est également, et de loin, le plus simple a utiliser.
Bref, il y a pas mal d'outils (open source ET gratuit, j'ai bien l'impression que c'est ce point qui est important pour l'OP :D, bien que par exemple cfengine est poussé par une boîte qui peut vendre du support) pour gérer un parc, chaque solution a ses avantages et inconvénients. Certains outils sont en Ruby, d'autres en python, en C, en bourne shell, en perl... et nécessiterons donc plus ou moins d'efforts en fonction de son confort personnel avec ces différentes techno.
[^] # Re: apt update + upgrade ?
Posté par freem . En réponse au message gestion des correctifs. Évalué à 5.
Au vu de la mention d'ansible, du pluriel et de l'usage de serveurs, je dirais que le problème que l'OP cherche a résoudre est la gestion de correctifs sur un parc, chose qu'apt-get ou autres ne font pas.
Du coup, oui, ansible est une possibilité, mais personnellement je ne pense pas qu'il s'agisse de la solution la plus efficace, du fait qu'ansible est "sans agent", tout comme rexify ou drist.
Ces solutions sont pratiques dans le cas ou il n'est pas possible d'installer un outil ou si l'on veut éviter de faire tourner un agent H24 (pour des raisons de performances), avec l'inconvénient que si une machine tombe ou est injoignable pour une raison X ou Y, l'indisponibilité ne se résoudra pas toute seule.
Je pense que les solutions a base d'agent, du type cfengine, chef, puppet (flemme de mettre tous les liens) et bien d'autres sont plus pertinentes, mais ça requiert d'installer des logiciels sur les machines cibles ainsi qu'une (ou plusieurs) machine centrales, ce qui implique un impact de performances et une complexité supérieure.
En échange, les machines cibles vont se maintenir "toutes seules", c'est à dire que leur configuration se dirigera vers la configuration voulue, sans intervention manuelle. Bon, évidemment, il reste en pratique à mettre en place le système ainsi qu'a maintenir les configurations.
En terme d'impact sur les performances systèmes, cfengine est le plus léger dans la catégorie des systèmes à agents, étant écrit en C. Il ne nécessite aussi aucune dépendance, et est packagé dans debian, à minima (qui en empaquète d'autres, hein!).
Dans la liste des outils sans agents, rex est en perl, et donc ne nécessite aussi que peu de dépendance, mais celui qui gagne est clairement drist, étant écrit en shell posix, sa portabilité est maximale. Drist est également, et de loin, le plus simple a utiliser.
Bref, il y a pas mal d'outils (open source ET gratuit, j'ai bien l'impression que c'est ce point qui est important pour l'OP :D, bien que par exemple cfengine est poussé par une boîte qui peut vendre du support) pour gérer un parc, chaque solution a ses avantages et inconvénients. Certains outils sont en Ruby, d'autres en python, en C, en bourne shell, en perl... et nécessiterons donc plus ou moins d'efforts en fonction de son confort personnel avec ces différentes techno.