GTM Server-Side sur Azure

Azure App Service offre un chemin de configuration moins complexe que AWS ECS Fargate pour GTM Server-Side, selon les praticiens de la communauté GTM, dont Simo Ahava, qui le décrit comme « le plus fluide et le plus rapide » parmi les trois principaux fournisseurs cloud.

L’image du conteneur GTM Server-Side (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable) fonctionne sans modification sur Azure avec les mêmes variables d’environnement qu’un déploiement Cloud Run. La couche d’hébergement Azure enveloppe le même conteneur.

App Service : l’option principale

App Service est la plateforme managée d’Azure pour l’hébergement d’applications web et de conteneurs. Pour GTM Server-Side, vous déployez deux instances App Service — une pour le serveur de tagging, une pour le serveur de preview — en utilisant la configuration de conteneur Docker.

App Services requis

Serveur de tagging — reçoit les hits entrants et les route vers les endpoints vendeurs :

# Configuration App Service
Name: gtm-tagging-server
Publish: Docker Container
Operating System: Linux
Region: westeurope  # ou votre région préférée

Container settings:
  Image Source: Docker Hub
  Image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
  Tag: stable

Application settings (variables d'environnement) :
  CONTAINER_CONFIG: [votre chaîne de configuration du conteneur GTM]
  PREVIEW_SERVER_URL: https://gtm-preview.yourdomain.com

Serveur de preview — l’interface de débogage utilisée pendant le développement du conteneur :

Name: gtm-preview-server
Container: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

Application settings:
  CONTAINER_CONFIG: [même chaîne de configuration]
  RUN_AS_PREVIEW_SERVER: "true"

Le serveur de preview peut fonctionner sur un niveau moins coûteux car il ne reçoit du trafic que des développeurs utilisant le mode preview de GTM, pas du trafic web de production.

Niveaux du plan de service

La tarification d’App Service est basée sur des niveaux, non sur la consommation. Vous sélectionnez un plan et le payez indépendamment de l’utilisation réelle :

Niveau	Coût mensuel	Idéal pour
B1 (Basic)	~13 $	Tests et développement uniquement
S1 (Standard)	~69 $	Production — minimum viable
P1V3 (Premium)	~124 $	Production avec auto-scaling
P2V3 (Premium)	~248 $	Workloads à trafic élevé

Le niveau B1 est sous-dimensionné pour la production — il dispose d’un CPU et d’une mémoire limités qui provoquent des timeouts sous une charge de trafic réelle. Pour la production, commencez au niveau S1.

Le niveau S1 à environ 69 $/mois pour une instance unique est compétitif par rapport à Cloud Run à des volumes de trafic comparables. Deux instances (tagging + preview) au niveau S1 reviennent à environ 138 $/mois — raisonnable pour les organisations payant déjà pour une infrastructure Azure.

Les niveaux Premium (P1V3 et supérieurs) permettent l’auto-scaling, laissant App Service ajouter des instances lorsque le trafic augmente et en réduire lors des périodes creuses. Pour les sites avec une variation significative du trafic entre les heures de pointe et les heures creuses, l’auto-scaling sur Premium peut être plus rentable que de payer pour une capacité always-on.

SSL et domaines personnalisés

Azure App Service dispose d’un bon support SSL managé pour les configurations de sous-domaines. La procédure :

Ajoutez votre domaine personnalisé dans les paramètres « Custom domains » de l’App Service
Créez un enregistrement CNAME : gtm.yourdomain.com → [votre-app-service].azurewebsites.net
Activez le certificat managé d’Azure (gratuit, renouvelé automatiquement)
Configurez le binding SSL sur SNI SSL

Une limitation : les certificats SSL managés fonctionnent simplement pour les sous-domaines mais nécessitent une configuration supplémentaire pour les domaines apex (le domaine racine sans www). Pour un serveur de tagging, vous utilisez presque toujours un sous-domaine, donc cette contrainte n’est pas pratiquement restrictive.

Déploiement depuis Azure CLI

# Créer un groupe de ressources
az group create \
  --name gtm-server-side \
  --location westeurope

# Créer un plan App Service (niveau Standard)
az appservice plan create \
  --name gtm-plan \
  --resource-group gtm-server-side \
  --is-linux \
  --sku S1

# Créer l'application du serveur de tagging
az webapp create \
  --resource-group gtm-server-side \
  --plan gtm-plan \
  --name gtm-tagging-server \
  --deployment-container-image-name gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

# Définir les variables d'environnement
az webapp config appsettings set \
  --resource-group gtm-server-side \
  --name gtm-tagging-server \
  --settings \
    CONTAINER_CONFIG="[votre-config-conteneur]" \
    PREVIEW_SERVER_URL="https://gtm-preview.yourdomain.com"

# Activer le déploiement continu depuis Docker Hub
az webapp config container set \
  --name gtm-tagging-server \
  --resource-group gtm-server-side \
  --docker-custom-image-name gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --enable-cd true

Le flag --enable-cd true configure un webhook pour que le conteneur se mette à jour automatiquement lorsque Google publie une nouvelle image stable — équivalent aux mises à jour automatiques d’images de Cloud Run.

Container Apps : l’alternative proche de Cloud Run

Azure Container Apps est la plateforme de conteneurs serverless d’Azure — plus proche du modèle d’exécution de Cloud Run qu’App Service. Elle scale en fonction du trafic HTTP (y compris le scale-to-zero), avec une tarification basée sur la consommation.

Pour GTM Server-Side, Container Apps offre une expérience plus proche de Cloud Run :

Scale automatiquement en fonction du volume de requêtes entrantes
Scale à zéro lors des périodes sans trafic (ce qui implique des cold starts — utilisez des réplicas minimaux pour éviter les événements perdus)
Tarification par requête plutôt que des coûts de niveau fixe

La configuration suit le même pattern — même image Docker, mêmes variables d’environnement — mais déployée via le type de ressource Container Apps plutôt qu’App Service.

Container Apps convient mieux qu’App Service si :

Votre trafic varie significativement et vous souhaitez une tarification basée sur la consommation
Vous préférez le modèle mental serverless aux plans managés
Vous voulez éviter de payer pour de la capacité idle sur les sites à faible trafic

App Service convient mieux si :

Vous souhaitez des coûts mensuels prévisibles indépendamment des variations du trafic
Votre organisation utilise déjà App Service pour d’autres workloads et préfère la cohérence
Vous êtes plus familier avec le modèle de configuration App Service

Azure Functions ne fonctionne pas

Comme AWS Lambda, Azure Functions est conçu pour des workloads de courte durée orientés événements. L’image GTM Server-Side exécute un serveur HTTP Node.js persistant — un modèle incompatible avec l’architecture d’invocation de Functions.

N’essayez pas d’exécuter le conteneur du serveur de tagging via Functions. Le serveur HTTP persistant ne démarrera pas correctement dans l’environnement d’exécution de Functions, et même si c’était le cas, Functions a des limites de durée d’exécution (10 minutes sur le plan Consumption, 60 minutes sur Premium) qui n’affectent pas un serveur de tagging typique mais créent une contrainte inutile.

Multi-région sur Azure

Le modèle de déploiement multi-région d’Azure utilise Traffic Manager ou Azure Front Door pour le routage global :

Déployer des instances App Service dans chaque région cible (par exemple westeurope et eastus)
Créer un plan App Service dans chaque région
Utiliser Azure Traffic Manager (routage basé sur DNS) ou Azure Front Door (routage CDN anycast) pour diriger les utilisateurs vers la région la plus proche

Azure Front Door est l’option la plus complète — il opère comme un CDN global avec WAF intégré, protection DDoS et intelligence de routage. Pour un déploiement GTM Server-Side qui nécessite aussi du géo-routage et l’optimisation des performances, Front Door apporte de la valeur au-delà de la simple distribution du trafic.

Traffic Manager est plus simple et moins cher pour le géo-routage pur sans capacités CDN.

Le point de décision

Choisissez Azure App Service lorsque l’organisation fonctionne déjà sur Azure : l’équipe connaît la plateforme, la facturation passe par les comptes Azure existants, et ajouter un compte GCP crée de la friction. La capacité technique est comparable à Cloud Run ; la friction pratique diffère.

Pour les organisations qui évaluent Azure spécifiquement pour l’hébergement GTM Server-Side sans infrastructure Azure existante, Cloud Run ou un provider managé comme Stape est un point de départ plus simple.