Question Déploiement de la production vers EC2 avec un temps d'arrêt minimal


J'ai une application Web simple déployée sur une grande instance avec EC2. Je souhaite maintenant déployer le code le plus récent sur ce serveur, mais de manière à minimiser les temps d'arrêt et à simplifier au maximum la tâche de l'utilisateur final. Voici mon plan:

  1. Lancez une autre grande instance
  2. Installer toutes les couches logicielles sur cette instance
  3. Restaurer et attacher un lecteur EBS à l'instance
  4. Déployez notre dernier code prêt pour la production sur la nouvelle instance
  5. Exécuter tous les tests (y compris les tests manuels de l'application)
  6. (Si les tests réussissent) Mettez un avis de "Site en maintenance" sur le site en direct.
  7. Sauvegarder l'instance EBS sur le site actif
  8. Détachez l'instance EBS du nouveau serveur et remplacez-la par la dernière sauvegarde
  9. Utilisez ec2-associate-address pour déplacer l'adresse IP vers la nouvelle instance
  10. Asseyez-vous et attendez que le trafic commence à circuler à travers la nouvelle instance
  11. Termine l'ancienne instance

Cela vous semble-t-il une bonne stratégie? Existe-t-il des tutoriels ou des livres pouvant couvrir ce sujet? J'ai déjà lu Cloud Application Architectures de George Reese, un excellent livre, mais qui ne couvre pas le déploiement. De plus, je sais qu'il existe des outils qui peuvent aider à cela, comme RightScale ou enStratus, que j'utiliserai lorsque je commencerai à utiliser plusieurs instances.


7
2018-06-10 02:15


origine


Votre instance est-elle Windows ou Linux? Est-ce que l'EBS est votre volume de démarrage? La pile de logiciels est-elle installée sur le volume EBS ou sur un volume séparé? Essayer d'obtenir un coup de la terre. - John Virgolino
Bonjour John, Nous utilisons Linux (serveur Ubuntu 9.04), EBS n’est pas le volume de démarrage, mais une pile logicielle tierce installée sur un stockage éphémère, notre application sur le volume EBS. - jensendarren


Réponses:


Cela ressemble à une bonne approche globale. Vous pouvez supprimer l'étape 2 et réduire ainsi le temps de lancement en créant une AMI personnalisée incluant toutes les couches logicielles dont vous avez besoin. Cela dit, je mettrais quand même à jour tous les packages au démarrage pour vous assurer de disposer des dernières mises à jour de sécurité.

Vous voudrez peut-être aussi penser à utiliser un Instance soutenue par EBS - Ainsi, le volume de démarrage, la pile de logiciels et votre application sont tous sur EBS, ce qui supprime certaines des étapes ci-dessus.


5
2018-06-10 19:57





OK, cela a été demandé il y a un moment, mais je vais quand même ajouter mes 2 centimes. je pense vous manquez les avantages du cloud computing.

Tout d'abord, vous devez séparer votre code d'application et vos données persistantes sur deux machines virtuelles différentes. Cela vous coûtera un peu en latence de communication entre ordinateurs virtuels, mais cela simplifiera grandement votre administration. N'oubliez pas qu'avoir 2 petites machines virtuelles au lieu d'une grande machine n'est pas plus coûteux. Alors choisissez le nombre d'hôtes qui correspond le mieux à vos besoins.

Si possible, vous voulez que vos serveurs d'applications soient "sans état" en ce sens qu'ils ne devraient pas avoir de données persistantes, et vous devriez pouvoir créer une nouvelle instance avec un minimum de travail manuel.

Deuxièmement, vous devez déterminer si certains des services gérés Amazon tels que SimpleDB ou le service de base de données relationnelle (MySQL hébergé) conviennent parfaitement à votre magasin de données persistantes.

Le flux idéal ressemble à ceci:

  1. Changez le système backend le plus "arrière" en premier. Par exemple, si votre modification nécessite l'ajout d'une colonne à une table de base de données, ajoutez-la à l'aide des outils MySQL normaux sur une instance RDS en cours d'exécution. (Cela suppose que votre architecture autorise la modification de votre magasin de données tout en préservant la compatibilité avec les versions antérieures ou que vous mettez d'abord à jour le code de votre serveur d'applications afin qu'il soit compatible avec les versions ultérieures.)
  2. Afficher une nouvelle instance de serveur d'applications, en utilisant une AMI personnalisée prête à l'emploi que vous avez préparée à l'avance.
  3. Installez votre code mis à jour sur le nouveau serveur d’applications, c’est-à-dire le nouveau code qui utilise la nouvelle colonne et possède la nouvelle fonctionnalité.
  4. Tester.
  5. Transférer tout ou partie du trafic, c’est-à-dire déplacer sur adresse IP / basculer sur Elastic Load Balancing sur le nouveau serveur d'applications. (Dans un monde idéal, vous ne devriez déplacer qu'un petit pourcentage, par exemple 5% de votre trafic, puis surveiller tous les problèmes. AFAIK Elastic Load Balancing ne prend pas encore en charge le routage pondéré, mais vous ne devriez probablement pas le faire. Un basculement progressif peut également être obtenu en ayant 2 chemins d’exécution dans votre code, mais c’est fastidieux et ennuyeux à faire - l’équilibrage de la charge collante pondéré est plus simple.)
  6. Conservez l'ancienne instance du serveur d'applications pendant quelques jours, au cas où le nouveau code comporterait des régressions et que vous deviez revenir en arrière.

7
2017-07-05 22:51



Ainsi, Elastic Load Balancing ne prend pas en charge le routage collant pondéré ... Comment allez-vous y parvenir sur AWS? - Pieter Breed
@Pieter Breed: Je pense que c'est une nouvelle question en soi. :-) J'ai utilisé les mots "collant pondéré", mais en réalité ce n'est pas précis à 100%. Ce que vous voulez peut-être vraiment, c’est de marquer certains clients comme des "bêta-testeurs" et d’envoyer uniquement ceux-ci vers la nouvelle version du code en tant que cookie. Si vous en avez besoin et que ELB ne peut pas vous aider, vous pouvez renoncer à ELB et installer votre propre équilibreur de charge sur une instance EC2. - Jesper Mortensen