Azure Container Instance (ACI) — Installation Dynamics

1. Installation

Cette section décrit le déploiement de DQE Unify Server sur Azure Container Instances (ACI). La pile applicative — Redis, RabbitMQ, Nginx, Unify Server et Queue Worker — s'exécute en tant que Container Group Azure unique. Tous les conteneurs partagent le même espace de noms réseau et communiquent via localhost.

1.1 Prérequis

1.1.1 Configuration des ressources requises

Remarque : Ces estimations sont basées sur 1 million d'enregistrements. Selon le volume de données, il peut être nécessaire d'augmenter l'allocation mémoire du conteneur queue-worker.

1.1.2 Configuration logicielle requise

1.2 S'authentifier auprès du DQE Container Registry

Toutes les images (DQE Unify, Redis, RabbitMQ, Nginx) sont hébergées sur un Azure Container Registry privé. Utilisez les identifiants fournis par DQE Software pour vous connecter depuis votre terminal local :

az login
docker login <registry-url> --username <Username provided by DQE> --password <Password provided by DQE>

Une connexion réussie affiche : Login Succeeded.

Remarque : Les identifiants du registre sont également requis dans le fichier YAML du Container Group (section 1.7) afin qu'ACI puisse récupérer les images au moment du déploiement.

1.3 Configurer Azure Storage

Azure Container Instances ne prend pas en charge les bind mounts locaux. Les données persistantes de Redis et RabbitMQ doivent être stockées dans des Azure File Shares. Le fichier de configuration Nginx est également téléversé vers un file share afin que le conteneur puisse le monter au démarrage.

1. Étape 1 — Créer un compte de stockage :

   az storage account create \
     --name dqeunifystorage \
     --resource-group <resource-group> \
     --location <location> \
     --sku Standard_LRS

2. Étape 2 — Récupérer la clé du compte de stockage :

   az storage account keys list \
     --account-name dqeunifystorage \
     --resource-group <resource-group> \
     --query "[0].value" -o tsv

3. Étape 3 — Créer les file shares :

   az storage share create --name redisvol   --account-name dqeunifystorage
   az storage share create --name rabbitvol  --account-name dqeunifystorage
   az storage share create --name nginxconf  --account-name dqeunifystorage

1.4 Configurer Nginx

Nginx agit comme reverse proxy, redirigeant les requêtes HTTP/HTTPS entrantes vers le Unify Server. Dans ACI, tous les conteneurs partagent le même espace de noms réseau, la cible du proxy est donc http://localhost:8000 et non un nom de service.

Créez le fichier default.conf en local, puis téléversez-le vers l'Azure File Share.

Le fichier default.conf doit contenir :

server {
    listen 80;

    location / {
        proxy_pass         http://localhost:8000;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_read_timeout 300s;
    }
}

Téléverser vers l'Azure File Share :

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

HTTPS

Ajoutez un second server block et téléversez votre certificat SSL et votre clé privée vers le file share nginxconf. Mettez à jour le YAML du Container Group pour exposer le port 443.

server {
    listen 443 ssl;

    ssl_certificate      /etc/nginx/ssl/cert.crt;
    ssl_certificate_key  /etc/nginx/ssl/cert.key;

    location / {
        proxy_pass         http://localhost:8000;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_read_timeout 300s;
    }
}

Remarque : Téléversez les fichiers de certificat vers le file share nginxconf sous un sous-répertoire ssl/, et montez le share sur /etc/nginx/ssl dans la configuration du conteneur Nginx.

1.5 Configurer le Log Analytics Workspace

Un Log Analytics workspace centralise les logs des conteneurs et permet la supervision via Azure Monitor. L'ID et la clé du workspace sont référencés dans le YAML du Container Group (section 1.7).

1. Étape 1 — Créer un Log Analytics workspace :

   az monitor log-analytics workspace create \
     --resource-group <resource-group> \
     --workspace-name dqe-unify-logs \
     --location <location>

2. Étape 2 — Récupérer le Workspace ID :

   az monitor log-analytics workspace show \
     --resource-group <resource-group> \
     --workspace-name dqe-unify-logs \
     --query customerId -o tsv

3. Étape 3 — Récupérer la Workspace Primary Key :

   az monitor log-analytics workspace get-shared-keys \
     --resource-group <resource-group> \
     --workspace-name dqe-unify-logs \
     --query primarySharedKey -o tsv

Remarque : Conservez le Workspace ID et la Primary Key à portée de main — ils sont utilisés comme placeholders <workspace-id> et <workspace-key> dans le YAML du Container Group (section 1.7).

1.6 Configurer le réseau virtuel (VNET)

Le Container Group doit être déployé dans un réseau virtuel Azure afin de recevoir une adresse IP privée accessible depuis votre environnement Azure (backend Dynamics 365, DNS interne, Application Gateway). Le sous-réseau doit être explicitement délégué à Microsoft.ContainerInstance/containerGroups — il s'agit d'une exigence stricte pour l'intégration VNET d'ACI.

1. Étape 1 — Créer un réseau virtuel :

   az network vnet create \
     --name dqe-unify-vnet \
     --resource-group <resource-group> \
     --location <location> \
     --address-prefix 10.0.0.0/16

2. Étape 2 — Créer un sous-réseau délégué à ACI :

   az network vnet subnet create \
     --name dqe-unify-subnet \
     --vnet-name dqe-unify-vnet \
     --resource-group <resource-group> \
     --address-prefix 10.0.0.0/24 \
     --delegations Microsoft.ContainerInstance/containerGroups

3. Étape 3 — Récupérer l'ID de ressource complet du sous-réseau :

   az network vnet subnet show \
     --name dqe-unify-subnet \
     --vnet-name dqe-unify-vnet \
     --resource-group <resource-group> \
     --query id -o tsv

   La valeur retournée a la forme suivante :

   /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/dqe-unify-vnet/subnets/dqe-unify-subnet

   Conservez cette valeur — elle est utilisée comme placeholder subnetIds[0].id dans le YAML du Container Group (section 1.7).

Remarque : Un sous-réseau délégué à Microsoft.ContainerInstance/containerGroups ne peut héberger aucun autre type de ressource. Utilisez un sous-réseau dédié — un bloc /24 (256 adresses) est recommandé. ACI consomme une adresse IP par déploiement de container group.

Remarque : Si le client dispose déjà d'un VNET existant, ignorez les étapes 1 et 2 et créez le sous-réseau dédié au sein du VNET existant. Récupérez l'ID du sous-réseau avec l'étape 3.

1.7 Fichier de configuration du Container Group

Créez le fichier container-group.yaml avec le contenu ci-dessous. Remplacez tous les placeholders entre chevrons avant de déployer.

name: dqe-unify-aci
apiVersion: '2021-10-01'
location: <azure-region>

tags:
  docker-compose-application: docker-compose-application

properties:
  containers:
    - name: redis
      properties:
        image: <registry-url>/dqe-unify-redis:latest
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.5
        volumeMounts:
          - name: redisvol
            mountPath: /data

    - name: rabbitmq
      properties:
        image: <registry-url>/dqe-unify-rabbitmq:latest
        ports:
          - protocol: TCP
            port: 5672
        resources:
          requests:
            memoryInGB: 1
            cpu: 1
        volumeMounts:
          - name: rabbitvol
            mountPath: /bitnami
            readOnly: false

    - name: nginx
      properties:
        image: <registry-url>/dqe-unify-nginx:latest
        ports:
          - protocol: TCP
            port: 80
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.25
        volumeMounts:
          - name: nginxconf
            mountPath: /etc/nginx/conf.d

    - name: unify-server
      properties:
        image: <registry-url>/unify-server-web-ms-dynamics:<version>
        command: ["python", "-u", "app.pyc"]
        ports:
          - protocol: TCP
            port: 8000
        environmentVariables:
          - name: REDIS_URL
            value: redis://127.0.0.1:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@127.0.0.1:5672/
          - name: PORT
            value: 8000
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.25

    - name: queue-worker
      properties:
        image: <registry-url>/unify-server-web-ms-dynamics:<version>
        command: ["python", "-u", "queue_worker.pyc"]
        environmentVariables:
          - name: REDIS_URL
            value: redis://127.0.0.1:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@127.0.0.1:5672/
        resources:
          requests:
            memoryInGB: 5
            cpu: 1

  imageRegistryCredentials:
    - server: <registry-url>
      username: <registry-username>
      password: <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: rabbitvol
      azureFile:
        shareName: rabbitvol
        readOnly: false
        storageAccountName: <storage-account-name>
        storageAccountKey: <storage-account-key>

    - name: nginxconf
      azureFile:
        shareName: nginxconf
        readOnly: false
        storageAccountName: <storage-account-name>
        storageAccountKey: <storage-account-key>

    - name: redisvol
      azureFile:
        shareName: redisvol
        readOnly: false
        storageAccountName: <storage-account-name>
        storageAccountKey: <storage-account-key>

  subnetIds:
    - id: /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>

Points clés de configuration :

• Tous les conteneurs d'un Container Group ACI partagent le même espace de noms réseau — les services communiquent via localhost, et non via des noms de service.
• REDIS_URL et CLOUDAMQP_URL utilisent localhost à la place de redis et rabbitmq.
• L'image unify-server-web-ms-dynamics:v3.0 contient du bytecode Python compilé — le point d'entrée est app.pyc, et non app.py.
• RabbitMQ utilise l'image officielle avec des identifiants définis via des variables d'environnement. Le virtual host est / par défaut.
• Le bloc diagnostics.logAnalytics route l'ensemble des stdout/stderr des conteneurs vers le Log Analytics workspace. Les logs apparaissent dans Azure Monitor sous la table ContainerInstanceLog_CL quelques minutes après le déploiement.

1.8 Déployer l'application

1. Étape 1 — Déployer le Container Group :

   az container create \
     --resource-group <resource-group> \
     --file container-group.yaml

2. Étape 2 — Vérifier le statut du déploiement :

   az container show \
     --resource-group <resource-group> \
     --name dqe-unify \
     --query "instanceView.state" -o tsv

   Résultat attendu : Running.

3. Étape 3 — Récupérer l'adresse IP privée attribuée au Container Group :

   az container show \
     --resource-group <resource-group> \
     --name dqe-unify \
     --query "ipAddress.ip" -o tsv

   L'adresse IP retournée n'est accessible que depuis le réseau virtuel Azure ou depuis les réseaux connectés.

4. Étape 4 — Vérifier que tous les conteneurs sont en cours d'exécution :

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

   Résultat attendu : tous les conteneurs doivent afficher l'état Running :

   Name            State
   -----------     -------
   redis           Running
   rabbitmq        Running
   nginx           Running
   unify-server    Running
   queue-worker    Running

Important : Si un conteneur affiche l'état Terminated ou Waiting, consultez immédiatement ses logs : az container logs --resource-group <rg> --name dqe-unify --container-name <service-name>.

Remarque : ACI démarre tous les conteneurs simultanément. RabbitMQ et Redis peuvent nécessiter quelques secondes avant d'être prêts. Le Unify Server retentera automatiquement la connexion au démarrage.

1.9 Configurer le Network Security Group (NSG)

Si le Container Instance est déployé dans un réseau virtuel Azure, configurez le NSG associé pour autoriser le trafic entrant sur les ports requis.

1. Allez dans Azure Portal → Network Security Groups → [Votre NSG] → Inbound security rules.
2. Cliquez sur Add.
3. Définissez Destination port ranges : 80. Si HTTPS est activé via un reverse proxy externe ou une Application Gateway, des règles supplémentaires peuvent être nécessaires.
4. Définissez Protocol sur TCP et Action sur Allow.
5. Cliquez sur Add.

Remarque : Le port 8000 (Unify Server) et le port 5672 (RabbitMQ) sont internes au Container Group et n'ont pas besoin d'être exposés à l'extérieur.

Dynamics 365 — Autoriser les plages d'IP entrantes

Le DQE Unify Server reçoit des requêtes de Microsoft Dynamics 365, qui s'exécute sur l'infrastructure Azure. Vous devez autoriser les plages d'IP Azure correspondantes dans le NSG.

La liste complète et à jour des plages d'IP Microsoft Azure est disponible en téléchargement à l'adresse suivante :
Microsoft Azure IP Ranges and Service Tags

Téléchargez le fichier JSON, identifiez les service tags Dynamics365 et AzureCloud pertinents pour votre région, et ajoutez les plages d'IP correspondantes en tant que règles d'autorisation entrantes sur le port exposé par le reverse proxy ou l'Application Gateway (généralement le port 80 ou 443 selon la configuration de l'infrastructure). Vous pouvez également définir Source sur Service Tag et sélectionner directement Dynamics365 dans la règle NSG.

1.10 Configurer le DNS

Contactez vos administrateurs réseau ou DNS pour créer un enregistrement DNS interne pointant vers l'adresse IP privée du Container Group ou vers le nom d'hôte exposé par le reverse proxy/l'Application Gateway.

Vous pouvez également attribuer un DNS name label directement au Container Instance dans le Azure Portal : Azure Portal → Container Instances → [dqe-unify] → Overview → DNS name label. Cela donne un nom d'hôte de la forme dqe-unify.<location>.azurecontainer.io.

1.11 Vérifier le déploiement

Une fois le DNS propagé, ouvrez un navigateur et accédez à :

http://unify.yourdomain.com

Vous pouvez également tester directement à l'aide de l'IP publique :

curl http://<private-ip>

Réponse attendue du Unify Server :

{"status": "available"}

Si l'application répond, le déploiement est terminé et le serveur est correctement configuré.

2. Configuration de l'application

Une fois l'application en cours d'exécution, le NSG ainsi que tout pare-feu ou proxy en amont doivent être configurés pour autoriser les plages d'IP listées ci-dessous.

2.1 Adresses IP à autoriser

DQE Software Office Server

Contactez le support DQE Software pour obtenir l'adresse IP à autoriser.

DQE – Service de dédoublonnage

Contactez le support DQE Software pour obtenir l'adresse IP à autoriser.

DQE – Service de qualité

Contactez le support DQE Software pour obtenir l'adresse IP à autoriser.

Action requise : Communiquez à DQE Software l'adresse IP publique sortante utilisée par votre infrastructure Azure (NAT Gateway, Azure Firewall ou équivalent) afin qu'elle puisse être autorisée sur les services DQE.

Plages d'IP Azure — Dynamics 365 et services Azure

La liste complète et à jour des plages d'IP Microsoft Azure (IPv4 et IPv6) est disponible en téléchargement à l'adresse suivante :

Microsoft Azure IP Ranges and Service Tags

Téléchargez le fichier JSON et identifiez les service tags pertinents pour votre région (Dynamics365, AzureCloud). Ajoutez les plages d'IP correspondantes à vos règles entrantes NSG.