Comment gérer efficacement plusieurs installations d'une application Web?

StackOverflow https://stackoverflow.com/questions/502774

Question

D'après mon expérience, l'un des plus gros problèmes que nous avons rencontrés au cours de notre processus de développement Web consiste à maintenir différentes configurations mises à jour et sécurisées sur différents serveurs.

Ma société possède son propre CMS, actuellement installé sur plus de 100 serveurs. Pour le moment, nous utilisons une approche basée sur le FTP bidon, combinée à des scripts de mise à niveau à des emplacements spécifiques pour mettre à niveau toutes les configurations de notre CMS. La gestion efficace de ces configurations devient de plus en plus difficile et risquée lorsque plusieurs modules personnalisés sont impliqués.

  • Quel est le meilleur moyen de garder plusieurs configurations d'une application Web sécurisées et à jour?
  • Comment vous le faites-vous?
  • Existe-t-il des conseils spécifiques concernant la modularité des applications, afin de conserver une flexibilité vis-à-vis de nos clients, tout en restant en mesure de gérer efficacement plusieurs & "; branches &"; d'une application?

Quelques informations contextuelles: nous développons principalement sur la pile LAMP. L'un des principaux facteurs qui nous aide à vendre notre système de gestion de contenu est que nous pouvons brancher à peu près tout ce que nos clients veulent. Cela peut aller de 10 à 10 000 lignes de code personnalisé.

Un grand nombre de travaux personnalisés se composent de très petits morceaux de code. La gestion de tous ces petits morceaux de code dans Subversion me semble assez fastidieuse et inefficace (puisque nous livrons environ deux sites Web chaque semaine, il en résulterait un lot de branches).

S'il y a quelque chose que je néglige, j'aimerais beaucoup l'entendre de votre part.

Merci d'avance.

Roundup: tout d'abord, merci pour toutes vos réponses. Tout cela est vraiment utile.

Je vais très probablement utiliser une approche SVN, qui rend la solution de benlumley plus proche de celle que j'utiliserai. . Étant donné que la réponse à cette question peut différer dans d'autres cas d'utilisation, j'accepterai la réponse avec le plus grand nombre de voix à la fin du tour.

Veuillez examiner les réponses et voter pour celles qui, selon vous, ont la plus grande valeur ajoutée.

Était-ce utile?

La solution

Je pense utiliser un système de contrôle de version et & "Branching &"; la partie des codes que vous devez modifier pourrait s'avérer être la meilleure approche en termes de robustesse et d'efficacité.

Un système de version distribuée pourrait être le mieux adapté à vos besoins, car il vous permettrait de mettre à jour votre " noyau " fonctionnalités de manière transparente sur différentes " branches " tout en conservant si nécessaire des modifications locales.

Modifier: Je suis presque certain que maintenir tout cela à jour avec un système de version distribuée serait beaucoup moins fastidieux que ce que vous semblez attendre: vous pouvez conserver les modifications que vous êtes sûr de vous Nous n’aurons jamais besoin d’autre local, et l’aspect distribué signifie que chacune de vos applications déployées est en réalité indépendante des autres et que seul le correctif que vous voulez propager propagera.

Autres conseils

Si la personnalisation de votre application implique de modifier de nombreux petits morceaux de code, cela peut indiquer que la conception de votre application est défectueuse. Votre application doit avoir un ensemble de code principal stable, des points d'extensibilité pour les bibliothèques personnalisées à brancher, la possibilité de modifier l'apparence à l'aide de modèles et la possibilité de modifier le comportement et d'installer des plugins à l'aide de fichiers de configuration. De cette manière, vous n'avez pas besoin d'une branche SVN distincte pour chaque client. Conservez normalement le code source et les bibliothèques de plug-in d'extension dans le contrôle de code source. Dans un autre référentiel, créez un dossier pour chaque client et conservez tous ses modèles et fichiers de configuration.

Pour le moment, la création de branches SVN peut être la seule solution permettant de préserver votre santé mentale. Dans votre état actuel, il est presque inévitable que vous commettiez une erreur et que vous gâchiez le site d'un client. Au moins avec les succursales, vous avez la garantie d'avoir une base de code stable pour chaque client. Le seul problème avec les branches SVN est que si vous déplacez ou renommez un fichier dans une branche, il est impossible de fusionner ce changement dans le coffre (vous devez le faire manuellement).

Bonne chance!

EDIT: pour obtenir un exemple d'application bien conçue utilisant tous les principes décrits ci-dessus, voir Magento E-Commerce. . Magento est l'application Web la plus puissante, la plus extensible et la plus facile à personnaliser avec laquelle j'ai travaillé jusqu'à présent.

Je me trompe peut-être, mais il me semble qu'Aron est après pas le contrôle de version. La gestion des versions est excellente, et je suis sûr qu'ils l'utilisent déjà, mais pour gérer des mises à jour sur des centaines d'installations personnalisées, vous avez besoin de quelque chose d'autre.

Je pense à un système de package spécialement conçu . Vous souhaiterez que chaque version d'un module garde la trace de ses dépendances individuelles et de ses "compatibilités garanties", et utilisera ces informations pour mettre à jour automatiquement uniquement les modules "sûrs".

E.g. Supposons que vous ayez construit une nouvelle version 3 de votre module "Wiki". Vous souhaitez propager la nouvelle version à tous les serveurs exécutant votre application, mais vous avez apporté des modifications à l'une des interfaces du module Wiki depuis la version 2. Désormais, pour toutes les installations par défaut, ce n'est pas un problème, mais cela casserait installations avec extensions personnalisées sur l'ancienne interface. Un système de colis bien planifié s’occuperait de cela.

Pour répondre à la question de sécurité, vous devez utiliser des signatures numériques sur vos correctifs. Il y a beaucoup de bonnes bibliothèques disponibles pour les signatures basées sur des clés publiques, alors n'utilisez que ce qui semble être la norme pour votre plate-forme choisie.

Je ne sais pas si quelqu'un a dit cela, il y a beaucoup de longues réponses ici, et je ne les ai pas toutes lues.

Je pense qu'une meilleure approche de votre contrôle de version consisterait à installer votre système de gestion de contenu seul dans son propre référentiel et chaque projet séparément. (ou, tous ceux-ci pourraient être des sous-dossiers dans un rapport, je suppose)

Vous pouvez ensuite utiliser son tronc (ou une branche / balise spécifique si vous préférez) en tant que svn: external dans chaque projet le nécessitant. De cette manière, toutes les mises à jour que vous apportez au CMS peuvent être validées dans son référentiel et seront intégrées à d'autres projets au fur et à mesure de leur mise à jour (ou l'externe est svn: switch 'ed).

Pour faciliter cela, vous devrez vous assurer que le CMS et les fonctionnalités personnalisées sont placés dans des dossiers différents, afin que svn externals fonctionne correctement.

IE: 

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(si nécessaire, vous pourriez avoir cms et lib sous le dossier www)

Cela vous permettra de relier / marquer chaque projet comme vous le souhaitez. Vous pouvez également changer l’emplacement svn: external sur une base par branche / balise.

En ce qui concerne les modifications effectives, je vous conseillerais de vous débarrasser immédiatement de ftp et d’utiliser rsync ou svn checkout / exports. Les deux fonctionnent bien, le choix est à vous.

Je connais le mieux la route rsync, en synchronisant une exportation SVN sur le serveur. Si vous suivez cette voie, écrivez quelques scripts shell et créez un script de test pour vous montrer les fichiers qu'il téléchargera sans les télécharger, à l'aide de l'indicateur -n. J'utilise généralement deux scripts pour chaque environnement: un test et un autre pour le faire.

L’authentification par clé partagée, de sorte que vous n’avez pas besoin de mot de passe pour envoyer des téléchargements peut également être utile, en fonction de la sécurité du serveur auquel l’accès est accordé.

Vous pouvez également gérer un autre script de shell pour effectuer des mises à niveau en masse. Ce script appelle simplement le script de shell correspondant à chaque projet à mettre à niveau.

Avez-vous regardé Drupal? Non, pas pour déployer et remplacer ce que vous avez, mais pour voir comment ils gèrent les personnalisations et les modules spécifiques à un site?

En gros, il existe un " sites & "; dossier qui a un répertoire pour chaque site que vous hébergez. Dans chaque dossier se trouve un fichier settings.php distinct qui vous permet de spécifier une base de données différente. Enfin, vous pouvez (facultativement) avoir & Quot; themes & Quot; et " modules " dossiers au sein de sites.

Cela vous permet de personnaliser certains modules de sites spécifiques et de limiter certains modules à ces sites. En conséquence, vous vous retrouvez avec un site dont la grande majorité est parfaitement identique et seules les différences sont dupliquées. Combinez cela avec la façon dont il gère les mises à niveau et les mises à jour et vous obtiendrez un modèle viable.

Intégrez dans le code un processus de mise à jour automatique.
Il recherchera les mises à jour et les exécutera quand / où / comment vous les avez configurées pour le client.

Vous devrez créer une sorte de liste de modules (personnalisés ou non) qui doivent être testés avec la nouvelle version avant leur déploiement. Lors du déploiement d'une mise à jour, vous devez vous assurer que celles-ci sont testées et intégrées correctement. J'espère que votre conception pourra gérer cela.

Les mises à jour sont idéalement quelques étapes clés.

  1. a) Sauvegardez pour pouvoir revenir en arrière. Vous devriez pouvoir revenir en arrière. la mise à jour complète à tout moment. Alors, cela signifie créer une archive locale de l'application et de la base de données premier.

    b) Processus de surveillance de la mise à jour : demandez au système téléphonique du système de gestion de la maison de rechercher une nouvelle version.

    c) Planifier la mise à jour de la disponibilité - il est fort probable que vous ne souhaitiez pas que la mise à jour soit exécutée à la seconde où elle est disponible. Cela signifie que vous devrez créer un cron / agent quelconque pour que le système se mette à jour automatiquement au milieu de la nuit. Vous pouvez également prendre en compte les exigences du client pour la mise à jour le week-end ou certains jours. Vous pouvez également échelonner le déploiement de vos mises à jour pour ne pas mettre à jour 1 000 clients en un jour et obtenir un support technique incroyable. Un déploiement échelonné peut être bénéfique pour vous.

    d) Ajouter le mode maintenance pour mettre à jour le site - Lancez le site en mode maintenance.

    e) Extraction SVN ou packages téléchargeables : idéalement, vous pouvez effectuer le déploiement via svn checkout. Sinon, configurez votre serveur pour qu'il fournisse les packages générés par svn dans une archive pouvant être déployée sur les sites clients.

    f) Déployer des scripts de base de données : sauvegardez les bases de données, mettez-les à jour, remplissez-les

    g) Mettre à jour le code du site : tout ce travail s’effectue en une étape.

    h) Exécuter des tests dessus. Si votre code comporte des autotests intégrés, il serait idéal.

Voici ce que je fais ...

Chemin d'inclusion spécifique au client

  • Le code commun est partagé dans version partagée / actuelle / lib /
  • Le code spécifique au site se trouve dans clients / foo.com / lib
    • .
  • Le chemin d'inclusion est défini pour inclure à partir de clients / foo.com / lib , puis share / lib
  • Le tout est dans un système de contrôle de version

Cela garantit que le code utilise des fichiers partagés dans la mesure du possible, mais si je dois remplacer une classe ou un fichier particulier pour une raison quelconque, je peux écrire une version client spécifique dans leur dossier.

Fichiers communs d'alias

La configuration de mon hôte virtuel contiendra une ligne comme 

Alias /common <path>/shared/current_version/public_html/common

Ce qui permet le partage d'éléments de l'interface utilisateur, d'icônes, etc. communs entre projets

Marquez le code commun avec chaque version du site

Après chaque publication du site, je balise le code commun en créant une branche pour geler efficacement ce point dans le temps. Cela me permet de déployer / shared / version_xyz / sur le serveur live. Ensuite, je peux demander à un hôte virtuel d’utiliser une version particulière des fichiers communs ou de le laisser pointer sur la version en cours si je souhaite qu’il récupère les dernières mises à jour.

Avez-vous examiné des outils tels que Puppet (pour l'administration du système, y compris le déploiement d'applications) ou < a href = "http://www.capify.org/" rel = "nofollow noreferrer"> Capistrano (déploiement d'applications dans RubyOnRails, mais sans s'y limiter)?

Une option serait de configurer un système de contrôle de version en lecture seule (Subversion). Vous pouvez intégrer l'accès au référentiel à votre CMS et appeler les mises à jour via un menu, ou automatiquement si vous ne souhaitez pas que l'utilisateur ait le choix d'une mise à jour (elle peut être critique). L'utilisation d'un système de contrôle de version vous permettrait également de conserver facilement différentes branches

Comme on l'a déjà mentionné, utiliser le contrôle de version (je préfère Subversion pour des raisons de fonctionnalité) et la création de branches seraient la meilleure option. Un autre logiciel open source disponible sur sourceforge appelé cruisecontrol. C'est incroyable, vous configurez cruisecontrol avec subversion de manière à ce que toute modification de code ou tout nouveau code ajouté dans serversion, le régulateur de vitesse le sache automatiquement et le construise à votre place. Cela vous fera gagner du temps.

J'ai fait la même chose dans mon entreprise. nous avons quatre projets et devons déployer ce projet sur différents serveurs. J'ai configuré cruiseconrol de telle sorte que toute modification de la base de code déclenche la construction automatique. et un autre script déploiera cette construction sur le serveur. vous êtes prêt à partir.

Si vous utilisez une pile LAMP, je transformerais certainement les fichiers de solutions en un paquet de votre distribution et l’utiliserais pour propager les modifications. Je recommande d'ailleurs Redhat / Fedora à cause de RPM et c'est ce que j'ai déjà expérimenté. Quoi qu’il en soit, vous pouvez aussi utiliser n’importe quelle distribution basée sur Debian.

Il y a quelque temps, j'ai créé une solution LAMP pour la gestion des serveurs d'hébergement de fournisseurs de services Internet. Ils avaient plusieurs serveurs pour s'occuper de l'hébergement Web et j'avais besoin d'un moyen de déployer les changements de mon responsable, car chaque machine était autonome et disposait d'un responsable en ligne. J'ai créé un paquet RPM contenant les fichiers de solution (php principalement) et des scripts de déploiement exécutés avec RPM.

Pour la mise à jour automatisée, nous avions notre propre référentiel RPM défini sur chaque serveur du fichier yum.conf. J'ai défini un travail crontab pour mettre à jour les serveurs quotidiennement avec les derniers RPM de ce référentiel approuvé.

La confiance peut également être obtenue, car vous pouvez utiliser des paramètres de confiance dans les packages RPM, tels que les signer avec votre fichier de clé publique et n'accepter que les packages signés.

Hm pourrait-il être une idée d'ajouter des fichiers de configuration? Vous avez écrit que beaucoup de petits scripts font quelque chose. Maintenant, si vous les construisez dans les sources et les dirigez avec des fichiers de configuration, cela ne devrait pas & "Faciliter &"; cette?

D'autre part, avoir des succursales pour chaque client me semble être une croissance exponentielle. Et comment & Sauriez-vous & Quot; quels domaines vous avez fait quelque chose et n'oubliez pas de & "faire &"; changements dans toutes les autres branches également. Cela me semble assez moche.

Il semble qu'une combinaison de contrôles de révision, d'options de configuration et / ou de reçus de déploiement semble être un & "bon &"; idée .....

Avec toutes ces variantes de votre logiciel principal, je pense que vous avez vraiment besoin d'un système de contrôle de version pour rester en mesure de transmettre les mises à jour du tronc aux sites clients individuels.

Donc, si vous pensez que Subversion serait fastidieux, vous avez une bonne idée de ce que seront les points douloureux ... Personnellement, je ne recommanderais pas Subversion pour cela, car ce n'est pas vraiment bon pour gérer amp; suivi des branches. Bien que la suggestion de benlumley d’utiliser des externes pour votre logiciel principal soit une bonne suggestion, elle s’effondre si vous devez modifier le code principal de vos sites clients.

Regardez dans Git pour le contrôle de version, il est conçu pour créer des branches et il est rapide.

Découvrez Capistrano pour gérer vos déploiements. C'est un script ruby, souvent utilisé avec Rails, mais il peut être utilisé pour toutes sortes de gestion de fichiers sur des serveurs distants, même sur des sites non ruby. Il peut acheminer le contenu vers l'extrémité distante via différentes stratégies, notamment ftp, scp, rsync, ainsi que l'extraction automatique de la dernière version de votre référentiel. Les fonctionnalités intéressantes fournies incluent des points de rappel pour chaque étape du processus de déploiement (par exemple, vous pouvez donc copier les fichiers de configuration spécifiques à votre site qui risquent de ne pas être sous contrôle de version), et un système de journalisation des versions (réalisé via des liens symboliques). peut rapidement revenir à une version précédente en cas de problème.

Je recommanderais un fichier de configuration avec la liste des branches et leur emplacement hébergé, puis exécutez-le avec un script qui extrait chaque branche à son tour et télécharge les dernières modifications. Cela pourrait être fait pour faire des mises à jour nocturnes automatiquement.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top