Bonnes pratiques pour les images de conteneurs Amazon ECS - Amazon Elastic Container Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques pour les images de conteneurs Amazon ECS

Une image de conteneur est un ensemble d'instructions expliquant comment créer le conteneur. Une image de conteneur contient le code de votre application et toutes les dépendances dont le code d'application a besoin pour s'exécuter. Les dépendances des applications incluent les packages de code source sur lesquels repose le code de votre application, un environnement d'exécution de langage pour les langages interprétés et les packages binaires sur lesquels repose votre code lié dynamiquement.

Suivez ces directives lors de la conception et de la création de vos images de conteneur :

  • Complétez vos images de conteneur en stockant toutes les dépendances de l'application sous forme de fichiers statiques à l'intérieur de l'image de conteneur.

    Si vous modifiez quelque chose dans l'image du conteneur, créez une nouvelle image du conteneur avec les modifications.

  • Exécutez un seul processus de candidature dans un conteneur.

    La durée de vie du conteneur est aussi longue que le processus de l'application. Amazon ECS remplace les processus bloqués et détermine où lancer le processus de remplacement. Une image complète rend le déploiement global plus résilient.

  • Simplifiez le traitement de votre applicationSIGTERM.

    Lorsqu'Amazon ECS arrête une tâche, il envoie d'abord un signal SIGTERM à la tâche pour informer l'application qu'elle doit terminer et s'arrêter. Amazon ECS envoie ensuite un SIGKILL message. Lorsque les applications ignorent leSIGTERM, le service Amazon ECS doit attendre avant d'envoyer le SIGKILL signal pour mettre fin au processus.

    Vous devez déterminer le temps nécessaire à votre application pour terminer son travail et vous assurer que vos applications gèrent le SIGTERM signal. La gestion du signal par l'application doit empêcher l'application de prendre de nouveaux travaux et de terminer le travail en cours, ou enregistrer le travail inachevé pour le stocker en dehors de la tâche lorsque le travail prend trop de temps à terminer.

  • Configurez des applications conteneurisées pour écrire des journaux dans stdout et stderr.

    Le découplage de la gestion des journaux du code de votre application vous donne la flexibilité d'ajuster la gestion des journaux au niveau de l'infrastructure. La modification de votre système de journalisation en est un exemple. Au lieu de modifier vos services, de créer et de déployer une nouvelle image de conteneur, vous pouvez ajuster les paramètres.

  • Utilisez des balises pour gérer les versions des images de vos conteneurs.

    Les images de conteneurs sont stockées dans un registre de conteneurs. Chaque image d'un registre est identifiée par une balise. Une balise est appelée latest. Cette balise est dirigée vers la dernière version de l'image du conteneur de l'application, comme HEAD dans un référentiel git. Nous vous recommandons d'utiliser uniquement la balise latest à des fins de test. Il est recommandé de baliser les images des conteneurs avec une balise unique pour chaque compilation. Nous vous recommandons de baliser vos images en utilisant le git SHA pour la validation git qui a été utilisée pour créer l'image.

    Vous n'avez pas besoin de créer une image de conteneur pour chaque validation. Toutefois, nous vous recommandons de créer une nouvelle image de conteneur chaque fois que vous publiez une validation de code spécifique dans l'environnement de production. Nous vous recommandons également de baliser l'image avec une balise correspondant à la validation git du code contenu dans l'image. Si vous avez balisé l'image avec la validation git, vous pouvez trouver plus rapidement la version du code exécutée par l'image.

    Nous vous recommandons également d'activer les balises d'image immuables dans Amazon Elastic Container Registry. Avec ce paramètre, vous ne pouvez pas modifier l'image du conteneur vers laquelle pointe une balise. Amazon ECR impose plutôt qu'une nouvelle image soit téléchargée vers un nouveau tag. Pour plus d'informations, veuillez consulter Mutabilité d'une étiquette d'image dans le Guide de l'utilisateur Amazon ECR.

Lorsque vous concevez votre application pour qu'elle s'exécute AWS Fargate, vous devez choisir entre déployer plusieurs conteneurs dans la même définition de tâche ou déployer des conteneurs séparément dans plusieurs définitions de tâches. Si les conditions suivantes sont requises, nous vous recommandons de déployer plusieurs conteneurs dans une définition de tâche unique :

  • Vos conteneurs partagent le même cycle de vie (autrement dit, ils sont lancés et résiliés conjointement).

  • Vos conteneurs doivent être exécutés sur le même hôte sous-jacent (autrement dit, un conteneur référence l'autre sur un port localhost).

  • Vos conteneurs partagent des ressources.

  • Vos conteneurs partagent des volumes de données.

Si ces conditions suivantes ne sont pas requises, nous vous recommandons de déployer des conteneurs distincts dans plusieurs définitions de tâche. Cela vous permet de dimensionner, d'approvisionner et de déprovisionner les conteneurs séparément.