--- schema_version: "1" id: a7e11e915cda27a599882d9baef7e00d1a528db207cb9d7fe0dc1cac7b63f9ec title: Tableau Server dans un conteneur - Dépannage collection: tableau version: next locale: fr-ca portal_url: https://docs.salesforce.com/tableau/next/fr-ca/server-linux/server-in-container_troubleshoot.md canonical_url: https://help.tableau.com/v0.0/server-linux/fr-ca/server-in-container_troubleshoot.htm source_site: help.tableau.com content_type: documentation content_hash: c9d6d9dd76cd98d0b4282c4845dc6a73700550551ecd1204425410a2e42ace73 description: Troubleshoot Tableau Server in a container deployments. --- [Passer au contenu principal](#main-content) # 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 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](https://help.tableau.com/v0.0/server-linux/fr-ca/server-in-container_quickstart.htm). ## Limitations de Tableau Server dans un conteneur - Tableau Server dans un conteneur prend uniquement en charge l’activation de licence à l’aide de Server ATR. L’activation hors ligne n’est pas prise en charge. - 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](https://github.com/tableau/tableau-server-in-kubernetes). #### Modifier le fuseau horaire pour Tableau Server dans un conteneur Si vous souhaitez que Tableau Server dans un conteneur utilise un fuseau horaire spécifique, vous pouvez le définir en créant un lien symbolique entre `/etc/localtime` et le fichier de fuseau horaire souhaité : ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime export TZ=“Asia/Tokyo” Redémarrez Tableau Server, en incluant les processus de gestion, pour qu’il reconnaisse le nouveau fuseau horaire : $ tsm configuration set -k service.log.timezone -v "Asia/Tokyo" $ tsm pending-changes apply $ cd /opt/tableau/tableau\_server/packages/scripts.{version}/ $ ./stop-administrative-services $ ./start-administrative-services Attendez que la commande `tsm status` renvoie l’état « STOPPED » puis démarrez Tableau : $ tsm start #### 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](https://help.tableau.com/v0.0/server-linux/fr-ca/cli_maintenance_tsm.htm#tsm4ziplogs). 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/.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 **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/ Indiquez le nom du service dans l’argument`` 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é. | Nom | Format du nom de fichier | Description | Types d’échec | Exemple | | --- | --- | --- | --- | --- | | Processus control-app | `control__-.log` | Contient 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, État | `control_backgrounder_node1-0.log` | | Fichier journal de service | `_-.log` | Fichier 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, État | `backgrounder_node1-1.log` | | Fichier journal stdout | `stdout__.log` | Contient 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êt | `stdout_backgrounder_0.log` | | Fichier journal NativeAPI | `nativeapi__.txt` | Certains 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, État | `nativeapi_backgrounder_1-1_2021_05_10_00_00_00.txt` | | Fichier journal tomcat | `tomcat__-.log` | Ceci 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émarrage | `tomcat_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 `. - 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 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= -p 8080:8080 --hostname= \\ -d ##### Utilisation de base de Tableau Server dans un conteneur avec un utilisateur administrateur initial automatisé docker run \\ -e LICENSE\_KEY= \\ -e TABLEAU\_USERNAME= \\ -e TABLEAU\_PASSWORD\_FILE=/etc/tableau-admin-secret \\ -v :/etc/tableau-admin-secret \\ --hostname= \\ -p 8080:8080 -d ##### Mode TSM uniquement docker run \\ -e TSM\_ONLY=1 \\ -p 8080:8080 -d ##### 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 :/docker/config/bootstrap \\ -v :/docker/config/config.json:ro \\ -e LICENSE\_KEY= \\ -p 8080:8080 -p 8800-9000:8800-9000 -p 27000-27010:27000-27010 \\ --hostname= \\ -d **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 :/docker/config/bootstrap \\ -e LICENSE\_KEY= -e ALWAYS\_WRITE\_BOOTSTRAP\_FILE=1 \\ -p 8080:8080 -p 8800-9000:8800-9000 -p 27000-27010:27000-27010 \\ --hostname= \\ -d ###### Nœud supplémentaire docker run \\ -v :/docker/config/bootstrap \\ -e BOOTSTRAP\_INSTALL=1 \\ -p 8080:8080 -p 8800-9000:8800-9000 \\ --hostname= \\ -d ##### Externaliser l’utilisation des données docker run \\ -v :/var/opt/tableau \\ -e LICENSE\_KEY= \\ ---hostname= \\ -p 8080:8080 -d ##### Utilisation de base d’init-container **Init Container** docker run \\ -v :/var/opt/tableau \\ -e LICENSE\_KEY= \\ -e INIT\_CONTAINER=1 \\ --hostname= \\ -p 8080:8080 -d **Run Container** docker run \\ -v :/var/opt/tableau \\ --hostname= \\ -p 8080:8080 -d ##### Restauration de base depuis une sauvegarde sur un seul nœud docker run \\ -v :/docker/config/backup/backup-file.tsbak \\ -v :/docker/config/config.json:ro \\ -e LICENSE\_KEY= \\ -p 8080:8080 -d #### Docker-Compose version: '3.2' services: tableau-server: hostname: localhost volumes: - :/docker/config/tsm-commands:ro - :/docker/config/config.json:ro ports: - "8080:8080" image: ${IMAGE\_NAME} environment: - LICENSE\_KEY=