Charges de travail .NET sur Amazon ECS et AWS Fargate

Un cluster est un groupe logique de ressources informatiques, dans une région spécifique. Les clusters contiennent les instances de conteneur en cours d'exécution qui hébergent vos applications et leurs composants, ce qui permet de les isoler afin qu'elles n'utilisent pas la même infrastructure sous-jacente. Cela améliore la disponibilité en cas de défaillance d'un élément particulier de l'infrastructure hébergeant votre application. Seul le cluster concerné devra être redémarré.

Que vous utilisiez Amazon ECS ou Amazon ECS sur AWS Fargate, vous travaillerez avec des clusters. Ce qui diffère, c'est le niveau de gestion que l'on attend de vous. Si vous spécifiez le type de lancement EC2 lors de la création de clusters, vous assumez la responsabilité de configurer et de gérer ces clusters. Cependant, lorsque vous utilisez le type de lancement Fargate, il est de la responsabilité de Fargate de les gérer.

Un conteneur contient l'ensemble du code, du moteur d'exécution, des outils et des bibliothèques système dont l'application ou le composant d'application du conteneur a besoin pour s'exécuter. Lorsque vous démarrez des instances de conteneur pour héberger vos applications, celles-ci s'exécutent sur l'infrastructure de calcul associée à un cluster.

Les modèles en lecture seule appelés images de conteneurs sont utilisés pour lancer des conteneurs. Avant de pouvoir utiliser une image pour exécuter vos conteneurs, vous devez déployer l'image du conteneur dans un registre, par exemple Amazon Elastic Container Registry (Amazon ECR) ou Docker Hub.

Vous définissez des images de conteneur à l'aide d'une ressource appelée Dockerfile. Un Dockerfile est un fichier texte qui détaille tous les composants et ressources que vous souhaitez inclure dans l'image. Amazon ECS utilise le même Dockerfile que celui utilisé pour définir des images de conteneur pour d'autres applications .NET, sans aucune modification. À l'aide de la commande docker build, vous transformez les commandes et paramètres définis dans le Dockerfile en une image de conteneur que vous pouvez envoyer vers un registre ou exécuter localement dans Docker. Les outils de conteneur disponibles auprès d'AWS, détaillés dans le Module 2, se chargent souvent de la création et de l’envoi de l'image pour vous.

Une définition de tâche est un fichier texte au format JSON utilisé pour décrire les conteneurs qui composent votre application. Une seule définition de tâche peut décrire jusqu'à 10 conteneurs.

Vous pouvez voir une définition de tâche comme un plan d'environnement d'application, qui spécifie les paramètres de l'application et du système d'exploitation. Les exemples incluent les ports réseau qui doivent être ouverts et les volumes de données qui doivent être connectés, entre autres ressources.

Amazon ECS ne limite pas votre application à une seule définition de tâche. En fait, il est recommandé de combiner les conteneurs associés à un composant faisant partie de votre application en une seule définition de tâche et d'utiliser plusieurs définitions de tâches pour décrire l'ensemble de l'application. Cela permet aux différents composants logiques qui composent votre application de se mettre à l'échelle indépendamment.

Prenons l'exemple d'une application Web à n niveaux typique, comprenant un niveau frontend d'interface utilisateur Web, un niveau d'API, un niveau intermédiaire et des niveaux de composants de base de données. L'image ci-dessous montre comment regrouper ces niveaux de composants dans différentes définitions de tâches. Cela permet, par exemple, de se mettre à l'échelle horizontalement au niveau de l'interface utilisateur Web, indépendamment des autres composants et vice versa, en cas d'augmentation de son utilisation. Si vous définissiez tous les niveaux dans une seule définition de tâche, l'ensemble de l'application se mettrait à l'échelle sous la charge, y compris les niveaux qui ne voient pas d'augmentation de leur utilisation, ce qui augmenterait le délai de montée en puissance (si votre application est volumineuse) et augmenterait potentiellement vos coûts financiers.

Vous trouverez ci-dessous un exemple de définition de tâche. Il met en place un serveur Web à l'aide de conteneurs Linux sur le type de lancement Fargate.

{
   "containerDefinitions": [ 
      { 
         "command": [
            "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
         ],
         "entryPoint": [
            "sh",
            "-c"
         ],
         "essential": true,
         "image": "httpd:2.4",
         "logConfiguration": { 
            "logDriver": "awslogs",
            "options": { 
               "awslogs-group" : "/ecs/fargate-task-definition",
               "awslogs-region": "us-east-1",
               "awslogs-stream-prefix": "ecs"
            }
         },
         "name": "sample-fargate-app",
         "portMappings": [ 
            { 
               "containerPort": 80,
               "hostPort": 80,
               "protocol": "tcp"
            }
         ]
      }
   ],
   "cpu": "256",
   "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
   "family": "fargate-task-definition",
   "memory": "512",
   "networkMode": "awsvpc",
   "runtimePlatform": {
        "operatingSystemFamily": "LINUX"
    },
   "requiresCompatibilities": [ 
       "FARGATE" 
    ]
}

Lorsque Amazon ECS instancie une définition de tâche, il crée une ou plusieurs tâches qui s'exécutent au sein d'un cluster. Une tâche est une instance de conteneur en cours d'exécution. Outre les autres paramètres environnementaux, la définition de tâche spécifie le nombre de tâches, ou d'instances de conteneur, à exécuter sur le cluster.

Vous pouvez configurer les tâches pour qu'elles s'exécutent de manière autonome, ce qui entraîne l'arrêt du conteneur lorsque la tâche est terminée, ou vous pouvez exécuter des tâches en continu en tant que service. Lorsqu'il est exécuté dans le cadre d'un service, Amazon ECS gère un certain nombre de tâches exécutées simultanément, remplaçant ainsi automatiquement les conteneurs défaillants.

Utilisez une tâche autonome pour le code de l'application qui n'a pas besoin d'être exécuté en continu. Le code s'exécute une fois dans la tâche, puis se termine, mettant fin à l'instance de conteneur. Un exemple serait le traitement par lots de certaines données.

Les tâches autonomes sont configurables pour être exécutées selon une planification ou en réponse à un événement. C'est ce que l'on appelle des tâches planifiées. Dans les deux cas, Amazon EventBridge est utilisé pour définir une planification cron ou un événement qui entraînera l'exécution de votre tâche. Les planifications cron configurent une tâche pour qu'elle s'exécute toutes les nièmes minutes, heures ou jours. Pour les tâches planifiées à exécuter lorsqu'un événement se produit, vous pouvez vous abonner à des événements définis par AWS, ou à vos propres événements personnalisés, dans Amazon EventBridge. Lorsque les événements se produisent, Amazon ECS exécute automatiquement la tâche.

Utilisez des tâches planifiées pour le code d'application qui doit être exécuté périodiquement sans intervention de l'opérateur afin de démarrer la tâche manuellement. Parmi les exemples de scénarios, citons le code permettant d'inspecter les journaux, les opérations de sauvegarde ou les tâches périodiques d'ETL (extraction, transformation, chargement).

Un service est un ensemble d'une ou de plusieurs tâches qui s'exécutent en continu. Dans la définition des tâches, vous définissez le nombre de tâches que le service doit gérer, et Amazon ECS surveille les conteneurs pour s'assurer que le nombre de tâches demandé est toujours disponible.

Amazon ECS exécute un agent sur chaque instance de conteneur d'un cluster. Vous n'avez pas besoin d'installer ou de gérer vous-même cet agent. L'agent fournit des informations sur les tâches en cours et l'utilisation des instances de conteneur, ce qui permet à Amazon ECS de détecter les tâches qui échouent ou qui s'arrêtent. Dans ce cas, Amazon ECS remplace les tâches ayant échoué par de nouvelles instances afin de maintenir le nombre spécifié de tâches dans le service, sans que vous ayez à les surveiller et à prendre des mesures vous-même.

Utilisez un service pour le code d'application qui doit être exécuté en continu. Il s'agit par exemple d'un frontend de site Web ou d'une API Web.

Le code d'application exécuté sur une instance de conteneur doit généralement lire ou écrire des données dynamiques. Il s'agit par exemple de fichiers de données temporaires, de données extraites d'un service externe que vous souhaitez mettre en cache localement pendant une courte période, et de bases de données, notamment celles qui utilisent SQL Server dans des instances Amazon EC2, des instances Amazon Relational Database Service (RDS) et d'autres conteneurs. Par ailleurs, les applications qui s'étendent sur plusieurs instances de conteneur peuvent avoir besoin d'accéder à un stockage partagé pour les données temporaires et à long terme.

Les instances de conteneur en cours d'exécution comportent une couche inscriptible qui peut stocker des données. Cependant, la couche inscriptible est transitoire, et elle est détruite lorsque l'instance de conteneur se termine, soit par une action de l'utilisateur, soit parce que l'instance est devenue défaillante et qu'Amazon ECS l'a remplacée. Cela fait de la couche inscriptible une approche inadaptée au stockage de données à long terme, telles que les données d'une base de données. En outre, les données de la couche inscriptible ne sont accessibles que par le code exécuté sur l'instance de conteneur individuelle, ce qui les rend inadaptées aux données que vous devez partager dans une application couvrant plusieurs instances de conteneur.

Pour permettre aux données d'application d'être stockées pendant une période supérieure à la durée de vie d'une instance de conteneur ou d'être partageables entre plusieurs instances de conteneur, AWS fournit plusieurs services de stockage. Ces services de stockage découplent le stockage des données des instances de calcul. L'utilisation d'un stockage découplé des instances de calcul permet aux données de l'application de survivre plus longtemps que les instances de conteneur sur lesquelles l'application s'exécute. De plus, elle rend les données partageables entre plusieurs instances.

Les services de stockage disponibles pour les applications .NET conteneurisées varient selon que les applications s'exécutent sur des conteneurs Linux ou Windows.

Les conteneurs Linux prennent actuellement en charge le plus large éventail de services de stockage pour les applications .NET lorsqu'elles sont exécutées dans Amazon ECS ou Amazon ECS sur AWS Fargate. Le choix du service de stockage dépendra de la nécessité pour l'application d'un accès partagé et simultané aux données.

Amazon Elastic Block Store (Amazon EBS) est un service de stockage qui fournit des volumes de stockage au niveau des blocs. Un volume EBS fournit aux applications un espace de stockage qui peut être monté sur des conteneurs Linux, accessibles de la même manière qu'un périphérique de disque classique. Amazon EBS réplique automatiquement les données dans des volumes EBS au sein d'une zone de disponibilité, ce qui en fait une solution de stockage fiable qui contribue à améliorer la fiabilité des applications en cas de défaillance d'un volume de stockage.

Les volumes EBS sont redimensionnables dynamiquement, prennent en charge le chiffrement et prennent également en charge les instantanés pour créer des copies. Si nécessaire, vous pouvez détacher des volumes d'un conteneur et les rattacher à un autre conteneur. Pour répondre aux exigences de performance et de prix de votre application, Amazon EBS propose différents types de volumes.

Les volumes EBS sont créés dans une zone de disponibilité spécifique d'une région. Le volume peut ensuite être monté sur une instance de conteneur exécutée dans la même zone, à l'aide des paramètres de la définition de la tâche. Pour accéder aux mêmes données depuis une zone de disponibilité différente, créez un instantané du volume et utilisez-le pour créer un nouveau volume ailleurs dans la même région ou dans une autre région. Un seul instantané peut créer de nombreux volumes dans les zones de disponibilité et les régions. Il s'agit d'une approche à envisager pour les données d'applications en lecture seule destinées à être consommées par des applications nécessitant une haute disponibilité et que vous avez déployées sur plusieurs instances de conteneur couvrant différentes zones de disponibilité et régions.

Amazon EBS est une bonne solution de stockage à envisager pour les applications qui nécessitent un accès rapide et à faible latence aux données qui ne sont pas partagées simultanément, car les applications se mettent à l'échelle horizontalement (c'est-à-dire qu'elles s'exécutent dans plusieurs instances de conteneur). Les exemples incluent les systèmes de fichiers généraux et les bases de données accessibles à partir d'une seule instance de conteneur.

Amazon EBS ne prend pas en charge l'accès simultané à un volume. Pour les applications où les applications doivent partager un système de fichiers monté sur plusieurs conteneurs, pensez à Amazon Elastic File Service ou à l'un des systèmes de fichiers disponibles auprès d'Amazon FSx.

Amazon EFS fournit un service de système de fichiers évolutif, accessible via NFS (Système de fichiers en réseau), qui ne nécessite pas de gestion du stockage. Les systèmes de fichiers gérés via Amazon EFS peuvent être attachés simultanément à plusieurs instances de conteneur basées sur Linux, avec une cohérence en lecture-écriture et un verrouillage des fichiers. Cela permet de partager des données sur un lecteur, pour un accès en lecture et en écriture, sur plusieurs conteneurs hébergeant une application évolutive. Le stockage Amazon EFS est également dynamique, augmentant (et diminuant) sa capacité automatiquement en fonction de l'évolution des besoins de stockage des applications.

Vous ne payez que pour le stockage consommé par vos applications. Par défaut, les données des systèmes de fichiers créés dans Amazon EFS sont stockées dans plusieurs zones de disponibilité d'une région afin de garantir la résilience et la durabilité. Amazon EFS fait référence à ce mode en tant que classe de stockage Standard. Si une application n'a pas besoin d'un stockage multi-AZ complet, utilisez plutôt la classe de stockage One Zone pour réduire les coûts. Les classes de stockage Standard-Infrequent Access et One Zone-Infrequent Access sont également disponibles pour héberger les données auxquelles les applications accèdent de manière non régulière afin de réduire les coûts supplémentaires.

Les systèmes de fichiers Amazon EFS conviennent à un large éventail d'applications, notamment les applications Web, les systèmes de gestion de contenu, les dossiers personnels des utilisateurs et les serveurs de fichiers généraux. Les systèmes de fichiers prennent en charge l'authentification, l'autorisation et le chiffrement. Le contrôle d'accès utilise des autorisations POSIX standard.

L'exemple d'extrait de définition de tâche ci-dessous montre comment monter un système de fichiers EFS pour une tâche.

"containerDefinitions":[
    {
        "mountPoints": [ 
            { 
                "containerPath": "/opt/my-app",
                 "sourceVolume": "Shared-EFS-Volume"
            }
    }
  ]
...
"volumes": [
    {
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-1234",
        "transitEncryption": "DISABLED",
        "rootDirectory": ""
      },
      "name": "Shared-EFS-Volume"
    }
  ]
                                            

Lustre est un système de fichiers open source conçu pour répondre aux besoins de performance du machine learning, du calcul haute performance (HPC), du traitement vidéo et de la modélisation financière. Pour les applications .NET répondant à ces solutions, ou pour d'autres scénarios nécessitant des latences inférieures à la milliseconde, Amazon FSx pour Lustre peut fournir la couche de stockage permanent pour les conteneurs Linux.

Remarque : au moment de la rédaction de cet article, les tâches exécutées dans AWS Fargate ne prennent pas en charge les systèmes de fichiers FSx pour Lustre.

Les systèmes de fichiers créés dans FSx pour Lustre sont conformes à POSIX. Cela signifie que vous pouvez continuer à utiliser les mêmes contrôles d'accès aux fichiers que vous utilisez déjà pour vos applications .NET exécutées sous Linux. Les systèmes de fichiers hébergés dans FSx pour Lustre assurent également la cohérence en lecture-écriture et le verrouillage des fichiers.

En fonction des besoins de l'application, un choix de stockage sur disque SSD ou HDD est disponible, optimisé pour les différentes exigences de charge de travail. Le stockage sur SSD convient aux applications gourmandes en IOPS qui sont sensibles à la latence et qui nécessitent généralement de petites opérations de fichiers à accès aléatoire. Le type de stockage sur HDD convient aux applications nécessitant un débit élevé, impliquant généralement des opérations de fichiers volumineuses et séquentielles. Avec le stockage sur HDD, vous pouvez également ajouter un cache SSD en lecture seule, dont la taille correspond à 20 % de la capacité de stockage du HDD, pour permettre une latence inférieure à la milliseconde et des IOPS plus élevées, et ainsi améliorer les performances des fichiers fréquemment consultés.

Les systèmes de fichiers de FSx pour Lustre peuvent également être liés à un compartiment Amazon S3, avec un accès complet en lecture-écriture. Cela permet à votre application .NET de traiter les objets du compartiment S3 comme s'ils résidaient déjà dans un système de fichiers. Ceci constitue une bonne option pour les applications conçues pour traiter des données provenant de grands jeux de données cloud déjà présents dans S3 sans avoir à copier ces données dans un système de fichiers avant d'y accéder et de les mettre à jour.

Notez que vous pouvez également monter les systèmes de fichiers Lustre à l'aide d'une commande dans votre conteneur Docker en utilisant le package lustre-client ; cela vous permet de monter des systèmes de fichiers dynamiquement dans le conteneur.

Pour les conteneurs Windows qui exécutent des applications .NET et .NET Framework, le stockage de fichiers fourni par Amazon FSx for Windows File Server est disponible pour la permanence et le partage des données entre un ou plusieurs conteneurs exécutés dans une tâche.

FSx for Windows File Server utilise des instances réelles de Windows File Server, accessibles via des partages de fichiers Windows standard SMB, pour stocker et diffuser les données des applications. Les partages de fichiers Windows standard permettent d'utiliser des fonctionnalités et des outils d'administration déjà connus des administrateurs de Windows File Server, tels que la restauration des fichiers des utilisateurs finaux à l'aide de clichés instantanés, les quotas d'utilisateurs et les listes de contrôle d'accès (ACL). SMB permet également la connexion à un partage FSx for Windows File Server à partir de conteneurs Linux.

Les systèmes de fichiers de FSx for Windows File Server peuvent contribuer à réduire les coûts de stockage des applications qui utilisent la déduplication et la compression des données. Les fonctionnalités supplémentaires incluent le chiffrement des données, l'accès aux fichiers vérifiable et les sauvegardes automatiques planifiées. L'accès aux partages du systèmes de fichiers est contrôlable grâce à l'intégration à un Microsoft Active Directory (AD) sur site ou à un Managed AD dans AWS.

FSx for Windows File Server convient à la migration de serveurs de fichiers Windows sur site vers le cloud afin de fonctionner avec des applications conteneurisées .NET et .NET Framework. Il convient également aux applications .NET et .NET Framework qui nécessitent un accès au cloud hybride et à des magasins de données sur site (avec la passerelle de fichiers Amazon FSx). Pour les applications qui utilisent SQL Server, FSx for Windows File Server permet d'exécuter ces charges de travail de base de données sans avoir besoin d'une licence SQL Server Enterprise.

L'exemple d'extrait de définition de tâche ci-dessous montre comment monter un système de fichiers créé dans FSx for Windows File Server pour une tâche.

{
    "containerDefinitions": [
        {
            "entryPoint": [
                "powershell",
                "-Command"
            ],
            "portMappings": [],
            "command": [...' -Force"],
            "cpu": 512,
            "memory": 256,
            "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
            "essential": false,
            "name": "container1",
            "mountPoints": [
                {
                    "sourceVolume": "fsx-windows-dir",
                    "containerPath": "C:\\fsx-windows-dir",
                    "readOnly": false
                }
            ]
        },
...
    ],
    "family": "fsx-windows",
    "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
    "volumes": [
        {
            "name": "fsx-windows-vol",
            "fsxWindowsFileServerVolumeConfiguration": {
                "fileSystemId": "fs-0eeb5730b2EXAMPLE",
                "authorizationConfig": {
                    "domain": "example.com",
                    "credentialsParameter": "arn:arn-1234"
                },
                "rootDirectory": "share"
            }
        }
    ]
}

Les applications basées sur .NET (.NET 6 ou supérieur) peuvent utiliser l'infrastructure de conteneurs provisionnée et maintenue par Fargate. Fargate utilise Amazon Linux 2, qui est disponible dans les architectures X86_64 ou ARM64. La définition de la tâche spécifie l'architecture requise.

Remarque : Il est également possible d'exécuter d'anciennes applications .NET Core 3.1 et .NET 5 sur Fargate. Cependant, ces deux versions ne sont plus prises en charge par Microsoft, ou ne le seront bientôt plus. .NET 5 n'était pas une version à prise en charge à long terme (LTS) et n'est désormais plus prise en charge. Au moment de la rédaction de cet article, .NET Core 3.1 est en phase de prise en charge de maintenance, ce qui signifie qu'il reste 6 mois maximum avant la fin de la prise en charge et de la réception de correctifs pour des problèmes de sécurité uniquement.

Les conteneurs Windows sur Fargate peuvent exécuter à la fois .NET Framework et les applications .NET. Fargate prend actuellement en charge deux versions de Windows Server pour les applications : Windows Server 2019 Full et Windows Server 2019 Core. Quelle que soit la version que vous utilisez, AWS gère les licences du système d'exploitation Windows pour vous.

Remarque : toutes les fonctionnalités de Windows Server, ainsi que certaines fonctionnalités AWS, ne sont pas disponibles avec les conteneurs Windows sur AWS Fargate. Reportez-vous à la documentation du service pour obtenir des informations à jour sur les limitations et les considérations relatives aux fonctionnalités. Certains exemples de fonctionnalités non prises en charge sont répertoriés ci-dessous.

• Comptes de services gérés par le groupe (GMSA).
• Systèmes de fichiers Amazon FSx (autres que FSx for Windows File Server).
• Stockage éphémère configurable.
• Volumes Amazon Elastic File Store (Amazon EFS).
• Volumes d'images.
• Service App Mesh et intégration de proxy pour les tâches.
  

AWS fournit à chaque compte un registre privé unique dans chaque région AWS, et chaque registre peut contenir aucun ou plusieurs référentiels (au moins un référentiel est requis pour contenir des images). Chaque registre régional d'un compte est accessible à l'aide d'une URL au format https://aws_account_id.dkr.ecr.region.amazonaws.com, par exemple https://123456789012.dkr.ecr.us-west-2.amazonaws.com.

Les référentiels d'un registre privé contiennent à la fois des images et des artefacts Docker et Open Container Initiative (OCI). Vous pouvez utiliser aussi peu ou autant de référentiels que nécessaire pour les images et les artefacts. Par exemple, vous pouvez utiliser un référentiel pour stocker des images pour une phase de développement, un autre pour les images en phase de test, et encore un autre pour les images transmises en phase de production.

Les noms d'image contenus dans une image de référentiel doivent être uniques. Toutefois, les référentiels Amazon ECR prennent également en charge les espaces de noms. Cela permet de réutiliser les noms des images, qui identifient différentes images, à différents stades de l'environnement ou au sein d'équipes différentes dans un référentiel unique.

Par défaut, les comptes ont un accès en lecture et en écriture aux référentiels d'un registre privé. Toutefois, les principaux IAM et les outils qui s'exécutent dans le cadre de ces principaux doivent obtenir des autorisations pour utiliser l'API d'Amazon ECR et pour émettre des commandes pull/push en utilisant des outils tels que la CLI Docker pour les référentiels. De nombreux outils détaillés dans le Module 2 de ce cours gèrent ce processus d'authentification en votre nom.

Les référentiels privés peuvent être créés à l'aide du tableau de bord Amazon ECR dans la console de gestion AWS, dans la vue de l'explorateur AWS de l'AWS Toolkit pour Visual Studio, ou dans la ligne de commande à l'aide de la CLI AWS ou des outils AWS pour PowerShell. La capture d'écran ci-dessous montre la création d'un référentiel privé depuis Visual Studio. Pour ce faire, développez l'entrée Amazon Elastic Container Service dans la vue de l'explorateur AWS et, dans le menu contextuel de l'entrée Référentiels, sélectionnez Créer un référentiel :

L'AWS Toolkit pour Visual Studio ne permet pas d'utiliser votre registre public ECR ni d'activer des fonctionnalités telles que l'analyse automatique et le chiffrement des référentiels pour les nouveaux référentiels de votre registre privé. Si ces fonctionnalités sont requises, créez des référentiels à l'aide de la console de gestion AWS ou d'outils en ligne de commande tels que l'interface de ligne de commande AWS et les outils AWS pour PowerShell.

Les registres et référentiels publics Amazon ECR sont accessibles à tous pour extraire les images que vous publiez. Chaque compte est doté d'un registre public qui peut contenir plusieurs référentiels publics. Tout comme les référentiels privés, les référentiels publics stockent des images et des artefacts Docker et Open Container Initiative (OCI).

Les référentiels des registres publics sont répertoriés dans la galerie publique Amazon ECR. Cela permet à la communauté de trouver et de récupérer des images publiques. Le compte AWS qui possède un registre public dispose d'un accès complet en lecture-écriture aux référentiels qu'il contient. Les principaux IAM qui accèdent aux référentiels doivent obtenir des autorisations fournies dans un jeton et utiliser ce jeton pour s'authentifier et envoyer des images (comme pour les référentiels privés). Cependant, n'importe qui peut extraire des images de vos référentiels publics avec ou sans authentification.

Les dépôts de la galerie sont accessibles à l'aide d'une URL au format https://gallery.ecr.aws/registry_alias/repository_name. Le registry_alias est créé lors de la création du premier référentiel public et peut être modifié. L'URI permettant d'extraire une image d'un référentiel public est au format public.ecr.aws/registry_alias/repository_name:image_tag.

L’envoi d'images vers un référentiel public nécessite des autorisations et une authentification auprès du registre public. Les autorisations sont fournies sous la forme d'un jeton, qui doit être fourni lors de l'authentification auprès du registre. Les images peuvent être extraites d'un référentiel public avec ou sans authentification préalable.

Les caches extractibles mettent en cache les images depuis les registres publics en amont vers votre registre privé dans Amazon ECR. Aujourd'hui, Amazon ECR prend en charge Amazon ECR Public et Quay en tant que registres en amont. Amazon ECR vérifie en amont la présence d'une nouvelle version de l'image et met à jour le cache si une nouvelle version est disponible, une fois toutes les 24 heures. Les caches extractibles peuvent aider à protéger vos processus de création et de déploiement des pannes ou d'autres problèmes affectant les registres en amont.

Les référentiels de cache sont créés automatiquement la première fois qu'une image est extraite d'un registre en amont configuré. Les extractions d'images utilisent les adresses IP AWS et ne sont pas affectées par les quotas de taux d'extraction en place sur le registre en amont. Les extractions d'images vers les référentiels de cache sont configurées à l'aide de règles. Un maximum de 10 règles de cache extractible peuvent être configurées pour votre registre privé.

L'image ci-dessous montre deux exemples de règles, l'une d'elles pour mettre en cache les images depuis Amazon ECR Public et l'autre depuis Quay. Dans cette configuration, la première fois que des images sont extraites d'Amazon ECR Public, un référentiel est automatiquement créé sous l'espace de noms ecr-public en utilisant le nom du référentiel en amont. Il en est de même pour les images extraites de Quay.

L'AWS Toolkit pour Visual Studio ne permet pas d'utiliser votre registre public ECR ni d'activer des fonctionnalités telles que l'analyse automatique et le chiffrement des référentiels pour les nouveaux référentiels de votre registre privé. Si ces fonctionnalités sont requises, créez des référentiels à l'aide de la console de gestion AWS ou d'outils en ligne de commande tels que l'interface de ligne de commande AWS et les outils AWS pour PowerShell.

Les images extraites des registres en amont vers des caches extractibles prennent en charge les fonctionnalités Amazon ECR supplémentaires disponibles pour vos référentiels privés, telles que la réplication et l'analyse automatique des vulnérabilités.

a. Un registre pour stocker des images de conteneurs

b. Un registre des conteneurs en cours d'exécution

c. Un registre des tâches en cours

d. Un registre des volumes de stockage mappés aux conteneurs

a. Vrai

b. Faux

a. Une instance d'un conteneur en cours d'exécution

b. Une définition du conteneur qui sera exécuté

c. Une définition de la composition de vos applications

d. Un groupe logique de ressources informatiques

Réponses : 1-a, 2-b, 3-d