Services managés d’orchestration de containers sur AWS

« Question de Richard Container : je voudrais avoir un service managé chez AWS sur de l’orchestration de containers… 

Eh bien Richard, c’est très simple ! Pas de spécialiste Kub chez vous ? Le Cloud Provider est ton ami. » 

Parmi les nombreux services que propose AWS, je vous propose un focus sur la partie orchestration de containers. 

Quels sont les services disponibles ? Lequel choisir correspondant à vos besoins et à la maturité de vos équipes ? 

Rappel : les containers 

Le plus classique est de faire un comparatif avec une solution de virtualisation : 

La containerisation part du même principe que la virtualisation : mutualiser et rationaliser l’infrastructure pour baisser les coûts, gagner en agilité par une technologie amenant de la portabilité aux applications. 

Le point central de la virtualisation est l’hyperviseur, celui des containers est l’OS hôte : on enlève donc une surcouche à l’infrastructure. 

Voici un exemple de comparatif (source Azure , un peu modifié ) 

L’un des intérêts majeur de la containerisation est de permettre une approche modulaire au niveau applicatif : 

Ici un comparatif entre une application monolithique et une approche microservice (chaque composant de l’application est containerisé.) 

Nous pourrions évoquer ici la différence entre le stateful d’une VM et le stateless d’un container (donnée persistante ou non) mais ce n’est pas le sujet central ? 

Les services managés AWS :

Il existe deux orchestrateurs de containers chez AWS : ECS et EKS. A ceux-ci on peut « greffer » une partie serverless ou non. Il existe également un service de Registry fourni par AWS (ECR)

ECS : 

Amazon ECS (Amazon Elastic Container Service) est un service d’orchestration de conteneurs rapide, hautement évolutif et entièrement géré qui permet aux utilisateurs d’exécuter et de mettre à l’échelle facilement des applications conteneurisées sur AWS. 

Contrairement à Amazon EKS, qui est le service géré par AWS pour Kubernetes, Amazon ECS est le propre service d’orchestration d’AWS qui prend en charge les conteneurs Docker. 

On parlera donc sur ce service de Tasks et de services (plutôt que pods et service pour faire simple) 

Ci-dessous un exemple d’architecture répartie sur deux zones de disponibilité : 

Comme on peut le voir, ECS est un service managé, le client AWS ne gère pas la partie Cluster de la solution pour se consacrer à la partie application. 

Le cluster peut être constitué d’instances « classiques » EC2 mais peut également faire tourner des containers en mode « serverless » : Fargate dont on reparlera un peu plus loin.. 

EKS : 

Amazon EKS (Amazon Elastic Kubernetes Service) est un service géré qui facilite l’exécution de Kubernetes sur AWS sans avoir besoin d’installer, d’exploiter et de gérer votre propre plan de contrôle Kubernetes (control plane). De plus, Amazon EKS s’intègre de manière transparente à une suite d’autres services AWS, et toute application exécutée sur Amazon EKS est compatible avec les applications déjà exécutées dans votre environnement Kubernetes existant. 

De la même manière qu’ECS, nous sommes sur un service managé, pas de gestion de la couche Cluster Kubernetes (ci-dessous la différence entre managé et non managé): 

Depuis peu, AWS a mis à disponibilité le code d’EKS (EKS distro : https://github.com/AWS/eks-distro ) 

Cette release permet d’installer et d’utiliser EKS on-premise : 

Avec donc une visibilité depuis la console AWS des différents clusters qu’ils soient on-prem ou dans le cloud public. Ceci amène également une hybridation facilitée par une expérimentation dans ses datacenters avant migration. 

Fargate :

AWS Fargate est un moteur de calcul sans serveur qui fournit une capacité de calcul à la demande de bonne taille pour les conteneurs cloud. 

En réduisant la charge opérationnelle liée à la mise à l’échelle, à l’application de correctifs, à la sécurisation et à la gestion des serveurs, Fargate permet aux DevOps de se concentrer sur ce qui les intéresse le plus: la création d’applications. Fargate fonctionne à la fois pour Amazon EKS et ECS. 

Voici un exemple de Cluster mixte entre EC2 et Fargate sous EKS : 

Dans quel cadre ne peut-on pas utiliser Fargate ? 

• Reserved Instances et instances spots 
• Containers windows 

Quel service AWS choisir ?

C’est en fonction de plusieurs critères : 

• Compatibilité avec un existant (par ex. Kubernetes en place on -premise) 
• Besoin de gestion des instances ou non (Fargate ou non) 
• Le coût (à déterminer sur AWS cost explorer !) 
• Utilisation ou non d’EKS distro on-premise 
• … 

Environnement technique  AWS: 

Ces services AWS sont souvent associés à d’autres pour la gestion et la mise à l’échelle par ex. 

Voici par exemple sur ECS une utilisation liée aux services DevOps natifs AWS : 

Simplement : 

Le repository de code (CodeCommit) détecte un ajout de nouveau code qui génère un event sur cloudwatch et permet à CodeBuild de détecter la nouvelle release. 

CodeBuild va donc générer la nouvelle image docker et la poser sur le service de registry (ECR). 

Un event de génération de nouvelle image est généré sur cloudwatch (avec l’ID de release) qui permet à CloudFormation (Infra as Code) de mettre les nouvelles versions en production sur ECS. 

Conclusion : 

Comme l’on peut le constater, il existe plusieurs possibilités d’orchestration de containers chez AWS qui seront à choisir en fonction des besoins et des coûts. Par la sortie d’EKS distro on pourrait tendre à penser que Kubernetes sort son épingle du jeu… A suivre !