Meilleures pratiques pour le déploiement d'outils et de scripts en production?

Question

J'ai un certain nombre de processus par lots qui fonctionnent en coulisses pour un site web Linux/PHP. Ils commencent à croître en nombre et en complexité, alors je veux apporter une petite quantité de processus pour les supporter.

Mon arborescence contient un tas de fichiers et de scripts cpp, organisés en fonction du développement mais pas du déploiement. Après avoir compilé tous les exécutables, j'ai besoin de mettre différents scripts et binaires sur un cluster de machines. Différentes machines ont besoin d'exécutables, de scripts et de fichiers de configuration différents pour leurs processus de traitement par lots. J'ai aussi quelques outils que j'ai écrits qui appartiennent à chaque machine. À l'heure actuelle, ce processus de déploiement est manuel et sujet aux erreurs.

Je devine que je vais finir avec un script qui va à la racine de l'arbre source et construit un petit arbre de tout le nécessaire pour l'une des machines. Ensuite, je vais juste rsync cela aux machines appropriées. Mais je suis curieux de savoir comment d'autres personnes gèrent ce type de problème. Des idées? Créez vos propres packages dans le format utilisé par votre distribution, par exemple,

Answer 1

Paquets Debian (.deb). Ceux-ci peuvent être copiés sur chaque machine et installés manuellement, ou vous pouvez configurer votre propre référentiel, et l'ajouter à votre liste de sources.

Vos colis doivent être mis en place afin que les scripts qu'ils contiennent consulter un fichier de configuration, qui est différent sur chaque hôte, selon ce que doivent être exécutés sur chaque script. Pour lier le tout, vous pouvez créer un méta-package qui dépend de chacun des autres packages que vous créez. De cette façon, lorsque vous configurez un nouveau serveur, vous installez ce méta-paquet et les autres paquets sont amenés en tant que dépendances.

Bien que ce processus semble un peu compliqué, si vous avez beaucoup de scripts et de nombreux hôtes de les déployer pour, il peut vraiment rentable à long terme.

Answer 2

Je dois déployer des scripts PHP et des configurations Apache à plusieurs clients fréquemment. Comme ils utilisent tous Debian Linux, j'ai installé un référentiel de paquets Debian sur mon serveur et tout ce que le client a à faire est de taper apt-get upgrade et ils obtiennent la dernière version.

Answer 3

Jetez un oeil à la cfengine tutorial pour voir si cfengine ressemble l'outil pour votre situation. C'est peut-être un peu trop compliqué pour un petit site web, mais si cela implique plus d'ordinateurs et plus de configuration à l'avenir, vous finirez par utiliser cfengine ou quelque chose comme ça.

Answer 4

La première chose à faire est d'obtenir tous ces scripts dans un référentiel de contrôle de code source (svn ou git sont bonnes) afin que vous puissiez suivre les modifications apportées à ces scripts au fil du temps. Si vous êtes intéressé par ruby, consultez Capistrano, il est bien adapté à déployer des choses à plusieurs machines dans un cluster, et est assez facile à configurer. Il peut lire les fichiers directement à partir de votre système de contrôle de version.

Answer 5

Puppet est un autre outil qui peut être utilisé dans cette situation. Il est semblable à cfengine - vous créez un modèle du déploiement désiré et des figures de marionnettes comment obtenir l'environnement à cet état.

Answer 6

Il existe plusieurs catégories d'outils ici. Certaines personnes utilisent une combinaison d'outils de ces catégories. J'utilise parfois, par exemple, à la fois Puppet et Capistrano. Voir Puppet or Capistrano - Use the Right Tool for the Job pour une discussion.

Outils de script destiné à déployer une application:

Le schéma général des outils dans cette catégorie est que vous créez un script et/ou d'un fichier de configuration, souvent avec des ensembles de commandes similaires à un Makefile, et L'outil va passer à votre boîte de production, faire un contrôle de votre source et exécuter toutes les autres étapes nécessaires.

Les outils dans cette zone disposent généralement d'installations permettant de restaurer une version précédente. Ils vont donc vérifier votre source dans le répertoire releases /, et créer un lien symbolique de "current" à "releases /" si tout se passe bien. S'il y a un problème, vous pouvez revenir à la version précédente en exécutant une commande qui supprimera "current" et le liera au répertoire/releases précédent.

• Capistrano provient de la communauté Rails mais est d'usage général. Les utilisateurs de Capistrano peuvent être intéressés par deprec, un ensemble de recettes de déploiement pour Capistrano.
• Vlad the Deployer est une alternative à Capistrano, encore une fois de la communauté Rails.
• Écrivez votre propre script shell ou Makefile.

pour obtenir les options des fichiers à la boîte de production:

• Finalisez votre commande de la source. Pas toujours possible si vos boîtes de production manquent d'outils de développement, en particulier d'outils de gestion de code source.
• Vérifiez la source localement, puis fermez le fichier zip/zip. Utilisez scp ou rsync pour copier l'archive tar. Ceci est parfois préféré pour quelque chose comme un déploiement Amazon EC2, où une archive tar compressée peut gagner du temps/de la bande passante.
• Extraire la source localement, puis la rediriger vers la boîte de production.

Outils d'emballage

Utilisez le système d'emballage de votre système d'exploitation pour générer des paquets contenant les fichiers de votre application. Créez un package principal ayant comme dépendances les autres packages dont vous avez besoin. Le système RubyWorks en est un exemple, utilisé pour déployer une pile Rails et un exemple d'application. Ensuite, il faut utiliser apt, yum/rpm, Windows msi ou autre pour déployer une version donnée. La restauration implique la désinstallation et la réinstallation d'une ancienne version.

Outils généraux Destinés à l'installation d'applications/configs et maintenance d'un ensemble de systèmes

Ces outils ne ciblent pas spécifiquement le problème du déploiement d'une application Web, mais le problème plus général du déploiement/maintien Apps/Configurations pour un ensemble de serveurs ou pour les postes de travail d'une entreprise entière. Ils s'adressent plus à l'administrateur système qu'au développeur Web, bien qu'ils puissent tous les trouver utiles.

• Cfengine est un outil de cette catégorie.
• Puppet vise à améliorer sur Cfengine. Il a une courbe d'apprentissage mais beaucoup trouvent qu'il vaut la peine de comprendre comment faire les configs. Une fois que vous l'avez fait, chaque boîte vérifie périodiquement le serveur central et s'assure que tout est à jour. Si quelqu'un modifie un fichier ou modifie une autorisation, celle-ci est détectée et corrigée.Donc, contrairement aux outils de déploiement ci-dessus, Puppet ne met pas seulement les fichiers au bon endroit pour vous, il assure qu'ils restent ainsi.
• Chef est un peu plus jeune que Puppet avec une approche similaire.
• Smartfrog est un autre outil dans cette catégorie.
• Ansible fonctionne avec les fichiers YAML simples et ne nécessitent pas d'agents en cours d'exécution sur les serveurs qu'il gère

Pour une comparaison de ces derniers et beaucoup plus d'outils dans cette catégorie, voir l'article de Wikipedia, Comparison of open source configuration management software.