Project

General

Profile

Actions

Demande #896

closed

Demande #973: gestion centralisée des configurations

évaluation et choix d'un outil d'administration centralisée / gestion de configuration

Added by Quentin Gibeaux over 12 years ago. Updated about 12 years ago.

Status:
Fermé
Priority:
Immédiate
Assignee:
Category:
Task
Target version:
Start date:
12/03/2011
Due date:
11/27/2012
% Done:

100%

Estimated time:
Spent time:
Difficulté:
3 Moyen

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


Related issues 1 (0 open1 closed)

Has duplicate Admins - Demande #855: Choisir un outil de gestion de configurationRejetéQuentin Gibeaux

Actions
Actions #1

Updated by theo _ over 12 years ago

Un guest chef a été installé ce week-end.

Actions #2

Updated by theo _ over 12 years ago

  • % Done changed from 0 to 50
Actions #3

Updated by theo _ over 12 years ago

  • Assignee changed from Quentin Gibeaux to Nicolas Vinot
Actions #4

Updated by Vincent-Xavier JUMEL over 12 years ago

Un guest chef a été installé ce week-end.

Peut-on avoir un vade-mecum de l'utilisation de chef ?

Actions #5

Updated by Nicolas Vinot over 12 years ago

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.

Sinon, un 1er retour par rapport à ce qu'on a vu ce week-end:
  • 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.

Actions #6

Updated by Vincent-Xavier JUMEL over 12 years ago

  • Target version set to April Camp septembre 2012
Actions #7

Updated by Loïc Dachary over 12 years ago

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 ;-)

Actions #8

Updated by Loïc Dachary about 12 years ago

  • Target version changed from April Camp septembre 2012 to Backlog
Actions #9

Updated by Loïc Dachary about 12 years ago

  • Category set to Task
  • Difficulté set to 2 Facile
Actions #10

Updated by Loïc Dachary about 12 years ago

  • Difficulté changed from 2 Facile to 3 Moyen
Actions #11

Updated by Loïc Dachary about 12 years ago

  • Subject changed from évaluation et choix d'un outil d'administration centralisée to évaluation et choix d'un outil d'administration centralisée / gestion de configuration
  • Parent task set to #973
Actions #12

Updated by Loïc Dachary about 12 years ago

  • Start date changed from 06/22/2012 to 12/03/2016
Actions #13

Updated by Loïc Dachary about 12 years ago

  • Assignee changed from Nicolas Vinot to theo _

En attente d'un arbitrage chef / puppet

Actions #14

Updated by Loïc Dachary about 12 years ago

  • Target version changed from Backlog to Novembre 2012
Actions #15

Updated by Loïc Dachary about 12 years ago

  • Due date set to 11/27/2012
  • Start date changed from 12/03/2016 to 12/03/2011
  • % Done changed from 50 to 90
Actions #16

Updated by Loïc Dachary about 12 years ago

http://framadate.org/s1tojxdzzno7vot4
Chef étant seulement connu par une personne il ne reste que puppet en lice, oui ?

Actions #17

Updated by Loïc Dachary about 12 years ago

  • Status changed from Nouveau to En cours de traitement
Actions #18

Updated by Nicolas Vinot about 12 years ago

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 =)

Actions #19

Updated by Loïc Dachary about 12 years ago

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 ;-)

Actions #20

Updated by Nicolas Vinot about 12 years ago

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

Actions #21

Updated by Loïc Dachary about 12 years ago

Quelle décision est prise ?

Actions #22

Updated by theo _ about 12 years ago

  • Status changed from En cours de traitement to Fermé
  • % Done changed from 90 to 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.

Actions #23

Updated by Loïc Dachary about 12 years ago

  • Priority changed from Normale to Immédiate
Actions

Also available in: Atom PDF