Comment démarrer avec Amazon ECS et Amazon Fargate

Docker peut être installé sur les plates-formes de système d'exploitation les plus couramment utilisées. CoreOS a Docker préinstallé et est conçu spécifiquement pour exécuter des conteneurs Docker. Docker pour AWS fournit un mode essaim Docker prêt à l'emploi dans lequel un cluster de nœuds, appelé essaim, fournit une plate-forme distribuée pour l'exécution d'applications de conteneur Docker.

Problème : Toutes les plates-formes Docker susmentionnées ne sont que différents types d'installations Docker et nécessitent que les conteneurs Docker s'exécutent et soient gérés sur la ligne de commande.

Solution : Amazon ECS (Service de conteneur élastique ) est un service géré pour les conteneurs Docker avec prise en charge intégrée de la mise à l'échelle, de l'équilibrage de charge, de la mise en réseau, du stockage, de la journalisation et d'autres tâches de gestion des conteneurs Docker. Amazon ECS prend en charge deux types de lancement :EC2 et Fargate.

Avec le type de lancement EC2, les instances EC2 sont lancées pour exécuter des conteneurs Docker. Le type de lancement Fargate, qui a été introduit récemment (novembre 2017), héberge des tâches qui encapsulent des conteneurs Docker. Les tâches sont directement rendues accessibles à l'utilisateur via une interface réseau élastique (ENI ). Les instances EC2 sur lesquelles Fargate est provisionné ne sont pas exposées à l'utilisateur et ne sont pas directement accessibles.

Dans ce chapitre, nous apprendrons ce qui suit :Qu'est-ce qu'Amazon Fargate

Avantages des objets Fargate Amazon ECS
Ressources de calcul dans Amazon ECS Fargate
Quelles sont les nouveautés du mode de type de lancement d'Amazon Fargate ?

Qu'est-ce qu'Amazon Fargate

Amazon Fargate est un nouveau type de lancement pour Amazon ECS et Amazon EKS (Service Elastic Kubernetes )-services d'orchestration gérés pour les conteneurs Docker sur AWS. Avec le type de lancement Fargate, l'infrastructure est entièrement provisionnée par Fargate. Il est sans serveur et aucune instance EC2 n'est exposée à l'utilisateur. Les conteneurs Docker sont définis comme des définitions de conteneurs dans une définition de tâche. Un service implémente la définition de tâche pour exécuter une ou plusieurs tâches. Chaque tâche est associée à une ENI. Si l'auto-affectation de l'IP publique au niveau de la tâche est activée, une IP publique sur laquelle un client externe peut accéder à une tâche est automatiquement affectée à une tâche. Les tâches communiquent entre elles via une adresse IP privée.

Avantages de Fargate

Les avantages d'ECS sont les suivants :

Un service géré pour les applications conteneurisées qui ne nécessite pas beaucoup d'interventions de l'utilisateur pour exécuter des applications Docker
Microservices composés de plusieurs applications exécutées dans des conteneurs isolés Mise à l'échelle automatique des tâches en fonction de la charge de l'application
S'intègre à d'autres services AWS, notamment IAM, CloudWatch Logs, Elastic Load Balancing, les modèles CloudFormation, les volumes EBS, Batch, ECR et les journaux CloudTrail
Un cloud privé virtuel (VPC ) sans ressources partagées avec d'autres utilisateurs Prend en charge l'exécution d'un CodePipeline avec ECS comme plate-forme de déploiement
Compatible avec la dernière version 17.0 de Docker

Fargate offre les avantages supplémentaires suivants :

Avec un type de lancement Fargate, un utilisateur ne crée ni ne gère aucune instance EC2, car aucune n'est exposée sur le cluster.
Les tâches sont directement exposées à l'utilisateur via une ENI.
L'infrastructure sous-jacente est provisionnée par Fargate. Les instances EC2 ne doivent pas être gérées avec le type de lancement Fargate.
CodePipeline prend en charge Fargate en tant que plate-forme de déploiement.
Les microservices basés sur des définitions de conteneur encapsulées dans une définition de tâche sont explicitement liés et ne doivent pas être liés à des options supplémentaires, telles que des liens.
CloudWatch Logs peut être configuré automatiquement.

Objets Amazon ECS

Les objets Amazon ECS avec Fargate sont les mêmes que pour le type de lancement EC2. Un cluster ECS est l'encapsulation la plus externe et se compose d'un ou plusieurs services. Un cluster peut être réparti sur plusieurs zones de disponibilité. Un service est une implémentation d'une définition de tâche et exécute une ou plusieurs tâches. Une définition de tâche peut avoir une ou plusieurs révisions de tâche. Une révision de tâche est une définition de tâche distincte avec un ensemble de tâches et un service qui lui est associé. Une instance Fargate est associée à un ensemble de tâches dans un service. Une définition de tâche se compose de zéro ou plusieurs définitions de conteneur. En règle générale, une définition de tâche est associée à une ou plusieurs définitions de conteneur, et une définition de tâche qui ne se compose d'aucune définition de conteneur n'exécute aucun conteneur de tâche. Un schéma des objets ECS est présenté comme suit :

Une définition de tâche est un modèle d'application et décrit un ou plusieurs conteneurs. Alors que certains attributs ou paramètres sont configurés au niveau de la tâche, la plupart d'entre eux sont configurés au niveau du conteneur. Plusieurs révisions peuvent être associées à une définition de tâche.

Un Service implémente une définition de tâche et définit un nombre souhaité de tâches à exécuter pour une définition de tâche. Les fonctionnalités facultatives telles que la mise à l'échelle automatique et l'équilibrage de charge sont configurées dans le service.

Un cluster dans un service ECS est un regroupement d'un ou plusieurs services de conteneur. Un nom de cluster doit être unique au sein d'un compte. Un cluster appelé default est provisionné par défaut.

Ressources de calcul dans Amazon ECS Fargate

Taille de la tâche se compose de mémoire de tâches (Go) et Task CPU (vCPU) . Bien que facultative dans le type de lancement EC2, la taille de la tâche est requise avec le type de lancement Fargate. Les paramètres de mémoire et de processeur au niveau du conteneur Docker peuvent éventuellement être définis, mais sont remplacés par les paramètres au niveau de la définition de tâche. Seules des combinaisons spécifiques de mémoire de tâche et de CPU de tâche sont prises en charge, et l'assistant ECS indique par un message la valeur (ou plage de valeurs) prise en charge pour une valeur sélectionnée. Par exemple, la plage de CPU valide pour 1 Go de mémoire est de 0,25 vCPU à 0,5 vCPU. Le total des ressources (mémoire ou processeur) configurées au niveau du conteneur ne doit pas dépasser les paramètres de ressources au niveau de la tâche. Par exemple, si une définition de tâche se compose de deux conteneurs (MySQL et WordPress) avec une limite de mémoire de 128 Mo pour chaque conteneur, la mémoire au niveau de la tâche doit être d'au moins 256 Mo. De plus, le total de la mémoire au niveau du conteneur ne doit pas dépasser 256 Mo. De même pour le CPU. Deux limites de mémoire peuvent être définies au niveau du conteneur :Soft limit et limite stricte . La limite Soft correspond à la memoryReservation au niveau de la tâche, et la limite matérielle correspond à la mémoire attribut au niveau de la tâche. La somme des réservations de mémoire du conteneur (limites logicielles) ne doit pas dépasser la mémoire de la tâche. La limite matérielle de chaque conteneur ne doit pas dépasser la mémoire configurée au niveau de la tâche. Un minimum de 4 Go doit être spécifié par défaut pour un conteneur.

Un exemple de taille de tâche est illustré dans la capture d'écran suivante, dans laquelle la mémoire de tâche (mémoire attribut) est défini sur 0,5 Go (512 Go) et le processeur de tâche est défini sur 0,25 vCPU . Au niveau du conteneur, comme configuré dans les deux définitions de conteneur, la réservation de mémoire est de 128 Mo pour chaque conteneur, ce qui porte la réservation de mémoire totale à 256 Mo bien dans les 512 Go attribué au niveau de la tâche. La taille de la tâche est allouée à une tâche, qu'elle soit utilisée ou non. De même, le nombre d'Unités CPU configuré pour chaque conteneur est 10 , ce qui fait que le nombre total d'unités CPU 20 pour les conteneurs dans les unités CPU, 25 sont alloués au niveau de la tâche. Reportez-vous à la capture d'écran suivante :

Configuration et allocation de la taille des tâches pour les conteneurs

Quelles sont les nouveautés du mode de type de lancement d'Amazon Fargate ?

Outre et parallèlement aux avantages de Fargate évoqués précédemment, Fargate prend en charge les nouvelles fonctionnalités suivantes :

Mode réseau, awsvpc , est le seul mode pris en charge
Les mappages de port hôte ne sont pas valides avec le mode réseau de type de lancement Fargate (awsvpc ), et les ports hôtes sur lesquels une application est exposée sont les mêmes que les ports de conteneur
ecsTaskExecutionRole est ajouté pour le type de lancement Fargate afin de permettre l'extraction d'images Docker et l'envoi de journaux vers CloudWatch Logs
Seuls les awslogs configuration des journaux et awslogs log driver sont pris en charge avec CloudWatch Logs
Le placement des tâches n'est pas pris en charge, car aucune instance ECS n'est provisionnée pour définir les contraintes de placement pour
Seules les images Docker sur Docker Hub et Amazon ECR sont prises en charge Les conteneurs Windows privilégiés ne sont pas pris en charge pour le type de lancement Fargate Les appareils hôtes ne peuvent pas être exposés à un conteneur
L'hôte et sourcePath les paramètres des volumes ne sont pas pris en charge avec le type de lancement Fargate

Résumé

Dans ce chapitre d'introduction, nous avons discuté des avantages de l'utilisation du type de lancement Fargate, de la manière dont les ressources de calcul sont distribuées et configurées avec le type de lancement Fargate, de la façon dont les objets ECS avec Fargate sont les mêmes que pour le type de lancement EC2 et des nouvelles fonctionnalités de Fargate. Dans le chapitre suivant, nous discuterons de la mise en réseau telle qu'elle est utilisée avec Fargate.

Le matériel précédent est un extrait du Guide de démarrage rapide d'Amazon Fargate , par Deepak Vohra, publié par Pact Publishing.