Notez que vous consultez actuellement la documentation de 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 de mon instance Looker change ?

Les administrateurs peuvent personnaliser le nom du domaine ou du nom d'hôte dans l'URL d'une instance Looker.

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

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

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

Les administrateurs d'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 dans laquelle l'instance est hébergée). Toutefois, certains ajouts ou modifications peuvent entraîner des coûts supplémentaires ou nécessiter des analyses intégrées. Contactez un spécialiste des ventes Google Cloud pour discuter des options disponibles pour votre déploiement de Looker.

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

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

Que dois-je savoir avant d'effectuer un changement d'URL ?

Dans la plupart des cas, si l'URL de l'instance change, un administrateur Looker doit mettre à jour le champ Host URL (URL de l'hôte) sur la page Settings (Paramètres) du panneau Admin avec la nouvelle URL. Si l'URL d'une instance change en raison d'une migration de Looker (version d'origine) 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, sans quoi vos utilisateurs risquent de se retrouver bloqués.

La modification de l'URL de l'instance peut entraîner une interruption de service momentanée. En fonction de votre déploiement, la mise à jour de l'URL hôte peut entraîner les modifications destructives suivantes.

Modification de l'instance	Exemple	Type de modification	Modification destructive
Passer de l'ancien hébergement sur Amazon EC2 à l'hébergement nouvelle génération sur Google Cloud ou Amazon EKS	De `company.looker.com` à `company.cloud.looker.com`	Modifie le sous-domaine	Les favoris des utilisateurs et des utilisateurs intégrés doivent mettre à jour leurs favoris dans un délai de sept jours, sans quoi leurs favoris ne fonctionneront plus. Les deux URL fonctionneront pendant sept jours après la modification. Si vous utilisez l'intégration Slack pour la diffusion de données, les envois de données envoyés par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Les planifications existantes et les distributions ad hoc envoyées par les utilisateurs déjà authentifiés dans l'espace de travail Slack ne sont pas affectées.
Passer de l'hébergement par le client à l'hébergement Looker	De `company.instance.com` à `company.cloud.looker.com`	Changement de domaine	Les favoris des utilisateurs et les utilisateurs de la fonctionnalité d'intégration doivent mettre à jour leurs favoris. Sinon, ceux-ci ne fonctionneront plus. La durée de fonctionnement de l'URL de l'instance hébergée par le client est laissée à la discrétion de l'entreprise. Si vous utilisez l'intégration Slack pour la diffusion de données, les envois de données envoyés par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Les planifications existantes et les distributions ad hoc envoyées par les utilisateurs déjà authentifiés dans l'espace de travail Slack ne sont pas affectées.
Migrer de Looker (version initiale) vers Looker (Google Cloud Core)	De `company.looker.com` à `hostname.looker.app`	Changement de domaine	Les favoris vers les instances Looker (version initiale) qui utilisent le domaine `looker.com` ne peuvent plus être conservés après la migration vers Looker (Google Cloud Core). Les utilisateurs et les utilisateurs de la fonctionnalité d'intégration doivent mettre à jour leurs favoris, sans quoi ceux-ci ne fonctionneront plus. Si vous passez d'une URL personnalisée pour Looker (version d'origine) (qui n'utilise pas le domaine `looker.com`) vers le même domaine personnalisé pour Looker (Google Cloud Core), les favoris devraient migrer sans interruption. Il existe quelques 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 récurrents. Consultez la documentation sur la migration pour en savoir plus sur la migration de Looker (version initiale) vers Looker (Google Cloud Core).
Modifier des régions hébergées AWS EC2	De `company.au.looker` à `company.jp.looker.com`	Modifie le sous-domaine	Les favoris des utilisateurs et des utilisateurs intégrés doivent mettre à jour leurs favoris dans un délai de sept jours, sans quoi leurs favoris ne fonctionneront plus. Les deux URL fonctionneront pendant sept jours après la modification. Si vous utilisez l'intégration Slack pour la diffusion de données, les envois de données envoyés par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Les planifications existantes et les distributions ad hoc envoyées par les utilisateurs déjà authentifiés dans l'espace de travail Slack ne sont pas affectées.
Changer l'ordre du domaine	De `example.looker.com` à `looker.example.com`	Changement de domaine	Les deux URL des instances fonctionneront indéfiniment. Si vous utilisez l'intégration Slack pour la diffusion de données, les envois de données envoyés par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Les planifications existantes et les distributions ad hoc envoyées par les utilisateurs déjà authentifiés dans l'espace de travail Slack ne sont pas affectées.
Passer à un domaine personnalisé	De `example.looker.com` à `example.custom.com`	Changement de domaine	Les deux URL des instances fonctionneront indéfiniment. Si vous utilisez l'intégration Slack pour la diffusion de données, les envois de données envoyés par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Les planifications existantes et les distributions ad hoc envoyées par les utilisateurs déjà authentifiés dans l'espace de travail Slack ne sont pas affectées.
Passer d'un hôte Looker à un autre	De `company1.cloud.looker.com` à `company2.cloud.looker.com`	Changement de domaine	Les favoris des utilisateurs et des utilisateurs intégrés doivent mettre à jour leurs favoris dans un délai de sept jours, sans quoi leurs favoris ne fonctionneront plus. Les deux URL fonctionneront pendant sept jours après la modification. Si vous utilisez l'intégration Slack pour la diffusion de données, les envois de données envoyés par des utilisateurs qui ne sont pas déjà connectés à Slack ne seront pas distribués. Les planifications existantes et les distributions ad hoc envoyées par les utilisateurs déjà authentifiés dans l'espace de travail Slack ne sont pas affectées. Les noms d'hôte des instances Looker ne peuvent contenir que des caractères alphanumériques et doivent comporter six caractères ou plus. Cela signifie qu'ils ne peuvent pas comporter de tirets, par exemple: customer-dev.looker.com.