Administration en vrac / à distance Linux

10

Outre notre infrastructure informatique interne, nous avons environ 500 machines Linux hébergeant nos services pour le monde en ligne. Ils sont regroupés dans un groupe de clusters comme Database An, Product An, NFS, Backoffice, etc. De plus, ils sont administrés par un prestataire externe, selon nos spécifications et exigences.

Cependant, nous rencontrons beaucoup de problèmes lors du développement, du déploiement et du déploiement de logiciels (Web), en particulier parce que les environnements de développement et de mise en scène n'ont presque rien en commun avec les systèmes en direct (j'épargne les détails désagréables ..) .

Ainsi, j'ai essayé de créer des machines virtuelles, j'ai copié les différents systèmes live aussi exactement que possible et les ai préparés à se connecter, par exemple, aux bases de données de développement au lieu des "vraies" de manière transparente pour les développeurs (ce n'est pas le cas root). Cela fonctionne plutôt bien, mais ...

Je me demandais comment on pouvait administrer ces systèmes à distance et en masse ? Y a-t-il une famille de logiciels que je ne connais pas? Ou, au moins, certaines techniques ou principes que l'on devrait connaître?

Nous fournirions à chaque développeur un tas d'images à exécuter localement (VirtualBox). Le département QA. obtiendrait des clusters virtuels (XEN ou Hyper-V). Si je dois fournir un module serveur supplémentaire, réacheminer une nouvelle connexion à la base de données ou simplement mettre à jour tout ce qui est fourni par le gestionnaire de paquets ... comment pourrais-je le faire sans être obligé de me connecter à chaque système et / ou demander à mes collègues de télécharger et d'exécuter un script de montage?

Je pense qu'il existe de nombreuses solutions. Eh bien, d'une manière ou d'une autre, je suis trop stupide pour entrer les bons mots clés dans les moteurs de recherche ... Ou ce problème n'est-il pas aussi trivial qu'il y paraît?

Pour mémoire:

  • Presque tous les systèmes exécutent Debian GNU / Linux 6.x "squeeze"
  • Aucun développeur n'est obligé d'utiliser un système d'exploitation particulier sur son poste de travail
  • Le budget est certes limité, mais pas trop petit pour acheter des logiciels propriétaires
  • Une solution qui impliquerait notre fournisseur susmentionné est préférée
mjhennig
la source

Réponses:

15

Cela dépend exactement de ce dont vous avez besoin et de ce que vous recherchez. Mais en général, il existe plusieurs solutions pour la " gestion de configuration " comme:

  1. fantoche
  2. chef
  3. cfengine
  4. ansible
  5. sel

etc. Je recommanderais personnellement la marionnette car elle a une grande communauté et beaucoup de recettes externes fournies. Cela vous permet de configurer et de gérer automatiquement les systèmes. Si vous combinez cela avec vos propres référentiels et mises à jour automatisées via, par exemple, unattended-upgradesvous pouvez mettre à jour automatiquement le système.

Une autre solution consiste simplement à fournir vos propres packages comme company-baseetc., qui dépendent automatiquement du logiciel nécessaire et peuvent configurer votre système automatiquement.

Vous devez également examiner les déploiements automatisés (barebone et virtualisés). Si vous combinez cela avec la gestion de la configuration ou votre propre référentiel, vous pouvez facilement automatiser et réinstaller vos systèmes. Si vous souhaitez commencer avec une installation automatisée, jetez un œil à theforman qui prend en charge libvirt ainsi que les installations nues et a un support de marionnettes intégré. Si vous voulez le faire vous-même, vous pouvez regarder dans kickstart (redhat et. Al.) Ou "préréglage" pour configurer automatiquement votre système. Pour Debian, vous pouvez également utiliser quelque chose comme debootstrap ou un wrapper nommé grml-debootstrap prenant en charge les images virtualisées.

Pour aider à fournir les images VirtualBox à votre développeur, jetez un œil à vagrant, cela vous permet d'automatiser la création de systèmes virtualisés avec VirtualBox prenant en charge les scripts chef, marionnette et shell pour personnaliser votre environnement virtuel.

Si vous souhaitez utiliser la solution par votre fournisseur existant, vous devez lui demander comment il gère vos systèmes, mais ce sera probablement une sorte de gestion de la configuration. Il peut être possible d'exécuter leur agent sur vos systèmes si vous pouvez accéder au serveur de configuration.

Pour les mots clés de Google se pencher sur devops, configuration management, it automationet server orchestration.

Bref, automatisez autant que possible et ne pensez même pas à faire des choses manuellement.

Ulrich Dangel
la source
1
Je vous remercie! C'est beaucoup de choses à lire, mais cela semble assez prometteur.
mjhennig
@mjhennig je viens d'ajouter quelques informations supplémentaires également. déploiement. Il existe de nombreuses ressources disponibles, mais le plus important, vous ne devriez pas vraiment faire des choses par vous-même via des shells ssh / distribués, mais avoir une sorte de système pour cela.
Ulrich Dangel
2
Il n'y a rien de mal à faire des choses par vous-même, surtout si les outils disponibles ne correspondent pas à l'objectif. Des systèmes comme Puppet sont en grande partie des outils d'administration système, et non une gestion de configuration en soi. Une grande majorité des systèmes que j'utilise ne sont même pas accessibles à partir d'un serveur central, mais à partir des ordinateurs portables des utilisateurs sur (de toutes choses) vpn - essayant de changer cela depuis trois ans. Notre service informatique est divisé par régions car chaque région ne peut pas accéder correctement à l'autre. Des scripts locaux sont nécessaires dans certaines situations. C'est aussi là que l'innovation commence.
Arcege
3
@Arcege je viens de voter pour votre commentaire, les scripts sont nécessaires et vous n'avez pas besoin de convertir toute votre infrastructure à la fois. La partie la plus importante est d'automatiser les choses et de les rendre reproductibles. Mais la nature descriptive de la marionnette et du chef a certains aspects uniques, par exemple, vous pouvez tester et vérifier les classes de marionnettes avec cucumber-puppet. Bien sûr, vous pouvez développer / développer votre propre cadre en réutilisant les composants existants, mais il semblait que OP n'a rien en place actuellement et si vous partez de zéro, je pense qu'il est préférable d'utiliser un cadre existant.
Ulrich Dangel
Oui, je suis d'accord avec les opérations automatisées / reproductibles. J'ai un certain nombre de scripts maison automatisés ou à bouton-poussoir pour interfacer entre les systèmes existants comme l'intégration Jenkins / Oc4j et Subversion / Bugzilla. Je n'étais tout simplement pas d'accord (fortement) avec votre commentaire "vous ne devriez pas vraiment faire des choses par vous-même". Parfois, les cadres existants ne sont pas applicables, comme dans ma situation, je l'ai décrit.
Arcege
3

Ulrich a déjà donné la réponse concernant le déploiement de logiciels et la configuration automatisée du serveur.

Les principes sous-jacents sont

  • Définissez l'apparence de vos serveurs - cela inclut les logiciels courants installés par défaut, le schéma de partitionnement et la disposition du système de fichiers
  • Les serveurs de production, de préparation, de test et de développement ne devraient pas différer en ce qui concerne ces normes de base (sinon vous rencontrerez des problèmes plus tard - comme vous l'avez fait)
  • Utilisez une gestion des changements appropriée pour documenter TOUTES les modifications que vous avez apportées (y compris les minuscules modifications d'une ligne dans n'importe quelle configuration)
  • Vous changez toujours d'abord en test, puis en développement, puis en mise en scène et enfin en production

Vous avez demandé un outil pratique pour gérer des masses de serveurs - mon préféré est cluster-ssh ( cssh). Tapez une fois et effectuez des modifications sur de nombreux serveurs simultanément.

Si vous découvrez un problème et avez un correctif pour le supprimer:

  1. Appliquez le correctif à Test / Dev / Staging / Prod (voir ci-dessus) si cela fonctionne vraiment
  2. Appliquez le correctif à vos modèles virtuels pour que les futurs clones VM n'aient pas ce bogue
  3. Appliquez le correctif à votre processus d'installation physique (kickstart / autoyast / autre)
  4. Appliquer le correctif à TOUS les serveurs

Si vous faites face à des masses de serveurs pour résoudre ce problème, c'est un processus qui doit être bien documenté et à la fin une autre équipe devrait vérifier si le correctif a été complètement appliqué.

Nous utilisons à cet effet Mantis (open source, PHP).

Nils
la source
2

Je gère environ 30 produits et quelques centaines de serveurs dans plusieurs pays. Je suis le gestionnaire de configuration logicielle, donc je n'ai pas d'accès root (par conception), je ne touche pas aux bases de données ou à leurs serveurs (encore une fois, par conception) et je dois sauter beaucoup de cerceaux à cause de la sécurité de l'entreprise. Mais je gère les configurations de test, de mise en scène et de production, y compris les liens et les modifications de base de données. J'ai un certain nombre de scripts qui vont vers les serveurs en utilisant des combinaisons de ssh, pythonet des scripts shell.

Les principales choses à penser sont:

  1. Quels types d'interactions allez-vous avoir avec vos serveurs? Juste des téléchargements de fichiers? Vous exécutez des programmes en ligne de commande? Vous exécutez des clients X distants?
  2. Quel niveau de sécurité est nécessaire pour accéder à ces serveurs? Pare-feu, réseaux sécurisés, VPN? Est-ce sshsuffisant et à partir d'un emplacement central sécurisé?
  3. Combien peut être automatisé sur chaque serveur? Pouvez-vous installer un programme sur chaque serveur et l'exécuter, ou avez-vous besoin de diffuser le programme via quelque chose comme sshpour l'exécuter à distance? Pouvez-vous l'écrire avec expectou simplement un appel en ligne de commande?

VirtualBox fournit de nombreux outils de ligne de commande que vous pouvez administrer via des sshsystèmes comme ou comme puppetle mentionne Ulrich.

Arcege
la source
2
Juste une petite suggestion concernant. virtualbox, jetez un œil à vagrantup.com, il peut simplifier et automatiser la création d'images virtuelles.
Ulrich Dangel
Malheureusement, même obtenir un accès réseau simple entre des environnements de test distants est presque impossible. La configuration d'une batterie de serveurs Virtualbox serait encore plus difficile. J'ai du mal à simplement demander au service informatique de mettre à jour le logiciel standard avec ce qui est obsolète depuis plus d'un an car il ne fait pas partie des référentiels «RedHat standard».
Arcege
Ce qui m'a aidé dans mon expérience avec un logiciel obsolète, c'est de montrer que le logiciel est soit en fin de vie, soit qu'il y a des problèmes de sécurité. La configuration / connexions réseau est souvent beaucoup plus difficile à réaliser, essayez peut-être de souligner comment la connexion des différents environnements de test permet d'économiser de l'argent, de simplifier les processus, de gagner du temps en AQ ou de rendre l'environnement de test plus réaliste. Cela pourrait également être utile si vous recrutiez des personnes des différentes succursales.
Ulrich Dangel