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.

Migration en libre-service de Looker (version initiale) vers Looker (Google Cloud Core)

Ce document décrit les étapes techniques à suivre pour migrer votre instance Looker existante de l'environnement Looker (version initiale) vers Looker (Google Cloud Core).

Looker (Google Cloud Core) est un environnement de déploiement qui s'intègre parfaitement à Google Cloud Platform. Looker (Google Cloud Core) est hébergé sur l'infrastructure Google Cloud. Vous pouvez le gérer directement via la console Google Cloud. De plus, ce service s'intègre en profondeur à de nombreux autres produits, services et fonctionnalités de Google Cloud.

Avant de commencer

Familiarisez-vous avec les principes et les outils Google Cloud en consultant la documentation suivante:

Contactez votre responsable de compte pour effectuer la migration et savoir si votre instance Looker (version d'origine) est éligible. Si votre instance est éligible et que vous avez mis à niveau votre contrat Looker (initial) existant pour couvrir Looker (Google Cloud Core), vous pouvez suivre la procédure décrite dans ce document pour migrer votre instance.
Pour obtenir les autorisations dont vous avez besoin pour préparer la migration, demandez à votre administrateur de vous attribuer les rôles IAM suivants sur le projet Google Cloud dans lequel résidera l'instance Looker (Google Cloud Core) :
- Créez une instance Looker (Google Cloud Core) : Administrateur Looker (roles/looker.admin).
- Attribuez des rôles IAM dans votre projet Google Cloud : Administrateur IAM de projet (roles/resourcemanager.projectIamAdmin).
- Créez un bucket Cloud Storage : Administrateur Storage (roles/storage.admin).
Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.
Pour gérer l'instance Looker (d'origine) en vue de la migration, vous devez disposer du rôle Looker Administrateur dans cette instance.
Créez une instance Looker (Google Cloud Core) "vide".

Veillez à sélectionner l'édition, le type de connexion réseau (adresse IP publique ou adresse IP privée) et les autres attributs de configuration (CMEK, VPC-SC) appropriés pour votre nouvelle instance Looker (Google Cloud Core) afin de vous assurer qu'elle dispose des fonctionnalités nécessaires. Certaines fonctionnalités de Looker (Google Cloud Core) dépendent de l'édition sélectionnée ou du type de réseau sélectionné.

Laissez l'instance"vide" ; ne la remplissez pas avec des données telles que des fichiers de modèle, des utilisateurs, des connexions, des explorations, des tableaux de bord ou des dossiers. Au cours de l'étape d'importation, tous les paramètres ou contenus sont supprimés et remplacés par les données issues de la migration.

Toutefois, les attributs de configuration de Looker (Google Cloud Core) spécifiés via la console Google Cloud ou qui ne peuvent être spécifiés que lors de la création de l'instance ne sont pas écrasés lors du processus de migration.

Présentation

De manière générale, le processus de migration comprend les étapes suivantes.

Assurez-vous que votre instance Looker (d'origine) est prête pour la migration.
Exportez les données depuis votre instance Looker (originale).
Importez les données dans la nouvelle instance Looker (Google Cloud Core) "vide".
Finalisez la configuration de l'instance Looker (Google Cloud Core).
Mettez hors service l'instance Looker (version initiale).

Les sections suivantes fournissent des détails sur chacune de ces étapes.

Assurez-vous que votre instance Looker (d'origine) est prête pour la migration

Votre instance Looker (originale) doit remplir les conditions préalables suivantes pour pouvoir être migrée:

Votre instance Looker (originale) doit être gérée par Google (et non hébergée par le client) et hébergée sur Google Cloud ou Amazon Web Services.
Votre instance Looker (originale) doit utiliser une version disponible dans une publication mensuelle de la version actuelle de Looker (Google Cloud Core). Pour connaître la version actuelle de Looker (Google Cloud Core), consultez les notes de version de Looker et la dernière annonce de déploiement.

Remarque :Les instances Looker (originales) du programme Extended Support Release (ESR) ne peuvent pas être migrées tant qu'elles n'ont pas été mises à niveau vers une version compatible.

En outre, effectuez les activités suivantes avant la migration:

Il existe de légères 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.

Conseil :Nous vous recommandons de désactiver les fonctionnalités de votre instance Looker (version d'origine) qui n'ont pas d'équivalent dans Looker (Google Cloud Core), par exemple les anciennes fonctionnalités et les fonctionnalités de l'atelier, pendant un certain temps avant la migration, afin de vous assurer que vous pourrez vous en passer.
La migration copie tous les projets en mode Production et les fichiers de modèle qu'ils contiennent, mais pas les projets en mode Développement qui appartiennent à des utilisateurs individuels. Pour vous assurer que les fichiers en mode Développement sont transférés lors de la migration, vous devez valider tous les fichiers de tous les projets en mode Développement dans des dépôts Git avant de lancer la migration.

Remarque :Si votre instance utilise des dépôts simples, ils seront copiés dans l'instance Looker (Google Cloud Core), et non partagés entre les instances Looker (version initiale) et Looker (Google Cloud Core).
Looker (Google Cloud Core) n'est compatible qu'avec les méthodes d'authentification Google OAuth, SAML et OpenID Connect.
- Si votre instance Looker (d'origine) utilise une autre méthode d'authentification (par exemple, adresse e-mail et mot de passe, LDAP, etc.), vous devrez convertir tous les utilisateurs vers une méthode d'authentification compatible avec Looker (Google Cloud Core).
- Si votre instance Looker (d'origine) utilise déjà Google OAuth, tous les enregistrements utilisateur seront transférés. Toutefois, vous devrez toujours créer manuellement des autorisations IAM pour les utilisateurs du projet de votre instance Looker (Google Cloud Core).
- Si votre instance Looker (d'origine) utilise SAML, le paramètre Fusionner les utilisateurs avec sur la page du panneau d'administration Authentification SAML doit être défini sur Google ou OIDC pour éviter une erreur lorsque vous testez l'authentification SAML.
- Si votre instance Looker (d'origine) utilise OIDC, le paramètre Fusionner les utilisateurs avec sur la page du panneau d'administration OpenID Connect authentication (Authentification OpenID Connect) doit être défini sur Google ou SAML pour éviter une erreur lorsque vous testez l'authentification OpenID Connect.
- Si vous utilisez un fournisseur d'identité externe, vous devez remplacer l'URL de rappel de votre fournisseur d'identité par l'URL Looker (Google Cloud Core) pour autoriser l'authentification sur la nouvelle instance Looker (Google Cloud Core).
- Si votre instance Looker (Google Cloud Core) utilise SAML ou OpenID Connect comme méthode d'authentification, nous vous recommandons de configurer également Google OAuth, qui servira de méthode d'authentification de secours pour Looker (Google Cloud Core).
- Si vous prévoyez d'utiliser un domaine personnalisé avec votre instance Looker (Google Cloud Core), ne configurez pas SAML ni OpenID Connect pour l'instance tant que le domaine personnalisé n'est pas activé.
Pendant la migration, deux instances Looker, une instance Looker (version initiale) et une instance Looker (Google Cloud Core), s'exécuteront en parallèle pendant un certain temps. Toute activité automatique ayant lieu (telle que les alertes et les rapports planifiés, ainsi que l'activité en arrière-plan qui accède aux bases de données backend) peut être dupliquée. Pour éviter les activités en double, supprimez les alertes et les planifications automatiques dans l'instance Looker (version d'origine) ou Looker (Google Cloud Core).

Exporter les données depuis votre instance Looker (version initiale)

L'exportation des données à partir de vos instances Looker (version initiale) nécessite deux étapes:

Créez un emplacement de stockage pour les données de migration.
Lancez l'exportation.

Créer un emplacement pour stocker les données de migration

Effectuez toutes les opérations suivantes dans le projet Google Cloud où vous avez créé l'instance Looker (Google Cloud Core).

Créez un bucket Cloud Storage (par exemple, <bucket-name>).
- Ce bucket servira à stocker les données de migration.
- Suivez les instructions de la page de documentation Créer des buckets.
- Notez que la valeur de <bucket-name> doit être unique dans Google Cloud. Nous vous recommandons de préfixer le nom du bucket par un identifiant unique, tel que l'ID de votre projet.
Choisissez le nom d'un dossier dans le bucket Cloud Storage (par exemple, <folder-name>). Ne créez pas le dossier maintenant. Indiquez le nom du dossier lors de la demande d'exportation. Il sera créé automatiquement lors du processus d'exportation.
Créez un trousseau de clés et une clé dans Cloud KMS (par exemple, <kms_keyring_id> et <kms-key-id>).
- Cette clé sera utilisée pour chiffrer les données de migration. Étant donné qu'il s'agit d'une clé KMS, vous ne devez divulguer que le nom de la clé, et non la clé elle-même, à la page Exporter dans le panneau Administration de Looker (d'origine).
- Suivez les instructions des pages de documentation Créer un trousseau et Créer une clé.
Créez un compte de service spécifique à la migration (par exemple, <export-service-account>).
- Il ne s'agit pas du même compte de service que le compte de service Looker.
- Suivez les instructions de la page de documentation Créer des comptes de service.
Attribuez à <export-service-account> deux rôles IAM spécifiques:
- Storage Object Creator sur le bucket Cloud Storage
- Cloud KMS CryptoKey Encrypter sur la clé KMS
- Suivez les instructions des pages de documentation Utiliser des autorisations IAM (Cloud Storage) et Contrôle des accès avec IAM (KMS).
Remarque :Les rôles que nous venons de décrire accordent les autorisations minimales requises pour exporter les données.
Créez une clé de compte de service associée à <export-service-account>, puis téléchargez le fichier de clé JSON.
- Suivez les instructions de la page de documentation Créer et supprimer des clés de compte de service.
Attention :Les clés de compte de service constituent un risque pour la sécurité si elles ne sont pas gérées correctement. Vous êtes responsable de la sécurité de la clé privée et des autres opérations décrites dans la section Bonnes pratiques de gestion des clés de compte de service. Si vous ne parvenez pas à créer une clé de compte de service, la création de clé de compte de service peut être désactivée pour votre organisation. Pour en savoir plus, consultez la page Gérer les ressources d'organisation sécurisées par défaut.

Demander l'exportation

Une fois que vous vous êtes assuré que votre instance est prête pour la migration, que vous avez créé une instance Looker (Google Cloud Core) "vide" et créé un emplacement pour stocker les données de migration, saisissez les informations suivantes sur la page Exporter du panneau Administration de votre instance Looker (d'origine) :

Nom du bucket Cloud Storage que vous avez créé.
Nom du dossier Cloud Storage : un dossier portant ce nom sera automatiquement créé lors de l'exportation. Une fois l'exportation terminée, les fichiers d'exportation apparaîtront dans un sous-dossier horodaté de ce dossier, dans le bucket Cloud Storage que vous avez créé.
Nom de la clé KMS.
Texte JSON contenant la clé du compte de service.

Une fois que vous avez saisi les informations sur la page Exporter, cliquez sur Demander une exportation pour lancer l'exportation.

Le processus d'exportation prend de quelques minutes à plusieurs heures. Une fois l'exportation terminée, plusieurs fichiers d'exportation (au format non lisible par l'humain) s'affichent dans votre bucket et dossier Cloud Storage. Ces fichiers serviront d'entrée pour l'étape d'importation suivante.

Importer les données dans la nouvelle instance Looker (Google Cloud Core) "vide"

Une fois les données de votre instance exportées, vous pouvez les importer dans votre instance Looker (Google Cloud Core).

Suivez les instructions de la page Importer vos données depuis Cloud Storage dans une instance Looker (Google Cloud Core) en faisant pointer les commandes vers le bucket et le dossier dans lesquels les fichiers d'exportation ont été placés.

En résumé, cela implique les opérations suivantes:

Accordez les rôles suivants pour accéder au bucket et à la clé KMS du compte de service Looker (et non à <export-service-account>) :
- Storage Object User sur le bucket Cloud Storage
- Cloud KMS CryptoKey Decrypter sur la clé KMS
Déclencher l'importation via la console Google Cloud ou gcloud CLI

L'opération d'importation prend de quelques minutes à plusieurs heures. Une fois l'opération terminée, votre instance Looker (Google Cloud Core) redémarrera et toutes les données migrées seront transférées.

Finaliser la configuration de l'instance Looker (Google Cloud Core)

À ce stade, les administrateurs Looker peuvent accéder à l'URL de l'instance et se connecter à l'instance pour finaliser la configuration.

Le processus de migration copie autant de configuration de l'instance Looker (originale) que possible. Toutefois, certains éléments ne peuvent pas être migrés ou fonctionnent un peu différemment dans Looker (Google Cloud Core) et doivent être ajustés.

Certains éléments qui requièrent une attention particulière sont les suivants:

Paramètres généraux (dans le panneau Admin de Looker)	La plupart des paramètres généraux (et d'autres paramètres du panneau Admin) ne sont pas copiés automatiquement, car ils sont généralement différents ou n'existent pas sous la même forme dans Looker (Google Cloud Core). Vous devez vérifier et configurer soigneusement tous les paramètres dans le contexte de la configuration Looker (Google Cloud Core) que vous avez choisie. Consultez les pages de documentation Administrer une instance Looker (Google Cloud Core) depuis Looker et Administrer une instance Looker (Google Cloud Core) depuis la console Google Cloud pour en savoir plus sur les paramètres dans Looker (Google Cloud Core).
Utilisateurs	Looker (Google Cloud Core) n'est compatible qu'avec les méthodes d'authentification Google OAuth, SAML et OpenID Connect. Si l'instance Looker (d'origine) a également été configurée pour Google OAuth, les enregistrements utilisateur et leurs attributs seront copiés (tant qu'ils sont associés au même ID Google et à la même adresse e-mail dans les deux instances). Un administrateur de projet IAM doit attribuer à chaque utilisateur le rôle IAM "Administrateur Looker" ou "Utilisateur de l'instance Looker" pour le projet Google Cloud dans lequel se trouve l'instance. Si l'instance Looker (d'origine) a été configurée pour SAML ou OpenID Connect, assurez-vous que le champ Fusionner les utilisateurs avec de la méthode d'authentification indique uniquement les méthodes d'authentification compatibles avec Looker (Google Cloud Core). Si certains utilisateurs de l'instance Looker (d'origine) s'authentifient via un mécanisme non pris en charge dans Looker (Google Cloud Core) (comme LDAP ou l'adresse e-mail/mot de passe), ces comptes utilisateur devront être recréés et convertis vers une méthode d'authentification compatible.
Connexions à la base de données	Looker (Google Cloud Core) est compatible avec un ensemble de dialectes de base de données légèrement différent de celui de Looker (version d'origine). Toutes les propriétés de configuration des connexions à la base de données (y compris la chaîne de connexion et le mot de passe, le cas échéant) sont copiées. Cependant, la topologie différente du réseau dans Looker (Google Cloud Core) peut empêcher les connexions à la base de données de fonctionner immédiatement. Par exemple, si les bases de données sont accessibles via des pare-feu ou des tunnels spécifiques à l'instance Looker (originale), vous devrez peut-être reconfigurer les pare-feu ou les tunnels. Nous vous conseillons de tester chaque connexion et de la rétablir si nécessaire.
Connexions au dépôt Git	Si l'instance utilise des dépôts Git simples, elle devrait fonctionner sans modification (copiée, mais pas partagée). Toutefois, si l'instance se connecte à des dépôts distants, il peut être nécessaire de vérifier et de réactiver ces connexions, comme pour les connexions à la base de données.
Autre configuration réseau	L'instance Looker peut avoir d'autres types de connexions réseau, entrantes et sortantes (par exemple, dans le contexte d'une adresse IP privée, d'Action Hub, de Marketplace, d'e-mails, etc.). Ces connexions réseau doivent également être vérifiées.
URL permettant d'accéder à l'instance Looker (Google Cloud Core)	L'instance Looker (Google Cloud Core) est fournie avec une URL principale attribuée aléatoirement. Si l'instance doit être accessible via une URL spécifique, vous pouvez configurer un domaine personnalisé.
Calendriers et alertes	Si les instances Looker (originale) et Looker (Google Cloud Core) sont actives simultanément, elles peuvent générer des actions planifiées et des alertes en double, et effectuer des opérations en arrière-plan en double qui accèdent aux bases de données connectées. Ces activités doivent être désactivées dans l'une des instances dès que possible.
Intervalles de maintenance	Contrairement à Looker (version initiale), vous pouvez spécifier une règle de maintenance pour Looker (Google Cloud Core).
Activité système Elite	Les données d'activité système Elite ne sont pas copiées lors de la migration. L'instance Looker (Google Cloud Core) démarrera avec un nouvel historique.
Domaine personnalisé	Vous pouvez créer un domaine personnalisé pour votre instance Looker (Google Cloud Core). Vous devez définir les enregistrements DNS pour garantir le déploiement du certificat SSL. En outre, veillez à remplacer l'URL de rappel dans votre client d'authentification par le domaine personnalisé une fois que votre domaine personnalisé est activé et que votre méthode d'authentification est configurée. Impossible de créer des domaines personnalisés pour Looker (Google Cloud Core) avec un domaine `looker.com`. Si vous souhaitez créer un domaine personnalisé pour votre instance Looker (Google Cloud Core) à l'aide de l'URL personnalisée de votre instance Looker (version d'origine), vous devez configurer le domaine personnalisé une fois la migration terminée et après avoir vérifié que l'instance Looker (Google Cloud Core) est prête à être utilisée. Une fois le domaine personnalisé activé, vos utilisateurs verront l'instance Looker (Google Cloud Core), et non l'instance Looker (version d'origine) lorsqu'ils accéderont à l'URL de l'instance. Ne configurez pas SAML ni OpenID Connect pour l'instance Looker (Google Cloud Core) tant que l'instance n'est pas prête à être utilisée, que les enregistrements DNS ont été mis à jour et que le domaine personnalisé n'a pas été activé.
Bookmarks	Si vous utilisez une URL personnalisée dans votre instance Looker (version d'origine) (qui n'utilise pas le domaine `looker.com`), ce processus de migration devrait conserver les favoris des utilisateurs si vous créez un domaine personnalisé pour votre instance Looker (Google Cloud Core) avec la même URL que votre instance Looker (version d'origine). Une fois le domaine personnalisé activé, les favoris vers le contenu Looker (original) comme `https://www.yourcustomdomain.com/dashboard/123` pointeront vers le contenu dans l'instance Looker (Google Cloud Core). (Remarque: les éditions Enterprise et Embed de Looker (Google Cloud Core) utilisent des slugs de contenu alphanumériques dans leurs URL au lieu d'ID de contenu numériques. Toutefois, un favori avec un Content ID redirigera quand même correctement vers le même contenu. Ce processus ne peut pas être utilisé avec les URL Looker (d'origine) qui utilisent le domaine `looker.com`.

Cette liste n'est pas exhaustive. Testez tous les aspects de l'instance qui sont les plus importants pour vous avant de considérer que la migration est terminée.

Une fois la migration terminée et que vous êtes certain de ne pas avoir besoin d'une autre exportation, vous pouvez supprimer le <export-service-account> que vous avez créé précédemment. La clé JSON qui a été partagée pour elle sera alors inutile.

Mettre hors service l'instance Looker (originale)

Une fois que l'instance Looker (Google Cloud Core) migrée fonctionne de manière satisfaisante, vous pouvez envoyer à vos utilisateurs l'URL de l'instance et leur demander de commencer à y accéder et d'arrêter d'accéder à l'instance Looker (d'origine).

Dépannage

Les sections suivantes peuvent vous aider à résoudre les problèmes d'importation ou d'exportation.

Problèmes lors de l'exportation

En cas de problème lors de l'exportation de vos données Looker (d'origine), l'état ERREUR s'affiche sur la page Exporter du panneau Administration. Cliquez sur l'état ERREUR pour afficher un message d'erreur.

Voici les principales sources d'erreurs:

Le bucket Cloud Storage, la clé KMS ou l'élément <export-service-account> ne sont pas valides.
Le <export-service-account> ne dispose pas des autorisations nécessaires.

Il est utile de vérifier l'état de ces objets avant d'envoyer votre demande d'exportation.

Problèmes lors de l'importation

Si l'opération d'importation ne se termine pas au bout de quatre heures (ou peut-être plus si l'instance source était très volumineuse) ou si elle se ferme par erreur, vous devrez peut-être envoyer une demande à Cloud Customer Care pour résoudre le problème. Pour cette opération, peu de diagnostics sont directement visibles par le client.