Article publié en Novembre 2022 par Nicolas Chollet
Nous avons déjà rédigé ici un article d’introduction sur la manière de déployer un container server-side par défaut.
C’est extrêmement simple. Mais dans la réalité, ce n’est en général pas l’option choisie. En effet, par défaut le déploiement se fait sur App Engine, sur la région
us-central-1, ce qui n’est pas toujours ce que l’on souhaite.Dans cet article, nous allons voir comment déployer le conteneur GTM serveur sur App Engine en manuel, puis sur Cloud Run, et enfin comparer les 2 options.
Références
Les articles les plus complets sur le sujet sont, comme d’habitude, ceux de Simo Ahava. Cet article a plutôt un but pédagogique, de “vulgarisation”, et n’est pas aussi complet que les 2 articles ci-dessous, que je vous invite à consulter :
Provision Server-side Tagging Application Manually
A guide for how to manually provision or upgrade a Google Tag Manager server-side tagging server. This is particularly useful if you already have a Google Cloud Platform project, or if you want to choose the region where the application is created in.
https://www.simoahava.com/analytics/provision-server-side-tagging-application-manually/
#GTMTips: Setup A Google Tag Manager Server Using Cloud Run
While Google App Engine, the default implementation pattern of server-side Google Tag Manager, is straightforward to setup with the automatic provisioning steps, it's certainly not the only way to deploy the server. In fact, the manual setup guide gives you the details on how to deploy a Google Tag Manager Server in any environment that runs Docker.
https://www.simoahava.com/gtmtips/setup-google-tag-manager-server-cloud-run/
Notes préliminaires
Cet article est consacré au déploiement sur un environnement Google Cloud.
Notons que GTM server-side peut être déployé sur tout tout d’environnement, et aussi qu’il existe des services dédiés, qui vous feront gagner en temps et en énergie. En particulier, nous conseillons sans hésitation la solution Addingwell :
Addingwell : La meilleure infrastructure pour votre conteneur GTM server-side
L'évolution naturelle de votre tagging Quels sont les avantages d'exécuter un conteneur Google Tag Manager côté serveur au lieu d'exécuter les scripts de suivi directement à partir du navigateur ? Protégez vos cookies d'ITP Avec les cookies first-party de votre sous-domaine, vos cookies sont à l'abri des protections navigateur comme ITP.
https://www.addingwell.com/fr/
1. Pourquoi déployer avec App Engine en manuel ?
On peut vouloir faire le déploiement App Engine “manuellement”, essentiellement pour pouvoir choisir sa zone géographique. Il y a 2 raisons pour laquelle vous voudriez faire cela :
- Si vos utilisateurs ne sont pas aux US. Il est alors préférable de déployer sur une autre zone (Europe, Canada, etc..)
- A plusieurs reprises, et surtout en novembre 2022, la zone
us-central-1a connu des problèmes de capacité d’instances app engine.
1.1 Zoom sur les problèmes constatés en novembre 2022
A l’occasion du black Friday, Google a été court d’instances App Engine, et on se retrouve avec des soucis de capacité, qui génèrent des erreurs 500, et donc des pertes de données.
Par ailleurs il est ensuite impossible de relancer une config, car on reçoit un autre message d’erreur, de ce type:
Error Response: [9] An internal error occurred while processing task /app-engine-flex/flex_await_healthy/flex_await_healthy>2022-11-28T19:54:43.077Z27899.vt.0: The region us-east1 does not have enough resources available to fulfill the request. Please try again laterA la date de cet article (29 novembre 2022), le problème n’a pas été résolu
Il faut donc redéployer App Engine sur une autre région. Le problème est qu’un fois qu’App Engine a été déployé sur un projet GCP, on ne peut plus le changer de région.
Il faudra donc créer un nouveau projet GCP, déployer App Engine manuellement en choisissant la région, et rattacher votre conteneur GTM à cette nouvelle instance
1.2 Déployer App Engine manuellement
C’est assez simple. Et le mieux est de se référer à l’article de Simo Ahava cité plus haut. Mais en quelques étapes :
- Dans le conteneur GTM server, aller dans Admin → “Container Settings”
- Cliquer sur “set up container server”. Puis choisir “manuel”, et Récupérer la chaîne de caractères du “container config”
- Ensuite allez dans GCP, et créez un projet (voir cet article si besoin). Puis dans le shell, taper la commande suivante (elle va lancer un exécutable qui configure App Engine)
sqlgcloud config set project project ID
sqlbash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
Répondez aux questions, et en particulier choisissez la région lorsque la question est posée
Comme indiqué plus haut, si vous avez déjà déployé une instance app engine sur ce projet, vous ne pourrez pas changer de région. Il faudra donc crééer un nouveau projet GCP.
- Une fois que c’est bon, il vous reste à
- Setup un sous-domaine qui va pointer sur cette application
- Renseigner l’adresse de l’application dans votre container server
Ces 2 points ne sont pas détaillés ici, mais dans la méthode ci-dessous qui concerne Cloud run (c’est quasiment identique pour App Engine)
2. Déployer sur Cloud run
2.1 Déployer le serveur sur cloud run
L’alternative est donc de déployer sur cloud run. Pour cela :
- Placez vous sur le shell, et lancez l’application développée par Simo Ahava :
sqlbash -c "$(curl -fsSL https://raw.githubusercontent.com/sahava/sgtm-cloud-run-shell/main/cr-script.sh)"
- Répondez aux questions. En particulier la région et le “Container configuration” (que vous récupérez comme précédemment dans votre conteneur GTM). Pour “fetch existing configuration”, il faut répondre “no”.
Attention : si vous souhaitez utiliser le mapping des custom domains de cloud run, il faut sélectionner une région qui accepte ce service https://cloud.google.com/run/docs/mapping-custom-domains#run
- Une fois tout terminé, vous aurez alors votre URL de production, que vous pouvez tester en rajoutant /healthy à la fin. Du type :
https://gtm-server-prod-p35njb2d3a-nn.a.run.app/healthy
2.2 Mapper un custom domain
Il faut maintenant faire le lien entre votre custom domain (par exemple
https://tagging.unnest.co) et l’application créée précédemment.Le process est détaillé ici :
Mapping custom domains | Cloud Run Documentation | Google Cloud
You can set up a custom domain rather than the default address that Cloud Run provides for a deployed service. There are a couple of ways to set up a custom domain for a Cloud Run service: You can map multiple custom domains to the same Cloud Run service.
https://cloud.google.com/run/docs/mapping-custom-domains#console
- Aller sur la page
https://console.cloud.google.com/run/domains
- Choisissez le sevice à mapper:
- Vous serez amené sur une page sur laquelle vous devrez prouver que vous êtes le propriétaire du domaine. La méthode la plus classique étant d’ajouter une ligne à vos enregistrements DNS
- Faites la modifcation, et attendez un peu la propagation
- Continuer la configuration
- Mettez à nouveau à jour les DNS pour faire pointer le sous-domaine vers l’adresse indiquée par Google Cloud
- Ensuite, il faut attendre (potentiellement plusieurs heures),jusqu’à avoir ceci :
- Vous pouvez maintenant tester en allant sur votre url, par exemple
https://tracking.unnest.co/healthy
- Il ne vous reste plus qu’à indiquer le nom du sous-domaine dans l’interface GTM, et voilà
3. Conclusion : Cloud Run ou App Engine ?
On le voit avec ce tutoriel, il est aussi simple de déployer l’un que l’autre. Cependant, bien qu’App Engine soit le déploiement par défaut, il semble que les dernières études convergent pour indiquer que Cloud run est une meilleure option :
- A priori moins cher dans la plupart des configurations (120$/mois pour App Engine avec 3 serveurs, vs moins de 50$ pour un trafic raisonnable avec Cloud run)
- Les récents problèmes de capacité d’App Engine sont un énorme frein
- Cloud run permet une configuration plus avancée, en particulier avec du multi-région.
Tout cela va évoluer probablement dans les prochains mois. Il faut aussi garder en tête qu’il est possible de déployer GTM server dans n’importe quel environnement, et pas seulement chez Google.
Rappelons aussi qu’il existe des services dédiés, comme Addingwell, qui rendent tout cela considérablement plus simple, et particulier le load balancing et le suivi des erreurs.