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.
Einen Stack in einem ausführen VPC
Wichtig
Der AWS OpsWorks Stacks Dienst 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 Instanzen eines Stacks steuern, indem Sie ihn in einer virtuellen privaten Cloud erstellen ()VPC. 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.
Das grundlegende Verfahren zum Ausführen eines Stacks in einem VPC ist:
-
Erstellen Sie mithilfe der VPC Amazon-Konsole oder API eine entsprechend konfigurierte VPC AWS CloudFormation Vorlage.
-
Geben Sie die VPC ID an, wenn Sie den Stack erstellen.
-
Starten Sie Stack-Instances im entsprechenden Subnetz.
Im Folgenden wird kurz beschrieben, wie Sie in AWS OpsWorks Stacks VPCs arbeiten.
Wichtig
Wenn Sie die VPC Endpoint-Funktion 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-Endpunkte.
Anmerkung
Damit AWS OpsWorks Stacks eine Verbindung zu den von Ihnen VPC aktivierten Endpunkten herstellen kann, müssen Sie auch das Routing für Ihre NAT oder öffentliche IP konfigurieren, da der AWS OpsWorks Stacks-Agent weiterhin Zugriff auf den öffentlichen Endpunkt benötigt.
VPC – Grundlagen
Eine ausführliche Beschreibung von VPCs finden Sie unter Amazon Virtual Private Cloud. Kurz gesagt VPC besteht a aus einem oder mehreren Subnetzen, von denen jedes eine oder mehrere Instances enthält. Jedes Subnetz ist einer Routing-Tabelle zugeordnet, über die ausgehender Datenverkehr anhand der Ziel-IP-Adresse weitergeleitet wird.
-
Instanzen innerhalb eines VPC können standardmäßig miteinander kommunizieren, unabhängig von ihrem Subnetz. Änderungen an Netzwerkzugriffskontrolllisten (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, deren Instanzen nur mit anderen Instances im Internet kommunizieren können VPC und nicht direkt mit dem Internet kommunizieren können, werden als private Subnetze bezeichnet.
AWS OpsWorks Stacks erfordertVPC, dass sie so konfiguriert werden, dass jede Instanz im Stack, einschließlich Instanzen 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
Es gibt verschiedene Möglichkeiten, a so zu konfigurieren, dass diese Konnektivität bereitgestellt wird. VPC Das Folgende ist ein einfaches Beispiel dafür, wie Sie einen App-Server-Stack VPC für einen AWS OpsWorks Stacks-App-Server konfigurieren können.
Dieser VPC besteht aus mehreren Komponenten:
- Subnets
-
Das VPC hat zwei Subnetze, ein öffentliches und ein privates.
-
Das öffentliche Subnetz enthält einen Load Balancer und ein Network Address Translation (NAT) -Gerät, das mit externen Adressen und mit den Instances im privaten Subnetz kommunizieren kann.
-
Das private Subnetz enthält die Anwendungsserver, die mit dem NAT und dem Load Balancer im öffentlichen Subnetz kommunizieren können, jedoch nicht direkt mit externen Adressen kommunizieren können.
-
- Internet-Gateway
-
Das Internet-Gateway ermöglicht Instances mit öffentlichen IP-Adressen, wie z. B. dem Load Balancer, die Kommunikation mit Adressen außerhalb von. VPC
- 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
-
Das (NAT) -Gerät bietet den App-Servern eingeschränkten Internetzugang, der in der Regel für Zwecke wie das Herunterladen von Softwareupdates aus einem externen Repository verwendet wird. 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, dieses Problem zu lösen, besteht darin, ein NAT Gerät mit einer zugehörigen Elastic IP-Adresse in ein öffentliches Subnetz zu stellen. Anschließend können Sie ausgehenden Datenverkehr von Instances im privaten Subnetz über das weiterleiten. NAT
Anmerkung
Eine einzelne NAT Instance erzeugt eine einzelne Fehlerquelle im ausgehenden Verkehr Ihres privaten Subnetzes. Sie können die Zuverlässigkeit verbessern, indem Sie sie VPC mit einem Paar von NAT Instances konfigurieren, die sich gegenseitig übernehmen, wenn eine ausfällt. Weitere Informationen finden Sie unter Hochverfügbarkeit für VPC NAT Amazon-Instances
. Sie können auch ein NAT Gateway verwenden. Weitere Informationen finden Sie NATim VPCAmazon-Benutzerhandbuch.
Die optimale VPC Konfiguration hängt von Ihrem AWS OpsWorks Stacks-Stack ab. Im Folgenden finden Sie einige Beispiele dafür, wann Sie bestimmte VPC Konfigurationen verwenden könnten. Beispiele für andere VPC Szenarien finden Sie unter Szenarien für die Nutzung von Amazon VPC.
- Working with one instance in a public subnet (Arbeiten mit einer Instance in einem öffentlichen Subnetz)
-
Wenn Sie über einen Single-Instance-Stack ohne zugehörige private Ressourcen verfügen — z. B. eine RDS Amazon-Instance, die nicht öffentlich zugänglich sein sollte —, können Sie einen VPC mit einem öffentlichen Subnetz erstellen und die Instance in dieses Subnetz stellen. Wenn Sie keinen Standard verwendenVPC, muss der Layer der Instance der Instance der Instance eine Elastic IP-Adresse zuweisen. Weitere Informationen finden Sie unter OpsWorks Grundlagen von Layern.
- Working with private resources (Arbeiten mit privaten Ressourcen)
-
Wenn Sie über Ressourcen verfügen, die nicht öffentlich zugänglich sein sollten, können Sie eine VPC mit einem öffentlichen Subnetz und einem privaten Subnetz erstellen. In einer automatischen Skalierungsumgebung mit Lastenausgleich können Sie beispielsweise alle EC2 Amazon-Instances im privaten Subnetz und den Load Balancer in einem öffentlichen Subnetz platzieren. Auf diese Weise kann nicht direkt über das Internet auf die EC2 Amazon-Instances zugegriffen werden. Der gesamte eingehende Datenverkehr muss über den Load Balancer geleitet werden.
Das private Subnetz isoliert die Instances vom EC2 direkten Benutzerzugriff durch Amazon, sie müssen jedoch weiterhin ausgehende Anfragen an AWS und die entsprechenden Linux-Paket-Repositorys senden. Um solche Anfragen zuzulassen, können Sie beispielsweise ein Network Address Translation (NAT) -Gerät mit eigener Elastic IP-Adresse verwenden und dann den ausgehenden Traffic der Instances über die weiterleiten. NAT Sie können das NAT in dasselbe öffentliche Subnetz wie den Load Balancer stellen, wie im vorherigen Beispiel gezeigt.
-
Wenn Sie eine Back-End-Datenbank wie eine RDS Amazon-Instance verwenden, können Sie diese Instances im privaten Subnetz platzieren. Für RDS Amazon-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, um sich beispielsweise bei einer Instance anzumelden, können Sie einen Bastion-Host in das öffentliche Subnetz stellen, der Anfragen aus dem Internet weiterleitet. SSH
-
- Erweitern Sie Ihr eigenes Netzwerk auf AWS
-
Wenn Sie Ihr eigenes Netzwerk in die Cloud erweitern und auch direkt von Ihrem aus auf das Internet zugreifen möchtenVPC, können Sie ein VPN Gateway erstellen. Weitere Informationen finden Sie unter Szenario 3: VPC mit öffentlichen und privaten Subnetzen und VPN Hardwarezugriff.
Erstellen Sie einen Stack VPC für einen AWS OpsWorks Stacks-Stack
In diesem Abschnitt wird anhand einer AWS CloudFormationBeispielvorlage gezeigt, wie Sie einen AWS OpsWorks Stack VPC für einen Stacks erstellen. Sie können die Vorlage in der OpsWorksVPCtemplatesZIP-Datei herunterladen. Weitere Informationen zum manuellen Erstellen eines VPC solchen, wie in diesem Thema beschrieben, 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 verkettet 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. Im folgenden Verfahren wird die Beispielvorlage verwendet, um eine Region VPC in den USA Ost (Nord-Virginia) zu erstellen. Anweisungen zur Verwendung der Vorlage zum Erstellen einer VPC in anderen Regionen finden Sie in dem Hinweis, der dem Verfahren folgt.
So erstellen Sie das 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.templateOpsWorksVPCtemplatesZIP-Datei nach der Datei, die Sie heruntergeladen haben. Wählen Sie Weiter.
Sie können diesen Stapel auch starten, indem Sie AWS CloudFormation 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 „Tags hinzufügen“ ein Tag, wobei Key auf
Nameund Value auf den VPC Namen gesetzt ist. Mit diesem Tag können Sie Ihren VPC beim Erstellen eines AWS OpsWorks Stacks-Stacks leichter identifizieren. -
Wählen Sie Continue (Weiter) und dann Close (Schließen) aus, um den Stack zu starten.
Hinweis: Sie können den VPC in anderen Regionen erstellen, indem Sie einen der folgenden Ansätze verwenden.
-
Gehen Sie zu Vorlagen in verschiedenen Regionen verwenden
, wählen Sie die entsprechende Region aus, suchen Sie die AWS OpsWorks VPC Stacks-Vorlage 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 das Subnetz und den VPC Load Balancer bereitstellen, IDs die Sie für die Erstellung des AWS OpsWorks Stacks-Stacks benötigen. Sie können sie sehen, indem Sie unten im Konsolenfenster auf die Registerkarte Ausgaben klicken. AWS CloudFormation
