Tableau Server dans un conteneur - Dépannage

Introduction

Tableau Server dans un conteneur est la première offre de Tableau d’un serveur basé sur un conteneur. Tableau Server dans un conteneur est une instance Tableau Server tout-en-un qui s’exécute dans un conteneur Linux Docker. En d’autres termes, une image Tableau Server dans un conteneur est une image Docker qui exécute une application Tableau Server autonome complète. Tableau Server dans un conteneur est notre première étape parmi de nombreuses étapes prenant en charge l’exécution de Tableau Server dans des environnements basés sur un conteneur. Pour comprendre simplement le concept de de Tableau Server dans un conteneur, considérez-le comme une machine virtuelle sur laquelle Tableau Server est préinstallé. L’image est basée sur une image UBI 8 Image(CentOS 7.x pour la version 2022.1 et les versions antérieures) et exécute supervisord (au lieu de systemd) à l’intérieur du conteneur. Lorsque le conteneur démarre supervisord, il tente immédiatement d’initialiser et de démarrer Tableau Server. Une grande partie de la présente documentation s’applique à décrire comment automatiser la configuration et l’utilisation afin que vous puissiez exécuter Tableau Server dans des environnements Docker.

L’outil d’installation de l’image Tableau Server dans un conteneur vous aide à créer et à personnaliser les images de conteneur de manière à inclure des packages et des artefacts personnalisés. L’une des fonctions principales de l’outil consiste à créer l’image du conteneur et à installer des connecteurs de données personnalisés.

Pour tester rapidement une image Tableau Server dans un conteneur dans des scénarios de faisabilité, consultez Tableau Server dans un conteneur - Démarrage rapide.

Limites

  • Tableau Server dans un conteneur prend uniquement en charge l’activation de licence à l’aide de Server ATR, ce qui nécessite que le conteneur puisse accéder à Internet. Par conséquent, l’activation hors ligne dans un environnement en air gap n’est pas possible.
  • Tableau Server dans un conteneur ne prend actuellement pas en charge l’agent Resource Monitoring Tool (RMT).
  • Tableau Server dans un conteneur ne prend pas en charge Kerberos.

Résolution des problèmes

Si vous rencontrez des problèmes lors de l’exécution de Tableau Server, plusieurs possibilités s’ouvrent à vous pour trouver une solution. Cette section couvre les conseils généraux de dépannage de Tableau Server, tels que l’emplacement des fichiers journaux et leur signification. Elle couvre également des cas de figure et des chemins de migration spécifiques connus.

Si vous travaillez avec l’assistance Tableau pour déboguer un problème, il peut être utile de fournir les éléments suivants :

  • Fichiers journaux Tableau Server (la collecte de ces fichiers journaux est expliquée ci-dessous).
  • Fichiers journaux du conteneur Docker stdout .
  • Dockerfile de Tableau Server (si des personnalisations ont été apportées).
  • Configuration de déploiement comprenant :

    • Kubeconfig (ou toute configuration de déploiement équivalente).
    • Fichiers de configuration statiques qui configurent le conteneur Tableau Server.

Échecs d’installation et d’initialisation

Si vous initialisez Tableau Server pour la première fois, ou si vous avez effectué une nouvelle installation dans un conteneur, le redémarrage du conteneur ne suffira pas à récupérer le serveur. Chaque tentative d’installation doit utiliser un répertoire de données nouveau. Vous devrez alors peut-être supprimer les données de volume persistantes des précédentes exécutions de conteneurs. Dans ce cas, veillez à sauvegarder les fichiers journaux et les données qui pourraient être utiles pour le débogage.

Débogage de l’échec de l’installation

Les conteneurs Tableau Server sont conçus pour se fermer en cas d’échec de l’installation. Ce modèle facilite l’automatisation et l’identification en cas d’échec de l’installation. Il peut toutefois rendre le débogage difficile car le conteneur se fermera et ne laissera aucun état d’exécution examinable. Si vous souhaitez avoir une session de débogage dans un conteneur en cours d’exécution qui échoue lors de l’initialisation, procédez comme suit :

  1. Préparez un nouveau déploiement Tableau Server dans un conteneur.
  2. Configurez le conteneur pour qu’il s’exécute avec la variable d’environnement TSM_ONLY=1. La variable d’environnement TSM_ONLY=1 indique à Tableau Server d’initialiser uniquement TSM, ce qui revient à exécuter simplement le script initialize-tsm dans une installation standard sans conteneur.
  3. Exécutez le conteneur Tableau Server.
  4. Ouvrez un interpréteur de commandes à l’intérieur du conteneur.
  5. Vous pouvez désormais exécuter des commandes TSM, même si Tableau Server n’a pas été initialisé. Pour reprendre l’automatisation qui se déroule normalement lors de l’initialisation, exécutez le script tsm-commands : "${DOCKER_CONFIG}"/config/tsm-commands

Assistance Tableau et Kubernetes

Tableau Server dans un conteneur peut être exécuté à l’aide de Kubernetes, mais ce n’est pas obligatoire. Nous nous attendons à ce que la plupart des clients utilisent Kubernetes ou l’un de ses environnements de nuage gérés associés (EKS, AKS ou GKS) pour exécuter et gérer Tableau Server dans un conteneur.

Kubernetes peut être un environnement complexe à exécuter et à déboguer et comprend souvent des dépendances sur l’infrastructure et la configuration de chaque entreprise. Pour cette raison, l’assistance Tableau ne peut pas aider les clients à résoudre les problèmes de Kubernetes (ou de déploiement d’infrastructure) associés à l’exécution de Tableau Server dans un conteneur. Tableau prend en charge toutefois l’exécution de Tableau Server dans un conteneur Docker. Par conséquent, si vous rencontrez des problèmes avec l’exécution de Tableau Server dans un conteneur utilisant Kubernetes, l’assistance Tableau peut aller jusqu’à valider le fonctionnement correct du conteneur Docker par lui-même, mais pas au-delà.

Pour plus d’informations sur l’exécution de Tableau Server dans un conteneur à l’aide de Kubernetes, consultez ce site Github : https://github.com/tableau/tableau-server-in-kubernetes(Le lien s’ouvre dans une nouvelle fenêtre).

Fichiers journaux

Les fichiers journaux sont une ressource essentielle pour rechercher, comprendre et résoudre les problèmes dans Tableau Server. Ils aideront nos équipes d’assistance à trouver la cause des problèmes que vous rencontrez. Les fichiers journaux peuvent également être utiles pour votre propre débogage et dépannage.

Extraction de tous les fichiers journaux

Si vous avez besoin d’extraire tous les fichiers journaux pour un débogage ultérieur ou pour les envoyer à nos équipes d’assistance, il existe plusieurs méthodes pour récupérer cette information.

Fichiers ziplog

TSM peut créer une archive compressée contenant tous les fichiers journaux de serveur pertinents. Vous pouvez déclencher cette opération en exécutant la commande tsm maintenance ziplogs. Une fois la commande terminée, elle indiquera le chemin du fichier de l’archive du fichier journal. Vous devrez copier l’archive en utilisant la méthode de transfert de fichiers la plus adaptée à votre situation. Pour des détails sur les fichiers ziplog, consultez tsm maintenance ziplogs.

Exemple de commande exécutée dans le conteneur :

tsm maintenance ziplogs
Commande tar manuelle

Si vous ne pouvez pas exécuter la commande de fichiers journaux auto-décompressables, par exemple si le serveur ne parvient pas à atteindre un état cohérent, vous pouvez toujours récupérer les fichiers journaux en exécutant une commande tar à l’intérieur du conteneur. Vous devrez copier l’archive en utilisant la méthode de transfert de fichiers la plus adaptée à votre situation.

Exemple de commande exécutée dans le conteneur (écrit le fichier tar dans un répertoire temporaire du répertoire de données du conteneur) :

tar -zcvf /var/opt/tableau/tableau_server/temp/<archive_name>.tar.gz \
/var/opt/tableau/tableau_server/data/tabsvc/logs/. \
/var/opt/tableau/tableau_server/supervisord/ \
/var/opt/tableau/tableau_server/data/tabsvc/config/ \
/docker/.metadata.conf \
--exclude='*keystores' --exclude='*.jks' --exclude='*.tks' \
--exclude='*asset_keys.yml' --exclude='*.ks' --exclude='*.ts' \
--exclude='*.crt' --exclude='*cacerts' --exclude='*.key'
Navigation dans les fichiers journaux et conseils de débogage

Plusieurs étapes courantes permettent de diagnostiquer la plupart des problèmes dans Tableau Server. Si vous envisagez de consulter les fichiers journaux de votre serveur, il peut être utile de décomposer les données à rechercher selon le moment du cycle de vie du serveur où l’erreur s’est produite.

Démarrage du conteneur (initial/installation)

Si le conteneur cesse immédiatement de fonctionner ou ne parvient pas à s’installer ou à s’initialiser, consultez les ressources suivantes :

« stdout » du conteneur

Recherchez stdout pour le conteneur Docker. Vous le trouverez en général examinant la sortie de conteneur collectée par le système d’orchestration de votre conteneur (par exemple Kubernetes). Étant donné que Tableau Server est un système multiprocessus qui s’exécute au sein d’un conteneur, stdout n’est souvent pas utile et n’indiquera pas la cause première du problème, à moins que des défaillances catastrophiques se produisent au démarrage. Il est recommandé de consulter stdout sur le conteneur défaillant avant d’explorer plus avant les fichiers journaux Tableau Server.

Exemple :

docker logs <container-name>

Fichier journal de démarrage du conteneur Tableau Server

Le fichier journal de démarrage du conteneur Tableau Server capture la sortie de l’automatisation qui initialise, configure et démarre Tableau Server. Si vous constatez que votre conteneur rencontre des problèmes lors du démarrage ou de l’exécution initiale, voici le premier fichier journal à consulter :

/var/opt/tableau/tableau_server/supervisord/run-tableau-server.log

Vérifiez le bas du fichier journal et voyez si un échec est signalé. Il arrive que l’erreur soit signalée et immédiatement évidente dans le fichier journal. Si l’erreur n’apparaît pas clairement dans le fichier journal, il est possible que la cause première ne soit visible que dans un fichier journal à une étape ou dans un service spécifique. Les fichiers journaux répertoriés ci-dessous couvrent ces possibilités.

Fichier journal d’installation de Tableau Server

Si le fichier journal de démarrage indique qu’un problème s’est produit avec l’automatisation gérant l’étape d’initialisation TSM, consultez ce fichier journal :

/var/opt/tableau/tableau_server/logs/app-install.log

Fichier journal du contrôleur Tableau Server

Si le fichier journal de démarrage indique qu’un problème s’est produit avec l’initialisation et le démarrage de l’étape du serveur (interface en ligne de commande uniquement), consultez le fichier journal du service tabadmincontroller :

/var/opt/tableau/tableau_server/data/tabsvc/logs/tabadmincontroller/tabadmincontroller_node1-0.log

Ce fichier journal concerne un service spécifique appelé tabadmincontroller. Le service tabadmincontroller est responsable de l’orchestration des fonctions d’initialisation et de démarrage dans Server. Ce fichier journal peut être complexe et détaillé. Les erreurs affichées dans ce fichier journal n’indiquent pas toujours la cause première. Les erreurs sont parfois causées par les services sur lesquels tabadmincontroller s’appuie pour effectuer une tâche donnée. Consultez la section Exécution du serveur ci-dessous pour plus de détails.

Fichiers journaux de service - Exécution du serveur

Si Tableau Server rencontre des problèmes pendant l’exécution normale ou avec les services qui ne parviennent pas à terminer les tâches ou sont en panne, vous pouvez consulter les fichiers journaux de service pour plus d’informations. Chaque service exécuté dans le cadre de Tableau Server possède un fichier journal de service. Si vous savez quel service vous souhaitez examiner, vous trouverez les fichiers journaux de ce service dans ce répertoire général :

/var/opt/tableau/tableau_server/data/tabsvc/logs/<service_name>

Indiquez le nom du service dans l’argument<service_name> du chemin du fichier. Tout service peut écrire plusieurs types de fichiers journaux. De plus, si plusieurs instances du même service sont en cours d’exécution, tous les fichiers journaux de service seront écrits dans le même répertoire de service.

Classifications générales des fichiers journaux spécifiques à un service

Ce tableau couvre les noms, types et descriptions des fichiers journaux de service les plus courants pour les services Tableau Server. La colonne « Types d’échec » indique quels fichiers journaux sont susceptibles d’être utiles dans un scénario d’échec donné.

NomFormat du nom de fichierDescriptionTypes d’échecExemple
Processus control-appcontrol_<service_name>_<node_id>-<instance_id>.logContient des informations sur le processus control-app qui est responsable de l’installation et de la configuration d’un service. Il s’agit souvent du premier fichier journal écrit lié à un service. Pour les échecs d’installation et de configuration du service, regardez d’abord ici.Installation, Configuration, Étatcontrol_backgrounder_node1-0.log
Fichier journal de service<service_name>_<node_id>-<instance_id>.logFichier journal principal d’un service en cours d’exécution. Le plus souvent, ce fichier journal contient une sortie de la couche d’application Spring/Java.Démarrage, Exécution, Étatbackgrounder_node1-1.log
Fichier journal stdoutstdout_<service_name>_<instance_id>.logContient la sortie stdout pour le service. La plupart des services ne génèrent pas beaucoup de contenu sur stdout et à la place, écrivent dans le fichier journal principal. Il arrive toutefois que ce fichier journal contienne des données utiles lors de la fermeture d’un service.Démarrage, Arrêtstdout_backgrounder_0.log
Fichier journal NativeAPInativeapi_<service_name>_<instance_id>.txtCertains services exécutent une couche de code native. Ce fichier journal capture cette partie de l’exécution de l’application.Licence, Démarrage, Exécution, Étatnativeapi_backgrounder_1-1_2021_05_10_00_00_00.txt
Fichier journal tomcattomcat_<service_name>_<node_id>-<instance_id>.logCeci ne concerne que les services qui s’exécutent dans un conteneur tomcat et contiennent des fichiers journaux tomcat. Il fournit rarement des informations concernant les pannes de service, mais peut être utile pour déboguer certains problèmes de réseau.Réseau, Démarragetomcat_backgrounder_node1-0.2021-05-10.log
Conteneur arrêté

Dans le cas où le conteneur est arrêté ou qu’il est difficile d’exécuter des commandes dans le conteneur, vous pouvez toujours consulter les fichiers journaux pour voir si le répertoire de données du serveur est externalisé vers un volume monté. Sinon, seule la sortie stdout du conteneur sera examinable dans le système d’orchestration du conteneur. Or, souvent, elle n’indique pas la cause première du problème.

Échec de la définition des propriétés d’authentification

Il semble qu’il y ait un problème de définition des propriétés d’authentification dans Tableau Server si le magasin d’identités n’est pas défini en premier. Pour contourner ce problème, définissez simplement le magasin d’identités dans le hook de pré-initialisation.

  1. Créez un fichier appelé./customer-files/pre_init_command dans le répertoire des fichiers clients de l’outil de création d’image Tableau Server et modifiez-le pour qu’il contienne :

    #!/bin/bash
    tsm configuration set -k wgserver.authenticate -v local --force-keys
  2. Définissez le script pour qu’il soit exécutable.

    chmod +x ./customer-files/pre_init_command
  3. Créez et exécutez l’image.

Échec pendant un nouveau démarrage (p. ex. pourquoi Tableau Server ne démarre-t-il pas?)

  • Si vous rencontrez des problèmes avec l’initialisation ou le démarrage de Tableau Server, il existe un certain nombre d’options de dépannage qui peuvent aider à découvrir le problème.
  • Si le conteneur ne peut pas démarrer du tout, vous pourriez vérifier la sortie stdout du processus PID 1 à l’aide de la commande docker logs <container-name>.
  • Si le conteneur s’exécute mais que Tableau Server ne semble pas être correctement en cours d’initialisation ou d’exécution, vous pouvez vous reporter à ce fichier pour vérifier la présence d’erreurs :
${DATA_DIR}/supervisord/run-tableau-server.log

Exemple :

docker exec -it <container-name> bash -c 'cat $DATA_DIR/supervisord/run-tableau-server.log'

Ce fichier journal contient tous les événements orchestrés par le service d’initialisation du conteneur Tableau qui gère le démarrage de Tableau Server ainsi que l’exécution de tout script d’installation ou de configuration personnalisée que vous avez éventuellement fourni dans le conteneur. La plupart des erreurs de démarrage signaleront les problèmes ici. Parfois, si l’erreur est liée à un processus TSM ou Tableau Server, un autre fichier journal sera proposé pour examiner des données plus détaillées.

Échec pendant le redémarrage ou le démarrage d’un conteneur avec des données existantes

Le serveur ne démarre pas PostGRES (ou d’autres processus)

Lorsqu’il y a des données persistantes à l’extérieur du conteneur et que vous démarrez une autre instance d’image Tableau Server dans un conteneur à l’aide de ces anciennes données, il est important de noter que le nom d’hôte interne du nouveau conteneur doit correspondre au nom d’hôte du conteneur qui a initialisé les données persistantes. Tableau Server ne gère pas les modifications de nom d’hôte dynamique et le démarrage d’un nouveau conteneur avec un nom d’hôte interne différent est effectivement à l’origine de ce scénario.

Le remède consiste simplement à s’assurer que le nom d’hôte du conteneur est défini sur la même valeur que le conteneur qui s’exécutait auparavant avec ces données. Cela ne doit pas être confondu avec un environnement multinœud, les workers peuvent (et devraient probablement) avoir des noms d’hôte différents les uns des autres. Ce qui importe, c’est qu’en cas de redémarrage ou d’arrêt d’un seul conteneur, le conteneur suivant ait le même nom d’hôte que son prédécesseur.

Exemples de configuration de déploiement

Docker

Utilisation de base de Tableau Server dans un conteneur
docker run \
-e LICENSE_KEY=<key>
-p 8080:8080
--hostname=<static (internal) name of host machine> \
-d <Tableau Server in a Container image ID or tag>
Utilisation de base de Tableau Server dans un conteneur avec un utilisateur administrateur initial automatisé
docker run \
-e LICENSE_KEY=<key> \
-e TABLEAU_USERNAME=<myadmin> \
-e TABLEAU_PASSWORD_FILE=/etc/tableau-admin-secret \
-v <full-path-to-pw-file>:/etc/tableau-admin-secret \
--hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
Mode TSM uniquement
docker run \
-e TSM_ONLY=1 \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
Utilisation de base d’une topologie multinœud
Nœud initial

Option 1 : utilisez cette option si la configuration du serveur (CONFIG_FILE) spécifie une topologie multinœud :

docker run \
-v <network-shared-directory>:/docker/config/bootstrap \
-v <full-path-to-config-file>:/docker/config/config.json:ro \
-e LICENSE_KEY=<key> \
-p 8080:8080 -p 8800-9000:8800-9000 -p 27000-27010:27000-27010 \
--hostname=<name-of-host-machine> \
-d <Tableau Server in a Container image ID or tag>

Option 2 : utilisez cette option si vous souhaitez un déploiement multinœud même si la configuration du serveur ne spécifie pas une topologie multinœud :

docker run \
-v <network-shared-directory>:/docker/config/bootstrap \
-e LICENSE_KEY=<key> -e ALWAYS_WRITE_BOOTSTRAP_FILE=1 \
-p 8080:8080 -p 8800-9000:8800-9000 -p 27000-27010:27000-27010 \
--hostname=<name-of-host-machine> \
-d <Tableau Server in a Container image ID or tag>
Nœud supplémentaire
docker run \
-v <network-shared-directory>:/docker/config/bootstrap \
-e BOOTSTRAP_INSTALL=1 \
-p 8080:8080 -p 8800-9000:8800-9000 \
--hostname=<static (internal) name of host machine> \
-d <Tableau Server in a Container image ID or tag>
Externaliser l’utilisation des données
docker run \
-v <empty-data-dir>:/var/opt/tableau \
-e LICENSE_KEY=<key> \
---hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
Utilisation de base d’init-container

Init Container

docker run \
-v <empty-data-dir>:/var/opt/tableau \
-e LICENSE_KEY=<key> \
-e INIT_CONTAINER=1 \
--hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Run Container

docker run \
-v <empty-data-dir>:/var/opt/tableau \
--hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
Restauration de base depuis une sauvegarde sur un seul nœud
docker run \
-v <full-path-to-backup-file>:/docker/config/backup/backup-file.tsbak \
-v <full-path-to-config-only-file>:/docker/config/config.json:ro \
-e LICENSE_KEY=<key> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Docker-Compose

version: '3.2'
services:
    tableau-server:
         hostname: localhost
         volumes:
              - <your-tsm-command-file>:/docker/config/tsm-commands:ro
              - <your-config-file >:/docker/config/config.json:ro
         ports:
              - "8080:8080"
         image: ${IMAGE_NAME}
         environment:
              - LICENSE_KEY=<license-key>