Elastic Beanstalk convient-il aux CD d'entreprise?


11

Je travaille avec un projet qui utilise Jenkins pour créer et déployer des microservices sur Elastic Beanstalk. Nous déployons une branche d'intégration dans un environnement de test, libérons des branches dans un environnement intermédiaire, puis une version finale du master en production. J'ai quelques inquiétudes à faire de cette façon: premièrement, cela signifie que nous nous retrouvons avec une matrice d'une construction par projet et par environnement, en dupliquant les efforts; et deuxièmement, cela signifie que nous ne déployons pas les mêmes artefacts de génération en production qui ont été validés lors de la préparation.

Je suis enclin à abandonner Beanstalk et à passer à des ASG simples en utilisant quelque chose comme Chef pour les déploiements. Cela nous laisserait une génération par projet, produisant un artefact de génération, et nous pourrions déployer le même artefact en production qui a été approuvé dans la mise en scène. La transition a cependant un coût initial non négligeable. Existe-t-il un moyen d'utiliser mieux Beanstalk qui permettrait un CI / CD plus fiable et plus facile à gérer?

Remarque : La promotion du même artefact de construction est exactement ce que je veux faire, mais d'après les documents, je ne vois aucun moyen clair de le faire; il explique comment déployer sur EB à partir de la source de votre application, mais pas comment promouvoir une version existante dans un autre environnement, sauf si j'ai réussi à la faire défiler à droite. S'il est disponible dans EB lui-même, il peut y avoir une limitation dans le plugin de déploiement Jenkins EB qui l'empêche de se faire spécifiquement dans Jenkins, mais je n'ai pas vu de moyen de le faire du tout.


Est-ce votre environnement Jenkins qui pose la seule restriction de build par environnement? J'utilise Elastic Beanstalk pour déployer des applications et les artefacts d'application téléchargés peuvent être promus (déployés) dans plusieurs environnements très bien. Donc, je ne vois pas vraiment les limites que vous décrivez. Il semble qu'il puisse y avoir un moyen d'utiliser Elastic Beanstalk pour faire ce que vous voulez. Mais cette question est assez large dans sa forme actuelle.
Andy Shinn

Pourquoi reconstruisez-vous vos actifs au lieu de promouvoir le même actif dans d'autres environnements après les tests?
Evgeny

Réponses:


4

L'OMI pense que votre problème n'est pas avec Elastic Beanstalk dans ce scénario, c'est avec Jenkins, ou du moins la façon dont vous l'utilisez. Vous devez vraiment vous concentrer sur la construction d'une «chose» une seule fois, quelle que soit cette chose.

Divulgation complète: Je travaille pour ThoughtWorks et je suis incroyablement partisan du GoCD. J'essaierai de préciser ce que je veux dire en étant aussi neutre que possible. J'utiliserai les documents de notre outil comme exemples, mais j'espère que les gens pourront extrapoler à leurs systèmes.

Quelque part au début de votre pipeline, vous créez des "artefacts". Il peut s'agir de fichiers binaires représentant tout ou partie de votre application, ou ils peuvent être générés par un certain nombre d'outils tels que des outils de test. Ces artefacts doivent être stockés par le système et ne plus jamais être reconstruits. Le système doit ensuite récupérer l'artefact de la révision appropriée en cas de besoin.

Par exemple...

  1. Je crée un fichier .jar et exécute des tests unitaires dessus, des trucs de base C / I. S'il réussit, ce fichier .jar et la sortie des tests sont téléchargés vers ce travail de pipeline spécifique .
  2. Le prochain pipeline pourrait être votre déploiement dans un environnement de test plus complexe. Il faut aller chercher l' exacte pot de l' exacte travail qui l'a construit. Il exécute ensuite Elastic Beanstalk pour déployer ce pot dans l'environnement approprié.
  3. Le prochain pipeline est votre déploiement intermédiaire. Il va tout l'arrière de façon à la première canalisation et va chercher l' exacte pot de l' exacte travail qui l'a construit. Exécutez ensuite Elastic Beanstalk pour déployer ce pot dans l'environnement approprié.

Ce sont chacun des pipelines distincts, car cela vous permet d' exécuter davantage en parallèle ou à la demande sans blocage.

Vous pouvez utiliser Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy ou un certain nombre d'autres outils pour effectuer les déploiements réels. Ce n'est pas de là que vient votre problème. Les serveurs d'intégration continue n'ont pas été conçus à l'origine pour ce faire. Bien sûr, il existe de nombreux plugins que vous pouvez utiliser pour vous rendre au même endroit si vous le souhaitez.

Les serveurs de livraison continue comme GoCD , Chef Automate et ConcourseCI ont été construits spécifiquement pour résoudre des problèmes comme celui-ci.


Oui, mon objectif est de construire une fois et de promouvoir la production. Ma question est de savoir si beanstalk est adapté à ce type d'utilisation. D'après ce que je peux dire, cela ne semble vraiment pas l'être; par exemple, la méthode recommandée pour déployer une application .NET est de le faire à partir de Visual Studio, ce qui est à peu près la pire pratique à laquelle je puisse penser.
Adrian

Je ne l'ai pas utilisé personnellement, mais il semble que ce serait le cas si vous changez le mot "promouvoir" en "déployer". Vos systèmes CD appellent beanstalk pour se déployer vers les tests, exécutent certains tests, puis signalent les succès / échecs. S'il réussit, votre système de CD appelle beanstalk pour déployer vers le transfert, et ainsi de suite. Ainsi, la promotion est effectuée par votre outil d'orchestration, le déploiement est effectué par votre outil de déploiement. (Pour info, c'est pourquoi des entreprises comme Chef ont Hibernate (la chose), Automate (promouvoir la chose) et Chef (déployer la chose).
Ken Mugrage

Pour info, il semble que vous puissiez le script (l'infrastructure car le code est une "bonne chose") docs.aws.amazon.com/elasticbeanstalk/latest/dg/… - mais encore une fois, absolument aucune expérience personnelle.
Ken Mugrage

Peu importe le mot que vous utilisez, Beanstalk ne semble pas le faire, pour autant que je sache. Il semble être orienté vers le déploiement à partir de la source, pas à partir d'artefacts. À partir de la page que vous avez liée: «Lorsque vous exécutez eb deploy, l'interface de ligne de commande EB regroupe le contenu de votre répertoire de projet et le déploie dans votre environnement.» J'apprécie la réponse, mais ma question est spécifique au haricot magique, alors j'espère que quelqu'un qui a une expérience du haricot magique peut sonner.
Adrian

Ah, désolé pour ça. J'interprétais ~/eb$ eb deploy Creating application version archive "app-150630_014338". Uploading elastic-beanstalk-example/app-150630_014338.zip to S3comme signifiant tout fichier zip que vous avez bloqué dans ce répertoire. Bonne chance!
Ken Mugrage
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.