Cette page présente les pratiques courantes concernant des composants spécifiques de l'architecture Looker et explique comment les configurer dans un déploiement.
Looker présente un certain nombre de dépendances pour héberger le serveur, gérer les charges de travail ad hoc et planifiées, suivre le développement itératif des modèles, etc. Ces dépendances sont appelées composants sur cette page. Chaque composant est décrit 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 simple d'utiliser Debian/Ubuntu ou un système d'exploitation dérivé de Debian/Ubuntu pour un fournisseur de services cloud spécifique.
Looker s'exécute dans la machine virtuelle Java (JVM). Lorsque vous choisissez une distribution, vérifiez si les versions d'OpenJDK 11 sont à jour. Il est possible que les distributions Linux plus anciennes puissent exécuter Looker, mais la version et les bibliothèques Java requises par Looker 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, cela n'est généralement pas suffisant. D'après notre expérience, les nœuds 16x64 (16 CPU et 64 Go de RAM) offrent un bon équilibre entre prix et performances. Plus de 64 Go de RAM peuvent affecter les performances, car les événements de récupération de mémoire sont monothread 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 JVM Java, et Java peut avoir du mal à gérer une mémoire supérieure à 64 Go. En règle générale, si vous avez besoin de plus de capacité, vous devez ajouter des nœuds 16x64 supplémentaires au cluster plutôt que d'augmenter la taille des nœuds au-delà de 16x64. Nous pouvons également préférer utiliser une architecture en cluster pour améliorer 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 un certain nombre de dépôts Git, la gestion de l'accès simultané et du verrouillage des fichiers est essentielle. Le système de fichiers doit être compatible avec POSIX. Le système de fichiers réseau (NFS) est connu pour fonctionner et est facilement disponible avec Linux. Vous devez créer une instance Linux supplémentaire et configurer NFS pour partager le disque. Le service 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 ressources 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 exceptions 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 évoluer avec la mémoire totale de la machine, mais 1 Go devrait suffire pour Meta.
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 adaptées à chaque déploiement varient. Utilisez donc 60 % comme référence et ajustez-la en fonction de l'utilisation.
Récupération de mémoire
Looker préfère utiliser le garbage collector le plus moderne disponible pour sa version Java. Par défaut, le délai d'expiration du garbage collection est de deux secondes, mais vous pouvez le modifier 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 de 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 est extrait du script shell qui démarre 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, des considérations particulières s'appliquent aux topologies de cluster mentionnées sur la page Modèles et pratiques d'architecture d'infrastructure hébergée par le client.
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 d'ordonnancement dédiés, ajoutez --scheduler-threads=<n> à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Par défaut, Looker démarre avec 10 threads de planification, mais ce nombre peut être augmenté jusqu'à <n>. Avec <n> threads de planification, chaque nœud peut exécuter <n> tâches de planification simultanées. 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, aucun travail 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, vous pouvez allouer environ 30 % (20 Go) au processus de base Looker. En réservant 20 % pour l'utilisation générale de l'OS, il reste 50 % (32 Go) pour le rendu, ce qui suffit pour 16 tâches de rendu simultanées.
Base de données interne (backend)
Le serveur Looker gère des informations sur sa propre configuration, les connexions aux bases de données, les utilisateurs, les groupes et les rôles, les dossiers, les looks et les tableaux de bord définis par l'utilisateur, ainsi que 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 qu'elle soit pratique et légère, cette base de données rencontre des problèmes de performances en cas d'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 petites lectures et écritures 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 que l'utilisateur 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 écrit également des données dans la base de données MySQL, telles que le code SQL 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 entraîner 15 ou 20 petites lectures et écritures dans la base de données MySQL.
MySQL
Le serveur MySQL doit être de la version 8.0.x et doit être configuré pour utiliser l'encodage utf8mb4. Le moteur de stockage InnoDB doit être utilisé. Les instructions de configuration de MySQL, ainsi que les instructions de migration des 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 est doublement licencié, 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énieurs Looker. Par conséquent, leur fonctionnalité n'est pas 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 sert à 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. Les requêtes "analytiques" volumineuses, lentes et générées par le modèle d'activité du système peuvent entrer en concurrence avec 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 d'un réglage et d'une configuration 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 quantité totale de RAM 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, le pool de tampons InnoDB doit être compris entre 32 Go et 45 Go. Plus la zone 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 peut mettre à jour les données du fichier réel ou enregistrer des informations sur 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 une base de données avec un pool de mémoire tampon de 32 Go, les fichiers journaux InnoDB doivent totaliser 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 l'un des moyens de le mesurer. Utilisez cette valeur pour innodb_io_capacity_max et une valeur comprise entre la moitié et les trois quarts de cette valeur pour innodb_io_capacity. Ainsi, dans l'exemple suivant, nous verrions 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, un grand nombre de threads peuvent être traités. Cela peut entraîner un temps de swap plus long que le temps de traitement.
Des benchmarks doivent être effectués pour déterminer le nombre idéal de threads. Pour effectuer le test, définissez le nombre de threads entre le nombre de processeurs (ou de cœurs de processeur) du 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. Définir cette valeur sur 0 ou 2 peut améliorer 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 généralement la mise en mémoire tampon des écritures sur le disque. Étant donné que MySQL et l'OS utilisent tous deux la mise en tampon, les performances sont affectées. Réduire 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
Augmenter la taille de la table temporaire et des tailles de tas maximales
tmp_table_size et max_heap_table_size définissent des valeurs par défaut raisonnables pour les tables temporaires en mémoire, 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 qui contient les descripteurs de fichiers 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 de gérer les 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 standard.
Si un service d'hébergement Git n'est pas adapté à votre déploiement en raison de règles de sécurité, de nombreux fournisseurs de services proposent des versions pouvant ê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 avec assistance. GitHub Enterprise est disponible en tant que service auto-hébergé et est un produit commercial pris en charge.
Les sections suivantes présentent les différences entre les 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
Pour connaître la procédure de configuration détaillée de GitLab, consultez l'article de la communauté Looker Utiliser GitLab pour le contrôle des versions dans Looker. 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
Consultez le post de la communauté Utiliser Cloud Source Repositories pour le contrôle des versions dans Looker pour découvrir comment configurer Git avec Cloud Source Repositories.
Bitbucket Cloud
Pour savoir comment configurer Git avec Bitbucket Cloud, consultez l'article de la communauté Utiliser Bitbucket pour le contrôle des versions dans Looker. Depuis août 2021, Bitbucket Cloud n'est pas compatible avec les secrets dans 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 de tirage, 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 devez le remplacer manuellement dans l'URL.
- Vous devez appeler 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. Le serveur Looker peut également être configuré pour effectuer les opérations suivantes :
- 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 qui peut être résolu localement en adresse IP du proxy. Looker n'acceptera les connexions HTTP que depuis cette adresse IP. - Utilisez un certificat SSL fourni par le client, avec l'indicateur 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 qu'avec 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 pour transférer la requête vers le nœud de serveur Looker sur le port 9999 à l'aide du certificat autosigné ou du protocole 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 volumineuse dans Looker, il peut en résulter une requête dont l'exécution sur la base de données peut être coûteuse. 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 verra cette déconnexion et annulera 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 exécuter Looker efficacement, l'équilibreur de charge doit être configuré pour permettre à cette connexion de rester 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 l'accès aux dépôts de paquets de 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 façon dont le dépôt est hébergé, vous devrez peut-être passer par un pare-feu.
Services externes
Les serveurs de télémétrie et de licence Looker sont disponibles sur l'Internet public via HTTPS. 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 la base de données pour obtenir des informations sur le réseau.
Services SMTP
Par défaut, Looker envoie des e-mails sortants à l'aide de SendGrid. Vous devrez peut-être ajouter smtp.sendgrid.net:587 à une liste d'autorisation. Vous pouvez également modifier les paramètres SMTP dans la configuration pour utiliser 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'actions, ces requêtes sont envoyées à
actions.looker.com. Pour en savoir plus, consultez notre documentation de configuration de Looker Action Hub. - Pour les autres serveurs d'actions, ces requêtes sont envoyées aux domaines spécifiés dans la configuration du serveur d'actions par les administrateurs dans le panneau Administration de Looker.
Serveur proxy
Si l'Internet public n'est pas accessible directement, Looker peut être configuré pour utiliser un serveur proxy pour les requêtes HTTP(S) en ajoutant une ligne semblable à la suivante à 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 souhaiterez 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 pour le trafic des utilisateurs finaux, mais les ports 1551 et 61616 doivent être ouverts entre les nœuds du cluster.