Cette page explore les pratiques courantes pour des composants spécifiques de l'architecture Looker et explique comment les configurer dans un déploiement.
Looker dispose d'un certain nombre de dépendances pour l'hébergement du serveur, le traitement des charges de travail planifiées et ponctuelles, le suivi du développement itératif de modèles, etc. Ces dépendances sont appelées composants sur cette page, et chacun d'eux est abordé en détail dans les sections suivantes:
- Configuration de l'hôte
- Configuration JVM
- Options de démarrage de Looker
- Base de données interne (backend)
- Service Git
- Réseau
Configuration de l'hôte
OS et distribution
Looker fonctionne bien sur les versions les plus courantes de Linux: RedHat, SUSE et Debian/Ubuntu. Les dérivées de ces distributions conçues et optimisées pour s'exécuter dans un environnement particulier sont généralement acceptables. Par exemple, les distributions Linux Google Cloud ou AWS sont compatibles avec Looker. Debian/Ubuntu est la variété Linux la plus utilisée dans la communauté Looker. Ce sont les versions les plus familières du support Looker. Il est plus facile d'utiliser Debian/Ubuntu ou un système d'exploitation pour un fournisseur de services cloud spécifique dérivé de Debian/Ubuntu.
Looker s'exécute dans la machine virtuelle Java (JVM). Lorsque vous choisissez une distribution, déterminez si les versions d'OpenJDK 11 sont à jour. Les anciennes distributions de Linux permettent peut-être d'exécuter Looker, mais la version et les bibliothèques Java dont Looker a besoin pour certaines fonctionnalités doivent être à jour. Si la JVM ne contient pas toutes les bibliothèques et versions Looker recommandées, Looker ne fonctionnera pas normalement. Looker nécessite Java HotSpot 1.8 mise à jour 161+ ou Java OpenJDK 11.0.12+.
Processeur et mémoire
4 x 16 nœuds (4 processeurs et 16 Go de RAM) suffisent pour un système de développement ou une instance Looker de test basique utilisée par une petite équipe. Toutefois, pour une utilisation en production, ce n'est généralement pas suffisant. D'après notre expérience, 16 x 64 nœuds (16 processeurs et 64 Go de RAM) offrent un bon compromis entre prix et performances. Plus de 64 Go de RAM peuvent nuire aux performances, car les événements de récupération de mémoire sont à thread unique et interrompent l'exécution de tous les autres threads.
Stockage sur disque
Un espace disque de 100 Go est généralement plus que suffisant pour un système de production.
Considérations relatives aux clusters
Looker s'exécute sur une machine virtuelle Java, et Java peut avoir des difficultés à gérer une mémoire supérieure à 64 Go. En règle générale, si une augmentation de capacité est nécessaire, vous devez ajouter 16 x 64 nœuds supplémentaires au cluster plutôt que d'augmenter la taille des nœuds au-delà de 16 x 64. Nous pouvons également préférer utiliser une architecture en cluster pour accroître la disponibilité.
Dans un cluster, les nœuds Looker doivent partager certaines parties du système de fichiers. Les données partagées incluent les éléments suivants:
- Modèles LookML
- Les modèles LookML de développement
- Connectivité du serveur Git
Étant donné que le système de fichiers est partagé et héberge plusieurs dépôts Git, il est essentiel de gérer les accès simultanés et le verrouillage des fichiers. Le système de fichiers doit être compatible avec POSIX. Le système de fichiers réseau (NFS, Network File System) est connu pour fonctionner et est facilement accessible sous Linux. Vous devez créer une instance Linux supplémentaire et configurer NFS pour partager le disque. Le protocole NFS par défaut est potentiellement un point de défaillance unique. Nous vous recommandons donc d'opter pour une configuration de basculement ou une configuration de haute disponibilité.
Les métadonnées Looker doivent également être centralisées, de sorte que sa base de données interne doit être migrée vers MySQL. Il peut s'agir d'un service MySQL ou d'un déploiement MySQL dédié. La section Base de données interne (backend) de cette page fournit des informations plus détaillées.
Configuration de la JVM
Les paramètres JVM Looker sont définis dans le script de démarrage Looker. Après toute mise à jour, Looker doit être redémarré pour que les modifications soient appliquées. Les configurations par défaut sont les suivantes:
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
Ressources
Les paramètres de la ressource sont définis dans le script de démarrage de Looker.
JAVAMEM="2300m" METAMEM="800m"
L'allocation de mémoire pour la JVM doit tenir compte des frais généraux du système d'exploitation sur lesquels Looker s'exécute. En règle générale, la JVM peut être allouée jusqu'à 60% de la mémoire totale, mais il existe des mises en garde en fonction de la taille de la machine. Pour les machines disposant d'un minimum de 8 Go de mémoire totale, nous recommandons une allocation de 4 à 5 Go pour Java et de 800 Mo pour Meta. Pour les machines plus volumineuses, une plus petite proportion de mémoire peut être allouée au système d'exploitation. Par exemple, pour les machines disposant de 60 Go de mémoire totale, nous recommandons une allocation de 36 Go pour Java et de 1 Go pour Meta. Il est important de noter que l'allocation de mémoire de Java doit généralement s'adapter à la mémoire totale de la machine, mais que Meta doit suffire à 1 Go.
De plus, étant donné que Looker partage les ressources système avec d'autres processus tels que Chromium pour le rendu, la quantité de mémoire allouée à Java doit être sélectionnée en fonction de la charge de rendu prévue et de la taille de la machine. Si la charge de rendu devrait être faible, Java peut se voir allouer une plus grande part de la mémoire totale. Par exemple, sur une machine disposant de 60 Go de mémoire totale, Java peut être alloué en toute sécurité à 46 Go, ce qui est supérieur aux 60% recommandés. Les allocations de ressources exactes pour chaque déploiement varient. Par conséquent, utilisez 60% comme référence et ajustez l'allocation en fonction de l'utilisation.
Récupération de mémoire
Looker préfère utiliser le récupérateur de mémoire le plus récent disponible pour sa version Java. Par défaut, le délai avant expiration de la récupération de mémoire est de 2 secondes, mais vous pouvez modifier ce paramètre en modifiant l'option suivante dans la configuration de démarrage:
-XX:MaxGCPauseMillis=2000
Sur une machine plus performante comportant plusieurs cœurs, le délai avant expiration de la récupération de mémoire peut être raccourci.
Journaux
Par défaut, les journaux de récupération de mémoire Looker sont stockés dans /tmp/gc.log. Pour changer cela, modifiez l'option suivante dans la configuration de démarrage:
-Xloggc:/tmp/gc.log
JMX
La gestion de Looker peut nécessiter une surveillance pour affiner les ressources. Nous vous recommandons d'utiliser JMX pour surveiller l'utilisation de la mémoire par la JVM.
Options de démarrage de Looker
Les options de démarrage sont stockées dans un fichier appelé lookerstart.cfg. Ce fichier provient du script shell qui lance Looker.
Pools de threads
En tant qu'application multithread, Looker dispose d'un certain nombre de pools de threads. Ces pools de threads vont du serveur Web principal aux sous-services spécialisés tels que la planification, l'affichage et les connexions à des bases de données externes. En fonction de vos workflows métier, vous devrez peut-être modifier la configuration par défaut pour ces pools. En particulier, les topologies de clusters mentionnées sur la page Modèles et pratiques d'architecture d'infrastructure hébergée par le client doivent être respectées.
Options de débit planifié élevée
Pour tous les nœuds non-programmeur, ajoutez --scheduler-threads=0 à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Sans threads de planification, aucune tâche planifiée ne s'exécutera sur ces nœuds.
Pour tous les nœuds de programmeur dédiés, ajoutez --scheduler-threads=<n> à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Looker commence avec 10 threads de programmeur par défaut, mais ce nombre peut être redéfini sur <n>. Avec <n> thread du programmeur, chaque nœud pourra exécuter <n> des jobs de planification simultanés. Il est généralement recommandé de conserver <n> Moins de deux fois le nombre de processeurs. Le plus grand hôte recommandé est un hôte doté de 16 processeurs et de 64 Go de mémoire. La limite supérieure des threads de programmeur doit donc être inférieure à 32.
Options de débit d'affichage élevé
Pour tous les nœuds hors rendu, ajoutez --concurrent-render-jobs=0 à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Sans nœuds de rendu, aucune tâche de rendu ne s'exécutera sur ces nœuds.
Pour tous les nœuds de rendu dédiés, ajoutez --concurrent-render-jobs=<n> à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Looker commence avec deux threads de rendu par défaut, mais ce nombre peut être augmenté jusqu'à <n>. Avec <n> threads de rendu, chaque nœud pourra exécuter <n> tâches de rendu simultanées.
Chaque tâche de rendu peut utiliser une quantité importante de mémoire. Prévoyez environ 2 Go par tâche de rendu. Par exemple, si le processus principal de Looker (Java) se voit attribuer 60% de la mémoire totale et que 20% de la mémoire restante est réservée au système d'exploitation, les 20% restants sont réservés aux tâches de rendu. Sur une machine de 64 Go, il reste 12 Go, ce qui est suffisant pour six tâches de rendu simultanées. Si un nœud est dédié au rendu et n'est pas inclus dans le pool d'équilibreur de charge qui gère les jobs interactifs, la mémoire principale du processus Looker peut être réduite pour permettre d'autres jobs de rendu. Sur une machine de 64 Go, on peut allouer environ 30% (20 Go) au processus principal de Looker. En réservant 20% pour l'utilisation générale du système d'exploitation, il reste 50% (32 Go) pour le rendu, ce qui est suffisant pour 16 tâches de rendu simultanées.
Base de données interne (backend)
Le serveur Looker conserve les informations sur sa propre configuration, ses connexions à la base de données, ses utilisateurs, ses groupes, ses rôles, ses dossiers, ses Looks et tableaux de bord définis par l'utilisateur, ainsi que sur diverses autres données dans une base de données interne.
Pour une instance Looker autonome de taille moyenne, ces données sont stockées dans une base de données HyperSQL en mémoire intégrée au processus Looker lui-même. Les données de cette base de données sont stockées dans le fichier <looker install directory>/.db/looker.script. Bien que pratique et légère, cette base de données rencontre des problèmes de performances avec une utilisation intensive. Par conséquent, nous vous recommandons de commencer par une base de données MySQL distante. Si ce n'est pas possible, nous vous recommandons de migrer vers une base de données MySQL distante une fois que le fichier ~/looker/.db/looker.script a atteint 600 Mo. Les clusters doivent utiliser une base de données MySQL.
Le serveur Looker effectue de nombreuses opérations de petite taille dans la base de données MySQL. Chaque fois qu'un utilisateur exécute une présentation ou une exploration, Looker vérifie la base de données pour s'assurer qu'il est toujours connecté, qu'il est autorisé à accéder aux données, qu'il a le droit d'exécuter la présentation ou l'exploration, etc. Looker écrira également des données dans la base de données MySQL, comme le code SQL qui a été exécuté et l'heure de début et de fin de la requête. Une seule interaction entre un utilisateur et l'application Looker peut aboutir à 15 ou 20 petites lectures et écritures dans la base de données MySQL.
MySQL
Le serveur MySQL doit être de version 8.0.x et être configuré pour utiliser l'encodage utf8mb4. Vous devez utiliser le moteur de stockage InnoDB. Les instructions de configuration de MySQL, ainsi que celles permettant de migrer les données d'une base de données HyperSQL existante vers MySQL, sont disponibles sur la page de documentation Migrer la base de données backend Looker vers MySQL.
Lorsque vous configurez Looker pour utiliser MySQL, vous devez créer un fichier YAML contenant les informations de connexion. Nommez le fichier YAML looker-db.yml et ajoutez le paramètre -d looker-db.yml dans la section LOOKERARGS du fichier lookerstart.cfg.
MariaDB
MySQL fonctionne sous double licence, disponible à la fois en tant que produit open source et en tant que produit commercial. Oracle a continué à améliorer MySQL, et MySQL a été remplacé par MariaDB. Les versions MariaDB équivalentes de MySQL sont connues pour fonctionner avec Looker, mais elles ne sont pas développées ni testées par les équipes d'ingénierie de Looker. Par conséquent, la fonctionnalité n'est ni prise en charge, ni garantie.
Versions cloud
Si vous hébergez Looker dans votre infrastructure cloud, il est logique d'héberger la base de données MySQL dans la même infrastructure cloud. Les trois principaux fournisseurs de services cloud : Amazon AWS, Microsoft Azure et Google Cloud Les fournisseurs de services cloud gèrent une grande partie de la maintenance et de la configuration de la base de données MySQL et proposent des services tels que l'aide à la gestion des sauvegardes et la récupération rapide. Ces produits fonctionnent bien avec Looker.
Requêtes liées à l'activité du système
La base de données MySQL permet de stocker des informations sur la façon dont les utilisateurs utilisent Looker. Tout utilisateur Looker autorisé à afficher le modèle Activité du système a accès à un certain nombre de tableaux de bord Looker prédéfinis pour analyser ces données. Les utilisateurs peuvent également accéder aux explorations des métadonnées Looker pour créer des analyses supplémentaires. La base de données MySQL est principalement utilisée pour les petites opérations requêtes. L'approche "analytique" à grande échelle, lente les requêtes générées par le modèle Activité du système peuvent concurrencer ces requêtes opérationnelles et ralentir Looker.
Dans ce cas, la base de données MySQL peut être répliquée sur une autre base de données. Les systèmes autogérés et certains systèmes gérés dans le cloud fournissent une configuration de base de la réplication vers d'autres bases de données. La configuration de la réplication n'entre pas dans le cadre de ce document.
Pour utiliser l'instance répliquée pour les requêtes d'activité du système, vous devez créer une copie du fichier looker-db.yml, par exemple nommée looker-usage-db.yml, la modifier pour qu'elle pointe vers l'instance répliquée, puis ajouter le paramètre --internal-analytics-connection-file looker-usage-db.yml.
à la section LOOKERARGS du fichier lookerstart.cfg.
Les requêtes sur l'activité du système peuvent être exécutées sur une instance MySQL ou une base de données Google BigQuery. Elles ne sont pas testées par rapport à d'autres bases de données.
Configuration des performances MySQL
En plus des paramètres requis pour migrer la base de données backend Looker vers MySQL, les clusters très actifs peuvent bénéficier de réglages et de configurations supplémentaires. Ces paramètres peuvent être définis dans le fichier /etc/my.cnf ou via la console Google Cloud pour les instances gérées dans le cloud.
Le fichier de configuration my.cnf est divisé en plusieurs parties. Les modifications de paramètres suivantes, qui sont décrites dans cette section, sont effectuées dans la partie [mysqld].
Définir la taille du pool de mémoire tampon InnoDB
La taille du pool de mémoire tampon InnoDB correspond à la RAM totale utilisée pour stocker l'état des fichiers de données InnoDB en mémoire. Si le serveur est dédié à l'exécution de MySQL, le paramètre innodb_buffer_pool_size doit être défini entre 50 % et 70% de la mémoire système totale.
Si la taille totale de la base de données est petite, vous pouvez définir le pool de mémoire tampon InnoDB sur la taille de la base de données plutôt que sur 50% ou plus de mémoire.
Dans cet exemple, un serveur dispose de 64 Go de mémoire. Par conséquent, la taille du pool de mémoire tampon InnoDB doit être comprise entre 32 Go et 45 Go. Plus la taille est grande, mieux c'est.
[mysqld] ... innodb_buffer_pool_size=45G
Définir les instances de pool de mémoire tampon InnoDB
Lorsque plusieurs threads tentent de rechercher un pool de mémoire tampon volumineux, ils peuvent entrer en conflit. Pour éviter cela, le pool de mémoire tampon est divisé en unités plus petites auxquelles différents threads peuvent accéder sans conflit. Par défaut, le pool de mémoire tampon est divisé en huit instances. Cela crée le potentiel d'un goulot d'étranglement à 8 threads. L'augmentation du nombre d'instances de pool de mémoire tampon réduit le risque de goulot d'étranglement. Le paramètre innodb_buffer_pool_instances doit être défini de sorte que chaque pool de mémoire tampon dispose d'au moins 1 Go de mémoire.
[mysqld] ... innodb_buffer_pool_instances=32
Optimiser le fichier journal InnoDB
Lorsqu'une transaction est validée, la base de données a la possibilité de mettre à jour les données dans le fichier réel ou d'enregistrer les détails de la transaction dans le journal. Si la base de données plante avant la mise à jour des fichiers de données, le fichier journal peut être « relu ». pour appliquer les modifications. L'écriture dans le fichier journal est une petite opération d'ajout. Il est efficace d'ajouter des modifications au journal au moment de la validation, de regrouper plusieurs modifications apportées aux fichiers de données et de les écrire en une seule opération d'E/S. Une fois le fichier journal rempli, la base de données doit suspendre le traitement des nouvelles transactions et réécrire toutes les données modifiées sur le disque.
En règle générale, le fichier journal InnoDB doit être assez volumineux pour contenir une heure de transactions.
Il y a généralement deux fichiers journaux InnoDB. Elles doivent représenter environ 25% de votre pool de mémoire tampon InnoDB. Pour un exemple de base de données avec un pool de mémoire tampon de 32 Go, le total des fichiers journaux InnoDB doit être de 8 Go, soit 4 Go par fichier.
[mysqld] ... innodb_log_file_size=8GB
Configurer la capacité d'E/S InnoDB
MySQL limite la vitesse à laquelle les écritures sont enregistrées sur le disque afin de ne pas surcharger le serveur. Les valeurs par défaut sont conservatrices pour la plupart des serveurs. Pour des performances optimales, utilisez l'utilitaire sysbench pour mesurer la vitesse d'écriture aléatoire sur le disque de données, puis utilisez cette valeur pour configurer la capacité d'E/S afin que MySQL écrive les données plus rapidement.
Sur un système hébergé dans le cloud, le fournisseur de services cloud doit être en mesure de rendre compte des performances des disques utilisés pour le stockage des données. Pour un serveur MySQL auto-hébergé, mesurez la vitesse des écritures aléatoires sur le disque de données en opérations d'E/S par seconde (IOPS). L'utilitaire Linux sysbench est une façon de mesurer cela. Utilisez cette valeur pour innodb_io_capacity_max, et une valeur égale à la moitié à trois quarts de celle-ci pour innodb_io_capacity. Dans l'exemple suivant, nous aurions donc obtenu ces valeurs si nous mesurions 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configurer les threads InnoDB
MySQL ouvrira au moins un thread pour chaque client diffusé. Si de nombreux clients sont connectés simultanément, cela peut entraîner le traitement d'un très grand nombre de threads. Le système peut ainsi passer plus de temps à échanger que à traiter.
Une analyse comparative doit être effectuée pour déterminer le nombre idéal de threads. Pour effectuer un test, définissez le nombre de threads entre le nombre de processeurs (ou cœurs de processeur) sur le système et quatre fois le nombre de processeurs. Pour un système à 16 cœurs, cette valeur est probablement comprise entre 16 et 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilité des transactions
Une valeur de transaction de 1 oblige MySQL à écrire sur le disque pour chaque transaction. Si le serveur plante, la transaction ne sera pas perdue, mais les performances de la base de données en seront affectées. Si vous définissez cette valeur sur 0 ou 2, vous améliorerez les performances, mais vous risquez de perdre quelques secondes. de transactions de données.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Définir la méthode de vidage
Le système d'exploitation effectue normalement la mise en mémoire tampon des écritures sur le disque. Étant donné que MySQL et l'OS sont tous deux mis en mémoire tampon, les performances sont affectées. La réduction de la méthode de vidage d'une couche de mise en mémoire tampon peut améliorer les performances.
[mysqld] ... innodb_flush_method=O_DIRECT
Activer un fichier par table
Par défaut, MySQL utilise un seul fichier de données pour toutes les données. Le paramètre innodb_file_per_table crée un fichier distinct pour chaque table, ce qui améliore les performances et la gestion des données.
[mysqld] ... innodb_file_per_table=ON
Désactiver les statistiques sur les métadonnées
Ce paramètre désactive la collecte de statistiques sur les tables de métadonnées internes, ce qui améliore les performances de lecture.
[mysqld] ... innodb_stats_on_metadata=OFF
Désactiver le cache de requêtes
Le cache de requêtes étant obsolète, il est désactivé lorsque query_cache_size et query_cache_type sont définis sur 0.
[mysqld] ... query_cache_size=0 query_cache_type=0
Agrandir le tampon de jointure
Le join_buffer permet d'effectuer des jointures en mémoire. L'augmenter peut améliorer certaines opérations.
[mysqld] ... join_buffer_size=512KB
Agrandir la table temporaire et la taille maximale des tas de mémoire
Les paramètres tmp_table_size et max_heap_table_size définissent des valeurs par défaut raisonnables pour les tables en mémoire temporaires, avant qu'elles ne soient forcées sur disque.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajuster le cache des tables ouvertes
Le paramètre table_open_cache détermine la taille du cache contenant les descripteurs de fichier pour les tables ouvertes. Le paramètre table_open_cache_instances divise le cache en plusieurs parties plus petites. Il existe un risque de conflit de threads dans table_open_cache. Le diviser en parties plus petites permet donc d'augmenter la simultanéité.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Service Git
Looker est conçu pour fonctionner avec un service Git afin d'assurer la gestion des versions des fichiers LookML. Les principaux services d'hébergement Git sont compatibles, y compris GitHub, GitLab et Bitbucket. Les fournisseurs de services Git offrent des avantages supplémentaires, comme une IUG pour afficher les modifications de code et la prise en charge de workflows tels que les demandes d'extraction et les approbations de modification. Si nécessaire, Git peut être exécuté sur un serveur Linux simple.
Si un service d'hébergement Git ne convient pas à votre déploiement en raison de règles de sécurité, nombre de ces fournisseurs de services proposent des versions qui peuvent être exécutées dans votre propre environnement. GitLab, en particulier, est généralement auto-hébergé et peut être utilisé en tant que produit Open Source sans frais de licence ou en tant que produit sous licence pris en charge. GitHub Enterprise est disponible en tant que service auto-hébergé et constitue un produit commercial pris en charge.
Les sections suivantes répertorient les nuances des fournisseurs de services les plus courants.
GitHub/GitHub Enterprise
La page de documentation Configurer et tester une connexion Git utilise GitHub comme exemple.
GitLab/gitlab.com
Consultez le post de la communauté Looker Utiliser GitLab pour le contrôle des versions dans Looker pour connaître les étapes de configuration détaillées de GitLab. Si votre dépôt est contenu dans des sous-groupes, ceux-ci peuvent être ajoutés à l'URL du dépôt en utilisant le format HTTPS ou SSH:
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
Vous pouvez également stocker les clés SSH générées par Looker dans GitLab de trois manières différentes: en tant que clé SSH utilisateur, clé de déploiement de dépôt ou clé de déploiement partagée globale. Vous trouverez une explication plus détaillée dans la documentation GitLab.
Google Cloud Source
Pour savoir comment configurer Git avec Cloud Source Repositories, consultez le post destiné à la communauté Utiliser Cloud Source Repositories pour le contrôle des versions dans Looker.
Bitbucket Cloud
Consultez le post destiné à la communauté Utiliser Bitbucket pour le contrôle des versions dans Looker pour savoir comment configurer Git avec Bitbucket Cloud. Depuis août 2021, Bitbucket Cloud n'accepte plus les secrets sur les webhooks de déploiement.
Bitbucket Server
Pour utiliser des requêtes pull avec Bitbucket Server, vous devrez peut-être procéder comme suit:
- Lorsque vous ouvrez une demande d'extraction, Looker utilise automatiquement le numéro de port par défaut (7999) dans l'URL. Si vous utilisez un numéro de port personnalisé, vous devrez remplacer manuellement le numéro de port indiqué dans l'URL.
- Vous devrez utiliser le webhook de déploiement du projet pour synchroniser la branche de production dans Looker avec la branche principale du dépôt.
Diffusion de Phabricator
Consultez le post destiné à la communauté Configurer Phabricator et Looker pour le contrôle des versions pour savoir comment configurer Git avec Phabricator.
Réseau
Connexions entrantes
Application Web Looker
Par défaut, Looker écoute les requêtes HTTPS sur le port 9999. Looker utilise un certificat autosigné avec un CN self-signed.looker.com. Il est également possible de configurer le serveur Looker pour:
- Acceptez les connexions HTTP à partir d'un équilibreur de charge/proxy avec terminaison SSL, avec l'option de démarrage
--ssl-provided-externally-by=<s>. La valeur doit être définie sur l'adresse IP du proxy ou sur un nom d'hôte pouvant être résolu localement en adresse IP du proxy. Looker n'acceptera que les connexions HTTP provenant de cette adresse IP. - Utilisez un certificat SSL fourni par le client, avec l'option de démarrage
--ssl-keystore=<s>.
API Looker
L'API Looker écoute sur le port 19999. Si l'installation nécessite un accès à l'API, l'équilibreur de charge doit disposer des règles de transfert requises. Les mêmes considérations SSL s'appliquent que pour l'application Web principale. Nous vous recommandons d'utiliser un port distinct de l'application Web.
Équilibreurs de charge
Un équilibreur de charge est souvent utilisé pour accepter une requête HTTPS sur le port 443 à l'aide du certificat du client, puis transmettre la requête au nœud du serveur Looker sur le port 9999 à l'aide du certificat autosigné ou HTTP. Si les équilibreurs de charge utilisent le certificat autosigné de Looker, ils doivent être configurés pour accepter ce certificat.
Connexions inactives et délais avant expiration
Lorsqu'un utilisateur lance une requête importante dans Looker, cela peut entraîner une requête dont l'exécution sur la base de données peut coûter cher. Si l'utilisateur abandonne cette requête de quelque façon que ce soit, par exemple en fermant le capot de son ordinateur portable, en se déconnectant du réseau ou en supprimant cet onglet du navigateur, Looker souhaite en savoir plus et mettre fin à cette requête de base de données.
Pour gérer cette situation, lorsque l'application Web cliente envoie une requête pour exécuter une requête de base de données, le navigateur ouvre une connexion de socket à l'aide d'une requête HTTP de longue durée adressée au serveur Looker. Cette connexion restera ouverte et inactive. Ce socket sera déconnecté si l'application Web cliente est fermée ou déconnectée de quelque manière que ce soit. Le serveur se déconnecte et annule toutes les requêtes de base de données associées.
Les équilibreurs de charge remarquent souvent ces connexions inactives ouvertes et les suppriment. Pour une exécution efficace de Looker, l'équilibreur de charge doit être configuré de sorte que cette connexion reste ouverte aussi longtemps que la requête la plus longue qu'un utilisateur peut exécuter. Nous suggérons un délai avant expiration d'au moins 60 minutes.
Connexions sortantes
Les serveurs Looker peuvent disposer d'un accès sortant illimité à toutes les ressources, y compris l'Internet public. Cela simplifie de nombreuses tâches, comme l'installation de Chromium, qui nécessite un accès aux dépôts de packages pour la distribution Linux.
Vous trouverez ci-dessous des connexions sortantes que Looker devra peut-être établir.
Connexion à la base de données interne
Par défaut, MySQL écoute les connexions sur le port 3306. Les nœuds Looker doivent pouvoir établir des connexions à MySQL sur ce port. Selon la manière dont le dépôt est hébergé, vous devrez peut-être traverser un pare-feu.
Services externes
Les serveurs de télémétrie et de licence Looker sont disponibles via HTTPS sur l'Internet public. Vous devrez peut-être ajouter le trafic d'un nœud Looker vers ping.looker.com:443 et license.looker.com:443 à une liste d'autorisation.
Connexions à l'entrepôt de données
Les bases de données hébergées dans le cloud peuvent nécessiter une connexion utilisant l'Internet public. Par exemple, si vous utilisez BigQuery, vous devrez peut-être ajouter accounts.google.com:443 et www.googleapis.com:443 à une liste d'autorisation. Si la base de données se trouve en dehors de votre propre infrastructure, contactez l'hôte de votre base de données pour obtenir des détails sur le réseau.
Services SMTP
Par défaut, Looker envoie des e-mails sortants à l'aide de SendGrid. Pour cela, vous devrez peut-être ajouter smtp.sendgrid.net:587 à une liste d'autorisation. Il est possible de modifier les paramètres SMTP dans la configuration afin d'utiliser également un autre gestionnaire de messagerie.
Hubs d'action, serveurs d'action et webhooks
De nombreuses destinations de planificateur, en particulier les webhooks et celles activées dans le panneau d'administration Looker, impliquent l'envoi de données à l'aide de requêtes HTTPS.
- Pour les webhooks, ces destinations sont spécifiées au moment de l'exécution par les utilisateurs, ce qui peut aller à l'encontre de l'objectif de pare-feu des connexions sortantes.
- Pour un hub d'action, ces requêtes sont envoyées à
actions.looker.com. Pour en savoir plus, consultez la documentation de configuration de Looker Action Hub. - Pour les autres serveurs d'action, ces requêtes sont envoyées aux domaines spécifiés par les administrateurs dans la configuration du serveur d'actions dans le panneau d'administration Looker.
Serveur proxy
S'il n'est pas possible d'accéder directement à l'Internet public, Looker peut être configuré pour utiliser un serveur proxy pour les requêtes HTTP(S) en ajoutant une ligne semblable à celle-ci à lookerstart.cfg:
JAVAARGS="-Dhttp.proxyHost=myproxy.example.com -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=127.0.0.1|localhost -Dhttps.proxyHost=myproxy.example.com -Dhttps.proxyPort=8080"
Notez que les communications entre les nœuds s'effectuent via HTTPS. Par conséquent, si vous utilisez un serveur proxy et que votre instance est en cluster, vous voudrez généralement ajouter les adresses IP/noms d'hôte de tous les nœuds du cluster à l'argument Dhttp.nonProxyHosts.
Communications entre nœuds
Identifiant d'hôte interne
Dans un cluster, chaque nœud doit pouvoir communiquer avec les autres nœuds. Pour ce faire, le nom d'hôte ou l'adresse IP de chaque nœud est spécifié dans la configuration de démarrage. Au démarrage du nœud, cette valeur est écrite dans le dépôt MySQL. Les autres membres du cluster peuvent ensuite se référer à ces valeurs pour communiquer avec ce nœud. Pour spécifier le nom d'hôte ou l'adresse IP dans la configuration de démarrage, ajoutez -H node1.looker.example.com à la variable d'environnement LOOKERARGS dans lookerstart.cfg.
Étant donné que le nom d'hôte doit être unique pour chaque nœud, le fichier lookerstart.cfg doit être unique sur chaque instance. Au lieu de coder en dur le nom d'hôte ou l'adresse IP, vous pouvez utiliser la commande hostname -I ou hostname --fqdn pour les trouver au moment de l'exécution. Pour implémenter cela, ajoutez -H $(hostname -I) ou -H $(hostname --fqdn) à la variable d'environnement LOOKERARGS dans lookerstart.cfg.
Ports internes
En plus des ports 9999 et 19999 utilisés respectivement pour les serveurs Web et d'API, les nœuds du cluster communiqueront entre eux via un service de courtier de messages, qui utilise les ports 1551 et 61616. Les ports 9999 et 19999 doivent être ouverts au trafic des utilisateurs finaux, tandis que les ports 1551 et 61616 doivent l'être entre les nœuds du cluster.