Notez que vous consultez la documentation Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Cette page a été traduite par l'API Cloud Translation.

Que se passe-t-il si l'URL change pour mon instance Looker ?

Les administrateurs peuvent personnaliser le nom du domaine ou du nom d'hôte dans l'URL d'un compte Compute Engine.

Les URL d'instances hébergées par Looker prennent les formes suivantes:

https://<hostname>.<subdomain>.<domain>.com

http://<hostname>.<subdomain>.<domain>.com

Les administrateurs des instances hébergées par Looker peuvent modifier chaque composant de l'URL de l'instance (à l'exception du sous-domaine, le cas échéant, qui peut être déterminé par la région où l'instance est hébergée), mais certaines modifications ou ajouts peuvent entraîner des coûts supplémentaires ou nécessiter des données analytiques intégrées. Contactez un spécialiste des ventes Google Cloud pour discuter des options disponibles pour votre Déploiement de Looker.

Outre ces modifications, l'URL de l'instance peut également être affectée si votre déploiement:

Migration de l'ancien hébergement sur Amazon EC2 vers un hébergement nouvelle génération sur Google Cloud ou Amazon Elastic Kubernetes Service (EKS)
Migrer d'un déploiement hébergé par un client vers un déploiement hébergé par Looker
Migration de Looker (version initiale) vers Looker (Google Cloud Core)
Modifie la région hébergée AWS EC2 (ce qui peut modifier le sous-domaine, le cas échéant)

Que dois-je savoir avant de modifier une URL ?

Dans la plupart des cas, si l'URL de l'instance change, un administrateur Looker doit mettre à jour le champ URL de l'hôte sur la page Paramètres du panneau Administration avec la nouvelle URL. Si l'URL d'une instance change en raison d'une migration de Looker (version initiale) vers Looker (Google Cloud Core), l'option URL de l'hôte n'est pas disponible dans Looker (Google Cloud Core), et cette étape n'est pas nécessaire.

Si votre instance utilise une méthode d'authentification telle que SAML ou LDAP, vous devez faire pointer la configuration du fournisseur d'identité vers la nouvelle URL, sinon vos utilisateurs risque de perdre l'accès à votre compte.

Une interruption temporaire du service peut être associée à la modification de l'URL de l'instance. Selon votre déploiement, la modification de l'URL de l'hôte peut entraîner les modifications non rétrocompatibles suivantes.

Modification d'instance	Exemple	Type de modification	Modification destructive
Migrer de l'ancien hébergement sur Amazon EC2 vers l'hébergement de nouvelle génération sur Google Cloud ou Amazon EKS	De `company.looker.com` à `company.cloud.looker.com`	Sous-domaine modifié	Les utilisateurs et les utilisateurs intégrés doivent mettre à jour leurs favoris dans un délai de sept jours, faute de quoi ils ne fonctionneront plus. Les deux URL fonctionneront pendant sept jours après le changement. Si vous utilisez l'intégration Slack pour la diffusion de données, les diffusions envoyées par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas diffusées. Les planifications existantes et les envois ponctuels envoyés par des utilisateurs déjà authentifiés dans l'espace de travail Slack ne seront pas affectés.
Migrer d'un environnement hébergé par le client vers un environnement hébergé par Looker	De `company.instance.com` à `company.cloud.looker.com`	Change de domaine	Les utilisateurs et les utilisateurs ayant intégré l'élément doivent mettre à jour leurs favoris ou leurs favoris. sont endommagées. La durée d'utilisation de l'URL de l'instance hébergée par le client dépend de l'entreprise. Si vous utilisez l'intégration Slack pour la diffusion de données, les diffusions envoyées par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas diffusées. Planifications existantes et les livraisons ad hoc envoyées par des utilisateurs déjà authentifiés dans l'espace de travail Slack.
Migrer de Looker (version initiale) vers Looker (Google Cloud Core)	De `company.looker.com` à `hostname.looker.app`	Change de domaine	Les favoris vers les instances Looker (d'origine) qui utilisent le domaine `looker.com` ne peuvent pas être conservés après la migration vers Looker (Google Cloud Core). Les utilisateurs et les utilisateurs intégrés doivent mettre à jour leurs favoris, sinon ils ne fonctionneront plus. Si vous passez d'une URL personnalisée pour Looker (version d'origine) (qui n'utilise pas le domaine `looker.com`) au même domaine personnalisé pour Looker (Google Cloud Core), les favoris devraient être migrés sans interruption. Il existe un petit ensemble de différences de fonctionnalités entre Looker (version initiale) et Looker (Google Cloud Core). Examinez ces différences pour vous assurer que les fonctionnalités de Looker (Google Cloud Core) répondent à vos besoins actuels. Consultez la documentation sur la migration pour en savoir plus sur la migration de Looker (version initiale) vers Looker (Google Cloud Core).
Modifier les régions hébergées AWS EC2	De `company.au.looker` à `company.jp.looker.com`	Modifie le sous-domaine	Les utilisateurs et les utilisateurs disposant d'un accès intégré doivent mettre à jour leurs favoris dans un délai de sept jours, sinon leurs favoris ne fonctionneront plus. Les deux URL fonctionnent pour sept jours après la modification. Si vous utilisez l'intégration Slack pour la diffusion de données, les diffusions envoyées par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas diffusées. Les planifications existantes et les envois ponctuels envoyés par des utilisateurs déjà authentifiés dans l'espace de travail Slack ne seront pas affectés.
Changer l'ordre du domaine	De `example.looker.com` à `looker.example.com`	Modifie le domaine	Les deux URL d'instance fonctionneront indéfiniment. Si vous utilisez l'intégration Slack pour la diffusion de données, les diffusions envoyées par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas diffusées. Les planifications existantes et les envois ponctuels envoyés par des utilisateurs déjà authentifiés dans l'espace de travail Slack ne seront pas affectés.
Passer à un domaine personnalisé	De `example.looker.com` à `example.custom.com`	Change de domaine	Les deux URL d'instance fonctionneront indéfiniment. Si vous utilisez la Intégration de Slack pour les livraisons de données, toutes les livraisons envoyées par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Planifications existantes et les livraisons ad hoc envoyées par des utilisateurs déjà authentifiés dans l'espace de travail Slack.
Passer d'un hôte Looker à un autre	De `company1.cloud.looker.com` à `company2.cloud.looker.com`	Change de domaine	Les utilisateurs et les utilisateurs intégrés doivent mettre à jour leurs favoris dans un délai de sept jours, faute de quoi ils ne fonctionneront plus. Les deux URL fonctionneront pendant sept jours après le changement. Si vous utilisez l'intégration Slack pour la diffusion de données, les diffusions envoyées par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas diffusées. Les planifications existantes et les envois ponctuels envoyés par des utilisateurs déjà authentifiés dans l'espace de travail Slack ne seront pas affectés. Les noms d'hôte des instances Looker ne peuvent contenir que des caractères alphanumériques et doivent comporter au moins six caractères. Cela signifie que ils ne peuvent pas avoir de tirets, par exemple: customer-dev.looker.com.