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

MÓDULO 1

Módulo 1: comprensión de Amazon ECS, ECR y AWS Fargate

 MÓDULO DE APRENDIZAJE

Información general

Este módulo presenta Amazon ECS, Amazon ECS en AWS Fargate y Amazon ECR. Aprenderá sobre clústeres, contenedores e imágenes, tareas y definiciones de tareas, servicios y tipos de lanzamiento para contenedores que se ejecutan en Linux y Windows. Por último, reunirá todos estos elementos para examinar los escenarios y las rutas que puede tomar para llegar a la mejor solución de contenedores con Amazon ECS o Amazon ECS en AWS Fargate para sus aplicaciones .NET.

 Tiempo de realización

30 minutos

Introducción a Amazon ECS

Amazon ECS es un servicio que se utiliza para ejecutar aplicaciones basadas en contenedores en la nube. Proporciona una administración de contenedores rápida y altamente escalable, y se integra con otros servicios de AWS para proporcionar seguridad, orquestación de contenedores, integración y despliegue continuos, detección de servicios, monitoreo y observabilidad.

Los contenedores se lanzan mediante imágenes de contenedores, de forma similar a como se lanzan máquinas virtuales a partir de imágenes de máquinas virtuales. Amazon ECS despliega y ejecuta contenedores a partir de imágenes de contenedores desplegadas en Amazon Elastic Container Registry (Amazon ECR) o Docker Hub.

Amazon ECS usa definiciones de las tareas para definir los contenedores que componen su aplicación. Una definición de la tarea especifica cómo se ejecutan los contenedores de la aplicación. Puede definir y usar una tarea individual, que se ejecuta y se detiene al finalizar, o puede definir que la tarea debe ejecutarse dentro de un servicio. Los servicios ejecutan y mantienen de forma continua un número específico de tareas de forma simultánea, lo que resulta adecuado para aplicaciones de ejecución prolongada, como las aplicaciones web.

Si es necesario, puede optar por configurar y administrar la infraestructura que aloja sus contenedores o utilizar Amazon ECS en AWS Fargate para aprovechar un enfoque sin servidores en el que AWS administra la infraestructura de contenedores y usted se centra en su aplicación. Amazon ECS ofrece dos modelos para ejecutar contenedores, denominados tipos de lanzamiento.

Tipo de lanzamiento EC2

El tipo de lanzamiento EC2 se usa para ejecutar contenedores en una o más instancias de Amazon Elastic Compute Cloud (EC2) configuradas en clústeres. Cuando usa el tipo de lanzamiento EC2, tiene control total sobre la configuración y administración de la infraestructura que aloja sus contenedores.

Elija el tipo de lanzamiento EC2 para sus contenedores cuando deba administrar su infraestructura o cuando sus aplicaciones requieran un uso elevado y constante de núcleos de CPU y memoria, tengan que estar optimizadas en cuanto a precios o necesiten almacenamiento persistente.

Tipo de lanzamiento Fargate

El tipo de lanzamiento Fargate es una opción de pago por uso sin servidor para ejecutar sus contenedores. Sin servidor significa que no tiene que configurar la infraestructura para alojar sus instancias de contenedor, a diferencia del tipo de lanzamiento EC2, que requiere que comprenda cómo configurar y administrar clústeres de instancias para alojar los contenedores en ejecución.

Recursos de Amazon ECS

Además de utilizar los tipos de lanzamiento para controlar cómo desea administrar su infraestructura de contenedores, encontrará y utilizará varios tipos de recursos cuando trabaje con Amazon ECS.

Clúster

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.

Contenedor

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.

definición de la tarea

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

Tarea

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.

Tarea programada

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).

Servicio

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.

Datos de aplicación persistentes

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.

Opciones de almacenamiento persistente para contenedores de Linux

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)

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 Elastic File System (Amazon EFS)

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

Amazon FSx para Lustre

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.

Opciones de almacenamiento persistente para contenedores de Windows

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.

Amazon FSx para Windows File Server

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

Otras opciones de almacenamiento persistente

AWS ofrece otros servicios de sistemas de archivos especializados para gestionar las necesidades de almacenamiento persistentes para las tareas en ECS. Este curso no cubrirá estos sistemas de archivos y servicios; sin embargo, lo remitimos a los detalles del producto que aparecen a continuación.

  • Amazon FSx para OpenZFS proporciona un almacenamiento de archivos totalmente administrado mediante el sistema de archivos OpenZFS. OpenZFS es un sistema de archivos de código abierto para cargas de trabajo que requieren un almacenamiento de alto rendimiento y funciones que incluyen instantáneas de datos instantáneas, cifrado y clonación. Se puede acceder al almacenamiento de OpenZFS mediante NFS y permite una migración sencilla de los servidores de archivos de Linux a la nube para usarlos con contenedores de aplicaciones .NET.
  • Amazon FSx para NetApp ONTAP es otro servicio de almacenamiento de archivos totalmente gestionado que proporciona funciones de gestión y acceso a los datos. Las aplicaciones acceden a los sistemas de archivos ONTAP de NetApp mediante los protocolos NFS, SMB e iSCSI.

Introducción a AWS Fargate

Un enfoque sin servidores para aprovisionar y administrar la infraestructura de nube resulta atractivo para muchos desarrolladores y organizaciones. Con la tecnología sin servidor, AWS gestiona el aprovisionamiento y la administración sin distinción de los recursos de infraestructura para alojar aplicaciones por usted. Esto le permite a usted, el desarrollador, centrarse en su aplicación. Usted especifica lo que las aplicaciones necesitan para ejecutarse y escalarse. Cómo hacerlo es responsabilidad de AWS.

AWS Fargate es un enfoque sin servidor para alojar contenedores en la nube. Cuando elige Fargate para aplicaciones basadas en Amazon ECS o Amazon EKS, ya no deberá administrar servidores o clústeres de instancias de Amazon EC2 para alojar aplicaciones basadas en contenedores. Fargate gestiona el aprovisionamiento, la configuración y el escalado y desescalado vertical de la infraestructura de contenedores según sea necesario.

Como desarrollador, su preocupación es definir la creación de las imágenes de sus contenedores mediante un Dockerfile y el despliegue de esas imágenes creadas en Amazon ECR o Docker Hub. Para la infraestructura de ejecución de las aplicaciones, solo tiene que especificar las políticas del sistema operativo, la CPU y la memoria, las redes y la IAM. Fargate luego aprovisiona y escala la infraestructura de contenedores que cumple con esos requisitos. Fargate admite la ejecución de aplicaciones .NET y .NET Framework como servicios, tareas y tareas programadas.

Los desarrolladores de .NET que deseen utilizar Amazon ECS en AWS Fargate pueden elegir entre entornos Windows Server o Linux. Las aplicaciones .NET Framework deben utilizar contenedores de Windows Server. Sin embargo, las aplicaciones creadas con .NET pueden elegir entre entornos Windows Server o Linux.

Nota: para las aplicaciones que utilizan una combinación de contenedores de Windows Server y Linux, se requieren tareas independientes para los distintos entornos.

.NET en contenedores de Linux en AWS Fargate

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.

.NET en contenedores de Windows en AWS Fargate

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.

Cómo elegir entre Amazon ECS y Amazon ECS en AWS Fargate

Utilice lo siguiente para determinar si debe seleccionar Amazon ECS o Amazon ECS en AWS Fargate para alojar sus aplicaciones .NET:

  • Si prefiere aprovisionar, administrar y escalar clústeres y otra infraestructura para alojar sus tareas, o si necesita autoadministrar esta infraestructura, elija Amazon ECS.
  • Si prefiere permitir que AWS aprovisione, administre y escale la infraestructura que respalda sus aplicaciones en contenedores, elija AWS Fargate. AWS Fargate admite contenedores de Windows para aplicaciones .NET Framework o de Linux para aplicaciones .NET.
  • Para las aplicaciones .NET que utilizan Amazon FSx para Windows File Server a fin de proporcionar volúmenes de almacenamiento persistente adicionales a sus contenedores, elija Amazon ECS. AWS Fargate no admite esta opción de almacenamiento al momento en el que se escribe este artículo.

Imágenes de contenedores y Amazon Elastic Container Registry (Amazon ECR)

Amazon ECR es un registro de contenedores escalable, seguro y totalmente gestionado para imágenes de contenedores de Docker y Open Container Initiative (OCI). Sus características facilitan el almacenamiento, la administración y el despliegue de imágenes de contenedores, ya sea que utilice Amazon ECS o Amazon ECS en AWS Fargate. Al ser un servicio totalmente gestionado, Amazon ECR proporciona, administra y escala la infraestructura necesaria para respaldar sus registros.

Nota: también puede utilizar Docker Hub para almacenar las imágenes de sus contenedores cuando trabaje con Amazon ECS y AWS Fargate.

Amazon ECR proporciona a cada cuenta un registro privado predeterminado en cada región de AWS. El registro se usa para administrar uno o más repositorios privados que contienen imágenes de contenedores. Antes de enviar imágenes a un repositorio o extraerlas de él, los clientes deben obtener un token de autorización que luego se usa para autenticar el acceso a un registro. A medida que las imágenes se envían a los repositorios, Amazon ECR ofrece un análisis automático de vulnerabilidades como característica opcional. Los repositorios también admiten el cifrado a través de AWS Key Management Service (KMS), con la opción de utilizar una clave proporcionada por AWS o una clave personalizada administrada por el usuario.

Para controlar el acceso, Amazon ECR se integra con AWS IAM. Los permisos detallados basados en recursos permiten controlar quién (o qué) puede acceder a las imágenes y los repositorios de los contenedores. Las políticas administradas, proporcionadas por Amazon ECR, también están disponibles para controlar los distintos niveles de acceso.

Con una configuración por registro, los repositorios se pueden replicar en todas las regiones y otras cuentas. También se pueden configurar políticas de ciclo de vida de imágenes adicionales. Por ejemplo, puede configurar (y probar) una política de ciclo de vida que dé como resultado la limpieza de las imágenes no utilizadas en un repositorio.

Los registros públicos y privados están disponibles en Amazon ECR. También está disponible una memoria caché desplegable para imágenes de contenedores extraídas de otros registros públicos. Las cachés extraíbles aíslan las compilaciones y despliegues de las interrupciones en los registros y repositorios iniciales, y también ayudan a los equipos de desarrollo a someterse a auditorías de cumplimiento para dependencias.

Revise las siguientes características para obtener más información sobre los registros públicos y privados de Amazon ECR, los repositorios que contienen y consulte los repositorios de caché.

Registro y repositorios privados

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.

Registro público y repositorios

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.

Repositorios de caché de extracción

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.

Insertar y extraer imágenes

Las cuentas tienen acceso de lectura y escritura a los repositorios de sus registros públicos y privados de forma predeterminada. Sin embargo, las entidades principales de IAM de esas cuentas y las herramientas que se ejecuten en el ámbito de estas deben obtener permisos para utilizar los comandos de inserción/extracción y la API de Amazon ECR. Estos permisos aparecen como un token de autorización, que debe proporcionarse al autenticar el acceso a un registro público o privado de Amazon ECR.

Nota: si bien las entidades principales de IAM necesitan permisos para enviar y extraer imágenes a repositorios privados y enviar imágenes a repositorios públicos, cualquier persona puede extraer imágenes de los repositorios públicos del registro público de una cuenta sin autenticación, lo que se denomina extracción no autenticada.

Autorizar el acceso al repositorio en la línea de comandos

Muchas de las herramientas de AWS mencionadas en el módulo 2 de este curso se encargarán de obtener el token y usarlo para autenticarse en su registro privado, pero, de ser necesario, puede realizar los mismos pasos usted mismo, por ejemplo, al acceder a un registro desde una canalización de CI/CD. Como alternativa, existe una utilidad de asistente de credenciales de Amazon ECR en GitHub; consulte Amazon ECR Docker Credential Helper para obtener más información (este curso no proporciona más información sobre cómo usar esta utilidad).

La CLI de AWS y las AWS Tools para PowerShell contienen comandos para obtener fácilmente un token de autorización, que luego se usa con herramientas como Docker Client para la inserción/extracción de imágenes. Ambos comandos procesan la salida del servicio y emiten el token requerido. Para los escenarios en los que el uso de la línea de comandos no es adecuado o para herramientas personalizadas, está disponible una llamada getAuthorizationToken a la API de Amazon ECR.

Nota: los permisos del token de autorización no superan los permisos otorgados a la entidad principal de IAM que lo solicita. El token es válido durante 12 horas.

Para autenticar Docker con un registro de Amazon ECR mediante la CLI de AWS, utilice el comando get-login-password y canalice el resultado a docker login, especificando AWS como nombre de usuario y URL del registro:

aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

Para utilizar las AWS Tools para PowerShell a fin de autenticar un cliente de Docker, utilice el comando Get-ECRLoginCommand (disponible en el módulo AWS.Tools.ecr o en los módulos AWSPowerShell y AWSPowerShell.NetCore). Canalice la propiedad Password del objeto de salida al comando docker login y especifique AWS como nombre de usuario y URL del registro:

(Get-ECRLoginCommand -Region region).Password | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

Una vez autorizado el cliente Docker, las imágenes se pueden enviar o extraer de los repositorios del registro. Tenga en cuenta que se requieren tokens de autorización independientes para los registros de diferentes regiones.

Insertar una imagen

Los permisos de IAM son necesarios para enviar imágenes a repositorios públicos y privados. Como práctica recomendada, considere la posibilidad de reducir el alcance de los permisos de las entidades principales de IAM a repositorios específicos. La política de ejemplo que aparece a continuación muestra las operaciones de la API de Amazon ECR (“Acción”) que requiere una entidad principal para enviar imágenes, en el ámbito de un repositorio específico. Cuando se especifican los repositorios, se utiliza el nombre de recurso de Amazon (ARN) para identificarlos. Tenga en cuenta que se pueden especificar varios repositorios (en un elemento de matriz) o utilizar un comodín (*) para ampliar el alcance a todos los repositorios.

Para utilizar la política que se indica a continuación, sustituya 111122223333 por el ID de su cuenta de AWS, la región por la región en la que se encuentra el repositorio y defina el nombre del repositorio.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:CompleteLayerUpload",
        "ecr:GetAuthorizationToken",
        "ecr:UploadLayerPart",
        "ecr:InitiateLayerUpload",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage"
      ],
      "Resource":
          "arn:aws:ecr:region:111122223333:repository/repository-name"
    }
  ]
}

Con una política de IAM similar a la anterior y una vez autenticadas en su registro, puede enviar imágenes mediante la CLI de Docker u otras herramientas. Antes de enviar una imagen a un repositorio, debe etiquetarse con el registro, el repositorio y el nombre de la etiqueta de imagen opcional (si se omite el nombre de la etiqueta de imagen, se asume la última). El siguiente ejemplo ilustra el formato de la etiqueta y el comando para etiquetar una imagen local antes de enviarla a Amazon ECR.

Sustituya 111122223333 por el ID de su cuenta de AWS, región por el identificador de la región que contiene el repositorio (us-east-1, us-west-2, etc.) y repository-name por el nombre real del repositorio.

docker tag ab12345ef 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag

Por último, inserte la imagen:

docker push 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag

Extraer una imagen

Las imágenes se extraen con el mismo formato de etiquetado para identificar la imagen que se utilizó cuando se insertó la imagen:

docker pull 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag

En el caso de los repositorios de su registro privado, debe autenticar a su cliente en el registro tal y como se describió anteriormente, antes de extraer la imagen. En el caso de los registros públicos, puede extraer imágenes con o sin autenticación.

Pruebas de conocimientos

Ya completó el módulo 1, una introducción a Amazon ECS y AWS Fargate. La siguiente prueba le permitirá comprobar lo que aprendió hasta ahora.

Pregunta 1: ¿Qué es Amazon Elastic Container Registry?

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

Pregunta 2: ¿Las opciones de almacenamiento persistente son las mismas para los contenedores de Windows/Linux que se ejecutan en Amazon ECS?

a. Verdadero

b. Falso

Pregunta 3: En relación con ECS, ¿qué es un clúster?

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

Conclusión

En este módulo, aprendió por primera vez sobre los contenedores: en qué se diferencian de las máquinas virtuales y los contenedores de Docker Linux en comparación con los contenedores Windows. Son livianos, estandarizados y portátiles, se mueven sin problemas, le permiten realizar envíos más rápido y pueden ahorrarle dinero. Los contenedores de AWS son seguros y confiables, cuentan con el respaldo de una variedad de servicios de contenedores y están profundamente integrados con AWS.

También aprendió sobre las tecnologías sin servidor, que le permiten crear aplicaciones sin tener que pensar en los servidores. Los beneficios incluyen la eliminación de los gastos operativos, el escalamiento automático, la reducción de los costos y la creación de aplicaciones con mayor facilidad mediante integraciones con otros servicios de AWS. Los casos de uso son las aplicaciones web, el procesamiento de datos, el procesamiento por lotes y la ingesta de eventos.

Aprendió sobre los servicios de computación de AWS para contenedores y cómo elegir un servicio de computación. Descubrió que AWS App Runner es un servicio totalmente administrado para alojar contenedores que también funciona sin servidor.

¿Le resultó útil esta página?

Herramientas para desarrolladores de contenedores .NET en AWS