Einrichtung einer benutzerdefinierten Domain für den Apache Airflow-Webserver - Amazon Managed Workflows für Apache Airflow

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.

Einrichtung einer benutzerdefinierten Domain für den Apache Airflow-Webserver

Mit Amazon Managed Workflows for Apache Airflow (Amazon MWAA) können Sie eine benutzerdefinierte Domain für den verwalteten Apache Airflow-Webserver einrichten. Mithilfe einer benutzerdefinierten Domain können Sie über die Apache Airflow-Benutzeroberfläche, die Apache Airflow-CLI oder den Apache Airflow-Webserver auf den von Amazon MWAA verwalteten Apache Airflow-Webserver Ihrer Umgebung zugreifen.

Anmerkung

Sie können eine benutzerdefinierte Domain nur mit einem privaten Webserver ohne Internetzugang verwenden.

Anwendungsfälle für eine benutzerdefinierte Domain auf Amazon MWAA
  1. Teilen Sie die Webserver-Domain in Ihrer Cloud-Anwendung unter AWS — Mithilfe einer benutzerdefinierten Domain können Sie anstelle des generierten Service-Domainnamens eine benutzerfreundliche URL für den Zugriff auf den Webserver definieren. Sie können diese benutzerdefinierte Domain speichern und als Umgebungsvariable in Ihren Anwendungen teilen.

  2. Zugriff auf einen privaten Webserver — Wenn Sie den Zugriff für einen Webserver in einer VPC ohne Internetzugang konfigurieren möchten, vereinfacht die Verwendung einer benutzerdefinierten Domain den Workflow für die URL-Umleitung.

Konfigurieren Sie die benutzerdefinierte Domain

Um die Funktion für benutzerdefinierte Domänen zu konfigurieren, müssen Sie den benutzerdefinierten Domänenwert über die webserver.base_url Apache Airflow-Konfiguration angeben, wenn Sie Ihre Amazon MWAA-Umgebung erstellen oder aktualisieren. Die folgenden Einschränkungen gelten für Ihren benutzerdefinierten Domainnamen:

  • Der Wert sollte ein vollqualifizierter Domänenname (FQDN) ohne Protokoll oder Pfad sein. z. B. your-custom-domain.com.

  • Amazon MWAA erlaubt keinen Pfad in der URL. your-custom-domain.com/dags/Ist beispielsweise kein gültiger benutzerdefinierter Domainname.

  • Die URL-Länge ist auf 255 ASCII-Zeichen begrenzt.

  • Wenn Sie eine leere Zeichenfolge angeben, wird die Umgebung standardmäßig mit einer von Amazon MWAA generierten Webserver-URL erstellt.

Das folgende Beispiel zeigt die Verwendung von AWS CLI , um eine Umgebung mit einem benutzerdefinierten Webserver-Domänennamen zu erstellen.

$ aws mwaa create-environment \ --name my-mwaa-env \ --source-bucket-arn arn:aws:s3:::my-bucket \ --airflow-configuration-options '{"webserver.base_url":"my-custom-domain.com"}' \ --network-configuration '{"SubnetIds":["subnet-0123456789abcdef","subnet-fedcba9876543210"]}' \ --execution-role-arn arn:aws:iam::123456789012:role/my-execution-role

Nachdem die Umgebung erstellt oder aktualisiert wurde, müssen Sie die Netzwerkinfrastruktur in Ihrem AWS Konto einrichten, um über die benutzerdefinierte Domäne auf den privaten Webserver zuzugreifen.

Um zur standardmäßigen, vom Dienst generierten URL zurückzukehren, aktualisieren Sie Ihre private Umgebung und entfernen Sie die webserver.base_url Konfigurationsoption.

Richten Sie die Netzwerkinfrastruktur ein

Gehen Sie wie folgt vor, um die erforderliche Netzwerkinfrastruktur für die Verwendung mit Ihrer benutzerdefinierten Domain in Ihrem AWS Konto einzurichten.

  1. Rufen Sie die IP-Adressen für die Amazon VPC Endpoint Network Interfaces (ENI) ab. Verwenden Sie dazu zunächst, get-environmentum die WebserverVpcEndpointService für Ihre Umgebung geeigneten zu finden.

    $ aws mwaa get-environment --name your-environment-name

    Bei Erfolg erhalten Sie eine Ausgabe, die der folgenden ähnelt.

    {
        "Environment": {
            "AirflowConfigurationOptions": {},
            "AirflowVersion": "latest-version",
            "Arn": "environment-arn",
            "CreatedAt": "2024-06-01T01:00:00-00:00",
            "DagS3Path": "dags",
            .
            .
            .
            "WebserverVpcEndpointService": "web-server-vpc-endpoint-service",
            "WeeklyMaintenanceWindowStart": "TUE:21:30"
        }
    }

    Notieren Sie sich den WebserverVpcEndpointService Wert und verwenden Sie ihn für web-server-vpc-endpoint-service im folgenden Amazon EC2 describe-vpc-endpoints EC2-Befehl. --filters Name=service-name,Values=web-server-vpc-endpoint-service-idim folgenden Befehl.

  2. Rufen Sie die Amazon VPC-Endpunktdetails ab. Dieser Befehl ruft Details zu Amazon VPC-Endpunkten ab, die einem bestimmten Servicenamen entsprechen, und gibt die Endpunkt-ID und die zugehörigen Netzwerkschnittstellen-IDs in einem Textformat zurück.

    $ aws ec2 describe-vpc-endpoints \ --filters Name=service-name,Values=web-server-vpc-endpoint-service \ --query 'VpcEndpoints[*].{EndpointId:VpcEndpointId,NetworkInterfaceIds:NetworkInterfaceIds}' \ --output text
  3. Rufen Sie die Details der Netzwerkschnittstelle ab. Dieser Befehl ruft private IP-Adressen für jede Netzwerkschnittstelle ab, die den im vorherigen Schritt identifizierten Amazon VPC-Endpunkten zugeordnet ist.

    $ for eni_id in $( aws ec2 describe-vpc-endpoints \ --filters Name=service-name,Values=service-id \ --query 'VpcEndpoints[*].NetworkInterfaceIds' \ --output text ); do aws ec2 describe-network-interfaces \ --network-interface-ids $eni_id \ --query 'NetworkInterfaces[*].PrivateIpAddresses[*].PrivateIpAddress' \ --output text done
  4. Wird verwendetcreate-target-group, um eine neue Zielgruppe zu erstellen. Sie verwenden diese Zielgruppe, um die IP-Adressen für Ihre Webserver-Amazon-VPC-Endpunkte zu registrieren.

    $ aws elbv2 create-target-group \ --name new-target-group-namne \ --protocol HTTPS \ --port 443 \ --vpc-id web-server-vpc-id \ --target-type ip \ --health-check-protocol HTTPS \ --health-check-port 443 \ --health-check-path / \ --health-check-enabled \ --matcher 'HttpCode="200,302"'

    Registrieren Sie die IP-Adressen mit dem register-targets Befehl.

    $ aws elbv2 register-targets \ --target-group-arn target-group-arn \ --targets Id=ip-address-1 Id=ip-address-2
  5. Fordern Sie ein ACM-Zertifikat an. Überspringen Sie diesen Schritt, wenn Sie ein vorhandenes Zertifikat verwenden.

    $ aws acm request-certificate \ --domain-name my-custom-domain.com \ --validation-method DNS
  6. Konfigurieren Sie einen Application Load Balancer. Erstellen Sie zuerst den Load Balancer und dann einen Listener für den Load Balancer. Geben Sie das ACM-Zertifikat an, das Sie im vorherigen Schritt erstellt haben.

    $ aws elbv2 create-load-balancer \ --name my-mwaa-lb \ --type application \ --subnets subnet-id-1 subnet-id-2
    $ aws elbv2 create-listener \ --load-balancer-arn load-balancer-arn \ --protocol HTTPS \ --port 443 \ --ssl-policy ELBSecurityPolicy-2016-08 \ --certificates CertificateArn=acm-certificate-arn \ --default-actions Type=forward,TargetGroupArn=target-group-arn

    Wenn Sie einen Network Load Balancer in einem privaten Subnetz verwenden, richten Sie einen Bastion-Host oder AWS VPN Tunnel für den Zugriff auf den Webserver ein.

  7. Erstellen Sie eine gehostete Zone mithilfe von Route 53 für die Domäne.

    $ aws route53 create-hosted-zone --name my-custom-domain.com \ --caller-reference 1

    Erstellen Sie einen A-Eintrag für die Domain. Rufen Sie dazu mithilfe von die AWS CLI Hosting-Zonen-ID ab und wenden Sie list-hosted-zones-by-name dann den Datensatz mit anchange-resource-record-sets.

    $ HOSTED_ZONE_ID=$(aws route53 list-hosted-zones-by-name \ --dns-name my-custom-domain.com \ --query 'HostedZones[0].Id' --output text)
    $ aws route53 change-resource-record-sets \ --hosted-zone-id $HOSTED_ZONE_ID \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "my-custom-domain.com", "Type": "A", "AliasTarget": { "HostedZoneId": "load-balancer-hosted-zone-id>", "DNSName": "load-balancer-dns-name", "EvaluateTargetHealth": true } } } ] }'
  8. Aktualisieren Sie die Sicherheitsgruppenregeln für den Amazon VPC-Endpunkt des Webservers, sodass sie dem Prinzip der geringsten Rechte folgen, indem HTTPS-Verkehr nur aus den öffentlichen Subnetzen zugelassen wird, in denen sich der Application Load Balancer befindet. Speichern Sie die folgende JSON-Datei lokal. Zum Beispiel alssg-ingress-ip-permissions.json.

    { "IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "UserIdGroupPairs": [ { "GroupId": "load-balancer-security-group-id" } ], "IpRanges": [ { "CidrIp": "public-subnet-1-cidr" }, { "CidrIp": "public-subnet-2-cidr" } ] }

    Führen Sie den folgenden Amazon EC2 EC2-Befehl aus, um Ihre Ingress-Sicherheitsgruppenregeln zu aktualisieren. Geben Sie die JSON-Datei für an. --ip-permissions

    $ aws ec2 authorize-security-group-ingress \ --group-id <security-group-id> \ --ip-permissions file://sg-ingress-ip-permissions.json

    Führen Sie den folgenden Amazon EC2 EC2-Befehl aus, um Ihre Ausgangsregeln zu aktualisieren.

    $ aws ec2 authorize-security-group-egress \ --group-id webserver-vpc-endpoint-security-group-id \ --protocol tcp \ --port 443 \ --source-group load-balancer-security-group-id

Öffnen Sie die Amazon MWAA-Konsole und navigieren Sie zur Apache Airflow-Benutzeroberfläche. Wenn Sie anstelle des hier verwendeten Application Load Balancers einen Network Load Balancer in einem privaten Subnetz einrichten, müssen Sie mit einer der folgenden Optionen auf den Webserver zugreifen.