.NET-Workloads auf Amazon ECS und AWS Fargate

Ein Cluster ist eine logische Gruppe von Rechenressourcen in einer bestimmten Region. Cluster enthalten die laufenden Container-Instances, die Ihre Anwendungen und Anwendungskomponenten hosten, und helfen so, sie zu isolieren, sodass sie nicht dieselbe zugrundeliegende Infrastruktur verwenden. Dies verbessert die Verfügbarkeit, falls eine bestimmte Infrastruktur, auf der Ihre Anwendung gehostet wird, ausfällt. Nur der betroffene Cluster muss neu gestartet werden.

Unabhängig davon, ob Sie Amazon ECS oder Amazon ECS auf AWS Fargate verwenden, werden Sie mit Clustern arbeiten. Was sich unterscheidet, ist das von Ihnen erwartete Managementniveau. Wenn Sie beim Erstellen von Clustern den EC2-Starttyp angeben, übernehmen Sie die Verantwortung für die Konfiguration und Verwaltung dieser Cluster. Wenn Sie jedoch den Starttyp Fargate verwenden, liegt es in der Verantwortung von Fargate, diese zu verwalten.

Ein Container enthält den gesamten Code, die Laufzeit, die Tools und die Systembibliotheken, die die Anwendung oder Anwendungskomponente im Container zum Ausführen benötigt. Wenn Sie Container-Instances starten, um Ihre Anwendungen zu hosten, werden sie auf der Recheninfrastruktur ausgeführt, die einem Cluster zugeordnet ist.

Schreibgeschützte Vorlagen, sogenannte Container-Images, werden zum Starten von Containern verwendet. Bevor Sie ein Image zum Ausführen Ihrer Container verwenden können, müssen Sie das Container-Image in einer Registry bereitstellen, z. B. Amazon Elastic Container Registry (Amazon ECR) oder Docker Hub.

Sie definieren Container-Images mithilfe einer Ressource namens Dockerfile. Ein Dockerfile ist eine Textdatei, in der alle Komponenten und Ressourcen aufgeführt sind, die Sie in das Image aufnehmen möchten. Amazon ECS verwendet dasselbe Dockerfile, das bei der Definition von Container-Images für .NET-Anwendungen an anderer Stelle verwendet wurde, ohne Änderungen. Mit dem Befehl docker build wandeln Sie die in der Dockerfile definierten Befehle und Einstellungen in ein Container-Image um, das Sie in eine Registrierung übertragen oder lokal in Docker ausführen können. Die von AWS verfügbaren Container-Tools, die in Modul 2 beschrieben werden, übernehmen häufig die Erstellung und Übertragung des Bildes für Sie.

Eine Aufgabendefinition ist eine Textdatei im JSON-Format, mit der die Container beschrieben werden, aus denen Ihre Anwendung besteht. Eine einzelne Aufgabendefinition kann bis zu 10 Container beschreiben.

Sie können sich eine Aufgabendefinition als einen Vorlage der Anwendungsumgebung vorstellen, der Anwendungs- und Betriebssystemparameter angibt. Beispiele sind, welche Netzwerkports geöffnet sein sollten, und alle Datenvolumen, die angeschlossen werden müssen, sowie andere Ressourcen.

Amazon ECS beschränkt Ihre Anwendung nicht auf eine einzelne Aufgabendefinition. Es wird sogar empfohlen, verwandte Container für eine Komponente, die einen Teil Ihrer Anwendung bildet, in einer einzigen Aufgabendefinition zu kombinieren und mehrere Aufgabendefinitionen zu verwenden, um die gesamte Anwendung zu beschreiben. Dadurch können die verschiedenen logischen Komponenten, aus denen Ihre Anwendung besteht, unabhängig voneinander skaliert werden.

Stellen Sie sich eine typische n-Stufen-Webanwendung vor, die aus einer Frontend-Ebene, einer API-Ebene, einer mittleren Ebene und Datenbankkomponentenebenen besteht. Die Abbildung unten zeigt, wie Sie diese Komponentenebenen in verschiedenen Aufgabendefinitionen gruppieren können. Auf diese Weise kann beispielsweise die Web-UI-Ebene unabhängig von den anderen Komponenten horizontal skaliert werden und umgekehrt, falls es zu einem Anstieg der Nutzung kommt. Wenn Sie alle Ebenen in einer einzigen Aufgabendefinition definieren, würde die gesamte Anwendung unter Last skalieren, einschließlich Ebenen, die nicht stärker genutzt werden, was die Zeit für die Skalierung verlängert (wenn Ihre Anwendung groß ist) und möglicherweise Ihre finanziellen Kosten in die Höhe treiben würde.

Unten finden Sie ein Beispiel für eine Aufgabendefinition. Es richtet einen Webserver ein, der Linux-Container im Fargate-Starttyp verwendet.

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

Wenn Amazon ECS eine Aufgabendefinition instanziiert, erstellt es eine oder mehrere Aufgaben, die innerhalb eines Clusters ausgeführt werden. Eine Aufgabe ist eine laufende Container-Instance. Neben anderen Umgebungseinstellungen gibt die Aufgabendefinition die Anzahl der Aufgaben oder Container-Instances an, die auf dem Cluster ausgeführt werden sollen.

Sie können Aufgaben so konfigurieren, dass sie eigenständig ausgeführt werden, sodass der Container gestoppt wird, wenn die Aufgabe abgeschlossen ist, oder Sie können Aufgaben kontinuierlich als Service ausführen. Wenn Amazon ECS als Teil eines Services ausgeführt wird, verwaltet es eine bestimmte Anzahl von Aufgaben, die gleichzeitig ausgeführt werden, und ersetzt ausgefallene Container automatisch.

Verwenden Sie eine eigenständige Aufgabe für Anwendungscode, der nicht kontinuierlich ausgeführt werden muss. Der Code wird einmal innerhalb der Aufgabe ausgeführt und endet dann, wodurch die Container-Instance beendet wird. Ein Beispiel wäre die Batch-Verarbeitung einiger Daten.

Eigenständige Aufgaben können so konfiguriert werden, dass sie entweder nach einem Zeitplan oder als Reaktion auf ein Ereignis ausgeführt werden. Diese werden als geplante Aufgaben bezeichnet. In beiden Fällen wird Amazon EventBridge verwendet, um einen Cron-Zeitplan oder ein Ereignis zu definieren, das die Ausführung Ihrer Aufgabe veranlasst. Cron-Zeitpläne konfigurieren eine Aufgabe so, dass sie jede N-te Minute, Stunde oder jeden Tag ausgeführt wird. Damit geplante Aufgaben ausgeführt werden, wenn ein Ereignis eintritt, können Sie AWS-definierte Ereignisse oder Ihre eigenen benutzerdefinierten Ereignisse in Amazon EventBridge abonnieren. Wenn die Ereignisse eintreten, führt Amazon ECS die Aufgabe automatisch aus.

Verwenden Sie geplante Aufgaben für Anwendungscode, der regelmäßig ausgeführt werden muss, ohne dass der Bediener eingreifen muss, um die Aufgabe manuell zu starten. Beispielszenarien sind Code zur Überprüfung von Protokollen, Backup-Vorgängen oder periodischen ETL-Aufträgen (Extract-Transform-Load).

Ein Service ist eine Sammlung von einer oder mehreren Aufgaben, die kontinuierlich ausgeführt werden. In der Aufgabendefinition definieren Sie die Anzahl der Aufgaben, die der Service verwalten soll, und Amazon ECS überwacht die Container, um sicherzustellen, dass die angeforderte Anzahl von Aufgaben immer verfügbar ist.

Amazon ECS führt auf jeder Container-Instance in einem Cluster einen Kundendienstmitarbeiter aus. Sie müssen diesen Kundendienstmitarbeiter nicht selbst installieren oder anderweitig warten. Der Kundendienstmitarbeiter meldet Informationen über die laufenden Aufgaben und die Auslastung der Container-Instances, sodass Amazon ECS Aufgaben erkennen kann, die fehlschlagen oder gestoppt werden. In diesem Fall ersetzt Amazon ECS die fehlgeschlagenen Aufgaben durch neue Instances, um die angegebene Anzahl von Aufgaben im Service aufrechtzuerhalten, ohne dass Sie selbst überwachen und Maßnahmen ergreifen müssen.

Verwenden Sie einen Service für Anwendungscode, der kontinuierlich ausgeführt werden muss. Beispiele sind ein Website-Frontend oder eine Web-API.

Anwendungscode, der auf einer Container-Instance ausgeführt wird, muss in der Regel statusbehaftete Daten lesen oder schreiben. Einige Beispiele sind temporäre Datendateien, Daten, die von einem externen Service abgerufen wurden, den Sie für einen kurzen Zeitraum lokal zwischenspeichern möchten, und Datenbanken – einschließlich Datenbanken, die SQL Server in Amazon-EC2-Instances, Amazon-Relational-Database Service-Instances (RDS) und anderen Containern verwenden. Alternativ müssen Anwendungen, die über mehrere Container-Instances skalieren, möglicherweise auf gemeinsam genutzten Speicher für temporäre und längerfristige Daten zugreifen.

Laufende Container-Instances verfügen über eine beschreibbare Schicht, in der Daten gespeichert werden können. Die beschreibbare Schicht ist jedoch vorübergehend und wird zerstört, wenn die Container-Instance entweder durch eine Benutzeraktion beendet wird oder weil die Instance fehlerhaft geworden ist und Amazon ECS sie ersetzt hat. Dies macht die beschreibbare Schicht zu einem ungeeigneten Ansatz für die langfristige Speicherung von Daten, wie z. B. Daten in einer Datenbank. Darüber hinaus sind Daten in der beschreibbaren Schicht nur über Code zugänglich, der auf der einzelnen Container-Instance ausgeführt wird, sodass sie für Daten ungeeignet sind, die Sie in einer Anwendung, die mehrere Container-Instances umfasst, gemeinsam nutzen müssen.

Damit Anwendungsdaten für einen Zeitraum gespeichert werden können, der über die Lebensdauer einer Container-Instance hinausgeht, oder dass sie von mehreren Container-Instances gemeinsam genutzt werden können, bietet AWS verschiedene Speicherservices an. Diese Speicherservices entkoppeln den Datenspeicher von den Rechen-Instances. Durch die Verwendung von Speicher, der von Rechen-Instances entkoppelt ist, können Anwendungsdaten die Container-Instance(s), auf denen die Anwendung ausgeführt wird, überleben, und die Daten können von mehreren Instanzen gemeinsam genutzt werden.

Die für containerisierte .NET-Anwendungen verfügbaren Speicherservices hängen davon ab, ob die Anwendungen auf Linux- oder Windows-Containern ausgeführt werden.

Linux-Container unterstützen derzeit die breiteste Palette von Speicherservices für .NET-Anwendungen, wenn sie in Amazon ECS oder Amazon ECS auf AWS Fargate ausgeführt werden. Die Wahl des Speicherservice hängt davon ab, ob die Anwendung gemeinsamen, gleichzeitigen Zugriff auf die Daten benötigt.

Amazon Elastic Block Store (Amazon EBS) ist ein Speicherservice, der Speichervolumes auf Blockebene bereitstellt. Ein EBS-Volume bietet Anwendungen Speicherplatz, der in Linux-Containern gemountet werden kann und auf den wie auf ein normales Laufwerksgerät zugegriffen wird. Amazon EBS repliziert automatisch Daten in EBS-Volumes innerhalb einer Availability Zone und ist somit eine zuverlässige Speicherlösung, die bei einem Ausfall eines Speichervolumes zur Verbesserung der Anwendungszuverlässigkeit beiträgt.

EBS-Volumes sind dynamisch skalierbar, unterstützen Verschlüsselung und unterstützen auch Snapshots zum Erstellen von Kopien. Bei Bedarf können Sie Volumes von einem Container trennen und sie wieder an einen anderen Container anhängen. Um den Leistungs- und Preisanforderungen Ihrer Anwendung gerecht zu werden, bietet Amazon EBS verschiedene Volumetypen.

EBS-Volumes werden in einer bestimmten Availability Zone in einer Region erstellt. Das Volume kann dann mithilfe der Einstellungen in der Aufgabendefinition auf eine Container-Instance gemountet werden, die in derselben Zone ausgeführt wird. Um von einer anderen Availability Zone aus auf dieselben Daten zuzugreifen, erstellen Sie einen Snapshot des Volumes und verwenden Sie den Snapshot, um ein neues Volume an einer anderen Stelle in derselben oder einer anderen Region zu erstellen. Ein einziger Snapshot kann viele Volumes in Availability Zones und Regionen erstellen. Dies ist ein Ansatz, den Sie für schreibgeschützte Anwendungsdaten in Betracht ziehen sollten, die von Anwendungen verwendet werden sollen, die eine hohe Verfügbarkeit erfordern, und die Sie auf mehreren Container-Instances bereitgestellt haben, die sich über verschiedene Availability Zones und Regionen erstrecken.

Amazon EBS ist eine gute Speicherlösung, die für Anwendungen in Betracht gezogen werden sollte, die einen schnellen Zugriff mit geringer Latenz auf Daten benötigen, die nicht gleichzeitig gemeinsam genutzt werden, da Anwendungen horizontal skaliert werden (d. h. in mehreren Container-Instances ausgeführt werden). Beispiele hierfür sind allgemeine Dateisysteme und Datenbanken, auf die von einer einzelnen Container-Instance aus zugegriffen wird.

Amazon EBS unterstützt keinen gleichzeitigen Zugriff auf ein Volume. Für Anwendungen, bei denen Anwendungen ein einzelnes Dateisystem gemeinsam nutzen müssen, das über mehrere Container gemountet ist, sollten Sie Amazon Elastic File Service oder eines der von Amazon FSx verfügbaren Dateisysteme in Betracht ziehen.

Amazon EFS bietet einen skalierbaren Dateisystem-Service, auf den über das Network File System (NFS) zugegriffen wird und für den Sie keinen Speicher verwalten müssen. Dateisysteme, die über Amazon EFS verwaltet werden, können gleichzeitig an mehrere Linux-basierte Container-Instances angehängt werden, wobei Lese-/Schreibkonsistenz gewährleistet ist und Dateien gesperrt werden. Dies bietet die Möglichkeit, Daten auf einem Laufwerk für Lese- und Schreibzugriff über mehrere Container hinweg gemeinsam zu nutzen, die eine skalierte Anwendung hosten. Amazon EFS-Speicher ist ebenfalls dynamisch und erweitert (und verringert) die Kapazität automatisch, wenn sich die Anforderungen an den Anwendungsspeicher ändern.

Sie zahlen nur für den Speicherplatz, den Ihre Anwendungen verbrauchen. Standardmäßig werden Daten in Dateisystemen, die in Amazon EFS erstellt wurden, in mehreren Availability Zones in einer Region gespeichert, um Stabilität und Beständigkeit zu gewährleisten. Amazon EFS bezeichnet diesen Modus als Standard-Speicherklasse. Wenn eine Anwendung keinen vollständigen Multi-AZ-Speicher benötigt, verwenden Sie stattdessen die One-Zone-Speicherklasse, um Kosten zu sparen. Die Speicherklassen Standard-Infrequent Access und One Zone-Infrequent Access sind auch verfügbar, um Daten zu hosten, auf die Anwendungen nicht regelmäßig zugreifen, um weitere Kosten zu sparen.

Amazon-EFS-Dateisysteme eignen sich für eine Vielzahl von Anwendungen, darunter Webanwendungen, Content-Management-Systeme, Home-Ordner für Benutzer und allgemeine Dateiserver. Die Dateisysteme unterstützen Authentifizierung, Autorisierung und Verschlüsselung. Die Zugriffskontrolle verwendet standardmäßige POSIX-Berechtigungen.

Der folgende Beispielausschnitt für eine Aufgabendefinition zeigt, wie ein EFS-Dateisystem für eine Aufgabe gemountet wird.

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

Lustre ist ein Open-Source-Dateisystem, das für die Leistungsanforderungen von Machine Learning, Hochleistungsrechnen (HPC), Videoverarbeitung und Finanzmodellierung entwickelt wurde. Für .NET-Anwendungen, die diese Lösungen adressieren, oder für andere Szenarien, die Latenzen unter einer Millisekunde erfordern, kann Amazon FSx for Lustre die persistente Speicherebene für Linux-Container bereitstellen.

Hinweis: Zum Zeitpunkt der Erstellung dieses Artikels unterstützen Aufgaben, die in AWS Fargate ausgeführt werden, FSx-für-Lustre-Dateisysteme nicht.

Dateisysteme, die in FSx für Lustre erstellt wurden, sind POSIX-konform. Das bedeutet, dass Sie weiterhin dieselben vertrauten Dateizugriffskontrollen verwenden können, die Sie bereits für Ihre unter Linux ausgeführten .NET-Anwendungen verwenden. Dateisysteme, die in FSx für Lustre gehostet werden, bieten auch Lese-/Schreibkonsistenz und Dateisperren.

Je nach den Anforderungen der Anwendung steht eine Auswahl an Solid-State-Speicher (SSD) und Festplattenspeicher (HDD) zur Verfügung, die für unterschiedliche Workload-Anforderungen optimiert sind. SSD-Speicher eignet sich für IOPS-intensive Anwendungen, die empfindlich auf Latenz reagieren und bei denen in der Regel kleine Dateioperationen mit Direktzugriff ausgeführt werden. Der HDD-Speichertyp eignet sich für Anwendungen mit hohen Durchsatzanforderungen, die typischerweise große und sequentielle Dateioperationen beinhalten. Mit HDD-Speicher können Sie auch einen schreibgeschützten SSD-Cache mit einer Größe von bis zu 20 % des Festplattenspeichers hinzufügen, um eine Latenz von unter einer Millisekunde und höhere IOPS zu ermöglichen und so die Leistung für häufig aufgerufene Dateien zu verbessern.

Dateisysteme in FSx für Lustre können auch eine Verbindung zu einem Amazon-S3-Bucket mit vollem Lese- und Schreibzugriff herstellen. Dies gibt Ihrer .NET-Anwendung die Möglichkeit, Objekte im S3-Bucket so zu verarbeiten, als ob sie sich bereits in einem Dateisystem befinden. Dies ist eine Option für Anwendungen, die für die Verarbeitung von Daten aus großen, cloudbasierten Datensätzen entwickelt wurden, die sich bereits in S3 befinden, ohne dass diese Daten vor dem Zugriff und der Aktualisierung in ein Dateisystem kopiert werden müssen.

Beachten Sie, dass Sie Lustre-Dateisysteme auch mithilfe eines Befehls in Ihrem Docker-Container mithilfe des Pakets lustre-client mounten können. Dadurch können Sie Dateisysteme dynamisch innerhalb des Containers mounten.

Für Windows-Container, auf denen .NET- und .NET Framework-Anwendungen ausgeführt werden, steht der von Amazon FSx für Windows File Server bereitgestellte Dateispeicher für die Datenpersistenz und den Datenaustausch zwischen einem oder mehreren Containern, die in einer Aufgabe ausgeführt werden, zur Verfügung.

FSx für Windows File Server verwendet tatsächliche Windows-Dateiserver-Instances, auf die über Standard-Windows-Dateifreigaben über SMB zugegriffen werden kann, um Anwendungsdaten zu speichern und bereitzustellen. Standard-Windows-Dateifreigaben ermöglichen die Verwendung von Funktionen und Verwaltungstools, mit denen Windows-Dateiserver-Administratoren bereits vertraut sind, wie z. B. die Wiederherstellung von Dateien durch Endbenutzer mithilfe von Schattenkopien, Benutzerkontingenten und Zugriffskontrolllisten (ACLs). SMB ermöglicht auch die Verbindung zu einer FSx-für-Windows-File-Server-Freigabe von Linux-Containern aus.

Dateisysteme in FSx für Windows File Server können dazu beitragen, die Speicherkosten für Anwendungen mithilfe von Datendeduplizierung und Komprimierung zu senken. Zu den zusätzlichen Funktionen gehören Datenverschlüsselung, überprüfbarer Dateizugriff und geplante automatische Backups. Der Zugriff auf Dateisystemfreigaben ist über die Integration mit einem lokalen Microsoft Active Directory (AD) oder Managed AD in AWS steuerbar.

FSx für Windows File Server eignet sich für die Migration von lokalen Windows-basierten Dateiservern in die Cloud, um zusammen mit containerisierten .NET/.NET Framework-Anwendungen zu arbeiten. Es eignet sich auch für die Verwendung mit .NET- und .NET-Framework-Anwendungen, die Zugriff auf Hybrid-Cloud- und lokale Datenspeicher benötigen (mit Amazon FSx File Gateway). Für Anwendungen, die SQL Server verwenden, ermöglicht FSx für Windows File Server die Ausführung dieser Datenbank-Workloads, ohne dass eine SQL Server Enterprise-Lizenz erforderlich ist.

Der folgende Beispielausschnitt für eine Aufgabendefinition zeigt, wie ein in FSx für Windows File Server erstelltes Dateisystem für eine Aufgabe gemountet wird.

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

.NET-basierte Anwendungen (.NET 6 oder höher) können die von Fargate bereitgestellte und verwaltete Container-Infrastruktur verwenden. Fargate verwendet Amazon Linux 2, das entweder in X86_64- oder ARM64-Architekturen verfügbar ist. Die Aufgabendefinition spezifiziert die erforderliche Architektur.

Hinweis: Es ist auch möglich, ältere .NET-Core-3.1- und .NET-5-basierte Anwendungen auf Fargate auszuführen. Beide Versionen werden jedoch nicht mehr von Microsoft unterstützt oder werden es bald sein. .NET 5 war kein Long-Term-Support-Release (LTS) und wird jetzt nicht mehr unterstützt. Zum Zeitpunkt der Erstellung dieses Artikels befindet sich .NET Core 3.1 in der Wartungs-Supportphase, d. h. es sind 6 Monate oder weniger bis zum Ende des Supports und dem Erhalt von Patches nur für Sicherheitsprobleme.

Windows-Container auf Fargate können sowohl .NET-Framework- als auch .NET-Anwendungen ausführen. Fargate unterstützt derzeit zwei Versionen von Windows Server für Anwendungen: Windows Server 2019 Full und Windows Server 2019 Core. Welche Version Sie auch verwenden, AWS verwaltet die Windows-Betriebssystemlizenzen für Sie.

Hinweis: Nicht alle Funktionen von Windows Server und einige AWS-Funktionen sind mit Windows-Containern auf AWS Fargate verfügbar. Aktuelle Informationen zu Funktionseinschränkungen und Überlegungen finden Sie in der Servicedokumentation. Einige Beispiele für nicht unterstützte Funktionen sind unten aufgeführt.

• Gruppenverwaltete Service-Konten (gMSA).
• Amazon-FSx-Dateisysteme (außer FSx für Windows File Server).
• Konfigurierbarer kurzlebiger Speicher.
• Amazon-Elastic-File-Store-Volumes (Amazon EFS).
• Bildvolumen.
• App-Mesh-Service und Proxyintegration für Aufgaben.
  

AWS stellt jedem Konto ein einziges privates Register in jeder AWS-Region zur Verfügung, und jedes Register kann kein oder mehr Repositories enthalten (mindestens ein Repository ist erforderlich, um Bilder aufzunehmen). Auf jedes regionale Register in einem Konto kann über eine URL im Format https://aws_account_id.dkr.ecr.region.amazonaws.com zugegriffen werden, z. B. https://123456789012.dkr.ecr.us-west-2.amazonaws.com.

Repositories in einem privaten Register enthalten sowohl Docker- als auch Open-Container-Initiative-Bilder (OCI) und -Artefakte. Sie können so wenige oder so viele Repositories für Bilder und Artefakte verwenden, wie Sie benötigen. Sie könnten beispielsweise ein Repository verwenden, um Bilder für eine Entwicklungsphase zu speichern, ein anderes für Bilder in einer Testphase und ein weiteres für Bilder, die für eine Produktionsphase veröffentlicht wurden.

Bildnamen innerhalb eines Repository-Bildes müssen eindeutig sein, Amazon-ECR-Repositories unterstützen jedoch auch Namespaces. Auf diese Weise können Bild-Namen, die verschiedene Images identifizieren, in verschiedenen Umgebungsphasen oder Teams in einem einzigen Repository wiederverwendet werden.

Konten haben standardmäßig Lese- und Schreibzugriff auf die Repositories in einem privaten Register. IAM-Prinzipale und Tools, die im Rahmen dieser Prinzipale ausgeführt werden, müssen jedoch über Berechtigungen verfügen, um die API von Amazon ECR zu verwenden und Pull-/Push-Befehle mithilfe von Tools wie der Docker-CLI für Repositories auszugeben. Viele der in Modul 2 dieses Kurses beschriebenen Tools übernehmen diesen Authentifizierungsprozess in Ihrem Namen.

Private Repositories können mithilfe des Amazon-ECR-Dashboards in der AWS-Managementkonsole, in der AWS-Explorer-Ansicht des AWS Toolkit für Visual Studio oder über die Befehlszeile mithilfe der AWS-CLI oder der AWS-Tools für PowerShell erstellt werden. Die Abbildung unten zeigt die Erstellung eines privaten Repositorys in Visual Studio. Dazu erweitern Sie den Eintrag Amazon Elastic Container Service in der AWS-Explorer-Ansicht und wählen im Kontextmenü des Eintrags „Repositories“ die Option „Repository erstellen“ aus:

Das AWS Toolkit für Visual Studio unterstützt nicht die Arbeit mit Ihres öffentlichen ECR-Registers oder die Aktivierung von Funktionen wie das automatische Scannen und Repository-Verschlüsselung für neue Repositories in Ihrem privaten Register. Wenn diese Funktionen erforderlich sind, erstellen Sie Repositories mithilfe der AWS-Managementkonsole oder Befehlszeilen-Tools wie AWS CLI und AWS Tools für PowerShell.

Öffentliche Register und Repositories von Amazon ECR stehen jedem zur Verfügung, um von Ihnen veröffentlichte Bilder abzurufen. Jedes Konto verfügt über ein öffentliches Register, das mehrere öffentliche Repositories enthalten kann. Genau wie private Repositories speichern öffentliche Repositories Bilder und Artefakte von Docker und Open Container Initiative (OCI).

Repositories in öffentlichen Registern sind in der Amazon ECR Public Gallery aufgeführt. Auf diese Weise kann die Community öffentliche Bilder finden und abrufen. Das AWS-Konto, das ein öffentliches Register besitzt, hat vollen Lese- und Schreibzugriff auf die darin enthaltenen Repositories. IAM-Prinzipale, die auf die Repositories zugreifen, müssen Berechtigungen erhalten, die in einem Token bereitgestellt werden, und dieses Token zur Authentifizierung verwenden, um Images zu übertragen (genau wie bei privaten Repositories). Jeder kann jedoch Bilder mit oder ohne Authentifizierung aus Ihren öffentlichen Repositories abrufen.

Auf Repositories in der Galerie wird über eine URL der Form https://gallery.ecr.aws/registry_alias/repository_name zugegriffen. Der registry_alias wird erstellt, wenn das erste öffentliche Repository erstellt wird, und kann geändert werden. Die URI zum Abrufen eines Bildes aus einem öffentlichen Repository hat das Format public.ecr.aws/registry_alias/repository_name:image_tag.

Das Verschieben von Bildern in ein öffentliches Repository erfordert Berechtigungen und eine Authentifizierung bei des öffentlichen Registers. Die Berechtigungen werden in einem Token bereitgestellt, das bei der Authentifizierung beim Register angegeben werden muss. Bilder können mit oder ohne vorherige Authentifizierung aus einem öffentlichen Repository abgerufen werden.

Führen Sie Cache-Bilder aus Upstream-öffentlichen Registern in Ihrem privatem Register in Amazon ECR durch. Heute unterstützt Amazon ECR Amazon ECR Public und Quay als Upstream-Register. Amazon ECR überprüft den Upstream auf eine neue Bildversion und aktualisiert den Cache, falls eine neue Version verfügbar ist, einmal alle 24 Stunden. Mithilfe von Pull-Through-Caches können Sie Ihre Build- und Bereitstellungsprozesse vor Ausfällen oder anderen Problemen schützen, die sich auf Upstream-Register auswirken.

Cache-Repositories werden automatisch erstellt, wenn ein Bild zum ersten Mal aus einem konfigurierten Upstream-Register abgerufen wird. Bild-Pulls verwenden AWS-IP-Adressen und sind von Pull-Rate-Kontingenten im Upstream-Register nicht betroffen. Das Abrufen von Bildern in Cache-Repositories wird mithilfe von Regeln konfiguriert. Für Ihr privates Register können maximal 10 Pull-Through-Cache-Regeln konfiguriert werden.

Das Bild unten zeigt zwei Beispielregeln, eine zum Zwischenspeichern von Bildern von Amazon ECR Public und die zweite von Quay. In dieser Konfiguration wird beim ersten Abrufen von Bildern aus Amazon ECR Public automatisch ein Repository unter dem ecr-public-Namespace unter dem Namen des Upstream-Repositorys erstellt. Ähnlich verhält es sich mit Bildern, die aus Quay abgerufen wurden.

Das AWS Toolkit für Visual Studio unterstützt nicht die Arbeit mit Ihres öffentlichen ECR-Registers oder die Aktivierung von Funktionen wie das automatische Scannen und Repository-Verschlüsselung für neue Repositories in Ihrem privaten Register. Wenn diese Funktionen erforderlich sind, erstellen Sie Repositories mithilfe der AWS-Managementkonsole oder Befehlszeilen-Tools wie AWS CLI und AWS Tools für PowerShell.

Bilder, die aus Upstream-Registern in Pull-Through-Caches abgerufen werden, unterstützen zusätzliche Amazon ECR-Funktionen, die Ihren privaten Repositories zur Verfügung stehen, wie Replikation und automatisiertes Scannen von Sicherheitslücken.

a. Ein Register zum Speichern von Container-Bildern

b. Ein Register laufender Container

c. Ein Register laufender Aufgaben

d. Ein Register von Speichervolumes, die Containern zugeordnet sind

a. Wahr

b. Falsch

a. Eine Instance eines laufenden Containers

b. Eine Definition des Containers, der ausgeführt wird

c. Eine Definition dessen, woraus Ihre Anfrage besteht

d. Eine logische Gruppe von Rechenressourcen

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