.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository@sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02",
"public.ecr.aws/amazonlinux/amazonlinux@sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5"
],
"Parent": "",
"Comment": "",
"Created": "2023-02-23T06:20:11.575053226Z",
"Container": "ec7f2fc7d2b6a382384061247ef603e7d647d65f5cd4fa397a3ccbba9278367c",
"ContainerConfig": {
"Hostname": "ec7f2fc7d2b6",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ",
"CMD [\"/bin/bash\"]"
],
"Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": null,
"Labels": {}
},
"DockerVersion": "20.10.17",
"Author": "",
"Config": {
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/bash"
],
"Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": null,
"Labels": null
},
"Architecture": "amd64",
"Os": "linux",
"Size": 167436755,
"VirtualSize": 167436755,
"GraphDriver": {
"Data": {
"MergedDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/merged",
"UpperDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/diff",
"WorkDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/work"
},
"Name": "overlay2"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2"
]
},
"Metadata": {
"LastTagTime": "2023-03-02T10:28:47.142155987Z"
}
}
]
```
# Installieren Sie SSM Agent mithilfe von Kubernetes auf Amazon EKS-Worker-Knoten DaemonSet
*Mahendra Revanasiddappa, Amazon Web Services*
## Zusammenfassung
**Hinweis, September 2021: Mit** der neuesten für Amazon EKS optimierten Version wird der SSM-Agent automatisch AMIs installiert. Weitere Informationen finden Sie in den [Versionshinweisen](https://github.com/awslabs/amazon-eks-ami/releases/tag/v20210621) für Juni 2021 AMIs.
In Amazon Elastic Kubernetes Service (Amazon EKS) sind Worker-Knoten aufgrund von Sicherheitsrichtlinien nicht mit Secure Shell (SSH) -Schlüsselpaaren verknüpft. Dieses Muster zeigt, wie Sie den DaemonSet Kubernetes-Ressourcentyp verwenden können, um den AWS Systems Manager Agent (SSM Agent) auf allen Worker-Knoten zu installieren, anstatt ihn manuell zu installieren oder das Amazon Machine Image (AMI) für die Knoten zu ersetzen. DaemonSet verwendet einen Cron-Job auf dem Worker-Knoten, um die Installation des SSM-Agenten zu planen. Sie können dieses Muster auch verwenden, um andere Pakete auf Worker-Knoten zu installieren.
Wenn Sie Probleme im Cluster beheben, können Sie durch die Installation von SSM Agent on Demand ohne SSH-Schlüsselpaare eine SSH-Sitzung mit dem Worker-Knoten einrichten, Protokolle sammeln oder die Instanzkonfiguration überprüfen.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein vorhandener Amazon EKS-Cluster mit Amazon Elastic Compute Cloud (Amazon EC2) -Worker-Knoten.
+ Container-Instances sollten über die erforderlichen Berechtigungen für die Kommunikation mit dem SSM-Service verfügen. Die von AWS Identity and Access Management (IAM) verwaltete Rolle **Amazon SSMManaged InstanceCore** stellt die erforderlichen Berechtigungen bereit, damit der SSM-Agent auf EC2 Instances ausgeführt werden kann. Weitere Informationen finden Sie in der [Dokumentation zu AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html).
**Einschränkungen**
+ Dieses Muster gilt nicht für AWS Fargate, da es auf der Fargate-Plattform DaemonSets nicht unterstützt wird.
+ Dieses Muster gilt nur für Linux-basierte Worker-Knoten.
+ Die DaemonSet Pods werden im privilegierten Modus ausgeführt. Wenn der Amazon EKS-Cluster über einen Webhook verfügt, der Pods im privilegierten Modus blockiert, wird der SSM-Agent nicht installiert.
## Architektur
Das folgende Diagramm veranschaulicht die Architektur für dieses Muster.
![\[Verwenden von Kubernetes DaemonSet zur Installation des SSM-Agenten auf Amazon EKS-Worker-Knoten.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/016d53f3-45c1-4913-b542-67124e1462b8/images/3a6dfd00-e54b-44d5-843a-4c26ce9826c9.png)
## Tools
**Tools**
+ [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) ist ein Befehlszeilenprogramm, das für die Interaktion mit einem Amazon EKS-Cluster verwendet wird. Dieses Muster wird verwendet`kubectl`, um einen DaemonSet auf dem Amazon EKS-Cluster bereitzustellen, der den SSM-Agent auf allen Worker-Knoten installiert.
+ [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) macht es Ihnen leicht, Kubernetes auf AWS auszuführen, ohne Ihre eigene Kubernetes-Steuerebene oder Knoten installieren, betreiben und warten zu müssen. Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Anwendungen in Containern.
+ Mit [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) können Sie Ihre EC2 Instances, lokalen Instances und virtuellen Maschinen (VMs) über eine interaktive, browserbasierte Shell mit einem Klick oder über die AWS-Befehlszeilenschnittstelle (AWS CLI) verwalten.
**Code**
Verwenden Sie den folgenden Code, um eine DaemonSet Konfigurationsdatei zu erstellen, mit der der SSM-Agent auf dem Amazon EKS-Cluster installiert wird. Folgen Sie den Anweisungen im Abschnitt [Epics](#install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-epics).
```
cat << EOF > ssm_daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
k8s-app: ssm-installer
name: ssm-installer
namespace: kube-system
spec:
selector:
matchLabels:
k8s-app: ssm-installer
template:
metadata:
labels:
k8s-app: ssm-installer
spec:
containers:
- name: sleeper
image: busybox
command: ['sh', '-c', 'echo I keep things running! && sleep 3600']
initContainers:
- image: amazonlinux
imagePullPolicy: Always
name: ssm
command: ["/bin/bash"]
args: ["-c","echo '* * * * * root yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm & rm -rf /etc/cron.d/ssmstart' > /etc/cron.d/ssmstart"]
securityContext:
allowPrivilegeEscalation: true
volumeMounts:
- mountPath: /etc/cron.d
name: cronfile
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumes:
- name: cronfile
hostPath:
path: /etc/cron.d
type: Directory
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
terminationGracePeriodSeconds: 30
EOF
```
## Epen
### Richten Sie kubectl ein
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Installieren und konfigurieren Sie kubectl für den Zugriff auf den EKS-Cluster. | Falls es noch `kubectl` nicht installiert und für den Zugriff auf den Amazon EKS-Cluster konfiguriert ist, finden Sie weitere Informationen unter [Installation von kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) in der Amazon EKS-Dokumentation. | DevOps |
### Stellen Sie das bereit DaemonSet
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie die DaemonSet Konfigurationsdatei. | Verwenden Sie den Code im Abschnitt [Code](#install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-tools) weiter oben in diesem Muster, um eine DaemonSet Konfigurationsdatei namens zu erstellen`ssm_daemonset.yaml`, die im Amazon EKS-Cluster bereitgestellt wird. Der von gestartete Pod DaemonSet hat einen Hauptcontainer und einen `init` Container. Der Hauptcontainer hat einen `sleep` Befehl. Der `init` Container enthält einen `command` Abschnitt, der eine Cron-Job-Datei zur Installation des SSM-Agenten im Pfad erstellt. `/etc/cron.d/` Der Cron-Job wird nur einmal ausgeführt, und die von ihm erstellte Datei wird nach Abschluss des Jobs automatisch gelöscht. Wenn der Init-Container fertig ist, wartet der Hauptcontainer 60 Minuten, bevor er beendet wird. Nach 60 Minuten wird ein neuer Pod gestartet. Dieser Pod installiert den SSM-Agent, falls er fehlt, oder aktualisiert den SSM-Agenten auf die neueste Version.Bei Bedarf können Sie den `sleep` Befehl so ändern, dass der Pod einmal täglich neu gestartet oder häufiger ausgeführt wird. | DevOps |
| Stellen Sie den DaemonSet auf dem Amazon EKS-Cluster bereit. | Verwenden Sie den folgenden Befehl, um die DaemonSet Konfigurationsdatei, die Sie im vorherigen Schritt erstellt haben, auf dem Amazon EKS-Cluster bereitzustellen:kubectl apply -f ssm_daemonset.yaml
Dieser Befehl erstellt einen DaemonSet , um die Pods auf Worker-Knoten auszuführen, um den SSM-Agent zu installieren. | DevOps |
## Zugehörige Ressourcen
+ [Installation von kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) (Amazon EKS-Dokumentation)
+ [Session Manager einrichten](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) (AWS Systems Manager Manager-Dokumentation)
# Installieren Sie den SSM-Agent und den CloudWatch Agenten auf Amazon EKS-Worker-Knoten mit preBootstrapCommands
*Akkamahadevi Hiremath, Amazon Web Services*
## Zusammenfassung
Dieses Muster enthält Codebeispiele und Schritte zur Installation des AWS Systems Manager Agent (SSM Agent) und des Amazon-Agenten auf Amazon CloudWatch Elastic Kubernetes Service (Amazon EKS) -Worker-Knoten in der Amazon Web Services (AWS) -Cloud während der Amazon EKS-Clustererstellung. Sie können den SSM-Agent und CloudWatch den SSM-Agenten installieren, indem Sie die `preBootstrapCommands` Eigenschaft aus dem `eksctl` [Konfigurationsdateischema](https://eksctl.io/usage/schema/) (Weaveworks-Dokumentation) verwenden. Anschließend können Sie den SSM-Agent verwenden, um eine Verbindung zu Ihren Worker-Knoten herzustellen, ohne ein Amazon Elastic Compute Cloud (Amazon EC2) -Schlüsselpaar zu verwenden. Darüber hinaus können Sie den CloudWatch Agenten verwenden, um die Speicher- und Festplattenauslastung auf Ihren Amazon EKS-Worker-Knoten zu überwachen.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktives AWS-Konto
+ Das [Befehlszeilenprogramm eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html), installiert und konfiguriert auf macOS, Linux oder Windows
+ Das [kubectl-Befehlszeilenprogramm](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html), installiert und konfiguriert auf macOS, Linux oder Windows
**Einschränkungen**
+ Wir empfehlen, das Hinzufügen von Skripten mit langer Laufzeit zur `preBootstrapCommands`**** Eigenschaft zu vermeiden, da dies den Knoten daran hindert, dem Amazon EKS-Cluster während der Skalierungsaktivitäten beizutreten. Wir empfehlen Ihnen, stattdessen ein [benutzerdefiniertes Amazon Machine Image (AMI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.customenv.html) zu erstellen.
+ Dieses Muster gilt nur für Amazon EC2 Linux-Instances.
## Architektur
**Technologie-Stack**
+ Amazon CloudWatch
+ Amazon Elastic Kubernetes Service (Amazon EKS)
+ AWS Systems Manager Parameter Store
**Zielarchitektur**
Das folgende Diagramm zeigt ein Beispiel für einen Benutzer, der mithilfe des SSM-Agenten, der mit dem installiert wurde, eine Verbindung zu Amazon EKS-Worker-Knoten herstellt. `preBootstrapCommands`
![\[User connecting to Amazon EKS worker nodes via Systems Manager, with SSM Agent and CloudWatch agent on each node.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/b37a3cdb-204f-4014-8317-3600a793dac7/images/9a5760af-23bb-4616-97b0-b401a9d080cf.png)
Das Diagramm zeigt den folgenden Workflow:
1. Der Benutzer erstellt mithilfe der `eksctl` Konfigurationsdatei mit der `preBootstrapCommands` Eigenschaft, die den SSM-Agenten und CloudWatch den Agenten installiert, einen Amazon EKS-Cluster.
1. Alle neuen Instances, die dem Cluster aufgrund von Skalierungsaktivitäten später beitreten, werden mit dem vorinstallierten SSM-Agenten und -Agenten erstellt. CloudWatch
1. Der Benutzer stellt EC2 mithilfe des SSM-Agenten eine Verbindung zu Amazon her und überwacht dann mithilfe des CloudWatch Agenten die Speicher- und Festplattenauslastung.
## Tools
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) hilft Ihnen dabei, die Metriken Ihrer AWS-Ressourcen und der Anwendungen, die Sie auf AWS ausführen, in Echtzeit zu überwachen.
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) hilft Ihnen, Kubernetes auf AWS auszuführen, ohne Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten zu müssen.
+ [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) bietet sicheren, hierarchischen Speicher für die Verwaltung von Konfigurationsdaten und Geheimnissen.
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) unterstützt Sie bei der Verwaltung Ihrer EC2 Instances, lokalen Instances und virtuellen Maschinen über eine interaktive, browserbasierte Shell mit einem Klick oder über die AWS-Befehlszeilenschnittstelle (AWS CLI).
+ [eksctl](https://eksctl.io/usage/schema/) ist ein Befehlszeilenprogramm zum Erstellen und Verwalten von Kubernetes-Clustern auf Amazon EKS.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) ist ein Befehlszeilenprogramm für die Kommunikation mit dem Cluster-API-Server.
## Epen
### Amazon-EKS-Cluster erstellen
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Speichern Sie die CloudWatch Agenten-Konfigurationsdatei. | Speichern Sie die CloudWatch Agentenkonfigurationsdatei im [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) in der AWS-Region, in der Sie Ihren Amazon EKS-Cluster erstellen möchten. [Erstellen Sie dazu einen Parameter](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) im AWS Systems Manager Parameter Store und notieren Sie sich den Namen des Parameters (z. B.`AmazonCloudwatch-linux`).Weitere Informationen finden Sie im *Beispielcode der CloudWatch Agenten-Konfigurationsdatei* im Abschnitt [Zusätzliche Informationen](#install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-additional) dieses Musters. | DevOps Ingenieur |
| Erstellen Sie die eksctl-Konfigurationsdatei und den Cluster. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.html) | AWS DevOps |
### Stellen Sie sicher, dass der SSM-Agent und der CloudWatch SSM-Agent funktionieren
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Testen Sie den SSM-Agenten. | Verwenden Sie SSH, um eine Verbindung zu Ihren Amazon EKS-Clusterknoten herzustellen, indem Sie [eine der Methoden verwenden, die in der AWS Systems Manager Manager-Dokumentation unter Sitzung starten](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console%20%20or%20https:%2F%2Fdocs.aws.amazon.com%2Fsystems-manager%2Flatest%2Fuserguide%2Fsession-manager-working-with-sessions-start.html%23sessions-start-cli) beschrieben werden. | AWS DevOps |
| Testen Sie den CloudWatch Agenten. | Verwenden Sie die CloudWatch Konsole, um den CloudWatch Agenten zu validieren:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.html) | AWS DevOps |
## Zugehörige Ressourcen
+ [Installation und Ausführung des CloudWatch Agenten auf Ihren Servern](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html) ( CloudWatch Amazon-Dokumentation)
+ [Einen Systems Manager Manager-Parameter erstellen (Konsole)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) (AWS Systems Manager Manager-Dokumentation)
+ [Erstellen Sie die CloudWatch Agenten-Konfigurationsdatei](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file.html) ( CloudWatch Amazon-Dokumentation)
+ [Starten einer Sitzung (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#sessions-start-cli) (AWS Systems Manager Manager-Dokumentation)
+ [Starten einer Sitzung ( EC2 Amazon-Konsole)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) (AWS Systems Manager Manager-Dokumentation)
## Zusätzliche Informationen
**Beispiel für eine CloudWatch Agenten-Konfigurationsdatei**
Im folgenden Beispiel ist der CloudWatch Agent so konfiguriert, dass er die Festplatten- und Speicherauslastung auf Amazon Linux-Instances überwacht:
```
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "cwagent"
},
"metrics": {
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}"
},
"metrics_collected": {
"disk": {
"measurement": [
"used_percent"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
},
"mem": {
"measurement": [
"mem_used_percent"
],
"metrics_collection_interval": 60
}
}
}
}
```
**Beispiel für eine eksctl-Konfigurationsdatei**
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: test
region: us-east-2
version: "1.24"
managedNodeGroups:
- name: test
minSize: 2
maxSize: 4
desiredCapacity: 2
volumeSize: 20
instanceType: t3.medium
preBootstrapCommands:
- sudo yum install amazon-ssm-agent -y
- sudo systemctl enable amazon-ssm-agent
- sudo systemctl start amazon-ssm-agent
- sudo yum install amazon-cloudwatch-agent -y
- sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudwatch-linux
iam:
attachPolicyARNs:
- arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
- arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
- arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
- arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
- arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
**Zusätzliche Codedetails**
+ In der letzten Zeile der `preBootstrapCommands` Eigenschaft `AmazonCloudwatch-linux` steht der Name des Parameters, der im AWS System Manager Parameter Store erstellt wurde. Sie müssen `AmazonCloudwatch-linux` in Parameter Store in derselben AWS-Region angeben, in der Sie den Amazon EKS-Cluster erstellt haben. Sie können auch einen Dateipfad angeben, wir empfehlen jedoch, Systems Manager zu verwenden, um die Automatisierung und Wiederverwendbarkeit zu vereinfachen.
+ Wenn Sie `preBootstrapCommands` in der `eksctl` Konfigurationsdatei verwenden, werden in der AWS-Managementkonsole zwei Startvorlagen angezeigt. Die erste Startvorlage enthält die unter angegebenen Befehle`preBootstrapCommands`. Die zweite Vorlage enthält die in den Amazon EKS-Benutzerdaten angegebenen Befehle `preBootstrapCommands` und die standardmäßigen Amazon EKS-Benutzerdaten. Diese Daten sind erforderlich, damit die Knoten dem Cluster beitreten können. Die Auto Scaling Scaling-Gruppe der Knotengruppe verwendet diese Benutzerdaten, um neue Instances hochzufahren.
+ Wenn Sie das `iam` Attribut in der `eksctl` Konfigurationsdatei verwenden, müssen Sie die standardmäßigen Amazon EKS-Richtlinien mit allen zusätzlichen Richtlinien auflisten, die in Ihren angehängten AWS Identity and Access Management (IAM) -Richtlinien erforderlich sind. Im Codeausschnitt aus dem Schritt „*Eksctl-Konfigurationsdatei und Cluster erstellen*“ wurden zusätzliche Richtlinien hinzugefügt, um sicherzustellen, dass der CloudWatch Agent `CloudWatchAgentServerPolicy` und `AmazonSSMMangedInstanceCore` der SSM-Agent wie erwartet funktionieren. Die`AmazonEKSWorkerNodePolicy`,`AmazonEKS_CNI_Policy`, `AmazonEC2ContainerRegistryReadOnly` Richtlinien sind verbindliche Richtlinien, die erforderlich sind, damit der Amazon EKS-Cluster ordnungsgemäß funktioniert.
# Migrieren Sie NGINX Ingress Controller, wenn Sie den Amazon EKS Auto Mode aktivieren
*Olawale Olaleye und Shamanth Devagari, Amazon Web Services*
## Zusammenfassung
[Der automatische EKS-Modus](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) für Amazon Elastic Kubernetes Service (Amazon EKS) kann den Betriebsaufwand für die Ausführung Ihrer Workloads auf Kubernetes-Clustern reduzieren. In diesem Modus können Sie auch AWS die Infrastruktur in Ihrem Namen einrichten und verwalten. Wenn Sie den EKS-Automatikmodus auf einem vorhandenen Cluster aktivieren, müssen Sie die Migration der [NGINX Ingress](https://docs.nginx.com/nginx-ingress-controller/overview/about/) Controller-Konfigurationen sorgfältig planen. Dies liegt daran, dass die direkte Übertragung von Network Load Balancers nicht möglich ist.
Sie können eine blue/green Bereitstellungsstrategie verwenden, um eine NGINX Ingress Controller-Instance zu migrieren, wenn Sie den EKS-Automatikmodus in einem vorhandenen Amazon EKS-Cluster aktivieren.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktiver AWS-Konto
+ Ein [Amazon EKS-Cluster](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html), auf dem Kubernetes Version 1.29 oder höher ausgeführt wird
+ Amazon EKS-Add-Ons mit [Mindestversionen](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html#auto-addons-required)
+ Aktuelle Version von [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html#kubectl-install-update)
+ Eine bestehende [NGINX](https://kubernetes.github.io/ingress-nginx/deploy/#aws) Ingress Controller-Instanz
+ (Optional) Eine [gehostete Zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Amazon Route 53 für DNS-basierte Verkehrsverlagerung
## Architektur
Eine *blaue/grüne Bereitstellung ist eine Bereitstellungsstrategie*, bei der Sie zwei separate, aber identische Umgebungen erstellen. Blue/green Bereitstellungen bieten Release-und Rollback-Funktionen nahezu ohne Ausfallzeiten. Die Grundidee besteht darin, den Datenverkehr zwischen zwei identischen Umgebungen zu verlagern, in denen unterschiedliche Versionen Ihrer Anwendung ausgeführt werden.
Die folgende Abbildung zeigt die Migration von Network Load Balancers von zwei verschiedenen NGINX Ingress Controller-Instanzen, wenn der EKS-Automatikmodus aktiviert wird. Sie verwenden eine blue/green Bereitstellung, um den Verkehr zwischen den beiden Network Load Balancers zu verlagern.
![\[Verwenden einer blue/green Bereitstellungsstrategie zur Migration von NGINX Ingress Controller-Instanzen.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/57e8c14f-cb50-4027-8ef6-ce8ea3f2db25/images/211a029a-90d8-4c92-8200-19e54062f936.png)
*Der ursprüngliche Namespace ist der blaue Namespace.* Hier werden der ursprüngliche NGINX Ingress Controller-Dienst und die ursprüngliche Instanz ausgeführt, bevor Sie den EKS Auto Mode aktivieren. Der ursprüngliche Dienst und die ursprüngliche Instanz stellen eine Verbindung zu einem Network Load Balancer her, dessen DNS-Name in Route 53 konfiguriert ist. Der [Load AWS Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.11/) hat diesen Network Load Balancer in der Ziel-Virtual Private Cloud (VPC) bereitgestellt.
Das Diagramm zeigt den folgenden Workflow zum Einrichten einer Umgebung für eine Bereitstellung: blue/green
1. *Installieren und konfigurieren Sie eine weitere NGINX Ingress Controller-Instanz in einem anderen Namespace, einem grünen Namespace.*
1. Konfigurieren Sie in Route 53 einen DNS-Namen für einen neuen Network Load Balancer.
## Tools
**AWS-Services**
+ Mit [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) können Sie Kubernetes ausführen, AWS ohne dass Sie Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten müssen.
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) verteilt den eingehenden Anwendungs- oder Netzwerkverkehr auf mehrere Ziele. Sie können beispielsweise den Traffic auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances, Container und IP-Adressen in einer oder mehreren Availability Zones verteilen.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) ist ein hochverfügbarer und skalierbarer DNS-Web-Service.
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) hilft Ihnen dabei, AWS Ressourcen in einem von Ihnen definierten virtuellen Netzwerk bereitzustellen. Dieses virtuelle Netzwerk entspricht einem herkömmlichen Netzwerk, wie Sie es in Ihrem Rechenzentrum betreiben würden, mit den Vorteilen der Verwendung der skalierbaren Infrastruktur von AWS.
**Andere Tools**
+ [Helm](https://helm.sh/) ist ein Open-Source-Paketmanager für Kubernetes, der Sie bei der Installation und Verwaltung von Anwendungen auf Ihrem Kubernetes-Cluster unterstützt.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) ist eine Befehlszeilenschnittstelle, mit der Sie Befehle für Kubernetes-Cluster ausführen können.
+ Der [NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/overview/about/) verbindet Kubernetes-Apps und -Dienste mit Anforderungsbearbeitung, Authentifizierung, benutzerdefinierten Self-Service-Ressourcen und Debugging.
## Epen
### Überprüfen Sie die bestehende Umgebung
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Vergewissern Sie sich, dass die ursprüngliche NGINX Ingress Controller-Instanz betriebsbereit ist. | Geben Sie den folgenden Befehl ein, um zu überprüfen, ob die Ressourcen im `ingress-nginx` Namespace betriebsbereit sind. Wenn Sie den NGINX Ingress Controller in einem anderen Namespace bereitgestellt haben, aktualisieren Sie den Namespace-Namen in diesem Befehl.kubectl get all -n ingress-nginx
Vergewissern Sie sich in der Ausgabe, dass sich die NGINX Ingress Controller-Pods im laufenden Zustand befinden. Im Folgenden finden Sie ein Beispiel für eine Ausgabe:NAME READY STATUS RESTARTS AGE
pod/ingress-nginx-admission-create-xqn9d 0/1 Completed 0 88m
pod/ingress-nginx-admission-patch-lhk4j 0/1 Completed 1 88m
pod/ingress-nginx-controller-68f68f859-xrz74 1/1 Running 2 (10m ago) 72m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx-controller LoadBalancer 10.100.67.255 k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com 80:30330/TCP,443:31462/TCP 88m
service/ingress-nginx-controller-admission ClusterIP 10.100.201.176 443/TCP 88m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ingress-nginx-controller 1/1 1 1 88m
NAME DESIRED CURRENT READY AGE
replicaset.apps/ingress-nginx-controller-68f68f859 1 1 1 72m
replicaset.apps/ingress-nginx-controller-d8c96cf68 0 0 0 88m
NAME STATUS COMPLETIONS DURATION AGE
job.batch/ingress-nginx-admission-create Complete 1/1 4s 88m
job.batch/ingress-nginx-admission-patch Complete 1/1 5s 88m
| DevOps Ingenieur |
### Stellen Sie einen HTTPd Beispiel-Workload bereit, um den NGINX Ingress Controller zu verwenden
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie die Kubernetes-Ressourcen. | Geben Sie die folgenden Befehle ein, um ein Beispiel für eine Kubernetes-Bereitstellung, einen Service und einen Ingress zu erstellen:kubectl create deployment demo --image=httpd --port=80
kubectl expose deployment demo
kubectl create ingress demo --class=nginx \
--rule nginxautomode.local.dev/=demo:80
| DevOps Ingenieur |
| Überprüfen Sie die eingesetzten Ressourcen. | Geben Sie den folgenden Befehl ein, um eine Liste der bereitgestellten Ressourcen anzuzeigen:kubectl get all,ingress
Vergewissern Sie sich in der Ausgabe, dass sich der HTTPd Beispiel-Pod im laufenden Zustand befindet. Im Folgenden finden Sie ein Beispiel für eine Ausgabe:NAME READY STATUS RESTARTS AGE
pod/demo-7d94f8cb4f-q68wc 1/1 Running 0 59m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/demo ClusterIP 10.100.78.155 80/TCP 59m
service/kubernetes ClusterIP 10.100.0.1 443/TCP 117m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/demo 1/1 1 1 59m
NAME DESIRED CURRENT READY AGE
replicaset.apps/demo-7d94f8cb4f 1 1 1 59m
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.networking.k8s.io/demo nginx nginxautomode.local.dev k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com 80 56m
| DevOps Ingenieur |
| Bestätigen Sie, dass der Dienst erreichbar ist. | Geben Sie den folgenden Befehl ein, um zu bestätigen, dass der Dienst über den DNS-Namen des Network Load Balancer erreichbar ist:curl -H "Host: nginxautomode.local.dev" http://k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com
Folgendes ist die erwartete Ausgabe:It works!
| DevOps Ingenieur |
| (Optional) Erstellen Sie einen DNS-Eintrag. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps Ingenieur, AWS DevOps |
### Aktivieren Sie den automatischen EKS-Modus auf dem vorhandenen Cluster
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Aktivieren Sie den EKS-Automatikmodus. | Folgen Sie den Anweisungen unter [Aktivieren des automatischen EKS-Modus auf einem vorhandenen Cluster](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html) (Amazon EKS-Dokumentation). | AWS DevOps |
### Installieren Sie einen neuen NGINX Ingress Controller
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Konfigurieren Sie eine neue NGINX Ingress Controller-Instanz. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps Ingenieur |
| Stellen Sie die neue NGINX Instance Controller-Instanz bereit. | Geben Sie den folgenden Befehl ein, um die geänderte Manifestdatei anzuwenden:kubectl apply -f deploy.yaml
| DevOps Ingenieur |
| Bestätigen Sie die erfolgreiche Bereitstellung. | Geben Sie den folgenden Befehl ein, um zu überprüfen, ob die Ressourcen im `ingress-nginx-v2` Namespace betriebsbereit sind:kubectl get all -n ingress-nginx-v2
Vergewissern Sie sich in der Ausgabe, dass sich die NGINX Ingress Controller-Pods im laufenden Zustand befinden. Im Folgenden finden Sie ein Beispiel für eine Ausgabe:NAME READY STATUS RESTARTS AGE
pod/ingress-nginx-admission-create-7shrj 0/1 Completed 0 24s
pod/ingress-nginx-admission-patch-vkxr5 0/1 Completed 1 24s
pod/ingress-nginx-controller-757bfcbc6d-4fw52 1/1 Running 0 24s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx-controller LoadBalancer 10.100.208.114 k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com 80:31469/TCP,443:30658/TCP 24s
service/ingress-nginx-controller-admission ClusterIP 10.100.150.114 443/TCP 24s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ingress-nginx-controller 1/1 1 1 24s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ingress-nginx-controller-757bfcbc6d 1 1 1 24s
NAME STATUS COMPLETIONS DURATION AGE
job.batch/ingress-nginx-admission-create Complete 1/1 4s 24s
job.batch/ingress-nginx-admission-patch Complete 1/1 5s 24s
| DevOps Ingenieur |
| Erstellen Sie einen neuen Ingress für den HTTPd Beispiel-Workload. | Geben Sie den folgenden Befehl ein, um einen neuen Ingress für den vorhandenen HTTPd Beispiel-Workload zu erstellen:kubectl create ingress demo-new --class=nginx-v2 \
--rule nginxautomode.local.dev/=demo:80
| DevOps Ingenieur |
| Vergewissern Sie sich, dass der neue Ingress funktioniert. | Geben Sie den folgenden Befehl ein, um zu bestätigen, dass der neue Eingang funktioniert:curl -H "Host: nginxautomode.local.dev" k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com
Das Folgende ist die erwartete Ausgabe:It works!
| DevOps Ingenieur |
### Überschneiden
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Wechseln Sie zum neuen Namespace. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | AWS DevOps, DevOps Ingenieur |
| Überprüfe die beiden Eingänge. | Geben Sie den folgenden Befehl ein, um die beiden Ingresses zu überprüfen, die für den HTTPd Beispiel-Workload erstellt wurden:kubectl get ingress
Im Folgenden finden Sie ein Beispiel für eine Ausgabe:NAME CLASS HOSTS ADDRESS PORTS AGE
demo nginx nginxautomode.local.dev k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com 80 95m
demo-new nginx-v2 nginxautomode.local.dev k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com 80 33s
| DevOps Ingenieur |
## Zugehörige Ressourcen
+ [Aktivieren Sie den automatischen EKS-Modus auf einem vorhandenen Cluster](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html) (Amazon EKS-Dokumentation)
+ [Fehlerbehebung bei Load Balancers, die vom Kubernetes Service Controller in Amazon EKS erstellt wurden](https://repost.aws/knowledge-center/eks-load-balancers-troubleshooting) (AWS re:POST Knowledge Center)
+ NGINX Ingress Controller ([NGINX-Dokumentation](https://docs.nginx.com/nginx-ingress-controller/))
# Migrieren Sie Ihre Container-Workloads von Azure Red Hat OpenShift (ARO) zu Red Hat OpenShift Service in AWS (ROSA)
*Naveen Ramasamy, Srikanth Rangavajhala und Gireesh Sreekantan, Amazon Web Services*
## Zusammenfassung
[Dieses Muster enthält step-by-step Anweisungen für die Migration von Container-Workloads von Azure Red Hat (ARO) nach (ROSA). OpenShift Red Hat OpenShift Service in AWS](https://aws.amazon.com/rosa/) ROSA ist ein verwalteter Kubernetes-Dienst, der von Red Hat in Zusammenarbeit mit bereitgestellt wird. AWS Er unterstützt Sie bei der Bereitstellung, Verwaltung und Skalierung Ihrer containerisierten Anwendungen mithilfe der Kubernetes-Plattform und profitiert von der Expertise von Red Hat in Bezug auf Kubernetes und die Infrastruktur. AWS Cloud
Die Migration von Container-Workloads von ARO, aus anderen Clouds oder von lokalen Umgebungen zu ROSA beinhaltet die Übertragung von Anwendungen, Konfigurationen und Daten von einer Plattform auf eine andere. Dieses Muster trägt dazu bei, einen reibungslosen Übergang zu gewährleisten und gleichzeitig AWS Cloud Services, Sicherheit und Kosteneffizienz zu optimieren. Es umfasst zwei Methoden für die Migration Ihrer Workloads zu ROSA-Clustern: CI/CD und das Migration Toolkit for Containers (MTC).
Dieses Muster deckt beide Methoden ab. Welche Methode Sie wählen, hängt von der Komplexität und Sicherheit Ihres Migrationsprozesses ab. Wenn Sie die volle Kontrolle über den Status Ihrer Anwendung haben und über eine Pipeline eine konsistente Einrichtung gewährleisten können, empfehlen wir Ihnen, diese CI/CD Methode zu verwenden. Wenn Ihr Anwendungsstatus jedoch Unsicherheiten, unvorhergesehene Änderungen oder ein komplexes Ökosystem beinhaltet, empfehlen wir Ihnen, MTC als zuverlässigen und kontrollierten Weg für die Migration Ihrer Anwendung und ihrer Daten auf einen neuen Cluster zu verwenden. Einen detaillierten Vergleich der beiden Methoden finden Sie im Abschnitt [Zusätzliche](#migrate-container-workloads-from-aro-to-rosa-additional) Informationen.
Vorteile der Migration zu ROSA:
+ ROSA lässt sich nahtlos AWS als systemeigener Service integrieren. Es ist leicht zugänglich über das AWS-Managementkonsole und wird über einen einzigen AWS-Konto abgerechnet. Es bietet volle Kompatibilität mit anderen Anbietern AWS-Services und bietet gemeinsamen Support sowohl AWS von RedHat als auch von RedHat.
+ ROSA unterstützt Hybrid- und Multi-Cloud-Implementierungen. Es ermöglicht die konsistente Ausführung von Anwendungen in lokalen Rechenzentren und mehreren Cloud-Umgebungen.
+ ROSA profitiert vom Sicherheitsfokus von Red Hat und bietet Funktionen wie rollenbasierte Zugriffskontrolle (RBAC), Image-Scanning und Schwachstellenanalysen, um eine sichere Container-Umgebung zu gewährleisten.
+ ROSA wurde für die einfache Skalierung von Anwendungen entwickelt und bietet Optionen für hohe Verfügbarkeit. Dadurch können Anwendungen nach Bedarf wachsen und gleichzeitig die Zuverlässigkeit beibehalten.
+ ROSA automatisiert und vereinfacht die Bereitstellung eines Kubernetes-Clusters im Vergleich zu manuellen Einrichtungs- und Verwaltungsmethoden. Dies beschleunigt den Entwicklungs- und Bereitstellungsprozess.
+ ROSA profitiert von AWS Cloud Services und bietet eine nahtlose Integration mit AWS Angeboten wie Datenbankdiensten, Speicherlösungen und Sicherheitsdiensten.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktiver AWS-Konto.
+ Berechtigungen AWS-Services , die für diese Funktion konfiguriert sind, auf die ROSA angewiesen ist, um Funktionen bereitzustellen. Weitere Informationen finden Sie in der ROSA-Dokumentation unter [Voraussetzungen](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html).
+ ROSA ist auf der [ROSA-Konsole](https://console.aws.amazon.com/rosa) aktiviert. Anweisungen finden Sie in der [ROSA-Dokumentation](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html#enable-rosa).
+ Der ROSA-Cluster wurde installiert und konfiguriert. Weitere Informationen finden [Sie unter Erste Schritte mit ROSA](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started.html) in der ROSA-Dokumentation. Informationen zu den verschiedenen Methoden zur Einrichtung eines ROSA-Clusters finden Sie im AWS Prescriptive Guidance Guide zu [ROSA-Implementierungsstrategien](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/).
+ [Netzwerkkonnektivität, die vom lokalen Netzwerk AWS über das Netzwerk [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html)(bevorzugt) oder AWS Virtual Private Network () hergestellt wird.Site-to-Site VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ Eine Amazon Elastic Compute Cloud (Amazon EC2) -Instance oder ein anderer virtueller Server zur Installation von Tools wie `aws client` OpenShift CLI (`oc`) -Client, ROSA-Client und Git-Binärdatei.
Zusätzliche Voraussetzungen für die CI/CD Methode:
+ Zugriff auf den lokalen Jenkins-Server mit Berechtigungen zum Erstellen einer neuen Pipeline, zum Hinzufügen von Stages, zum Hinzufügen von OpenShift Clustern und zum Ausführen von Builds.
+ Zugriff auf das Git-Repository, in dem der Quellcode der Anwendung verwaltet wird, mit der Berechtigung, einen neuen Git-Branch zu erstellen und Commits für den neuen Branch durchzuführen.
Zusätzliche Voraussetzungen für die MTC-Methode:
+ Ein Amazon Simple Storage Service (Amazon S3) -Bucket, der als Replikationsrepository verwendet wird.
+ Administratorzugriff auf den ARO-Quell-Cluster. Dies ist erforderlich, um die MTC-Verbindung einzurichten.
**Einschränkungen**
+ Einige AWS-Services sind nicht in allen AWS-Regionen verfügbar. Informationen zur Verfügbarkeit in den einzelnen Regionen finden Sie [AWS-Services unter Nach Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). Informationen zu bestimmten Endpunkten finden Sie auf der Seite [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html). Wählen Sie dort den Link für den Dienst aus.
## Architektur
ROSA bietet drei Netzwerkbereitstellungsmuster: öffentlich, privat und. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) PrivateLinkermöglicht es den Teams von Red Hat Site Reliability Engineering (SRE), den Cluster mithilfe eines privaten Subnetzes zu verwalten, das mit dem PrivateLink Endpunkt des Clusters in einer vorhandenen VPC verbunden ist.
Die Wahl der PrivateLink Option bietet die sicherste Konfiguration. Aus diesem Grund empfehlen wir sie für sensible Workloads oder strenge Compliance-Anforderungen. Informationen zu den Bereitstellungsoptionen für öffentliche und private Netzwerke finden Sie in der [Red OpenShift Hat-Dokumentation](https://docs.openshift.com/rosa/architecture/rosa-architecture-models.html#rosa-hcp-architecture_rosa-architecture-models).
**Wichtig**
Sie können einen PrivateLink Cluster nur bei der Installation erstellen. Sie können einen zu verwendenden Cluster PrivateLink nach der Installation nicht ändern.
Das folgende Diagramm zeigt die PrivateLink Architektur für einen ROSA-Cluster, der für die Verbindung Direct Connect zu lokalen Umgebungen und ARO-Umgebungen verwendet wird.
![\[ROSA-Cluster, der AWS Direct Connect und AWS verwendet PrivateLink.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/eff9b017-6fc7-4874-b610-849a42071ef4.png)
**AWS Berechtigungen für ROSA**
Für AWS Berechtigungen für ROSA empfehlen wir, AWS -Security-Token-Service (AWS STS) mit kurzlebigen, dynamischen Tokens zu verwenden. Diese Methode verwendet vordefinierte Rollen und Richtlinien mit den geringsten Rechten, um ROSA minimale Berechtigungen für den Betrieb in der ROSA-Installations- AWS-Konto, Steuerungsebene- und Rechenfunktionen zu gewähren, und unterstützt die ROSA-Funktionalität.
**Neuverteilung der CI/CD-Pipeline**
CI/CD pipeline redeployment is the recommended method for users who have a mature CI/CDPipeline. Wenn Sie diese Option wählen, können Sie eine beliebige [DevOps Bereitstellungsstrategie](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html) verwenden, um Ihre Anwendungslast schrittweise auf Bereitstellungen auf ROSA zu verlagern.
**Anmerkung**
Dieses Muster geht von einem häufigen Anwendungsfall aus, bei dem Sie eine lokale Git-, JFrog Artifactory- und Jenkins-Pipeline haben. [Dieser Ansatz erfordert, dass Sie die Netzwerkkonnektivität von Ihrem lokalen Netzwerk bis AWS hin zum Through herstellen und dass Sie den ROSA-Cluster einrichten Direct Connect, bevor Sie den Anweisungen im Abschnitt Epics folgen.](#migrate-container-workloads-from-aro-to-rosa-epics) Einzelheiten finden Sie im Abschnitt [Voraussetzungen](#migrate-container-workloads-from-aro-to-rosa-prereqs).
Das folgende Diagramm zeigt den Arbeitsablauf für diese Methode.
![\[Migrieren von Containern von ARO zu ROSA mithilfe der CI/CD Methode.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/f658590e-fbd9-4297-a02c-0b516694d436.png)
**MTC-Methode**
Sie können das [Migration Toolkit for Containers (MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html) verwenden,**** um Ihre containerisierten Workloads zwischen verschiedenen Kubernetes-Umgebungen zu migrieren, z. B. von ARO zu ROSA. MTC vereinfacht den Migrationsprozess, indem es mehrere wichtige Aufgaben automatisiert und ein umfassendes Framework für die Verwaltung des Migrationslebenszyklus bereitstellt.
Das folgende Diagramm zeigt den Arbeitsablauf für diese Methode.
![\[Migrieren von Containern von ARO zu ROSA mithilfe der MTC-Methode.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/979bbc7b-2e39-4dd1-b4f0-ea1032880a38.png)
## Tools
**AWS-Services**
+ [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)ist ein Online-Datenübertragungs- und Erkennungsdienst, mit dem Sie Dateien oder Objektdaten zu, von und zwischen AWS Speicherdiensten verschieben können.
+ [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)verbindet Ihr internes Netzwerk über ein Standard-Ethernet-Glasfaserkabel mit einem Direct Connect Standort. Mit dieser Verbindung können Sie virtuelle Schnittstellen direkt zur Öffentlichkeit einrichten AWS-Services und dabei Internetdienstanbieter in Ihrem Netzwerkpfad umgehen.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)hilft Ihnen dabei, unidirektionale, private Verbindungen von Ihren virtuellen privaten Clouds (VPCs) zu Diensten außerhalb der VPC herzustellen.
+ [Red Hat OpenShift Service in AWS (ROSA)](https://docs.aws.amazon.com/rosa/latest/userguide/what-is-rosa.html) ist ein verwalteter Service, der OpenShift Benutzern von Red Hat dabei hilft, containerisierte Anwendungen zu erstellen, zu skalieren und zu verwalten. AWS
+ [AWS -Security-Token-Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) hilft Ihnen dabei, temporäre Zugangsdaten mit eingeschränkten Rechten für Benutzer anzufordern.
**Andere Tools**
+ Das [Migration Toolkit for Containers (MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html) bietet eine Konsole und eine API für die Migration von containerisierten Anwendungen von ARO zu ROSA.
## Best Practices
+ Aus Gründen der [Ausfallsicherheit](https://docs.aws.amazon.com/ROSA/latest/userguide/disaster-recovery-resiliency.html) und wenn Sie über Workloads zur Einhaltung der Sicherheitsbestimmungen verfügen, richten Sie einen Multi-AZ-ROSA-Cluster ein, der Folgendes verwendet: PrivateLink Weitere Informationen finden Sie in der [ROSA-Dokumentation](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started-classic-private-link.html).
**Anmerkung**
PrivateLink kann nach der Installation nicht konfiguriert werden.
+ Der S3-Bucket, den Sie für das Replikationsrepository verwenden, sollte nicht öffentlich sein. Verwenden Sie die entsprechenden S3-Bucket-Richtlinien, um den Zugriff einzuschränken.
+ Wenn Sie sich für die MTC-Methode entscheiden, verwenden Sie die Option **Stage-Migration**, um das Ausfallzeitfenster während der Umstellung zu reduzieren.
+ Überprüfen Sie Ihre Servicekontingenten vor und nach der Bereitstellung des ROSA-Clusters. Fordern Sie bei Bedarf eine Erhöhung des Kontingents entsprechend Ihren Anforderungen an. Weitere Informationen finden Sie in der [Dokumentation zu Servicekontingenten](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html).
+ Lesen Sie die [ROSA-Sicherheitsrichtlinien](https://docs.aws.amazon.com/ROSA/latest/userguide/security.html) und implementieren Sie bewährte Sicherheitsmethoden.
+ Wir empfehlen, den Standard-Clusteradministrator nach der Installation zu entfernen. Weitere Informationen finden Sie in der [Red OpenShift Hat-Dokumentation](https://docs.openshift.com/container-platform/4.13/post_installation_configuration/cluster-tasks.html).
+ Verwenden Sie die automatische Skalierung von Maschinenpools, um ungenutzte Worker-Knoten im ROSA-Cluster herunterzufahren und so die Kosten zu optimieren. Weitere Informationen finden Sie im [ROSA-Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/5-nodes-storage/3-autoscale-machine-pool).
+ Nutzen Sie den Red Hat Cost Management Service für OpenShift Container Platform, um die Kosten für Clouds und Container besser zu verstehen und nachzuverfolgen. Weitere Informationen finden Sie im [ROSA-Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/10-cost-management).
+ Überwachen und prüfen Sie die Infrastrukturdienste und -anwendungen des ROSA-Clusters mithilfe von AWS-Services. Weitere Informationen finden Sie im [ROSA-Workshop](https://catalog.workshops.aws/aws-openshift-workshop/en-US/8-observability).
## Epen
### Option 1: Verwenden Sie eine Pipeline CI/CD
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Fügen Sie den neuen ROSA-Cluster zu Jenkins hinzu. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS-Administrator, AWS-Systemadministrator, AWS DevOps |
| Fügen Sie den `oc` Client zu Ihren Jenkins-Knoten hinzu. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS-Administrator, AWS-Systemadministrator, AWS DevOps |
| Erstelle einen neuen Git-Branch. | Erstellen Sie einen neuen Branch in Ihrem Git-Repository für`rosa-dev`. Dieser Zweig trennt die Code- oder Konfigurationsparameteränderungen für ROSA von Ihrer bestehenden Pipeline. | AWS DevOps |
| Tag-Bilder für ROSA. | Verwenden Sie in Ihrer Erstellungsphase ein anderes Tag, um die Bilder zu identifizieren, die aus der ROSA-Pipeline erstellt wurden. | AWS-Administrator, AWS-Systemadministrator, AWS DevOps |
| Erstellen Sie eine Pipeline. | Erstellen Sie eine neue Jenkins-Pipeline, die Ihrer bestehenden Pipeline ähnelt. Verwenden Sie für diese Pipeline den `rosa-dev` Git-Branch, den Sie zuvor erstellt haben, und stellen Sie sicher, dass die Git-Checkout-, Codescan- und Build-Phasen enthalten sind, die mit Ihrer vorhandenen Pipeline identisch sind. | AWS-Administrator, AWS-Systemadministrator, AWS DevOps |
| Fügen Sie eine ROSA-Bereitstellungsphase hinzu. | Fügen Sie in der neuen Pipeline eine Phase hinzu, die im ROSA-Cluster bereitgestellt werden soll, und verweisen Sie auf den ROSA-Cluster, den Sie der globalen Jenkins-Konfiguration hinzugefügt haben. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Starten Sie einen neuen Build. | Wählen Sie in Jenkins Ihre Pipeline aus und wählen Sie **Jetzt erstellen** oder starten Sie einen neuen Build, indem Sie eine Änderung an dem `rosa-dev` Branch in Git festschreiben. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Überprüfen Sie die Bereitstellung. | Verwenden Sie den Befehl **oc** oder die [ROSA-Konsole](https://console.aws.amazon.com/rosa), um zu überprüfen, ob die Anwendung auf Ihrem ROSA-Zielcluster bereitgestellt wurde. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Kopieren Sie Daten in den Zielcluster. | Kopieren Sie für statusbehaftete Workloads die Daten vom Quellcluster in den Zielcluster, indem Sie Open-Source-Dienstprogramme wie **rsync** verwenden AWS DataSync , oder Sie können die MTC-Methode verwenden. Weitere Informationen finden Sie in der [AWS DataSync -Dokumentation](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Testen Sie Ihre Anwendung. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Überschneiden. | Wenn Ihre Tests erfolgreich sind, verwenden Sie die entsprechende Amazon Route 53-Richtlinie, um den Datenverkehr von der ARO-gehosteten Anwendung zur ROSA-gehosteten Anwendung zu verlagern. Wenn Sie diesen Schritt abgeschlossen haben, wird die Arbeitslast Ihrer Anwendung vollständig auf den ROSA-Cluster übertragen. | AWS-Administrator, AWS-Systemadministrator |
### Option 2: Verwenden Sie MTC
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Installieren Sie den MTC-Operator. | Installieren Sie den MTC-Operator sowohl auf ARO- als auch auf ROSA-Clustern:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Konfigurieren Sie den Netzwerkverkehr zum Replikationsrepository. | Wenn Sie einen Proxyserver verwenden, konfigurieren Sie ihn so, dass Netzwerkverkehr zwischen dem Replikationsrepository und den Clustern zugelassen wird. Das Replikationsrepository ist ein Zwischenspeicherobjekt, das MTC zur Datenmigration verwendet. Die Quell- und Zielcluster müssen während der Migration Netzwerkzugriff auf das Replikationsrepository haben. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Fügen Sie den Quellcluster zu MTC hinzu. | Fügen Sie auf der MTC-Webkonsole den ARO-Quellcluster hinzu. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Fügen Sie Amazon S3 als Ihr Replikationsrepository hinzu. | Fügen Sie auf der MTC-Webkonsole den Amazon S3 S3-Bucket (siehe [Voraussetzungen](#migrate-container-workloads-from-aro-to-rosa-prereqs)) als Replikations-Repository hinzu. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Erstellen Sie einen Migrationsplan. | Erstellen Sie auf der MTC-Webkonsole einen Migrationsplan und geben Sie als Datenübertragungstyp **Kopieren** an. Dadurch wird MTC angewiesen, die Daten vom Quellcluster (ARO) in den S3-Bucket und vom Bucket in den Zielcluster (ROSA) zu kopieren. | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
| Führen Sie den Migrationsplan aus. | Führen Sie den Migrationsplan mithilfe der Option **Stage** oder **Cutover aus**:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS-Administrator, AWS DevOps, AWS-Systemadministrator |
## Fehlerbehebung
| Problem | Lösung |
| --- | --- |
| Probleme mit der Verbindung | Wenn Sie Ihre Container-Workloads von ARO zu ROSA migrieren, können Verbindungsprobleme auftreten, die gelöst werden sollten, um eine erfolgreiche Migration sicherzustellen. Um diese Konnektivitätsprobleme (in dieser Tabelle aufgeführt) während der Migration zu beheben, sind eine sorgfältige Planung, Abstimmung mit Ihren Netzwerk- und Sicherheitsteams sowie gründliche Tests unerlässlich. Die Implementierung einer schrittweisen Migrationsstrategie und die Überprüfung der Konnektivität bei jedem Schritt tragen dazu bei, potenzielle Störungen zu minimieren und einen reibungslosen Übergang von ARO zu ROSA sicherzustellen. |
| Unterschiede in der Netzwerkkonfiguration | ARO und ROSA können unterschiedliche Netzwerkkonfigurationen aufweisen, z. B. virtuelle Netzwerkeinstellungen (VNet), Subnetze und Netzwerkrichtlinien. Stellen Sie für eine korrekte Kommunikation zwischen den Diensten sicher, dass die Netzwerkeinstellungen auf den beiden Plattformen übereinstimmen. |
| Sicherheitsgruppen- und Firewallregeln | ROSA und ARO haben möglicherweise unterschiedliche Standardeinstellungen für Sicherheitsgruppen und Firewalls. Stellen Sie sicher, dass Sie diese Regeln anpassen und aktualisieren, damit der erforderliche Datenverkehr zur Aufrechterhaltung der Konnektivität zwischen Containern und Diensten während der Migration gewährleistet ist. |
| Änderungen der IP-Adresse und des DNS | Wenn Sie Workloads migrieren, können sich IP-Adressen und DNS-Namen ändern. Konfigurieren Sie Anwendungen neu, die auf statischen IPs oder spezifischen DNS-Namen basieren. |
| Zugriff auf externe Dienste | Wenn Ihre Anwendung von externen Diensten wie Datenbanken oder abhängig ist APIs, müssen Sie möglicherweise deren Verbindungseinstellungen aktualisieren, um sicherzustellen, dass sie mit den neuen Diensten von ROSA kommunizieren können. |
| Konfiguration von Azure Private Link | Wenn Sie Azure Private Link oder private Endpunktdienste in ARO verwenden, müssen Sie die entsprechende Funktionalität in ROSA einrichten, um die private Konnektivität zwischen Ressourcen sicherzustellen. |
| Site-to-Site VPN oder Direct Connect einrichten | Wenn zwischen Ihrem lokalen Netzwerk und ARO bereits Direct Connect Verbindungen bestehen Site-to-Site VPN oder Verbindungen bestehen, müssen Sie ähnliche Verbindungen mit ROSA herstellen, um eine unterbrechungsfreie Kommunikation mit Ihren lokalen Ressourcen zu gewährleisten. |
| Einstellungen für Ingress und Load Balancer | Die Konfigurationen für Ingress-Controller und Load Balancer können sich zwischen ARO und ROSA unterscheiden. Konfigurieren Sie diese Einstellungen neu, um den externen Zugriff auf Ihre Dienste aufrechtzuerhalten. |
| Umgang mit Zertifikaten und TLS | Wenn Ihre Anwendungen SSL-Zertifikate oder TLS verwenden, stellen Sie sicher, dass die Zertifikate gültig und in ROSA korrekt konfiguriert sind. |
| Zugriff auf die Container-Registrierung | Wenn Ihre Container in einer externen Container-Registry gehostet werden, richten Sie die entsprechenden Authentifizierungs- und Zugriffsberechtigungen für ROSA ein. |
| Überwachung und Protokollierung | Aktualisieren Sie die Überwachungs- und Protokollierungskonfigurationen entsprechend der neuen Infrastruktur auf ROSA, sodass Sie den Zustand und die Leistung Ihrer Container weiterhin effektiv überwachen können. |
## Zugehörige Ressourcen
**AWS****Verweise**
+ [Was ist Red Hat OpenShift Service in AWS?](https://docs.aws.amazon.com/ROSA/latest/userguide/what-is-rosa.html) (ROSA-Dokumentation)
+ [Erste Schritte mit ROSA](https://docs.aws.amazon.com/ROSA/latest/userguide/getting-started.html) (ROSA-Dokumentation)
+ [Red Hat OpenShift Service in AWS Umsetzungsstrategien](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/) (AWS Prescriptive Guidance)
+ [Red Hat OpenShift Service in AWS Jetzt GA](https://aws.amazon.com/blogs/aws/red-hat-openshift-service-on-aws-now-generally-availably/) (AWS Blogbeitrag)
+ [ROSA-Werkstatt](https://catalog.workshops.aws/aws-openshift-workshop/en-US/0-introduction)
+ [HÄUFIG GESTELLTE FRAGEN ZU ROSA](https://aws.amazon.com/rosa/faqs/)
+ [Häufig gestellte Fragen zum ROSA-Workshop](https://www.rosaworkshop.io/rosa/14-faq/)
+ [ROSA-Preisgestaltung](https://aws.amazon.com/rosa/pricing/)
** OpenShift Dokumentation zu Red Hat**
+ [Schnelles Installieren eines Clusters auf AWS](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-default.html)
+ [Installation eines Clusters AWS in einem eingeschränkten Netzwerk](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.html)
+ [Installation eines Clusters AWS in einer vorhandenen VPC](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-vpc.html)
+ [Installation eines Clusters auf einer vom Benutzer bereitgestellten Infrastruktur mithilfe von Vorlagen AWS CloudFormation ](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-user-infra.html)
+ [Installation eines Clusters AWS in einem eingeschränkten Netzwerk mit einer vom Benutzer bereitgestellten Infrastruktur](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws.html)
+ [Installation eines Clusters auf AWS einem mit Anpassungen](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-customizations.html)
+ [Erste Schritte mit der OpenShift CLI](https://docs.openshift.com/container-platform/4.13/cli_reference/openshift_cli/getting-started-cli.html)
## Zusätzliche Informationen
**Wählen Sie zwischen MTC- und CI/CD Pipeline-Redeployment-Optionen**
Die Migration von Anwendungen von einem OpenShift Cluster auf einen anderen erfordert sorgfältige Überlegungen. Idealerweise wünschen Sie sich einen reibungslosen Übergang, indem Sie eine CI/CD Pipeline verwenden, um die Anwendung erneut bereitzustellen und die Migration persistenter Volume-Daten abzuwickeln. In der Praxis ist eine auf einem Cluster ausgeführte Anwendung jedoch anfällig für unvorhergesehene Änderungen im Laufe der Zeit. Diese Änderungen können dazu führen, dass die Anwendung allmählich von ihrem ursprünglichen Bereitstellungsstatus abweicht. MTC bietet eine Lösung für Szenarien, in denen der genaue Inhalt eines Namespaces ungewiss ist und eine nahtlose Migration aller Anwendungskomponenten auf einen neuen Cluster wichtig ist.
Um die richtige Wahl zu treffen, müssen Sie Ihr spezifisches Szenario bewerten und die Vorteile der einzelnen Ansätze abwägen. Auf diese Weise können Sie eine erfolgreiche und reibungslose Migration sicherstellen, die Ihren Bedürfnissen und Prioritäten entspricht. Im Folgenden finden Sie zusätzliche Richtlinien für die Auswahl zwischen den beiden Optionen.
**Neuverteilung der CI/CD-Pipeline**
Die CI/CD Pipeline-Methode ist der empfohlene Ansatz, wenn Ihre Anwendung mithilfe einer Pipeline problemlos erneut bereitgestellt werden kann. Dadurch wird sichergestellt, dass die Migration kontrolliert und vorhersehbar ist und auf Ihre bestehenden Bereitstellungspraktiken abgestimmt ist. Wenn Sie sich für diese Methode entscheiden, können Sie die [Bereitstellungsstrategien blau/grün](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html) oder kanarisch nutzen, um die Last schrittweise auf Bereitstellungen auf ROSA zu verlagern. Für dieses Szenario geht dieses Muster davon aus, dass Jenkins Anwendungsbereitstellungen von der lokalen Umgebung aus orchestriert.
Vorteile:
+ Sie benötigen keinen Administratorzugriff auf den ARO-Quell-Cluster und müssen keine Operatoren auf dem Quell- oder Zielcluster bereitstellen.
+ Dieser Ansatz hilft Ihnen, den Verkehr mithilfe einer DevOps Strategie schrittweise umzustellen.
Nachteile:
+ Es erfordert mehr Aufwand, die Funktionalität Ihrer Anwendung zu testen.
+ Wenn Ihre Anwendung persistente Daten enthält, sind zusätzliche Schritte erforderlich, um die Daten mithilfe von AWS DataSync oder anderen Tools zu kopieren.
**MTC-Migration**
In der Praxis können laufende Anwendungen unvorhergesehene Änderungen erfahren, die dazu führen, dass sie von der ursprünglichen Bereitstellung abweichen. Wählen Sie die MTC-Option, wenn Sie sich über den aktuellen Status Ihrer Anwendung auf dem Quell-Cluster nicht sicher sind. Wenn Ihr Anwendungsökosystem beispielsweise verschiedene Komponenten, Konfigurationen und Datenspeichervolumen umfasst, empfehlen wir Ihnen, MTC zu wählen, um eine vollständige Migration sicherzustellen, die die Anwendung und ihre gesamte Umgebung abdeckt.
Vorteile:
+ MTC bietet eine vollständige Sicherung und Wiederherstellung des Workloads.
+ Es kopiert die persistenten Daten von der Quelle zum Ziel, während der Workload migriert wird.
+ Es ist kein Zugriff auf das Quellcode-Repository erforderlich.
Nachteile:
+ Sie benötigen Administratorrechte, um den MTC-Operator auf den Quell- und Zielclustern zu installieren.
+ Das DevOps Team benötigt eine Schulung, um das MTC-Tool verwenden und Migrationen durchführen zu können.
# Führen Sie Amazon ECS-Aufgaben auf Amazon WorkSpaces mit Amazon ECS Anywhere aus
*Akash Kumar, Amazon Web Services*
## Zusammenfassung
Amazon Elastic Container Service (Amazon ECS) Anywhere unterstützt die Bereitstellung von Amazon ECS-Aufgaben in jeder Umgebung, einschließlich der von Amazon Web Services (AWS) verwalteten Infrastruktur und der vom Kunden verwalteten Infrastruktur. Sie können dies tun, während Sie eine vollständig von AWS verwaltete Kontrollebene verwenden, die in der Cloud läuft und immer auf dem neuesten Stand ist.
Unternehmen nutzen Amazon häufig WorkSpaces für die Entwicklung containerbasierter Anwendungen. Dies erforderte Amazon Elastic Compute Cloud (Amazon EC2) oder AWS Fargate mit einem Amazon ECS-Cluster, um ECS-Aufgaben zu testen und auszuführen. Mit Amazon ECS Anywhere können Sie Amazon jetzt WorkSpaces als externe Instances direkt zu einem ECS-Cluster hinzufügen und Ihre Aufgaben direkt ausführen. Dies reduziert Ihre Entwicklungszeit, da Sie Ihren Container mit einem ECS-Cluster lokal auf Amazon testen können WorkSpaces. Sie können sich auch die Kosten für die Nutzung unserer EC2 Fargate-Instances zum Testen Ihrer Containeranwendungen sparen.
Dieses Muster zeigt, wie ECS-Aufgaben auf Amazon WorkSpaces mit Amazon ECS Anywhere bereitgestellt werden. Es richtet den ECS-Cluster ein und verwendet AWS Directory Service Simple AD, um den zu starten WorkSpaces. Dann startet die ECS-Beispielaufgabe NGINX in der. WorkSpaces
## Voraussetzungen und Einschränkungen
+ Ein aktives AWS-Konto
+ AWS-Befehlszeilenschnittstelle (AWS Command Line Interface, AWS CLI)
+ [Auf Ihrem Computer konfigurierte](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) AWS-Anmeldeinformationen
## Architektur
**Zieltechnologie-Stack**
+ Eine Virtual Private Cloud (VPC)
+ Ein Amazon ECS-Cluster
+ Amazon WorkSpaces
+ AWS Directory Service mit Simple AD
**Zielarchitektur**
![\[ECS Anywhere richtet den ECS-Cluster ein und verwendet Simple AD zum Starten WorkSpaces.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/da8b2249-3423-485c-9fef-6f902025e969/images/fd354d14-f29b-4b9e-8f1a-c3cb7ed4d6bf.png)
Die Architektur umfasst die folgenden Dienste und Ressourcen:
+ Ein ECS-Cluster mit öffentlichen und privaten Subnetzen in einer benutzerdefinierten VPC
+ Simple AD in der VPC, um Benutzern Zugriff auf Amazon zu gewähren WorkSpaces
+ Amazon wird in der VPC mit Simple AD WorkSpaces bereitgestellt
+ AWS Systems Manager wurde für das Hinzufügen von Amazon WorkSpaces als verwaltete Instances aktiviert
+ Mithilfe von Amazon ECS und AWS Systems Manager Agent (SSM Agent) WorkSpaces fügte Amazon Systems Manager und dem ECS-Cluster hinzu
+ Ein Beispiel für eine ECS-Aufgabe zur Ausführung WorkSpaces im ECS-Cluster
## Tools
+ [AWS Directory Service Simple Active Directory (Simple AD)](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_simple_ad.html) ist ein eigenständiges verwaltetes Verzeichnis, das von einem Samba 4 Active Directory-kompatiblen Server betrieben wird. Simple AD bietet einen Teil der Funktionen von AWS Managed Microsoft AD, einschließlich der Möglichkeit, Benutzer zu verwalten und eine sichere Verbindung zu EC2 Amazon-Instances herzustellen.
+ [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) ist ein hoch skalierbarer, schneller Container-Management-Service, der das Ausführen, Beenden und Verwalten von Containern in einem Cluster vereinfacht.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) hilft Ihnen dabei, den Zugriff auf Ihre AWS-Ressourcen sicher zu verwalten, indem kontrolliert wird, wer authentifiziert und autorisiert ist, diese zu verwenden.
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) unterstützt Sie bei der Verwaltung Ihrer Anwendungen und Infrastruktur, die in der AWS-Cloud ausgeführt werden. Es vereinfacht das Anwendungs- und Ressourcenmanagement, verkürzt die Zeit für die Erkennung und Lösung betrieblicher Probleme und hilft Ihnen, Ihre AWS-Ressourcen sicher und skalierbar zu verwalten.
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) unterstützt Sie bei der Bereitstellung virtueller, Cloud-basierter Microsoft Windows- oder Amazon Linux-Desktops für Ihre Benutzer, bekannt als *WorkSpaces*. WorkSpaces macht die Beschaffung und Bereitstellung von Hardware oder die Installation komplexer Software überflüssig.
## Epen
### Richten Sie den ECS-Cluster ein
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen und konfigurieren Sie den ECS-Cluster. | Um den ECS-Cluster zu erstellen, folgen Sie den Anweisungen in der [AWS-Dokumentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html), einschließlich der folgenden Schritte:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere.html) | Cloud-Architekt |
### Starten Sie Amazon WorkSpaces
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Richten Sie Simple AD ein und starten Sie Amazon WorkSpaces. | Folgen Sie den Anweisungen in der [AWS-Dokumentation](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-simple-ad.html), um ein Simple AD AD-Verzeichnis für Ihre neu erstellte VPC bereitzustellen und Amazon WorkSpaces zu starten. | Cloud-Architekt |
### AWS Systems Manager für eine Hybridumgebung einrichten
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Laden Sie die angehängten Skripte herunter. | Laden Sie auf Ihrem lokalen Computer die `ssm-activation.json` Dateien `ssm-trust-policy.json` und herunter, die sich im Bereich *Anlagen* befinden. | Cloud-Architekt |
| Fügen Sie die IAM-Rolle hinzu. | Fügen Sie Umgebungsvariablen hinzu, die auf Ihren Geschäftsanforderungen basieren.export AWS_DEFAULT_REGION=${AWS_REGION_ID}
export ROLE_NAME=${ECS_TASK_ROLE}
export CLUSTER_NAME=${ECS_CLUSTER_NAME}
export SERVICE_NAME=${ECS_CLUSTER_SERVICE_NAME}Führen Sie den folgenden Befehl aus.aws iam create-role --role-name $ROLE_NAME --assume-role-policy-document file://ssm-trust-policy.json
| Cloud-Architekt |
| Fügen Sie die SSMManaged InstanceCore Amazon-Richtlinie zur IAM-Rolle hinzu. | Führen Sie den folgenden Befehl aus.aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
| Cloud-Architekt |
| Fügen Sie die EC2 ContainerServicefor EC2 Amazon-Rollenrichtlinie zur IAM-Rolle hinzu. | Führen Sie den folgenden Befehl aus.aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
| Cloud-Architekt |
| Überprüfen Sie die IAM-Rolle. | Führen Sie den folgenden Befehl aus, um die IAM-Rolle zu überprüfen.aws iam list-attached-role-policies --role-name $ROLE_NAME
| Cloud-Architekt |
| Aktivieren Sie den Systems Manager. | Führen Sie den folgenden Befehl aus.aws ssm create-activation --iam-role $ROLE_NAME | tee ssm-activation.json
| Cloud-Architekt |
### WorkSpaces Zum ECS-Cluster hinzufügen
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Connect dich mit deinem WorkSpaces. | Folgen Sie den Anweisungen in der [AWS-Dokumentation](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html), um eine Verbindung zu Ihren Workspaces herzustellen und diese einzurichten. | App-Developer |
| Laden Sie das ECS-Anywhere-Installationsskript herunter. | Führen Sie an der Eingabeaufforderung den folgenden Befehl aus.curl -o "ecs-anywhere-install.sh" "https://amazon-ecs-agent-packages-preview.s3.us-east-1.amazonaws.com/ecs-anywhere-install.sh" && sudo chmod +x ecs-anywhere-install.sh
| App-Developer |
| Überprüfen Sie die Integrität des Shell-Skripts. | (Optional) Führen Sie den folgenden Befehl aus.curl -o "ecs-anywhere-install.sh.sha256" "https://amazon-ecs-agent-packages-preview.s3.us-east-1.amazonaws.com/ecs-anywhere-install.sh.sha256" && sha256sum -c ecs-anywhere-install.sh.sha256
| App-Developer |
| Fügen Sie ein EPEL-Repository auf Amazon Linux hinzu. | Um ein EPEL-Repository (Extra Packages for Enterprise Linux) hinzuzufügen, führen Sie den Befehl aus. `sudo amazon-linux-extras install epel -y` | App-Developer |
| Installieren Sie Amazon ECS Anywhere. | Verwenden Sie den folgenden Befehl, um das Installationsskript auszuführen.sudo ./ecs-anywhere-install.sh --cluster $CLUSTER_NAME --activation-id $ACTIVATION_ID --activation-code $ACTIVATION_CODE --region $AWS_REGION
| |
| Überprüfen Sie die Instanzinformationen aus dem ECS-Cluster. | Führen Sie den folgenden Befehl auf Ihrem lokalen Computer aus, um die Informationen zu Systems Manager- und ECS-Clusterinstanzen zu überprüfen und zu überprüfen, ob sie dem Cluster hinzugefügt WorkSpaces wurden.aws ssm describe-instance-information" && "aws ecs list-container-instances --cluster $CLUSTER_NAME
| App-Developer |
### Fügen Sie eine ECS-Aufgabe hinzu für WorkSpaces
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie eine IAM-Rolle für die Aufgabenausführung. | Laden Sie `task-execution-assume-role.json` und `external-task-definition.json` aus dem Bereich *Anlagen* herunter. Führen Sie auf Ihrem lokalen Computer den folgenden Befehl aus.aws iam --region $AWS_DEFAULT_REGION create-role --role-name $ECS_TASK_EXECUTION_ROLE --assume-role-policy-document file://task-execution-assume-role.json
| Cloud-Architekt |
| Fügen Sie die Richtlinie der Ausführungsrolle hinzu. | Führen Sie den folgenden Befehl aus.aws iam --region $AWS_DEFAULT_REGION attach-role-policy --role-name $ECS_TASK_EXECUTION_ROLE --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
| Cloud-Architekt |
| Erstellen Sie eine Aufgabenrolle. | Führen Sie den folgenden Befehl aus.aws iam --region $AWS_DEFAULT_REGION create-role --role-name $ECS_TASK_EXECUTION_ROLE --assume-role-policy-document file://task-execution-assume-role.json
| Cloud-Architekt |
| Registrieren Sie die Aufgabendefinition im Cluster. | Führen Sie auf Ihrem lokalen Computer den folgenden Befehl aus.aws ecs register-task-definition --cli-input-json file://external-task-definition.json
| Cloud-Architekt |
| Führen Sie die Aufgabe aus. | Führen Sie auf Ihrem lokalen Computer den folgenden Befehl aus.aws ecs run-task --cluster $CLUSTER_NAME --launch-type EXTERNAL --task-definition nginx
| Cloud-Architekt |
| Überprüfen Sie den Status, in dem die Aufgabe ausgeführt wird. | Führen Sie den folgenden Befehl aus, um die Aufgaben-ID abzurufen.export TEST_TASKID=$(aws ecs list-tasks --cluster $CLUSTER_NAME | jq -r '.taskArns[0]')
Führen Sie mit der Task-ID den folgenden Befehl aus.aws ecs describe-tasks --cluster $CLUSTER_NAME --tasks ${TEST_TASKID} | Cloud-Architekt |
| Überprüfen Sie die Aufgabe auf dem WorkSpace. | Um zu überprüfen, ob NGINX auf dem läuft WorkSpace, führen Sie den Befehl aus. ` curl http://localhost:8080` | App-Developer |
## Zugehörige Ressourcen
+ [ECS-Cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
+ [Einrichtung einer Hybridumgebung](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html)
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [Simple AD](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-simple-ad.html)
## Anlagen
[Um auf zusätzliche Inhalte zuzugreifen, die mit diesem Dokument verknüpft sind, entpacken Sie die folgende Datei: attachment.zip](samples/p-attach/da8b2249-3423-485c-9fef-6f902025e969/attachments/attachment.zip)
# Führen Sie einen ASP.NET Core-Web-API-Docker-Container auf einer Amazon EC2 Linux-Instance aus
*Vijai Anand Ramalingam und Sreelaxmi Pai, Amazon Web Services*
## Zusammenfassung
Dieses Muster ist für Benutzer gedacht, die damit beginnen, ihre Anwendungen in der Amazon Web Services (AWS) Cloud zu containerisieren. Wenn Sie beginnen, Apps in der Cloud zu containerisieren, sind in der Regel keine Container-Orchestrierungsplattformen eingerichtet. Mit diesem Muster können Sie schnell eine Infrastruktur auf AWS einrichten, um Ihre containerisierten Anwendungen zu testen, ohne dass eine aufwändige Container-Orchestrierungsinfrastruktur erforderlich ist.
Der erste Schritt auf dem Weg zur Modernisierung besteht darin, die Anwendung zu transformieren. Wenn es sich um eine ältere .NET Framework-Anwendung handelt, müssen Sie zuerst die Laufzeit auf ASP.NET Core ändern. Führen Sie dann die folgenden Schritte aus:
+ Erstellen Sie das Docker-Container-Image
+ Führen Sie den Docker-Container mit dem erstellten Image aus
+ Überprüfen Sie die Anwendung, bevor Sie sie auf einer beliebigen Container-Orchestrierungsplattform wie Amazon Elastic Container Service (Amazon ECS) oder Amazon Elastic Kubernetes Service (Amazon EKS) bereitstellen.
Dieses Muster behandelt die Aspekte der Erstellung, Ausführung und Validierung der modernen Anwendungsentwicklung auf einer Amazon Elastic Compute Cloud (Amazon EC2) Linux-Instance.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktives [Amazon Web Services (AWS) -Konto](https://aws.amazon.com/account/)
+ Eine [AWS Identity and Access Management (IAM) -Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) mit ausreichendem Zugriff, um AWS-Ressourcen für dieses Muster zu erstellen
+ [Visual Studio Community 2022](https://visualstudio.microsoft.com/downloads/) oder höher wurde heruntergeladen und installiert
+ Ein auf ASP.NET Core modernisiertes .NET Framework-Projekt
+ Ein Repositorium GitHub
**Produktversionen**
+ Visual Studio Community 2022 oder höher
## Architektur
**Zielarchitektur**
Dieses Muster verwendet eine [ CloudFormation AWS-Vorlage](https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=SSM-SSH-Demo&templateURL=https://aws-quickstart.s3.amazonaws.com/quickstart-examples/samples/session-manager-ssh/session-manager-example.yaml), um die im folgenden Diagramm gezeigte Architektur mit hoher Verfügbarkeit zu erstellen. Eine Amazon EC2 Linux-Instance wird in einem privaten Subnetz gestartet. AWS Systems Manager Session Manager wird verwendet, um auf die private Amazon EC2 Linux-Instance zuzugreifen und die API zu testen, die im Docker-Container läuft.
![\[Ein Benutzer, der auf die Amazon EC2 Linux-Instance zugreift und die im Docker-Container ausgeführte API testet.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/512e61b2-10ba-43be-bbd8-2bdc597c3de3/images/9c5206f6-32b1-47be-9037-360c0bff713c.png)
1. Zugriff auf die Linux-Instance über Session Manager
## Tools
**AWS-Services**
+ [AWS-Befehlszeilenschnittstelle](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) — AWS Command Line Interface (AWS CLI) ist ein Open-Source-Tool für die Interaktion mit AWS-Services über Befehle in Ihrer Befehlszeilen-Shell. Mit minimaler Konfiguration können Sie AWS-CLI-Befehle ausführen, die Funktionen implementieren, die denen der browserbasierten AWS-Managementkonsole entsprechen.
+ [AWS-Managementkonsole](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/learn-whats-new.html) — Die AWS-Managementkonsole ist eine Webanwendung, die eine breite Sammlung von Servicekonsolen für die Verwaltung von AWS-Ressourcen umfasst und sich auf diese bezieht. Wenn Sie sich zum ersten Mal anmelden, sehen Sie die Startseite der Konsole. Die Startseite bietet Zugriff auf jede Servicekonsole und bietet einen zentralen Ort, an dem Sie auf die Informationen zugreifen können, die Sie zur Ausführung Ihrer AWS-bezogenen Aufgaben benötigen.
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) — Session Manager ist eine vollständig verwaltete Funktion von AWS Systems Manager. Mit Session Manager können Sie Ihre Amazon Elastic Compute Cloud (Amazon EC2) -Instances verwalten. Session Manager bietet eine sichere und überprüfbare Knotenverwaltung, ohne dass eingehende Ports geöffnet, Bastion-Hosts verwaltet oder SSH-Schlüssel verwaltet werden müssen.
**Andere Tools**
+ [Visual Studio 2022](https://visualstudio.microsoft.com/downloads/) — Visual Studio 2022 ist eine integrierte Entwicklungsumgebung (IDE).
+ [Docker](https://www.docker.com/) — Docker ist eine Reihe von Platform-as-a-Service (PaaS) -Produkten, die Virtualisierung auf Betriebssystemebene nutzen, um Software in Containern bereitzustellen.
**Code**
```
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["DemoNetCoreWebAPI/DemoNetCoreWebAPI.csproj", "DemoNetCoreWebAPI/"]
RUN dotnet restore "DemoNetCoreWebAPI/DemoNetCoreWebAPI.csproj"
COPY . .
WORKDIR "/src/DemoNetCoreWebAPI"
RUN dotnet build "DemoNetCoreWebAPI.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "DemoNetCoreWebAPI.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DemoNetCoreWebAPI.dll"]
```
## Epen
### Entwickeln Sie die ASP.NET Core-Web-API
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie mit Visual Studio ein Beispiel für eine ASP.NET Core-Web-API. | Gehen Sie wie folgt vor, um ein Beispiel für eine ASP.NET Core-Web-API zu erstellen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | App-Developer |
| Erstellen Sie eine Docker-Datei. | Gehen Sie wie folgt vor, um ein Dockerfile zu erstellen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html)Führen Sie den folgenden Befehl aus, um die Änderungen in Ihr GitHub Repository zu übertragen.git add --all
git commit -m "Dockerfile added"
git push
| App-Developer |
### Richten Sie die Amazon EC2 Linux-Instance ein
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Richten Sie die Infrastruktur ein. | Starten Sie die [ CloudFormation AWS-Vorlage](https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=SSM-SSH-Demo&templateURL=https://aws-quickstart.s3.amazonaws.com/quickstart-examples/samples/session-manager-ssh/session-manager-example.yaml), um die Infrastruktur zu erstellen, die Folgendes umfasst: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html)Weitere Informationen zum Zugriff auf eine private EC2 Amazon-Instance mit Session Manager, ohne dass ein Bastion-Host erforderlich ist, finden Sie im Blogbeitrag [Toward a bastion-less world](https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/). | App-Entwickler, AWS-Administrator, AWS DevOps |
| Melden Sie sich bei der Amazon EC2 Linux-Instance an. | Gehen Sie wie folgt vor, um eine Verbindung zur Amazon EC2 Linux-Instance im privaten Subnetz herzustellen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | App-Developer |
| Installieren und starten Sie Docker. | Gehen Sie wie folgt vor, um Docker in der Amazon EC2 Linux-Instance zu installieren und zu starten:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | App-Entwickler, AWS-Administrator, AWS DevOps |
| Installiere Git und klone das Repository. | Gehen Sie wie folgt vor, um Git auf der Amazon EC2 Linux-Instance zu installieren und das Repository von GitHub zu klonen.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | App-Entwickler, AWS-Administrator, AWS DevOps |
| Erstellen Sie den Docker-Container und führen Sie ihn aus. | Gehen Sie wie folgt vor, um das Docker-Image zu erstellen und den Container in der Amazon EC2 Linux-Instance auszuführen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | App-Entwickler, AWS-Administrator, AWS DevOps |
### Testen Sie die Web-API
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Testen Sie die Web-API mit dem Befehl curl. | Führen Sie den folgenden Befehl aus, um die Web-API zu testen.curl -X GET "http://localhost/WeatherForecast" -H "accept: text/plain"
Überprüfen Sie die API-Antwort.Sie können die curl-Befehle für jeden Endpunkt von Swagger abrufen, wenn Sie ihn lokal ausführen. | App-Developer |
### Bereinigen von Ressourcen
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Löschen Sie alle Ressourcen. | Löschen Sie den Stapel, um alle Ressourcen zu entfernen. Dadurch wird sichergestellt, dass Ihnen keine Dienste in Rechnung gestellt werden, die Sie nicht nutzen. | AWS-Administrator, AWS DevOps |
## Zugehörige Ressourcen
+ [Stellen Sie mithilfe von PuTTY von Windows aus eine Connect zu Ihrer Linux-Instance her](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)
+ [Erstellen Sie eine Web-API mit ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio)
+ [Auf dem Weg zu einer Welt ohne Bastionen](https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/)
# Führen Sie statusbehaftete Workloads mit persistentem Datenspeicher aus, indem Sie Amazon EFS auf Amazon EKS mit AWS Fargate verwenden
*Ricardo Morais, Rodrigo Bersa und Lucio Pereira, Amazon Web Services*
## Zusammenfassung
Dieses Muster bietet Anleitungen zur Aktivierung von Amazon Elastic File System (Amazon EFS) als Speichergerät für Container, die auf Amazon Elastic Kubernetes Service (Amazon EKS) ausgeführt werden, indem Sie AWS Fargate zur Bereitstellung Ihrer Rechenressourcen verwenden.
Das in diesem Muster beschriebene Setup folgt bewährten Sicherheitsmethoden und bietet standardmäßig Sicherheit im Ruhezustand und Sicherheit bei der Übertragung. Um Ihr Amazon EFS-Dateisystem zu verschlüsseln, verwendet es einen AWS Key Management Service (AWS KMS) -Schlüssel, aber Sie können auch einen Schlüsselalias angeben, der den Prozess der Erstellung eines KMS-Schlüssels auslöst.
Sie können den Schritten in diesem Muster folgen, um einen Namespace und ein Fargate-Profil für eine proof-of-concept (PoC-) Anwendung zu erstellen, den Amazon EFS Container Storage Interface (CSI) -Treiber zu installieren, der für die Integration des Kubernetes-Clusters in Amazon EFS verwendet wird, die Speicherklasse zu konfigurieren und die PoC-Anwendung bereitzustellen. Diese Schritte führen zu einem Amazon EFS-Dateisystem, das von mehreren Kubernetes-Workloads gemeinsam genutzt wird und über Fargate ausgeführt wird. Das Muster wird von Skripten begleitet, die diese Schritte automatisieren.
Sie können dieses Muster verwenden, wenn Sie Datenpersistenz in Ihren containerisierten Anwendungen wünschen und Datenverluste bei Skalierungsvorgängen vermeiden möchten. Beispiel:
+ **DevOps Tools** — Ein gängiges Szenario ist die Entwicklung eines Tools für kontinuierliche Integration und kontinuierliche Bereitstellung (Continuous Delivery). CI/CD) strategy. In this case, you can use Amazon EFS as a shared file system to store configurations among different instances of the CI/CD tool or to store a cache (for example, an Apache Maven repository) for pipeline stages among different instances of the CI/CD
+ **Webserver** — Ein gängiges Szenario ist die Verwendung von Apache als HTTP-Webserver. Sie können Amazon EFS als gemeinsam genutztes Dateisystem verwenden, um statische Dateien zu speichern, die von verschiedenen Instanzen des Webservers gemeinsam genutzt werden. In diesem Beispielszenario werden Änderungen direkt auf das Dateisystem angewendet, anstatt statische Dateien in ein Docker-Image zu integrieren.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktives AWS-Konto
+ Ein vorhandener Amazon EKS-Cluster mit Kubernetes Version 1.17 oder höher (getestet bis Version 1.27)
+ Ein vorhandenes Amazon EFS-Dateisystem zum Binden von Kubernetes StorageClass und zum dynamischen Bereitstellen von Dateisystemen
+ Berechtigungen für die Clusterverwaltung
+ Kontext, der so konfiguriert ist, dass er auf den gewünschten Amazon EKS-Cluster verweist
**Einschränkungen**
+ Bei der Verwendung von Amazon EKS mit Fargate sind einige Einschränkungen zu beachten. Beispielsweise wird die Verwendung einiger Kubernetes-Konstrukte, wie z. B. DaemonSets privilegierte Container, nicht unterstützt. Weitere Informationen zu den Einschränkungen von Fargate finden Sie in den [Überlegungen zu AWS Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html#fargate-considerations) in der Amazon EKS-Dokumentation.
+ Der mit diesem Muster bereitgestellte Code unterstützt Workstations, auf denen Linux oder macOS ausgeführt wird.
**Produktversionen**
+ AWS-Befehlszeilenschnittstelle (AWS CLI) Version 2 oder höher
+ Amazon EFS CSI-Treiber Version 1.0 oder höher (getestet bis Version 2.4.8)
+ eksctl Version 0.24.0 oder höher (getestet bis Version 0.158.0)
+ jq Version 1.6 oder höher
+ kubectl Version 1.17 oder höher (getestet bis Version 1.27)
+ Kubernetes Version 1.17 oder höher (getestet bis Version 1.27)
## Architektur
![\[Architekturdiagramm der Ausführung von statusbehafteten Workloads mit persistentem Datenspeicher mithilfe von Amazon EFS\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/2487e285-269b-415b-a270-877f973e3aaf/images/ec8de63c-3307-4010-9e03-2bd7b9881fff.png)
Die Zielarchitektur besteht aus der folgenden Infrastruktur:
+ Eine Virtual Private Cloud (VPC)
+ Zwei Verfügbarkeitszonen
+ Ein öffentliches Subnetz mit einem NAT-Gateway, das Internetzugang bietet
+ Ein privates Subnetz mit einem Amazon EKS-Cluster und Amazon EFS-Mount-Zielen (auch bekannt als *Mount-Points*)
+ Amazon EFS auf VPC-Ebene
Im Folgenden finden Sie die Umgebungsinfrastruktur für den Amazon EKS-Cluster:
+ AWS Fargate-Profile, die die Kubernetes-Konstrukte auf Namespace-Ebene berücksichtigen
+ Ein Kubernetes-Namespace mit:
+ Zwei Anwendungs-Pods, die über Availability Zones verteilt sind
+ Ein persistenter Volume Claim (PVC), der an ein persistentes Volume (PV) auf Clusterebene gebunden ist
+ Ein clusterweiter PV, der an das PVC im Namespace gebunden ist und auf die Amazon EFS-Mount-Ziele im privaten Subnetz außerhalb des Clusters verweist
## Tools
**AWS-Services**
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) ist ein Open-Source-Tool, mit dem Sie über die Befehlszeile mit AWS-Services interagieren können.
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) unterstützt Sie bei der Erstellung und Konfiguration gemeinsam genutzter Dateisysteme in der AWS-Cloud. In diesem Muster bietet es ein einfaches, skalierbares, vollständig verwaltetes und gemeinsam genutztes Dateisystem für die Verwendung mit Amazon EKS.
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) hilft Ihnen, Kubernetes auf AWS auszuführen, ohne Ihre eigenen Cluster installieren oder betreiben zu müssen.
+ [AWS Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html) ist eine serverlose Rechen-Engine für Amazon EKS. Sie erstellt und verwaltet Rechenressourcen für Ihre Kubernetes-Anwendungen.
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) unterstützt Sie bei der Erstellung und Kontrolle kryptografischer Schlüssel, um Ihre Daten zu schützen.
**Andere Tools**
+ [Docker](https://www.docker.com/) ist eine Reihe von Platform-as-a-Service (PaaS) -Produkten, die Virtualisierung auf Betriebssystemebene nutzen, um Software in Containern bereitzustellen.
+ [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) ist ein Befehlszeilenprogramm zum Erstellen und Verwalten von Kubernetes-Clustern auf Amazon EKS.
+ [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) ist eine Befehlszeilenschnittstelle, mit der Sie Befehle für Kubernetes-Cluster ausführen können.
+ [jq ist ein Befehlszeilentool](https://stedolan.github.io/jq/download/) zum Parsen von JSON.
**Code**
Der Code für dieses Muster wird in der GitHub [Persistenzkonfiguration mit Amazon EFS auf Amazon EKS mithilfe des AWS Fargate-Repos](https://github.com/aws-samples/eks-efs-share-within-fargate) bereitgestellt. Die Skripts sind nach Epic in den Ordnern `epic01` bis angeordnet`epic06`, entsprechend der Reihenfolge im Abschnitt [Epics](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-epics) in diesem Muster.
## Best Practices
Die Zielarchitektur umfasst die folgenden Services und Komponenten und entspricht den Best Practices von [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/):
+ Amazon EFS, das ein einfaches, skalierbares, vollständig verwaltetes elastisches NFS-Dateisystem bietet. Dies wird als gemeinsam genutztes Dateisystem für alle Replikationen der PoC-Anwendung verwendet, die in Pods ausgeführt werden, die in den privaten Subnetzen des ausgewählten Amazon EKS-Clusters verteilt sind.
+ Ein Amazon EFS-Mount-Ziel für jedes private Subnetz. Dies bietet Redundanz pro Availability Zone innerhalb der Virtual Private Cloud (VPC) des Clusters.
+ Amazon EKS, das die Kubernetes-Workloads ausführt. Sie müssen einen Amazon EKS-Cluster bereitstellen, bevor Sie dieses Muster verwenden können, wie im Abschnitt [Voraussetzungen](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-prereqs) beschrieben.
+ AWS KMS bietet Verschlüsselung im Ruhezustand für den Inhalt, der im Amazon EFS-Dateisystem gespeichert ist.
+ Fargate, das die Rechenressourcen für die Container verwaltet, sodass Sie sich auf die Geschäftsanforderungen konzentrieren können, anstatt die Infrastruktur zu belasten. Das Fargate-Profil wird für alle privaten Subnetze erstellt. Es bietet Redundanz pro Availability Zone innerhalb der Virtual Private Cloud (VPC) des Clusters.
+ Kubernetes-Pods, mit denen überprüft wird, ob Inhalte von verschiedenen Instanzen einer Anwendung gemeinsam genutzt, genutzt und geschrieben werden können.
## Epen
### Bereitstellen eines Amazon EKS-Clusters (optional)
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie einen Amazon-EKS-Cluster. | Wenn Sie bereits einen Cluster bereitgestellt haben, fahren Sie mit dem nächsten Epic fort. Erstellen Sie einen Amazon EKS-Cluster in Ihrem bestehenden AWS-Konto. Verwenden Sie im [GitHub Verzeichnis](https://github.com/aws-samples/eks-efs-share-within-fargate/tree/master/bootstrap) eines der Muster, um einen Amazon EKS-Cluster mithilfe von Terraform oder eksctl bereitzustellen. Weitere Informationen finden Sie unter [Erstellen eines Amazon EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) in der Amazon EKS-Dokumentation. Das Terraform-Muster enthält auch Beispiele, die zeigen, wie Sie: Fargate-Profile mit Ihrem Amazon EKS-Cluster verknüpfen, ein Amazon EFS-Dateisystem erstellen und den Amazon EFS-CSI-Treiber in Ihrem Amazon EKS-Cluster bereitstellen können. | AWS-Administrator, Terraform- oder eksctl-Administrator, Kubernetes-Administrator |
| Exportieren Sie Umgebungsvariablen. | Führen Sie das Skript env.sh aus. Es enthält die Informationen, die für die nächsten Schritte erforderlich sind.source ./scripts/env.sh
Inform the AWS Account ID:
<13-digit-account-id>
Inform your AWS Region:
Inform your Amazon EKS Cluster Name:
Inform the Amazon EFS Creation Token:
Falls noch nicht angegeben, können Sie alle oben angeforderten Informationen mit den folgenden CLI-Befehlen abrufen.# ACCOUNT ID
aws sts get-caller-identity --query "Account" --output text
# REGION CODE
aws configure get region
# CLUSTER EKS NAME
aws eks list-clusters --query "clusters" --output text
# GENERATE EFS TOKEN
uuidgen
| AWS-Systemadministrator |
### Erstellen Sie einen Kubernetes-Namespace und ein verknüpftes Fargate-Profil
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie einen Kubernetes-Namespace und ein Fargate-Profil für Anwendungsworkloads. | Erstellen Sie einen Namespace für den Empfang der Anwendungs-Workloads, die mit Amazon EFS interagieren. Führen Sie das `create-k8s-ns-and-linked-fargate-profile.sh`-Skript aus. Sie können wählen, ob Sie einen benutzerdefinierten Namespace-Namen oder den standardmäßig bereitgestellten Namespace verwenden möchten. `poc-efs-eks-fargate`**Mit einem benutzerdefinierten Anwendungs-Namespace-Namen:**export $APP_NAMESPACE=
./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \
-c "$CLUSTER_NAME" -n "$APP_NAMESPACE"
**Ohne einen benutzerdefinierten Anwendungs-Namespace-Namen:**./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \
-c "$CLUSTER_NAME"
wo `$CLUSTER_NAME` ist der Name Ihres Amazon EKS-Clusters. Der `-n ` Parameter ist optional. Wenn Sie nicht darüber informiert werden, wird ein standardmäßig generierter Namespace-Name bereitgestellt. | Kubernetes-Benutzer mit erteilten Berechtigungen |
### Erstellen eines Amazon EFS-Dateisystems
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Generieren Sie ein eindeutiges Token. | Amazon EFS benötigt ein Erstellungstoken, um einen idempotenten Vorgang sicherzustellen (der Aufruf des Vorgangs mit demselben Erstellungstoken hat keine Auswirkung). Um diese Anforderung zu erfüllen, müssen Sie mithilfe einer verfügbaren Technik ein eindeutiges Token generieren. Sie können beispielsweise einen Universally Unique Identifier (UUID) generieren, um ihn als Erstellungstoken zu verwenden. | AWS-Systemadministrator |
| Erstellen Sie ein Amazon EFS-Dateisystem. | Erstellen Sie das Dateisystem für den Empfang der Datendateien, die von den Anwendungsworkloads gelesen und geschrieben werden. Sie können ein verschlüsseltes oder ein unverschlüsseltes Dateisystem erstellen. (Es hat sich bewährt, dass der Code für dieses Muster ein verschlüsseltes System erstellt, sodass die Verschlüsselung im Ruhezustand standardmäßig aktiviert ist.) Sie können einen eindeutigen, symmetrischen AWS-KMS-Schlüssel verwenden, um Ihr Dateisystem zu verschlüsseln. Wenn kein benutzerdefinierter Schlüssel angegeben ist, wird ein von AWS verwalteter Schlüssel verwendet.Verwenden Sie das Skript create-efs.sh, um ein verschlüsseltes oder unverschlüsseltes Amazon EFS-Dateisystem zu erstellen, nachdem Sie ein eindeutiges Token für Amazon EFS generiert haben.**Mit Verschlüsselung im Ruhezustand, ohne KMS-Schlüssel:**./scripts/epic02/create-efs.sh \
-c "$CLUSTER_NAME" \
-t "$EFS_CREATION_TOKEN"
wo `$CLUSTER_NAME` ist der Name Ihres Amazon EKS-Clusters und `$EFS_CREATION_TOKEN` ist ein eindeutiges Erstellungstoken für das Dateisystem.**Mit Verschlüsselung im Ruhezustand, mit einem KMS-Schlüssel:**./scripts/epic02/create-efs.sh \
-c "$CLUSTER_NAME" \
-t "$EFS_CREATION_TOKEN" \
-k "$KMS_KEY_ALIAS"
wobei `$CLUSTER_NAME` der Name Ihres Amazon EKS-Clusters, `$EFS_CREATION_TOKEN` ein eindeutiges Erstellungstoken für das Dateisystem und der Alias für den KMS-Schlüssel `$KMS_KEY_ALIAS` ist.**Ohne Verschlüsselung:**./scripts/epic02/create-efs.sh -d \
-c "$CLUSTER_NAME" \
-t "$EFS_CREATION_TOKEN"
wobei `$CLUSTER_NAME` der Name Ihres Amazon EKS-Clusters `$EFS_CREATION_TOKEN` steht, ein eindeutiges Erstellungstoken für das Dateisystem ist und die Verschlüsselung im Ruhezustand `–d` deaktiviert. | AWS-Systemadministrator |
| Erstellen einer Sicherheitsgruppe. | Erstellen Sie eine Sicherheitsgruppe, um dem Amazon EKS-Cluster den Zugriff auf das Amazon EFS-Dateisystem zu ermöglichen. | AWS-Systemadministrator |
| Aktualisieren Sie die Regel für eingehende Nachrichten für die Sicherheitsgruppe. | Aktualisieren Sie die Regeln für eingehenden Datenverkehr der Sicherheitsgruppe, um eingehenden Datenverkehr für die folgenden Einstellungen zuzulassen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate.html) | AWS-Systemadministrator |
| Fügen Sie für jedes private Subnetz ein Mount-Ziel hinzu. | Erstellen Sie für jedes private Subnetz des Kubernetes-Clusters ein Mount-Ziel für das Dateisystem und die Sicherheitsgruppe. | AWS-Systemadministrator |
### Installieren Sie Amazon EFS-Komponenten im Kubernetes-Cluster
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Stellen Sie den Amazon EFS CSI-Treiber bereit. | Stellen Sie den Amazon EFS CSI-Treiber im Cluster bereit. Der Treiber stellt Speicher entsprechend den von Anwendungen generierten persistenten Volume-Ansprüchen bereit. Führen Sie das `create-k8s-efs-csi-sc.sh` Skript aus, um den Amazon EFS CSI-Treiber und die Speicherklasse im Cluster bereitzustellen../scripts/epic03/create-k8s-efs-csi-sc.sh
Dieses Skript verwendet das `kubectl` Hilfsprogramm. Stellen Sie also sicher, dass der Kontext konfiguriert wurde, und verweisen Sie auf den gewünschten Amazon EKS-Cluster. | Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie die Speicherklasse bereit. | Stellen Sie die Speicherklasse im Cluster für den Amazon EFS-Provisioner bereit (efs.csi.aws.com). | Kubernetes-Benutzer mit erteilten Berechtigungen |
### Installieren Sie die PoC-Anwendung im Kubernetes-Cluster
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Stellen Sie das persistente Volume bereit. | Stellen Sie das persistente Volume bereit und verknüpfen Sie es mit der erstellten Speicherklasse und der ID des Amazon EFS-Dateisystems. Die Anwendung verwendet das persistente Volume zum Lesen und Schreiben von Inhalten. Sie können eine beliebige Größe für das persistente Volumen im Speicherfeld angeben. Kubernetes erfordert dieses Feld, aber da Amazon EFS ein elastisches Dateisystem ist, erzwingt es keine Dateisystemkapazität. Sie können das persistente Volume mit oder ohne Verschlüsselung bereitstellen. (Der Amazon EFS CSI-Treiber aktiviert standardmäßig die Verschlüsselung als bewährte Methode.) Führen Sie das `deploy-poc-app.sh` Skript aus, um das persistente Volume, den Anspruch auf persistente Volumes und die beiden Workloads bereitzustellen.**Bei Verschlüsselung während der Übertragung:**./scripts/epic04/deploy-poc-app.sh \
-t "$EFS_CREATION_TOKEN"
wo `$EFS_CREATION_TOKEN` ist das eindeutige Erstellungstoken für das Dateisystem.**Ohne Verschlüsselung bei der Übertragung:**./scripts/epic04/deploy-poc-app.sh -d \
-t "$EFS_CREATION_TOKEN"
wo `$EFS_CREATION_TOKEN` ist das eindeutige Erstellungstoken für das Dateisystem und `–d` deaktiviert die Verschlüsselung bei der Übertragung. | Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie den von der Anwendung angeforderten Anspruch auf persistentes Volumen bereit. | Stellen Sie den von der Anwendung angeforderten Anspruch auf beständiges Volumen bereit und verknüpfen Sie ihn mit der Speicherklasse. Verwenden Sie denselben Zugriffsmodus wie das persistente Volume, das Sie zuvor erstellt haben. Sie können im Speicherfeld eine beliebige Größe für den Anspruch auf persistentes Volumen angeben. Kubernetes erfordert dieses Feld, aber da Amazon EFS ein elastisches Dateisystem ist, erzwingt es keine Dateisystemkapazität. | Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie Workload 1 bereit. | Stellen Sie den Pod bereit, der Workload 1 der Anwendung darstellt. Dieser Workload schreibt Inhalt in die Datei`/data/out1.txt`. | Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie Workload 2 bereit. | Stellen Sie den Pod bereit, der Workload 2 der Anwendung darstellt. Dieser Workload schreibt Inhalt in die Datei`/data/out2.txt`. | Kubernetes-Benutzer mit erteilten Berechtigungen |
### Überprüfen Sie die Persistenz, Haltbarkeit und gemeinsame Nutzung des Dateisystems
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Überprüfen Sie den Status von`PersistentVolume`. | Geben Sie den folgenden Befehl ein, um den Status von zu überprüfen`PersistentVolume`.kubectl get pv
Eine Beispielausgabe finden Sie im Abschnitt [Zusätzliche Informationen](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional). | Kubernetes-Benutzer mit erteilten Berechtigungen |
| Überprüfen Sie den Status von. `PersistentVolumeClaim` | Geben Sie den folgenden Befehl ein, um den Status von zu überprüfen`PersistentVolumeClaim`.kubectl -n poc-efs-eks-fargate get pvc
Eine Beispielausgabe finden Sie im Abschnitt [Zusätzliche Informationen](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional). | Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie sicher, dass Workload 1 in das Dateisystem schreiben kann. | Geben Sie den folgenden Befehl ein, um zu überprüfen, ob Workload 1 schreibt`/data/out1.txt`.kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -f /data/out1.txt
Die Ergebnisse ähneln den folgenden:...
Thu Sep 3 15:25:07 UTC 2023 - PoC APP 1
Thu Sep 3 15:25:12 UTC 2023 - PoC APP 1
Thu Sep 3 15:25:17 UTC 2023 - PoC APP 1
...
| Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie sicher, dass Workload 2 in das Dateisystem schreiben kann. | Geben Sie den folgenden Befehl ein, um zu überprüfen, ob Workload 2 schreibt`/data/out2.txt`.kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -f /data/out2.txt
Die Ergebnisse ähneln den folgenden:...
Thu Sep 3 15:26:48 UTC 2023 - PoC APP 2
Thu Sep 3 15:26:53 UTC 2023 - PoC APP 2
Thu Sep 3 15:26:58 UTC 2023 - PoC APP 2
...
| Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie sicher, dass Workload 1 die von Workload 2 geschriebene Datei lesen kann. | Geben Sie den folgenden Befehl ein, um zu überprüfen, ob Workload 1 die von Workload 2 geschriebene `/data/out2.txt` Datei lesen kann.kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -n 3 /data/out2.txt
Die Ergebnisse ähneln den folgenden:...
Thu Sep 3 15:26:48 UTC 2023 - PoC APP 2
Thu Sep 3 15:26:53 UTC 2023 - PoC APP 2
Thu Sep 3 15:26:58 UTC 2023 - PoC APP 2
...
| Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie sicher, dass Workload 2 die von Workload 1 geschriebene Datei lesen kann. | Geben Sie den folgenden Befehl ein, um zu überprüfen, ob Workload 2 die von Workload 1 geschriebene `/data/out1.txt` Datei lesen kann.kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -n 3 /data/out1.txt
Die Ergebnisse ähneln den folgenden:...
Thu Sep 3 15:29:22 UTC 2023 - PoC APP 1
Thu Sep 3 15:29:27 UTC 2023 - PoC APP 1
Thu Sep 3 15:29:32 UTC 2023 - PoC APP 1
...
| Kubernetes-Benutzer mit erteilten Berechtigungen |
| Stellen Sie sicher, dass Dateien nach dem Entfernen von Anwendungskomponenten beibehalten werden. | Als Nächstes verwenden Sie ein Skript, um die Anwendungskomponenten (persistentes Volume, Persistentes Volume Claim und Pods) zu entfernen und zu überprüfen, ob die Dateien `/data/out1.txt` im Dateisystem aufbewahrt `/data/out2.txt` werden. Führen Sie das Skript `validate-efs-content.sh` mit dem folgenden Befehl aus../scripts/epic05/validate-efs-content.sh \
-t "$EFS_CREATION_TOKEN"
wo `$EFS_CREATION_TOKEN` ist das eindeutige Erstellungstoken für das Dateisystem.Die Ergebnisse ähneln den folgenden:pod/poc-app-validation created
Waiting for pod get Running state...
Waiting for pod get Running state...
Waiting for pod get Running state...
Results from execution of 'find /data' on validation process pod:
/data
/data/out2.txt
/data/out1.txt
| Kubernetes-Benutzer mit erteilten Berechtigungen, Systemadministrator |
### Überwachen Sie den Betrieb
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Überwachen Sie Anwendungsprotokolle. | Senden Sie die Anwendungsprotokolle im Rahmen eines Vorgangs am zweiten Tag CloudWatch zur Überwachung an Amazon. | AWS-Systemadministrator, Kubernetes-Benutzer mit erteilten Berechtigungen |
| Überwachen Sie Amazon EKS- und Kubernetes-Container mit Container Insights. | Überwachen Sie im Rahmen eines Vorgangs am zweiten Tag die Amazon EKS- und Kubernetes-Systeme mithilfe von Amazon CloudWatch Container Insights. Dieses Tool sammelt, aggregiert und fasst Metriken aus containerisierten Anwendungen auf verschiedenen Ebenen und Dimensionen zusammen. [Weitere Informationen finden Sie im Abschnitt Verwandte Ressourcen.](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-resources) | AWS-Systemadministrator, Kubernetes-Benutzer mit erteilten Berechtigungen |
| Überwachen Sie Amazon EFS mit CloudWatch. | Überwachen Sie im Rahmen eines Vorgangs am zweiten Tag die Dateisysteme mithilfe von Amazon CloudWatch, das Rohdaten von Amazon EFS sammelt und zu lesbaren Metriken nahezu in Echtzeit verarbeitet. Weitere Informationen finden Sie im Abschnitt [Verwandte Ressourcen](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-resources). | AWS-Systemadministrator |
### Bereinigen von Ressourcen
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Bereinigen Sie alle erstellten Ressourcen für das Muster. | Nachdem Sie dieses Muster abgeschlossen haben, bereinigen Sie alle Ressourcen, um zu vermeiden, dass AWS-Gebühren anfallen. Führen Sie das `clean-up-resources.sh` Skript aus, um alle Ressourcen zu entfernen, nachdem Sie die PoC-Anwendung nicht mehr verwendet haben. Füllen Sie eine der folgenden Optionen aus.**Mit Verschlüsselung im Ruhezustand, mit einem KMS-Schlüssel:**./scripts/epic06/clean-up-resources.sh \
-c "$CLUSTER_NAME" \
-t "$EFS_CREATION_TOKEN" \
-k "$KMS_KEY_ALIAS"
wobei `$CLUSTER_NAME` der Name Ihres Amazon EKS-Clusters, `$EFS_CREATION_TOKEN` das Erstellungstoken für das Dateisystem und der Alias für den KMS-Schlüssel `$KMS_KEY_ALIAS` ist.**Ohne Verschlüsselung im Ruhezustand:**./scripts/epic06/clean-up-resources.sh \
-c "$CLUSTER_NAME" \
-t "$EFS_CREATION_TOKEN"
wobei `$CLUSTER_NAME` der Name Ihres Amazon EKS-Clusters und das Erstellungstoken für das Dateisystem `$EFS_CREATION_TOKEN` ist. | Kubernetes-Benutzer mit erteilten Berechtigungen, Systemadministrator |
## Zugehörige Ressourcen
**Referenzen**
+ [AWS Fargate für Amazon EKS unterstützt jetzt Amazon EFS](https://aws.amazon.com/blogs/aws/new-aws-fargate-for-amazon-eks-now-supports-amazon-efs/) (Ankündigung)
+ [So erfassen Sie Anwendungsprotokolle bei der Verwendung von Amazon EKS auf AWS Fargate](https://aws.amazon.com/blogs/containers/how-to-capture-application-logs-when-using-amazon-eks-on-aws-fargate/) (Blogbeitrag)
+ [Verwenden von Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) ( CloudWatch Amazon-Dokumentation)
+ [Container Insights auf Amazon EKS und Kubernetes einrichten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) ( CloudWatch Amazon-Dokumentation)
+ [Kennzahlen zu Amazon EKS und Kubernetes Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) ( CloudWatch Amazon-Dokumentation)
+ [Überwachung von Amazon EFS mit Amazon CloudWatch](https://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html) (Amazon EFS-Dokumentation)
**GitHub Tutorials und Beispiele**
+ [Statische Bereitstellung](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md)
+ [Verschlüsselung während der Übertragung](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/encryption_in_transit/README.md)
+ [Zugriff auf das Dateisystem von mehreren Pods aus](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/multiple_pods/README.md)
+ [Nutzung von Amazon EFS in StatefulSets](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/statefulset/README.md)
+ [Unterpfade werden eingebunden](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/volume_path/README.md)
+ [Verwenden von Amazon EFS-Zugriffspunkten](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/access_points/README.md)
+ [Amazon EKS Blueprints für Terraform](https://aws-ia.github.io/terraform-aws-eks-blueprints/)
**Erforderliche Tools**
+ [Installation der AWS-CLI Version 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
+ [Installation von eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)
+ [Kubectl wird installiert](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
+ [jq installieren](https://stedolan.github.io/jq/download/)
## Zusätzliche Informationen
Im Folgenden finden Sie ein Beispiel für die Ausgabe des `kubectl get pv` Befehls.
```
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
poc-app-pv 1Mi RWX Retain Bound poc-efs-eks-fargate/poc-app-pvc efs-sc 3m56s
```
Im Folgenden finden Sie ein Beispiel für die Ausgabe des `kubectl -n poc-efs-eks-fargate get pvc` Befehls.
```
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
poc-app-pvc Bound poc-app-pv 1Mi RWX efs-sc 4m34s
```
# Richten Sie ereignisgesteuertes Auto Scaling in Amazon EKS mithilfe von Amazon EKS Pod Identity und KEDA ein
*Dipen Desai, Abhay Diwan, Kamal Joshi und Mahendra Revanasiddappa, Amazon Web Services*
## Zusammenfassung
Orchestrierungsplattformen wie [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) haben das Lebenszyklusmanagement containerbasierter Anwendungen optimiert. Dies hilft Unternehmen, sich auf die Entwicklung, Sicherung, den Betrieb und die Wartung containerbasierter Anwendungen zu konzentrieren. Da ereignisgesteuerte Bereitstellungen immer häufiger vorkommen, skalieren Unternehmen Kubernetes-Bereitstellungen immer häufiger auf der Grundlage verschiedener Ereignisquellen. Diese Methode kann in Kombination mit Auto Scaling zu erheblichen Kosteneinsparungen führen, da Rechenressourcen auf Abruf und eine effiziente Skalierung bereitgestellt werden, die auf die Anwendungslogik zugeschnitten ist.
[KEDA](https://keda.sh/) ist ein auf Kubernetes basierender ereignisgesteuerter Autoscaler. KEDA hilft Ihnen dabei, jeden Container in Kubernetes auf der Grundlage der Anzahl der Ereignisse, die verarbeitet werden müssen, zu skalieren. Es ist leicht und lässt sich in jeden Kubernetes-Cluster integrieren. Es funktioniert auch mit Standard-Kubernetes-Komponenten wie [Horizontal Pod Autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA). KEDA bietet auch eine Funktion [TriggerAuthentication](https://keda.sh/docs/2.14/concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication), mit der Sie die Authentifizierung delegieren können. Es ermöglicht Ihnen, Authentifizierungsparameter zu beschreiben, die von den Containern ScaledObject und den Bereitstellungscontainern getrennt sind.
AWS bietet AWS Identity and Access Management (IAM) -Rollen, die verschiedene Kubernetes-Bereitstellungsoptionen unterstützen, darunter Amazon EKS, Amazon EKS Anywhere Red Hat OpenShift Service in AWS (ROSA) und selbstverwaltete Kubernetes-Cluster auf Amazon Elastic Compute Cloud (Amazon). EC2 Diese Rollen verwenden IAM-Konstrukte wie OpenID Connect (OIDC) -Identitätsanbieter und IAM-Vertrauensrichtlinien, um in verschiedenen Umgebungen zu arbeiten, ohne sich direkt auf Amazon EKS-Services oder verlassen zu müssen. APIs Weitere Informationen finden Sie unter [IAM-Rollen für Dienstkonten](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) in der Amazon EKS-Dokumentation.
[Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) vereinfacht den Prozess, bei dem Kubernetes-Servicekonten IAM-Rollen übernehmen können, ohne dass OIDC-Anbieter erforderlich sind. Es bietet die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten. Anstatt Ihre AWS Anmeldeinformationen zu erstellen und an die Container zu verteilen oder die Rolle der EC2 Amazon-Instance zu verwenden, verknüpfen Sie eine IAM-Rolle mit einem Kubernetes-Dienstkonto und konfigurieren Ihre Pods so, dass sie das Dienstkonto verwenden. Dies hilft Ihnen, eine IAM-Rolle in mehreren Clustern zu verwenden, und vereinfacht die Richtlinienverwaltung, indem die Wiederverwendung von Berechtigungsrichtlinien für alle IAM-Rollen ermöglicht wird.
Durch die Implementierung von KEDA mit Amazon EKS Pod Identity können Unternehmen eine effiziente ereignisgesteuerte auto Skalierung und eine vereinfachte Verwaltung von Anmeldeinformationen erreichen. Anwendungen werden je nach Bedarf skaliert, wodurch die Ressourcennutzung optimiert und die Kosten gesenkt werden.
Dieses Muster hilft Ihnen bei der Integration von Amazon EKS Pod Identity in KEDA. Es zeigt, wie Sie das `keda-operator` Dienstkonto verwenden und die Authentifizierung delegieren können. `TriggerAuthentication` Außerdem wird beschrieben, wie eine Vertrauensbeziehung zwischen einer IAM-Rolle für den KEDA-Operator und einer IAM-Rolle für die Anwendung eingerichtet wird. Diese Vertrauensbeziehung ermöglicht es KEDA, Nachrichten in den Ereigniswarteschlangen zu überwachen und die Skalierung für die Kubernetes-Zielobjekte anzupassen.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ AWS Command Line Interface [(AWS CLI) Version 2.13.17 oder höher, installiert](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Python-Version 3.11.5 oder höher, installiert](https://www.python.org/downloads/)
+ AWS SDK für Python (Boto3) [Version 1.34.135 oder höher, installiert](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html)
+ [Helm Version 3.12.3 oder höher, installiert](https://helm.sh/docs/intro/install/)
+ [kubectl Version 1.25.1 oder höher, installiert](https://kubernetes.io/docs/tasks/tools/)
+ [Docker Engine Version 26.1.1 oder höher, installiert](https://docs.docker.com/engine/install/)
+ [Ein Amazon EKS-Cluster Version 1.24 oder höher, erstellt](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)
+ Voraussetzungen für die Erstellung des Amazon EKS Pod Identity-Agenten, [erfüllt](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html#pod-id-agent-add-on-create)
**Einschränkungen**
+ Es ist erforderlich, dass Sie eine Vertrauensbeziehung zwischen der `keda-operator` Rolle und der `keda-identity` Rolle einrichten. Anweisungen finden Sie im Abschnitt [Epen](#event-driven-auto-scaling-with-eks-pod-identity-and-keda-epics) dieses Musters.
## Architektur
In diesem Muster erstellen Sie die folgenden AWS Ressourcen:
+ **Amazon Elastic Container Registry (Amazon ECR) -Repository** — In diesem Muster wird dieses Repo benannt. `keda-pod-identity-registry` Dieses private Repo wird zum Speichern von Docker-Images der Beispielanwendung verwendet.
+ **Amazon Simple Queue Service (Amazon SQS) -Warteschlange** — In diesem Muster wird diese Warteschlange benannt`event-messages-queue`. Die Warteschlange fungiert als Nachrichtenpuffer, der eingehende Nachrichten sammelt und speichert. KEDA überwacht die Warteschlangenmetriken, z. B. die Anzahl der Nachrichten oder die Länge der Warteschlange, und skaliert die Anwendung automatisch auf der Grundlage dieser Messwerte.
+ **IAM-Rolle für die Anwendung** — In diesem Muster wird diese Rolle benannt. `keda-identity` Die `keda-operator` Rolle übernimmt diese Rolle. Diese Rolle ermöglicht den Zugriff auf die Amazon SQS SQS-Warteschlange.
+ **IAM-Rolle für den KEDA-Operator** — In diesem Muster wird diese Rolle benannt. `keda-operator` Der KEDA-Operator verwendet diese Rolle, um die erforderlichen AWS API-Aufrufe durchzuführen. Diese Rolle ist berechtigt, die `keda-identity` Rolle zu übernehmen. Aufgrund der Vertrauensstellung zwischen den Rollen `keda-operator` und den `keda-identity` Rollen verfügt die `keda-operator` Rolle über Amazon SQS SQS-Berechtigungen.
Über die benutzerdefinierten Ressourcen `TriggerAuthentication` und `ScaledObject` Kubernetes verwendet der Operator die `keda-identity` Rolle, um eine Verbindung mit einer Amazon SQS SQS-Warteschlange herzustellen. Basierend auf der Größe der Warteschlange skaliert KEDA die Anwendungsbereitstellung automatisch. Es fügt 1 Pod für jeweils 5 ungelesene Nachrichten in der Warteschlange hinzu. Wenn sich in der Standardkonfiguration keine ungelesenen Nachrichten in der Amazon SQS SQS-Warteschlange befinden, wird die Anwendung auf 0 Pods herunterskaliert. Der KEDA-Operator überwacht die Warteschlange in einem von Ihnen festgelegten Intervall.
Die folgende Abbildung zeigt, wie Sie Amazon EKS Pod Identity verwenden, um der `keda-operator` Rolle sicheren Zugriff auf die Amazon SQS SQS-Warteschlange zu gewähren.
![\[Verwendung von KEDA und Amazon EKS Pod Identity zur automatischen Skalierung einer Kubernetes-basierten Anwendung.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/56f7506d-e8d3-43e5-bec6-42267fedd0ae/images/05bdbd09-9eb8-4c0b-8c0d-efe38aecb683.png)
Das Diagramm zeigt den folgenden Workflow:
1. Sie installieren den Amazon EKS Pod Identity-Agenten im Amazon EKS-Cluster.
1. Sie stellen den KEDA-Operator im KEDA-Namespace im Amazon EKS-Cluster bereit.
1. Sie erstellen die Rollen `keda-operator` und `keda-identity` IAM im Ziel. AWS-Konto
1. Sie stellen eine Vertrauensbeziehung zwischen den IAM-Rollen her.
1. Sie stellen die Anwendung im `security` Namespace bereit.
1. Der KEDA-Operator fragt Nachrichten in einer Amazon SQS SQS-Warteschlange ab.
1. KEDA initiiert HPA, wodurch die Anwendung automatisch auf der Grundlage der Warteschlangengröße skaliert wird.
## Tools
**AWS-Services**
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) ist ein verwalteter Container-Image-Registry-Service, der sicher, skalierbar und zuverlässig ist.
+ Mit [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) können Sie Kubernetes ausführen, AWS ohne dass Sie Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten müssen.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) hilft Ihnen dabei, den Zugriff auf Ihre AWS Ressourcen sicher zu verwalten, indem kontrolliert wird, wer authentifiziert und autorisiert ist, diese zu verwenden.
+ [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) bietet eine sichere, dauerhafte und verfügbare gehostete Warteschlange, mit der Sie verteilte Softwaresysteme und -komponenten integrieren und entkoppeln können.
**Andere Tools**
+ [KEDA](https://keda.sh/) ist ein auf Kubernetes basierender ereignisgesteuerter Autoscaler.
**Code-Repository**
Der Code für dieses Muster ist im GitHub [Event-Driven Auto Scaling using EKS Pod Identity and KEDA](https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main) Repository verfügbar.
## Best Practices
Wir empfehlen Ihnen, die ACM bewährte Methode für zu befolgen.
+ [Bewährte Methoden für Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html)
+ [Bewährte Methoden für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Bewährte Methoden für Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-best-practices.html)
## Epen
### Ressourcen erstellen AWS
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie die IAM-Rolle für den KEDA-Operator. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS-Administrator |
| Erstellen Sie die IAM-Rolle für die Beispielanwendung. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS-Administrator |
| Erstellen einer Amazon SQS-Warteschlange | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | Allgemeines AWS |
| Erstellen Sie ein Amazon-ECR-Repository. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | Allgemeines AWS |
### Den Amazon EKS-Cluster einrichten
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Stellen Sie den Amazon EKS Pod Identity-Agenten bereit. | Richten Sie für den Amazon EKS-Zielcluster den Amazon EKS Pod Identity-Agenten ein. Folgen Sie den Anweisungen unter [Amazon EKS Pod Identity Agent einrichten](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html#pod-id-agent-add-on-create) in der Amazon EKS-Dokumentation. | AWS DevOps |
| Stellen Sie KEDA bereit. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
| Weisen Sie dem Kubernetes-Dienstkonto die IAM-Rolle zu. | Folgen Sie den Anweisungen unter [Zuweisen einer IAM-Rolle zu einem Kubernetes-Servicekonto](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html) in der Amazon EKS-Dokumentation. Verwenden Sie die folgenden Werte:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | AWS DevOps |
| Erstellen Sie einen -Namespace. | Geben Sie den folgenden Befehl ein, um einen `security` Namespace im Amazon EKS-Zielcluster zu erstellen:kubectl create ns security
| DevOps Ingenieur |
### Bereitstellen der Beispielanwendung
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Klonen Sie die Anwendungsdateien. | Geben Sie den folgenden Befehl ein, um die [ereignisgesteuerte auto Skalierung mithilfe von EKS Pod Identity und dem KEDA-Repository](https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main) von zu klonen: GitHubgit clone https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda.git
| DevOps Ingenieur |
| Erstellen Sie das Docker-Image. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
| Senden Sie das Docker-Image an Amazon ECR. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html)Sie finden Push-Befehle, indem Sie zur Amazon ECR-Repository-Seite navigieren und dann **Push-Befehle anzeigen** wählen. | DevOps Ingenieur |
| Stellen Sie die Beispielanwendung bereit. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
| Weisen Sie dem Anwendungsdienstkonto die IAM-Rolle zu. | Gehen Sie wie folgt vor, um die `keda-identity` IAM-Rolle dem Dienstkonto für die Beispielanwendung zuzuordnen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
| Bereitstellen `ScaledObject` und`TriggerAuthentication`. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
### Testen Sie die auto Skalierung
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Senden Sie Nachrichten an die Amazon SQS SQS-Warteschlange. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
| Überwachen Sie die Anwendungs-Pods. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps Ingenieur |
## Fehlerbehebung
| Problem | Lösung |
| --- | --- |
| Der KEDA-Operator kann die Anwendung nicht skalieren. | Geben Sie den folgenden Befehl ein, um die Protokolle der `keda-operator` IAM-Rolle zu überprüfen:kubectl logs -n keda -l app=keda-operator -c keda-operator
Wenn es einen `HTTP 403` Antwortcode gibt, verfügen die Anwendung und der KEDA-Scaler nicht über ausreichende Berechtigungen, um auf die Amazon SQS SQS-Warteschlange zuzugreifen. Führen Sie folgende Schritte aus:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html)Wenn ein `Assume-Role` Fehler auftritt, kann eine [Amazon EKS-Knoten-IAM-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html) die IAM-Rolle, für die definiert ist, nicht übernehmen. `TriggerAuthentication` Führen Sie folgende Schritte aus:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) |
## Zugehörige Ressourcen
+ [Den Amazon EKS Pod Identity Agent einrichten](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) (Amazon EKS-Dokumentation)
+ [Bereitstellung von KEDA](https://keda.sh/docs/2.14/deploy/) (KEDA-Dokumentation)
+ [ScaledObject Spezifikation](https://keda.sh/docs/2.16/reference/scaledobject-spec/) (KEDA-Dokumentation)
+ [Authentifizierung mit TriggerAuthentication](https://keda.sh/docs/2.14/concepts/authentication/) (KEDA-Dokumentation)
# Optimieren Sie PostgreSQL-Bereitstellungen auf Amazon EKS mithilfe von PGO
*Shalaka Dengale, Amazon Web Services*
## Zusammenfassung
Dieses Muster integriert den Postgres-Operator von Crunchy Data (PGO) mit Amazon Elastic Kubernetes Service (Amazon EKS), um PostgreSQL-Bereitstellungen in cloudnativen Umgebungen zu optimieren. PGO bietet Automatisierung und Skalierbarkeit für die Verwaltung von PostgreSQL-Datenbanken in Kubernetes. Wenn Sie PGO mit Amazon EKS kombinieren, bildet es eine robuste Plattform für die effiziente Bereitstellung, Verwaltung und Skalierung von PostgreSQL-Datenbanken.
Diese Integration bietet die folgenden Hauptvorteile:
+ Automatisierte Bereitstellung: Vereinfacht die Bereitstellung und Verwaltung von PostgreSQL-Clustern.
+ Benutzerdefinierte Ressourcendefinitionen (CRDs):**** Verwendet Kubernetes-Primitive für das PostgreSQL-Management.
+ Hohe Verfügbarkeit: Unterstützt automatisches Failover und synchrone Replikation.
+ Automatisierte Backups und Wiederherstellungen:**** Optimiert Sicherungs- und Wiederherstellungsprozesse.
+ Horizontale Skalierung:**** Ermöglicht die dynamische Skalierung von PostgreSQL-Clustern.
+ Versionsupgrades: Ermöglicht fortlaufende Upgrades mit minimalen Ausfallzeiten.
+ Sicherheit: Erzwingt Verschlüsselungs-, Zugriffskontrollen und Authentifizierungsmechanismen.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktiver AWS-Konto.
+ [AWS-Befehlszeilenschnittstelle (AWS CLI) Version 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html), installiert und konfiguriert unter Linux, macOS oder Windows.
+ [AWS CLI Config](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html), um AWS Ressourcen über die Befehlszeile zu verbinden.
+ [eksctl](https://github.com/eksctl-io/eksctl#installation), installiert und konfiguriert unter Linux, MacOS oder Windows.
+ `kubectl`, installiert und konfiguriert für den Zugriff auf Ressourcen in Ihrem Amazon EKS-Cluster. Weitere Informationen finden Sie unter [Kubectl und eksctl einrichten in der Amazon EKS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html).
+ Ihr Computerterminal ist für den Zugriff auf den Amazon EKS-Cluster konfiguriert. Weitere Informationen finden [Sie in der Amazon EKS-Dokumentation unter Konfiguration Ihres Computers für die Kommunikation mit Ihrem Cluster](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-configure-kubectl).
**Produktversionen**
+ [Kubernetes-Versionen 1.21—1.24 oder höher (siehe PGO-Dokumentation).](https://access.crunchydata.com/documentation/postgres-operator/5.2.5/)
+ PostgreSQL Version 10 oder höher. Dieses Muster verwendet PostgreSQL Version 16.
**Einschränkungen**
+ Einige AWS-Services sind nicht in allen verfügbar. AWS-Regionen Informationen zur Verfügbarkeit in den einzelnen Regionen finden Sie [AWS-Services unter Nach Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). Informationen zu bestimmten Endpunkten finden Sie auf der Seite [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html). Wählen Sie dort den Link für den Dienst aus.
## Architektur
**Zieltechnologie-Stack**
+ Amazon EKS
+ Amazon Virtual Private Cloud (Amazon VPC)
+ Amazon Elastic Compute Cloud (Amazon EC2)
**Zielarchitektur**
![\[Architektur für die Verwendung von PGO mit drei Availability Zones und zwei Replikaten sowie PgBouncer PGO-Operator.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/4c164012-7527-4ebe-b6a7-c129600328d6/images/26a5572b-405b-4634-b96a-91254c3ea2c1.png)
Dieses Muster erstellt eine Architektur, die einen Amazon EKS-Cluster mit drei Knoten enthält. Jeder Knoten läuft auf einer Reihe von EC2-Instances im Backend. Dieses PostgreSQL-Setup folgt einer primären Replikatarchitektur, die besonders für leseintensive Anwendungsfälle effektiv ist. Die Architektur umfasst die folgenden Komponenten:
+ Der **primäre Datenbankcontainer (pg-primary)** hostet die PostgreSQL-Hauptinstanz, an die alle Schreibvorgänge gerichtet sind.
+ **Sekundäre Replikatcontainer (pg-replica)** hosten die PostgreSQL-Instanzen, die die Daten aus der Primärdatenbank replizieren und Lesevorgänge abwickeln.
+ **PgBouncer**ist ein leichter Verbindungspooler für PostgreSQL-Datenbanken, der in PGO enthalten ist. Es befindet sich zwischen dem Client und dem PostgreSQL-Server und fungiert als Vermittler für Datenbankverbindungen.
+ **PGO** automatisiert die Bereitstellung und Verwaltung von PostgreSQL-Clustern in dieser Kubernetes-Umgebung.
+ **Patroni** ist ein Open-Source-Tool, das Hochverfügbarkeitskonfigurationen für PostgreSQL verwaltet und automatisiert. Es ist in PGO enthalten. Wenn Sie Patroni mit PGO in Kubernetes verwenden, spielt dies eine entscheidende Rolle bei der Sicherstellung der Widerstandsfähigkeit und Fehlertoleranz eines PostgreSQL-Clusters. [Weitere Informationen finden Sie in der Patroni-Dokumentation.](https://patroni.readthedocs.io/en/latest/)
Der Workflow umfasst die folgenden Schritte:
+ **Stellen Sie den PGO-Operator** bereit. Sie stellen den PGO-Operator auf Ihrem Kubernetes-Cluster bereit, der auf Amazon EKS läuft. Dies kann mithilfe von Kubernetes-Manifesten oder Helm-Diagrammen erfolgen. Dieses Muster verwendet Kubernetes-Manifeste.
+ **Definieren Sie PostgreSQL-Instanzen**. Wenn der Operator ausgeführt wird, erstellen Sie benutzerdefinierte Ressourcen (CRs), um den gewünschten Status von PostgreSQL-Instanzen anzugeben. Dazu gehören Konfigurationen wie Speicher-, Replikations- und Hochverfügbarkeitseinstellungen.
+ **Betreiberverwaltung**. Sie interagieren mit dem Operator über Kubernetes-API-Objekte, z. B. CRs um PostgreSQL-Instanzen zu erstellen, zu aktualisieren oder zu löschen.
+ **Überwachung und Wartung.** Sie können den Zustand und die Leistung der PostgreSQL-Instances überwachen, die auf Amazon EKS ausgeführt werden. Betreiber stellen häufig Metriken und Protokollierung zu Überwachungszwecken bereit. Sie können bei Bedarf routinemäßige Wartungsaufgaben wie Upgrades und Patches durchführen. Weitere Informationen finden Sie unter [Überwachen der Cluster-Leistung und Anzeigen von Protokollen](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html) in der Amazon EKS-Dokumentation.
+ **Skalierung und Backup**: Sie können die vom Betreiber bereitgestellten Funktionen verwenden, um PostgreSQL-Instanzen zu skalieren und Backups zu verwalten.
Dieses Muster deckt keine Überwachungs-, Wartungs- und Sicherungsvorgänge ab.
**Automatisierung und Skalierung**
+ Sie können es verwenden CloudFormation , um die Erstellung der Infrastruktur zu automatisieren. Weitere Informationen finden Sie unter [Amazon EKS-Ressourcen erstellen mit CloudFormation](https://docs.aws.amazon.com/eks/latest/userguide/creating-resources-with-cloudformation.html) in der Amazon EKS-Dokumentation.
+ Sie können Build Numbers GitVersion oder Jenkins verwenden, um die Bereitstellung von Datenbank-Instances zu automatisieren.
## Tools
**AWS-Services**
+ Mit [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) können Sie Kubernetes ausführen, AWS ohne dass Sie Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten müssen.
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) ist ein Open-Source-Tool, mit dem Sie über Befehle in Ihrer Befehlszeilen-Shell interagieren AWS-Services können.
**Andere Tools**
+ [eksctl](https://eksctl.io/) ist ein einfaches Befehlszeilentool zum Erstellen von Clustern auf Amazon EKS.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) ist ein Befehlszeilenprogramm zum Ausführen von Befehlen für Kubernetes-Cluster.
+ [PGO](https://github.com/CrunchyData/postgres-operator) automatisiert und skaliert die Verwaltung von PostgreSQL-Datenbanken in Kubernetes.
## Best Practices
Folgen Sie diesen Best Practices, um eine reibungslose und effiziente Bereitstellung zu gewährleisten:
+ **Schützen Sie Ihren EKS-Cluster**. Implementieren Sie bewährte Sicherheitsmethoden für Ihren EKS-Cluster, z. B. die Verwendung von AWS Identity and Access Management (IAM-) Rollen für Dienstkonten (IRSA), Netzwerkrichtlinien und VPC-Sicherheitsgruppen. Beschränken Sie den Zugriff auf den EKS-Cluster-API-Server und verschlüsseln Sie die Kommunikation zwischen den Knoten und dem API-Server mithilfe von TLS.
+ **Stellen Sie die Versionskompatibilität** zwischen PGO und Kubernetes sicher, die auf Amazon EKS ausgeführt werden. Einige PGO-Funktionen erfordern möglicherweise bestimmte Kubernetes-Versionen oder führen zu Kompatibilitätseinschränkungen. Weitere Informationen finden Sie in der PGO-Dokumentation unter [Komponenten und Kompatibilität](https://access.crunchydata.com/documentation/postgres-operator/5.2.5/references/components/).
+ **Planen Sie die Ressourcenzuweisung** für Ihre PGO-Bereitstellung, einschließlich CPU, Arbeitsspeicher und Speicher. Berücksichtigen Sie die Ressourcenanforderungen sowohl von PGO als auch der von ihr verwalteten PostgreSQL-Instanzen. Überwachen Sie die Ressourcennutzung und skalieren Sie die Ressourcen nach Bedarf.
+ **Design für hohe Verfügbarkeit**. Gestalten Sie Ihre PGO-Bereitstellung für hohe Verfügbarkeit, um Ausfallzeiten zu minimieren und die Zuverlässigkeit zu gewährleisten. Stellen Sie aus Gründen der Fehlertoleranz mehrere PGO-Repliken in mehreren Availability Zones bereit.
+ **Implementieren Sie Sicherungs- und Wiederherstellungsverfahren** für Ihre von PGO verwalteten PostgreSQL-Datenbanken. Verwenden Sie Funktionen von PGO oder Backup-Lösungen von Drittanbietern, die mit Kubernetes und Amazon EKS kompatibel sind.
+ **Richten Sie die Überwachung und Protokollierung** für Ihre PGO-Bereitstellung ein, um Leistung, Zustand und Ereignisse zu verfolgen. Verwenden Sie Tools wie Prometheus für die Überwachung von Metriken und Grafana für die Visualisierung. Konfigurieren Sie die Protokollierung, um PGO-Protokolle zur Fehlerbehebung und Prüfung zu erfassen.
+ **Konfigurieren Sie das Netzwerk** ordnungsgemäß, um die Kommunikation zwischen PGO, PostgreSQL-Instanzen und anderen Diensten in Ihrem Kubernetes-Cluster zu ermöglichen. Verwenden Sie Amazon VPC-Netzwerkfunktionen und Kubernetes-Netzwerk-Plugins wie Calico oder [Amazon VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) für die Durchsetzung von Netzwerkrichtlinien und die Isolierung des Datenverkehrs.
+ **Wählen Sie geeignete Speicheroptionen** für Ihre PostgreSQL-Datenbanken aus und berücksichtigen Sie dabei Faktoren wie Leistung, Haltbarkeit und Skalierbarkeit. Verwenden Sie Amazon Elastic Block Store (Amazon EBS) -Volumes oder AWS verwaltete Speicherdienste für persistenten Speicher. Weitere Informationen finden Sie unter [Speichern von Kubernetes-Volumes mit Amazon EBS in der Amazon EKS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html).
+ **Verwenden Sie Infrastructure-as-Code-Tools (IaC)** CloudFormation , um beispielsweise die Bereitstellung und Konfiguration von PGO auf Amazon EKS zu automatisieren. Definieren Sie Infrastrukturkomponenten — einschließlich des EKS-Clusters, der Netzwerk- und PGO-Ressourcen — als Code, um Konsistenz, Wiederholbarkeit und Versionskontrolle zu gewährleisten.
## Epen
### Erstellen einer IAM-Rolle
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie eine IAM-Rolle. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS-Administrator |
### Amazon-EKS-Cluster erstellen
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie einen Amazon-EKS-Cluster. | Wenn Sie bereits einen Cluster bereitgestellt haben, überspringen Sie diesen Schritt. Andernfalls stellen Sie einen Amazon EKS-Cluster in Ihrem aktuellen mithilfe AWS-Konto `eksctl` von Terraform oder bereit. CloudFormation Dieses Muster wird `eksctl` für die Cluster-Bereitstellung verwendet.Dieses Muster verwendet Amazon EC2 als Knotengruppe für Amazon EKS. Wenn Sie es verwenden möchten AWS Fargate, lesen Sie die `managedNodeGroups` Konfiguration in der [eksctl-Dokumentation](https://eksctl.io/usage/schema/#managedNodeGroups).[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS-Administrator, Terraform- oder eksctl-Administrator, Kubernetes-Administrator |
| Überprüfen Sie den Status des Clusters. | Führen Sie den folgenden Befehl aus, um den aktuellen Status der Knoten im Cluster zu überprüfen:kubectl get nodes
Wenn Sie auf Fehler stoßen, lesen Sie den [Abschnitt zur Fehlerbehebung](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html) in der Amazon EKS-Dokumentation. | AWS-Administrator, Terraform- oder eksctl-Administrator, Kubernetes-Administrator |
### Erstellen Sie einen OIDC-Identitätsanbieter
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Aktivieren Sie den IAM OIDC-Anbieter. | Als Voraussetzung für den Amazon EBS Container Storage Interface (CSI) -Treiber benötigen Sie einen vorhandenen IAM OpenID Connect (OIDC) -Anbieter für Ihren Cluster.Aktivieren Sie den IAM OIDC-Anbieter mit dem folgenden Befehl:eksctl utils associate-iam-oidc-provider --region={region} --cluster={YourClusterNameHere} --approveWeitere Informationen zu diesem Schritt finden Sie in der [Amazon EKS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html). | AWS-Administrator |
| Erstellen Sie eine IAM-Rolle für den Amazon EBS CSI-Treiber. | Verwenden Sie den folgenden `eksctl` Befehl, um die IAM-Rolle für den CSI-Treiber zu erstellen:eksctl create iamserviceaccount \
--region {RegionName} \
--name ebs-csi-controller-sa \
--namespace kube-system \
--cluster {YourClusterNameHere} \
--attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--approve \
--role-only \
--role-name AmazonEKS_EBS_CSI_DriverRole
Wenn Sie verschlüsselte Amazon EBS-Laufwerke verwenden, müssen Sie die Richtlinie weiter konfigurieren. Anweisungen finden Sie in der [Amazon EBS SCI-Treiberdokumentation](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#installation-1). | AWS-Administrator |
| Fügen Sie den Amazon EBS CSI-Treiber hinzu. | Verwenden Sie den folgenden `eksctl` Befehl, um den Amazon EBS CSI-Treiber hinzuzufügen:eksctl create addon \
--name aws-ebs-csi-driver \
--cluster service-account-role-arn arn:aws:iam::$(aws sts get-caller-identity \
--query Account \
--output text):role/AmazonEKS_EBS_CSI_DriverRole \
--force
| AWS-Administrator |
### Installieren Sie PGO
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Klonen Sie das PGO-Repository. | Klonen Sie das GitHub Repository für PGO:git clone https://github.com/CrunchyData/postgres-operator-examples.git
| AWS DevOps |
| Geben Sie die Rollendetails für die Erstellung des Dienstkontos an. | Um dem Amazon EKS-Cluster Zugriff auf die erforderlichen AWS Ressourcen zu gewähren, geben Sie den Amazon-Ressourcennamen (ARN) der OIDC-Rolle an, die Sie zuvor erstellt haben, in der `service_account.yaml` Datei, die sich unter befindet. [GitHub](https://github.com/CrunchyData/postgres-operator/blob/main/config/rbac/cluster/service_account.yaml)cd postgres-operator-examples
---
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam:::role/ # Update the OIDC role ARN created earlier
| AWS-Administrator, Kubernetes-Administrator |
| Erstellen Sie den Namespace und die PGO-Voraussetzungen. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | Kubernetes-Administrator |
| Überprüfen Sie die Erstellung von Pods. | Stellen Sie sicher, dass der Namespace und die Standardkonfiguration erstellt wurden:kubectl get pods -n postgres-operator
| AWS-Administrator, Kubernetes-Administrator |
| Verifizieren. PVCs | Verwenden Sie den folgenden Befehl, um Ansprüche auf persistente Volumes (PVCs) zu überprüfen:kubectl describe pvc -n postgres-operator
| AWS-Administrator, Kubernetes-Administrator |
### Erstellen Sie einen Operator und stellen Sie ihn bereit
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie einen Operator. | Überarbeiten Sie den Inhalt der Datei unter`/kustomize/postgres/postgres.yaml`, sodass er den folgenden Kriterien entspricht:spec:
instances:
- name: pg-1
replicas: 3
patroni:
dynamicConfiguration:
postgresql:
pg_hba:
- "host all all 0.0.0.0/0 trust" # this line enabled logical replication with programmatic access
- "host all postgres 127.0.0.1/32 md5"
synchronous_mode: true
users:
- name: replicator
databases:
- testdb
options: "REPLICATION"
Diese Updates bewirken Folgendes:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS-Administrator, DBA, Kubernetes-Administrator |
| Stellen Sie den Operator bereit. | Stellen Sie den PGO-Operator bereit, um die Verwaltung und den Betrieb von PostgreSQL-Datenbanken in Kubernetes-Umgebungen zu optimieren:kubectl apply -k kustomize/postgres
| AWS-Administrator, DBA, Kubernetes-Administrator |
| Überprüfen Sie die Bereitstellung. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html)Notieren Sie sich in der Befehlsausgabe das primäre Replikat (`primary_pod_name`) und das Lesereplikat (`read_pod_name`). Sie werden diese in den nächsten Schritten verwenden. | AWS-Administrator, DBA, Kubernetes-Administrator |
### Überprüfen Sie die Streaming-Replikation
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Schreiben Sie Daten in das primäre Replikat. | Verwenden Sie die folgenden Befehle, um eine Verbindung zum primären PostgreSQL-Replikat herzustellen und Daten in die Datenbank zu schreiben:kubectl exec -it bash -n postgres-operator
psql
CREATE TABLE customers (firstname text, customer_id serial, date_created timestamp);
\dt
| AWS-Administrator, Kubernetes-Administrator |
| Vergewissern Sie sich, dass die Read Replica dieselben Daten enthält. | Connect zur PostgreSQL-Read Replica her und überprüfen Sie, ob die Streaming-Replikation ordnungsgemäß funktioniert:kubectl exec -it {read_pod_name} bash -n postgres-operatorpsql
\dt
Die Read Replica sollte die Tabelle enthalten, die Sie im vorherigen Schritt im primären Replikat erstellt haben. | AWS-Administrator, Kubernetes-Administrator |
## Fehlerbehebung
| Problem | Lösung |
| --- | --- |
| Der Pod startet nicht. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) |
| Replikate liegen deutlich hinter der Primärdatenbank zurück. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) |
| Sie haben keinen Einblick in die Leistung und den Zustand des PostgreSQL-Clusters. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) |
| Die Replikation funktioniert nicht. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) |
## Zugehörige Ressourcen
+ [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html) (*Überblick über Bereitstellungsoptionen auf AWS-Whitepaper*)
+ [CloudFormation](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/aws-cloudformation.html)(*Whitepaper über die Bereitstellungsoptionen auf AWS*)
+ [Erste Schritte mit Amazon EKS — eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) (*Amazon EKS-Benutzerhandbuch*)
+ [Kubectl und eksctl einrichten (*Amazon* EKS-Benutzerhandbuch](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html))
+ [Eine Rolle für den OpenID Connect-Verbund erstellen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html) (*IAM-Benutzerhandbuch*)
+ [Konfiguration der Einstellungen für das AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) (*AWS CLI Benutzerhandbuch*)
+ [Dokumentation zu Crunchy Postgres für Kubernetes](https://access.crunchydata.com/documentation/postgres-operator/latest)
+ [Crunch & Learn: Crunchy Postgres für Kubernetes 5.0 (Video](https://www.youtube-nocookie.com/embed/IIf9WZO3K50))
# Vereinfachen Sie die Anwendungsauthentifizierung mit gegenseitigem TLS in Amazon ECS mithilfe von Application Load Balancer
*Olawale Olaleye und Shamanth Devagari, Amazon Web Services*
## Zusammenfassung
Dieses Muster hilft Ihnen dabei, Ihre Anwendungsauthentifizierung zu vereinfachen und Sicherheitsbelastungen mit gegenseitigem TLS in Amazon Elastic Container Service (Amazon ECS) mithilfe von [Application Load Balancer (](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html)ALB) zu entlasten. Mit ALB können Sie X.509-Client-Zertifikate von authentifizieren. AWS Private Certificate Authority Diese leistungsstarke Kombination trägt zu einer sicheren Kommunikation zwischen Ihren Diensten bei und reduziert so den Bedarf an komplexen Authentifizierungsmechanismen innerhalb Ihrer Anwendungen. Darüber hinaus verwendet das Muster Amazon Elastic Container Registry (Amazon ECR) zum Speichern von Container-Images.
Das Beispiel in diesem Muster verwendet Docker-Bilder aus einer öffentlichen Galerie, um die Beispiel-Workloads zunächst zu erstellen. Anschließend werden neue Docker-Images für die Speicherung in Amazon ECR erstellt. Ziehen Sie als Quelle ein Git-basiertes System wie GitHub, oder Bitbucket in Betracht GitLab, oder verwenden Sie Amazon Simple Storage Service Amazon S3 (Amazon S3). Für die Erstellung der Docker-Images sollten Sie die Verwendung AWS CodeBuild für die nachfolgenden Images in Betracht ziehen.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein Aktiv AWS-Konto mit Zugriff auf die Bereitstellung von AWS CloudFormation Stacks. Stellen Sie sicher, dass Sie über AWS Identity and Access Management (IAM-) [Benutzer- oder Rollenberechtigungen für die Bereitstellung verfügen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/control-access-with-iam.html). CloudFormation
+ AWS Command Line Interface (AWS CLI) [installiert](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). [Konfigurieren Sie](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) Ihre AWS Anmeldeinformationen auf Ihrem lokalen Computer oder in Ihrer Umgebung, indem Sie entweder die AWS CLI oder verwenden, indem Sie die Umgebungsvariablen in der `~/.aws/credentials` Datei festlegen.
+ OpenSSL [installiert](https://www.openssl.org/).
+ [Docker installiert.](https://www.docker.com/get-started/)
+ [Vertrautheit mit den AWS-Services unter Tools beschriebenen Funktionen.](#simplify-application-authentication-with-mutual-tls-in-amazon-ecs-tools)
+ Kenntnisse von Docker und NGINX.
**Einschränkungen**
+ Mutual TLS für Application Load Balancer unterstützt nur X.509v3-Clientzertifikate. X.509v1-Clientzertifikate werden nicht unterstützt.
+ Die CloudFormation Vorlage, die im Code-Repository dieses Musters bereitgestellt wird, beinhaltet nicht die Bereitstellung eines CodeBuild Projekts als Teil des Stacks.
+ Einige AWS-Services sind nicht in allen AWS-Regionen verfügbar. Informationen zur Verfügbarkeit in den einzelnen Regionen finden Sie unter [AWS Dienste nach Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). Informationen zu bestimmten Endpunkten finden Sie unter [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html). Wählen Sie dort den Link für den Dienst aus.
**Produktversionen**
+ Docker-Version 27.3.1 oder höher
+ AWS CLI Version 2.14.5 oder höher
## Architektur
Das folgende Diagramm zeigt die Architekturkomponenten für dieses Muster.
![\[Workflow zur Authentifizierung mit Mutual TLS mithilfe von Application Load Balancer.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/a343fa4e-097f-416b-9c83-01a28eb57dc3/images/e1371297-b987-4487-9b13-8120933c921f.png)
Das Diagramm zeigt den folgenden Workflow:
1. Erstellen Sie ein Git-Repository und übertragen Sie den Anwendungscode in das Repository.
1. Erstellen Sie eine private Zertifizierungsstelle (CA) in AWS Private CA.
1. Erstellen Sie ein CodeBuild Projekt. Das CodeBuildproject wird durch Commit-Änderungen ausgelöst und erstellt das Docker-Image und veröffentlicht das erstellte Image in Amazon ECR.
1. Kopieren Sie die Zertifikatskette und den Zertifikatshauptteil von der CA und laden Sie das Zertifikatspaket auf Amazon S3 hoch.
1. Erstellen Sie einen Trust Store mit dem CA-Bundle, das Sie auf Amazon S3 hochgeladen haben. Ordnen Sie den Trust Store den gegenseitigen TLS-Listenern auf dem Application Load Balancer (ALB) zu.
1. Verwenden Sie die private CA, um Client-Zertifikate für die Container-Workloads auszustellen. Erstellen Sie auch ein privates TLS-Zertifikat mit AWS Private CA.
1. Importieren Sie das private TLS-Zertifikat in AWS Certificate Manager (ACM) und verwenden Sie es mit dem ALB.
1. Der Container-Workload in `ServiceTwo` verwendet das ausgestellte Client-Zertifikat, um sich bei der ALB zu authentifizieren, wenn er mit dem Container-Workload in kommuniziert. `ServiceOne`
1. Der Container-Workload in `ServiceOne` verwendet das ausgestellte Client-Zertifikat zur Authentifizierung bei der ALB, wenn er mit dem Container-Workload in kommuniziert. `ServiceTwo`
**Automatisierung und Skalierung**
Dieses Muster kann vollständig automatisiert werden CloudFormation, indem AWS Cloud Development Kit (AWS CDK) , oder API-Operationen aus einem SDK zur Bereitstellung der AWS Ressourcen verwendet werden.
Sie können AWS CodePipeline damit eine CI/CD-Pipeline (Continuous Integration and Continuous Deployment) implementieren, CodeBuild um den Prozess der Container-Image-Erstellung zu automatisieren und neue Versionen für die Amazon ECS-Cluster-Services bereitzustellen.
## Tools
**AWS-Services **
+ [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) unterstützt Sie bei der Erstellung, Speicherung und Erneuerung öffentlicher und privater SSL/TLS X.509-Zertifikate und -Schlüssel, die Ihre AWS Websites und Anwendungen schützen.
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)hilft Ihnen dabei, AWS Ressourcen einzurichten, sie schnell und konsistent bereitzustellen und sie während ihres gesamten AWS-Konten Lebenszyklus über und zu verwalten. AWS-Regionen
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)ist ein vollständig verwalteter Build-Service, der Ihnen hilft, Quellcode zu kompilieren, Komponententests durchzuführen und Artefakte zu erstellen, die sofort einsatzbereit sind.
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) ist ein verwalteter Container-Image-Registry-Service, der sicher, skalierbar und zuverlässig ist.
+ [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) ist ein hoch skalierbarer, schneller Container-Management-Service zum Ausführen, Stoppen und Verwalten von Containern in einem Cluster. Sie können Ihre Aufgaben und Dienste auf einer serverlosen Infrastruktur ausführen, die von AWS Fargate verwaltet wird. Für mehr Kontrolle über Ihre Infrastruktur können Sie Ihre Aufgaben und Dienste alternativ auf einem Cluster von Amazon Elastic Compute Cloud (Amazon EC2) -Instances ausführen, die Sie verwalten.
+ [Amazon ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) ermöglicht Ihnen die direkte Interaktion mit Containern, ohne zuerst mit dem Host-Container-Betriebssystem interagieren, eingehende Ports öffnen oder SSH-Schlüssel verwalten zu müssen. Sie können ECS Exec verwenden, um Befehle in einem Container auszuführen oder eine Shell für einen Container zu erhalten, der auf einer EC2 Amazon-Instance oder auf AWS Fargate einem läuft.
+ [Elastic Load Balancing (ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) verteilt eingehenden Anwendungs- oder Netzwerkverkehr auf mehrere Ziele. Sie können beispielsweise den Traffic auf EC2 Amazon-Instances, Container und IP-Adressen in einer oder mehreren Availability Zones verteilen. ELB überwacht den Zustand seiner registrierten Ziele und leitet den Datenverkehr nur an die fehlerfreien Ziele weiter. ELB skaliert Ihren Load Balancer, wenn sich Ihr eingehender Datenverkehr im Laufe der Zeit ändert. Es kann automatisch auf die meisten Workloads skaliert werden.
+ [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html)hilft Ihnen beim Betrieb von Containern, ohne Server oder EC2 Amazon-Instances verwalten zu müssen. Fargate ist sowohl mit Amazon ECS als auch mit Amazon Elastic Kubernetes Service (Amazon EKS) kompatibel. Sie können Ihre Amazon ECS-Aufgaben und -Services mit dem Starttyp Fargate oder einem Fargate-Kapazitätsanbieter ausführen. Verpacken Sie dazu Ihre Anwendung in Containern, geben Sie die CPU- und Speicheranforderungen an, definieren Sie Netzwerk- und IAM-Richtlinien und starten Sie die Anwendung. Jede Fargate-Aufgabe hat ihre eigene Isolationsgrenze und teilt den zugrunde liegenden Kernel, die CPU-Ressourcen, Speicherressourcen oder die elastic network interface nicht mit einer anderen Aufgabe.
+ [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)ermöglicht die Erstellung von privaten Zertifizierungsstellenhierarchien (CA), einschließlich Stamm- und untergeordneter Zertifizierungsstellen CAs, ohne dass die Investitions- und Wartungskosten für den Betrieb einer lokalen Zertifizierungsstelle anfallen.
**Andere Tools******
+ [Docker](https://www.docker.com/) ist eine Reihe von Platform-as-a-Service (PaaS) -Produkten, die Virtualisierung auf Betriebssystemebene nutzen, um Software in Containern bereitzustellen.
+ [GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories), [GitLab](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html), und [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-bitbucket-with-git/) sind einige der am häufigsten verwendeten Git-basierten Quellcodeverwaltungssysteme, um Quellcodeänderungen zu verfolgen.
+ [NGINX Open Source](https://nginx.org/en/docs/?_ga=2.187509224.1322712425.1699399865-405102969.1699399865) ist ein Open-Source-Loadbalancer, ein Inhalts-Cache und ein Webserver. Dieses Muster verwendet es als Webserver.
+ [OpenSSL](https://www.openssl.org/) ist eine Open-Source-Bibliothek, die Dienste bereitstellt, die von den OpenSSL-Implementierungen von TLS und CMS verwendet werden.
**Code-Repository**
Der Code für dieses Muster ist im Repository GitHub [MTLS-with-Application-Load-Balancer-In-Amazon-ECS](https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS) verfügbar.
## Best Practices
+ Verwenden Sie Amazon ECS Exec, um Befehle auszuführen oder eine Shell für einen Container abzurufen, der auf Fargate läuft. Sie können ECS Exec auch verwenden, um Diagnoseinformationen für das Debuggen zu sammeln.
+ Verwenden Sie Sicherheitsgruppen und Netzwerkzugriffskontrolllisten (ACLs), um den eingehenden und ausgehenden Verkehr zwischen den Diensten zu kontrollieren. Fargate-Aufgaben erhalten eine IP-Adresse aus dem konfigurierten Subnetz in Ihrer Virtual Private Cloud (VPC).
## Epen
### Erstellen Sie das Repository
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Laden Sie den Quellcode herunter. | Um den Quellcode dieses Patterns herunterzuladen, forken oder klonen Sie das GitHub [MTLS-with-Application-Load-Balancer-In-Amazon-ECS-Repository](https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS). | DevOps Ingenieur |
| Erstellen Sie ein Git-Repository. | Gehen Sie wie folgt vor, um ein Git-Repository zu erstellen, das das Dockerfile und die `buildspec.yaml` Dateien enthält:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)`git clone https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS.git` | DevOps Ingenieur |
### CA erstellen und Zertifikate generieren
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie eine private CA in AWS Private CA. | Um eine private Zertifizierungsstelle (CA) zu erstellen, führen Sie die folgenden Befehle in Ihrem Terminal aus. Ersetzen Sie die Werte in den Beispielvariablen durch Ihre eigenen Werte. export AWS_DEFAULT_REGION="us-west-2"
export SERVICES_DOMAIN="www.example.com"
export ROOT_CA_ARN=`aws acm-pca create-certificate-authority \
--certificate-authority-type ROOT \
--certificate-authority-configuration \
"KeyAlgorithm=RSA_2048,
SigningAlgorithm=SHA256WITHRSA,
Subject={
Country=US,
State=WA,
Locality=Seattle,
Organization=Build on AWS,
OrganizationalUnit=mTLS Amazon ECS and ALB Example,
CommonName=${SERVICES_DOMAIN}}" \
--query CertificateAuthorityArn --output text`
Weitere Informationen finden Sie [AWS Private CA in der AWS Dokumentation unter Eine private Zertifizierungsstelle erstellen](https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html). | DevOps Ingenieur, AWS DevOps |
| Erstellen und installieren Sie Ihr privates CA-Zertifikat. | Um ein Zertifikat für Ihre private Root-CA zu erstellen und zu installieren, führen Sie die folgenden Befehle in Ihrem Terminal aus:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html) | AWS DevOps, DevOps Ingenieur |
| Fordern Sie ein verwaltetes Zertifikat an. | Verwenden Sie den folgenden Befehl AWS Certificate Manager , um ein privates Zertifikat zur Verwendung mit Ihrem privaten ALB anzufordern:export TLS_CERTIFICATE_ARN=`aws acm request-certificate \
--domain-name "*.${DOMAIN_DOMAIN}" \
--certificate-authority-arn ${ROOT_CA_ARN} \
--query CertificateArn --output text`
| DevOps Ingenieur, AWS DevOps |
| Verwenden Sie die private CA, um ein Client-Zertifikat auszustellen. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)`openssl req -out client_csr1.pem -new -newkey rsa:2048 -nodes -keyout client_private-key1.pem``openssl req -out client_csr2.pem -new -newkey rsa:2048 -nodes -keyout client_private-key2.pem`Dieser Befehl gibt die CSR und den privaten Schlüssel für die beiden Dienste zurück. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)SERVICE_ONE_CERT_ARN=`aws acm-pca issue-certificate \
--certificate-authority-arn ${ROOT_CA_ARN} \
--csr fileb://client_csr1.pem \
--signing-algorithm "SHA256WITHRSA" \
--validity Value=5,Type="YEARS" --query CertificateArn --output text`
echo "SERVICE_ONE_CERT_ARN: ${SERVICE_ONE_CERT_ARN}"
aws acm-pca get-certificate \
--certificate-authority-arn ${ROOT_CA_ARN} \
--certificate-arn ${SERVICE_ONE_CERT_ARN} \
| jq -r '.Certificate' > client_cert1.cert
SERVICE_TWO_CERT_ARN=`aws acm-pca issue-certificate \
--certificate-authority-arn ${ROOT_CA_ARN} \
--csr fileb://client_csr2.pem \
--signing-algorithm "SHA256WITHRSA" \
--validity Value=5,Type="YEARS" --query CertificateArn --output text`
echo "SERVICE_TWO_CERT_ARN: ${SERVICE_TWO_CERT_ARN}"
aws acm-pca get-certificate \
--certificate-authority-arn ${ROOT_CA_ARN} \
--certificate-arn ${SERVICE_TWO_CERT_ARN} \
| jq -r '.Certificate' > client_cert2.cert
Weitere Informationen finden Sie in der AWS Dokumentation unter [Ausstellen von privaten Endentitätszertifikaten](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html). | DevOps Ingenieur, AWS DevOps |
### Bereitstellung von AWS-Services
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Bereitstellung AWS-Services mit der CloudFormation Vorlage. | Verwenden Sie die Vorlage, um die Virtual Private Cloud (VPC), den Amazon ECS-Cluster, die Amazon ECS-Services, den Application Load Balancer und das Amazon Elastic Container Registry (Amazon ECR) bereitzustellen. CloudFormation | DevOps Ingenieur |
| Variablen abrufen. | Stellen Sie sicher, dass Sie über einen Amazon ECS-Cluster verfügen, auf dem zwei Dienste ausgeführt werden. Verwenden Sie die folgenden Befehle, um die Ressourcendetails abzurufen und als Variablen zu speichern:
export LoadBalancerDNS=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`LoadBalancerDNS`].OutputValue')
export ECRRepositoryUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryUri`].OutputValue')
export ECRRepositoryServiceOneUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryServiceOneUri`].OutputValue')
export ECRRepositoryServiceTwoUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryServiceTwoUri`].OutputValue')
export ClusterName=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`ClusterName`].OutputValue')
export BucketName=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`BucketName`].OutputValue')
export Service1ListenerArn=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`Service1ListenerArn`].OutputValue')
export Service2ListenerArn=$(aws cloudformation describe-stacks --stack-name ecs-mtls \
--output text \
--query 'Stacks[0].Outputs[?OutputKey==`Service2ListenerArn`].OutputValue')
| DevOps Ingenieur |
| Erstellen Sie ein CodeBuild Projekt. | Gehen Sie wie folgt vor, um ein CodeBuild Projekt zur Erstellung der Docker-Images für Ihre Amazon ECS-Services zu verwenden:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)Weitere Informationen finden Sie [AWS CodeBuild in der AWS Dokumentation unter Erstellen eines Build-Projekts](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project.html). | AWS DevOps, DevOps Ingenieur |
| Erstellen Sie die Docker-Images. | Sie können es verwenden CodeBuild , um den Image-Erstellungsprozess durchzuführen. CodeBuild benötigt Berechtigungen, um mit Amazon ECR zu interagieren und mit Amazon S3 zu arbeiten.Im Rahmen des Prozesses wird das Docker-Image erstellt und in die Amazon ECR-Registrierung übertragen. Einzelheiten zur Vorlage und zum Code finden Sie unter [Zusätzliche](#simplify-application-authentication-with-mutual-tls-in-amazon-ecs-additional) Informationen.(Optional) Verwenden Sie den folgenden Befehl, um lokal zu Testzwecken zu erstellen:# login to ECR
aws ecr get-login-password | docker login --username AWS --password-stdin $ECRRepositoryUri
# build image for service one
cd /service1
aws s3 cp s3://$BucketName/serviceone/ service1/ --recursive
docker build -t $ECRRepositoryServiceOneUri .
docker push $ECRRepositoryServiceOneUri
# build image for service two
cd ../service2
aws s3 cp s3://$BucketName/servicetwo/ service2/ --recursive
docker build -t $ECRRepositoryServiceTwoUri .
docker push $ECRRepositoryServiceTwoUri
| DevOps Ingenieur |
### Mutual TLS aktivieren
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Laden Sie das CA-Zertifikat auf Amazon S3 hoch. | Verwenden Sie den folgenden Beispielbefehl, um das CA-Zertifikat in den Amazon S3 S3-Bucket hochzuladen:`aws s3 cp ca-cert.pem s3://$BucketName/acm-trust-store/ ` | AWS DevOps, DevOps Ingenieur |
| Erstellen Sie den Trust Store. | Verwenden Sie den folgenden Beispielbefehl, um den Trust Store zu erstellen:TrustStoreArn=`aws elbv2 create-trust-store --name acm-pca-trust-certs \
--ca-certificates-bundle-s3-bucket $BucketName \
--ca-certificates-bundle-s3-key acm-trust-store/ca-cert.pem --query 'TrustStores[].TrustStoreArn' --output text`
| AWS DevOps, DevOps Ingenieur |
| Laden Sie Kundenzertifikate hoch. | Verwenden Sie den folgenden Beispielbefehl, um Client-Zertifikate für Docker-Images auf Amazon S3 hochzuladen:# for service one
aws s3 cp client_cert1.cert s3://$BucketName/serviceone/
aws s3 cp client_private-key1.pem s3://$BucketName/serviceone/
# for service two
aws s3 cp client_cert2.cert s3://$BucketName/servicetwo/
aws s3 cp client_private-key2.pem s3://$BucketName/servicetwo/
| AWS DevOps, DevOps Ingenieur |
| Ändern Sie den Listener. | Um Mutual TLS auf dem ALB zu aktivieren, ändern Sie die HTTPS-Listener mit den folgenden Befehlen:aws elbv2 modify-listener \
--listener-arn $Service1ListenerArn \
--certificates CertificateArn=$TLS_CERTIFICATE_ARN_TWO \
--ssl-policy ELBSecurityPolicy-2016-08 \
--protocol HTTPS \
--port 8080 \
--mutual-authentication Mode=verify,TrustStoreArn=$TrustStoreArn,IgnoreClientCertificateExpiry=false
aws elbv2 modify-listener \
--listener-arn $Service2ListenerArn \
--certificates CertificateArn=$TLS_CERTIFICATE_ARN_TWO \
--ssl-policy ELBSecurityPolicy-2016-08 \
--protocol HTTPS \
--port 8090 \
--mutual-authentication Mode=verify,TrustStoreArn=$TrustStoreArn,IgnoreClientCertificateExpiry=false
Weitere Informationen finden Sie in der AWS Dokumentation unter [Konfiguration von gegenseitigem TLS auf einem Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/configuring-mtls-with-elb.html). | AWS DevOps, DevOps Ingenieur |
### Aktualisieren Sie die Dienste
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Aktualisieren Sie die Amazon ECS-Aufgabendefinition. | Um die Amazon ECS-Aufgabendefinition zu aktualisieren, ändern Sie den `image` Parameter in der neuen Version.Um die Werte für die jeweiligen Services abzurufen, aktualisieren Sie die Aufgabendefinitionen mit dem neuen Docker-Images-URI, den Sie in den vorherigen Schritten erstellt haben: oder `echo $ECRRepositoryServiceOneUri` `echo $ECRRepositoryServiceTwoUri`
"containerDefinitions": [
{
"name": "nginx",
"image": "public.ecr.aws/nginx/nginx:latest", # <----- change to new Uri
"cpu": 0,
Weitere Informationen finden Sie in der AWS Dokumentation unter [Aktualisieren einer Amazon ECS-Aufgabendefinition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) mithilfe der Konsole. | AWS DevOps, DevOps Ingenieur |
| Aktualisieren Sie den Amazon ECS-Service. | Aktualisieren Sie den Service mit der neuesten Aufgabendefinition. Diese Aufgabendefinition ist der Entwurf für die neu erstellten Docker-Images und enthält das Client-Zertifikat, das für die gegenseitige TLS-Authentifizierung erforderlich ist. Gehen Sie wie folgt vor, um den Dienst zu aktualisieren:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)Wiederholen Sie die Schritte für den anderen Dienst. | AWS-Administrator, AWS DevOps, DevOps Ingenieur |
### Greifen Sie auf die Anwendung zu
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Kopieren Sie die Anwendungs-URL. | Verwenden Sie die Amazon ECS-Konsole, um die Aufgabe anzusehen. Wenn der Aufgabenstatus auf Wird **ausgeführt** aktualisiert wurde, wählen Sie die Aufgabe aus. Kopieren Sie im Abschnitt **Aufgabe** die Aufgaben-ID. | AWS-Administrator, AWS DevOps |
| Testen Sie Ihre Anwendung. | Um Ihre Anwendung zu testen, verwenden Sie ECS Exec, um auf die Aufgaben zuzugreifen.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html) | AWS-Administrator, AWS DevOps |
## Zugehörige Ressourcen
**Amazon ECS-Dokumentation**
+ [Erstellen einer Amazon ECS-Aufgabendefinition mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)
+ [Erstellen eines Container-Images zur Verwendung auf Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html)
+ [Amazon-ECS-Cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
+ [Amazon ECS für AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html#create-container-image-next-steps)
+ [Bewährte Methoden für Amazon-ECS-Netzwerke](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/networking-best-practices.html)
+ [Parameter der Amazon ECS-Servicedefinition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)
**Andere AWS Ressourcen**
+ [Wie verwende ich AWS private CA, um mTLS auf dem Application Load Balancer zu konfigurieren?](https://repost.aws/knowledge-center/elb-alb-configure-private-ca-mtls) ()AWS re:Post
## Zusätzliche Informationen
**Das Dockerfile bearbeiten******
Der folgende Code zeigt die Befehle, die Sie im Dockerfile für Service 1 bearbeiten:
```
FROM public.ecr.aws/nginx/nginx:latest
WORKDIR /usr/share/nginx/html
RUN echo "Returning response from Service 1: Ok" > /usr/share/nginx/html/index.html
ADD client_cert1.cert client_private-key1.pem /usr/local/share/ca-certificates/
RUN chmod -R 400 /usr/local/share/ca-certificates/
```
Der folgende Code zeigt die Befehle, die Sie im Dockerfile für Dienst 2 bearbeiten:
```
FROM public.ecr.aws/nginx/nginx:latest
WORKDIR /usr/share/nginx/html
RUN echo "Returning response from Service 2: Ok" > /usr/share/nginx/html/index.html
ADD client_cert2.cert client_private-key2.pem /usr/local/share/ca-certificates/
RUN chmod -R 400 /usr/local/share/ca-certificates/
```
Wenn Sie die Docker-Images mit erstellen, verwendet die `buildspec` Datei die CodeBuild Build-Nummer CodeBuild, um Image-Versionen eindeutig als Tag-Wert zu identifizieren. Sie können die `buildspec` Datei an Ihre Anforderungen anpassen, wie im folgenden `buildspec ` benutzerdefinierten Code gezeigt:
```
version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REPOSITORY_URI
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=${COMMIT_HASH:=latest}
build:
commands:
# change the S3 path depending on the service
- aws s3 cp s3://$YOUR_S3_BUCKET_NAME/serviceone/ $CodeBuild_SRC_DIR/ --recursive
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $ECR_REPOSITORY_URI:latest .
- docker tag $ECR_REPOSITORY_URI:latest $ECR_REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $ECR_REPOSITORY_URI:latest
- docker push $ECR_REPOSITORY_URI:$IMAGE_TAG
- echo Writing image definitions file...
# for ECS deployment reference
- printf '[{"name":"%s","imageUri":"%s"}]' $CONTAINER_NAME $ECR_REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json
artifacts:
files:
- imagedefinitions.json
```
# Mehr Muster
**Topics**
+ [Automatisieren Sie das Löschen von AWS CloudFormation Stacks und zugehörigen Ressourcen](automate-deletion-cloudformation-stacks-associated-resources.md)
+ [Automatisieren Sie das dynamische Pipeline-Management für die Bereitstellung von Hotfix-Lösungen in Gitflow-Umgebungen mithilfe von und AWS Service Catalog AWS CodePipeline](automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.md)
+ [Automatisches Erstellen von CI/CD Pipelines und Amazon ECS-Clustern für Microservices mithilfe von AWS CDK](automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.md)
+ [Erstellen und übertragen Sie Docker-Images mithilfe von GitHub Actions und Terraform auf Amazon ECR](build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.md)
+ [Containerisieren Sie Mainframe-Workloads, die von Blu Age modernisiert wurden](containerize-mainframe-workloads-that-have-been-modernized-by-blu-age.md)
+ [Erstellen Sie einen benutzerdefinierten Protokollparser für Amazon ECS mithilfe eines Firelens-Protokollrouters](create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.md)
+ [Stellen Sie mithilfe von Terraform Agentensysteme auf Amazon Bedrock mit dem CrewAI-Framework bereit](deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.md)
+ [Stellen Sie mithilfe von Terraform eine Umgebung für containerisierte Blu Age-Anwendungen bereit](deploy-an-environment-for-containerized-blu-age-applications-by-using-terraform.md)
+ [Stellen Sie mithilfe einer Inferenz-Pipeline in Amazon Vorverarbeitungslogik in einem ML-Modell an einem einzigen Endpunkt bereit SageMaker](deploy-preprocessing-logic-into-an-ml-model-in-a-single-endpoint-using-an-inference-pipeline-in-amazon-sagemaker.md)
+ [Stellen Sie Workloads aus DevOps Azure-Pipelines auf private Amazon EKS-Cluster bereit](deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.md)
+ [Implementieren Sie KI-gestützte Kubernetes-Diagnose und -Fehlerbehebung mit der Integration von K8SGPT und Amazon Bedrock](implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.md)
+ [Verwalten Sie blue/green Bereitstellungen von Microservices für mehrere Konten und Regionen mithilfe von AWS-Code-Services und AWS KMS-Schlüsseln für mehrere Regionen](manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.md)
+ [Verwalten Sie lokale Containeranwendungen, indem Sie Amazon ECS Anywhere mit dem AWS CDK einrichten](manage-on-premises-container-applications-by-setting-up-amazon-ecs-anywhere-with-the-aws-cdk.md)
+ [Migrieren Sie von Oracle WebLogic zu Apache Tomcat (ToMEE) auf Amazon ECS](migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs.md)
+ [Modernisieren Sie ASP.NET Web Forms-Anwendungen auf AWS](modernize-asp-net-web-forms-applications-on-aws.md)
+ [Überwachen Sie Amazon ECR-Repositorys mit AWS und AWS CloudFormation Config auf Platzhalterberechtigungen](monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.md)
+ [Überwachen Sie die Anwendungsaktivität mithilfe von CloudWatch Logs Insights](monitor-application-activity-by-using-cloudwatch-logs-insights.md)
+ [Richten Sie mithilfe von AWS CDK eine CI/CD Pipeline für Hybrid-Workloads auf Amazon ECS Anywhere ein und GitLab](set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.md)
+ [Richten Sie die end-to-end Verschlüsselung für Anwendungen auf Amazon EKS mithilfe von cert-manager und Let's Encrypt ein](set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.md)
+ [Vereinfachen Sie die Bereitstellung von Amazon EKS-Anwendungen für mehrere Mandanten mithilfe von Flux](simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.md)
+ [Optimieren Sie mithilfe von SageMaker KI und Hydra Workflows für maschinelles Lernen — von der lokalen Entwicklung bis hin zu skalierbaren Experimenten](streamline-machine-learning-workflows-by-using-amazon-sagemaker.md)
+ [Strukturieren Sie ein Python-Projekt in hexagonaler Architektur mit AWS Lambda](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md)
+ [Testen Sie die AWS Infrastruktur mithilfe LocalStack von Terraform-Tests](test-aws-infra-localstack-terraform.md)
+ [Koordinieren Sie die Ressourcenabhängigkeit und die Aufgabenausführung mithilfe des AWS Fargate WaitCondition Hook-Konstrukts](use-the-aws-fargate-waitcondition-hook-construct.md)
+ [Verwenden Sie Amazon Bedrock-Agenten, um die Erstellung von Zugriffskontrollen in Amazon EKS durch textbasierte Eingabeaufforderungen zu automatisieren](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md)