Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Ausführen eines Stacks in einer VPC
Wichtig
Der AWS OpsWorks Stacks Service hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf AWS re:POST
Sie können den Benutzerzugriff auf die Instances eines Stacks mithilfe einer Virtual Private Cloud (VPC) steuern. Möglicherweise möchten Sie nicht, dass Benutzer direkt auf die Anwendungsserver oder Datenbanken Ihres Stacks zugreifen können, und möchten stattdessen sämtlichen öffentlichen Datenverkehr über einen Elastic Load Balancer leiten.
Gehen Sie wie folgt vor, um einen Stack in einer VPC auszuführen:
-
Erstellen Sie mithilfe der Amazon VPC-Konsole, API oder einer Vorlage eine AWS CloudFormation entsprechend konfigurierte VPC.
-
Geben Sie beim Erstellen des Stacks die VPC-ID an.
-
Starten Sie Stack-Instances im entsprechenden Subnetz.
Nachfolgend wird kurz erläutert, wie VPCs in AWS OpsWorks Stacks funktionieren.
Wichtig
Wenn Sie die VPC-Endpunktfunktion verwenden, beachten Sie, dass jede Instance im Stack in der Lage sein muss, die folgenden Aktionen von Amazon Simple Storage Service (Amazon S3) aus durchzuführen:
-
Installieren des Instance-Agenten
-
Installieren von Ressourcen wie Ruby
-
Hochladen von Chef-Protokollen
-
Abrufen von Stack-Befehlen
Um diese Aktionen zu aktivieren, müssen die Stack-Instances Zugriff auf die folgenden Buckets in der Region des Stacks haben. Andernfalls schlagen die zuvor genannten Aktionen fehl.
Für Chef 12 Linux und Chef 12.2 Windows lauten die Buckets wie folgt.
| Agent-Buckets | Ressourcen-Buckets | Protokoll-Buckets | DNA-Buckets |
|---|---|---|---|
|
|
|
|
Für Chef 11.10 und frühere Versionen für Linux sind dies folgende Buckets. Chef 11.4-Stacks werden auf regionalen Endpunkten außerhalb der Region USA Ost (Nord-Virginia) nicht unterstützt.
| Agent-Buckets | Ressourcen-Buckets | Protokoll-Buckets | DNA-Buckets |
|---|---|---|---|
|
|
|
|
Weitere Informationen finden Sie unter VPC Endpoints.
Anmerkung
Damit AWS OpsWorks Stacks eine Verbindung zu den VPC-Endpunkten herstellen kann, die Sie aktivieren, müssen Sie auch das Routing für Ihr NAT oder Ihre öffentliche IP konfigurieren, da der AWS OpsWorks Stacks-Agent weiterhin Zugriff auf den öffentlichen Endpunkt benötigt.
VPC-Grundlagen
Detaillierte Informationen zu VPCs finden Sie unter Amazon Virtual Private Cloud. Kurz zusammengefasst besteht eine VPC aus mindestens einem Subnetz mit je mindestens einer Instance. Jedes Subnetz ist einer Routing-Tabelle zugeordnet, über die ausgehender Datenverkehr anhand der Ziel-IP-Adresse weitergeleitet wird.
-
Instances innerhalb der VPC können unabhängig vom jeweiligen Subnetz standardmäßig miteinander kommunizieren. Änderungen an Netzwerk-Zugriffskontrolllisten (ACLs), Sicherheitsgruppenrichtlinien oder die Verwendung statischer IP-Adressen können diese Kommunikation jedoch unterbrechen.
-
Subnetze, deren Instances auf das Internet zugreifen können, sind öffentliche Subnetze.
-
Subnetze, die mit anderen Instances in der VPC kommunizieren können, jedoch keinen Internetzugriff haben, werden als private Subnetze bezeichnet.
AWS OpsWorks Stacks erfordert, dass die VPC so konfiguriert ist, dass jede Instanz im Stack, einschließlich Instances in privaten Subnetzen, Zugriff auf die folgenden Endpunkte hat:
-
Einer der AWS OpsWorks Stacks-Dienstendpunkte, die im Abschnitt „Regionssupport“ von aufgeführt sind. Erste Schritte mit AWS OpsWorks Stacks
-
Einer der folgenden Instanzdienst-Endpunkte, der vom Stacks-Agenten verwendet wird. AWS OpsWorks Der Agent führt auf verwalteten Kunden-Instances ausgeführt, um Daten mit dem Service auszutauschen.
-
opsworks-instance-service.us-east-2.amazonaws.com
-
opsworks-instance-service.us-east-1.amazonaws.com
-
opsworks-instance-service.us-west-1.amazonaws.com
-
opsworks-instance-service.us-west-2.amazonaws.com
-
opsworks-instance-service.ap-south-1.amazonaws.com
-
opsworks-instance-service.ap-northeast-1.amazonaws.com
-
opsworks-instance-service.ap-northeast-2.amazonaws.com
-
opsworks-instance-service.ap-southeast-1.amazonaws.com
-
opsworks-instance-service.ap-southeast-2.amazonaws.com
-
opsworks-instance-service.ca-central-1.amazonaws.com
-
opsworks-instance-service.eu-central-1.amazonaws.com
-
opsworks-instance-service.eu-west-1.amazonaws.com
-
opsworks-instance-service.eu-west-2.amazonaws.com
-
opsworks-instance-service.eu-west-3.amazonaws.com
-
-
Amazon S3
-
Alle Paket-Repositorys, die von Ihrem Betriebssystem verwendet werden, wie beispielsweise Amazon Linux- oder Ubuntu Linux-Repositorys
-
Die Repositorys Ihrer App und Ihres benutzerdefinierten Rezeptbuchs
Sie können eine VPC auf unterschiedliche Weise konfigurieren, um diese Vernetzung zu schaffen. Im Folgenden finden Sie ein einfaches Beispiel dafür, wie Sie eine VPC für einen AWS OpsWorks Stacks-App-Server-Stack konfigurieren können.
Diese VPC hat mehrere Komponenten:
- Subnets
-
Die VPC hat zwei Subnetze, ein öffentliches und ein privates.
-
Das öffentliche Subnetz enthält einen Load Balancer und ein NAT-Gerät, das mit externen Adressen sowie mit Instances im privaten Subnetz kommunizieren kann.
-
Das private Subnetz enthält die Anwendungsserver, die mit dem NAT und dem Load Balancer im öffentlichen Subnetz, nicht jedoch direkt mit externen Adressen kommunizieren können.
-
- Internet-Gateway
-
Über den Internet-Gateway können Instances mit öffentlichen IP-Adressen wie der Load Balancer mit Adressen außerhalb der VPC kommunizieren.
- Load Balancer
-
Der Elastic Load Balancer verteilt eingehenden Datenverkehr von Benutzern auf die Anwendungsserver im privaten Subnetz und gibt die Antworten an die Benutzer zurück.
- NAT
-
Über das NAT-Gerät haben die Anwendungsserver begrenzten Zugriff auf das Internet. Dieser dient üblicherweise dazu, Softwareaktualisierungen von externen Repositorys herunterzuladen. Alle AWS OpsWorks Stacks-Instanzen müssen in der Lage sein, mit AWS OpsWorks Stacks und den entsprechenden Linux-Repositorys zu kommunizieren. Eine Möglichkeit, dies zu gewährleisten, besteht darin, ein NAT-Gerät mit einer entsprechenden Elastic IP-Adresse in einem öffentlichen Subnetz zu platzieren. Von dort aus können Sie ausgehenden Datenverkehr über das NAT von Instances an das private Subnetz weiterleiten.
Anmerkung
Eine einzelne NAT-Instance ist für den ausgehenden Datenverkehr Ihres privaten Subnetzes sehr fehleranfällig. Sie können die Zuverlässigkeit erhöhen, indem Sie zwei NAT-instances konfigurieren und so die Ausfallsicherheit erhöhen. Weitere Informationen finden Sie unter Hohe Verfügbarkeit für Amazon VPC NAT-Instances
. Sie können auch einen NAT-Gateway verwenden. Weitere Informationen finden Sie unter NAT im Amazon VPC-Benutzerhandbuch.
Die optimale VPC-Konfiguration hängt von Ihrem AWS OpsWorks Stacks-Stack ab. In den nachfolgenden Beispielen sehen Sie, wann welche VPC-Konfiguration geeignet ist. Beispiele für weitere VPC-Szenarios finden Sie unter Szenarios für die Verwendung von Amazon VPC.
- Working with one instance in a public subnet (Arbeiten mit einer Instance in einem öffentlichen Subnetz)
-
Wenn Sie über einen Einzelinstanz-Stack ohne zugehörige private Ressourcen verfügen — z. B. eine Amazon RDS-Instance, die nicht öffentlich zugänglich sein sollte —, können Sie eine VPC mit einem öffentlichen Subnetz erstellen und die Instance in dieses Subnetz stellen. Wenn Sie keine Standard-VPC verwenden, müssen Sie den Layer der Instance anweisen, der Instance eine Elastic IP-Adresse zuzuweisen. Weitere Informationen finden Sie unter OpsWorks Grundlagen der Ebene.
- Working with private resources (Arbeiten mit privaten Ressourcen)
-
Wenn Sie über Ressourcen verfügen, die nicht öffentlich zugreifbar sein sollen, können Sie eine VPC mit einem öffentlichen und einem privaten Subnetz erstellen. In einer automatischen Skalierungsumgebung mit Lastenausgleich können Sie beispielsweise alle Amazon EC2 EC2-Instances im privaten Subnetz und den Load Balancer in einem öffentlichen Subnetz platzieren. Auf diese Weise kann nicht direkt über das Internet auf die Amazon EC2 EC2-Instances zugegriffen werden. Der gesamte eingehende Datenverkehr muss über den Load Balancer geleitet werden.
Das private Subnetz isoliert die Instances vom direkten Benutzerzugriff von Amazon EC2, sie müssen jedoch weiterhin ausgehende Anfragen an AWS und die entsprechenden Linux-Paket-Repositorys senden. Um solche Anfragen zu ermöglichen, können Sie beispielsweise ein NAT-Gerät mit eigener Elastic IP-Adresse verwenden und den ausgehenden Datenverkehr der Instances über das NAT leiten. Sie können das NAT im selben öffentlichen Subnetz wie den Load Balancer platzieren (siehe vorheriges Beispiel).
-
Wenn Sie eine Back-End-Datenbank wie eine Amazon RDS-Instance verwenden, können Sie diese Instances im privaten Subnetz platzieren. Für Amazon RDS-Instances müssen Sie mindestens zwei verschiedene Subnetze in verschiedenen Availability Zones angeben.
-
Wenn Sie direkten Zugriff auf Instances in einem privaten Subnetz benötigen — Sie möchten beispielsweise SSH verwenden, um sich bei einer Instance anzumelden —, können Sie einen Bastion-Host in das öffentliche Subnetz stellen, der Anfragen aus dem Internet weiterleitet.
-
- Extending your own network into AWS (Erweitern Ihres eigenen Netzwerks in AWS)
-
Wenn Sie Ihr eigenes Netzwerk auf die Cloud ausweiten und aus der VPC direkt auf das Internet zugreifen möchten, können Sie einen VPN-Gateway erstellen. Weitere Informationen finden Sie unter Szenario 3: VPC mit öffentlichen und privaten Subnetzen sowie Hardware-VPN-Zugriff.
Eine VPC für einen AWS OpsWorks Stacks-Stack erstellen
In diesem Abschnitt wird anhand einer CloudFormationAWS-Beispielvorlage gezeigt, wie Sie eine VPC für einen AWS OpsWorks Stacks-Stack erstellen. Sie können die Vorlage in der OpsWorksDatei VPCtemplates.zip herunterladen. Weitere Informationen zum manuellen Erstellen einer VPC, wie sie in diesem Thema erläutert wurde, finden Sie unter Szenario 2: VPC mit öffentlichen und privaten Subnetzen. Weitere Informationen zur Konfiguration von Routing-Tabellen, Sicherheitsgruppen usw. finden Sie in der Beispielvorlage.
Anmerkung
Standardmäßig zeigt AWS OpsWorks Stacks Subnetznamen an, indem deren CIDR-Bereich und Availability Zone miteinander verknüpft werden, z. B. 10.0.0.1/24 - us-east-1b Um die Namen besser lesbar zu machen, erstellen Sie für jedes Subnetz ein Tag, wobei Key auf Name und Value auf den Subnetznamen eingestellt ist. AWS OpsWorks Stacks fügt dann den Subnetznamen an den Standardnamen an. Das private Subnetz im folgenden Beispiel hat beispielsweise ein Tag mit der Einstellung Name aufPrivate, das als angezeigt wird. OpsWorks 10.0.0.1/24
us-east - 1b - Private
Sie können eine VPC-Vorlage mit nur wenigen Schritten über die AWS CloudFormation Konsole starten. Das folgende Verfahren verwendet die Beispielvorlage, um eine VPC in der Region USA Ost (Nord-Virginia) zu erstellen. Eine Anleitung dazu, wie Sie anhand der Vorlage eine VPC in anderen Regionen erstellen, finden Sie im Hinweis am Ende des Verfahrens.
So erstellen Sie die VPC
-
Öffnen Sie die AWS CloudFormation -Konsole
, wählen Sie die Region US East (N. Virginia) (USA Ost (Nord-Virginia)) und anschließend Create Stack (Stack erstellen) aus. -
Wählen Sie auf der Seite Select Template (Vorlage auswählen) Upload a template (Eine Vorlage hochladen) aus. Suchen Sie in der
OpsWorksinVPC.templateDatei OpsWorksVPCtemplates.zip nach der Datei, die Sie heruntergeladen haben. Wählen Sie Weiter.
Sie können diesen Stack auch starten, indem Sie CloudFormation AWS-Beispielvorlagen
öffnen, die VPC-Vorlage AWS OpsWorks Stacks suchen und Stack starten auswählen. -
Akzeptieren Sie auf der Seite Specify Parameters (Parameter angeben) die Standardwerte und Continue (Weiter) aus.
-
Erstellen Sie auf der Seite Add Tags (Tags hinzufügen) ein Tag, legen Sie Key (Schlüssel) auf
Nameund Value (Wert) auf den VPC-Namen fest. Mit diesem Tag können Sie Ihre VPC leichter identifizieren, wenn Sie einen AWS OpsWorks Stacks-Stack erstellen. -
Wählen Sie Continue (Weiter) und dann Close (Schließen) aus, um den Stack zu starten.
Hinweis: Sie können die VPC mithilfe eines der folgenden Ansätze in anderen Regionen erstellen.
-
Gehen Sie zu Vorlagen in verschiedenen Regionen verwenden
, wählen Sie die entsprechende Region aus, suchen Sie die VPC-Vorlage AWS OpsWorks Stacks und wählen Sie dann Stack starten aus. -
Kopieren Sie die Vorlagendatei zu Ihrem System und wählen Sie in der AWS CloudFormation -Konsole
die entsprechende Region aus. Verwenden Sie im Assistenten Create Stack (Stack erstellen) die Option Upload a template to Amazon S3 (Vorlage zu Amazon S3 hochladen), um die Vorlage aus Ihrem System hochzuladen.
Die Beispielvorlage enthält Ausgaben, die die VPC-, Subnetz- und Load Balancer-IDs bereitstellen, die Sie zum Erstellen des AWS OpsWorks Stacks-Stacks benötigen. Sie können sie sehen, indem Sie unten im Konsolenfenster auf die Registerkarte Ausgaben klicken. AWS CloudFormation
