Azure Container Instance (ACI) — Standalone-Installation

Stellen Sie DQE One Standalone als eigenständige Azure Container Instance (ACI)-Gruppe mit NGINX, Redis und PostgreSQL bereit, die über ein Application Gateway freigegeben wird.

Hinweis: Alle im Folgenden beschriebenen Elemente sind Empfehlungen von DQE, die auf Bereitstellungserfahrungen mit verschiedenen Kunden basieren. Der Kunde ist dafür verantwortlich, die Lösung in seine eigene Architektur zu integrieren. Ein mit dem Kundenkontext und der internen Infrastruktur vertrauter Architekt sollte die Empfehlungen von DQE mit der Kundeninfrastruktur abstimmen.

1. Architektur

Dieses Dokument beschreibt, wie das DQE One Standalone-Backend als Azure Container Instance (ACI)-Containergruppe bereitgestellt wird. Alle Container in der Gruppe teilen sich denselben Netzwerk-Namespace und kommunizieren über localhost. Ein Application Gateway stellt die Anwendung über HTTPS bereit und leitet den Datenverkehr über ein privates VNET an die ACI weiter.

Empfohlene Architektur

Internet (HTTPS port 443)
         |
Application Gateway (public IP + WAF)
         |
    Private VNET subnet
         |
ACI Container Group (private IP)
         |
    NGINX sidecar (port 443)
         |
  DQE One Standalone (port 8000, internal)
         |
  Redis - PostgreSQL (internal)

Sicherheitsmaßnahmen

• Application Gateway: beendet HTTPS und leitet den Datenverkehr über das private VNET an die ACI weiter. Verwenden Sie die WAF, um eingehende IP-Bereiche einzuschränken.
• VNET: isoliert die ACI vom direkten öffentlichen Internetzugang. Der gesamte Datenverkehr vom Application Gateway läuft über ein privates Subnetz.
• SSL-Zertifikat: wird auf Ebene des Application Gateway oder auf NGINX-Ebene innerhalb der ACI verwaltet.
• Geheimnisse (Secrets): Verwenden Sie secureValue in der YAML-Datei der Containergruppe für alle sensiblen Werte (Passwörter, Lizenzschlüssel, Verschlüsselungsschlüssel).

Empfohlene Dimensionierung

ACI-Containergruppen sind auf 4 vCPU und 16 GB Arbeitsspeicher pro Gruppe begrenzt.

2. Installation

2.1. Azure CLI

Azure CLI muss auf Ihrem lokalen Computer installiert sein.

Linux / macOS

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Windows

Siehe die Microsoft-Dokumentation.

2.2. Ein Application Gateway erstellen

Das Application Gateway macht die ACI über eine öffentliche IP-Adresse und einen DNS-Namen zugänglich. Es übernimmt außerdem die HTTPS-Terminierung und die IP-Filterung über die WAF.

Vollständige Konfigurationsdetails finden Sie in der Microsoft-Dokumentation zum Application Gateway.

Registerkarte „Basics“

Wählen Sie Ihr Abonnement, Ihre Ressourcengruppe und Ihre Region aus. Wählen Sie den Tarif WAF V2, um die Web Application Firewall zu aktivieren.

WAF-Richtlinie

Erstellen Sie über das Feld WAF policy eine neue WAF-Richtlinie. Verwenden Sie die WAF, um eingehende IP-Bereiche zu definieren, die berechtigt sind, das Application Gateway aufzurufen (zum Beispiel Ihr Unternehmensnetzwerk oder bestimmte Partner-IP-Bereiche).

VNET

Erstellen Sie über das Feld Virtual network ein neues virtuelles Netzwerk (VNET). Dieses VNET verbindet das Application Gateway mit der ACI. Der gesamte Datenverkehr zwischen beiden läuft über dieses private Netzwerk.

Frontends

Erstellen Sie eine neue öffentliche IP-Adresse. Dies ist die extern zugängliche IP-Adresse, die zur Weiterleitung des Datenverkehrs an die ACI verwendet wird.

Backends

Erstellen Sie einen neuen Backend-Pool. Lassen Sie ihn vorerst leer — die private IP-Adresse der ACI wird hinzugefügt, nachdem die ACI bereitgestellt wurde (Abschnitt 3.3).

Konfiguration — Routingregeln

Erstellen Sie eine Routingregel mit:

• Listener: HTTPS auf Port 443, mit Ihrem SSL-Zertifikat.
• Backend-Ziel: der oben erstellte Backend-Pool.
• Backend-Einstellung: HTTP auf Port 80 (der Datenverkehr zwischen dem Application Gateway und der ACI läuft über das private VNET und erfordert intern kein HTTPS).

Klicken Sie auf Review + create, um das Application Gateway bereitzustellen.

2.3. Ein VNET-Subnetz für die ACI hinzufügen

Erstellen Sie im in Abschnitt 2.2 erstellten VNET ein neues, der ACI gewidmetes Subnetz. Delegieren Sie dieses Subnetz an Microsoft.ContainerInstance/containerGroups.

Notieren Sie sich die vollständige Subnetz-Ressourcen-ID — sie wird in der YAML-Datei der Containergruppe benötigt:

/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

2.4. Azure Storage konfigurieren

ACI-Container verwenden Azure File Shares für persistenten Speicher. Erstellen Sie ein Speicherkonto und anschließend die folgenden Dateifreigaben:

Schritt 1 — Erstellen Sie das Speicherkonto:

az storage account create \
  --name MY_STORAGE_ACCOUNT \
  --resource-group MY_RESOURCE_GROUP \
  --location MY_LOCATION \
  --sku Standard_LRS

Schritt 2 — Rufen Sie den Speicherkontoschlüssel ab:

az storage account keys list \
  --account-name MY_STORAGE_ACCOUNT \
  --resource-group MY_RESOURCE_GROUP \
  --query "[0].value" -o tsv

Schritt 3 — Erstellen Sie die Dateifreigaben:

az storage share create --name nginxconf --account-name MY_STORAGE_ACCOUNT
az storage share create --name redisdata --account-name MY_STORAGE_ACCOUNT
az storage share create --name postgresdata --account-name MY_STORAGE_ACCOUNT

Hinweis zum PostgreSQL-Speicher: Azure File Shares verwenden das SMB-Protokoll, das möglicherweise nicht alle von PostgreSQL benötigten POSIX-Dateisystemoperationen unterstützt. Wenn der Container postgres nicht startet, finden Sie in Abschnitt 5 die empfohlene Alternative mit Azure Database for PostgreSQL.

2.5. Einen Log Analytics-Arbeitsbereich erstellen

Ein Log Analytics-Arbeitsbereich zentralisiert Container-Protokolle und ermöglicht die Überwachung über Azure Monitor. Protokolle werden standardmäßig 30 Tage lang gespeichert.

Schritt 1 — Erstellen Sie den Arbeitsbereich:

az monitor log-analytics workspace create \
  --resource-group MY_RESOURCE_GROUP \
  --workspace-name dqe-standalone-logs \
  --location MY_LOCATION

Schritt 2 — Rufen Sie die Workspace-ID ab:

az monitor log-analytics workspace show \
  --resource-group MY_RESOURCE_GROUP \
  --workspace-name dqe-standalone-logs \
  --query customerId -o tsv

Schritt 3 — Rufen Sie den primären Workspace-Schlüssel ab:

az monitor log-analytics workspace get-shared-keys \
  --resource-group MY_RESOURCE_GROUP \
  --workspace-name dqe-standalone-logs \
  --query primarySharedKey -o tsv

Bewahren Sie die Workspace-ID und den primären Schlüssel auf — sie werden in der YAML-Datei der Containergruppe benötigt (Abschnitt 2.7).

2.6. NGINX konfigurieren

NGINX fungiert als Reverse-Proxy innerhalb der ACI-Containergruppe und leitet eingehende Anfragen an den Container dqeone auf Port 8000 weiter. Da alle Container in einer ACI-Gruppe denselben Netzwerk-Namespace teilen, verwendet das Proxy-Ziel localhost.

Erstellen Sie eine Datei namens default.conf mit folgendem Inhalt:

server {
    listen 80;

    location / {
        proxy_pass         http://localhost:8000;
        proxy_read_timeout 300s;
    }
}

Wenn HTTPS direkt auf ACI-Ebene gehandhabt wird (ohne SSL-Offloading am Application Gateway), fügen Sie einen zweiten Server-Block für Port 443 hinzu und laden Sie die SSL-Zertifikats- und Schlüsseldateien in die Dateifreigabe nginxconf unter einem Unterverzeichnis ssl/ hoch.

Laden Sie default.conf in die Dateifreigabe nginxconf hoch:

az storage file upload \
  --account-name MY_STORAGE_ACCOUNT \
  --share-name nginxconf \
  --source ./default.conf \
  --path default.conf

2.7. YAML-Datei der Containergruppe

Erstellen Sie eine Datei namens container-group.yaml. Ersetzen Sie vor der Bereitstellung alle Platzhalter. Die folgende Tabelle listet alle erforderlichen Werte auf.

name: dqe-standalone
apiVersion: '2021-10-01'
location: MY_LOCATION
tags: {"docker-compose-application": "docker-compose-application"}

properties:
  containers:

    - name: nginx
      properties:
        image: nginx:latest
        ports:
          - protocol: TCP
            port: 80
        resources:
          requests:
            memoryInGB: 0.5
            cpu: 0.25
        volumeMounts:
          - name: nginxconf
            mountPath: /etc/nginx/conf.d

    - name: redis
      properties:
        image: dqeone.azurecr.io/dqe-one-redis:v1.0
        resources:
          requests:
            memoryInGB: 1.0
            cpu: 0.5
        volumeMounts:
          - name: redisdata
            mountPath: /data

    - name: postgres
      properties:
        image: dqeone.azurecr.io/dqe-one-postgres:v1.0
        resources:
          requests:
            memoryInGB: 1.0
            cpu: 0.5
        environmentVariables:
          - name: POSTGRES_USER
            value: dqeone
          - name: POSTGRES_PASSWORD
            secureValue: DATABASE_PASSWORD
          - name: POSTGRES_DB
            value: dqeone
        volumeMounts:
          - name: postgresdata
            mountPath: /var/lib/postgresql/data

    - name: dqeone
      properties:
        image: dqeone.azurecr.io/standalone:v1.4.0
        command:
          - "bash"
          - "./entrypoint.sh"
        ports:
          - protocol: TCP
            port: 8000
        resources:
          requests:
            memoryInGB: 2.0
            cpu: 1.0
        environmentVariables:
          - name: SFAPIVERSION
            value: v65.0
          - name: CREATE_SUPERUSER
            value: "true"
          - name: RUN_COLLECTSTATIC
            value: "false"
          - name: DQE_ONE_SERVER_ADMIN_USER
            value: ADMIN_USER
          - name: DQE_ONE_SERVER_ADMIN_PASSWORD
            secureValue: ADMIN_PASSWORD
          - name: DQE_CLIENT_LICENCE
            value: CLIENT_LICENCE
          - name: WEBSITE_HOSTNAME
            value: https://YOUR_DNS_NAME
          - name: SECRET_ENCRYPTION_KEY
            secureValue: SECRET_ENCRYPTION_KEY_VALUE
          - name: WAIT_HOSTS
            value: "localhost:6379"
          - name: WAIT_HOSTS_TIMEOUT
            value: "300"
          - name: WAIT_SLEEP_INTERVAL
            value: "5"
          - name: WAIT_HOST_CONNECT_TIMEOUT
            value: "30"
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: PORT
            value: "8000"
          - name: DEBUG
            value: "false"
          - name: DB_USER
            value: dqeone
          - name: DB_PASSWORD
            secureValue: DATABASE_PASSWORD
          - name: DB_NAME
            value: dqeone
          - name: DB_HOST
            value: localhost
          - name: DB_VOLUME_PATH
            value: ./db/
          - name: DB_MAX_CAPACITY
            value: "8000000000"
          - name: AUTHORIZED_SFTP_HOSTS
            value: AUTHORIZED_SFTP_HOSTS

  imageRegistryCredentials:
    - server: dqeone.azurecr.io
      username: DQE_REGISTRY_LOGIN
      password: DQE_REGISTRY_PASSWORD

  diagnostics:
    logAnalytics:
      workspaceId: LOG_ANALYTICS_WORKSPACE_ID
      workspaceKey: LOG_ANALYTICS_WORKSPACE_KEY

  restartPolicy: Always

  ipAddress:
    ports:
      - protocol: TCP
        port: 80
    type: Private

  osType: Linux

  volumes:
    - name: nginxconf
      azureFile:
        shareName: nginxconf
        readOnly: false
        storageAccountName: MY_STORAGE_ACCOUNT
        storageAccountKey: MY_STORAGE_ACCOUNT_KEY
    - name: redisdata
      azureFile:
        shareName: redisdata
        readOnly: false
        storageAccountName: MY_STORAGE_ACCOUNT
        storageAccountKey: MY_STORAGE_ACCOUNT_KEY
    - name: postgresdata
      azureFile:
        shareName: postgresdata
        readOnly: false
        storageAccountName: MY_STORAGE_ACCOUNT
        storageAccountKey: MY_STORAGE_ACCOUNT_KEY

  subnetIds:
    - id: SUBNET_RESOURCE_ID

Wichtig: Verwenden Sie die von DQE bereitgestellten Image-Versionen. Ersetzen Sie diese nicht durch das Tag latest.

Wichtiger Hinweis zum ACI-Networking: Alle Container teilen sich denselben Netzwerk-Namespace. Die Kommunikation zwischen den Containern erfolgt über localhost — deshalb ist REDIS_URL gleich redis://localhost:6379 und DB_HOST gleich localhost, im Gegensatz zu einem Docker-Compose-Setup, bei dem Dienstnamen verwendet werden.

2.8. Umgebungsvariablen

Wichtig: Der SECRET_ENCRYPTION_KEY muss einmalig generiert und für die gesamte Lebensdauer der Bereitstellung beibehalten werden. Um einen kompatiblen Schlüssel zu generieren:

python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

3. Start

3.1. Bei Azure anmelden

az login

3.2. Die Containergruppe bereitstellen

az container create -g MY_RESOURCE_GROUP -f container-group.yaml

Nachdem der Vorgang abgeschlossen ist, rufen Sie die der Containergruppe zugewiesene private IP-Adresse ab:

az container show \
  --resource-group MY_RESOURCE_GROUP \
  --name dqe-standalone \
  --query "ipAddress.ip" -o tsv

Diese private IP-Adresse ist nur innerhalb des Azure-VNET erreichbar.

3.3. Den Backend-Pool des Application Gateway einrichten

Nachdem die ACI bereitgestellt wurde, gehen Sie zu Azure Portal > Application Gateway > Backend pools > Ihr Backend-Pool > Edit.

Fügen Sie die in Schritt 3.2 abgerufene private IP-Adresse der ACI hinzu. Klicken Sie auf Save.

3.4. Den Health Probe des Application Gateway einrichten

Mit dem Health Probe kann das Application Gateway überprüfen, ob die Anwendung ausgeführt wird. Gehen Sie zu Azure Portal > Application Gateway > Health probes > Add.

Konfigurieren Sie den Probe so, dass er den Root-Pfad der Anwendung über HTTP aufruft. Klicken Sie auf Test. Wenn der Status Healthy anzeigt, ist die ACI korrekt konfiguriert und das Application Gateway kann Datenverkehr an sie weiterleiten.

Klicken Sie auf Add, um den Health Probe zu speichern.

3.5. DNS einrichten

Wenden Sie sich an Ihre DNS-Administratoren, um einen DNS-Eintrag zu erstellen, der auf die öffentliche IP-Adresse des Application Gateway verweist:

3.6. Überprüfen der Installation

Überprüfen Sie, ob alle Container ausgeführt werden:

az container show \
  --resource-group MY_RESOURCE_GROUP \
  --name dqe-standalone \
  --query "containers[].{Name:name, State:instanceView.currentState.state}" \
  -o table

Erwartete Ausgabe:

Name        State
--------    -------
nginx       Running
redis       Running
postgres    Running
dqeone      Running

Hinweis: ACI startet alle Container gleichzeitig. Der Mechanismus WAIT_HOSTS regelt die Startreihenfolge durch wiederholte Verbindungsversuche. Beim ersten Start ist eine Verzögerung von 1–2 Minuten zu erwarten, bevor die Anwendung vollständig betriebsbereit ist.

Sobald alle Container ausgeführt werden und die DNS-Änderung propagiert wurde, rufen Sie https://standalone.yourdomain.com auf.

4. Zu autorisierende IP-Adressen

Sobald die Anwendung ausgeführt wird, konfigurieren Sie die WAF oder die vorgeschaltete Firewall so, dass die folgenden eingehenden IP-Bereiche autorisiert werden:

• DQE Software Office Server: Wenden Sie sich an den DQE Software-Support, um die zu autorisierende IP-Adresse zu erhalten.
• DQE Deduplication Service: Wenden Sie sich an den DQE Software-Support, um die zu autorisierende IP-Adresse zu erhalten.
• DQE Quality Service: Wenden Sie sich an den DQE Software-Support, um die zu autorisierende IP-Adresse zu erhalten.

Erforderliche Maßnahme: Teilen Sie DQE Software die von Ihrer Azure-Infrastruktur verwendete ausgehende öffentliche IP-Adresse mit (NAT Gateway, Azure Firewall oder gleichwertig), damit diese für die DQE-Dienste autorisiert werden kann.

5. Fehlerbehebung

Container-Protokolle anzeigen

Container-Protokolle sind in Azure Monitor unter der Tabelle ContainerInstanceLog_CL verfügbar. Sie können sie auch direkt über die CLI abrufen:

az container logs \
  --resource-group MY_RESOURCE_GROUP \
  --name dqe-standalone \
  --container-name CONTAINER_NAME

Nicht autorisiert beim Abrufen von Images

Überprüfen Sie, dass:

• der Abschnitt imageRegistryCredentials den korrekten von DQE bereitgestellten Login und das Passwort enthält;
• alle Images auf die DQE-Produktionsregistry dqeone.azurecr.io verweisen;
• die Image-Versionen mit den von DQE bereitgestellten übereinstimmen.

PostgreSQL-Container startet nicht

Azure File Shares verwenden das SMB-Protokoll, das möglicherweise nicht die von PostgreSQL benötigten POSIX-Dateisystemoperationen unterstützt. Wenn der Container postgres wiederholt mit Berechtigungsfehlern neu startet, verwenden Sie stattdessen Azure Database for PostgreSQL — Flexible Server:

• Entfernen Sie den Container postgres und das Volume postgresdata aus der YAML-Datei.
• Setzen Sie DB_HOST auf den Hostnamen des verwalteten Servers (zum Beispiel: myserver.postgres.database.azure.com).
• Aktualisieren Sie DB_USER, DB_PASSWORD und DB_NAME, damit sie mit den Anmeldedaten des verwalteten Servers übereinstimmen.

Health Probe des Application Gateway schlägt fehl

Überprüfen Sie, dass:

• alle ACI-Container den Status Running anzeigen;
• der Backend-Pool die korrekte private IP-Adresse der ACI enthält;
• das Subnetz korrekt an Microsoft.ContainerInstance/containerGroups delegiert ist;
• die dem Subnetz zugeordnete NSG eingehenden Datenverkehr auf Port 80 vom Subnetz des Application Gateway zulässt.