Cargas de trabajo de .NET en Amazon ECS y AWS Fargate

Un clúster es un grupo lógico de recursos informáticos en una región específica. Los clústeres contienen las instancias de contenedor en ejecución que alojan las aplicaciones y los componentes de las aplicaciones, lo que ayuda a aislarlas para que no usen la misma infraestructura subyacente. Esto mejora la disponibilidad en caso de que falle un elemento concreto de la infraestructura que aloja la aplicación. Solo será necesario reiniciar el clúster afectado.

Independientemente de si usa Amazon ECS o Amazon ECS en AWS Fargate, trabajará con clústeres. Lo que difiere es el nivel de gestión que se espera de usted. Si especifica el tipo de lanzamiento EC2 al crear clústeres, asume la responsabilidad de configurar y administrar esos clústeres. Sin embargo, cuando utiliza el tipo de lanzamiento Fargate, es responsabilidad de Fargate gestionarlos.

Un contenedor contiene todo el código, el tiempo de ejecución, las herramientas y las bibliotecas del sistema que necesita la aplicación o el componente de la aplicación en el contenedor para ejecutarse. Cuando inicia instancias de contenedor para alojar sus aplicaciones, se ejecutan en la infraestructura informática asociada a un clúster.

Las plantillas de solo lectura conocidas como imágenes de contenedores se utilizan para lanzar contenedores. Antes de poder utilizar una imagen para ejecutar los contenedores, debe desplegar la imagen del contenedor en un registro, por ejemplo, Amazon Elastic Container Registry (Amazon ECR) o Docker Hub.

Las imágenes de los contenedores se definen mediante un recurso denominado Dockerfile. Un Dockerfile es un archivo de texto que detalla todos los componentes y recursos que quiere incluir en la imagen. Amazon ECS usa el mismo Dockerfile que se usa para definir imágenes de contenedores para aplicaciones .NET en otros lugares, sin cambios. Con el comando docker build, convierte los comandos y la configuración definidos en el Dockerfile en una imagen de contenedor que puede enviar a un registro o ejecutar localmente en Docker. Las herramientas de contenedores disponibles en AWS, que se detallan en el módulo 2, a menudo gestionarán la creación y el envío de la imagen por usted.

Una definición de la tarea es un archivo de texto en formato JSON que se utiliza para describir los contenedores que componen la aplicación. Una sola definición de la tarea puede describir hasta 10 contenedores.

Puede pensar en una definición de la tarea como un esquema del entorno de aplicaciones, en el que se especifican los parámetros de la aplicación y del sistema operativo. Algunos ejemplos son qué puertos de red deben estar abiertos y cualquier volumen de datos que deba adjuntarse, entre otros recursos.

Amazon ECS no restringe su aplicación a una sola definición de la tarea. De hecho, se recomienda combinar los contenedores relacionados de un componente que forme parte de la aplicación en una sola definición de la tarea y utilizar varias definiciones de las tareas para describir toda la aplicación. Esto permite que los diferentes componentes lógicos que componen la aplicación se escalen de forma independiente.

Considere una aplicación web típica de niveles N, que comprende un nivel de interfaz de usuario web, un nivel de API, un nivel intermedio y niveles de componentes de base de datos. La siguiente imagen muestra cómo puede agrupar estos niveles de componentes en diferentes definiciones de las tareas. Esto permite, por ejemplo, que el nivel de la interfaz de usuario web se escale horizontalmente, independientemente de los demás componentes y viceversa, si experimenta un aumento de uso. Si definiera todos los niveles en una sola definición de la tarea, toda la aplicación se escalaría en función de la carga, incluidos los niveles que no experimentaran un mayor uso, lo que aumentaría el tiempo de escalamiento horizontal (si la aplicación es grande) y, posiblemente, aumentarían los costos financieros.

A continuación, encontrará un ejemplo de definición de la tarea. Configure un servidor web mediante contenedores de Linux en el tipo de lanzamiento 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" 
    ]
}

Cuando Amazon ECS crea una instancia de una definición de la tarea, crea una o más tareas que se ejecutan dentro de un clúster. Una tarea es una instancia de contenedor en ejecución. Además de otras configuraciones del entorno, la definición de la tarea especifica la cantidad de tareas, o instancias de contenedor, que se van a ejecutar en el clúster.

Puede configurar las tareas para que se ejecuten de forma independiente, lo que hace que el contenedor se detenga cuando se complete la tarea, o puede ejecutar tareas de forma continua como un servicio. Cuando se ejecuta como parte de un servicio, Amazon ECS mantiene una cantidad específica de tareas en ejecución de forma simultánea y reemplaza automáticamente los contenedores fallidos.

Utilice una tarea independiente para el código de la aplicación que no necesite ejecutarse de forma continua. El código se ejecuta una vez dentro de la tarea y, a continuación, finaliza con la instancia del contenedor. Un ejemplo sería el procesamiento por lotes de algunos datos.

Las tareas independientes se pueden configurar para que se ejecuten según una programación o en respuesta a un evento. Estas se denominan tareas programadas. En ambos casos, Amazon EventBridge se utiliza para definir una programación cron o un evento que provocará la ejecución de la tarea. Las programaciones cron configuran una tarea para que se ejecute cada enésimo minuto, hora o día. Para que las tareas programadas se ejecuten cuando se produce un evento, puede suscribirse a eventos definidos por AWS o a sus propios eventos personalizados en Amazon EventBridge. Cuando se produzcan los eventos, Amazon ECS ejecutará la tarea automáticamente.

Use tareas programadas para el código de la aplicación que debe ejecutarse periódicamente sin la intervención del operador para iniciar la tarea manualmente. Ejemplos de escenarios son el código para realizar la inspección de registros, las operaciones de respaldo o los trabajos periódicos de extracción, transformación y carga (ETL).

Un servicio es un conjunto de una o más tareas que se ejecutan de forma continua. En la definición de las tareas, usted define la cantidad de tareas que debe mantener el servicio y Amazon ECS supervisa los contenedores para garantizar que la cantidad de tareas solicitadas esté siempre disponible.

Amazon ECS ejecuta un agente en cada instancia de contenedor de un clúster. No necesita instalar ni mantener este agente usted mismo. El agente proporciona información sobre las tareas en ejecución y el uso de las instancias del contenedor, lo que permite a Amazon ECS detectar las tareas que fallan o se detienen. Cuando esto ocurre, Amazon ECS reemplaza las tareas que fallaron por nuevas instancias para mantener la cantidad especificada de tareas en el servicio, sin necesidad de que usted mismo supervise y tome medidas.

Utilice un servicio para el código de la aplicación que deba ejecutarse de forma continua. Algunos ejemplos son la interfaz de un sitio web o una API web.

El código de aplicación que se ejecuta en una instancia de contenedor suele necesitar leer o escribir datos con estado. Algunos ejemplos son los archivos de datos temporales, los datos obtenidos de un servicio externo que desea almacenar en caché localmente durante un período breve y las bases de datos, incluidas las que utilizan SQL Server en instancias de Amazon EC2, instancias de Amazon Relational Database Service (RDS) y otros contenedores. Como alternativa, es posible que las aplicaciones que escalan en varias instancias de contenedores necesiten acceder al almacenamiento compartido para datos temporales y a largo plazo.

Las instancias de contenedor en ejecución tienen una capa en la que se puede escribir y que puede almacenar datos. Sin embargo, la capa escribible es transitoria y se destruye cuando la instancia del contenedor finaliza ya sea por una acción del usuario o porque la instancia pasa a estar en mal estado y Amazon ECS la reemplaza. Esto hace que la capa escribible sea un enfoque inadecuado para el almacenamiento de datos a largo plazo, como los datos de una base de datos. Además, solo se puede acceder a los datos de la capa escribible mediante el código que se ejecuta en la instancia de contenedor individual, por lo que no es adecuado para los datos que necesita compartir en una aplicación que abarca varias instancias de contenedor.

Para permitir que los datos de las aplicaciones se almacenen durante un período superior a la vida útil de una instancia de contenedor o que se puedan compartir en varias instancias de contenedor, AWS proporciona varios servicios de almacenamiento. Estos servicios de almacenamiento desacoplan el almacenamiento de datos de las instancias informáticas. El uso del almacenamiento desacoplado de las instancias de procesamiento permite que los datos de la aplicación sobrevivan a las instancias de contenedor en las que se ejecuta la aplicación y hace que los datos se puedan compartir en varias instancias.

Los servicios de almacenamiento disponibles para las aplicaciones .NET en contenedores dependen de si las aplicaciones se ejecutan en contenedores de Linux o Windows.

Los contenedores de Linux actualmente admiten el conjunto más amplio de servicios de almacenamiento para aplicaciones .NET cuando se ejecutan en Amazon ECS o Amazon ECS en AWS Fargate. La elección del servicio de almacenamiento dependerá de si la aplicación necesita un acceso compartido y simultáneo a los datos.

Amazon Elastic Block Store (Amazon EBS) es un servicio de almacenamiento que proporciona volúmenes de almacenamiento a nivel de bloque. Un volumen de EBS proporciona a las aplicaciones un almacenamiento que se puede montar en contenedores de Linux, al que se accede igual que a un dispositivo de disco normal. Amazon EBS replica automáticamente los datos de los volúmenes de EBS dentro de una zona de disponibilidad, lo que lo convierte en una solución de almacenamiento fiable que ayuda a mejorar la fiabilidad de las aplicaciones en caso de que falle un volumen de almacenamiento.

Los volúmenes de EBS se pueden cambiar de tamaño de forma dinámica, admiten el cifrado y también admiten instantáneas para realizar copias. Si es necesario, puede separar los volúmenes de un contenedor y volver a conectarlos a otro diferente. Para adaptarse a los requisitos de rendimiento y precio de su aplicación, Amazon EBS ofrece diferentes tipos de volúmenes.

Los volúmenes de EBS se crean en una zona de disponibilidad específica de una región. Luego el volumen se puede montar en una instancia de contenedor, utilizando la configuración de la definición de la tarea, que se ejecuta en la misma zona. Para acceder a los mismos datos desde una zona de disponibilidad diferente, haga una instantánea del volumen y utilícela para crear un volumen nuevo en otro lugar de la misma región o de otra diferente. Una sola instantánea puede crear muchos volúmenes en todas las zonas de disponibilidad y regiones. Este es un enfoque que se debe tener en cuenta para los datos de aplicaciones de solo lectura que van a consumir las aplicaciones que requieren alta disponibilidad y que se han implementado en varias instancias de contenedores que abarcan diferentes zonas de disponibilidad y regiones.

Amazon EBS es una buena solución de almacenamiento a tener en cuenta para las aplicaciones que requieren un acceso rápido y de baja latencia a los datos que no se comparten de forma simultánea, ya que las aplicaciones se escalan horizontalmente (es decir, se ejecutan en varias instancias de contenedores). Los ejemplos incluyen sistemas de archivos y bases de datos generales a los que se accede desde una única instancia de contenedor.

Amazon EBS no admite el acceso simultáneo a un volumen. Para aplicaciones en las que las aplicaciones necesitan compartir un único sistema de archivos montado en varios contenedores, considere usar Amazon Elastic File Service o uno de los sistemas de archivos disponibles en Amazon FSx.

Amazon EFS proporciona un servicio de sistema de archivos escalable, al que se accede mediante el sistema de archivos de red (NFS), que no requiere que administre el almacenamiento. Los sistemas de archivos gestionados a través de Amazon EFS se pueden adjuntar a varias instancias de contenedores basadas en Linux de forma simultánea, con coherencia de lectura y escritura y bloqueo de archivos. Esto brinda la posibilidad de compartir datos en una unidad, con acceso de lectura y escritura, en varios contenedores que alojan una aplicación escalable. El almacenamiento de Amazon EFS también es dinámico y amplía (y reduce) la capacidad automáticamente a medida que cambian las necesidades de almacenamiento de las aplicaciones.

Solo paga por el almacenamiento que consumen sus aplicaciones. De forma predeterminada, los datos de los sistemas de archivos creados en Amazon EFS se almacenan en varias zonas de disponibilidad de una región para ofrecer resiliencia y durabilidad. Amazon EFS se refiere a este modo como clase de almacenamiento estándar. Si una aplicación no necesita un almacenamiento Multi-AZ completo, utilice la clase de almacenamiento One Zone para ahorrar costos. Las clases de almacenamiento de acceso poco frecuente estándar y acceso poco frecuente de una zona también están disponibles para alojar datos a los que las aplicaciones acceden de forma no regular para ahorrar costos adicionales.

Los sistemas de archivos Amazon EFS son adecuados para una amplia gama de aplicaciones, incluidas las aplicaciones web, los sistemas de administración de contenido, las carpetas principales de los usuarios y los servidores de archivos generales. Los sistemas de archivos admiten la autenticación, la autorización y el cifrado. El control de acceso usa permisos POSIX estándar.

El siguiente fragmento de definición de tarea de ejemplo muestra cómo montar un sistema de archivos EFS para una tarea.

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

Lustre es un sistema de archivos de código abierto diseñado para satisfacer las necesidades de rendimiento de machine learning, la computación de alto rendimiento (HPC), el procesamiento de vídeo y el modelado financiero. Para las aplicaciones .NET que abordan esas soluciones u otros escenarios que requieren latencias inferiores a un milisegundo, Amazon FSx para Lustre puede proporcionar la capa de almacenamiento persistente para los contenedores de Linux.

Nota: al momento en el que se escribe este artículo, las tareas que se ejecutan en AWS Fargate no admiten FSx para los sistemas de archivos Lustre.

Los sistemas de archivos creados en fSx para Lustre son compatibles con POSIX. Esto significa que puede seguir utilizando los mismos controles de acceso a archivos conocidos que ya utiliza para las aplicaciones .NET que se ejecutan en Linux. Los sistemas de archivos alojados en fSx para Lustre también proporcionan coherencia de lectura y escritura y bloqueo de archivos.

En función de las necesidades de la aplicación, está disponible una selección de almacenamiento en estado sólido (SSD) y en disco duro (HDD), optimizados para diferentes requisitos de carga de trabajo. El almacenamiento SSD es adecuado para aplicaciones con un uso intensivo de IOPS que son sensibles a la latencia y que, por lo general, utilizan pequeñas operaciones de archivos de acceso aleatorio. El tipo de almacenamiento HDD es adecuado para aplicaciones con requisitos de alto rendimiento, que normalmente implican operaciones de archivos grandes y secuenciales. Con el almacenamiento en disco duro, también puede añadir una caché SSD de solo lectura, con un tamaño del 20 % del almacenamiento del disco duro, para permitir una latencia inferior a un milisegundo y un IOPS más alto, lo que mejora el rendimiento de los archivos a los que se accede con frecuencia.

Los sistemas de archivos de FSx para Lustre también se pueden vincular a un bucket de Amazon S3, con acceso completo de lectura y escritura. Esto proporciona a la aplicación .NET la capacidad de procesar objetos del bucket de S3 como si ya estuvieran en un sistema de archivos, una opción para las aplicaciones creadas para procesar datos de grandes conjuntos de datos basados en la nube que ya están en S3 sin necesidad de copiar esos datos en un sistema de archivos antes de acceder a ellos y actualizarlos.

Tenga en cuenta que también puede montar sistemas de archivos Lustre mediante un comando en su contenedor Docker a través del paquete lustre-client; esto le permite montar sistemas de archivos de forma dinámica dentro del contenedor.

Para los contenedores de Windows que ejecutan aplicaciones .NET y .NET Framework, el almacenamiento de archivos proporcionado por Amazon FSx para Windows File Server está disponible para la persistencia de los datos y el intercambio de datos en uno o más contenedores que se ejecutan en una tarea.

fSx para Windows File Server usa instancias reales de Windows File Server, accesibles mediante recursos compartidos de archivos estándar de Windows a través de SMB, para almacenar y servir los datos de las aplicaciones. Los recursos compartidos de archivos estándar de Windows permiten el uso de funciones y herramientas administrativas que ya conocen los administradores de servidores de archivos de Windows, como la restauración de archivos del usuario final mediante instantáneas, cuotas de usuarios y listas de control de acceso (ACL). SMB también permite la conexión a un recurso compartido de FSx para Windows File Server desde contenedores de Linux.

Los sistemas de archivos de fSx para Windows File Server pueden ayudar a reducir los costos de almacenamiento de las aplicaciones que utilizan la deduplicación y compresión de datos. Las funciones adicionales incluyen el cifrado de datos, el acceso a archivos auditables y las copias de seguridad automáticas programadas. El acceso a los recursos compartidos del sistema de archivos se puede controlar mediante la integración con un Microsoft Active Directory (AD) local o un AD administrado en AWS.

FSx para Windows File Server es adecuado para migrar servidores de archivos locales basados en Windows a la nube para que funcionen junto con aplicaciones .NET/.NET Framework en contenedores. También es adecuado para su uso con aplicaciones .NET y .NET Framework que necesitan acceso a almacenes de datos locales y en la nube híbrida (con Amazon FSx File Gateway). Para las aplicaciones que utilizan SQL Server, fSx para Windows File Server permite ejecutar estas cargas de trabajo de bases de datos sin necesidad de licencias de SQL Server Enterprise.

El siguiente ejemplo de definición de tarea muestra cómo montar un sistema de archivos creado en fSx para Windows File Server para una tarea.

{
    "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"
            }
        }
    ]
}

Las aplicaciones basadas en .NET (.NET 6 o superior) pueden usar la infraestructura de contenedores aprovisionada y mantenida por Fargate. Fargate usa Amazon Linux 2, que está disponible en las arquitecturas X86_64 o ARM64. La definición de la tarea especifica la arquitectura requerida.

Nota: también es posible ejecutar aplicaciones antiguas basadas en .NET Core 3.1 y .NET 5 en Fargate. Sin embargo, ninguna de las dos versiones cuenta con el soporte de Microsoft, o si aún no es así, sucederá pronto. .NET 5 no era una versión de soporte a largo plazo (LTS) y ahora no tiene soporte. Al momento en el que se escribe este artículo, .NET Core 3.1 se encuentra en la fase de soporte de mantenimiento, lo que significa que faltan 6 meses o menos para que finalice el soporte y empiece a recibir parches solo para problemas de seguridad.

Los contenedores de Windows de Fargate pueden ejecutar aplicaciones .NET Framework y .NET. Fargate admite actualmente dos versiones de Windows Server para aplicaciones: Windows Server 2019 Full y Windows Server 2019 Core. Sea cual sea la versión que utilice, AWS administra las licencias del sistema operativo Windows por usted.

Nota: no todas las funciones de Windows Server, y algunas de AWS, están disponibles con los contenedores de Windows en AWS Fargate. Consulte la documentación de servicio para obtener información actualizada sobre las limitaciones y consideraciones de las características. A continuación se enumeran algunos ejemplos de características no compatibles.

• Cuentas de servicios administradas por grupos (gMSA).
• Sistemas de archivos Amazon FSx (aparte de FSx para Windows File Server).
• Almacenamiento efímero configurable.
• Volúmenes de Amazon Elastic File Store (Amazon EFS).
• Volúmenes de imágenes.
• Integración de proxy y servicio App Mesh para tareas.
  

AWS proporciona a cada cuenta un único registro privado en cada región de AWS, y cada registro puede contener cero o más repositorios (se requiere al menos un repositorio para contener imágenes). Se puede acceder a cada registro regional de una cuenta mediante una URL de formato https://aws_account_id.dkr.ecr.region.amazonaws.com, por ejemplo https://123456789012.dkr.ecr.us-west-2.amazonaws.com.

Los repositorios de un registro privado contienen imágenes y artefactos de Docker y Open Container Initiative (OCI). Puede utilizar tantos o tan pocos repositorios como necesite para imágenes y artefactos. Por ejemplo, puede utilizar un repositorio para almacenar imágenes para una fase de desarrollo, otro para imágenes en fase de prueba y otro para imágenes publicadas en una fase de producción.

Los nombres de las imágenes dentro de una imagen de repositorio deben ser únicos; sin embargo, los repositorios de Amazon ECR también admiten espacios de nombres. Esto permite que los nombres de las imágenes, que identifican diferentes imágenes, se reutilicen en diferentes etapas o equipos del entorno en un único repositorio.

Las cuentas tienen acceso de lectura y escritura a los repositorios de un registro privado de forma predeterminada. Sin embargo, las entidades principales de IAM y las herramientas que se ejecuten en el ámbito de estas deben obtener permisos para utilizar la API de Amazon ECR y emitir comandos inserción/extracción mediante herramientas como la CLI de Docker en los repositorios. Muchas de las herramientas detalladas en el módulo 2 de este curso gestionan este proceso de autenticación por usted.

Los repositorios privados se pueden crear mediante el panel de Amazon ECR de la consola de administración de AWS, en la vista del Kit de herramientas de AWS para Visual Studio del Explorador de AWS o en la línea de comandos mediante la CLI de AWS o las AWS Tools para PowerShell. La siguiente captura de pantalla muestra la creación de un repositorio privado desde Visual Studio. Para hacer esto, expanda la entrada Amazon Elastic Container Service en la vista del Explorador de AWS y, en el menú contextual de la entrada Repositorios, seleccione Crear repositorio:

El kit de herramientas de AWS para Visual Studio no permite trabajar con su registro público de ECR ni habilitar funciones como el escaneo automático y el cifrado de repositorios para nuevos repositorios en su registro privado. Si se requieren esas funciones, cree repositorios con la consola de administración de AWS o herramientas de línea de comandos, como la CLI de AWS y las AWS Tools para PowerShell.

Los registros y repositorios públicos de Amazon ECR están disponibles para que cualquiera pueda extraer las imágenes que publique. Cada cuenta tiene un registro público que puede contener varios repositorios públicos. Al igual que los repositorios privados, los repositorios públicos almacenan imágenes y artefactos de Docker y Open Container Initiative (OCI).

Los repositorios de los registros públicos se enumeran en la Galería pública de Amazon ECR. Esto le permite a la comunidad encontrar y extraer imágenes públicas. La cuenta de AWS que posee un registro público tiene acceso completo de lectura y escritura a los repositorios que contiene. Las entidades principales de IAM que accedan a los repositorios deben obtener los permisos que se proporcionan en un token y usar ese token para autenticarse y enviar imágenes (al igual que ocurre con los repositorios privados). Sin embargo, cualquier persona puede extraer imágenes de sus repositorios públicos con o sin autenticación.

Se accede a los repositorios de la galería mediante una URL de formato https://gallery.ecr.aws/registry_alias/repository_name. El registry_alias se crea cuando se crea el primer repositorio público y se puede cambiar. E URI para extraer una imagen de un repositorio público tiene el formato public.ecr.aws/registry_alias/repository_name:image_tag.

Para enviar imágenes a un repositorio público se requieren permisos y autenticación en el registro público. Los permisos se proporcionan en un token, que se debe proporcionar al autenticarse en el registro. Las imágenes se pueden extraer de un repositorio público con o sin autenticación previa.

Extraiga imágenes de caché de registros públicos anteriores a su registro privado en Amazon ECR. Actualmente, Amazon ECR admite Amazon ECR Public y Quay como registros ascendentes. Amazon ECR comprueba en la versión ascendente una nueva versión de la imagen y actualiza la caché, si hay una nueva versión disponible, una vez cada 24 horas. Las cachés extraíbles pueden ayudar a aislar los procesos de creación y despliegue de las interrupciones u otros problemas que afecten a los registros anteriores.

Los repositorios de caché se crean automáticamente la primera vez que se extrae una imagen de un registro anterior configurado. Las extracciones de imágenes utilizan direcciones IP de AWS y no se ven afectadas por las cuotas de tasas de extracción establecidas en el registro anterior. Las extracciones de imágenes a los repositorios de caché se configuran mediante reglas. Puede configurar un máximo de 10 reglas de extracción de caché para su registro privado.

La siguiente imagen muestra dos reglas de ejemplo, una para almacenar en caché imágenes de Amazon ECR Public y la segunda de Quay. En esta configuración, la primera vez que se extraigan imágenes de Amazon ECR Public, se creará automáticamente un repositorio en el espacio de nombres ecr-public con el nombre del repositorio anterior y, de forma similar, para las imágenes extraídas de Quay.

El kit de herramientas de AWS para Visual Studio no permite trabajar con su registro público de ECR ni habilitar funciones como el escaneo automático y el cifrado de repositorios para nuevos repositorios en su registro privado. Si se requieren esas funciones, cree repositorios con la consola de administración de AWS o herramientas de línea de comandos, como la CLI de AWS y las AWS Tools para PowerShell.

Las imágenes extraídas de los registros anteriores y almacenadas en cachés de extracción admiten funciones adicionales de Amazon ECR disponibles en sus repositorios privados, como la replicación y el análisis automático de vulnerabilidades.

a. Un registro para almacenar imágenes de contenedores

b. Un registro de contenedores en ejecución

c. Un registro de tareas en ejecución

d. Un registro de volúmenes de almacenamiento mapeados a contenedores

a. Verdadero

b. Falso

a. Una instancia de un contenedor en ejecución

b. Una definición del contenedor que se ejecutará

c. Una definición de lo que compone su solicitud

d. Un grupo lógico de recursos informáticos

Respuestas: 1-a, 2-b, 3-d