Automatisation du déploiement du serveur

Je trouve que je configure constamment des serveurs et VPS à peu près identiques pour un certain nombre de mes clients et cela peut prendre beaucoup de temps. Souvent, la seule chose qui change entre chaque déploiement est le site Web différent qui doit être servi. Existe-t-il un moyen facile d'automatiser tout cela et de prendre la monotonie ennuyeuse de la configuration de 56 serveurs identiques?

Les serveurs que j'ai déployés jusqu'à présent n'étaient que Ubuntu, mais il est possible que je commence à utiliser d'autres systèmes d'exploitation Linux ou même Windows. Jusqu'à présent, j'ai regardé Capistrano, mais il semble être axé sur l'écriture de petits programmes rubis pour faire le travail, et je n'ai aucune connaissance du tout

Puppet semble parfait pour ce que vous essayez de faire, avec la mise en garde qu'à l'heure actuelle, il n'y a pas de support pour Windows.

Dans votre cas, vous définiriez un nœud de serveur en termes de tous les packages identiques sur les machines. Ensuite, vous définissez les hôtes individuels en tant que nœuds héritant du serveur et configurez les éléments uniques spécifiques pour celui-ci.

Puppet est déclaratif - il vous permet de décrire vos boîtes en termes de ressources que chaque boîte devrait avoir. Donc, si vous voulez ssh- vous écrivez une classe pour cette ressource - et à l'intérieur de la classe, vous pouvez inclure une logique sur la façon dont ssh est appelé légèrement différent sur FreeBSD vs Ubuntu. Il sait également utiliser à l' yumintérieur de Redhat et à l' apt-getintérieur des distributions basées sur Debian, et portsdans les BSD. Maintenant, dans votre nœud de serveur, vous aurez juste une ligne comme include ssh- et la marionnette fera la bonne chose et mettra SSH sur la machine sans que vous ayez à vous rappeler si c'est Ubuntu ou Redhat ou FreeBSD.

Ce qui est bien, c'est que tous les éléments du serveur vivent au même endroit - et si à tout moment vous ajoutez à la définition du nœud du serveur, TOUTES les machines mettront à jour leur configuration en conséquence.

À l'heure actuelle, je ne gère que trois boîtes à l'aide de Puppet - mais c'est déjà payant. Après avoir passé une semaine à configurer une boîte que nous utiliserons pour la présentation de stimulus dans une expérience, il s'est avéré que le pilote de la carte graphique était trop ancien dans la version d'Ubuntu que j'ai mise dessus (8.04). J'ai dû installer la dernière version d'Ubuntu (9.04), mais après cela, je devais juste me procurer et exécuter des marionnettes - et tout ce que j'avais passé une semaine à configurer était restauré.

La marionnette a un peu de courbe d'apprentissage, mais j'ai réussi à éviter d'apprendre Ruby - je sais que je l'utilise, car c'est ce que la marionnette est écrite - mais jusqu'à présent, j'ai réussi à modifier les exemples dans la documentation et les recettes sur le wiki . Un autre inconvénient est que la marionnette prend un peu plus de temps pour faire les choses la première fois. L'avantage est que tout ce que vous modifiez sur toutes vos machines est stocké en un seul endroit - il est courant de conserver votre configuration de marionnettes dans un système de contrôle de version - afin que vous puissiez toujours regarder en arrière et voir comment vous avez configuré des serveurs dans le passé - ou annulez certaines modifications infructueuses.

Enfin, voici une vidéo rapide qui fait une simple démonstration de marionnettes qui m'a permis de démarrer rapidement.

Nous utilisons Cobbler et Puppet pour l'automatisation de la construction et de la configuration des machines réelles et virtuelles.

Cobbler relie DHCP, le démarrage PXE et Kickstart pour rendre le déploiement rien de plus que l'ajout d'un profil de machine et l'appui sur le bouton d'alimentation. Pour les machines virtuelles, la koan commande fait la magie (dans notre cas) de Xen pour démarrer l'installation - sur le dom0Je viens de taper:

koan --system vps.fqdn --server cobbler --no-gfx

puis virsh consoleregarder un bâtiment VPS sans aucune interaction.

Nous utilisons RHEL et avons un ensemble de profils mis en place pour partitionner les disques, configurer la mise en réseau et installer des packages de base pour différentes classes de serveurs. Cobbler prend en charge les races Debian et Ubuntu mais je ne l'ai jamais essayé. Un côté: d'autres utilisations intéressantes de Cobbler incluent l'exécution des ISO memtest et des mises à jour du firmware HP .

Une fois que nos systèmes sont construits avec Cobbler Puppet prend le relais pour configurer les applications, les démons système, enregistrer la boîte avec RHN, etc. Puppet fonctionne comme un démon qui vérifie périodiquement que la configuration des systèmes correspond aux manifestes définis - vous savez que vos mises à jour ont disparu à tous les serveurs. C'est également un excellent moyen de s'assurer qu'une boîte qui a été arrêtée pour maintenance a la configuration correcte avant de la remettre en service.

La marionnette est vraiment géniale. Vous n'avez pas besoin de contrôler tous les aspects de votre configuration - commencez par lui faire gérer quelque chose de simple que vous devez configurer sur chaque boîte ( sudoersc'est l'exemple canonique) et prenez-le à partir de là. Assurez-vous que vos manifestes Puppet sont également versionnés; rien de mieux que de pouvoir facilement revenir à une configuration connue sans avoir à se rappeler quoi régler.

Là où je travaille en ce moment, nous devons gérer la partie Linux de notre batterie de serveurs qui est un peu plus de 300 serveurs Linux. Cela comprend principalement HP Proliants, suivi par les IBM 3850, certaines lames IBM, VMware ESX et certains KVM pour nos serveurs de gestion internes.

cordonnier

Nous avons examiné le cordonnier, mais le problème était que le cordonnier est très spécifique à RHEL / Red Hat. Nous devons au moins prendre en charge RHEL et SLES, et Ubuntu est le suivant.

fantoche

Nous avons considéré la marionnette, mais nous avons décidé par la suite de ne pas l'utiliser car cela dépend de Ruby, ce qui signifie qu'une mise à niveau de Ruby pourrait potentiellement briser notre système de gestion.

fil chaud

Hotwire est ce que nous utilisons (développé en interne, mais est open-source), et ce depuis les dernières années. Il inventorie tout d'abord les systèmes qui vont être construits, ce qui signifie inventorier le centre de données, le rack, le matériel, le système d'exploitation, le réseau, etc., et ensuite effectuer la construction et le déploiement rapides. Une fois le système construit, l'inventaire automatique de hotwire maintient l'inventaire synchronisé, tandis que cfengine les maintient. Hotwire connaît le matériel du serveur en parlant aux données SMBIOS / DMI dans le BIOS via python-dmidecode .

Les points bonus sont qu'il combine l'inventaire et le processus de construction en un seul, donc il y a moins à gérer, et la fonction d'inventaire en direct est excellente car nous savons si quelque chose ne va pas bien.

Les inconvénients sont que l'interface utilisateur doit encore être polie, et il y a des bugs ici et là, mais le développement est toujours d'actualité et les bugs signalés sont corrigés relativement rapidement.

cfengine

Nous utilisons cfengine car à part ça, et marionnette, il n'y a rien d'autre. C'est en fait un bon outil, mais "bon" uniquement en fonction de la qualité de vos politiques - si vous définissez des politiques dangereuses, une petite erreur peut causer beaucoup de dégâts. Par exemple, par politique, nous ne «modifions» pas les fichiers, nous les remplaçons ou nous ne le faisons pas. Tous les fichiers remplacés ont également un en-tête qui permet à toute personne qui le modifie de savoir qu'il sera remplacé la prochaine fois qu'il s'exécutera (il est exécuté via cron toutes les heures).

La configuration et tous les fichiers envoyés par cfengine aux serveurs sont également conservés dans un SCM, et en utilisant des hooks post-commit, si possible, nous vérifions la syntaxe et si cela échoue, la validation est rejetée. C'est facile pour de belles applications comme Apache, mais pas si facile pour la plupart des applications d'entreprise.

J'ai eu du succès avec Puppet . Le chef est nouveau. Pour une liste plus longue des options et un tableau de comparaison, voir l'article Wikipedia, Comparaison des logiciels de gestion de configuration open source .

Pour automatiser l'installation en fonction du système cible:

• Debian / Ubuntu: FAI ou di préconfiguration
• Chapeau rouge / Fedora: Kickstart
• Novell / openSuSE: AutoYaST
• Solaris: Jumpstart
• Windows: unattended.sourceforge.net

Pour la gestion de la configuration, je suggère d'utiliser des marionnettes.

J'ai beaucoup de succès avec Puppet , mais vous devez écrire beaucoup de config.

Un autre vote pour Puppet ici. Nous l'utilisons largement pour effectuer toutes les installations et la gestion de la configuration des serveurs et des applications. Plus de 200 nœuds et comptage. Le support de Windows est apparemment en développement, mais dans quel état je ne suis pas sûr.

Nous examinons toujours le côté initial du bootstrap du système d'exploitation, mais comme mentionné ci-dessus, Cobbler semble intéressant. Nous utilisons actuellement un mélange de démarrage PXE avec une préconfiguration Debian / Ubuntu, mais ce n'est pas optimal.