Salut à tous
Je ne sais pas si ça peut intéresser quelqu’un mais je me suis fait un script de post installation de ma Fedora.
Il s’agit suite à une installation de zéro du système d’exploitation de reconfigurer et réinstaller les applications de « tous les jours » .
L’outil mis en œuvre est Ansible. Il s’agit d’un outil de déploiement assez sympa que je manipule de temps à autres au boulot et qui permet de faciliter le travail et permet de maintenir des machines à ISO périmètre.
Je ne vais pas vous faire l’apologie de l’outil mais sachez qu’il permet de faire beaucoup de chose comme Puppet ou d’autres. A la différence de ce dernier si vous lancez des scénarii sur des machines distantes vous n’avez pas besoin d’agent mais juste de python et d’une connexion ssh bien configurer sur toutes les machines distantes.
C’est un outil qui monte, racheté de mémoire par RedHat qui le met de plus en plus en avant.
Ce que je propose ici n’est pas sorcier, et certainement que d’autres ici l’utilise et aurait fait certainement mieux.
Je me suis surtout dit que ça pouvait aider certains et que c’était à la porté de tous même d’un débutant.
Si vous ne connaissez pas Ansible je vous invite à regarder les tutos et le site web du projet.
Ça bouge énormément en ce moment, le projet se démocratise, et l’équipe de développement se fait plaisir.

Je suis ouvert aux questions sur mon Plauybook (script). :-P
Comme je l’ai inscrit dans mon Readme sur GitHub, je conseil de le tester dans une machine virtuelle avec une Fedora 26 fraichement installée ça vous donnera une idée de l’outil et de sa puissance.
En sachant que j’ai fait des choses très simples.

Après lecture si ça vous tente toujours.
https://github.com/jpjubenot/ansible-post-install-my-fedora

N'hésitez pas à me faire un retour, même si vous trouvez ça pourri lol
Oui c'est bien du Redhat.

Tiens si t'as l'occasion test toi aussi freeIPA qui réuni tout les outils pour faire un contrôleur de domaine complet.
Mais aussi Kattelo/Foreman qui sert de base à RedHat satellite 6 pour la gestion, le déploiement, mises à jour etc... d'un parc informatique.
Ansible est là depuis de nombreuses années mais le rachat par RedHat est relativement récent (2015).

Ansible a aussi des desavantages, mais bon quand on doit gérer des centaines/milliers de machines c'est le genre d'outils qui est indispensable.

J'ai cependant, avec le recul d'années d'utilisation en production, une préférence pour puppet, principalement pour la lisibilité de son langage (on est proche du langage naturel), la gestion simple des certificats (et revocation) histoire d'éviter les clef SSH à avoir partout, et surtout, surtout, son langage objet qui permet de faire des trucs très complexes plus facilement. Il y a aussi le fait que c'est les clients qui tirent leur configuration, et pas quelqu'un qui les pousse (=ansible). Il y a un mode standalone/déconnecté bien pratique aussi (pour une infra sans serveur puppet). Et la couche ENC nous a permit de le pluguer à notre LDAP, toutes les conf de toutes les machines y sont stockées, bien pratique.

Ansible a une learning curve plus accessible, il est plus "procédural/fonctionnel" donc plus accessibles pour les sysadmin allergiques à la programmation. Du coup il génère du buzz, autre point négatif (=effet de mode).

Après, je regarde forcément ansible car Puppet font des choix récents bien pourri (vers du tout java), et qui du coup font reflechir. Mais tout changer pour migrer d'outils, c'est dur.

J'aime bien salt stack aussi (tout en python, rapide, que du bonheur).

Bref, chacun ses préférences pour les outils d'automatisation, c'est un peu comme les couleurs. Et c'est pas le choix qui manque.

Si tu aimes automatiser des tâches régulières, je conseil souvent RunDeck (bien plus vieux que Ansible). Il a l'avantage d'avoir une interface web propre. Car Ansible Tower est toujours payant me semble?
Pourtant le yalm utilisé de base par Ansible est orienté "langage naturel".
Après c'est vrai que c'est encore jeune et intègre moins de choses de base que les autres. Après à voir si ce n'est pas plus mal (moins usineàgazpower).
Ansible est en effet très lisible aussi. C'est à comparer avec d'autres solutions comme CFEngine, chef

Chef: 
package 'Install Apache' do
    package_name 'httpd'
end
Ansible 
- name: install the latest version of httpd
  package:
    name: httpd
    state: latest
puppet 
Package { "httpd": ensure => latest }
C'est quand même relativement proche tout ça.

CFEngine: 
body common control
{
  bundlesequence => { "install_packages" }; 
  inputs => { "libraries/cfengine_stdlib.cf" };
}

bundle agent install_packages
{
  packages:
    "httpd" 
         package_policy => "add",     # What to do with packages: install them.
         package_method => generic;   # Infer package manager (e.g. apt, yum) from the OS.
}
là...
LOL
Bon ben je sais que je n'essaierai pas CFEngine alors. Merci ta démo est radicale.
Je n'ai pas essayé "Chef" ni "Puppet", je tenterai surement l'aventure pour me faire une idée.
Mais j'ai pu faire des choses assez rapidement sur Ansible car le code est assez lisible et la doc pas trop mal faite.
Pour mon cas personnel j'administre entre autres une cinquantaine de serveur sous Gnu Linux et c'est déjà bien pratique.
Après je ne connais pas l'offre de RedHat mais il semblerait qu'ils proposent un certain nombre de plugins pour aller plus loin avec Ansible.
Madko, tu parlais du client puppet qui vient chercher sa conf, ansible semble utiliser un plugin qui lui permet de faire un check de status constant des machines distantes.
Bon le principe reste le même.
J'admet que dans ma boîte, j'ai un usage léger de l'outil puisque le gros de mes serveurs tourne sous windows.
Il semblerait que l'équipe d'ansible ait envie de tenter un portage de l'outil pour manager des machines sous windows également par la suite.
Info ou intox ??!!
Merci pour vos retours quoi qu'il en soit. C'est toujours sympa d'avoir une idée de ce qui se fait ailleurs.
Le truc, je pense c'est de sauter le pas, car on a toujours tendance à se dire. Oui mais bon pour si peu de serveurs c'est gérable sans passer par du provionning et puis le temps de mettre en place les scripts ont
aurait tôt fini de faire à la main.....
Mais on prend vite le plis et on comprend tout de suite l'intérêt de ce genre d'outil et même pour une seule machine.
Il suffit de relire son code pour savoir ce qui a été entrepris sur tel ou tel machine. Le collègue sait quels logiciels ont été installés et quels fichiers ont été modifiés et le troisième ou quatrième serveur ajouté à la dernière minute
par le DSI sera installé de la même manière que les précédents suivant le même scénario.
Je rebondis sur ton exemple Madko
Ici Ansible, utilise le module package pour installer des logiciels, l'avantage c'est que le script "permettra" d'installer httpd sur une debian, une centos ou tout autre distribution si le paquet porte le même nom.
Dans mon cas je suis passé de ce module au module dnf plus rapide et fontionnant de façon plus global, pas paquet par paquet.
L'inconvénient c'est que mon script ne marchera que sur une distrib utilisant dnf.
Alors puppet a déjà un client pour Windows. C'est donc un avantage que je n'avais pas cité. Ces ressources (par ex Package) sont déjà agnostique de l'OS, il faut juste en effet croiser les doigts pour que le nom du paquet soit identique entre les différents OS. Je gère avec puppet plus de 5000 VM, et quelques centaines de serveurs, ça aurait été impossible de faire sans un outil de ce genre. Avant d'être passé à puppet les serveurs (environ 300) étaient gérés à la main, à l'ancienne, aucun n'étaient configuré identiquement... le bordel !

Pour Ansible clairement il est bien plus facile à prendre en main. Surement le plus simple de tous.

Comme tu l'as dis, pouvoir décrire de manière lisible, une installation/configuration, pouvoir la reproduire, sans risque d'erreur, bref pouvoir d'écrire son infra en code c'est le pied.
Le truc bien à la mode maintenant c'est l'étape d'après, où tu code ton infra (langage HOT/Heat openstack par ex, ou AWS etc).
Chez nous c'est puppet aussi sur les linux, mais ansible fait son petit chemin. chez nous les 5000vm ça doit pas en être loin (voir plus...) sans compter les pĥysiques.

Tu peux gérer du windows avec ansible mais là j'ai pas creusé plus loin. le souci c'est que ssh est encore jeune dans son intégration à MS windows, donc ça doit utiliser d'autres mécanismes.

Sinon on utilise entre autre SCCM de MS qui gère du linux maintenant avec du vbs/powershell (je préfère le deuxième, même si je trouve qu'ils ont toujours 20 ans de retards sur certains points...). Les autres outils sont très peut intuitif et très très usines à gaz... J'espère qu'ils ne vont pas vouloir les utiliser pour tout car aussi complet ils sont aussi imbuvable c'est... Et l'un utilise le JYTHON sorte de mixe entre du JAVA et du Python. Bon autant le python ça passe, que le java pas bieng me donne des boutons perso.
Oui j'avais pas du tout vu passer l'info.
http://docs.ansible.com/ansible/latest/intro_windows.html

Bon ça fait rêver vos infra les gars.
Notre infra est plus light, environ:
50 Serveurs Linux administrés par ansible
80 autres au moins en mode freestyle ... oui je reconnais beurk
100 autres sous Windows
10 xserve ou mac pro server ... snif snif dire que j'avais encore plus d'xserve ... snif ... apple pas glop
Ben c'est pas mal déjà en binome et que pour la partie serveur.

Si vous habitiez pas si loin de chez moi, surtout Vindicator, je ferai mon mendiant pour un poste. lol

Oui, comme tu dis Madko, l'étape suivante c'est le codage de l'infra saupoudrer d'Hyper-Convergence.
Pouvoir déployer des VM's à la volée et surtout au besoin, les provisionner en settings et applications en un script,
tout en découpant des quartiers de LUN's dans nos baies de stockage.
J'en ai déjà des frissons, et la bave aux lèvres xptdr. :hammer:
Bah si ta la main sur ton infra et que cela te conviens garde ton poste, chez nous c'est la misère parfois rien que pour dégager un serveur merdique au possible qui n'a même plus de support officiel...
Voir pour faire de simple action.