Solutions d'architecture hébergées par le client: présentation des composants

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 présente un certain nombre de dépendances pour héberger le serveur, traiter les charges de travail ponctuelles 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

OS et distribution

Looker fonctionne bien sur les versions les plus courantes de Linux : RedHat, SUSE et Debian/Ubuntu. Les dérivés de ces distributions conçus et optimisés pour s'exécuter dans un environnement particulier sont généralement acceptés. Par exemple, les distributions Linux Google Cloud ou AWS sont compatibles avec Looker. Debian/Ubuntu est la variante Linux la plus utilisée dans la communauté Looker. L'assistance Looker connaît donc bien ces versions. 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, vérifiez si les versions d'OpenJDK 11 sont à jour. Les anciennes distributions de Linux peuvent être en mesure d'exécuter Looker, mais la version et les bibliothèques Java dont Looker a besoin pour des fonctionnalités spécifiques 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

Les nœuds 4x16 (4 processeurs et 16 Go de RAM) suffisent pour un système de développement ou une instance Looker de test de base utilisée par une petite équipe. Toutefois, pour une utilisation en production, cela ne suffit généralement pas. D'après notre expérience, 16 nœuds x 64 (16 CPU et 64 Go de RAM) offrent un bon équilibre entre prix et performances. Plus de 64 Go de RAM peuvent avoir un impact sur les performances, car les événements de récupération de mémoire sont monothread et interrompent tous les autres threads pour s'exécuter.

Stockage sur disque

100 Go d'espace disque sont généralement plus que suffisants pour un système de production.

Considérations relatives aux clusters

Looker s'exécute sur une JVM Java, et Java peut avoir des difficultés à 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 une disponibilité accrue.

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
  • Modèles LookML du développeur
  • 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 des accès simultanés et du verrouillage des fichiers est essentielle. Le système de fichiers doit être conforme à 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 système NFS par défaut peut potentiellement être un point de défaillance unique. Envisagez donc une configuration de basculement ou de haute disponibilité.

Les métadonnées Looker doivent également être centralisées. Par conséquent, leur 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é. Pour en savoir plus, consultez la section Base de données interne (backend) sur cette page.

Configuration de la JVM

Les paramètres JVM de Looker sont définis dans le script de démarrage de Looker. Après toute mise à jour, Looker doit être redémarré pour que les modifications soient prises en compte. 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 Looker. 

JAVAMEM="2300m"
METAMEM="800m"

L'allocation de mémoire pour la JVM doit tenir compte de la surcharge du système d'exploitation sur lequel Looker s'exécute. En règle générale, la JVM peut se voir allouer jusqu'à 60 % de la mémoire totale, mais il existe des exceptions en fonction de la taille de la machine. Pour les machines disposant du minimum requis de 8 Go de mémoire totale, nous recommandons d'allouer 4 à 5 Go à Java et 800 Mo à Meta. Pour les machines plus volumineuses, une plus faible 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 d'allouer 36 Go à Java et 1 Go à Meta. Il est important de noter que l'allocation de mémoire de Java doit généralement être proportionnelle à la mémoire totale de la machine, mais que Meta devrait être suffisant à 1 Go.

De plus, comme 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 est censée être faible, une plus grande partie de la mémoire totale peut être allouée à Java. Par exemple, sur une machine disposant de 60 Go de mémoire totale, vous pouvez allouer 46 Go à Java sans risque, ce qui est supérieur à la recommandation générale de 60 %. L'allocation exacte des ressources appropriée pour chaque déploiement varie. 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 collecteur de déchets le plus récent disponible pour sa version Java. Par défaut, le délai d'expiration du garbage collector est de deux secondes, mais vous pouvez le modifier en éditant l'option suivante dans la configuration de démarrage : 

-XX:MaxGCPauseMillis=2000

Sur une machine plus grande avec plusieurs cœurs, le délai d'expiration du garbage collection 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 modifier ce comportement, 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 l'allocation des ressources. Nous vous recommandons d'utiliser JMX pour surveiller l'utilisation de la mémoire JVM.

Options de démarrage de Looker

Les options de démarrage sont stockées dans un fichier appelé lookerstart.cfg. Ce fichier est utilisé dans le script shell qui démarre Looker.

Pools de threads

En tant qu'application multithread, Looker dispose de plusieurs pools de threads. Ces pools de threads vont du serveur Web principal aux sous-services spécialisés tels que la planification, le rendu et les connexions à des bases de données externes. En fonction de vos workflows d'entreprise, vous devrez peut-être modifier ces pools par rapport à la configuration par défaut. En particulier, il existe des considérations spéciales pour les topologies de cluster mentionnées sur la page Pratiques et modèles d'architecture d'infrastructure hébergée par le client.

Options de programmation à haut débit

Pour tous les nœuds non planificateurs, ajoutez --scheduler-threads=0 à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Sans threads de programmateur, aucune tâche planifiée ne s'exécutera sur ces nœuds.

Pour tous les nœuds de planification dédiés, ajoutez --scheduler-threads=<n> à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Looker commence avec 10 threads de planification par défaut, mais ce nombre peut être augmenté à <n>. Avec <n> threads de planification, chaque nœud sera en mesure d'exécuter <n> tâches de planification simultanées. Il est généralement recommandé de conserver <n> inférieur à deux fois le nombre de processeurs. L'hôte le plus grand recommandé est celui qui dispose de 16 processeurs et de 64 Go de mémoire. La limite supérieure des threads du planificateur doit donc être inférieure à 32.

Options de rendu à haut débit

Pour tous les nœuds non liés au rendu, ajoutez --concurrent-render-jobs=0 à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Sans nœuds de rendu, aucun job 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. Par défaut, Looker commence avec deux threads de rendu, mais ce nombre peut être augmenté à <n>. Avec <n> threads de rendu, chaque nœud sera capable d'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 Looker principal (Java) se voit allouer 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 disponibles pour les 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 de l'équilibreur de charge qui gère les jobs interactifs, la mémoire du processus Looker principal peut être réduite pour permettre davantage de jobs de rendu. Sur une machine de 64 Go, vous pouvez allouer environ 30 % (20 Go) au processus Looker Core. En réservant 20 % pour l'utilisation générale de l'OS, 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 des informations sur sa propre configuration, les connexions à la base 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 que pratique et légère, cette base de données rencontre des problèmes de performances en cas d'utilisation intensive. Nous vous recommandons donc de commencer par une base de données MySQL à distance. Si cela 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 atteint 600 Mo. Les clusters doivent utiliser une base de données MySQL.

Le serveur Looker effectue de nombreuses petites opérations de lecture et d'écriture dans la base de données MySQL. Chaque fois qu'un utilisateur exécute un Look ou une exploration, Looker vérifie dans la base de données que l'utilisateur est toujours connecté, qu'il dispose des droits d'accès aux données, qu'il dispose des droits d'exécution du Look ou de l'exploration, etc. Looker écrira également des données dans la base de données MySQL, telles que le code SQL réel qui a été exécuté, ainsi que 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 à 20 petites lectures et écritures dans la base de données MySQL.

MySQL

Le serveur MySQL doit être en 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 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 est soumis à une double licence. Il est disponible à la fois en tant que produit Open Source et en tant que produit commercial. Oracle a continué à améliorer MySQL, qui a été dupliqué sous le nom de MariaDB. Les versions MariaDB équivalentes de MySQL sont connues pour fonctionner avec Looker, mais elles n'ont pas été développées ni testées par les équipes d'ingénierie 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 la gestion des sauvegardes et la récupération rapide. Ces produits sont connus pour bien fonctionner avec Looker.

Requêtes sur l'activité du système

La base de données MySQL est utilisée pour 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 effectuer des analyses supplémentaires. La base de données MySQL est principalement utilisée pour les requêtes opérationnelles petites et rapides. Les requêtes analytiques volumineuses et lentes 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 dans une autre base de données. Les systèmes autogérés et certains systèmes gérés dans le cloud permettent 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 le réplica pour les requêtes sur l'activité du système, vous allez créer une copie du fichier looker-db.yml (par exemple, looker-usage-db.yml), la modifier pour qu'elle pointe vers le réplica et 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 de 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'une optimisation et d'une configuration supplémentaires. Ces paramètres peuvent être définis dans le fichier /etc/my.cnf ou dans 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 décrites dans cette section sont apportées à 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, innodb_buffer_pool_size doit être défini sur 50 à 70 % de la mémoire système totale.

Si la taille totale de la base de données est faible, 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 la mémoire.

Dans cet exemple, un serveur dispose de 64 Go de mémoire. Le pool de mémoire tampon InnoDB doit donc être compris entre 32 et 45 Go. Plus la zone est grande, mieux c'est. 

[mysqld]
...
innodb_buffer_pool_size=45G

Définir les instances du pool de mémoire tampon InnoDB

Lorsque plusieurs threads tentent de rechercher un grand pool de mémoire tampon, 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 peut entraîner un goulot d'étranglement à huit threads. Augmenter le nombre d'instances de pool de mémoire tampon réduit le risque de goulot d'étranglement. La valeur de innodb_buffer_pool_instances doit être définie 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 choisir 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 au journal au moment du commit, puis de regrouper plusieurs modifications apportées aux fichiers de données et de les écrire en une seule opération d'E/S. Lorsque le fichier journal est plein, 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 suffisamment volumineux pour contenir une heure de transactions.

Il existe 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 exemple 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 d'InnoDB

MySQL limitera la vitesse à laquelle les écritures sont enregistrées sur le disque afin de ne pas surcharger le serveur. Les valeurs par défaut sont prudentes 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 fournir des informations sur les 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 celle-ci pour innodb_io_capacity. Ainsi, dans l'exemple suivant, nous verrions les valeurs si nous mesurions 800 IOPS. 

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

Configurer les threads InnoDB

MySQL ouvre au moins un thread pour chaque client desservi. Si de nombreux clients sont connectés simultanément, cela peut entraîner le traitement d'un grand nombre de threads. Cela peut entraîner une perte de temps pour le système, qui passe plus de temps à échanger des données qu'à les traiter.

Des benchmarks doivent être effectués pour déterminer le nombre idéal de threads. Pour effectuer un test, définissez le nombre de threads sur une valeur comprise 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 force 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 seront affectées. Définir cette valeur sur 0 ou 2 peut améliorer les performances, mais au risque 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 met normalement en mémoire tampon les écritures sur le disque. Comme MySQL et l'OS mettent en mémoire tampon, les performances sont pénalisé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 tableau, 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, le fait de définir query_cache_size et query_cache_type sur 0 le désactive. 

[mysqld]
...
query_cache_size=0
query_cache_type=0

Agrandir le tampon de jointure

join_buffer est utilisé pour 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 du tas de mémoire

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 le 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 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 fait de le diviser en parties plus petites permet d'accroître 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 proposent des avantages supplémentaires, tels qu'une interface utilisateur graphique pour afficher les modifications de code et la prise en charge de workflows tels que les demandes d'extraction et les approbations de modifications. 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é, sachez que la plupart de ces fournisseurs de services proposent des versions qui peuvent être exécutées dans votre propre environnement. GitLab, en particulier, est souvent 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 compatible.

Les sections suivantes listent les nuances pour 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 obtenir des instructions de configuration détaillées pour GitLab, consultez le post 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, vous pouvez les ajouter à l'URL du dépôt au format HTTPS ou SSH : 

https://gitlab.com/accountname/subgroup/reponame


git@gitlab.com:accountname/subgroup/reponame.git

De plus, vous pouvez 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, en tant que clé de déploiement de dépôt ou en tant que clé de déploiement partagée globale. Pour en savoir plus, consultez 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 savoir comment configurer Git avec Cloud Source Repositories.

Bitbucket Cloud

Consultez le post de 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 pas les secrets sur les Webhooks de déploiement.

Bitbucket Server

Pour utiliser les requêtes d'extraction avec Bitbucket Server, vous devrez peut-être effectuer les étapes suivantes :

  1. 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 le remplacer manuellement dans l'URL.
  2. Vous devrez accéder au webhook de déploiement du projet pour synchroniser la branche de production dans Looker avec la branche principale du dépôt.

Diffusion Phabricator

Pour savoir comment configurer Git avec Phabricator, consultez le post de la communauté Configurer Phabricator et Looker pour le contrôle des versions.

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 nom commun (CN) de self-signed.looker.com. Le serveur Looker peut également être configuré pour effectuer les opérations suivantes :

  1. Acceptez les connexions HTTP à partir d'un équilibreur de charge/proxy avec terminaison SSL, avec l'indicateur 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 qu'à partir de cette adresse IP.
  2. 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 d'accéder à 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 celui 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 transférer 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é 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, cela peut entraîner une requête coûteuse à exécuter sur la base de données. Si l'utilisateur abandonne cette requête de quelque manière que ce soit (par exemple, en fermant le couvercle de son ordinateur portable, en se déconnectant du réseau ou en fermant cet onglet dans le navigateur), Looker souhaite le savoir 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 socket à l'aide d'une requête HTTP de longue durée au serveur Looker. Cette connexion restera ouverte et inactive. Ce socket sera déconnecté si l'application Web cliente est arrêté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 interrompent. Pour que Looker s'exécute efficacement, l'équilibreur de charge doit être configuré pour que cette connexion reste ouverte aussi longtemps que la requête la plus longue qu'un utilisateur peut exécuter. Nous vous suggérons de définir un délai d'inactivité 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 packages pour la distribution Linux.

Vous trouverez ci-dessous les connexions sortantes que Looker peut avoir besoin d'établir.

Connexion à une base de données interne

Par défaut, MySQL écoute les connexions sur le port 3306. Les nœuds Looker doivent pouvoir initier des connexions à MySQL sur ce port. Selon la façon 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. Il peut être nécessaire d'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 à 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 votre hébergeur de base de données pour obtenir des informations sur le réseau.

Services SMTP

Par défaut, Looker envoie les e-mails sortants à l'aide de SendGrid. Cela peut nécessiter l'ajout de 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.

Action hubs, serveurs d'actions et webhooks

De nombreuses destinations de planification, 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 et peuvent être contraires à l'objectif de pare-feu des connexions sortantes.
  • Pour un hub d'actions, ces demandes sont envoyées à actions.looker.com. Pour en savoir plus, consultez notre documentation sur la configuration de l'Action Hub Looker.
  • 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 Admin de Looker.

Serveur proxy

Si l'Internet public n'est pas directement accessible, vous pouvez configurer Looker pour qu'il utilise un serveur proxy pour les requêtes HTTP(S). Pour ce faire, ajoutez une ligne comme celle ci-dessous à 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 se font via HTTPS. Par conséquent, si vous utilisez un serveur proxy et que votre instance est en cluster, vous devez généralement ajouter les adresses IP/noms d'hôte de tous les nœuds du cluster à l'argument Dhttp.nonProxyHosts.

Communications entre les 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. Lorsque le nœud démarre, cette valeur est écrite dans le dépôt MySQL. Les autres membres du cluster peuvent ensuite faire référence à 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 les commandes hostname -I ou hostname --fqdn pour les trouver au moment de l'exécution. Pour ce faire, 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, qui sont utilisés respectivement pour les serveurs Web et d'API, les nœuds du cluster communiquent 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, mais les ports 1551 et 61616 doivent être ouverts entre les nœuds du cluster.