Vous devez ajouter des tests d'intégration à un workflow CodePipeline existant qui construit une image de conteneur pour un service Amazon ECS et pousse l'image vers ECR avec une nouvelle balise. Les tests doivent vérifier que la nouvelle version du service est accessible et que les points de terminaison de l'API renvoient des réponses réussies. Un cluster ECS pour les tests existe déjà. Quelles sont les trois actions qui permettent d'y parvenir avec le moins de frais de gestion ?

Pour déployer l'image sur ECS, une étape de déploiement (Deploy) avec Amazon ECS comme fournisseur d'action est nécessaire. Cette action gère le déploiement de la nouvelle image conteneur sur le cluster ECS existant. L'étape de construction de l'image doit produire un fichier imagedefinitions.json qui contient la référence à la nouvelle balise d'image. Ce fichier est utilisé par l'action de déploiement ECS pour identifier l'image à déployer. Enfin, pour les tests d'intégration, une fonction Lambda est une solution à faible gestion. Elle peut être configurée pour exécuter des vérifications de connectivité et des appels d'API sur le service déployé après le déploiement, puis ajoutée au pipeline en tant qu'action Lambda. Utiliser AWS CodeDeploy comme fournisseur d'action pour ECS est incorrect car CodeDeploy est généralement utilisé pour des déploiements sur EC2, Lambda ou des déploiements sans serveur, mais l'intégration directe avec ECS pour les images conteneur est mieux gérée par le fournisseur ECS. L'ajout d'un fichier appspec.yml est pertinent pour CodeDeploy, pas directement pour un déploiement ECS natif. Écrire un script de test et l'invoquer depuis S3 est possible mais moins gérable qu'une fonction Lambda dédiée, qui offre une exécution sans serveur et une intégration plus simple avec CodePipeline.