Notez que vous consultez la documentation de Looker. Pour accéder à la documentation Looker Studio, consultez 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 d'instance hébergées par Looker se présentent sous 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 commercial Google Cloud pour discuter des options disponibles pour votre déploiement Looker.

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

Migrez de l'ancien hébergement sur Amazon EC2 vers l'hébergement de 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 rediriger la configuration du fournisseur d'identité vers la nouvelle URL, sinon vos utilisateurs risquent d'être bloqués.

Une interruption de service momentanée 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 intégrés doivent mettre à jour leurs favoris, sinon ils ne fonctionneront plus. La durée de fonctionnement 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. 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 de Looker (version initiale) vers Looker (Google Cloud Core)	De `company.looker.com` à `hostname.looker.app`	Change de domaine	Les favoris des instances Looker (version initiale) 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 initiale) (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 nombre de différences de fonctionnalités entre Looker (version initiale) et Looker (Google Cloud Core). Passez en revue ces différences pour vous assurer que les fonctionnalités de Looker (Google Cloud Core) répondent à vos besoins. Pour en savoir plus sur la migration de Looker (version initiale) vers Looker (Google Cloud Core), consultez la documentation de migration.
Modifier les régions hébergées AWS EC2	De `company.au.looker` à `company.jp.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.
Modifier l'ordre du domaine	De `example.looker.com` à `looker.example.com`	Change de 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 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 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 doivent contenir que des caractères alphanumériques et doivent comporter au moins six caractères. Cela signifie qu'elles ne peuvent pas contenir de tirets, par exemple: customer-dev.looker.com.