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.

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

Ce document décrit les étapes techniques de la migration d'une 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 depuis la console Google Cloud, et il s'intègre parfaitement à de nombreux autres produits, services et fonctionnalités de Google Cloud.

Avant de commencer

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

Contactez votre responsable de compte au sujet de la migration et contactez votre responsable de compte pour savoir si votre instance Looker (d'origine) est éligible. Si votre instance est éligible et si vous avez mis à niveau votre contrat Looker (version initiale) existant pour inclure 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éside 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 du projet (roles/resourcemanager.projectIamAdmin).
- Créez un bucket Cloud Storage : Administrateur de l'espace de stockage (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 (classique) en vue de sa 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 qu'elle dispose des fonctionnalités nécessaires. Certaines fonctionnalités de Looker (Google Cloud Core) dépendent de l'édition ou du type de réseau sélectionné.

Laissez l'instance"vide" et ne lui ajoutez aucune donnée, comme 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 seront effacé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 dans 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 (classique) est prête pour la migration.
Exportez les données depuis votre instance Looker (classique).
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 (classique).

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

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

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

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

Remarque :Les instances Looker (classiques) 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.

Vous devez également effectuer les opérations suivantes avant la migration:

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.

Conseil :Nous vous recommandons de désactiver dans votre instance Looker (version d'origine) les fonctionnalités qui n'ont pas d'équivalent dans Looker (Google Cloud Core), telles que les anciennes fonctionnalités et les fonctionnalités expérimentales, avant un certain temps avant la migration afin de pouvoir continuer à travailler sans.
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 garantir le transfert des fichiers en mode Développement 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, ces dépôts seront copiés sur l'instance Looker (Google Cloud Core), et non partagés entre les instances Looker (version d'origine) 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 (version initiale) 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 (classique) utilise déjà Google OAuth, tous les enregistrements utilisateur seront transférés, mais vous devrez tout de même créer manuellement des autorisations IAM pour les utilisateurs du projet de votre instance Looker (Google Cloud Core).
- Si votre instance Looker (classique) utilise SAML, le paramètre Fusionner les utilisateurs à l'aide de 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 (classique) utilise OIDC, le paramètre Fusionner les utilisateurs à l'aide de la page du panneau d'administration 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 permettre l'authentification dans 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 sert de méthode d'authentification de secours pour Looker (Google Cloud Core).
- Si vous souhaitez 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 Looker (version initiale) et une Looker (Google Cloud Core) s'exécuteront en parallèle pendant un certain temps. Toute activité automatique en cours (comme 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 toute activité en double, supprimez les alertes et les planifications automatiques dans l'instance Looker (version initiale) ou Looker (Google Cloud Core).

Exporter les données depuis votre instance Looker (classique)

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

Créez un emplacement pour stocker 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 dans lequel vous avez créé l'instance Looker (Google Cloud Core).

Créez un bucket Cloud Storage (par exemple, <bucket-name>).
- Ce bucket sera utilisé pour stocker les données de migration.
- Suivez les instructions de la page de documentation Créer des buckets.
- Notez que le <bucket-name> doit être unique dans l'ensemble de Google Cloud. Nous vous recommandons de faire précéder le nom du bucket d'un identifiant unique, tel que l'ID de votre projet.
Choisissez un nom pour un dossier à l'intérieur du 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é servira à chiffrer les données de migration. Étant donné qu'il s'agit d'une clé KMS, vous ne devez divulguer que son nom, et non la clé elle-même, à la page Export (Exporter) du panneau d'administration de Looker (version initiale).
- Suivez les instructions des pages de documentation Créer un trousseau de clés et Créer une clé.
Créez un compte de service spécifiquement pour 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 deux rôles IAM spécifiques à <export-service-account>:
- 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 vous venez 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 représentent 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

Après vous être assuré que votre instance est prête pour la migration, 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 Export (Exporter) du panneau Admin 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 apparaissent dans un sous-dossier horodaté de ce dossier, dans le bucket Cloud Storage que vous avez créé.
Le 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, vous verrez plusieurs fichiers d'exportation (dans un format non lisible) dans votre bucket et dossier Cloud Storage. Ces fichiers seront utilisés 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 Cloud Storage vers une instance Looker (Google Cloud Core), en indiquant les commandes vers le bucket et le dossier dans lesquels les fichiers d'exportation ont été placés.

En résumé, cela implique ce qui suit:

Attribuer les rôles suivants pour accéder au bucket et à la clé KMS au compte de service Looker (et non au compte <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 la 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 avec toutes les données migré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 que possible la configuration de l'instance Looker (d'origine). 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.

Voici certains éléments qui requièrent une attention particulière:

Paramètres généraux (dans le panneau Administration de Looker)	La plupart des paramètres généraux (et les 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 le même format dans Looker (Google Cloud Core). Vous devez examiner attentivement et configurer tous les paramètres dans le contexte de la configuration Looker (Google Cloud Core) que vous avez choisie. Consultez les pages de documentation Gérer une instance Looker (Google Cloud Core) à partir de Looker et Gérer une instance Looker (Google Cloud Core) à partir de la console Google Cloud pour en savoir plus sur les paramètres de 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 des utilisateurs et leurs attributs seront copiés (à condition qu'ils soient associés au même ID Google et à la même adresse e-mail dans les deux cas). Un administrateur IAM de projet doit attribuer à chaque utilisateur le rôle IAM d'administrateur Looker ou d'utilisateur d'instance Looker sur le projet Google Cloud dans lequel se trouve l'instance. Si l'instance Looker (version initiale) a été configurée pour SAML ou OpenID Connect, assurez-vous que le champ Fusionner les utilisateurs à l'aide 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 (version initiale) s'authentifient via un mécanisme non compatible avec Looker (Google Cloud Core) (LDAP ou une adresse e-mail/mot de passe, par exemple), ces comptes utilisateur devront être recréés et convertis selon une méthode d'authentification compatible.
Connexions à la base de données	Looker (Google Cloud Core) est compatible avec un ensemble légèrement différent de dialectes de base de données par rapport à Looker (version initiale). 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 du réseau différente dans Looker (Google Cloud Core) peut empêcher les connexions à la base de données de fonctionner immédiatement. Par exemple, si vous accédez aux bases de données via des pare-feu ou des tunnels spécifiques à l'instance Looker (d'origine), vous devrez peut-être reconfigurer les pare-feu ou les tunnels. Nous vous recommandons 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, ils devraient 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, de la même manière que 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'une e-mail, etc.). Ces connexions réseau doivent également être vérifiées.
URL d'accès à l'instance Looker (Google Cloud Core)	L'instance Looker (Google Cloud Core) est fournie avec une URL principale attribuée de manière aléatoire. Si l'instance doit être accessible via une URL spécifique, vous pouvez configurer un domaine personnalisé.
Programmations et alertes	Si les instances Looker (version initiale) et Looker (Google Cloud Core) sont toutes les deux actives simultanément, elles peuvent générer des actions et des alertes planifiées 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'un des cas dès que possible.
Intervalles de maintenance	Contrairement à Looker (version initiale), une règle de maintenance peut être spécifiée pour Looker (Google Cloud Core).
Activité du système Elite	Les données concernant l'activité du système Elite ne sont pas copiées lors de la migration. L'instance Looker (Google Cloud Core) démarre 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. Une fois votre domaine personnalisé activé et votre méthode d'authentification configurée, veillez également à remplacer l'URL de rappel de votre client d'authentification par le domaine personnalisé. 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 (classique) 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 (d'origine). Une fois le domaine personnalisé activé, les favoris vers du contenu Looker (version initiale) tels que `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érique dans leurs URL au lieu d'ID de contenu numériques, mais un favori avec un ID de contenu redirigera toujours 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 les plus importants de l'instance avant de considérer la migration comme étant terminée.

Une fois la migration terminée et si vous êtes certain de ne pas demander d'autre exportation, vous pouvez supprimer le <export-service-account> que vous avez créé précédemment. La clé JSON partagée devient alors inutile.

Mettre l'instance Looker (d'origine) hors service

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 de ne plus accéder à l'instance Looker (d'origine).

Dépannage

Les sections suivantes peuvent vous aider à résoudre les problèmes liés à l'importation ou à l'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.

Les causes les plus courantes d'erreurs sont les suivantes:

Le bucket Cloud Storage, la clé KMS ou l'élément <export-service-account> n'est pas valide.
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 plus si l'instance source est très volumineuse) ou si elle se ferme par erreur, vous devrez peut-être ouvrir une demande auprès du Cloud Customer Care pour résoudre le problème. Peu de diagnostics sont directement visibles pour le client pour cette opération.