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 depuis la console Google Cloud . Il est également profondément intégré à 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 :
- Google Cloud overview
- 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 pour 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) existant pour couvrir Looker (Google Cloud Core), vous pouvez suivre les étapes décrites dans ce document pour migrer votre instance.
-
Pour obtenir les autorisations nécessaires pour préparer 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 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 Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises avec 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 (Original) 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 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 avec aucune donnée, comme 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 ou 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 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 remplacé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 pour la migration.
- Exportez les données de votre instance Looker (version initiale).
- 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.
S'assurer que votre instance Looker (Original) est prête pour la migration
Pour pouvoir être migrée, votre instance Looker (Original) doit répondre aux conditions préalables suivantes :
- Votre instance Looker (version initiale) doit être gérée par Google (c'est-à-dire non hébergée par le client) et hébergée sur Google Cloud ou Amazon Web Services.
Votre instance Looker (édition originale) doit utiliser une version qui date d'un mois maximum par rapport à 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 et recherchez la dernière annonce de déploiement.
De plus, effectuez les activités suivantes avant la migration :
Il existe un petit ensemble 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 continus.
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 les dépôts Git avant de lancer la migration.
Looker (Google Cloud Core) n'accepte que 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 en méthode d'authentification compatible avec Looker (Google Cloud Core).
- Si votre instance Looker (Original) 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 dans le projet de votre instance Looker (Google Cloud Core).
- Si votre instance Looker (Original) utilise SAML, le paramètre "Fusionner les utilisateurs à l'aide de" sur la page Authentification SAML du panneau d'administration doit être défini sur Google ou OIDC pour éviter une erreur lorsque vous testez l'authentification SAML.
- Si votre instance Looker (Original) 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 une erreur lorsque vous testez l'authentification OpenID Connect.
- Si vous utilisez un fournisseur d'identité externe, vous devez mettre à jour l'URL de rappel dans votre fournisseur d'identité avec 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 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 Looker (version initiale) et une Looker (Google Cloud Core)) s'exécuteront en parallèle pendant un certain temps. Toute activité automatique (comme les alertes et les livraisons de données planifiées, 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 plannings 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 depuis 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 projet Google Cloud 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 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 pour tous les 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 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 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. Comme il s'agit d'une clé KMS, vous n'avez besoin de communiquer que son nom, et non la clé elle-même, sur la page Exporter du panneau Admin 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.
Accordez à
<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>
, 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.
Demander l'exportation
Une fois que vous avez vérifié 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 Exporter du panneau Admin de votre instance Looker (Original) :
- Nom du bucket Cloud Storage que vous avez créé.
- Nom du dossier Cloud Storage. Un dossier portant ce nom sera créé automatiquement lors de l'exportation. Une fois l'exportation terminée, les fichiers d'exportation s'affichent 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 l'exportation pour lancer l'exportation.
Le processus d'exportation prend de quelques minutes à quelques heures. Une fois l'exportation terminée, plusieurs fichiers d'exportation (dans un format non lisible par l'homme) s'affichent dans votre bucket et dossier Cloud Storage. Ces fichiers sont des entrées 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 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 les éléments suivants :
- Attribuez les rôles suivants pour accéder 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 à l'aide de la console Google Cloud ou de gcloud CLI
L'opération d'importation prend de quelques minutes à quelques 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 de configuration d'instance Looker (Original) que possible. Toutefois, certains éléments ne peuvent pas être migrés ou fonctionnent légèrement 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 options des paramètres généraux (et d'autres paramètres du panneau Admin) ne sont pas copiées automatiquement, car elles sont généralement 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 en fonction 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'accepte que les méthodes d'authentification Google OAuth, SAML et OpenID Connect. Si l'instance Looker (Original) a également été configurée pour Google OAuth, les fiches utilisateur et leurs attributs seront copiés (à condition qu'ils soient associés au même ID et à la même adresse e-mail Google dans les deux instances). Un administrateur IAM de projet doit accorder à 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 (original) était 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 (Original) s'authentifiaient à l'aide d'un mécanisme non compatible avec Looker (Google Cloud Core) (tel que LDAP ou une adresse e-mail/un mot de passe), ces comptes utilisateur devront être recréés et convertis en 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 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. Toutefois, la topologie 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 les bases de données sont accessibles via des pare-feu ou des tunnels spécifiques à l'instance Looker (Original), vous devrez peut-être reconfigurer les pare-feu ou les tunnels. Vous devez tester chaque connexion et la rétablir si nécessaire. |
Connexions à des bases de données utilisant OAuth |
La migration de Looker (Original) vers Looker (Google Cloud Core) ne conserve pas les jetons d'accès OAuth ni les jetons d'actualisation pour les connexions à la base de données des utilisateurs individuels vers BigQuery ou Snowflake. Après la migration, les utilisateurs de Looker (Google Cloud Core) seront invités à réauthentifier OAuth lorsqu'ils consulteront 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 et 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 seront interrompues jusqu'à ce que cet utilisateur se connecte avec ses identifiants OAuth. |
Connexions de dépôt Git |
Si l'instance utilise des dépôts Git nus, ils devraient fonctionner sans modification (copiés, mais non partagés). Toutefois, si l'instance se connecte à des dépôts distants, ces connexions devront peut-être être vérifiées et réactivées, comme les connexions à la base de données. |
Autre configuration réseau |
L'instance Looker peut disposer d'autres types de connexions réseau, entrantes et sortantes (par exemple, dans le contexte de l'adresse IP privée, du hub d'actions, du Marketplace, de l'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é. |
Programmes 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 faisant référence à la connexion OAuth individuelle de cet utilisateur ne fonctionneront plus tant que l'utilisateur ne se sera pas connecté avec ses identifiants OAuth. |
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 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 historique vierge. |
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. De plus, une fois votre domaine personnalisé activé et votre méthode d'authentification configurée, veillez à mettre à jour l'URL de rappel dans votre client d'authentification pour qu'elle corresponde au domaine personnalisé. 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 (Original), 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 n'ont pas é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 (Original) (qui n'utilise pas le domaine Une fois le domaine personnalisé activé, les favoris vers le contenu Looker (version initiale), comme Ce processus ne peut pas être utilisé avec les URL Looker (original) qui utilisent le domaine |
Cette liste n'est pas exhaustive. Testez tous les aspects de l'instance qui sont les plus importants pour vous avant de considérer la migration comme terminée.
Une fois la migration terminée et si vous êtes certain de ne plus avoir besoin d'exporter de données, vous pouvez supprimer le <export-service-account>
que vous avez créé précédemment. La clé JSON partagée pour ce <export-service-account>
deviendra alors inutile.
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 à 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 (Original).
Dépannage
Les sections suivantes peuvent vous aider à résoudre les problèmes lors de l'importation ou de l'exportation.
Problèmes lors de l'exportation
En cas de problème lié à l'exportation de vos données Looker (Original), l'état ERREUR s'affiche sur la page Exporter du panneau Admin. Si vous cliquez sur l'état ERROR (ERREUR), un message d'erreur s'affiche.
Voici les sources d'erreurs les plus courantes :
- Le bucket Cloud Storage, la clé KMS ou
<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 (voire plus si l'instance source était très volumineuse) ou si elle se termine avec une erreur, vous devrez peut-être ouvrir un ticket auprès du Cloud Customer Care pour résoudre le problème. Il existe relativement peu de diagnostics directement visibles par les clients pour cette opération.
É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 console Google Cloud
- Administrer votre instance Looker (Google Cloud Core) depuis Looker