Aide de Tableau Server sur Linux

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 à l’aide de Server ATR est prise en charge dans la version 2023.1 et les versions ultérieures. Cette fonctionnalité est disponible dans les conteneurs mais nécessite des étapes et une approbation supplémentaires. Si vous devez exécuter Tableau Server dans un conteneur dans un environnement isolé ou hors ligne, communiquez avec votre représentant de compte pour plus d’information.
• 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.

Image Tableau Server dans un conteneur

L’image Tableau Server dans un conteneur est une image Docker contenant l’intégralité de Tableau Server. L’image est créée à l’aide de Tableau Server dans un outil d’installation de conteneur. Une fois créée, l’image inclut Tableau Server mais elle n’est pas encore initialisée. L’utilisateur par défaut d’une image Tableau Server dans une image est un utilisateur sans privilège différent de l’utilisateur racine.

Conditions préalables

Exécuter le script configure-container-host

Lorsque Tableau Server est installé sans conteneur, certaines limites de ressources et propriétés coredump sont modifiées dans le cadre du processus d’installation. Cela est effectué pour aider à optimiser les performances de Tableau Server. Une image Tableau Server dans un conteneur n’a pas la possibilité d’effectuer ces modifications sur la machine hôte. Nous vous recommandons donc d’exécuter le script configure-container-host qui est fourni dans Tableau Server dans un outil d’installation de conteneur sur n’importe quelle machine appelée à exécuter Tableau Server dans des images de conteneur. Cela permettra de garantir que les performances du serveur Tableau dans une image de conteneur sont équivalentes à celles de son homologue sans conteneur.

Pour exécuter le script configure-container-host :

1. Localisez le script (configure-container-host) dans le répertoire de niveau supérieur de l’outil d’installation de Tableau Server dans un conteneur.

2. Copiez-le dans les environnements sur lesquels vous prévoyez d’exécuter Tableau Server.

3. Déterminez le compte d’utilisateur/uid sans privilèges qui s’exécutera en tant qu’utilisateur par défaut de l’image de Tableau Server dans un conteneur. Cet utilisateur doit exister sur la machine hôte et doit correspondre à l’UID défini dans la variable d’environnement UNPRIVILEGED_TABLEAU_UID du conteneur Tableau Server. Si vous ne l’avez pas défini lors de la création de votre image Docker, l’ID utilisateur non privilégié par défaut à l’intérieur du conteneur est 999. Si vous utilisez le mappage utilisateur Docker, cet UID doit correspondre à l’utilisateur qui existe sur la machine hôte.

4. Exécutez le script en tant que root :

   sudo ./configure-container-host -u <uid>

Exécution de l’image

Pour exécuter une image Docker de Tableau Server dans un conteneur, la commande la plus simple pour obtenir une image Tableau Server dans un conteneur en cours d’exécution est la suivante :

docker run \
-e LICENSE_KEY=<key>
-p 8080:8080
-d <Tableau Server in a Container image ID or tag>

Cette fonction exécute le Docker en arrière-plan et, après un certain délai, aboutit à une instance entièrement installée de Tableau Server. Le démarrage complet de Tableau Server peut prendre 10 à 20 minutes, selon la configuration matérielle de l’ordinateur exécutant l’image. Vous pouvez vérifier que le conteneur est en cours d’exécution en utilisant la commande docker ps. Une fois que Tableau Server est opérationnel, le compte initial d’administrateur de Tableau Server devra être créé. Cette étape peut être automatisée. Pour plus d’informations, consultez Automatiser l’administrateur initial de Tableau Server.

Résumé des arguments d’exécution de base

Toutes les options utilisées dans la commande d’exécution Docker sont nécessaires. Il arrive souvent que des options supplémentaires soient fournies afin de tirer parti des différentes fonctionnalités de l’image. Pour l’instant, examinons de plus près les arguments utilisés dans la commande d’exécution Docker la plus simple pour Tableau Server dans un conteneur :

Automatiser l’administrateur initial de Tableau Server

Lorsque Tableau Server démarre pour la première fois, un utilisateur administrateur initial doit être créé avant que les connexions réseau à distance vers Tableau Server soient autorisées. Pour cela, vous pouvez exécuter la commandetabcmd initialuser -s localhost:8080 -u <username> -p <password> à l’intérieur du conteneur. Vous pouvez également définir des informations d’identification d’administrateur via des variables d’environnement. TABLEAU_USERNAME et TABLEAU_PASSWORD ou TABLEAU_PASSWORD_FILE (préféré) sont les variables d’environnement qui peuvent être configurées pour transmettre les informations d’identification d’administrateur initiales. Pour plus d’informations sur la gestion des mots de passe, consultez Gestion des mots de passe.

Pour plus d’informations sur la commande tabcmd initialuser, consultez initialuser.

Exemple

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 \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Licences

Licences dans des conteneurs

Les licences de Tableau Server dans un conteneur utilisent le service ATR (Authorize-To-Run) pour activer Tableau Server déployé dans le nuage, des conteneurs ou des environnements virtuels sans se retrouver à court d’activations de licence. Le service ATR offre cette possibilité en fournissant des locations à court terme d’une durée configurable (durée ATR) jusqu’à ce que la date d’expiration de la clé produit soit atteinte. ATR extrait les licences Tableau à partir de modifications matérielles sous-jacentes, ce qui constitue un aspect fondamental des déploiements de conteneur. Étant donné que le service ATR du serveur nécessite que le conteneur puisse se connecter au service ATR hébergé par Tableau, les conteneurs doivent pouvoir accéder à Internet. Tableau Server dans un conteneur ne prend pas en charge l’activation hors ligne ou manuelle. Consultez Activer Tableau Server à l’aide du service Authorize to Run pour plus d’informations.

Important : vous devez fournir les variables d’environnement LICENSE_KEY ou LICENSE_KEY_FILE (n’en définissez qu’une).

Lors de la mise à niveau de Tableau Server dans un conteneur, si vous avez utilisé le nombre maximum d’activations pour votre licence, Tableau Server ne peut pas démarrer tant que la durée ATR ne s’est pas écoulée (4 heures/14 400 secondes par défaut). Pour plus d’informations sur la définition ou la modification de la durée ATR, consultez Activer Tableau Server à l’aide du service Authorize to Run(Le lien s’ouvre dans une nouvelle fenêtre).

Variable d’environnement de licence

Tableau Server dans un conteneur prend en charge la définition des clés produit à l’aide d’une variable d’environnement : LICENSE_KEY peut contenir une ou plusieurs clés (-e LICENSE_KEY="<key1> , <key2>") par une liste séparée par des virgules.

Exemple

docker run \
-e LICENSE_KEY="<key1>, <key2>" \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Fichier de licence

Tableau Server dans un conteneur prend également en charge la définition de clés produit à l’aide d’un fichier. Montez un fichier à l’emplacement du fichier de clé produit par défaut dans le conteneur (/docker/config/license_file) ou comme spécifié par la variable d’environnement LICENSE_KEY_FILE.

Exemple

docker run \
-v <full-path-to-license-file>:/docker/config/license_file \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Durée de location de licence demandée

Vous pouvez spécifier la durée de location de la licence ATR dans un conteneur Tableau Server en définissant la variable d’environnement REQUESTED_LEASE_TIME. Vous devez indiquer la durée de location en secondes, la durée minimale étant de 3600 secondes (ou 1 heure). Nous vous recommandons de réduire la durée de la location lors de l’expérimentation et du test de Tableau Server afin de réduire la probabilité d’atteindre la limite maximale de location activée. Pour les déploiements en production, il est fortement recommandé de ne pas définir le paramètre REQUESTED_LEASE_TIME (utilisant ainsi la valeur par défaut), afin que Tableau puisse déterminer la durée de location idéale.

Exemple

docker run \
...
-e REQUESTED_LEASE_TIME=<time-in-seconds> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Exécution d’une image non initialisée

L’installation de Tableau Server s’effectue en deux phases : en premier, les services Tableau Service Manager (TSM) sont installés. Dans une installation typique sur site, cette étape permet aux administrateurs de serveur d’enregistrer leur serveur, d’activer leurs licences et de configurer le comportement souhaité du serveur. La deuxième phase de l’installation couvre la configuration et le démarrage des processus Tableau Server chargés de traiter le trafic des utilisateurs finaux et la logique métier associée.

Le comportement par défaut des images Tableau Server dans un conteneur consiste à automatiser toutes les étapes d’installation afin que la commande docker run aboutisse à un serveur entièrement fonctionnel. Toutefois, si vous souhaitez démarrer une image Tableau Server dans un conteneur et qu’elle exécute uniquement les services TSM (c’est-à-dire à la base, ce qu’un administrateur serveur attendrait s’il venait d’exécuter initialize-tsm), vous pouvez le faire en transmettant l’indicateur TSM_ONLY en tant que variable d’environnement.

Par exemple :

docker run \
-e TSM_ONLY=1 \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Interagir avec l’image

Lorsqu’une image Tableau Server dans un conteneur est en cours d’exécution, vous pouvez appeler les commandes TSM et tabcmd directement. Ces outils sont ajoutés directement à la trajectoire de l’environnement de l’utilisateur pid 1 (qui est la racine à ce stade). Cela signifie que vous pouvez appeler les commandes TSM et tabcmd comme suit :

docker exec -it <container> tsm status -v

docker exec -it <container> tabcmd initialuser -s localhost -u <admin> -p <secret>

Il est également possible d’ouvrir un interpréteur de commandes dans le conteneur pour effectuer des opérations plus générales. Cette pratique n’est généralement pas recommandée, sauf à des fins de débogage :

docker exec -it <container> bash

Interface utilisateur Web TSM et interface en ligne de commande à distance

L’interface utilisateur Web TSM et l’interface en ligne de commande à distance ne sont pas accessibles par défaut. En effet, elles requièrent un nom d’utilisateur et un mot de passe pour l’authentification. Or, par défaut, aucun mot de passe n’a été fourni à l’utilisateur exécutant les processus Tableau Server dans le conteneur. Des raisons de sécurité expliquent cette restriction (nous déconseillons d’envoyer des images incluant un mot de passe par défaut, ce qui permettrait un accès à distance). Dans certains cas, l’interface utilisateur Web TSM et les appels d’accès à distance à l’aide de l’interface en ligne de commande TSM peuvent être utiles. Si vous souhaitez utiliser ces fonctionnalités, vous devrez suivre les étapes décrites ci-dessous pour créer un compte d’utilisateur d’accès à distance.

Pour plus d’informations sur l’interface utilisateur Web et l’interface en ligne de commande TSM, consultez Se connecter à l’interface utilisateur Web Tableau Services Manager.

Créer un utilisateur distant TSM

Spécifiez les variables d’environnement TSM_REMOTE_UID et TSM_REMOTE_USERNAME lorsque vous créez une image Tableau Server dans un conteneur à l’aide de l’outil d’installation. La création d’un compte compatible TSM dans l’image nécessite un accès privilégié à l’image qui n’est pas disponible au moment de l’exécution. Par conséquent, cela n’est possible que lorsque l’image Docker est créée par un outil d’installation de Tableau Server dans un conteneur (build-image).

Exemple de fichier environment de l’outil d’installation de Tableau Server dans un conteneur :

TSM_REMOTE_UID=1010
TSM_REMOTE_USERNAME=myuser

Définir le mot de passe pour l’utilisateur distant TSM

L’image Tableau Server dans un conteneur nécessite un mot de passe pour le compte lorsque l’image est exécutée. Vous pouvez définir le mot de passe de ce compte de deux manières.

Fichier de secrets (recommandé)

Créez un fichier nommé remote-user-secret, écrivez le mot de passe dans le fichier et montez-le dans le conteneur lors de l’exécution. TSM_REMOTE_PASSWORD_FILE détermine l’emplacement attendu (l’emplacement par défaut est/docker/config/remote-user-secret) du fichier de secrets dans le conteneur.

Exemple de fichier remote-user-secret :

mypassword

Exemple de commande d’exécution de Docker :

docker run \
-e LICENSE_KEY=<key>
-v {absolute-path}/remote-user-secret:/docker/config/remote-user-secret
-p 8080:8080 \
-p 8850:8850 \
-d <Tableau Server in a Container image ID or tag>

Variable d’environnement

Vous pouvez aussi simplement définir la variable d’environnement TSM_REMOTE_PASSWORD lors du démarrage de l’image Docker.

Exemple de commande d’exécution de Docker :

docker run \
-e LICENSE_KEY=<key>
-e TSM_REMOTE_PASSWORD=<password>
-p 8080:8080 \
-p 8850:8850 \
-d <Tableau Server in a Container image ID or tag>

Remarques de sécurité

• Le port 8850 doit être exposé pour recevoir le trafic de requête TSM.
• Si le mot de passe n’est pas défini correctement dans l’image au moment de l’exécution, le conteneur se fermera immédiatement.
• TSM s’appuie sur le système de compte utilisateur Linux de l’image. Dans ce cas, le compte est restreint à l’intérieur de l’image. Cela signifie que le compte aura un interpréteur de commandes restreint et se limitera à l’exécution de deux commandes : /bin/true et passwd.

Comment faire pivoter le mot de passe de l’utilisateur distant TSM

Si vous souhaitez modifier le mot de passe du compte de l’utilisateur distant TSM, vous pouvez le faire à l’aide de l’une de ces options :

Démarrer un nouveau Tableau Server dans un conteneur

Le mot de passe du compte est défini à chaque démarrage du conteneur. Si vous conservez des données Tableau en dehors du conteneur, le démarrage d’une nouvelle image avec un nouveau mot de passe alternera efficacement le mot de passe.

1. Arrêter et supprimer l’image en cours d’exécution
2. Définissez une nouvelle valeur de mot de passe dans les variables d’environnement TSM_REMOTE_PASSWORD ou TSM_REMOTE_PASSWORD_FILE (voir ci-dessus) dans la configuration de votre image.
3. Redémarrez l’image.

Alterner le mot de passe manuellement à l’intérieur d’un conteneur en cours d’exécution

Si vous ne souhaitez pas fermer l’image, vous pouvez toujours alterner le mot de passe manuellement.

1. Ouvrir un interpréteur de commandes dans le conteneur en cours d’exécution
2. Connectez-vous en tant que compte utilisateur distant à l’aide de la commande su

3. Exécutez la commande passwd pour modifier le mot de passe.

   Avertissement : ces rotations manuelles persistent uniquement tant que la couche d’écriture de l’instance de conteneur est conservée. Si vous supprimez le conteneur, les modifications manuelles ne sont pas appliquées au démarrage d’un nouveau conteneur.

Options de configuration initiale

La configuration du conteneur Tableau Server est essentielle pour obtenir le comportement souhaité de Tableau Server. Tableau Server dans un conteneur est une installation nouvelle de Tableau Server. Vous devez donc fournir les mêmes informations au conteneur que lors de la configuration de Tableau Server en dehors d’un conteneur.

Variable d’environnement d’exécution

Les variables d’environnement d’exécution ci-dessous indiquent à l’image Tableau Server dans un conteneur comment déployer Tableau Server. Un sous-ensemble de ces variables sera décrit plus en détail.

Toutes ces valeurs sont créées pour être remplacées afin d’offrir plus de flexibilité pour la configuration.

Variables d’environnement en lecture seule

Il s’agit de propriétés d’environnement qui décrivent certaines des propriétés de base de l’image du Tableau Server dans un conteneur. Il n’est pas recommandé de remplacer ces valeurs.

Variables d’environnement au moment de la création

Remplacements de configuration Tableau Server

Ces variables d’environnement peuvent être remplacées par Docker pour pointer vers n’importe quel fichier dans le conteneur. Donc, si vous voulez spécifier un point de montage différent, vous pouvez le faire sans problème.

Tableau Server a besoin d’un fichier de configuration pour démarrer et s’exécuter :

CONFIG_FILE=/docker/config/config.json

CONFIG_FILE fait référence à un fichier de configuration TSM. Le format et l’utilisation sont identiques au fichier de configuration décrit dans Exemple de fichier de configuration.

Commandes de pré-initialisation et de post-initialisation

Tableau Server exécute un script d’installation automatisé conçu pour faire passer le serveur d’un état pré-initialisé à un fonctionnement complet. Cependant, vous souhaiterez parfois ajouter votre propre code d’automatisation dans le processus d’initialisation. Nous proposons deux hooks à cette fin, le script de pré-initialisation et le script de post-initialisation.

Script de pré-initialisation

Ce script s’exécutera immédiatement après l’initialisation des processus TSM de base et avant l’exécution de toute autre étape de configuration TSM. Cette option est utile pour exécuter les commandes de configuration TSM avant l’exécution de Tableau Server. Pour les modifications de configuration apportées à ce stade, vous n’avez pas besoin d’appliquer les modifications car l’automatisation habituelle de Tableau Server le fait une fois votre script terminé.

Script de post-initialisation

Ce script s’exécutera une fois toutes les autres initialisations et automatisations de démarrage de Tableau Server terminées. Tableau Server sera entièrement fonctionnel et en cours d’exécution lorsque ce script s’exécutera. Les modifications de configuration apportées à ce stade doivent être appliquées.

Instructions

Pour ajouter un script personnalisé à l’un de ces hooks dans votre image, procédez comme suit :

1. Écrivez votre script personnalisé
2. Copiez le script personnalisé dans le répertoire customer-files de l’outil de création d’image de Tableau Server dans un conteneur.
3. Renommez le script en pre_init_command ou post_init_command selon le moment où vous souhaitez que le script s’exécute (vous pouvez utiliser les deux hooks indépendamment l’un de l’autre).
4. Assurez-vous que les autorisations du script sont exécutables par un autre (chmod +rx <command-file> ) ou que les autorisations de propriété correspondent à l’utilisateur non privilégié dans le conteneur.

Configuration utilisateur

Tableau Server utilise un utilisateur non privilégié pour exécuter les processus du serveur. Cet utilisateur est créé à l’intérieur du conteneur lorsque Tableau Server dans un conteneur est en phase d’initialisation. Par défaut, l’utilisateur est nommé tableau avec un UID de 999. Si vous déployez une instance Tableau Server dans un conteneur qui utilise des montages pour stocker des données de manière externe sur la machine hôte, vous préférerez peut-être modifier l’UID pour l’associer à un UID sur la machine hôte. L’utilisation de d’espace de noms d’utilisateur Docker est une autre façon d’obtenir le même résultat.

Utilitaires et outils de Tableau Server dans un conteneur

Toutes les fonctions d’utilitaires et d’outils de Tableau Server dans un conteneur sont placées sous ce répertoire :

/docker/

Gestion des autorisations de fichier

Lors de la transmission de fichiers de configuration au conteneur, vous voudrez vous assurer que l’utilisateur exécutant le processus Tableau Server à l’intérieur du conteneur est autorisé à accéder aux fichiers. Pour éviter que tous les utilisateurs soient autorisés à accéder aux fichiers montés sur le conteneur, vous pouvez modifier l’UID et/ou le GID de l’utilisateur exécutant Tableau Server à l’intérieur du conteneur afin qu’il corresponde au propriétaire de l’utilisateur/du groupe sur l’hôte. L’utilisateur du conteneur aura un UID déterminé par la variable d’environnement UNPRIVILEGED_TABLEAU_UID (par défaut : 999) et un GID déterminé par UNPRIVILEGED_TABLEAU_GID (par défaut : 998). Vous pouvez modifier ces valeurs en remplaçant la variable d’environnement ou vous pouvez utiliser un mappage d’espace de noms d’utilisateur Docker pour associer l’UID/le GID dans le conteneur à un autre UID/GID sur l’hôte.

Gestion des mots de passe

Certaines fonctionnalités et options exigent que les informations d’identification des utilisateurs soient fournies en tant que paramètre de configuration dans le conteneur. Les informations d’identification d’administrateur initial Tableau sont un exemple d’informations d’identification facultatives qui activent des fonctionnalités supplémentaires. Dans ces cas, nous fournissons toujours deux méthodes de définition des mots de passe. Premièrement, vous pouvez fournir un fichier contenant le mot de passe ainsi qu’un chemin d’accès du fichier à une variable d’environnement. Sinon, vous pouvez définir une variable d’environnement pour stocker le mot de passe directement.

L’option recommandée et la plus sécurisée consiste à fournir le mot de passe sous forme de chemin d’accès du fichier au conteneur. Fournir un secret dans un fichier est un modèle bien pris en charge dans Docker, Docker Swarm, Kubernetes et d’autres systèmes d’orchestration de conteneurs. Le stockage des mots de passe directement dans les variables d’environnement est un modèle courant, que nous prenons en charge, mais cela signifie généralement que le mot de passe est moins sécurisé.

Exemples

Examinons l’identifiant TABLEAU_USERNAME. Vous pouvez fournir le mot de passe pour l’utilisateur en tant que TABLEAU_PASSWORD ou TABLEAU_PASSWORD_FILE. Lors de l’exécution d’une image Tableau Server dans un conteneur, vous pouvez fournir l’une ou l’autre variable d’environnement pour fournir le mot de passe.

La variable d’environnement du fichier de mot de passe attend un chemin d’accès de fichier à l’intérieur du conteneur vers un fichier de secrets valide. Le fichier de secrets doit être une seule ligne qui contient le secret.

Exemple d’utilisation d’un fichier de secrets

docker run \
...
-e TABLEAU_USERNAME=admin \
-e TABLEAU_PASSWORD_FILE=/etc/admin-secret \
-v <full-path-to-pw-file>:/etc/admin-secret \
-d <Tableau Server in a Container image ID or tag>

Exemple de contenu d’un fichier de secrets

mypassword23879172

Vous pouvez sinon stocker directement le mot de passe en texte clair dans la variable d’environnement du mot de passe. Cette approche est considérée comme moins sûre, mais elle est plus pratique et un modèle courant avec les conteneurs.

Exemple

docker run \
...
-e TABLEAU_USERNAME=admin \
-e TABLEAU_PASSWORD=password \
-d <Tableau Server in a Container image ID or tag>

Configuration de Tableau Server après son exécution

Une fois Tableau Server initialisé et en cours d’exécution, le meilleur moyen d’interagir avec le serveur consiste à utiliser l’outil d’interface en ligne de commande TSM. Il s’agit de l’outil Tableau Server classique pour effectuer des tâches administratives. À l’avenir, nous prendrons en charge Tableau Server pour réagir aux modifications de la configuration statique fournie dans la variable d’environnement CONFIG_FILE entre les exécutions. Mais pour l’instant, une fois Tableau Server initialisé, vous devez interagir avec le serveur à l’aide des outils classiques.

Pour plus d’informations sur l’interface en ligne de commande TSM, consultez Référence de ligne de commande tsm.

État

Deux contrôles d’état de base pour Tableau Server sont fournis dans l’image. Ils peuvent être utilisés pour vérifier si le serveur est actif et prêt.

Contrôle d’activité

Le contrôle d’activité indique si les services TSM sont en cours d’exécution. Il indique donc si les services d’orchestration de Tableau Server sont actifs et opérationnels. Vous pouvez appeler ce contrôle ici :

/docker/alive-check

Une autre option consiste à exposer le port 8850 que le service de contrôleur Tableau exécute pour fournir des fonctions administratives via un navigateur Web. Il est possible de vérifier périodiquement l’intégrité du service en la vérifiant par le biais de contrôles d’intégrité tcp.

Contrôle de disponibilité

Le contrôle de disponibilité indique si Tableau Server est en cours d’exécution et si les services d’entreprise sont prêts à recevoir du trafic. Vous pouvez le déterminer à l’aide du script suivant :

/docker/server-ready-check

Une autre option consiste à utiliser des contrôles d’intégrité tcp sur le port 8080 (ou tout port sur lequel Tableau Server recevra du trafic). Parfois, ce type de contrôle d’intégrité tcp est plus fiable que le contrôle de disponibilité du serveur. Ce dernier est en effet basé sur l’état de service signalé à TSM, lequel peut parfois avoir du retard suite à la mise à jour de l’état du service.

Données persistantes

Souvent, avec les conteneurs, nous souhaitons avoir la possibilité d’arrêter un conteneur, puis de le rallumer sans perdre d’informations importantes. Les images Tableau Server dans un conteneur prennent en charge ce processus de sorte que vous pouvez monter certains répertoires hors du conteneur et détruire ou supprimer complètement les instances de conteneur tout en préservant vos données. Ces données peuvent être utilisées pour démarrer une autre instance de conteneur et reprendre là où le conteneur précédent s’est arrêté.

Les sections suivantes couvrent les différents types d’états gérés.

Données Tableau Server

Les données du serveur sont toutes stockées dans le répertoire de données. Le répertoire de données est l’endroit où toutes les données liées à l’utilisateur et les métadonnées d’exécution de service sont stockées. L’externalisation de ces données signifie que les données de votre utilisateur peuvent être conservées même après la suppression complète de Tableau Server dans un conteneur.

Ces données sont transférables et peuvent être utilisées avec un système de stockage de blocs géré dans le nuage, tels que les volumes AWS EBS.

Lorsque Tableau Server dans un conteneur est utilisé conjointement avec un stockage de fichiers externe, le répertoire de données doit être sur EBS. N’utilisez pas de système de fichiers réseau (par exemple, NFS) pour le répertoire de données. Le répertoire du stockage de fichiers externe peut se trouver sur un volume NFS.

Noms d’hôte statiques

Tableau Server ne prend pas en charge les modifications dynamiques de nom d’hôte. Il est donc important de spécifier le nom d’hôte interne du conteneur afin qu’il soit cohérent entre les exécutions de conteneurs. Le nom d’hôte à l’intérieur d’un conteneur est arbitraire et peut être défini sur n’importe quelle valeur. L’utilisation de l’option --hostname permet de spécifier le nom d’hôte interne du conteneur. Assurez-vous que les conteneurs ultérieurs utilisant les mêmes données persistantes soient exécutés en utilisant la même valeur de nom d’hôte.

À ne pas confondre avec les installations distribuées de serveurs. Dans ces installations, un nom d’hôte différent doit être attribué à chaque nœud supplémentaire. Ce qui importe, c’est qu’en cas de redémarrage d’un seul conteneur, le conteneur de remplacement qui utilise les mêmes données persistantes pour cette instance ait un nom d’hôte correspondant.

Exemple complet

Voici un exemple où le répertoire de données est monté à l’extérieur du conteneur.

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>

Sauvegarde et restauration

Tableau Server dans un conteneur prend en charge la création de sauvegardes et la restauration de Tableau Server à partir d’un fichier de sauvegarde (.tsbak). La première étape consiste à exécuter une image Tableau Server dans un conteneur, à monter le fichier de sauvegarde (.tsbak) sur l’image et à définir la variable d’environnement BACKUP_FILE avec le chemin d’accès du fichier sur le fichier de sauvegarde. Vous devez en outre fournir le fichier de configuration json de sauvegarde dans la variable d’environnement CONFIG_FILE. Le conteneur Tableau Server automatise le processus de restauration même pour les déploiements distribués. Si, à un moment donné, cette automatisation ne parvient pas à restaurer complètement le système, vous pouvez toujours vous rabattre sur les outils et processus Tableau Server classiques tels que les commandes TSM pour interagir avec Tableau Server comme que vous le feriez dans le cas d’un déploiement sans conteneur.

Pour savoir comment effectuer une sauvegarde et une restauration d’une instance Tableau Server standard, consultez Effectuer une sauvegarde et une restauration complètes de Tableau Server.

Sauvegarde dans le conteneur Tableau Server

1. Ouvrez l’interpréteur de commandes à l’intérieur de Tableau Server dans un conteneur version A. Créez une sauvegarde de référentiel, ainsi que des fichiers de sauvegarde de topologie et de configuration.

   docker exec -it my-server bash
   
   # Just providing filename automatically produces the backup file at /var/opt/tableau/tableau_server/data/tabsvc/files/backups/
   tsm maintenance backup -f <repository-backup>.tsbak -d
   
   # Any filepath where current user(UNPRIVILEGED USER) can write.
   tsm settings export -f /var/opt/tableau/tableau_server/data/tabsvc/files/backups/<topology-conf-backup>.json

2. Copiez les fichiers créés à l’étape précédente sur la machine hôte. Modifiez l’autorisation de fichier de manière à activer l’autorisation de lecture totale pour les deux fichiers.

   docker cp my-server:/var/opt/tableau/tableau_server/data/tabsvc/files/backups/<repository-backup>.tsbak ./<repository-backup>.tsbak
   docker cp my-server:/var/opt/tableau/tableau_server/data/tabsvc/files/backups/<topology-conf-backup>.json ./<topology-conf-backup>.json
   chmod a+r ./<repository-backup>.tsbak ./<topology-conf-backup>.json

3. Stockez les artefacts de sauvegarde dans un emplacement sécurisé. Suivez les étapes de restauration ci-dessous si nécessaire.

Restauration au sein du conteneur Tableau Server

Les sauvegardes de toute version de Tableau Server prise en charge (conteneur et non-conteneur) peuvent être restaurées au sein du conteneur Tableau Server.

Conditions préalables

• Fichier de sauvegarde Tableau Server.
• Fichier json de configuration contenant à la fois des informations de configuration et de topologie.
• Remarque : vous devrez probablement modifier les fichiers de sauvegarde pour disposer de l’ensemble complet d’autorisations de lecture. Les fichiers de sauvegarde sont généralement verrouillés pour l’utilisateur qui a créé le fichier. Il est probable que ce dernier soit différent de l’utilisateur Tableau en cours d’exécution dans le conteneur.

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>

Remarques :

• Si vous restaurez un système multinœud, vous devez également démarrer les autres nœuds pour que l’automatisation de la restauration fonctionne. Consultez la section Tableau Server multinœud dans un conteneur dans le présent document pour plus d’informations. Seul le nœud initial requiert le fichier de sauvegarde, le fichier de configuration de sauvegarde et la licence.
• Les fichiers de sauvegarde n’ont besoin d’être fournis que lors de la première exécution du conteneur. Une fois le serveur initialisé, il n’est pas nécessaire de continuer le montage dans les fichiers de sauvegarde.

Migration de Tableau Desktop vers Tableau Server dans un conteneur

Afin de migrer d’une installation Tableau Server standard vers Tableau Server dans un conteneur, vous devez utiliser la technique de sauvegarde et de restauration. Les sauvegardes de toute version de Tableau Server prise en charge (conteneur et non-conteneur) peuvent être restaurées au sein du conteneur Tableau Server. Consultez la section Restauration au sein du conteneur Tableau Server ci-dessus pour plus d’informations.

Mise à niveau des versions de Tableau Server

Vous pouvez mettre à niveau Tableau Server de deux manières. La méthode Upgrade-Image répertoriée dans cette section est la solution recommandée. Toutefois, comme solution de repli, il est également possible de mettre à niveau Tableau Server à l’aide de la sauvegarde/restauration.

Mise à niveau par la méthode de mise à niveau-Image

L’image de mise à niveau est une image Docker qui peut être créée à l’aide du script build-upgrade-image à partir de l’outil d’installation de Tableau Server dans un conteneur. Le but de l’image est uniquement de mettre à niveau Tableau Server actuellement en cours d’exécution dans un conteneur.

Suivez les étapes ci-dessous pour effectuer la mise à niveau.

1. Créez une image de mise à niveau en utilisant le script build-upgrade-image. Le package rpm Tableau Server de la nouvelle version est nécessaire pour créer ce conteneur.
2. Arrêtez le conteneur exécutant actuellement Tableau Server.
3. Démarrez l’image de mise à niveau en montant le même répertoire de données depuis l’arrêt du conteneur à l’étape précédente.
4. Le processus de mise à niveau prend un certain temps, mais Tableau Server sera mis à niveau. Vérifiez la mise à jour du processus de mise à niveau dans les fichiers journaux Docker. Le conteneur s’arrêtera une fois le processus de mise à niveau terminé.
5. Démarrez une version plus récente de Tableau Server dans un conteneur. Montez le même répertoire à partir des étapes précédentes.

Exemple :

Imaginons que nous avons un Tableau Server dans un conteneur exécutant Tableau Server. Voici quelques hypothèses formulées dans cet exemple :

• J’ai des données précieuses et je ne veux pas perdre de données pendant le processus de mise à niveau. Le répertoire de données doit être conservé en dehors du conteneur.
• Le conteneur s’appelle my-server. L’image Docker s’appelle tableau-server :versionA.
• La version du serveur my-server actuellement utilisée est la version A.
• La version du serveur vers laquelle vous souhaitez mettre à niveau est la version B.

1. Obtenez le package rpm Tableau Server rpm pour la version B. Créez une image de mise à niveau.

   # For all the options available in the script
   ./build-upgrade-image -h
    
   # Frequently used command to create a upgrade-image
   ./build-upgrade-image --installer=<path to the tableau server version B> -i tableau-server:versionA -o tableau-server-upgrade:versionAB

2. Arrêtez le conteneur my-server.

   docker stop my-server -t 120

3. Démarrez l’image nouvellement créée tableau-server-upgrade :versionAB. Montez le même répertoire de données à partir du conteneur précédemment arrêté. Le conteneur démarre le processus de mise à niveau vers la version B.

   docker run --name my-upgrade-server \
   -v <data-dir mount from previous step>:/var/opt/tableau \
   ...
   tableau-server-upgrade:versionAB

4. Le conteneur s’arrêtera une fois la mise à niveau terminée. Vérifiez les fichiers journaux de processus de mise à niveau dans les fichiers journaux Docker et assurez-vous que le processus de mise à niveau est un succès. Vous pouvez également vérifier le code de sortie du conteneur Docker, pour vous assurer que le processus de mise à niveau s’est terminé avec succès.

   # The log file /var/opt/tableau/tableau_server/logs/upgrade-console.log is created after 3-4 mins into the start of upgrade container. When the upgrade completes successfully, "upgrade is complete" log will be # seen.
   docker logs my-upgrade-server
   ...
   ...
   Verifying licensing state.
   Tableau Server has been upgraded to version near.20.0801.1050.
   >> The upgraded Tableau binary directory will be added to PATH for new shells. To get the
   >> updated path, either start a new session, or for bash users run:
   >> source /etc/profile.d/tableau_server.sh
   Starting service...
   Starting service...
   Job id is '12', timeout is 30 minutes.
   Service was started successfully.
   Status: RUNNING
   Tableau Server is Running
   upgrade is complete

5. Arrêtez le conteneur my-upgrade-server. Démarrez la nouvelle version B de l’image de Tableau Server dans un conteneur et montez le répertoire de données à partir du conteneur my-upgrade-server arrêté

   # Stop the server.
   docker stop my-upgrade-server -t 120
   
   
   # Run the new version Hu
   docker run --name my-upgraded-server \
   -v <data-dir mount from previous step>:/var/opt/tableau \
   ...
   ...
   tableau-server:versionB

Mise à niveau par la méthode de sauvegarde-restauration

Suivez les étapes de la section Sauvegarde et restauration de ce document. Le seul ajustement nécessaire pour transformer une opération de sauvegarde-restauration en une opération de mise à niveau consiste à restaurer la sauvegarde sur une nouvelle version de Tableau Server.

Tableau Server multinœud dans un conteneur

Un déploiement multinœud de Tableau Server dans un conteneur désigne un déploiement unique de Tableau Server distribué sur plusieurs nœuds. Le déploiement multinœud dans ce contexte est identique au déploiement multinœud de Tableau Server où certains processus peuvent être exécutés sur d’autres nœuds afin d’augmenter la capacité, la puissance de calcul, etc. Il se distingue d’un démarrage de plusieurs instances individuelles de Tableau Server dans un conteneur où chaque conteneur est un serveur indépendant avec ses propres données distinctes.

Le déploiement multinœud de Tableau Server dans un conteneur fonctionne un peu comme une installation distribuée de Tableau Server sans conteneur et utilise le même mécanisme sous-jacent. Pour un aperçu de la configuration d’une installation distribuée de Tableau Server sans conteneur, consultez Installations Tableau Server distribuées et à haute disponibilité.

En voici un exemple :

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=<static (internal) 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=<static (internal) 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>

Exposer les licences et les ports TSM

Pour que les nœuds worker communiquent avec l’instance principale, nous devons ouvrir des ports supplémentaires. Vous devrez autoriser le trafic depuis d’autres nœuds sur votre instance principale de Tableau Server dans un conteneur sur les plages de ports suivantes :

Service Ports: 8800-9000
Postgres Port: 8060
Licensing Ports: 27000-27010

Attention au nombre de ports que vous ouvrez : Pour des raisons de performances, nous vous recommandons d’exposer seulement 200 ports (8800-9000) au lieu de la plage de ports locale par défaut 8000-9000 de Tableau Server. En effet, l’exposition de 1 000 ports dans Docker peut avoir un impact négatif sur le temps de démarrage de l’image Docker. Vous pouvez utiliser une plage de ports plus restreinte ou plus étendue en fonction de la complexité de votre topologie Tableau Server. En général, nous ne recommandons pas d’exposer moins de 100 ports, sinon vous courez le risque que les services d’un groupement ne soient pas en mesure de parler à certains services. Si vous spécifiez votre propre plage de ports, veillez à exposer le port 8850 (implicitement inclus dans la plage 8800-9000). La plage de ports est spécifiée à l’aide des variables d’environnement PORT_RANGE_MIN et PORT_RANGE_MAX.

Les nœuds supplémentaires devront également exposer la plage de ports de service (8800-9000), mais pas la plage de ports de licence. Il est important de noter que ces plages de ports servent uniquement à autoriser la communication inter-processus de Tableau Server. Ces ports ne doivent pas être exposés aux utilisateurs ou à d’autres machines que les ordinateurs exécutant Tableau Server dans un conteneur pour le même groupement multinœuds.

Ces règles de ports sont conformes à la documentation sur les pare-feu Tableau Server. Pour plus d’informations, consultez Configurer le pare-feu local.

Résolution des noms d’hôte

Des nœuds multiples de Tableau Server dans un conteneur doivent être exécutés avec des noms d’hôte cohérents parce que Tableau Server ne gère pas les changements dynamiques de nom d’hôte. Lors de l’exécution de Tableau Server multinœud, ces nœuds voudront communiquer les uns avec les autres. Les nœuds Tableau Server tenteront de se joindre les uns les autres à l’aide des noms d’hôtes configurés pour les nœuds multiples de Tableau Server dans un conteneur. Par exemple, si vous exécutez votre nœud initial avec un nom d’hôte « initial », les nœuds supplémentaire stenteront d’envoyer du trafic à un hôte appelé « initial ». Il existe plusieurs façons de configurer des images pour résoudre les noms d’hôte en d’autres images. Utilisez le fichier /etc/hosts dans chaque conteneur pour mapper le nom d’hôte arbitraire du conteneur (à savoir « initial ») à l’adresse IP qui exécute réellement l’autre conteneur.

Fichier bootstrap des nœuds supplémentaires

Le conteneur Tableau Server initial qui s’exécute dans le cadre d’un groupement génère un fichier bootstrap que les nœuds supplémentaires suivants doivent utiliser pour accéder au groupement. Une fois que des nœuds supplémentaires sont enregistrés dans la topologie du groupement, vous pouvez commencer à affecter des processus Tableau Server pour qu’ils s’exécutent dessus. Ce processus peut être entièrement automatisé. Si vous avez fourni un fichier de configuration Tableau Server (généralement fourni en montant un fichier de configuration sur le chemin de fichier spécifié par CONFIG_FILE, chemin par défaut : /docker/config/config.json ) qui spécifie une topologie multinœud, le nœud initial attendra automatiquement jusqu’à ce que tous les nœuds supplémentaires soient enregistrés. Une fois enregistrée, la topologie multinœuds sera appliquée à l’ensemble du groupement.

Une fois que le nœud initial Tableau Server dans un conteneur exécute pleinement Tableau Server, vous pouvez lui demander de générer un fichier bootstrap pour les nœuds supplémentaires :

docker exec -it <container-name> tsm topology nodes get-bootstrap-file -f $BOOTSTRAP_FILE

Cette commande est automatiquement appelée pour vous si vous définissez la valeur ALWAYS_WRITE_BOOTSTRAP_FILE sur 1.

Considérations de sécurité

Le fichier bootstrap contient des secrets de serveur qui lui permettent d’établir une session TSM avec le nœud initial. Cela signifie que si un utilisateur malveillant a obtenu le fichier, il pourrait envoyer des commandes TSM au serveur pendant un certain temps. Le fichier lui-même contient également des données permettant de déchiffrer des secrets de configuration du serveur. Ce fichier doit être traité comme sensible et ne doit être accessible que par des services et des systèmes directement liés à l’établissement d’un déploiement multinœud.

Expiration du fichier bootstrap

Les fichiers bootstrap sont associées à une session à durée limitée qui dure 2 heures. Dans ce volet, les nœuds supplémentaires n’auront pas besoin de fournir des identifiants au nœud initial pour se connecter en tant que nœud supplémentaire. Il est possible d’utiliser un fichier bootstrap une fois la session expirée, mais vous devez alors fournir des informations d’identification au nœud initial.

Transfert du fichier bootstrap

Le fichier bootstrap doit être mis à disposition et utilisé par les nœud worker Tableau Server dans un conteneur. Le fichier bootstrap devra être partagé avec tous les autres nœud Tableau Server dans un conteneur que vous souhaitez utiliser comme nœuds worker pour ce déploiement. Vous pouvez le faire de multiples façons.

Transférer le fichier sur un réseau sécurisé

Une partie de votre automatisation sur le nœud initial peut impliquer l’envoi du fichier directement aux nœuds supplémentaires. Vous devez le faire en utilisant un client/outil sécurisé de transfert de fichiers. Cette option est probablement plus utile dans les cas où plusieurs fichiers bootstrap peuvent être générés tout au long de la vie du nœud initial (peut-être pour ajouter plus d’autres nœuds supplémentaires ultérieurement).

Utiliser un montage de fichiers réseau

Il est également possible de monter des fichiers réseau partagés par tous les conteneurs dans un déploiement donné.

Autre

L’objectif final est de transférer en toute sécurité un fichier produit par un conteneur et de le transférer à un ensemble spécifique d’autres conteneurs. Ainsi, toute méthode qui atteint cet objectif et est sécurisé est suffisante.

Démarrage de nœuds supplémentaires

Pour démarrer un nœud supplémentaire Tableau Server dans un conteneur, il suffit de démarrer le conteneur avec la variable d’environnement BOOTSTRAP_INSTALL définie sur 1.

Cela indiquera à l’instance de Tableau Server dans un conteneur de rester en veille jusqu’à ce qu’il y ait un fichier bootstrap sur le chemin spécifié par la variable d’environnement BOOTSTRAP_FILE (qui est également configurable). Consultez la table des variables d’environnement pour afficher le chemin d’accès du fichier par défaut. Pour clarifier, si vous exécutez une image Tableau Server dans un conteneur en « mode nœud supplémentaire », le conteneur ne démarrera pas supervisord ou tout processus autre qu’un script bash fonctionnant en tant que pid 1 vérifiant toutes les 5 secondes l’existence du fichier bootstrap. Une fois le fichier présent, Tableau Server dans un conteneur lance l’initialisation en tant que nœud supplémentaire.

Configuration de nœuds supplémentaires

La configuration des nœuds supplémentaires pour exécuter une topologie spécifique fonctionne de la même façon que dans un déploiement Tableau Server normal. Elle vient avec les mêmes exigences, ce qui signifie que l’ajout de nouveaux processus sur un nœud peut nécessiter un redémarrage à l’échelle du groupement. Pour plus d’informations, consultez Configurer les nœuds.

Considérations relatives aux fonctionnalités de Tableau Server

Certaines fonctionnalités de Tableau Server fonctionnent différemment dans les conteneurs. Cette section couvre des fonctionnalités spécifiques présentant des considérations spéciales ou différentes dans un environnement de conteneur.

Active Directory

Définir le contrôleur de domaine AD

Si vous prévoyez d’utiliser Active Directory en tant que magasin d’identités pour les pages Web et les sites Tableau Server, vous devez prendre en compte une considération supplémentaire. Les instances Tableau Server exécutées dans des environnements Linux déterminent de manière dynamique avec quel contrôleur de domaine AD communiquer en examinant leur sous-réseau IP. Les conteneurs peuvent se voir attribuer des adresses IP arbitraires, et dans ce cas, Tableau Server ne pourra pas nécessairement utiliser son adresse IP pour trouver un contrôleur de domaine approprié. Pour cette raison, il peut être nécessaire de configurer un contrôleur de domaine/nom d’hôte spécifique avec lequel Tableau Server communiquera. Procédez comme suit :

1. Déterminez le contrôleur de domaine que Tableau Server doit utiliser et obtenez le nom d’hôte.

2. Définissez la clé de configuration wgserver.domain.ldap.hostname sur le nom d’hôte à l’aide des options de configuration standard de l’Administrateur Tableau Server :

   • Définissez la valeur dans le fichier de configuration jsonCONFIG_FILE.

   • Utilisez la commande de configuration TSM

     tsm configuration set -k wgserver.domain.ldap.hostname -v <hostname>

Importer un certificat AD dans le keystore Tableau Server

Par défaut, Tableau Server dans un conteneur communique avec AD via StartTLS chaque fois qu’une liaison simple est utilisée. Ainsi, lorsque le conteneur est exécuté dans cette configuration, il est nécessaire d’importer le certificat du serveur AD dans le magasin de clés Tableau Server, sinon l’initialisation du serveur échouera. Procédez comme suit :

1. Créez un script pre-init-command (consultez la section Script de pré-initialisation). Ajoutez la ligne suivante pour ajouter le certificat AD au keystore Tableau Server.

   ${INSTALL_DIR}/packages/repository.${SERVICE_VERSION}/jre/bin -importcert -noprompt -alias startTlsCert -file <mounted-certificate-path> -storetype JKS -storepass changeit -keystore ${DATA_DIR}/config/tableauservicesmanagerca.jks

2. Montez le certificat du serveur AD sur le chemin de fichier fourni pour le paramètre -file dans le script pre-init-command.

Sinon, le paramètre par défaut pour communiquer avec AD via StartTLS peut être désactivé. Définissez wgserver.domain.ldap.starttls.enabled sur false pour désactiver StartTLS. Cette option n’est toutefois pas recommandée.

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
-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 \
-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=<static (internal) 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=<static (internal) 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>