- Serve traffic from multiple regions | Cloud Run Documentation | Google Cloud
- You can return faster responses to your users around the world by deploying services in multiple regions and routing your users to the nearest region. Deploying across multiple regions delivers low latency and higher availability in case of regional outages.
GCP a lancé la semaine dernière une fonctionnalité permettant d'utiliser Cloud Run sur plusieurs régions en une seule exécution.
Pour résumer brièvement le service multi-régions, imaginons par exemple que nous ayons les régions de Séoul, Londres et Las Vegas.
Auparavant, il fallait déployer plusieurs régions individuellement à l'aide de scripts. La nouvelle fonctionnalité permet de déployer plusieurs régions avec un seul script.
En fait, avant sa publication, j'avais beaucoup d'attentes pour cette fonctionnalité après avoir lu la documentation annonçant son arrivée, mais j'ai été un peu déçu.
Le déploiement à l'aide de scripts permettait déjà de déployer plusieurs éléments simultanément, et comme les opérations s'exécutent en parallèle, le temps n'est pas significativement différent, donc je n'avais pas de grandes attentes à ce niveau. Cependant, comme il s'agit d'un déploiement unique, il est impossible de définir des variables d'environnement différentes pour chaque région.
Par conséquent, j'utilisais souvent la fonctionnalité permettant à chaque instance Cloud Run d'utiliser des valeurs différentes pour se connecter à des bases de données ou à des instances GCS différentes, mais cette fonctionnalité a commencé à poser problème.
Le deuxième problème est que lorsque l'on répète le déploiement, on souhaite parfois supprimer les versions précédentes, mais cela ne peut pas être contrôlé individuellement. Les anciennes versions sont placées en lecture seule, ce qui empêche la suppression individuelle des anciennes versions.
Il y a plusieurs inconvénients, mais l'avantage est que l'on peut "regrouper" plusieurs instances Cloud Run.
Dans notre service, nous utilisons beaucoup Cloud Run et de nombreuses régions, donc nous avons actuellement environ 50 instances, et ce nombre pourrait atteindre 100 une fois que les tâches en cours seront terminées. En utilisant le service multi-régions, nous pouvons réduire ce nombre à 10 ou 20. (Il ne s'agit que de masquer les instances.)
Voici le script :
L'exécution de ce script effectue le déploiement comme suit :
Cloud Run
Cloud Run du même nom est déployé dans chaque région, et un dossier(?) du même nom est créé au niveau supérieur.
L'écran regroupé est le suivant :
Cloud Run - écran réduit
En fait, cela n'est pas très utile si le nombre d'instances est faible, mais si l'on suppose que le déploiement est effectué dans 40 régions, cela devient extrêmement utile. (Même si ce n'est pas forcément le cas ...)
Indiqué comme lecture seule.
Pour la plupart des fonctions, lorsqu'on essaie de modifier quelque chose, il est indiqué en lecture seule. La documentation indique que la fonctionnalité est fournie, mais il semble y avoir un problème avec l'API, car elle ne fonctionne pas correctement.
Voici l'emplacement de la documentation correspondante :
Voici la documentation concernant gcloud. Seules les versions alpha/bêta sont prises en charge pour le moment, la version officielle n'est pas prise en charge. De plus, l'option --regions mentionnée dans la documentation ci-dessus n'y figure pas. (Elle sera bientôt mise à jour ?)
Ce que je souhaite, c'est qu'au lieu de cela, le numéro de port soit fourni par défaut comme variable d'environnement, comme c'est le cas actuellement. Bien sûr, je sais que diverses informations sont fournies via le serveur de métadonnées, mais cela nécessite une récupération manuelle via Fetch, ce qui est gênant. (Et c'est aussi une ressource...)
Comme il s'agit d'une version préliminaire, cela s'améliorera certainement. (Se plaindre dès le lancement ...)
Commentaires0