1 votes

Conseils pour une stratégie d'architecture et de déploiement EC2

Mon entreprise est en train de migrer plusieurs sites web et applications web PHP (pile LAMP standard) de trois serveurs internes vers Amazon EC2. Comme nous n'avions que trois serveurs, nous avons regroupé plusieurs sites web à faible trafic avec peut-être une application web à fort trafic, et nous les avons servis à partir du même serveur. L'administrateur du serveur a pratiquement copié l'architecture précédente sur les instances EC2, en augmentant simplement la taille de l'instance pour tenir compte du client à plus fort trafic qui occupe cette instance particulière.

Cette architecture pourrait être acceptable s'il ne s'agissait pas de déploiement. Chaque fois qu'un de ces sites/applications change, il faut redéployer l'instance entière, ainsi que les 30 sites/applications qu'elle héberge, au lieu de n'en mettre qu'un seul à jour.

Comment pouvons-nous concevoir notre nuage de manière plus modulaire ? Chaque application doit-elle avoir sa propre instance de taille appropriée ? Quelle est la meilleure stratégie de déploiement dans ce type de situation ?

1voto

DuStorm Points 106

Votre administrateur de serveur a en fait transféré vos sites d'un centre de données à un autre. Vous considérez les instances EC2 comme des serveurs traditionnels. Il est temps de changer votre façon de penser. Considérez les instances EC2 comme des conteneurs pour vos applications web, et même comme une partie de votre application web, plutôt que comme un simple élément sur lequel vous les hébergez.

Modulariser vos sites web est une bonne idée. Vous pouvez les diviser en une instance EC2 par site. Ainsi, lorsque vous déployez une mise à jour, seul ce site web est affecté (en bien ou en mal).

Vous pouvez également placer vos sites derrière des répartiteurs de charge appropriés et/ou des groupes de mise à l'échelle automatique pour tenir compte des changements de charge, en fonction des exigences propres à chaque site.

Jetez un coup d'œil à Elastic Beanstalk. Il s'agit d'un mécanisme de déploiement "prêt à l'emploi" pour les sites web (PHP, .NET, Ruby, etc.). Si tout se passe bien, vous ne devriez pas avoir besoin de vous connecter à votre instance. Il utilise une (ou plusieurs) instance EC2 par application web, en fonction de votre configuration.

L'inconvénient est le coût : vous paierez plus cher parce que vous utiliserez plus d'instances EC2. Mais c'est la contrepartie de la modularité et de la fiabilité.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X