--- schema_version: "1" id: 3d0d87311160c3b9eed72b0bf0c6b42fa12994fd3006d7a7b5d922c0013892bd title: Mise à l’échelle dynamique dans un conteneur - Gestionnaire de processus en arrière-plan Tableau Server collection: tableau version: current locale: fr-ca portal_url: https://docs.salesforce.com/tableau/current/fr-ca/server-linux/server-backgrounder-autoscaling.md canonical_url: https://help.tableau.com/current/server-linux/fr-ca/server-backgrounder-autoscaling.htm source_site: help.tableau.com content_type: documentation content_hash: 98148ab93db2705c99e4628a9f5a63945b917c36f8bf00b6c3e07043a7424321 description: Configure dynamic scaling of Backgrounders for Tableau Server in a container. --- [Passer au contenu principal](#main-content) # Mise à l’échelle dynamique dans un conteneur - Gestionnaire de processus en arrière-plan Tableau Server ## Introduction La mise à l’échelle dynamique du gestionnaire de processus en arrière-plan dans un conteneur permet l’application de diverses stratégies de mise à l’échelle au gestionnaire de processus en arrière-plan et aux tâches planifiées dans Tableau Server. Dans un tel contexte, la mise à l’échelle automatique implique que les services peuvent être mis à l’échelle de manière indépendante afin de gérer des charges de tâches variables sans nécessiter d’intervention humaine ni affecter la disponibilité d’autres systèmes de serveurs. Les conteneurs Tableau Server qui contiennent des nœuds complets de processus Tableau Server continueront à fonctionner comme des systèmes monolithiques. En revanche, un ensemble plus petit de services de conteneurs indépendants découplés comprenant le rôle de service du « gestionnaire de processus en arrière-plan » sera dynamiquement évolutif et gérera la charge de calcul qui, en temps normal, aurait été gérée par les conteneurs Tableau Server. Les services du gestionnaire de processus en arrière-plan sont chargés du traitement des tâches système, notamment l’actualisation/la création d’extraits, l’envoi d’abonnements, la vérification des alertes basées sur les données et de nombreuses tâches de maintenance. Si par exemple, à certains moments, il serait avantageux d’actualiser un grand nombre d’ensembles de données ou de calculer une série d’alertes de données gourmandes en termes de calcul, vous pouvez désormais utiliser Kubernetes pour augmenter la puissance de calcul afin d’exécuter ces tâches efficacement. Ce guide couvre les exigences de configuration et de déploiement pour la mise à l’échelle automatique des gestionnaires de processus en arrière-plan dans Kubernetes. Le présent document complète la documentation sur le [Tableau Server dans un conteneur](https://help.tableau.com/current/server-linux/fr-ca/server-in-container.htm). ## Conditions préalables La mise à l’échelle automatique des gestionnaires de processus en arrière-plan n’est disponible que dans Kubernetes et est basée sur Tableau Server dans des conteneurs. Pour utiliser la fonctionnalité de mise à l’échelle automatique des gestionnaires de processus en arrière-plan, vous devez remplir certains conditions préalables : - Tableau Server doit avoir les capacités Advanced Management. Pour plus d’information, consultez [À propos de Tableau Advanced Management sur Tableau Server](https://help.tableau.com/current/server-linux/fr-ca/itm_intro.htm). - Vous devez utiliser un modèle de licences basées sur les utilisateurs. Les licences basée sur les cœurs ne sont pas prises en charge. Pour plus de détails sur les licences, consultez [Comprendre les modèles de licence et les clés produit](https://help.tableau.com/current/server-linux/fr-ca/license_product_keys.htm). - Les fonctionnalités Advanced Management suivantes doivent être activées : - [Stockage de fichiers externe Tableau Server](https://help.tableau.com/current/server-linux/fr-ca/server_external_filestore_storage.htm) - [Référentiel externe Tableau Server](https://help.tableau.com/current/server-linux/fr-ca/server_external_repo.htm) - Vous devez avoir un groupement Kubernetes version 1.20 ou versions ultérieures et savoir comment l’utiliser et le gérer. ## Limites - Cette fonctionnalité ne marche que dans le cadre d’un déploiement avec Linux. - Les tâches de flux ne sont pas prises en charge lors de la mise à l’échelle automatique des gestionnaires de processus en arrière-plan. Elles seront gérées par les services du gestionnaire de processus en arrière-plan qui continuent de s’exécuter dans le conteneur Tableau Server. ## Créer des images de Tableau Server et du module de gestionnaire de processus en arrière-plan La première étape pour l’utilisation de la mise à l’échelle automatique des gestionnaires de processus en arrière-plan dans des conteneurs consiste à créer les images de service intégrées à l’installation de Tableau Server. Il s’agit de l’image Tableau Server et des images du gestionnaire de processus en arrière-plan et des services d’assistance. Vous utilisez le même outil de génération que celui utilisé pour créer l’image complète et intégrante du conteneur Tableau Server. Toutefois, vous devez utiliser la version 2022.3.0 de l’outil ou des versions ultérieures, vous devez avoir une licence Advanced Management et vous devez utiliser un indicateur spécial pour créer les images. 1. Pour créer les images de service, exécutez cette commande : build-image --accepteula -i --backgrounder-images Cette action permet de créer l’image Tableau Server et quatre nouvelles images. Ces autres images contiennent des services individuels qui constituent le nouveau module du gestionnaire de processus en arrière-plan pouvant faire l’objet d’une mise à l’échelle automatiquement. La commande `docker images` répertorie les images créées dans le référentiel docker local : hyper 20214.21.1117.1006 52fd9843c178 10 seconds ago gateway 20214.21.1117.1006 2308e602a2a3 11 seconds ago backgrounder 20214.21.1117.1006 4540e459cf23 12 seconds ago dataserver 20214.21.1117.1006 c5345ed47f51 12 seconds ago tableau\_server\_image 20214.21.1117.1006 b27817047dd1 7 minutes ago Les images hyper, passerelle indépendante, gestionnaire de processus en arrière-plan et serveur de données constituent le nouveau module du gestionnaire de processus en arrière-plan. Ces cinq images partagent les pilotes personnalisés, les scripts d’installation et les propriétés. Pour plus d’information, consultez [Personnalisation de l’image](https://help.tableau.com/current/server-linux/fr-ca/server-in-container_setup-tool.htm#CustomizingImage). 2. Publiez toutes ces images dans votre référentiel d’images interne en vue du déploiement. ## Guide de déploiement L’information suivante offre un contexte pour le déploiement de Tableau Server dans un conteneur et pour la mise à l’échelle automatique des gestionnaires de processus en arrière-plan. Cette information suppose que vous connaissez et savez déjà comment déployer Tableau Server dans un conteneur autonome. Pour plus d’informations, consultez [Tableau Server dans un conteneur](https://help.tableau.com/current/server-linux/fr-ca/server-in-container.htm). Pour configurer le déploiement, vous pouvez utiliser les trois fichiers de configuration Kubernetes situés dans la section Configuration Kubernetes comme modèles. Les autres sections de ce guide traitent des exigences et des détails du déploiement. Le déploiement de Tableau Server et la mise à l’échelle automatique des gestionnaires de processus en arrière-plan devraient être aussi simples que ceux des fichiers de configuration Kubernetes qui figurent au bas du guide : kubectl apply -f ### Tâches du gestionnaire de processus en arrière-plan Les modules de gestionnaires de processus en arrière-plan aident Tableau Server dans un conteneur à calculer les autres charges de travail programmées en parallèle. Le gestionnaire de processus en arrière-plan gère l’actualisation des extraits, l’abonnement, l’alerte, le flux et les charges de travail du système. La répartition des tâches entre les modules de gestionnaires de processus en arrière-plan implique la mise à disposition d’un plus grand nombre de ressources informatiques pour permettre à Tableau Server de gérer d’autres tâches, comme les activités interactives des utilisateurs, notamment le rendu des classeurs et des tableaux de bord. Les tâches de flux sont le seul type de tâche du gestionnaire de processus en arrière-plan qui ne s’exécute pas dans le gestionnaire de processus en arrière-plan. Pour plus d’information sur les tâches du gestionnaire de processus en arrière-plan, consultez [Gérer les tâches du gestionnaire de processus en arrière-plan dans Tableau Server](https://help.tableau.com/current/server-linux/fr-ca/server_backgrounder_job_management.htm). Les modules de gestionnaires de processus en arrière-plan peuvent gérer tout type de charge, à l’exception des tâches de flux, qui doivent être exécutées dans les principaux conteneurs de Tableau Server; ces derniers continuent d’exécuter le service du gestionnaire de processus en arrière-plan. La fonctionnalité Rôles de nœud donne aux utilisateurs la possibilité de dédier des modules de gestionnaires de processus en arrière-plan à un type de tâche spécifique. Cette fonctionnalité est une extension de la fonctionnalité Rôles de nœud sur Tableau Server. La description détaillée des différents rôles de nœud est disponible ici. Notez que, par défaut, les tâches de flux sont désactivées sur les modules de gestionnaires de processus en arrière-plan (c’est-à-dire que le rôle est défini sur « no-flows ») car les modules de gestionnaires de processus en arrière-plan ne peuvent pas exécuter de tâches de flux. Pour configurer les rôles de nœud pour le gestionnaire de processus en arrière-plan, vous devez définir la variable d’environnement `NODE_ROLES` comme partie du fichier de configuration kubeconfig pour le conteneur qui exécute le service du gestionnaire de processus en arrière-plan. Par exemple, pour configurer le gestionnaire de processus en arrière-plan de manière à ce qu’il n’exécute que les tâches d’actualisation d’extraits, configurez la variable d’environnement `NODE_ROLES` pour l’actualisation d’extraits tel qu’indiqué ci-dessous : #### NODE\_ROLE\_CONFIG containers: - name: backgrounder image: # Backgrounder Image ports: - containerPort: 8600 volumeMounts: - name: logmount mountPath: /var/log/tableau - name: clone-volume mountPath: /docker/clone - name: dataengine-volume mountPath: /docker/dataengine - name: temp mountPath: /var/opt/tableau/tableau\_server/data/tabsvc/temp env: - name: ROOT\_LOG\_DIR value: /var/log/tableau - name: CLONE\_ARTIFACT\_DIR value: /docker/clone/clone-artifacts - name: FILESTORE\_MOUNT\_PATH value: /docker/dataengine - name: NODE\_ROLES value: extract-refreshes Les modules de Tableau Server auront au moins un gestionnaire de processus en arrière-plan configuré de la même manière, ce qui est nécessaire pour s’assurer qu’il y a toujours un emplacement pour l’exécution des tâches du gestionnaire de processus en arrière-plan. Par défaut, TSM exigera qu’un gestionnaire de processus en arrière-plan capable de gérer chaque rôle de la tâche du gestionnaire de processus en arrière-plan soit disponible. Dans certains scénarios, vous voudrez peut-être que les modules du gestionnaire de processus en arrière-plan gèrent toutes les tâches d’un certain type. Pour cela, vous devez définir la clé de configuration du serveur `topology.roles_handle_all_jobs_constraint_disabled` sur `true`; cette action désactivera l’exigence selon laquelle la topologie TSM doit gérer tous les types de travaux. Lorsque ce paramètre est activé, le rôle du gestionnaire de processus en arrière-plan pour son instance sur Tableau Server peut être défini sur `no-extract-refreshes` et le rôle des modules de gestionnaires de processus en arrière-plan peut être défini sur `extract-refreshes`; cette action garantirait que toutes les tâches d’actualisation d’extraits ne s’exécutent que sur les modules de gestionnaires de processus en arrière-plan. **Remarque :** la désactivation de cette contrainte vous permet de configurer des rôles de manière à ce que certains types de travaux ne seront jamais programmés. Il est important de bien définir la configuration des rôles et des tâches des gestionnaires de processus en arrière-plan dans TSM car TSM ne vérifiera plus que tous les types de tâches du gestionnaire de processus en arrière-plan peuvent être programmés. ### Modules Tableau Server dans un conteneur Les conteneurs Tableau Server utilisés dans le cadre de la mise à l’échelle automatique des modules de gestionnaires de processus en arrière-plan se déploient presque de la même manière que le Tableau Server dans un conteneur que nous utilisons. On note cependant quelques changements dans les principales exigences : - Un partage de fichiers réseau est _nécessaire_ pour un transfert de configuration entre le conteneur Tableau Server et les modules de gestionnaires de processus en arrière-plan. - Vous devez activer et utiliser la fonctionnalité Stockage de fichiers externe. Cette action nécessite également un partage de fichiers réseau dédié. ### Modules de gestionnaires de processus en arrière-plan Les modules de gestionnaires de processus en arrière-plan sont quatre conteneurs de services indépendants qui fonctionnent ensemble : **passerelle**, **hyper**, **serveur de données** et **gestionnaire de processus en arrière-plan**. Vous pouvez déployer ces modules comme des modules authentiques du conteneur Kubernetes. Les exigences des modules sont les suivantes : - Les modules de gestionnaires de processus en arrière-plan devraient pouvoir atteindre le nœud Tableau Server à l’aide de la résolution DNS du nom d’hôte. - Il est impératif d’ouvrir les partages de fichiers réseau Stockage externe et Clonage. **Remarque :** les modules de gestionnaires de processus en arrière-plan sont configurés avec init-container pour attendre que le conteneur Tableau Server ait réussi à produire une sortie de configuration de clonage avant l’exécution. #### Fichiers journaux Les services des modules de gestionnaires de processus en arrière-plan (comme Tableau Server) continuent d’écrire les fichiers journaux principalement sur le disque. Étant donné que les modules de gestionnaires de processus en arrière-plan peuvent être mis à l’échelle, ils sont éphémères. Il est donc essentiel de s’assurer que les fichiers journaux sont stockés en dehors des modules. De nombreux clients qui disposent d’environnements K8 existants utilisent déjà un service d’agrégation des fichiers journaux d’un certain type pour collecter les fichiers journaux des modules qu’ils déploient. Splunk et fluentd sont par exemples des services d’agrégation de fichiers journaux. Nous recommandons vivement aux clients d’utiliser n’importe quel service d’agrégation des fichiers journaux pour collecter les fichiers journaux de leurs modules de gestionnaires de processus en arrière-plan. Pour faciliter la gestion des fichiers journaux, le kubeconfig que nous fournissons configure chaque service du module de manière à écrire sur un volume de fichiers journaux partagé. Le chemin du répertoire dans chaque conteneur de services est spécifié par la variable d’environnement `ROOT_LOG_DIR` . Si vous avez besoin d’ouvrir une demande d’assistance et de fournir des fichiers journaux, vous devez proposer deux ensembles de fichiers journaux : les fichiers journaux auto-décompressables collectés à partir des principaux conteneurs Server et les fichiers journaux des modules de gestionnaires de processus en arrière-plan (soit récupérés à partir de votre service d’agrégation de fichiers journaux, soit en suivant le processus manuel ci-dessous) . Pour les clients qui ne peuvent pas utiliser un service d’agrégation de fichier journaux, il est possible de récupérer les fichiers journaux manuellement à partir des modules. **Remarque :** les fichiers journaux provenant de tout module qui n’a pas utilisé de demande de volume persistant pour le volume contenant les fichiers journaux seront perdus lorsque le module sera mis à l’échelle! Tous les fichiers journaux concernés sont disponibles dans le répertoire `/var/log/tableau` (configurable par l’intermédiaire de la variable d’environnement `ROOT_LOG_DIR`) située à dans le module de gestionnaires de processus en arrière-plan. Nous vous recommandons vivement de monter une demande de volume persistant à cet emplacement afin que les fichiers journaux soient disponibles lorsque le module est effacé. ##### Collecter des fichiers journaux lorsque le module de gestionnaires de processus en arrière-plan est en cours d’exécution : Créez un fichier tar des fichiers journaux dans le conteneur : kubectl exec -it -- bash -c "tar -czf /docker/user/backgrounder-pod-logs.tar.gz /var/log/tableau" Copiez le fichier tar à l’extérieur du conteneur : kubectl cp :docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz ##### Collecter des fichiers journaux lorsque le module de gestionnaires de processus en arrière-plan s’est fermé (ou n’a pas pu démarrer) Associez n’importe quel module de longue durée à la demande de volume persistant montée qui est utilisée pour les fichiers journaux de déploiement du module de gestionnaires de processus en arrière-plan. Voici un exemple de configuration : apiVersion: v1 kind: Pod metadata: name: namespace: spec: containers: - name: get-logs-pod image: busybox:1.28 securityContext: runAsUser: 0 allowPrivilegeEscalation: true command: \['sh', '-c', "while :; do sleep 5; done"\] volumeMounts: - name: logmount mountPath: /var/log/tableau restartPolicy: Never volumes: - name: logmount persistentVolumeClaim: claimName: logvolume Créez un fichier tar des fichiers journaux dans le conteneur : kubectl exec -it -- bash -c "tar -czf /backgrounder-pod-logs.tar.gz /var/log/tableau" Copiez le fichier tar à l’extérieur du conteneur : kubectl cp :/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz #### Changements de configuration en direct Si vous modifiez des configurations dans Tableau Server dans un conteneur (par exemple en utilisant la ligne de commande tsm) et que vous souhaitez que ces changements de configuration soient représentées dans les modules de gestionnaires de processus en arrière-plan, vous devez exécuter la commande `[tsm settings clone](https://help.tableau.com/current/server-linux/fr-ca/cli_settings_tsm.htm#TSMSettingsClone)` pour créer un nouvel ensemble de fichiers de configuration clonés (« cloner la charge utile »). 1. Utilisez TSM pour modifier des configurations dans le module Tableau Server dans un conteneur et appliquez les changements de configuration au serveur. 2. Exécutez la commande suivante dans le module Tableau Server dans un conteneur : \## Run this command in the Tableau Server in a Container pod. tsm settings clone -d $CLONE\_ARTIFACT\_DIR Cette commande crée un nouvel ensemble de fichiers de configuration et l’écrit à l’emplacement du lecteur Clone NFS. 3. Redéployez vos modules de gestionnaires de processus en arrière-plan. Les modules doivent être configurés de manière à utiliser le lecteur Clone NFS et adopteront la nouvelle configuration. ### Stratégies de mise à l’échelle Les modules de gestionnaires de processus en arrière-plan peuvent être mis à l’échelle dans Kubernetes grâce à diverses techniques et stratégies. Nous proposons un exemple de stratégie de mise à l’échelle qui modifie la taille du pool du module de gestionnaires de processus en arrière-plan en fonction d’une programmation. Notez que l’utilisation de l’unité centrale de traitement et de la mémoire ne **sont** pas des indicateurs appropriés pour la mise à l’échelle des modules de gestionnaires de processus en arrière-plan. L’utilisation de la mémoire et de l’unité centrale de traitement ne représente pas avec précision la demande de charge globale sur le groupement. Par exemple, un module de gestionnaires de processus en arrière-plan peut être utilisé tout au plus pour actualiser un extrait, mais aucune autre tâche n’est en attente dans la file d’attente des tâches du gestionnaire de processus en arrière-plan. Dans ce cas, la mise à l’échelle automatique ne permettra pas d’améliorer le débit des tâches. #### Mise à l’échelle programmée Les mécanismes Kubernetes standard qui utilisent des tâches cron vous permettent de programmer une solution de mise à l’échelle. La section Configuration Kubernetes ci-dessous présente un exemple de configuration Kubernetes pour ce type de tâche. ## Configuration Kubernetes ### Nouvelles variables d’environnement En plus des variables d’environnement standard du conteneur Tableau Server (consultez [Options de configuration initiale](https://help.tableau.com/current/server-linux/fr-ca/server-in-container_image.htm#InitialConfigOptions-container)), de nouvelles variables d’environnement requises doivent être définies dans la configuration Kubernetes.
Variable d’environnementValeur recommandéeDescription
FILESTORE_MOUNT_PATH/docker/dataengineEmplacement de montage du répertoire de stockage de fichiers externe. Ce répertoire doit pointer sur le répertoire NFS du moteur de données monté dans chaque conteneur Tableau déployé. Pour plus d’information sur le stockage de fichiers externe, consultez Stockage de fichiers externe Tableau Server. La valeur doit être la même pour Tableau Server dans un module Conteneur et le module de gestionnaire de processus en arrière-plan.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsEmplacement de montage du répertoire de la configuration du clonage. Ce répertoire doit pointer sur un répertoire NFS monté dans chaque conteneur Tableau. Tableau Server va générer les données de configuration que les modules de gestionnaires de processus en arrière-plan utilisent avant de devenir membres du groupement.
ROOT_LOG_DIR/var/log/tableau(Modules de gestionnaires de processus en arrière-plan uniquement)

Emplacement du répertoire de fichiers journaux courant pour tous les services exécutés dans un module de gestionnaires de processus en arrière-plan.

### Ports du module de gestionnaires de processus en arrière-plan Les modules de gestionnaires de processus en arrière-plan se composent de quatre services. Chacun est par défaut configuré pour s’exécuter sur un port spécifié. Si vous souhaitez modifier le port sur lequel le service se connecte à l’intérieur du conteneur, vous devez fournir la clé qui correspond à l’affectation du port du service. Dans la plupart des cas, ce type de configuration ne devrait pas être nécessaire, sauf si un conteneur side-car ou un composant supplémentaire est ajouté au module et entre en conflit avec le port d’un service | Variable d’environnement du port | Par défaut | | --- | --- | | `BACKGROUNDER_PORT` | `8600` | | `DATASERVER_PORT` | `8400` | | `HYPER_PORT` | `8200` | | `GATEWAY_PORT` | `8080` | Dataserver utilise également le port 8300 qui ne peut pas être reconfiguré. ### Répertoire de réseau partagé Ce déploiement Tableau Server a besoin de deux partages réseau pour fonctionner correctement. Notez que ces répertoires de réseau sont présents dans tous les modèles de configuration Tableau Server, d gestionnaire de processus en arrière-plan ou de Kubernetes : - **Répertoire Dataengine** (`FILESTORE_MOUNT_PATH`) : les modules de gestionnaires de processus en arrière-plan nécessitent la fonctionnalité de stockage de fichiers externe. Ce partage réseau contient des extraits et d’autres artefacts basés sur des fichiers qui seront partagés entre Tableau Server et les modules de gestionnaires de processus en arrière-plan. - **Répertoire de clonage** (`CLONE_ARTIFACT_DIR`) : Tableau Server écrit les données statiques de connexion et de configuration sur un partage réseau. Les modules de gestionnaires de processus en arrière-plan utiliseront ces données pour devenir membres du groupement Tableau Server. Dans les futures pré-versions, cette configuration sera intégrée au cycle de vie standard de la configuration Kubernetes. **Important :** si vous souhaitez redéployer entièrement le groupement (notamment un nouveau conteneur Tableau Server), vous devez purger le contenu du montage NFS cloné (sinon les modules du gestionnaire de processus en arrière-plan tenteront de se connecter à l’ancien serveur). ### Exemples de configuration Kubernetes **Remarque :** les exemples de configuration incluent l’utilisation d’une sonde de préparation. Vous pouvez utiliser la sonde de préparation lorsque votre déploiement Tableau Server Container est un déploiement TSM à nœud unique (le déploiement peut inclure plusieurs modules de gestionnaire de processus en arrière-plan). Vous ne pouvez pas utiliser une sonde de préparation avec Tableau Server à plusieurs nœuds dans un déploiement de conteneur. #### Configuration du conteneur Tableau Server \--- apiVersion: v1 kind: Service metadata: name: namespace: spec: selector: app: ports: - protocol: TCP port: 8080 nodePort: name: http - protocol: TCP port: 8443 nodePort: name: https type: NodePort \--- apiVersion: v1 kind: ConfigMap metadata: name: configfile namespace: data: config.json: |- { "configEntities": { "identityStore": { "\_type": "identityStoreType", "type": "local" } }, "configKeys" : { "tabadmincontroller.init.smart\_defaults.enable" : "false", "wgserver.domain.ldap.starttls.enabled" : "false" }, "daysLeftForMaintenanceExpiring" : 0 } \--- apiVersion: v1 kind: ConfigMap metadata: name: extrepojsonfile namespace: data: config.json: |- { "flavor":"generic", "masterUsername":"", "masterPassword":"", "host":"", "port":5432, "prerequisiteCheckEnabled":false, "requireSsl":false } \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: datadir1 namespace: spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi \--- \# This is required for multi-node tableau server in container apiVersion: v1 kind: PersistentVolume metadata: name: bootstrapnfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- \# This is required for multi-node tableau server in container apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bootstrapnfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: PersistentVolumn metadata: name: clonenfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: clonenfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: PersistentVolume metadata: name: dataenginenfs namespace: spec: accessModes: - ReadWriteMany capacity: storage: 1Gi nfs: server: path: \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dataenginenfs namespace: spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Mi \--- apiVersion: v1 kind: Secret type: Opaque metadata: name: tableau-server-in-a-container-secrets namespace: stringData: license\_key: # Tableau License Key String tableau\_username: # Initial admin username in Tableau Server tableau\_password: # Initial admin password \--- apiVersion: apps/v1 kind: StatefulSet metadata: name: tableau-server namespace: labels: app: spec: selector: matchLabels: app: replicas: 1 serviceName: template: metadata: labels: app: spec: securityContext: runAsUser: 999 fsGroup: 998 fsGroupChangePolicy: "OnRootMismatch" terminationGracePeriodSeconds: 120 dnsPolicy: "None" dnsConfig: nameservers: - # DNS IP for resolving container hostnames searches: - ..svc.. # SRV Record - .svc.. # SRV Record - svc.. # SRV Record - . # SRV Record options: - name: ndots value: "5" initContainers: # init containers are optional, to clear directory content if already exists - name: clean-bootstrap-dir image: busybox:1.28 securityContext: runAsUser: 0 allowPrivilegeEscalation: true volumeMounts: - name: bootstrap mountPath: /docker/config/bootstrap command: \['sh', '-c', 'rm -rf /docker/config/bootstrap/\* || true'\] - name: clean-clone-artifacts-dir image: busybox:1.28 securityContext: runAsUser: 0 allowPrivilegeEscalation: true volumeMounts: - name: clone mountPath: /docker/clone command: \['sh', '-c', 'rm -rf /docker/clone/clone-artifacts || true'\] containers: - name: # Name of container image: # Tableau Server in Container Image env: - name: LICENSE\_KEY valueFrom: secretKeyRef: name: tableau-server-in-a-container-secrets key: license\_key - name: FILESTORE\_MOUNT\_PATH value: /docker/dataengine - name: CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS value: /docker/clone/clone-artifacts - name: SERVER\_FOR\_INDEPENDENT\_SERVICE\_CONTAINERS value: "1" - name: EXT\_REP\_JSON\_FILE value: /docker/external-repository/config.json - name: TABLEAU\_USERNAME valueFrom: secretKeyRef: name: tableau-server-in-a-container-secrets key: tableau\_username - name: TABLEAU\_PASSWORD valueFrom: secretKeyRef: name: tableau-server-in-a-container-secrets key: tableau\_password resources: requests: memory: 40Gi cpu: 15 limits: memory: 40Gi cpu: 15 ports: - containerPort: 8080 volumeMounts: - name: configmount mountPath: /docker/config/config.json subPath: config.json - name: externalrepomount mountPath: /docker/external-repository - name: datadir1 mountPath: /var/opt/tableau - name: bootstrap mountPath: /docker/config/bootstrap - name: clone mountPath: /docker/clone - name: dataengine mountPath: /docker/dataengine imagePullPolicy: IfNotPresent startupProbe: exec: command: - /bin/sh - -c - /docker/server-ready-check initialDelaySeconds: 300 periodSeconds: 15 timeoutSeconds: 30 failureThreshold: 200 readinessProbe: exec: command: - /bin/sh - -c - /docker/server-ready-check periodSeconds: 30 timeoutSeconds: 60 livenessProbe: exec: command: - /bin/sh - -c - /docker/alive-check initialDelaySeconds: 600 periodSeconds: 60 timeoutSeconds: 60 volumes: - name: configmount configMap: name: configfile - name: externalrepomount configMap: name: extrepojsonfile - name: datadir1 persistentVolumeClaim: claimName: datadir1 - name: bootstrap persistentVolumeClaim: claimName: bootstrapnfs - name: clone persistentVolumeClaim: claimName: clonenfs - name: dataengine persistentVolumeClaim: claimName: dataenginenfs #### Configuration du module de gestionnaires de processus en arrière-plan \--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: logvolume namespace: spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi \--- apiVersion: apps/v1 kind: Deployment metadata: name: backgrounder labels: app: backgrounder namespace: spec: replicas: 2 selector: matchLabels: app: backgrounder template: metadata: labels: app: backgrounder spec: securityContext: runAsUser: 999 runAsGroup: 998 fsGroup: 998 fsGroupChangePolicy: "OnRootMismatch" hostname: backgrounder dnsPolicy: "None" dnsConfig: nameservers: - # DNS IP for resolving container hostnames searches: - ..svc.. # SRV Record - .svc.. # SRV Record - svc.. # SRV Record - . # SRV Record options: - name: ndots value: "5" initContainers: - name: init-myservice image: busybox # This init-container is optional (as long as there is a mechanism to set the log volume directory permissions and the pod waits for clone artifacts) securityContext: runAsUser: 0 allowPrivilegeEscalation: true env: - name: CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS value: /docker/clone/clone-artifacts volumeMounts: - name: logmount mountPath: /var/log/tableau - name: clone-volume mountPath: /docker/clone command: \['sh', '-c', "chmod 777 /var/log/tableau && while \[ ! -d ${CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS} \]; do sleep 5; done"\] containers: - name: backgrounder image: # Backgrounder Image ports: - containerPort: 8600 imagePullPolicy: IfNotPresent readinessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' periodSeconds: 30 timeoutSeconds: 60 livenessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' initialDelaySeconds: 600 periodSeconds: 60 timeoutSeconds: 60 volumeMounts: - name: logmount mountPath: /var/log/tableau - name: clone-volume mountPath: /docker/clone - name: dataengine-volume mountPath: /docker/dataengine - name: temp mountPath: /var/opt/tableau/tableau\_server/data/tabsvc/temp env: - name: ROOT\_LOG\_DIR value: /var/log/tableau - name: CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS value: /docker/clone/clone-artifacts - name: FILESTORE\_MOUNT\_PATH value: /docker/dataengine - name: dataserver image: # Dataserver Image ports: - containerPort: 8400 imagePullPolicy: IfNotPresent readinessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' periodSeconds: 30 timeoutSeconds: 60 livenessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' initialDelaySeconds: 600 periodSeconds: 60 timeoutSeconds: 60 volumeMounts: - name: logmount mountPath: /var/log/tableau - name: clone-volume mountPath: /docker/clone - name: dataengine-volume mountPath: /docker/dataengine - name: temp mountPath: /var/opt/tableau/tableau\_server/data/tabsvc/temp env: - name: ROOT\_LOG\_DIR value: /var/log/tableau - name: CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS value: /docker/clone/clone-artifacts - name: FILESTORE\_MOUNT\_PATH value: /docker/dataengine - name: gateway image: # Gateway Image ports: - containerPort: 8080 imagePullPolicy: IfNotPresent readinessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' periodSeconds: 30 timeoutSeconds: 60 livenessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' initialDelaySeconds: 600 periodSeconds: 60 timeoutSeconds: 60 volumeMounts: - name: logmount mountPath: /var/log/tableau - name: clone-volume mountPath: /docker/clone - name: dataengine-volume mountPath: /docker/dataengine - name: temp mountPath: /var/opt/tableau/tableau\_server/data/tabsvc/temp env: - name: ROOT\_LOG\_DIR value: /var/log/tableau - name: CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS value: /docker/clone/clone-artifacts - name: FILESTORE\_MOUNT\_PATH value: /docker/dataengine - name: hyper image: # Hyper Image ports: - containerPort: 8200 imagePullPolicy: IfNotPresent readinessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' periodSeconds: 30 timeoutSeconds: 60 livenessProbe: exec: command: - /bin/sh - -c - /tsm\_docker\_utils/status\_check.sh | grep -E 'ACTIVE|BUSY' initialDelaySeconds: 600 periodSeconds: 60 timeoutSeconds: 60 volumeMounts: - name: logmount mountPath: /var/log/tableau - name: clone-volume mountPath: /docker/clone - name: dataengine-volume mountPath: /docker/dataengine - name: temp mountPath: /var/opt/tableau/tableau\_server/data/tabsvc/temp env: - name: ROOT\_LOG\_DIR value: /var/log/tableau - name: CLONE\_ARTIFACT\_DIR\_FOR\_INDEPENDENT\_CONTAINERS value: /docker/clone/clone-artifacts - name: FILESTORE\_MOUNT\_PATH value: /docker/dataengine volumes: - name: clone-volume nfs: server: path: - name: dataengine-volume nfs: server: path: /dataengine - name: logmount persistentVolumeClaim: claimName: logvolume - name: temp emptyDir: {} #### Configuration de la mise à l’échelle programmée apiVersion: v1 kind: ServiceAccount metadata: name: backgrounder-scaler-service-account namespace: # Namespace \--- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: scale-backgrounder-pods namespace: # Namespace subjects: \- kind: ServiceAccount name: backgrounder-scaler-service-account roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io \--- apiVersion: batch/v1beta1 kind: CronJob metadata: name: scale-up-job namespace: # Namespace spec: schedule: "0 7 \* \* \*" # Cron Job timing to scale up deployment replicas jobTemplate: spec: template: spec: serviceAccountName: backgrounder-scaler-service-account restartPolicy: OnFailure containers: \- name: scale image: bitnami/kubectl:1.21 imagePullPolicy: IfNotPresent args: \- scale \- --replicas=4 \- deployment/backgrounder \--- apiVersion: batch/v1beta1 kind: CronJob metadata: name: scale-down-job namespace: spec: schedule: "0 9 \* \* \*" # Cron Job timing to scale down deployment replicas jobTemplate: spec: template: spec: serviceAccountName: backgrounder-scaler-service-account restartPolicy: OnFailure containers: \- name: scale image: bitnami/kubectl:1.21 imagePullPolicy: IfNotPresent args: \- scale \- --replicas=2 \- deployment/backgrounder #### Tâche Kubernetes pour nettoyer une configuration de clonage (facultatif) Il s’agit d’une tâche Kubernetes pratique que vous pouvez utiliser lors des tests. Si vous souhaitez effacer la configuration de clonage générée par Tableau Server dans un conteneur entre plusieurs exécutions de déploiement, vous pouvez exécuter une tâche comme celle-ci pour nettoyer le NFS. apiVersion: batch/v1 kind: Job metadata: name: delete-clone-artifacts-job namespace: manatee-cluster spec: template: spec: containers: \- name: delete-clone-artifacts image: busybox:1.28 command: \['sh', '-c', "rm -rf ${CLONE\_ARTIFACT\_DIR}"\] env: \- name: CLONE\_ARTIFACT\_DIR value: /docker/clone/clone-artifacts securityContext: runAsUser: 0 allowPrivilegeEscalation: true volumeMounts: \- name: clone-volume mountPath: /docker/clone restartPolicy: Never volumes: \- name: clone-volume nfs: server: # IP for shared NFS directory for clone output path: /clone