Développement de PaaS à l'aide des fonctions Step Functions et Hashicorp

Introduction:

Les outils de cloud ont maintenant la possibilité de permettre à DevOps de fournir des applications parallèles à l'infrastructure de cloud déployées. Est-ce que je viens de dire, construire une solution PaaS? Les solutions PaaS commerciales telles que OpenShift et Pivotal Cloud Foundry peuvent être coûteuses et requièrent des compétences spécialisées. Ils accélèrent le développement et maintiennent l'agnostique de votre fournisseur d'adoption de cloud d'entreprise. Cependant, leur adoption appelle un changement stratégique dans la manière dont votre organisation développe les applications. Tout va bien avec cette approche, il faut juste du temps – POC, POV, Road Show, puis une décision. Les solutions PaaS sont excellentes, mais une autre solution consiste à utiliser des services AWS individuels, ainsi que des outils open source, qui peuvent aider à mettre en place, sécuriser, exécuter et connecter une infrastructure informatique en nuage.

La connaissance de ces outils et leur organisation dans un flux de travail cohérent peuvent aider votre L'équipe DevOps effectue un déploiement continu sur une infrastructure cloud dont les résultats sont similaires à ceux des solutions PaaS commerciales. Cette solution est économique et gérable sans recourir à des compétences spécialisées. Pourquoi pas de compétences spécialisées ici? Parce que votre équipe de développement possède déjà les compétences nécessaires pour construire «Castles in the Cloud». Bien qu'ils soient conçus comme des solutions, le résultat final est un produit complet doté de son propre cycle de vie de gouvernance et de gestion. Il peut facilement être intégré au pipeline de distribution d'applications. De plus, la solution fournit des instances EC2 immuables qui capturent les informations de journal pour la surveillance et le débogage. Cette conviction sous-tend cette approche – «Automatisation complète, intégration transparente à l'aide d'outils et de services non commerciaux».

Solution:

Il semble tout d'abord que la solution réside dans Elastic Beanstalk. Bien que Beanstalk produise une infrastructure immuable, il présente certains inconvénients en ce qui concerne le chiffrement de la configuration et des données de journal lors du provisionnement de l'infrastructure. Cela pourrait constituer un défi pour les organisations opérant dans un secteur hautement réglementé. En tant que tel, la configuration requise pour transférer les journaux de service dans un compartiment S3 chiffré, pour que la configuration du processus de génération AMI soit pilotée et pour pouvoir automatiser la surveillance et l'audit de l'infrastructure nécessite une solution personnalisée personnalisée et pilotée par la configuration. En outre, des secteurs hautement réglementés tels que la finance et les soins de santé nécessitent un cryptage complet des données transitives et journalisées.

L'automatisation de l'infrastructure en nuage peut être divisée en cinq processus clés:

• Pré-disposition
• Bakery
• Fourniture
• Validation [19659008] Disposition postérieure

Considérons le processus ci-dessus en tant que travailleur individuel essayant d'accomplir une tâche déterminée et indépendante. Les fonctions AWS Step peuvent facilement orchestrer le flux de travail entre ces travailleurs individuels (ouvriers d'activité) et peuvent être configurées pour créer un processus de provisioning d'infrastructure complet, dynamique et basé sur la configuration. Avec les fonctions Step, les cinq processus ci-dessus sont désormais des états individuels qui sont exécutés dans un ordre chronologique. Un processus reste dans cet état particulier jusqu'à ce que l'activité worker termine son activité. Une machine à états est configurée pour transmettre le contrôle à différents états qui exécutent en interne les ouvriers d'activité construits à l'aide de fonctions Lambda.

Résumé rapide de chaque processus / état:

• Pré-disposition – Il s'agit la première étape du processus déclenchée par le pipeline de CI des applications. La plupart des pipelines d'entreprise CI sont construits à l'aide d'outils tels que Jenkins. Le pipeline envoie une notification à un sujet SNS. Une fonction lambda souscrite au sujet déclenche ensuite l'exécution de la fonction d'étape. Dans cette étape, l'activité rassemble les informations pertinentes d'un fichier de configuration de l'application. Il combine ces informations avec la configuration spécifique au processus et les informations relatives à l'environnement reçues du déclencheur de pipeline. Il chiffre ensuite ces informations et les enregistre dans un magasin de paramètres EC2 crypté. Le fichier de configuration de l'application est généré par les équipes de développement de l'application à l'aide d'une interface utilisateur basée sur des règles qui restreint l'accès aux services AWS en fonction des besoins de l'application.

• Boulangerie – Ce processus est au cœur de la solution d'automatisation. Cette étape est le prochain état de transition après le pré-approvisionnement. Il utilise des outils tels que Packer, InSpec, Chef et AWS CW Agent. L'état appelle un opérateur d'activité Lambda qui exécute une commande SSM. La commande démarre une génération de packer s'exécutant sur une instance EC2 distincte. L'emballeur extrait toutes les informations pertinentes requises pour la construction à partir du magasin de paramètres EC2 crypté et commence la construction. Il utilise Chef pour superposer une application, un middleware et d’autres dépendances sur l’AMI. L'AMI spécifique à l'application, créée après le packer, est chiffrée et partagée avec le propriétaire du compte AWS de l'application pour le provisionnement.

• Provision – Une fois que l'AMI est prête et partagée par le propriétaire du compte de l'application, le prochain état du processus d'automatisation est Provision. Cet état appelle un opérateur d'activité Lambda qui exécute une autre commande SSM démarrant l'exécution des modules Terraform, qui fournit les éléments suivants: ALB, LC, ID AMI cuit à l'état précédent et ASG pour compléter l'élasticité. À la fin de cet état, toute l'architecture physique AWS de l'application est opérationnelle et vous devez pouvoir utiliser le DNS ALB pour vous connecter à l'application. L'accès SSH est supprimé pour conserver les instances immuables.

• Validation – La validation est l'étape suivante du processus. Une fois l'infrastructure configurée, des scripts de validation InSpec automatisés valident le système d'exploitation et les services fournis. Cette phase est également invoquée par un opérateur d'activité Lambda. Les journaux InSpec sont déplacés vers un compartiment S3 chiffré à partir duquel ils sont fournis à l'équipe de test pour examiner et consigner les défauts si nécessaire. Ces défauts sont ensuite triés et attribués aux équipes respectives.

• Post-provisioning – Il s'agit du dernier état du processus où la nouvelle infrastructure mise en service subit un test de fumée avant d'être livrée aux équipes d'application / de test. Cet état configure les journaux CW basés sur EC2 avec un compartiment S3 chiffré. À partir de S3, les journaux sont exportés dans des outils de gestion des journaux tels que Splunk. Dans Splunk Operations, l’équipe peut créer des tableaux de bord de surveillance. De plus, à cette étape, tous les services AWS fournis avec l'ID d'application sont stockés dans une table Dynamodb à des fins de journalisation et d'audit. Enfin, cette étape initie également les déploiements bleu-vert pour une transition plus en douceur vers la nouvelle version.

Le processus d'automatisation d'infrastructure ci-dessus permet d'activer et de paver l'infrastructure à l'aide des services AWS. Une nouvelle version ou une mise à jour de l'image SOE de base déclenche l'exécution du processus d'automatisation. Cela peut considérablement améliorer l'efficacité du déploiement d'applications sur AWS. Cela réduit considérablement le temps de mise en service EC2 et peut réduire vos coûts d'exploitation AWS sur une période donnée. Bien que personnalisées, ces solutions d'automatisation sont complexes et nécessitent une connaissance approfondie de Cloud Native Services et des outils permettant de créer une infrastructure via du code. L’équipe de services de plate-forme cloud de Perficient est experte dans ce type de solutions et peut aider votre organisation à regarder au-delà du monde des «instances EC2 de compagnie». Si vous souhaitez en savoir plus, contactez l'un de nos spécialistes à l'adresse sales@perficient.com et téléchargez notre guide des services Web Amazon pour plus d'informations.