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 via la console Google Cloud. Il offre une intégration approfondie avec 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:
- Présentation deGoogle Cloud
- Présentation d'IAM
- Présentation de Looker (Google Cloud Core)
- Présentation de Cloud Billing
- 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 (version initiale) pour qu'il couvre Looker (Google Cloud Core), vous pouvez suivre la procédure décrite dans ce document pour migrer votre instance.
-
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 Google Cloud projet 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 Google Cloud projet :
Administrateur IAM de 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 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.
-
Créez une instance Looker (Google Cloud Core) :
Administrateur Looker (
- Pour gérer l'instance Looker (originale) en vue de la migration, vous devez disposer du rôle Administrateur Looker dans cette instance.
Créez une instance Looker (Google Cloud Core) "vide".
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 la remplissez pas de 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 d'une 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 (version initiale) est prête à être migrée.
- Exportez les données de votre instance Looker (version initiale).
- Importez les données dans la nouvelle instance Looker (Google Cloud Core) "vide".
- Terminez 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 (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 datant de moins d'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 l'annonce de déploiement la plus récente.
En outre, effectuez les activités suivantes avant la migration:
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.
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 appartenant à 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.
- Si votre instance Looker (version initiale) utilise une méthode d'authentification différente (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 (originale) utilise déjà Google OAuth, tous les enregistrements utilisateur seront transférés, mais vous devez 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 (originale) utilise SAML, le paramètre "Fusionner les utilisateurs à l'aide de" sur la page du panneau d'administration Authentification SAML doit être défini sur Google ou OIDC pour éviter toute erreur lorsque vous testez l'authentification SAML.
- Si votre instance Looker (originale) utilise OIDC, le paramètre "Fusionner les utilisateurs à l'aide de" sur la page du panneau d'administration Authentification OpenID Connect doit être défini sur Google ou SAML pour éviter toute erreur lorsque vous testez l'authentification OpenID Connect.
- Si vous utilisez un fournisseur d'identité externe, vous devez remplacer l'URL de rappel dans votre fournisseur d'identité par l'URL Looker (Google Cloud core) pour autoriser 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 également de configurer Google OAuth, qui sert 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 ou OpenID Connect pour l'instance tant que le domaine personnalisé n'est pas activé.
Lors de la migration, deux instances Looker (une Looker (version initiale) et une Looker (Google Cloud Core)) s'exécutent en parallèle pendant un certain temps. Toute activité automatique qui a lieu (telles 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 doublons d'activité, 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 de vos instances Looker (original) se fait en deux étapes:
Créer un emplacement pour stocker les données de migration
Effectuez toutes les opérations suivantes dans le même Google Cloud projet que celui dans lequel 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 l'
<bucket-name>
doit être unique dans l'ensemble de Google Cloud. Nous vous recommandons d'ajouter un identifiant unique (par exemple, votre ID de projet) au nom du bucket.
- Choisissez un nom pour un dossier dans le bucket Cloud Storage (par exemple,
<folder-name>
). Ne créez pas le dossier pour le moment. Spécifiez le nom du dossier lors de la requête d'exportation. Il sera créé automatiquement lors du processus d'exportation. - Créez un trousseau 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. Comme il s'agit d'une clé KMS, vous ne devez indiquer que le nom de la clé, et non la clé elle-même, sur la page Export (Exporter) du panneau Admin (Administration) de Looker (original).
- 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 à
<export-service-account>
deux rôles IAM spécifiques:Storage Object Creator
sur le bucket Cloud StorageCloud 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).
Créez une clé de compte de service associée à
<export-service-account>
et 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.
Demander l'exportation
Une fois que vous vous êtes assuré que votre instance est prête à être migrée, que vous avez créé une instance Looker (Google Cloud Core) "vide" et un emplacement pour stocker les données de migration, saisissez les informations suivantes sur la page Export (Exporter) du panneau Admin (Administration) de votre instance Looker (originale) :
- 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 l'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 votre dossier Cloud Storage. Ces fichiers sont saisis 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 éléments suivants:
- 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>
) :Storage Object User
sur le bucket Cloud StorageCloud 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 la migration terminée, votre instance Looker (Google Cloud Core) redémarre, 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 (originale). Toutefois, certains éléments ne peuvent pas être migrés ou fonctionnent 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 Administration de Looker) |
La plupart des options des paramètres généraux (et des autres paramètres du panneau Administration) ne sont pas copiées automatiquement, car elles ont tendance à être différentes 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. Pour en savoir plus sur les paramètres de Looker (Google Cloud Core), 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. |
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 accorder à chaque utilisateur le rôle IAM administrateur Looker ou utilisateur d'instance Looker sur le Google Cloud projet dans lequel se trouve l'instance. Si l'instance Looker (originale) a été configurée pour SAML ou OpenID Connect, assurez-vous que le champ Fusionner les utilisateurs à l'aide de pour la méthode d'authentification n'indique que 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 légèrement différent de dialectes de base de données que Looker (version initiale). 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 à la base de données à l'aide d'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 qui font 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 nus, ils devraient fonctionner sans modification (copiés, mais pas partagés). 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, à la fois entrantes et sortantes (par exemple, dans le contexte d'une adresse IP privée, d'un hub d'actions, d'une place de marché, d'un e-mail, 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 de manière aléatoire. Si l'instance doit être accessible via une URL spécifique, vous pouvez configurer un domaine personnalisé. |
Calendriers et alertes |
Si les instances Looker (version initiale) et Looker (Google Cloud Core) sont 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'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é du 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 assurer 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 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 (originale), vous devez le configurer 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 ou OpenID Connect pour l'instance Looker (Google Cloud Core) tant qu'elle n'est pas prête à être utilisée, que les enregistrements DNS n'ont pas é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 (originale) (qui n'utilise pas le domaine Une fois le domaine personnalisé activé, les signets vers le contenu Looker (version initiale), tels que Ce processus ne peut pas être utilisé avec les URL Looker (d'origine) qui utilisent le domaine |
Cette liste n'est pas exhaustive. Testez tous les aspects de l'instance qui vous intéressent le plus avant de considérer la migration comme 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 (version initiale)
Une fois que l'instance Looker (Google Cloud Core) migrée fonctionne de manière satisfaisante, vous pouvez envoyer l'URL de l'instance à vos utilisateurs et leur demander de commencer à y accéder et d'arrêter d'accéder à l'instance Looker (originale).
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 ERROR (ERREUR) pour afficher un message d'erreur.
Voici les sources d'erreurs courantes:
- Le bucket Cloud Storage, la clé KMS ou
<export-service-account>
n'est pas valide. <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 était très volumineuse) ou si elle se termine par une erreur, vous devrez peut-être ouvrir une demande auprès du service client Cloud pour résoudre le problème. Les diagnostics directement visibles par le client pour cette opération sont relativement peu nombreux.
Étape suivante
- Paramètres d'administration - Exporter
- Connecter Looker (Google Cloud Core) à votre base de données
- Configurer l'instance Looker (Google Cloud Core)
- Gérer l'accès des utilisateurs à l'instance Looker (Google Cloud Core)
- Administrer une instance Looker (Google Cloud Core) depuis la Google Cloud console
- Administrer votre instance Looker (Google Cloud Core) depuis Looker