Demande #896
ferméDemande #973: gestion centralisée des configurations
évaluation et choix d'un outil d'administration centralisée / gestion de configuration
Ajouté par Quentin Gibeaux il y a plus de 12 ans. Mis à jour il y a presque 12 ans.
Description
évaluation d'une solution d'administation centralisée des machines du local de l'april : celle-ci permettera de gérer plus proprement les configurations de chaque machines, en gardant des traces et permettre de faire des mises à jour plus facilement.
Outils en discussion : Puppet, Chef et cfengine
Mis à jour par theo _ il y a plus de 12 ans
- Assigné à changé de Quentin Gibeaux à Nicolas Vinot
Mis à jour par Vincent-Xavier JUMEL il y a plus de 12 ans
Un guest chef a été installé ce week-end.
Peut-on avoir un vade-mecum de l'utilisation de chef ?
Mis à jour par Nicolas Vinot il y a plus de 12 ans
Il est prévu que je mette à dispo les sources de la conf, il manque juste un dépôt git.
Pour l'utilisation courante de chef, voir leur excellent wiki.
- Vu la complexité de ce qu'il y a besoin pour l'April (par exemple un resolv.conf dépendant de qui est son host et de tous les autres hosts), Chef est juste fait pour, Puppet ou CfEngine seraient juste à la ramasse (conf trop statique)
- Truc clairement pas top et dont je n'avais pas forcément fait attention, tout le trafic Chef est en clair. Il faudra monter un Nginx en frontal pour SSLiser et/ou tout passer uniquement par le VPN (quand il sera là).
À terme je pense qu'il est possible de gérer pas mal de choses en conf.
Mis à jour par Vincent-Xavier JUMEL il y a plus de 12 ans
- Version cible mis à April Camp septembre 2012
Mis à jour par Loïc Dachary il y a environ 12 ans
Je recommande puppet parceque c'est un outil addossé à une entreprise qui prend soin de sa communauté (puppetlabs). A contrario, opscode qui est l'entreprise derrière chef est beaucoup plus dans un modèle corporate et ses actions sont essentiellement destinées à satisfaire les besoins de l'industrie. Le choix est d'autant moins évident que chef est fait par des anciens de puppet : on a pas l'impression de faire face à deux technologies différentes. Durant toute l'année 2012 j'ai eu l'occasion de beaucoup cotoyer la communauté puppet et d'observer chef et opscode: c'est sur cette expérience que je fonde ma recommendation.
Par ailleurs je travaille pour une entreprise qui utilise quotidiennement puppet, j'ai donc accès à une expertise forte sur cet outil, ce qui n'est pas le cas pour puppet. C'est un atout à prendre en compte ;-)
Mis à jour par Loïc Dachary il y a environ 12 ans
- Version cible changé de April Camp septembre 2012 à Backlog
Mis à jour par Loïc Dachary il y a environ 12 ans
- Catégorie mis à Task
- Difficulté mis à 2 Facile
Mis à jour par Loïc Dachary il y a environ 12 ans
- Difficulté changé de 2 Facile à 3 Moyen
Mis à jour par Loïc Dachary il y a environ 12 ans
- Sujet changé de évaluation et choix d'un outil d'administration centralisée à évaluation et choix d'un outil d'administration centralisée / gestion de configuration
- Tâche parente mis à #973
Mis à jour par Loïc Dachary il y a environ 12 ans
- Début changé de 22/06/2012 à 03/12/2016
Mis à jour par Loïc Dachary il y a environ 12 ans
- Assigné à changé de Nicolas Vinot à theo _
En attente d'un arbitrage chef / puppet
Mis à jour par Loïc Dachary il y a environ 12 ans
- Version cible changé de Backlog à Novembre 2012
Mis à jour par Loïc Dachary il y a environ 12 ans
- Echéance mis à 27/11/2012
- Début changé de 03/12/2016 à 03/12/2011
- % réalisé changé de 50 à 90
Mis à jour par Loïc Dachary il y a environ 12 ans
http://framadate.org/s1tojxdzzno7vot4
Chef étant seulement connu par une personne il ne reste que puppet en lice, oui ?
Mis à jour par Loïc Dachary il y a environ 12 ans
- Statut changé de Nouveau à En cours de traitement
Mis à jour par Nicolas Vinot il y a environ 12 ans
OK pour moi si on part sur du Puppet.
Par contre, est-ce qu'on aurait pas intérêt à étudier un peu la faisabilité de l'un et de l'autre dans le contexte de l'APRIL ?
Choisir un outil parce que des gens ont de l'XP dans un contexte et une complexité peut-être totalement différents de ceux de l'APRIL, ça serait con au final de choisir tout pile la solution qui s'adapte le moins à notre besoin :þ
Juste pour exemple, alors que je suis pourtant plutôt dans la catégorie « maîtrise » de chef (2 prods + contributeur), j'ai du juste foutre à la poubelle toutes mes recettes existantes et les recoder from scratch dans ma tenta de monter une config de test « APRIL », en particulier pour gérer les dépendances host/guest + VPN (le resolver DNS d'un guest est l'IP du guest dns du host de la machine concernée, suivi de l'IP du host, suivi de l'IP de tous les autres hosts…), sans monter une usine-à-gaz de configs manuelles.
C'est aussi pour ça qu'au final je suis agnostique chef/puppet pour notre choix, j'ai l'impression que dans un cas comme dans l'autre, on va juste commencer totalement à poil =)
Mis à jour par Loïc Dachary il y a environ 12 ans
Pour la génération de resolv.conf je pense qu'on a bien meilleur compte de traiter des fichiers statiques ( il y a 2 resolv.conf pour toute la plateforme, on va pas se noyer ;-)
Mis à jour par Nicolas Vinot il y a environ 12 ans
J'ai pris cet exemple parce que c'est un des plus simples.
J'ai aussi le même problème pour le relay mail, les proxies nginx, les mysql si on les consolide, les pare-feux…
On peut aussi ajouter la génération auto des champs SPF en fonction de nos machines réellement outgoing-mail, de nos champs SSHFP à partir de nos serveurs SSH, la gestion de notre MX, etc.
Et le problème est encore pire si on veut faire de la vraie intégration continue :
<_aeris_> si on a de la conf statique, on risque d'avoir une conf de prod et une conf pour la c-i
<_aeris_> sauf si tu garantis qu'on est capable d'avoir strictement la même conf réso en c-i, aux ips et routes près
<_aeris_> c'est à dire que si la c-i dit « vert », on doit pouvoir prendre la conf de la c-i et l'appliquer telle quel sur la prod
<_aeris_> si on commence à avoir besoin de la reprendre à la main, au final on a pas du tout tester que ça continuera à fonctionner en prod
<_aeris_> on a très bien pu oublier de modifier un resolv.conf, ou fait une coquille
<_aeris_> et se bouffer un bon gros « rouge » sur la prod
Mis à jour par theo _ il y a environ 12 ans
- Statut changé de En cours de traitement à Fermé
- % réalisé changé de 90 à 100
On part sur puppet qui est le seul outil qui est maitrisé par plusieurs personnes et qui, à priori, permet de faire la même chose que chef dans notre contexte.
Mis à jour par Loïc Dachary il y a presque 12 ans
- Priorité changé de Normale à Immédiate