Azure Container Instance (ACI) — DQE One Standalone-Installation

Stellen Sie DQE One Standalone auf Azure Container Instance (ACI) für Microsoft-Dynamics-Umgebungen bereit, wobei eine verwaltete Azure Database for PostgreSQL anstelle eines Datenbank-Containers verwendet wird.

Hinweis: Alle nachfolgend beschriebenen Elemente sind Empfehlungen von DQE, die auf Erfahrungen aus Implementierungen bei 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 an die Infrastruktur des Kunden anpassen.

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 macht die Anwendung über HTTPS verfügbar 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 80, internal)
         |
  DQE One Standalone (port 8000, internal)
         |
       Redis (internal)
         |
Azure Database for PostgreSQL (private VNET)

Sicherheitsmaßnahmen

• Application Gateway: terminiert 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.
• 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.

PostgreSQL wird auf Azure Database for PostgreSQL gehostet (außerhalb der ACI-Containergruppe). Die Einrichtung ist in Abschnitt 2.5 beschrieben.

2. Installation

2.1. Azure CLI

Die Azure CLI muss auf Ihrem lokalen Rechner 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.

Ausführliche Konfigurationsdetails finden Sie in der Microsoft-Dokumentation zu Application Gateway.

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

WAF Policy
Erstellen Sie über das Feld WAF policy eine neue WAF-Richtlinie. Verwenden Sie die WAF, um die eingehenden IP-Bereiche festzulegen, die zum Aufruf des Application Gateway berechtigt sind.

VNET
Erstellen Sie über das Feld Virtual network ein neues Virtual Network (VNET). Dieses VNET verbindet das Application Gateway mit der ACI.

Frontends
Erstellen Sie eine neue öffentliche IP-Adresse. Dies ist die extern zugängliche IP-Adresse, über die der Datenverkehr an die ACI weitergeleitet wird.

Backends
Erstellen Sie einen neuen Backend-Pool. Lassen Sie ihn vorerst leer — die private IP-Adresse der ACI wird nach der Bereitstellung der ACI hinzugefügt (Abschnitt 3.3).

Configuration — Routing Rules
Erstellen Sie eine Routingregel mit:

• Listener: HTTPS auf Port 443, mit Ihrem SSL-Zertifikat.
• Backend target: der oben erstellte Backend-Pool.
• Backend setting: 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 in dem in Abschnitt 2.2 erstellten VNET ein neues, der ACI vorbehaltenes Subnetz. Delegieren Sie dieses Subnetz an Microsoft.ContainerInstance/containerGroups.

az network vnet subnet create \
  --resource-group MY_RESOURCE_GROUP \
  --vnet-name VNET_NAME \
  --name aci-subnet \
  --address-prefixes 10.0.1.0/24 \
  --delegations Microsoft.ContainerInstance/containerGroups

Notieren Sie sich die vollständige Ressourcen-ID des Subnetzes — 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 — Speicherkonto erstellen:

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

Schritt 2 — Speicherkontoschlüssel abrufen:

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

Schritt 3 — Dateifreigaben erstellen:

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

2.5. Azure Database for PostgreSQL erstellen

PostgreSQL wird als verwalteter Azure-Dienst außerhalb der ACI-Containergruppe gehostet. Azure File Shares (SMB) unterstützen nicht die von PostgreSQL benötigten POSIX-Dateisystemoperationen und führen zu einem CrashLoopBackOff.

Schritt 1 — Ein dediziertes Subnetz für PostgreSQL erstellen

Fügen Sie dem in Abschnitt 2.2 erstellten VNET ein neues Subnetz hinzu (z. B. postgres-subnet). Delegieren Sie es an Microsoft.DBforPostgreSQL/flexibleServers. Dieses Subnetz darf nicht mit dem ACI-Subnetz geteilt werden.

az network vnet subnet create \
  --resource-group MY_RESOURCE_GROUP \
  --vnet-name VNET_NAME \
  --name postgres-subnet \
  --address-prefixes 10.0.2.0/24 \
  --delegations Microsoft.DBforPostgreSQL/flexibleServers

Schritt 2 — Den Server erstellen

Erstellen Sie im Azure-Portal eine Azure Database for PostgreSQL-Ressource:

• Networking: wählen Sie Private access (VNet Integration).
• Virtual network: wählen Sie dasselbe VNet wie die ACI. Die ACI und der Server müssen dasselbe VNet verwenden.
• Subnet: wählen Sie das in Schritt 1 erstellte Subnetz.
• Admin username / password: legen Sie die Anmeldedaten fest. Diese Werte werden in DB_USER und DB_PASSWORD in der YAML-Datei der Containergruppe verwendet.

az postgres flexible-server create \
  --resource-group MY_RESOURCE_GROUP \
  --name SERVERNAME \
  --location MY_LOCATION \
  --vnet VNET_NAME \
  --subnet postgres-subnet \
  --admin-user DB_ADMIN_USER \
  --admin-password "DB_ADMIN_PASSWORD" \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --version 16

Schritt 3 — Die Anwendungsdatenbank erstellen

Navigieren Sie im Azure-Portal zur Azure Database for PostgreSQL-Ressource → Databases → + Add, geben Sie dqeone als Namen ein und speichern Sie.

az postgres flexible-server db create \
  --resource-group MY_RESOURCE_GROUP \
  --server-name SERVERNAME \
  --database-name dqeone

2.6. Einen Log Analytics-Arbeitsbereich erstellen

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

Schritt 1 — Den Arbeitsbereich erstellen:

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

Schritt 2 — Die Workspace-ID abrufen:

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

Schritt 3 — Den primären Workspace-Schlüssel abrufen:

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.8).

2.7. NGINX konfigurieren

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

Erstellen Sie eine Datei mit dem Namen default.conf und folgendem Inhalt:

server {
    listen 80;

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

Wenn HTTPS direkt auf ACI-Ebene verarbeitet wird (ohne SSL-Offloading durch das Application Gateway), fügen Sie einen zweiten server-Block für Port 443 hinzu und laden Sie die SSL-Zertifikats- und Schlüsseldateien in einem ssl/-Unterverzeichnis in die Dateifreigabe nginxconf 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.8. YAML-Datei der Containergruppe

Erstellen Sie eine Datei mit dem Namen container-group.yaml. Ersetzen Sie alle Platzhalter, bevor Sie die Bereitstellung durchführen.

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

properties:
  containers:

    - name: nginx
      properties:
        image: dqeone.azurecr.io/dqe-one-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: 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: DQE_ADMIN_USER
          - name: DQE_ONE_SERVER_ADMIN_PASSWORD
            secureValue: DQE_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: DB_ADMIN_USER
          - name: DB_PASSWORD
            secureValue: DB_ADMIN_PASSWORD
          - name: DB_NAME
            value: dqeone
          - name: DB_HOST
            value: SERVERNAME.postgres.database.azure.com
          - name: DB_PORT
            value: "5432"
          - name: DB_VOLUME_PATH
            value: ./db/
          - name: DB_MAX_CAPACITY
            value: "8000000000"
          - name: AUTHORIZED_SFTP_HOSTS
            value: AUTHORIZED_SFTP_HOSTS
          # Only required if WEBSITE_HOSTNAME does not match the URL used to access the app:
          # - name: CSRF_TRUSTED_ORIGINS
          #   value: https://YOUR_IP_OR_ALTERNATE_URL

  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

  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-Netzwerk: Alle Container der Gruppe teilen sich denselben Netzwerk-Namespace. Die Kommunikation zwischen den Containern erfolgt über localhost — deshalb lautet REDIS_URL redis://localhost:6379. PostgreSQL läuft außerhalb der Containergruppe als verwalteter Azure-Dienst, weshalb DB_HOST der FQDN von Azure Database for PostgreSQL ist.

2.9. Umgebungsvariablen

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

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

Rufen Sie nach Abschluss des Vorgangs 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

Navigieren Sie nach der Bereitstellung der ACI 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 Application Gateway Health Probe einrichten

Der Health Probe ermöglicht es dem Application Gateway zu überprüfen, ob die Anwendung läuft. Navigieren 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. Die Installation überprüfen

Überprüfen Sie, dass 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
dqeone    Running

Hinweis: Die ACI startet alle Container gleichzeitig. Der WAIT_HOSTS-Mechanismus regelt die Startreihenfolge, indem die Verbindung wiederholt versucht wird. Beim ersten Start ist eine Verzögerung von 1–2 Minuten zu erwarten, bevor die Anwendung vollständig einsatzbereit ist.

Sobald alle Container ausgeführt werden und die DNS-Änderungen verbreitet wurden, rufen Sie https://standalone.yourdomain.com auf.

4. Zu autorisierende IP-Adressen

Sobald die Anwendung läuft, konfigurieren Sie die WAF oder die vorgelagerte 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 Äquivalent), damit diese für die DQE-Dienste autorisiert werden kann.

5. Fehlerbehebung

Container-Logs anzeigen

Container-Logs sind in Azure Monitor in 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 Folgendes:

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

PostgreSQL-Einrichtung

Das vollständige Einrichtungsverfahren finden Sie in Abschnitt 2.5. Wichtige Punkte:

• Der Server muss sich im selben VNet wie die ACI befinden — unterschiedliche VNets erfordern Peering und die Konfiguration einer DNS-Zone.
• Azure Database for PostgreSQL erfordert ein dediziertes Subnetz, das an Microsoft.DBforPostgreSQL/flexibleServers delegiert ist.
• Erstellen Sie nach der Servererstellung die Datenbank dqeone über das Azure-Portal: Azure Database for PostgreSQL → Databases → + Add.
• Alle DB_*-Umgebungsvariablen müssen vor der ersten Bereitstellung in der YAML-Datei der Containergruppe gesetzt werden — siehe Abschnitt 2.8.

CSRF-Überprüfung fehlgeschlagen (403)

Django überprüft, dass eingehende Anfragen von einem vertrauenswürdigen Ursprung stammen, der mit WEBSITE_HOSTNAME übereinstimmt. Ein 403-CSRF-Fehler tritt auf, wenn auf die Anwendung über eine URL zugegriffen wird, die vom konfigurierten Hostnamen abweicht.

Dauerhafte Lösung: Konfigurieren Sie DNS so, dass der Hostname in WEBSITE_HOSTNAME zur öffentlichen IP-Adresse des Application Gateway aufgelöst wird.

Vorübergehende Umgehungslösung (Test ohne DNS): Setzen Sie WEBSITE_HOSTNAME auf die IP-Adresse und fügen Sie CSRF_TRUSTED_ORIGINS hinzu:

- name: WEBSITE_HOSTNAME
  value: https://YOUR_GATEWAY_IP
- name: CSRF_TRUSTED_ORIGINS
  value: https://YOUR_GATEWAY_IP

Sobald DNS konfiguriert ist, setzen Sie beide Werte wieder auf den korrekten Domainnamen zurück.

Application Gateway Health Probe schlägt fehl

Überprüfen Sie Folgendes:

• 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.