Carichi di lavoro .NET su Amazon ECS e AWS Fargate

Un cluster è un gruppo logico di risorse di calcolo, in una regione specifica. I cluster contengono le istanze di container in esecuzione che ospitano le applicazioni e i componenti delle applicazioni, il che consente di isolarli in modo che non utilizzino la stessa infrastruttura sottostante. Ciò migliora la disponibilità in caso di guasto di un particolare elemento dell'infrastruttura che ospita l'applicazione. Sarà necessario riavviare solo il cluster interessato.

Indipendentemente dal fatto che utilizzi Amazon ECS o Amazon ECS su AWS Fargate, lavorerai con i cluster. Ciò che differisce è il livello di gestione che ci si aspetta da te. Se specifichi il tipo di avvio EC2 durante la creazione dei cluster, ti assumi la responsabilità di configurare e gestire tali cluster. Quando utilizzi il tipo di avvio Fargate, tuttavia, è responsabilità di Fargate gestire i cluster.

Un container contiene tutto il codice, il runtime, gli strumenti e le librerie di sistema richiesti dall'applicazione o dal componente dell'applicazione nel container per l'esecuzione. Quando avvii le istanze di container per ospitare le tue applicazioni, le istanze di container vengono eseguite sull'infrastruttura di calcolo associata a un cluster.

I modelli di sola lettura noti come immagini dei container vengono utilizzati per avviare i container. Per poter utilizzare un'immagine per eseguire i container, devi implementare l'immagine del container in un registro, ad esempio Amazon Elastic Container Registry (Amazon ECR) o Docker Hub.

Le immagini dei container vengono definite utilizzando una risorsa chiamata Dockerfile. Un Dockerfile è un file di testo che descrive in dettaglio tutti i componenti e le risorse che desideri includere nell'immagine. Amazon ECS utilizza lo stesso Dockerfile utilizzato per definire le immagini dei container per le applicazioni .NET altrove, senza modifiche. Utilizzando il comando docker build, trasformi i comandi e le impostazioni definiti nel Dockerfile in un'immagine di container che puoi inviare a un registro o eseguire localmente in Docker. Gli strumenti di container disponibili in AWS, descritti in dettaglio nel modulo 2, spesso gestiscono la creazione e l'invio dell'immagine per tuo conto.

Una definizione di attività è un file di testo in formato JSON utilizzato per descrivere i container che compongono l'applicazione. Una singola definizione di attività può descrivere fino a 10 container.

È possibile pensare a una definizione di attività come a uno schema di ambiente applicativo, che specifica i parametri dell'applicazione e del sistema operativo. Alcuni esempi sono le porte di rete che devono essere aperte e i volumi di dati che devono essere collegati, tra le altre risorse.

Amazon ECS non limita la tua applicazione a una singola definizione di attività. In realtà, si consiglia di combinare i contenitori correlati per un componente che costituisce una parte dell'applicazione in un'unica definizione di attività e di utilizzare più definizioni di attività per descrivere l'intera applicazione. Ciò consente ai diversi componenti logici che compongono l'applicazione di scalare in modo indipendente.

Consideriamo una tipica applicazione Web a n livelli, composta da un livello front-end dell'interfaccia utente Web, un livello API, un livello intermedio e livelli di componenti del database. L'immagine seguente mostra come raggruppare questi livelli di componenti in diverse definizioni di attività. Ciò consente, ad esempio, al livello di interfaccia utente Web di scalare orizzontalmente, indipendentemente dagli altri componenti e viceversa, se si verifica un'impennata dell'utilizzo. Se si definissero tutti i livelli in un'unica definizione di attività, l'intera applicazione scalerebbe sotto carico, compresi i livelli che non registrano un aumento dell'utilizzo, aumentando i tempi di scalabilità (se l'applicazione è di grandi dimensioni) e incrementando potenzialmente i costi finanziari.

Di seguito è riportato un esempio di definizione di attività. Un server Web viene configurato utilizzando container Linux sul tipo di avvio 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" 
    ]
}

Quando Amazon ECS crea un'istanza di una definizione di attività, crea una o più attività che vengono eseguite all'interno di un cluster. Un'attività è un'istanza di container in esecuzione. Oltre ad altre impostazioni ambientali, la definizione di attività specifica il numero di attività, o istanze di container, da eseguire sul cluster.

È possibile configurare le attività in modo che vengano eseguite in modo autonomo, causando l'interruzione del container al termine dell'attività, oppure è possibile eseguire le attività in modo continuo come un servizio. Quando viene eseguito come parte di un servizio, Amazon ECS mantiene un numero specificato di attività in esecuzione simultanea, sostituendo automaticamente i container in errore.

Utilizza un'attività autonoma per il codice di applicazione che non deve essere eseguito in modo continuo. Il codice viene eseguito una volta all'interno dell'attività e poi termina, chiudendo l'istanza di container. Un esempio potrebbe essere l'elaborazione in batch di alcuni dati.

Le attività autonome sono configurabili per essere eseguite in base a una pianificazione o in risposta a un evento. Queste attività sono chiamate attività pianificate. In entrambi i casi, Amazon EventBridge viene utilizzato per definire una pianificazione Cron o un evento che causerà l'esecuzione dell'attività. Le pianificazioni Cron configurano un'attività in modo che venga eseguita ogni N minuti, ore o giorni. Affinché le attività pianificate vengano eseguite quando si verifica un evento, puoi sottoscrivere eventi definiti da AWS o eventi personalizzati in Amazon EventBridge. Quando si verificano gli eventi, Amazon ECS esegue automaticamente l'operazione.

Utilizza le attività pianificate per il codice di applicazione che deve essere eseguito periodicamente senza l'intervento dell'operatore per avviare l'attività manualmente. Gli scenari di esempio riportano il codice per eseguire l'ispezione di log, operazioni di backup o processi periodici di estrazione e trasformazione del carico (ETL).

Un servizio è una raccolta di una o più attività che vengono eseguite in modo continuo. Nella definizione di attività, l'utente specifica il numero di attività che il servizio deve gestire e Amazon ECS monitora i container per garantire che il numero di attività richiesto sia sempre disponibile.

Amazon ECS esegue un agente su ogni istanza di container in un cluster. Non è necessario installare o gestire personalmente questo agente. L'agente riporta informazioni sulle attività in esecuzione e sull'utilizzo delle istanze di container, consentendo ad Amazon ECS di rilevare le attività che riportano errori o si interrompono. In questo caso, Amazon ECS sostituisce le attività non riuscite con nuove istanze per mantenere il numero specificato di attività nel servizio, senza che tu debba monitorare e intervenire personalmente.

Utilizza un servizio per il codice di applicazione che deve essere eseguito in modo continuo. Alcuni esempi sono il front-end di un sito Web o un'API Web.

Il codice di applicazione in esecuzione su un'istanza di container richiede in genere la lettura o la scrittura di dati stateful. Alcuni esempi sono i file di dati temporanei, i dati recuperati da un servizio esterno che desideri memorizzare nella cache locale per un breve periodo e i database, inclusi quelli che utilizzano SQL Server nelle istanze Amazon EC2, nelle istanze Amazon Relational Database Service (RDS) e altri container. In alternativa, le applicazioni scalabili su più istanze di container potrebbero dover accedere allo spazio di archiviazione condiviso sia per i dati temporanei che per quelli a lungo termine.

Le istanze di container in esecuzione dispongono di un livello scrivibile in grado di archiviare dati. Tuttavia, il livello scrivibile è transitorio e viene distrutto quando l'istanza di container termina per azione dell'utente o perché, non essendo integra, viene sostituita da Amazon ECS. Ciò rende il livello scrivibile un approccio inadatto per l'archiviazione di dati a lungo termine, ad esempio, i dati in un database. Inoltre, i dati nel livello scrivibile sono accessibili solo tramite il codice in esecuzione sulla singola istanza di container, il che rende questo livello inadatto per i dati che è necessario condividere in un'applicazione che si estende su più istanze di container.

Per consentire ai dati delle applicazioni di essere archiviati per un periodo più lungo della durata di un'istanza di container o di essere condivisi tra più istanze di container, AWS fornisce diversi servizi di archiviazione. Questi servizi disaccoppiano l'archiviazione dei dati dalle istanze di calcolo. L'utilizzo dell'archiviazione disaccoppiata dalle istanze di calcolo consente ai dati delle applicazioni di sopravvivere alle istanze di container su cui è in esecuzione l'applicazione e rende i dati condivisibili tra più istanze.

I servizi di archiviazione disponibili per le applicazioni .NET containerizzate dipendono dal fatto che le applicazioni siano eseguite su container Linux o Windows.

I container Linux attualmente supportano la più ampia gamma di servizi di archiviazione per applicazioni. NET quando vengono eseguiti in Amazon ECS o Amazon ECS su AWS Fargate. La scelta del servizio di archiviazione dipenderà dal fatto che l'applicazione richieda un accesso condiviso e simultaneo ai dati.

Amazon Elastic Block Store (Amazon EBS) è un servizio di archiviazione che fornisce volumi di archiviazione a livello di blocchi. Un volume EBS fornisce alle applicazioni uno spazio di archiviazione montabile su container Linux, a cui si accede come a un normale dispositivo a disco. Amazon EBS replica automaticamente i dati nei volumi EBS all'interno di una zona di disponibilità, rendendola una soluzione di archiviazione affidabile che consente di migliorare l'affidabilità delle applicazioni in caso di guasto di un volume di archiviazione.

I volumi EBS sono ridimensionabili dinamicamente, supportano la crittografia e supportano anche le istantanee per la creazione di copie. Se necessario, è possibile scollegare i volumi da un container e ricollegarli a un altro. Per soddisfare i requisiti di prestazioni e prezzo dell'applicazione, Amazon EBS offre diversi tipi di volume.

I volumi EBS vengono creati in una zona di disponibilità specifica di una regione. Il volume è quindi montabile su un'istanza di container utilizzando le impostazioni presenti nella definizione di attività, in esecuzione nella stessa zona. Per accedere agli stessi dati da una zona di disponibilità diversa, crea un'istantanea del volume e utilizza l'istantanea per creare un nuovo volume altrove nella stessa regione o in una regione diversa. Una singola istantanea può creare molti volumi in diverse zone di disponibilità e regioni. Questo è un approccio da considerare per i dati delle applicazioni di sola lettura che devono essere utilizzati dalle applicazioni che richiedono un'elevata disponibilità e che hai implementato in più istanze di container che si estendono su diverse zone di disponibilità e regioni.

Amazon EBS è una soluzione di archiviazione efficace da prendere in considerazione per le applicazioni che richiedono un accesso rapido e a bassa latenza ai dati non condivisi contemporaneamente, poiché le applicazioni sono scalabili orizzontalmente (cioè eseguite in più istanze di container). Gli esempi includono file system e database generali a cui si accede da una singola istanza di container.

Amazon EBS non supporta l'accesso simultaneo a un volume. Per le applicazioni che devono condividere un singolo file system montato su più container, prendi in considerazione Amazon Elastic File Service o uno dei file system resi disponibili da Amazon FSx.

Amazon EFS fornisce un servizio di file system scalabile, accessibile tramite Network File System (NFS), che non richiede la gestione dello spazio di archiviazione. I file system gestiti tramite Amazon EFS sono collegabili contemporaneamente a più istanze di container basate su Linux, con coerenza in lettura-scrittura e blocco dei file. Ciò consente di condividere i dati su un'unità, per l'accesso in lettura e scrittura, tra più container che ospitano un'applicazione scalabile. Lo spazio di archiviazione di Amazon EFS è inoltre dinamico e amplia (e riduce) la capacità automaticamente, man mano che cambiano le esigenze di archiviazione delle applicazioni.

Si paga solo per lo spazio di archiviazione utilizzato dalle applicazioni. Per impostazione predefinita, i dati nei file system creati in Amazon EFS vengono archiviati in più zone di disponibilità di una regione per fornire resilienza e durabilità. Amazon EFS si riferisce a questa modalità come alla classe di archiviazione Standard. Se un'applicazione non richiede uno spazio di archiviazione Multi-AZ completo, utilizza invece la classe di archiviazione One Zone per risparmiare sui costi. Sono disponibili anche classi di archiviazione Standard-Infrequent Access e One Zone-Infrequent Access per ospitare i dati a cui le applicazioni accedono in modo non regolare per risparmiare ulteriormente sui costi.

I file system Amazon EFS sono adatti per un'ampia gamma di applicazioni, tra cui applicazioni Web, sistemi di gestione dei contenuti, home folder per utenti e file server generici. I file system supportano l'autenticazione, l'autorizzazione e la crittografia. Il controllo degli accessi utilizza le autorizzazioni POSIX standard.

Lo snippet di definizione di attività di esempio riportato di seguito mostra come montare un file system EFS per un'attività.

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

Lustre è un file system open-source progettato per soddisfare le esigenze di prestazioni di machine learning, calcolo ad alte prestazioni (HPC), elaborazione video e modellazione finanziaria. Per le applicazioni .NET che si rivolgono a queste soluzioni o per altri scenari che richiedono latenze inferiori al millisecondo, Amazon FSx per Lustre può fornire il livello di archiviazione persistente per i container Linux.

Nota: al momento della stesura del presente documento, le attività in esecuzione in AWS Fargate non supportano i file system FSx per Lustre.

I file system creati in FSx per Lustre sono conformi a POSIX. Ciò significa che puoi continuare a utilizzare gli stessi controlli di accesso ai file che già utilizzi per le tue applicazioni .NET in esecuzione su Linux. I file system ospitati in FSx per Lustre forniscono inoltre coerenza in lettura-scrittura e blocco dei file.

A seconda delle esigenze dell'applicazione, è disponibile una scelta di archiviazione a stato solido (SSD) e su disco rigido (HDD), ottimizzata per i diversi requisiti di carico di lavoro. L'archiviazione SSD è adatta per applicazioni a uso intensivo di IOPS sensibili alla latenza e che in genere prevedono operazioni di file di piccole dimensioni ad accesso casuale. Il tipo di archiviazione HDD è adatto per applicazioni con requisiti di velocità di trasmissione effettiva elevata, che in genere comportano operazioni su file di grandi dimensioni e sequenziali. Con l'archiviazione HDD, puoi anche aggiungere una cache SSD di sola lettura, di dimensioni pari al 20% dello spazio di archiviazione HDD, per consentire una latenza inferiore al millisecondo e IOPS più elevati, migliorando le prestazioni per i file a cui si accede di frequente.

I file system in FSx per Lustre possono anche collegarsi a un bucket Amazon S3, con accesso completo in lettura-scrittura. Ciò consente all'applicazione .NET di elaborare gli oggetti nel bucket S3 come se fossero già residenti in un file system, un'opzione per le applicazioni create per elaborare dati da set di dati di grandi dimensioni basati su cloud già in S3, senza dover copiare tali dati in un file system prima di accedervi e aggiornarli.

Puoi montare i file system Lustre anche con un comando nel container Docker usando il pacchetto per client lustre; questo ti consente di montare i file system in modo dinamico all'interno del container.

Per i container Windows che eseguono applicazioni .NET e .NET Framework, l'archiviazione di file forniti da Amazon FSx per Windows File Server è disponibile per la persistenza e la condivisione dei dati tra uno o più container in esecuzione in un'attività.

FSx per Windows File Server utilizza le istanze effettive di Windows File Server, accessibili tramite condivisioni di file Windows standard su SMB, per archiviare e servire i dati delle applicazioni. Le condivisioni di file Windows standard consentono l'uso di funzionalità e strumenti di amministrazione già noti agli amministratori di Windows File Server, come il ripristino dei file degli utenti finali tramite copie shadow, quote utente e liste di controllo degli accessi (ACL). SMB consente inoltre la connessione a una condivisione di FSx per Windows File Server da container Linux.

I file system in FSx per Windows File Server possono contribuire a ridurre i costi di archiviazione per le applicazioni che utilizzano la deduplicazione e la compressione dei dati. Le funzionalità aggiuntive includono crittografia dei dati, accesso ai file verificabile e backup automatici pianificati. L'accesso alle condivisioni del file system è controllabile tramite l'integrazione con Microsoft Active Directory (AD) on-premise o Managed AD in AWS.

FSx per Windows File Server è adatto alla migrazione di file server basati su Windows on-premise nel cloud per funzionare insieme ad applicazioni .NET/.NET Framework containerizzate. È anche adatto all'uso con applicazioni .NET e .NET Framework che necessitano di accedere al cloud ibrido e a data store on-premise (con Gateway di file Amazon FSx). Per le applicazioni che utilizzano SQL Server, FSx per Windows File Server consente l'esecuzione di questi carichi di lavoro del database senza la necessità di licenze SQL Server Enterprise.

Lo snippet di definizione di attività di esempio riportato di seguito mostra come montare un file system creato in FSx per Windows File Server per un'attività.

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

Le applicazioni basate su .NET (.NET 6 o versioni successive) possono utilizzare l'infrastruttura di container fornita e gestita da Fargate. Fargate utilizza Amazon Linux 2, disponibile nelle architetture X86_64 o ARM64. La definizione di attività specifica l'architettura richiesta.

Nota: è anche possibile eseguire su Fargate le applicazioni precedenti basate su .NET Core 3.1 e .NET 5. Tuttavia, entrambe le versioni non sono più supportate da Microsoft, o non lo saranno presto. .NET 5 non era una release con supporto a lungo termine (LTS) e ora non è più supportata. Al momento della stesura di questo documento, .NET Core 3.1 è in fase di supporto di manutenzione, il che significa che mancano 6 mesi o meno alla fine del supporto e alla ricezione di patch solo per problemi di sicurezza.

I container Windows su Fargate possono eseguire sia applicazioni .NET Framework sia applicazioni .NET. Fargate attualmente supporta due versioni di Windows Server per le applicazioni: Windows Server 2019 Full e Windows Server 2019 Core. A prescindere dalla versione che utilizzi, sarà AWS a gestire le licenze del sistema operativo Windows per tuo conto.

Nota: non tutte le funzionalità di Windows Server e alcune funzionalità di AWS non sono disponibili con i container Windows su AWS Fargate. Consulta la documentazione del servizio per informazioni aggiornate sulle limitazioni e sulle considerazioni relative alle funzionalità. Di seguito sono elencati alcuni esempi di funzionalità non supportate.

• Account di servizio gestito di gruppo (gMSA).
• File system Amazon FSx (diversi da FSx per Windows File Server).
• Archiviazione effimera configurabile.
• Volumi Amazon Elastic File Store (Amazon EFS).
• Volumi di immagini.
• Servizio App Mesh e integrazione proxy per le attività.
  

AWS fornisce a ogni account un singolo registro privato in ogni regione AWS e ogni registro può contenere zero o più repository (è necessario almeno un repository per contenere le immagini). Ogni registro regionale di un account è accessibile utilizzando un URL nel formato https://aws_account_id.dkr.ecr.region.amazonaws.com, ad esempio https://123456789012.dkr.ecr.us-west-2.amazonaws.com.

I repository in un registro privato contengono immagini e artefatti Docker e Open Container Initiative (OCI). Puoi utilizzare un numero di repository pari o inferiore a quello necessario per le immagini e gli artefatti. Ad esempio, puoi utilizzare un repository per contenere le immagini per una fase di sviluppo, un altro per le immagini in una fase di test e un altro ancora per le immagini rilasciate in una fase di produzione.

I nomi delle immagini all'interno di un'immagine del repository devono essere univoci, tuttavia, i repository Amazon ECR supportano anche spazi dei nomi. Ciò consente di riutilizzare i nomi delle immagini, che identificano immagini diverse, in diverse fasi dell'ambiente o team in un unico repository.

Per impostazione predefinita, gli account hanno accesso in lettura e scrittura ai repository in un registro privato. Tuttavia, i principali IAM e gli strumenti in esecuzione nell'ambito di tali principali devono ottenere le autorizzazioni per utilizzare l'API di Amazon ECR e per emettere comandi pull/push utilizzando strumenti come la CLI di Docker con i repository. Molti degli strumenti descritti nel modulo 2 di questo corso gestiscono questo processo di autenticazione per tuo conto.

I repository privati possono essere creati utilizzando la dashboard di Amazon ECR nella Console di gestione AWS, nella vista Esploratore AWS del kit di strumenti AWS per Visual Studio o dalla riga di comando utilizzando l'AWS CLI o gli strumenti AWS per PowerShell. La schermata seguente mostra la creazione di un repository privato dall'interno di Visual Studio. A tale scopo, espandi la voce Amazon Elastic Container Service nella vista Esploratore AWS e, dal menu contestuale nella voce Repository, seleziona Crea repository:

Il kit di strumenti AWS per Visual Studio non supporta l'utilizzo del registro pubblico ECR né l'abilitazione di funzionalità come la scansione automatica e la crittografia dei repository per i nuovi repository nel registro privato. Se queste funzionalità sono necessarie, crea repository utilizzando la Console di gestione AWS o strumenti a riga di comando come l'AWS CLI e gli strumenti AWS per PowerShell.

I registri e i repository pubblici di Amazon ECR sono disponibili per chiunque voglia estrarre le immagini pubblicate. Ogni account è dotato di un registro pubblico che può contenere più repository pubblici. Proprio come i repository privati, i repository pubblici archiviano immagini e artefatti Docker e Open Container Initiative (OCI).

I repository nei registri pubblici sono elencati nella Galleria pubblica di Amazon ECR. Ciò consente alla community di trovare ed estrarre immagini pubbliche. L'account AWS proprietario di un registro pubblico dispone dell'accesso completo in lettura-scrittura ai repository in esso contenuti. I principali IAM che accedono ai repository devono ottenere le autorizzazioni che vengono fornite in un token e utilizzare quel token per autenticarsi per inviare le immagini (proprio come con i repository privati). Tuttavia, chiunque può estrarre immagini dai tuoi repository pubblici con o senza autenticazione.

È possibile accedere ai repository nella galleria utilizzando un URL del modulo https://gallery.ecr.aws/registry_alias/repository_name. Il registry_alias viene creato al momento della creazione del primo repository pubblico e può essere modificato. L'URI per estrarre un'immagine da un repository pubblico ha il formato public.ecr.aws/registry_alias/repository_name:image_tag.

L'invio di immagini a un repository pubblico richiede autorizzazioni e autenticazione al registro pubblico. Le autorizzazioni vengono fornite in un token, che deve essere specificato al momento dell'autenticazione al registro. Le immagini possono essere estratte da un repository pubblico con o senza autenticazione preventiva.

Le cache pull-through archiviano le immagini dai registri pubblici upstream nel tuo registro privato in Amazon ECR. Al momento, Amazon ECR supporta Amazon ECR Public and Quay come registri upstream. Amazon ECR verifica nel registro upstream la presenza di una nuova versione dell'immagine e, se è disponibile una nuova versione, aggiorna la cache una volta ogni 24 ore. Le cache pull through possono aiutare a isolare i processi di compilazione e implementazione da interruzioni o altri problemi che interessano i registri upstream.

I repository di cache vengono creati automaticamente la prima volta che un'immagine viene estratta da un registro upstream configurato. Le estrazioni di immagini utilizzano gli indirizzi IP di AWS e non sono influenzate dalle quote di estrazione presenti nel registro upstream. Le estrazioni di immagini nei repository di cache sono configurate utilizzando regole. È possibile configurare un massimo di 10 regole di cache pull through per il registro privato.

L'immagine seguente mostra due regole di esempio, una per memorizzare nella cache le immagini estratte da Amazon ECR Public e la seconda per memorizzare le immagini estratte da Quay. In questa configurazione, la prima volta che le immagini vengono estratte da Amazon ECR Public, viene creato automaticamente un repository nello spazio dei nomi ecr-public, utilizzando il nome del repository upstream, e la stessa cosa accade per le immagini estratte da Quay.

Il kit di strumenti AWS per Visual Studio non supporta l'utilizzo del registro pubblico ECR né l'abilitazione di funzionalità come la scansione automatica e la crittografia dei repository per i nuovi repository nel registro privato. Se queste funzionalità sono necessarie, crea repository utilizzando la Console di gestione AWS o strumenti a riga di comando come l'AWS CLI e gli strumenti AWS per PowerShell.

Le immagini estratte dai registri upstream nelle cache pull-through supportano funzionalità aggiuntive di Amazon ECR disponibili per i tuoi repository privati, come la replica e la scansione automatica delle vulnerabilità.

a. Un registro per l'archiviazione di immagini di container

b. Un registro dei container in esecuzione

c. Un registro delle attività in esecuzione

d. Un registro dei volumi di archiviazione mappati ai container

a. Vero

b. Falso

a. Un'istanza di un container in esecuzione

b. Una definizione di container che verrà eseguito

c. Una definizione di ciò che costituisce la tua applicazione

d. Un gruppo logico di risorse di calcolo

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