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 étroitement à la plate-forme Google Cloud. Looker (Google Cloud Core) est hébergé sur l'infrastructure Google Cloud. vous pouvez le gérer directement dans la console Google Cloud. Il s'intègre parfaitement à de nombreux autres produits, services et fonctionnalités de Google Cloud.

Avant de commencer

  1. Familiarisez-vous avec les principes et les outils Google Cloud en consultant la documentation suivante :
  2. Contactez votre responsable de compte pour en savoir plus sur la migration et savoir si votre instance Looker (version initiale) 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.

  3. Pour obtenir les autorisations nécessaires à la préparation de la migration, demandez à votre administrateur de vous accorder 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 de projet IAM (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 page Gérer l'accès aux projets, aux dossiers et aux organisations.

    Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

  4. Pour gérer l'instance Looker (originale) en vue de la migration, vous devez disposer du rôle Administrateur Looker dans cette instance.

  5. Créer une instance vide une instance Looker (Google Cloud Core).

    Veillez à sélectionner la édition, le type de connexion réseau (adresse IP publique ou privée) et d'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 le 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. Lors de l'étape d'importation, tous les paramètres et contenus seront effacés et remplacés par les données 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.

  1. Assurez-vous que votre instance Looker (version initiale) est prête à être migrée.
  2. Exportez les données depuis votre instance Looker (version d'origine).
  3. Importer les données dans le nouveau "vide" une instance Looker (Google Cloud Core).
  4. Finalisez la configuration de l'instance Looker (Google Cloud Core).
  5. 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 (originale) est prête à être migrée

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 (autrement dit, ne pas être 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 dans les un mois 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.

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). Passez en revue ces différences pour vous assurer que les fonctionnalités de Looker (Google Cloud core) répondent à vos besoins.

  • 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 du 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.

  • Looker (Google Cloud Core) n'est compatible qu'avec les méthodes d'authentification Google OAuth, SAML et OpenID Connect.

  • 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 envois de données 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 initiale) ou Looker (Google Cloud Core).

Exporter les données de votre instance Looker (original)

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

  1. Créez un emplacement de stockage pour les données de migration.
  2. 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).

  1. 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 d'ajouter un identifiant unique (par exemple, votre ID de projet) au nom du bucket.
  2. Choisissez un nom pour 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.
  3. Créez un trousseau de clés et une clé dans Cloud KMS (par exemple, <kms_keyring_id> et <kms-key-id>).
  4. Créez un compte de service spécifiquement pour la migration (par exemple, <export-service-account>).

  5. Attribuez à <export-service-account> deux rôles IAM spécifiques :

  6. Créez une clé de compte de service associée à <export-service-account>, puis téléchargez le fichier de clé JSON.

Demander l'exportation

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

  • Nom du bucket Cloud Storage que vous avez créé.
  • Nom du dossier Cloud Storage : un dossier de ce nom sera automatiquement créé lors de l'exportation. Une fois l'exportation terminée, les fichiers d'exportation s'affichent dans un sous-dossier associé à un code temporel dans ce dossier du 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 plusieurs minutes, voire 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 un bucket Cloud Storage vers une instance Looker (Google Cloud Core), en pointant 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:

  1. Attribuez les rôles suivants pour l'accès au bucket et à la clé KMS au compte de service Looker (et non à <export-service-account>) :
  2. 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, ainsi que 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 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.

Voici quelques éléments qui nécessitent une attention particulière :

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 "Administration") ne sont pas copiés automatiquement, car ils ont tendance à être différents ou n'existent pas sous la même forme dans Looker (Google Cloud Core). Vous devez examiner et configurer attentivement 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 (à condition qu'ils soient associés au même ID Google et à la même adresse e-mail dans les deux instances). Un administrateur IAM de projet doit attribuer à chaque utilisateur le rôle IAM administrateur Looker ou utilisateur d'instance Looker sur 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 (originale) s'authentifiaient via un mécanisme non compatible avec Looker (Google Cloud Core) (par exemple, LDAP ou adresse e-mail/mot de passe), ces comptes utilisateur devront être recréés et convertis en 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 aux bases de données (y compris la chaîne de connexion et le mot de passe, le cas échéant) sont copiées. Toutefois, la topologie réseau différente de Looker (noyau Google Cloud) peut empêcher les connexions de 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 (d'origine), vous devrez peut-être reconfigurer les pare-feu ou les tunnels. Vous devez tester chaque connexion et la rétablir si nécessaire.

Connexions aux bases de données avec OAuth

La migration de Looker (original) vers Looker (Google Cloud Core) ne conserve pas les jetons d'accès ou d'actualisation OAuth pour les connexions de base de données des utilisateurs individuels à BigQuery ou Snowflake. Après la migration, les utilisateurs de Looker (Google Cloud Core) seront invités à réauthentifier OAuth lorsqu'ils afficheront une exploration ou un tableau de bord qui fait référence à une connexion de base de données OAuth. Les utilisateurs peuvent également se réauthentifier auprès de leurs bases de données en accédant à la page Compte, puis en sélectionnant Se connecter pour chaque base de données sous l'en-tête Identifiants de connexion OAuth. Toutes les planifications ou alertes automatiques appartenant à un seul utilisateur et faisant référence à une connexion OAuth ne fonctionneront plus jusqu'à ce que cet utilisateur se connecte avec ses identifiants OAuth.

Connexions de dépôts 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, ces connexions peuvent devoir être vérifiées et réactivées, comme les connexions de 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 validé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.

Toutes les planifications ou alertes automatiques appartenant à un seul utilisateur et qui font référence à sa connexion OAuth individuelle ne fonctionneront plus jusqu'à ce qu'il se connecte avec ses identifiants OAuth.

Intervalles de maintenance

Contrairement à Looker (version initiale), vous pouvez spécifier une règle de maintenance pour Looker (Google Cloud Core).

Activité du système élite

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. Veillez également à remplacer le domaine personnalisé par l'URL de rappel dans votre client d'authentification une fois que votre domaine personnalisé est activé et que votre méthode d'authentification est configurée. Vous ne pouvez pas créer de domaines personnalisés pour Looker (Google Cloud Core) à l'aide d'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 initiale) 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é.

Favoris

Si vous utilisez une URL personnalisée dans votre instance Looker (originale) (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) à l'aide de la même URL que votre instance Looker (originale).

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 ID de contenu redirigera tout de 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 sûr de ne pas avoir besoin d'une autre exportation, vous pouvez supprimer le <export-service-account> que vous avez créé précédemment, ce qui rend inutile la clé JSON qui a été partagée pour celui-ci.

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 (données d'origine), l'état ERROR (ERREUR) s'affiche sur la page Export (Exporter) du panneau Admin. 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.

Étape suivante