Reprise du message précédent :
vouala

Haha si je chope l'enflure qui a fait un hostname "IF", si j'ai pas le FQDN dans le fichier dans lequel je trifouille je me retrouve avec une tétrachiée de résultat moisis

Ca m'intéresse comme phrase !
 
J'ai pas regardé en détail, ça couvre tout le périmètre de GLPI (licences, contrats etc) ?

Bah tu fous tout dans un repo git et tu le garde en local  

 
Yep.
 
Y'a une version démo en ligne sur le site officiel qui te permettra de te faire une idée
 
https://demo.combodo.com/simple/pag [...] _pwd=admin

Merci !!

 
je sais que les gens du wiki ont une solution à ce problème, mais je ne sais plus laquelle mais ça doit être un truc du genre oui, export pdf ou html stocké sur un NAS qu'on a sur site.

Bon je m'attaque à PQL (Puppet Query Language), j'ai raison ou pas ?

Les gens du wiki

il y a des gens pour tout

 
Bah ouais c'est pratique
 
Non en fait j'en sais rien, ça m'évoque juste Puppet et la gestion de conf de serveurs.
 
Peut être que je me plante atrocement

https://puppet.com/docs/puppetdb/5. [...] 4/pql.html
Ca peut être utile pour certains trucs, bon là ça marche moyen si je fais des requêtes via puppetboard vu que cette partie est un peu buguée m'enfin
Le but c'est de scripter certains trucs (là dans mon cas je veux nettoyer les certs et plus largement les nodes qui n'ont pas étés enlevés du système (dhcp, dns, ticket kerberos, cert puppet, site.pp puppet, ..)).
Ca me file une base puis je moulinette ça sur les autres services voir ce qui traîne, j'ai ~500 nodes puppet.
Après tu fais run ça 2x par an

Je laisse ça aux vrais informaticiens, n'étant que simple alternant

J'adore nettoyer ce que les gens n'ont pas été capables de faire correctement au fil de l'eau

 
Dites moi si la puppetdb cli est moisie que je m'y aventure ou pas

Ansible power chez moi  

Ansible power, le truc édité par Red Hap ?

 
   
 
J'ai vraiment fais exprès de mettre power, le pouvoir d'ansible quoi... après oui awx c'est pas mal aussi  

ansible, plus j'en fait, plus j'ai envie de m'en débarasser

 
Tu le remplaces par quel outil chef ?

je comptais m'y mettre à ansible mais je ne sais pas par ou commencer

Par le début

Puppet je trouve que ça s'améliore avec le temps

 
Un bon tutoriel: https://www.youtube.com/watch?v=DwNapBHypE8

La bataille se joue entre Ansible et Puppet ou y'en a d'autres ?
 
Je vais sûrement devoir m'y mettre pour le boulot dans les prochains mois...

Y'a Chef aussi je crois ?

https://www.hebergeurcloud.com/pour [...] formation/

Merci
 
Du coup, lequel est le meilleur ?

Ca dépend

pupet est client server c'est plus facile à manoeuvrer je pense

ansible lui peut aller conf des switchs aussi https://docs.ansible.com/ansible/2. [...] odule.html

Ansible le n'a pas besoin d'agent, marche via ssh.

Puppet marche sur Linux, macOS et Windows. Nécessaire pour un parc étherogene (mon cas).

 
saltstack aussi.
 

 
en fait je conserverais un peu d'ansible pour ce pour quoi il est fait, construire en one shot, rapidement, et sur un petit nombre de hosts.
La dernière fois j'ai eu besoin d'installer une stack graylog / mongodb / elasticsearch avec un reverse proxy nginx, je me suis crée mon propre role, en m'inspirant de bouts de roles mongodb/ES/graylog qui existent mais qui me convenaient pas.
En une journée environ c'était plié, et si j'ai besoin de remonter un graylog j'ai mon role, et je peux le partager avec le reste de la boite déjà.
 
Par contre je travaille notamment sur une plateforme ou les ops ont voulu utiliser ansible derrière des runners gitlab pour déployer une petite centaine de serveurs et les maintenir en configuration,et livrer les applicatifs.
Le problème c'est qu'Ansible n'est pas fait pour du maintien en configuration, puisqu'à moins d'être croné ou piloté par un AWX, il ne se lance que quand on décide de le lancer, et il ne réagit par du tout aux dérives comme le ferait un puppet/salt et compagnie. On a eu des cas ou des roles modifiés étaient passés sur des environnements mais oublié de pousser en prod, et quand un gars passait 1 mois plus tard sur un autre changement, il se retrouvait à appliquer des modifs d'un autre.  
AWX j'ai regardé un peu, ça devient vite une usine à gaz qui oriente ansible vers un truc pour quoi il n'est pas vraiment fait, en lui ajoutant des fonctionnalités qu'on retrouve sur un rundeck.
 
Et la plus grande faiblesse d'Ansible à mon sens pour faire cela, c'est d'etre agent-less et de reposer sur SSH qui est très lent et se scale très mal. A côté d'un agent saltstack zero MQ, on a l'impression d'être une 2cv face à une Veyron, et plus on ajoute de host, plus les playbooks s'allonge, et plus le déploiement continu devient terriblement lent et les ops perdent un temps fou à attendre, simplement. On a beau eu essayer de tuner ssh et les options ansible, c'est toujours lent, et ça demande aussi de gérer la tringlerie ssh (gestion des clés, des known hosts etc.). En terme de sécu c'est très moyen aussi.
 
Le fait d'être agent-less l'empêche aussi complètement d'agir sur de l'event-driven qui devient de plus en plus important dans les infras, et donc il doit obligatoirement être épaulé d'un autre outil qui réagit à des événements sur la prod.
 
Autre truc qui me gonfle, c'est la rapidité avec laquelle les deprecated débarquent sur Ansible, obligeant à retoucher les rôles tous les 6 mois pour pas se retrouver avec un truc injouable. Entre ansible 2.2 et 2.7 par exemple le nombre de trucs qui ont changé de terme est dingue.

C'est un son de cloche que j'ai entendu à plusieurs reprises yep

 
Très bonne analyse d'Ansible dans l'ensemble. Après forcement en fonction du contexte c'est pas forcément le meilleur outil on est d'accord. Terraform est pas mal pour la gestion des infra dans le cloud. Ansible-pull si tu veux que les hosts aillent chercher la conf, du coup tu supprimes la liste d'attente mais tu as un agent... Pour le CD avec gitlab voir spinnaker plutôt.  
 
Mais si tu as aucun outil de gestion, pour moi Ansible c'est le plus abordable dans un premier temps.

Salt est relativement simple aussi en terme d'accessibilité (possibilité d'utiliser salt-ssh si tu veux pas d'agent dans un premier temps)

 
oui surement, je connais très mal terraform car ma boite utilise encore principalement du "on premise", du pseudo cloud privé, et vient seulement de nous pousser des projets vers du cloud public (enfin, du cloud public mouture maison ...)
Je suis en train de m'y former sur la linuxacademy
 
Pour en revenir au métier et faire un peu de mylife, j'ai reçu une offre intéressante de "builder" de plateformes sous AWS/GCP/Azure, et la boite me paye les certifs sur les 3 avant de me lancer dans l'eau du bain (faut dire que je pars de loin). Je suis pas sûr que ça va me botter à long terme de perdre un peu la main et d'utiliser des API et des briques managées par d'autres (db as a service, kubernetes as a service etc.) plutot que rester sur des plateformes ou j'ai la main à bas presque de A à Z (enfin, on va dire juste après la couche virtualisation, je m'occupe pas de l'exploitation de vmware / openstack), mais j'ai l'impression que ma boite actuelle veut aussi faire de moins en moins d'infra, et que je vais la perdre de toute façon, donc...  
 
Et le salaire c'est presque 10k de plus avec du full remote possible  

 
ça sera plus porteur sur le marché du travail c'est certain, 10k de + mais tu es à combien et quel région... je viens de faire cette migration donc je suis curieux de voir  

10k de plus et certif, au pire tu changes à  nouveau après  

 
je suis en province (bordeaux) donc rien de mirobolant ... en gros je suis à 42 et ils me proposent 50. Par contre j'ai quelques primes (interessement, participation etc.) dont je ne connais pas encore la teneur là-bas.