Erstellen Sie einen ROSA klassischen Cluster, der AWS PrivateLink - Red Hat OpenShift Service in AWS

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.

Erstellen Sie einen ROSA klassischen Cluster, der AWS PrivateLink

ROSAklassische Cluster können auf verschiedene Arten bereitgestellt werden: öffentlich, privat oder privat mit AWS PrivateLink. Weitere Informationen zu ROSA Classic finden Sie unterArchitekturmodelle. Sowohl für öffentliche als auch für private Zwecke Cluster Konfigurationen, die OpenShift Cluster hat Zugriff auf das Internet, und der Datenschutz wird für die Anwendungs-Workloads auf der Anwendungsebene festgelegt.

Wenn Sie beide benötigen Cluster und dass die Anwendungs-Workloads privat sind, können Sie konfigurieren AWS PrivateLink mit ROSA Klassik. AWS PrivateLink ist eine hochverfügbare, skalierbare Technologie, die ROSA verwendet, um eine private Verbindung herzustellen zwischen ROSA Service- und Clusterressourcen im AWS Kundenkonto. Mit AWS PrivateLink, das RedHat Site Reliability Engineering (SRE) -Team kann zu Support- und Problembehebungszwecken auf den Cluster zugreifen, indem es ein privates Subnetz verwendet, das mit dem des Clusters verbunden ist AWS PrivateLink Endpunkt.

Weitere Informationen zur AWS PrivateLink, siehe Was ist AWS PrivateLink?

Führen Sie die erforderlichen Aktionen aus, die unter aufgeführt sindZur Verwendung eingerichtet ROSA.

Erstellen Amazon VPC Anwendung ansehen

Das folgende Verfahren erstellt Amazon VPC Architektur, die zum Hosten eines Clusters verwendet werden kann. Alle Cluster Ressourcen werden im privaten Subnetz gehostet. Das öffentliche Subnetz leitet ausgehenden Verkehr vom privaten Subnetz über ein NAT Gateway zum öffentlichen Internet weiter. In diesem Beispiel wird der Block für die CIDR verwendet 10.0.0.0/16 Amazon VPC. Sie können jedoch einen anderen CIDR Block wählen. Weitere Informationen finden Sie unter VPCGröße.

Wichtig

Wenn Amazon VPC Die Anforderungen werden nicht erfüllt, die Clustererstellung schlägt fehl.

Amazon VPC console
  1. Öffnen Sie Amazon VPC Konsole.

  2. Wählen Sie im VPC Dashboard die Option Erstellen ausVPC.

  3. Wählen Sie unter Zu erstellende Ressourcen die Option VPCund mehr aus.

  4. Lassen Sie die automatische Generierung von Namensschildern aktiviert, um Namensschilder für die VPC Ressourcen zu erstellen, oder deaktivieren Sie die Option, um eigene Namensschilder für die VPC Ressourcen bereitzustellen.

  5. Geben Sie im Feld IPv4CIDRBlock einen IPv4 Adressbereich für den VPC ein. A VPC muss einen IPv4 Adressbereich haben.

  6. (Optional) Um IPv6 Traffic zu unterstützen, wählen Sie IPv6CIDRBlock, von Amazon bereitgestellter Block IPv6 CIDR.

  7. Belassen Sie Tenancy als. Default

  8. Wählen Sie unter Anzahl der Availability Zones (AZs) die Anzahl aus, die Sie benötigen. Für Multi-AZ-Bereitstellungen ROSA erfordert drei Availability Zones. Erweitern Sie Anpassen AZs, um die AZs für Ihre Subnetze auszuwählen.

    Anmerkung

    Etwas ROSA Instanztypen sind nur in ausgewählten Availability Zones verfügbar. Sie können das ROSA CLIBefehl rosa list instance-types Befehl, um alle aufzulisten ROSA Verfügbare Instanztypen. Um zu überprüfen, ob ein Instance-Typ für eine bestimmte Availability Zone verfügbar ist, verwenden Sie den AWS CLI Befehlaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

  9. Um Ihre Subnetze zu konfigurieren, wählen Sie Werte für Anzahl der öffentlichen Subnetze und Anzahl der privaten Subnetze. Um die IP-Adressbereiche für Ihre Subnetze auszuwählen, erweitern Sie die Option Subnetzblöcke CIDR anpassen.

    Anmerkung

    ROSA erfordert, dass Kunden mindestens ein privates Subnetz pro Availability Zone konfigurieren, das zum Erstellen von Clustern verwendet wird.

  10. Um Ressourcen im privaten Subnetz Zugriff auf das öffentliche Internet zu gewährenIPv4, wählen Sie für NATGateways die Anzahl der Gateways aus, AZs in denen Gateways erstellt werden sollen. NAT In der Produktion empfehlen wir, in jeder AZ ein NAT Gateway mit Ressourcen bereitzustellen, die Zugriff auf das öffentliche Internet benötigen.

  11. (Optional) Wenn Sie darauf zugreifen müssen Amazon S3 direkt von IhremVPC, ausgewählten VPCEndpunkt, S3 Gateway.

  12. Behalten Sie die ausgewählten DNS Standardoptionen bei. ROSA erfordert DNS Hostnamen-Unterstützung auf demVPC.

  13. Wählen Sie Erstellen VPC.

AWS CLI
  1. Erstellen Sie eine VPC mit einem 10.0.0.0/16 CIDR Block.

    aws ec2 create-vpc \ --cidr-block 10.0.0.0/16 \ --query Vpc.VpcId \ --output text

    Der vorherige Befehl gibt die VPC ID zurück. Im Folgenden finden Sie eine Beispielausgabe.

    vpc-1234567890abcdef0
  2. Speichern Sie die VPC ID in einer Umgebungsvariablen.

    export VPC_ID=vpc-1234567890abcdef0
  3. Erstellen Sie mithilfe der VPC VPC_ID Umgebungsvariablen ein Name Tag für die.

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC
  4. Aktivieren Sie die DNS Hostnamen-Unterstützung auf demVPC.

    aws ec2 modify-vpc-attribute \ --vpc-id $VPC_ID \ --enable-dns-hostnames
  5. Erstellen Sie ein öffentliches und privates Subnetz in der und geben Sie die Availability Zones anVPC, in denen die Ressourcen erstellt werden sollen.

    Wichtig

    ROSA erfordert, dass Kunden mindestens ein privates Subnetz pro Availability Zone konfigurieren, die zur Erstellung von Clustern verwendet wird. Für Multi-AZ-Bereitstellungen sind drei Availability Zones erforderlich. Wenn diese Anforderungen nicht erfüllt sind, schlägt die Clustererstellung fehl.

    Anmerkung

    Etwas ROSA Instanztypen sind nur in ausgewählten Availability Zones verfügbar. Sie können das ROSA CLIBefehl rosa list instance-types Befehl, um alle aufzulisten ROSA Verfügbare Instanztypen. Um zu überprüfen, ob ein Instance-Typ für eine bestimmte Availability Zone verfügbar ist, verwenden Sie den AWS CLI Befehlaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

    aws ec2 create-subnet \ --vpc-id $VPC_ID \ --cidr-block 10.0.1.0/24 \ --availability-zone us-east-1a \ --query Subnet.SubnetId \ --output text aws ec2 create-subnet \ --vpc-id $VPC_ID \ --cidr-block 10.0.0.0/24 \ --availability-zone us-east-1a \ --query Subnet.SubnetId \ --output text
  6. Speichern Sie das öffentliche und private Subnetz IDs in Umgebungsvariablen.

    export PUBLIC_SUB=subnet-1234567890abcdef0 export PRIVATE_SUB=subnet-0987654321fedcba0
  7. Erstellen Sie ein Internet-Gateway und eine Routing-Tabelle für ausgehenden Verkehr. Erstellen Sie eine Routentabelle und eine elastische IP-Adresse für privaten Datenverkehr.

    aws ec2 create-internet-gateway \ --query InternetGateway.InternetGatewayId \ --output text aws ec2 create-route-table \ --vpc-id $VPC_ID \ --query RouteTable.RouteTableId \ --output text aws ec2 allocate-address \ --domain vpc \ --query AllocationId \ --output text aws ec2 create-route-table \ --vpc-id $VPC_ID \ --query RouteTable.RouteTableId \ --output text
  8. Speichern Sie die Variablen IDs in der Umgebung.

    export IGW=igw-1234567890abcdef0 export PUBLIC_RT=rtb-0987654321fedcba0 export EIP=eipalloc-0be6ecac95EXAMPLE export PRIVATE_RT=rtb-1234567890abcdef0
  9. Verbinden Sie das Internet-Gateway mit demVPC.

    aws ec2 attach-internet-gateway \ --vpc-id $VPC_ID \ --internet-gateway-id $IGW
  10. Ordnen Sie die Tabelle für öffentliche Routen dem öffentlichen Subnetz zu und konfigurieren Sie den Datenverkehr so, dass er zum Internet-Gateway weitergeleitet wird.

    aws ec2 associate-route-table \ --subnet-id $PUBLIC_SUB \ --route-table-id $PUBLIC_RT aws ec2 create-route \ --route-table-id $PUBLIC_RT \ --destination-cidr-block 0.0.0.0/0 \ --gateway-id $IGW
  11. Erstellen Sie das NAT Gateway und ordnen Sie es der elastischen IP-Adresse zu, um den Verkehr zum privaten Subnetz zu ermöglichen.

    aws ec2 create-nat-gateway \ --subnet-id $PUBLIC_SUB \ --allocation-id $EIP \ --query NatGateway.NatGatewayId \ --output text
  12. Ordnen Sie die private Routing-Tabelle dem privaten Subnetz zu und konfigurieren Sie den Datenverkehr so, dass er zum NAT Gateway weitergeleitet wird.

    aws ec2 associate-route-table \ --subnet-id $PRIVATE_SUB \ --route-table-id $PRIVATE_RT aws ec2 create-route \ --route-table-id $PRIVATE_RT \ --destination-cidr-block 0.0.0.0/0 \ --gateway-id $NATGW
  13. (Optional) Wiederholen Sie bei Multi-AZ-Bereitstellungen die obigen Schritte, um zwei weitere Availability Zones mit öffentlichen und privaten Subnetzen zu konfigurieren.

Sie können das ROSA CLIund AWS PrivateLink um eine zu erstellen Cluster mit einer einzigen Availability Zone (Single-AZ) oder mehreren Availability Zones (Multi-AZ). In beiden Fällen muss der Wert Ihrer Maschine mit Ihrem CIDR VPC Wert übereinstimmen. CIDR

Das folgende Verfahren verwendet den rosa create cluster Befehl, um einen ROSA Klassiker zu erstellen Cluster. Um ein Multi-AZ zu erstellen Cluster, geben Sie --multi-az im Befehl an, und wählen Sie dann das private Subnetz ausIDs, das Sie verwenden möchten, wenn Sie dazu aufgefordert werden.

Anmerkung

Wenn Sie eine Firewall verwenden, müssen Sie sie so konfigurieren, dass ROSA kann auf die Websites zugreifen, die für den Betrieb erforderlich sind.

Weitere Informationen finden Sie unter AWS Firewall-Voraussetzungen in der Red OpenShift Hat-Dokumentation.

  1. Erstellen Sie die erforderlichen IAM Kontorollen und Richtlinien mit --mode auto oder--mode manual.

    • rosa create account-roles --classic --mode auto
    • rosa create account-roles --classic --mode manual
      Anmerkung

      Wenn Ihr Offline-Zugriffstoken abgelaufen ist, ROSA CLIgibt eine Fehlermeldung aus, die besagt, dass Ihr Autorisierungstoken aktualisiert werden muss. Schritte zur Problembehandlung finden Sie unterProblembehandlung bei ROSA CLI abgelaufenen Offline-Zugriffstoken.

  2. Erstellen Sie ein Cluster indem Sie einen der folgenden Befehle ausführen.

    • Single-AZ

      rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>
    • Multi-AZ

      rosa create cluster --private-link --multi-az --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16
      Anmerkung

      Um einen Cluster zu erstellen, der AWS PrivateLink mit AWS Security Token Service (AWS STS) kurzlebige Anmeldeinformationen, fügen Sie --sts --mode auto oder --sts --mode manual an das Ende des rosa create cluster Befehls an.

  3. Erstellen Sie die Cluster operator IAM Rollen, indem Sie den interaktiven Anweisungen folgen.

    rosa create operator-roles --interactive -c <CLUSTER_NAME>
  4. Erstellen Sie den OpenID Connect (OIDC) -Anbieter Cluster Operatoren verwenden, um sich zu authentifizieren.

    rosa create oidc-provider --interactive -c <CLUSTER_NAME>
  5. Überprüfen Sie den Status Ihres Cluster.

    rosa describe cluster -c <CLUSTER_NAME>
    Anmerkung

    Es kann bis zu 40 Minuten dauern Cluster StateFeld zur Anzeige des ready Status. Wenn die Bereitstellung fehlschlägt oder nicht ready nach 40 Minuten angezeigt wird, finden Sie weitere Informationen unterFehlerbehebung. Um Kontakt aufzunehmen AWS Support oder Unterstützung durch den Red Hat Support finden Sie unterROSA Unterstützung erhalten.

  6. Verfolgen Sie den Fortschritt des Cluster Erstellung, indem Sie sich die OpenShift Installationsprotokolle ansehen.

    rosa logs install -c <CLUSTER_NAME> --watch

Cluster, die verwenden AWS PrivateLink erstellen Sie eine öffentlich gehostete Zone und eine private gehostete Zone in Route 53. Aufzeichnungen innerhalb der Route 53 Eine private gehostete Zone kann nur innerhalb der Zone aufgelöst werdenVPC, der sie zugewiesen ist.

Für die Validierung von Let's Encrypt DNS -01 ist eine öffentliche Zone erforderlich, damit gültige und öffentlich vertrauenswürdige Zertifikate für die Domain ausgestellt werden können. Die Validierungsdatensätze werden gelöscht, nachdem die Let's Encrypt-Validierung abgeschlossen ist. Die Zone ist weiterhin für die Ausstellung und Erneuerung dieser Zertifikate erforderlich, die normalerweise alle 60 Tage erforderlich sind. Obwohl diese Zonen normalerweise leer erscheinen, spielt eine öffentliche Zone eine entscheidende Rolle im Validierungsprozess.

Weitere Informationen zur AWS private gehostete Zonen, siehe Arbeiten mit privaten Zonen. Weitere Informationen zu öffentlich gehosteten Zonen finden Sie unter Arbeiten mit öffentlich gehosteten Zonen.

  1. Um Datensätze wie api.<cluster_domain> und deren Auflösung außerhalb von *.apps.<cluster_domain> zu ermöglichenVPC, konfigurieren Sie einen Route 53 Resolver eingehender Endpunkt.

    Anmerkung

    Wenn Sie einen Eingangsendpunkt konfigurieren, müssen Sie aus Redundanzgründen mindestens zwei IP-Adressen angeben. Wir empfehlen, IP-Adressen in mindestens zwei Availability Zones festzulegen. Wahlweise können Sie zusätzliche IP-Adressen in diesen oder anderen Availability Zones angeben.

  2. Wählen Sie bei der Konfiguration des Eingangsendpunkts die privaten Subnetze VPC und die privaten Subnetze aus, die bei der Erstellung des Clusters verwendet wurden.

Nach dem Route 53 Resolver Der interne Endpunkt ist zugeordnet und betriebsbereit. Konfigurieren Sie die DNS Weiterleitung so, dass DNS Anfragen von den dafür vorgesehenen Servern in Ihrem Netzwerk bearbeitet werden können.

  1. Konfigurieren Sie Ihr Unternehmensnetzwerk so, dass DNS Anfragen an die IP-Adressen für die Top-Level-Domain weitergeleitet werden, z. B. drow-pl-01.htno.p1.openshiftapps.com

  2. Wenn Sie DNS Anfragen von einem Server VPC an einen anderen weiterleitenVPC, folgen Sie den Anweisungen unter Weiterleitungsregeln verwalten.

  3. Wenn Sie Ihren DNS Remote-Netzwerkserver konfigurieren, finden Sie in der jeweiligen DNS Serverdokumentation Informationen zur Konfiguration der selektiven DNS Weiterleitung für die installierte Clusterdomäne.

ROSA beinhaltet einen integrierten OAuth Server. Nach deinem ROSA Cluster erstellt wurde, müssen Sie für OAuth die Verwendung eines Identitätsanbieters konfigurieren. Anschließend können Sie Benutzer zu Ihrem konfigurierten Identitätsanbieter hinzufügen, um ihnen Zugriff auf Ihren Cluster. Sie können diesen Benutzern cluster-admin oder dedicated-admin Berechtigungen nach Bedarf gewähren.

Sie können verschiedene Identitätsanbietertypen für Ihre konfigurieren Cluster. Zu den unterstützten Typen gehören GitHub Enterprise GitHub GitLab, GoogleLDAP, OpenID Connect und HTPasswd Identity Providers.

Wichtig

Der HTPasswd Identitätsanbieter ist nur enthalten, um die Erstellung eines einzelnen statischen Administratorbenutzers zu ermöglichen. HTPasswdwird nicht als allgemein verwendbarer Identitätsanbieter für unterstützt ROSA.

Im folgenden Verfahren wird ein GitHub Identitätsanbieter als Beispiel konfiguriert. Anweisungen zur Konfiguration der einzelnen unterstützten Identitätsanbietertypen finden Sie unter Konfiguration von Identitätsanbietern für AWS STS.

  1. Navigieren Sie zu github.com und melden Sie sich bei Ihrem GitHub Konto an.

  2. Wenn Sie keine GitHub Organisation haben, die Sie für die Identitätsbereitstellung für Ihr ROSA Cluster, erstellen Sie eine. Weitere Informationen finden Sie in den Schritten in der GitHub Dokumentation.

  3. Verwendung der ROSA CLIKonfigurieren Sie im interaktiven Modus einen Identitätsanbieter für Ihren Cluster, indem Sie den folgenden Befehl ausführen.

    rosa create idp --cluster=<CLUSTER_NAME> --interactive
  4. Folgen Sie den Konfigurationsanweisungen in der Ausgabe, um einzuschränken Cluster Zugriff auf Mitglieder Ihrer GitHub Organisation.

    I: Interactive mode enabled. Any optional fields can be left empty and a default will be selected. ? Type of identity provider: github ? Identity provider name: github-1 ? Restrict to members of: organizations ? GitHub organizations: <GITHUB_ORG_NAME> ? To use GitHub as an identity provider, you must first register the application: - Open the following URL: https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com - Click on 'Register application' ...
  5. Öffnen Sie das URL in der Ausgabe und <GITHUB_ORG_NAME> ersetzen Sie es durch den Namen Ihrer GitHub Organisation.

  6. Wählen Sie auf der GitHub Webseite Anwendung registrieren aus, um eine neue OAuth Anwendung in Ihrer GitHub Organisation zu registrieren.

  7. Verwenden Sie die Informationen GitHub OAuth auf der Seite, um die verbleibenden rosa create idp interaktiven Eingabeaufforderungen zu füllen, <GITHUB_CLIENT_ID> und <GITHUB_CLIENT_SECRET> ersetzen Sie dabei die Anmeldeinformationen aus Ihrer GitHub OAuth Anwendung.

    ... ? Client ID: <GITHUB_CLIENT_ID> ? Client Secret: [? for help] <GITHUB_CLIENT_SECRET> ? GitHub Enterprise Hostname (optional): ? Mapping method: claim I: Configuring IDP for cluster '<CLUSTER_NAME>' I: Identity Provider 'github-1' has been created. It will take up to 1 minute for this configuration to be enabled. To add cluster administrators, see 'rosa grant user --help'. To login into the console, open https://console-openshift-console.apps.<CLUSTER_NAME>.<RANDOM_STRING>.p1.openshiftapps.com and click on github-1.
    Anmerkung

    Es kann etwa zwei Minuten dauern, bis die Identity Provider-Konfiguration aktiv wird. Wenn Sie einen cluster-admin Benutzer konfiguriert haben, können Sie den oc get pods -n openshift-authentication --watch Befehl ausführen, um zu beobachten, wie die OAuth Pods mit der aktualisierten Konfiguration erneut bereitgestellt werden.

  8. Stellen Sie sicher, dass der Identitätsanbieter korrekt konfiguriert wurde.

    rosa list idps --cluster=<CLUSTER_NAME>

Sie können einem Benutzer Zugriff auf Ihr gewähren Cluster indem Sie sie dem konfigurierten Identity Provider hinzufügen.

Das folgende Verfahren fügt einen Benutzer zu einer GitHub Organisation hinzu, die für die Identitätsbereitstellung im Cluster konfiguriert ist.

  1. Navigieren Sie zu github.com und melden Sie sich bei Ihrem GitHub Konto an.

  2. Laden Sie Benutzer ein, die Folgendes benötigen Cluster Zugriff auf Ihre GitHub Organisation. Weitere Informationen finden Sie in der GitHub Dokumentation unter Benutzer einladen, Ihrer Organisation beizutreten.

  1. Erteilen Sie die cluster-admin Berechtigungen mit dem folgenden Befehl. Ersetzen Sie <IDP_USER_NAME> und <CLUSTER_NAME> durch Ihren Benutzer- und Clusternamen.

    rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. Stellen Sie sicher, dass der Benutzer als Mitglied der cluster-admins Gruppe aufgeführt ist.

    rosa list users --cluster=<CLUSTER_NAME>
  1. Erteilen Sie die dedicated-admin Berechtigungen mit dem folgenden Befehl. Ersetzen Sie <IDP_USER_NAME> und <CLUSTER_NAME> durch Ihren Benutzer und Cluster Name.

    rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. Stellen Sie sicher, dass der Benutzer als Mitglied der cluster-admins Gruppe aufgeführt ist.

    rosa list users --cluster=<CLUSTER_NAME>

Nachdem Sie ein erstellt haben Cluster Administratorbenutzer oder wenn Sie Ihrem konfigurierten Identity Provider einen Benutzer hinzugefügt haben, können Sie sich bei Ihrem Cluster über die Red Hat Hybrid Cloud Console.

  1. Besorgen Sie sich die Konsole URL für Cluster mit dem folgenden Befehl. <CLUSTER_NAME>Ersetze es durch den Namen deines Cluster.

    rosa describe cluster -c <CLUSTER_NAME> | grep Console
  2. Navigieren Sie URL in der Ausgabe zur Konsole und melden Sie sich an.

    • Wenn Sie einen cluster-admin Benutzer erstellt haben, melden Sie sich mit den angegebenen Anmeldeinformationen an.

    • Wenn Sie einen Identitätsanbieter für Ihren konfiguriert haben Cluster, wählen Sie den Namen des Identitätsanbieters im Dialogfeld Anmelden mit... und füllen Sie alle Autorisierungsanfragen Ihres Anbieters aus.

Von der Red Hat Hybrid Cloud Console aus können Sie eine Developer Catalog-Testanwendung bereitstellen und sie mit einer Route verfügbar machen.

  1. Navigieren Sie zur Red Hat Hybrid Cloud Console und wählen Sie den Cluster aus, in dem Sie die App bereitstellen möchten.

  2. Wählen Sie auf der Seite des Clusters Open Console aus.

  3. Wählen Sie in der Administratorperspektive Startseite > Projekte > Projekt erstellen aus.

  4. Geben Sie einen Namen für Ihr Projekt ein und fügen Sie optional einen Anzeigenamen und eine Beschreibung hinzu.

  5. Wählen Sie Erstellen, um das Projekt zu erstellen.

  6. Wechseln Sie zur Entwicklerperspektive und wählen Sie +Hinzufügen. Stellen Sie sicher, dass das ausgewählte Projekt das ist, das gerade erstellt wurde.

  7. Wählen Sie im Dialogfeld „Entwicklerkatalog“ die Option Alle Dienste aus.

  8. Wählen Sie auf der Seite mit dem Entwicklerkatalog im Menü Sprachen > JavaScriptaus.

  9. Wählen Sie „Node.js“ und anschließend „Anwendung erstellen“, um die Seite „Source-to-Image-Anwendung erstellen“ zu öffnen.

    Anmerkung

    Möglicherweise müssen Sie „Alle Filter löschen“ auswählen, um die Option Node.js anzuzeigen.

  10. Wählen Sie im Abschnitt Git die Option Try Sample aus.

  11. Fügen Sie im Feld Name einen eindeutigen Namen hinzu.

  12. Wählen Sie Create (Erstellen) aus.

    Anmerkung

    Die Bereitstellung der neuen Anwendung dauert mehrere Minuten.

  13. Wenn die Bereitstellung abgeschlossen ist, wählen Sie die Route URL für die Anwendung aus.

    Im Browser wird eine neue Registerkarte mit einer Meldung geöffnet, die der folgenden ähnelt.

    Welcome to your Node.js application on OpenShift
  14. (Optional) Löschen Sie die Anwendung und bereinigen Sie die Ressourcen.

    1. Wählen Sie in der AdministratorperspektiveStartseite“ > „Projekte“.

    2. Öffnen Sie das Aktionsmenü für Ihr Projekt und wählen Sie Projekt löschen.

  1. Widerrufen Sie die cluster-admin Berechtigungen mit dem folgenden Befehl. Ersetzen Sie <IDP_USER_NAME> und <CLUSTER_NAME> durch Ihren Benutzer und Cluster Name.

    rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. Stellen Sie sicher, dass der Benutzer nicht als Mitglied der cluster-admins Gruppe aufgeführt ist.

    rosa list users --cluster=<CLUSTER_NAME>
  1. Widerrufen Sie die dedicated-admin Berechtigungen mit dem folgenden Befehl. Ersetzen Sie <IDP_USER_NAME> und <CLUSTER_NAME> durch Ihren Benutzer und Cluster Name.

    rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. Stellen Sie sicher, dass der Benutzer nicht als Mitglied der dedicated-admins Gruppe aufgeführt ist.

    rosa list users --cluster=<CLUSTER_NAME>

Sie können widerrufen Cluster Zugriff für einen Identity Provider-Benutzer, indem Sie ihn aus dem konfigurierten Identity Provider entfernen.

Sie können verschiedene Arten von Identitätsanbietern für Ihre konfigurieren Cluster. Das folgende Verfahren widerruft Cluster Zugriff für ein Mitglied einer GitHub Organisation.

  1. Navigieren Sie zu github.com und melden Sie sich bei Ihrem GitHub Konto an.

  2. Entferne den Benutzer aus deiner GitHub Organisation. Weitere Informationen finden Sie in der GitHub Dokumentation unter Ein Mitglied aus Ihrer Organisation entfernen.

Sie können das ROSA CLIum einen zu löschen Cluster das benutzt AWS Security Token Service (AWS STS). Sie können auch die verwenden ROSA CLIum das zu löschen IAM Rollen und OIDC Anbieter, erstellt von ROSA. Um das zu löschen IAM Richtlinien erstellt von ROSA, Sie können das verwenden IAM console.

Wichtig

IAM Rollen und Richtlinien, erstellt von ROSA könnte von anderen verwendet werden ROSA Cluster im selben Konto.

  1. Löschen Sie die Cluster und sieh dir die Protokolle an. Ersetze es <CLUSTER_NAME> durch den Namen oder die ID deines Cluster.

    rosa delete cluster --cluster=<CLUSTER_NAME> --watch
    Wichtig

    Sie müssen auf das warten Cluster um es vollständig zu löschen, bevor Sie das entfernen IAM Rollen, Richtlinien und OIDC Anbieter. Die IAM Kontorollen sind erforderlich, um die vom Installationsprogramm erstellten Ressourcen zu löschen. Die IAM Operatorrollen sind erforderlich, um die von den OpenShift Operatoren erstellten Ressourcen zu bereinigen. Die Betreiber verwenden den OIDC Anbieter zur Authentifizierung.

  2. Löschen Sie den OIDC Anbieter, den Cluster Operatoren verwenden, um sich zu authentifizieren, indem sie den folgenden Befehl ausführen.

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto
  3. Löschen Sie den clusterspezifischen Operator IAM Rollen.

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto
  4. Löschen Sie die IAM Kontorollen mit dem folgenden Befehl. <PREFIX>Ersetzen Sie es durch das Präfix der zu löschenden IAM Kontorollen. Wenn Sie beim Erstellen der IAM Kontorollen ein benutzerdefiniertes Präfix angegeben haben, geben Sie das ManagedOpenShift Standardpräfix an.

    rosa delete account-roles --prefix <PREFIX> --mode auto
  5. Löschen Sie die IAM Richtlinien wurden erstellt von ROSA.

    1. Loggen Sie sich ein in IAM Konsole.

    2. Wählen Sie im linken Menü unter Zugriffsverwaltung die Option Richtlinien aus.

    3. Wählen Sie die Richtlinie aus, die Sie löschen möchten, und wählen Sie Aktionen > Löschen.

    4. Geben Sie den Richtliniennamen ein und wählen Sie Löschen aus.

    5. Wiederholen Sie diesen Schritt, um alle IAM Richtlinien für das zu löschen Cluster.