Einen Stack ausführen in einem VPC - AWS OpsWorks

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 ausführen in einem VPC

Wichtig

Das Tool AWS OpsWorks Stacks Der 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 AWS Support Team ein AWS Re:post oder durch AWS Premium-Support.

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:

  1. Erstellen Sie eine entsprechend konfigurierteVPC, mithilfe der VPC Amazon-Konsole oderAPI, oder eine AWS CloudFormation Vorlage.

  2. Geben Sie die VPC ID an, wenn Sie den Stack erstellen.

  3. Starten Sie Stack-Instances im entsprechenden Subnetz.

Im Folgenden wird kurz beschrieben, wie VPCs Sie in AWS OpsWorks Stapel.

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 DNAEimer
  • opsworks-instance-agent-sa-Ost-1

  • opsworks-instance-agent-ap-Süd-1

  • opsworks-instance-agent-ap-Nordost-1

  • opsworks-instance-agent-ap-Nordost-2

  • opsworks-instance-agent-ap-Südost-1

  • opsworks-instance-agent-ap-Südost-2

  • opsworks-instance-agent-ca-zentral-1

  • opsworks-instance-agent-eu-zentral-1

  • opsworks-instance-agent-eu-West-1

  • opsworks-instance-agent-eu-West-2

  • opsworks-instance-agent-eu-West-3

  • opsworks-instance-agent-us-Ost-1

  • opsworks-instance-agent-us-Ost-2

  • opsworks-instance-agent-us-West-1

  • opsworks-instance-agent-us-West-2

  • opsworks-instance-assets-us-Ost-2

  • opsworks-instance-assets-us-Ost-1

  • opsworks-instance-assets-ap-Süd-1

  • opsworks-instance-assets-ap-Nordost-1

  • opsworks-instance-assets-ap-Nordost-2

  • opsworks-instance-assets-ap-Südost-1

  • opsworks-instance-assets-ap-Südost-2

  • opsworks-instance-assets-ca-zentral-1

  • opsworks-instance-assets-eu-zentral-1

  • opsworks-instance-assets-eu-West-1

  • opsworks-instance-assets-eu-West-2

  • opsworks-instance-assets-eu-West-3

  • opsworks-instance-assets-sa-Ost-1

  • opsworks-instance-assets-us-West-1

  • opsworks-instance-assets-us-West-2

  • opsworks-us-east-2 logarithmisch

  • opsworks-us-east-1-Protokoll

  • opsworks-ap-south-1-Protokoll

  • opsworks-ap-northeast-1-Protokoll

  • opsworks-ap-northeast-2 protokollieren

  • opsworks-ap-southeast-1-Protokoll

  • opsworks-ap-southeast-2 protokollieren

  • opsworks-ca-central-1-Protokoll

  • opsworks-eu-central-1-Protokoll

  • opsworks-eu-west-1-Protokoll

  • opsworks-eu-west-2 protokollieren

  • opsworks-eu-west-3 protokollieren

  • opsworks-sa-east-1-Protokoll

  • opsworks-us-west-1-Protokoll

  • opsworks-us-west-2 protokollieren

  • opsworks-us-east-2-DNA

  • opsworks-us-east-1-DNA

  • opsworks-ap-south-1-DNA

  • opsworks-ap-northeast-1-DNA

  • opsworks-ap-northeast-2-DNA

  • opsworks-ap-southeast-1-DNA

  • opsworks-ap-southeast-2-DNA

  • opsworks-ca-central-1-DNA

  • opsworks-eu-central-1-DNA

  • opsworks-eu-west-1-DNA

  • opsworks-eu-west-2-DNA

  • opsworks-eu-west-3-DNA

  • opsworks-sa-east-1-DNA

  • opsworks-us-west-1-DNA

  • opsworks-us-west-2-DNA

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 DNAEimer
  • opsworks-instance-agent-us-Ost-2

  • opsworks-instance-agent-us-Ost-1

  • opsworks-instance-agent-ap-Süd-1

  • opsworks-instance-agent-ap-Nordost-1

  • opsworks-instance-agent-ap-Nordost-2

  • opsworks-instance-agent-ap-Südost-1

  • opsworks-instance-agent-ap-Südost-2

  • opsworks-instance-agent-ca-zentral-1

  • opsworks-instance-agent-eu-zentral-1

  • opsworks-instance-agent-eu-West-1

  • opsworks-instance-agent-eu-West-2

  • opsworks-instance-agent-eu-West-3

  • opsworks-instance-agent-us-Ost-1

  • opsworks-instance-agent-us-West-1

  • opsworks-instance-agent-us-West-2

  • opsworks-instance-assets-us-Ost-2

  • opsworks-instance-assets-us-Ost-1

  • opsworks-instance-assets-ap-Süd-1

  • opsworks-instance-assets-ap-Nordost-1

  • opsworks-instance-assets-ap-Nordost-2

  • opsworks-instance-assets-ap-Südost-1

  • opsworks-instance-assets-ap-Südost-2

  • opsworks-instance-assets-ca-zentral-1

  • opsworks-instance-assets-eu-zentral-1

  • opsworks-instance-assets-eu-West-1

  • opsworks-instance-assets-eu-West-2

  • opsworks-instance-assets-eu-West-3

  • opsworks-instance-assets-sa-Ost-1

  • opsworks-instance-assets-us-West-1

  • opsworks-instance-assets-us-West-2

  • prod_stage-log

  • prod_stage-dna

Weitere Informationen finden Sie unter VPC-Endpunkte.

Anmerkung

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. AWS OpsWorks Für Stacks zur Verbindung mit den VPC Endpunkten, die Sie aktivieren, müssen Sie auch das Routing für Ihre NAT oder öffentliche IP konfigurieren, wie AWS OpsWorks Der Stacks-Agent benötigt weiterhin Zugriff auf den öffentlichen Endpunkt.

VPCGrundlagen

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, verwendet von AWS OpsWorks Stacks-Agent. 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 eine Vielzahl von Möglichkeiten, a so zu konfigurieren, dass diese Konnektivität bereitgestellt wird. VPC Im Folgenden finden Sie ein einfaches Beispiel dafür, wie Sie a VPC für eine konfigurieren könnten AWS OpsWorks Stapelt den App-Server-Stapel.

VPC diagram showing public and private subnets, NAT, load balancing, and connections to external services.

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 mit den entsprechenden Linux-Repositorys. 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 Stapel stapeln sich. 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 eine VPC für AWS OpsWorks Stapel Stapel

Dieser Abschnitt zeigt, wie Sie eine VPC für eine erstellen AWS OpsWorks Stapel stapeln sich mithilfe einer AWS CloudFormationBeispielvorlage. 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 AWS OpsWorks Stacks zeigt Subnetznamen an, indem deren CIDR Bereich und Availability Zone verkettet werden, z. B. 10.0.0.1/24 - us-east-1b Um lesbarere Namen zu generieren, erstellen Sie ein Tag für jedes Subnetz, bei dem Sie für Key (Schlüssel) die Option Name und für Value (Wert) den Namen des Subnetzes auswählen. 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 starten, indem Sie AWS CloudFormation Konsole mit nur wenigen Schritten. 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.

Um das zu erstellen VPC
  1. Öffnen Sie AWS CloudFormation Wählen Sie in der Konsole die Region USA Ost (Nord-Virginia) und anschließend Create Stack aus.

  2. Wählen Sie auf der Seite Select Template (Vorlage auswählen) Upload a template (Eine Vorlage hochladen) aus. Suchen Sie in der OpsWorksinVPC.template OpsWorksVPCtemplatesZIP-Datei nach der Datei, die Sie heruntergeladen haben. Wählen Sie Weiter.

    CloudFormation Wählen Sie die Vorlagenseite

    Sie können diesen Stapel auch starten, indem Sie AWS CloudFormation Beispielvorlagen öffnen und dort den AWS OpsWorks VPCVorlage Stacks und Auswahl von Launch Stack.

  3. Akzeptieren Sie auf der Seite Specify Parameters (Parameter angeben) die Standardwerte und Continue (Weiter) aus.

  4. Erstellen Sie auf der Seite „Tags hinzufügen“ ein Tag, bei dem Key auf Name und Value auf den VPC Namen eingestellt sind. Mit diesem Tag können Sie Ihren leichter identifizierenVPC, wenn Sie ein AWS OpsWorks Stapel stapeln sich.

  5. Wählen Sie Continue (Weiter) und dann Close (Schließen) aus, um den Stack zu starten.

Hinweis: Sie können die 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 und suchen Sie nach AWS OpsWorks VPCStacks-Vorlage und wählen Sie dann Stack starten aus.

  • Kopieren Sie die Vorlagendatei auf Ihr System und wählen Sie die entsprechende Region im AWS CloudFormation Konsole und verwenden Sie die Option Vorlage auf Amazon S3 hochladen des Assistenten „Stack erstellen“, um die Vorlage von Ihrem System hochzuladen.

Die Beispielvorlage enthält Ausgaben, die das VPC Subnetz und den Load Balancer bereitstellen, IDs die Sie für die Erstellung des AWS OpsWorks Stapel stapeln sich. Sie können sie sehen, indem Sie den Tab Ausgaben unten im AWS CloudFormation Konsolenfenster.

Stack outputs table showing VPC, subnet, and load balancer IDs for an OpsWorks-in-VPC stack.