Déploiement de production sur EC2 avec un temps d'arrêt minimal

D'accord, cela a été demandé il y a un moment, mais je vais quand même donner mon avis. Je pense que vous passez à côté des avantages du cloud computing.

Tout d'abord, vous devriez séparer votre code d'application et vos données persistantes sur 2 machines virtuelles différentes. Cela vous coûtera un peu en termes de latence de communication inter-VM, mais devrait rendre votre administration beaucoup plus simple. Rappelez-vous, avoir 2 petites VM au lieu d'1 grande VM n'est pas plus cher; donc choisissez le nombre d'hôtes qui correspond le mieux à vos besoins.

Si possible, vous voulez que vos serveurs d'application soient "sans état" dans le sens où ils ne devraient pas avoir de données persistantes, et vous devriez être en mesure de démarrer une nouvelle instance avec un minimum de travail manuel.

Deuxièmement, vous devriez envisager si certains des services gérés par Amazon comme SimpleDB ou le service de base de données relationnelle (MySQL hébergé) sont bien adaptés à votre magasin de données persistantes.

Le flux idéal ressemble à ceci :

1. Changer le système backend "le plus arrière" en premier. Par exemple, si votre changement nécessite d'ajouter une colonne à une table de base de données, ajoutez-la en utilisant des outils MySQL normaux sur une instance RDS en cours d'exécution. (Cela suppose que votre architecture permet à votre magasin de données de changer tout en maintenant la compatibilité ascendante, ou que vous mettez d'abord à jour le code de votre serveur d'application pour qu'il soit compatible vers l'avant.)
2. Démarrer une nouvelle instance de serveur d'application, en utilisant une AMI prête à l'emploi personnalisée que vous avez préparée à l'avance.
3. Installer votre code mis à jour sur le nouveau serveur d'application, c'est-à-dire le nouveau code qui utilise la nouvelle colonne et a la nouvelle fonctionnalité.
4. Tester.
5. Transférer une partie ou tout le trafic, c'est-à-dire basculer l'adresse IP / le basculement de l'équilibrage de charge élastique vers le nouveau serveur d'application. (Dans un monde idéal, vous ne transféreriez qu'un petit pourcentage, disons 5% de votre trafic au début, et vous surveilleriez ensuite tout problème. À ma connaissance, l'équilibrage de charge élastique ne prend pas en charge le routage pondéré persistant encore, donc vous ne devriez probablement pas le faire. Le basculement progressif peut également être réalisé en ayant 2 chemins d'exécution dans votre code, mais c'est fastidieux et ennuyeux à faire - l'équilibrage de charge pondéré persistant est plus simple.)
6. Gardez l'ancienne instance de serveur d'application pendant quelques jours, au cas où le nouveau code aurait des régressions et que vous deviez revenir en arrière.