--- schema_version: "1" id: 0d257bedf71db79b1f9934f7baca1a0b87b00a70d413413215d741dacb0d6533 title: Déploiement de graphique Helm collection: tableau version: next locale: fr-fr portal_url: https://docs.salesforce.com/tableau/next/fr-fr/server-linux/server-helm-deploy.md canonical_url: https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-deploy.htm source_site: help.tableau.com content_type: documentation content_hash: b7e1e37449802d53c96e68c2e35c91f3499e7d9d5433ee77118b1fabb69baf22 description: "Important : cette documentation présuppose une connaissance de Helm et des graphiques de Helm et ne prétend pas fournir des exemples détaillés et prescriptifs" --- [Passer au contenu principal](#main-content) # Graphique Helm de Tableau Server - Déploiement **Important** : cette documentation présuppose une connaissance de Helm et des graphiques de Helm et ne prétend pas fournir des exemples détaillés et prescriptifs. Elle s’adresse aux clients qui connaissent à la fois Tableau Server, Helm et les graphiques Helm. Cette rubrique présente les étapes générales du déploiement de Tableau Server sur Kubernetes à l’aide d’un graphique Helm. ## Conditions préalables Avant de commencer, assurez-vous que les conditions préalables sont remplies. Pour plus d’informations, consultez [Graphique Helm de Tableau Server - Conditions préalables](https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-prerequisites.htm). ### Téléchargement de graphique Helm Les graphiques Helm sont fournis avec Tableau Server dans un outil d’installation de conteneur (`tableau-server-container-setup-tool-.tar.gz`) et peuvent être téléchargés depuis la page de [téléchargement de Tableau Server](http://tableau.com/fr-fr/support/releases/server/latest). Une fois extraits, les fichiers de graphiques Helm requis se trouvent dans le répertoire `helm/tableau`. ## Aperçu rapide de l’utilisation d’un graphique Helm pour déployer Tableau Server **Important** : ceci est une description générale du déploiement de Tableau Server à l’aide de graphiques Helm. Il ne s’agit pas d’une procédure exhaustive. Il présuppose une connaissance de Helm et des graphiques Helm. Avant de commencer, assurez-vous que vous remplissez les conditions préalables au déploiement de Tableau Server à l’aide des graphiques Helm. Consultez [Graphique Helm de Tableau Server - Conditions préalables](https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-prerequisites.htm) pour plus d’informations. ### Ajouter votre clé produit à values.yaml Modifiez `values.yaml` et définissez votre clé produit. ### Déployer une instance de Tableau Server à nœud unique Déployez une instance de Tableau Server à nœud unique en exécutant ces commandes à l’invite (remplacez votre espace de nom de version par ``, par exemple `tableau` ou `default`) : helm install tableau-server ./helm/tableau-server \\ -n \\ --create-namespace \\ -f ./helm/tableau-server/values-single.yaml ### Déployer une instance multi-nœud de Tableau Server Déployez une instance multi-nœud de Server en exécutant ces commandes à l’invite, en utilisant la même convention d’espace de noms que ci-dessus : helm install tableau-server ./helm/tableau-server \\ \-n \\ \--create-namespace \\ -f ./helm/tableau-server/values-multinode.yaml ## Runbook multi-nœud EKS (espace de noms + PV de bootstrap statique) Cette section décrit l’ordre des opérations pour EKS : espace de noms dédié, module complémentaire EFS CSI, IAM sur le rôle de nœud, PV de bootstrap statique et Helm. 1. Créez un espace de noms dédié. Celui-ci doit correspondre à `claimFef.namespace` sur le PV de bootstrap. Cet exemple utilise `tableau`. kubectl create namespace tableau-server kubectl get namespace tableau 2. Vérifiez que le module complémentaire EFS CSI est présent. S’il est manquant, créez-le et attendez que l’état soit `ACTIVE` : kubectl get csidriver efs.csi.aws.com aws eks describe-addon \\ --cluster-name \\ --addon-name aws-efs-csi-driver \\ --region \\ --query 'addon.status' 3. Confirmez la StorageClass : StorageClass `efs-bootstrap` : s’applique s’il n’est pas déjà présent. Consultez [Conditions préalables pour Amazon Elastic Kubernetes Service (EKS)](https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-prerequisites.htm#EKS-Prereq-storageclass) pour plus de détails. kubectl get csidriver efs.csi.aws.com aws eks describe-addon \\ --cluster-name \\ --addon-name aws-efs-csi-driver \\ --region \\ --query 'addon.status' 4. Vérifiez le PV de bootstrap statique. `claimRef` doit faire référence au même espace de noms et au même nom de PVC que ceux créés par le graphique Helm (`tableau-server-bootstrap`). Remplacez `fs-...` par votre ID de système de fichiers EFS : cat > /tmp/tableau-bootstrap-pv.yaml <<'EOF' apiVersion: v1 kind: PersistentVolume metadata: name: tableau-bootstrap-pv spec: capacity: storage: 1Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-bootstrap claimRef: namespace: tableau name: tableau-server-bootstrap csi: driver: efs.csi.aws.com volumeHandle: EOF kubectl apply -f /tmp/tableau-bootstrap-pv.yaml kubectl get pv tableau-bootstrap-pv 5. IAM sur le rôle d’instance du nœud. Joignez le client EFS et les stratégies EC2 en lecture seule. Consultez [Conditions préalables pour Amazon Elastic Kubernetes Service (EKS)](https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-prerequisites.htm#EKS-Prereq-storageclass) pour la résolution de `` à partir du groupe de nœuds. StorageClass `efs-bootstrap` : s’applique s’il n’est pas déjà présent. Consultez [Conditions préalables pour Amazon Elastic Kubernetes Service (EKS)](https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-prerequisites.htm#EKS-Prereq-storageclass) pour plus de détails. kubectl get csidriver efs.csi.aws.com aws eks describe-addon \\ --cluster-name \\ --addon-name aws-efs-csi-driver \\ --region \\ --query 'addon.status' 6. Valeurs Dans `values-multinode.yaml` (ou une superposition), définissez le mode PV statique manuel persistence: bootstrap: createPV: false volumeName: tableau-bootstrap-pv storageClass: efs-bootstrap 7. Assurez-vous que `image.repository`, `image.tag` et les secrets/licence sont définis comme requis. 8. Installer le graphique Helm Installez le graphique dans le même espace de noms que le PV `claimRef` : helm install tableau-server ./helm/tableau-server \\ -n tableau \\ -f ./helm/tableau-server/values-multinode.yaml 9. Vérifiez le stockage et les pods : kubectl get pv,pvc -n tableau kubectl get pods -n tableau -w 10. Statut du PVC de données Les PVC de données peuvent afficher `Pending` brièvement jusqu’à ce que des volumes EBS soient connectés. Tous les PVC doivent passer à `Bound`, puis `Running`, et enfin `READY 1/1`. 11. Topologie (facultatif) Si le hook post-installation est désactivé, vous devrez peut-être définir le nœud `clustercontroller` et appliquer les modifications en attente (voir Automatisation de la topologie post-installation (hook) plus loin dans ce document). La commande `tsm pending-changes apply` peut entraîner des avertissements sur la distribution du serveur d’indexation et de recherche ou sur l’ensemble du service de coordination lorsque vous avez plusieurs nœuds Tableau. Traitez ces avertissements comme indiqué dans [Serveur d’indexation et de recherche](https://help.tableau.com/v0.0/server-linux/fr-fr/server_process_index-and-search.htm) et [Service de coordination Tableau Server](https://help.tableau.com/v0.0/server-linux/fr-fr/server_process_coordination.htm). ### Installation personnalisée 1. Personnaliser les valeurs cp ./helm/tableau-server/values.yaml ./helm/tableau-server/my-values.yaml \# Edit ./helm/tableau-server/my-values.yaml with your configuration 2. Installer avec des valeurs personnalisées helm install tableau-server ./helm/tableau-server -f ./helm/tableau-server/my-values.yaml ## Configuration ### Modes de déploiement #### Déploiement sur un seul nœud Le déploiement sur un seul nœud exécute Tableau Server en tant que conteneur monolithique. Utilisez `values-single.yaml` ou définissez : deploymentMode: "single" primary: replicaCount: 1 worker: replicaCount: 0 #### Déploiement multi-nœud Le déploiement multinœud exécute un serveur principal et un ou plusieurs workers. Définissez le nombre de workers avec `worker.replicaCount` : utilisez 1, 2 ou toute valeur supérieure autorisée par la capacité de votre cluster et la topologie Tableau. Le graphique crée `tableau-server-worker-0 … tableau-server-worker-(N-1)` pour `replicaCount: N`. Utilisez `values-multinode.yaml` (l’exemple par défaut utilise deux workers) ou définissez explicitement : deploymentMode: "multinode" primary: replicaCount: 1 worker: replicaCount: 3 # example: three workers Alignement de la topologie : `values-multinode.yaml` est livré avec un exemple de topologie `config.configJson` (ID de nœud tels que `node1`, `node2`, `node3`). Si vous modifiez `worker.replicaCount` ou réorganisez les services, mettez à jour cette topologie (et toute affectation de processus Tableau associé) afin que le nombre et les rôles des nœuds TSM correspondent à votre déploiement. Consultez l’aide de Tableau Server au sujet du clustering et de l’organisation des processus. ### Options de configuration de clé #### Configuration d’image image: repository: tableau\_server\_image tag: "latest" pullPolicy: IfNotPresent pullSecrets: \[\] #### Licence et secrets secrets: licenseKey: "YOUR-LICENSE-KEY" tsmRemotePassword: "password" tableauUsername: "admin" tableauPassword: "password" Sinon, vous pouvez les définir à l’aide de variables d’environnement : env: LICENSE\_KEY: "YOUR-LICENSE-KEY" TSM\_REMOTE\_PASSWORD: "password" TABLEAU\_USERNAME: "admin" TABLEAU\_PASSWORD: "password" Nous vous recommandons d’utiliser un fichier séparé (par exemple, `secrets.yaml`) et de le transmettre avec le commutateur `-f`. `secrets.yaml`: secrets: licenseKey: "YOUR-LICENSE-KEY" tsmRemotePassword: "YOUR-TSM-PASSWORD" tableauUsername: "YOUR-ADMIN-USER" tableauPassword: "YOUR-ADMIN-PASSWORD" Exemple d’installation/de mise à niveau avec `secrets.yaml` : helm upgrade --install tableau-server ./helm/tableau-server \\ -n default \\ -f ./helm/tableau-server/values-multinode.yaml \\ -f ./helm/tableau-server/secrets.yaml **Remarque :** le référencement d’un secret Kubernetes préexistant (par exemple s`ecrets.existingSecret`) n’est pas pris en charge actuellement. La seule méthode prise en charge consiste à utiliser des valeurs de graphique avec un fichier de valeurs de secrets séparé. #### Référentiel externe PostgreSQL Le graphique Helm n’active pas un référentiel externe par défaut à l’aide de clés de valeurs dédiées. Nous vous recommandons de suivre les étapes suivantes pour activer un référentiel externe : 1. Déployez le graphique et vérifiez l’intégrité du serveur principal. 2. Exécutez des commandes Tableau `tsm external repository` depuis le pod principal. 3. Appliquez les modifications en attente. Exemple de flux de travail (découverte et application des commandes) : \# Discover command syntax for your Tableau version kubectl exec -n default tableau-server-primary-0 -- sh -lc 'tsm topology external-services repository enable --help' \# After enabling external repository with Tableau-supported args/options: kubectl exec -n default tableau-server-primary-0 -- sh -lc 'tsm pending-changes apply -iw --ignore-prompt' kubectl exec -n default tableau-server-primary-0 -- sh -lc 'tsm status -v' Remarques : - La configuration du référentiel externe est spécifique à la version de Tableau (mode SSL, options de basculement, champs d’identifiants). Pour plus d’informations, consultez [Référentiel externe Tableau Server](https://help.tableau.com/v0.0/server-linux/fr-fr/server_external_repo.htm) et [tsm topology](https://help.tableau.com/v0.0/server-linux/fr-fr/cli_topology_tsm.htm). - Pour les déploiements clients, stockez les informations d’identification pour la base de données dans des secrets Kubernetes et évitez le texte ordinaire dans l’historique de l’interpréteur de commandes. #### Stockage persistant persistence: enabled: true storageClass: "standard" accessMode: ReadWriteOnce size: 100Gi # Bootstrap volume (required for multi-node) bootstrap: enabled: true storageClass: "standard" accessMode: ReadWriteMany size: 1Gi createPV: false Pour les clusters utilisant EFS CSI statique (par exemple avec `mounttargetip`), Helm peut gérer à la fois les PV et les PVC de bootstrap : persistence: bootstrap: enabled: true storageClass: "efs-bootstrap" accessMode: ReadWriteMany size: 1Gi createPV: true permissionsFix: enabled: true pv: name: "tableau-bootstrap-pv" csi: driver: efs.csi.aws.com volumeHandle: "fs-xxxxxxxx" volumeAttributes: mounttargetip: "10.x.x.x" `permissionsFix.enabled` ajoute un conteneur d’initialisation qui permet au processus Tableau (UID/GID 999:998) `chown/chmods /docker/config/bootstrap` d’écrire `bootstrap.json` sur les montages EFS partagés dont la valeur par défaut est `root:root`. Lorsque `createPV: true`, le graphique crée le PV de bootstrap à partir de valeurs (par exemple `tableau-bootstrap-pv`) et y relie le PVC `tableau-server-bootstrap`. Si vous gérez manuellement le PV de bootstrap, commencez par créer `tableau-bootstrap-pv`, puis installez Helm avec `createPV: false` et `volumeName: tableau-bootstrap-pv:` apiVersion: v1 kind: PersistentVolume metadata: name: tableau-bootstrap-pv spec: capacity: storage: 1Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-bootstrap csi: driver: efs.csi.aws.com volumeHandle: fs-xxxxxxxx volumeAttributes: mounttargetip: 10.x.x.x kubectl apply -f tableau-bootstrap-pv.yaml kubectl get pv tableau-bootstrap-pv #### Limites de ressources primary: resources: limits: cpu: "4" memory: "8Gi" requests: cpu: "2" memory: "4Gi" worker: resources: limits: cpu: "4" memory: "8Gi" requests: cpu: "2" memory: "4Gi" #### Configuration du service service: primary: type: ClusterIP # or NodePort, LoadBalancer ports: http: 80 https: 8080 tsm: 8850 #### Ingress ingress: enabled: true className: "nginx" hosts: - host: tableau.example.com paths: - path: / pathType: Prefix tls: - secretName: tableau-tls hosts: - tableau.example.com #### Runbook de configuration d’ingress (exemple : contrôleur d’ingress NGINX) 1. Installez un contrôleur d’ingress dans le cluster (requis avant d’activer l’ingress de graphique). 2. Définissez les valeurs d’ingress dans votre fichier de valeurs : ingress: enabled: true className: "nginx" annotations: nginx.ingress.kubernetes.io/proxy-body-size: "64m" nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" hosts: - host: tableau.example.com paths: - path: / pathType: Prefix tls: - secretName: tableau-tls hosts: - tableau.example.com 3. Créez un enregistrement DNS pointant tableau.example.com vers le point de terminaison de votre ingress/équilibreur de charge. 4. Créez un secret TLS (ou utilisez cert-manager) dans l’espace de noms release. 5. Déployez/mettez à niveau le graphique et vérifiez l’ingress : helm upgrade --install tableau-server ./helm/tableau-server -n default -f ./helm/tableau-server/values.yaml kubectl get ingress -n default kubectl describe ingress tableau-server Pour plus d’informations, consultez : - [Concept d’ingress Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/) - [Guide de déploiement d’ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/) - [Prise en main de cert-manager](https://cert-manager.io/docs/tutorials/getting-started-aks-letsencrypt/) #### Contrôles d’intégrité Le graphique prend en charge les sondes de démarrage, d’activité et de préparation. La sonde de démarrage autorise une initialisation initiale longue (par exemple, failureThreshold : 200 × periodSeconds) avant l’exécution d’activité/préparation : healthChecks: startup: enabled: true initialDelaySeconds: 300 periodSeconds: 15 timeoutSeconds: 30 failureThreshold: 200 liveness: enabled: true initialDelaySeconds: 300 periodSeconds: 30 timeoutSeconds: 10 failureThreshold: 3 readiness: enabled: true initialDelaySeconds: 300 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 Pour les pods de worker multi-nœud, le graphique par défaut `worker.healthChecks.enabled: false` permet d’éviter les échecs de fausse sonde lorsque les workers exécutent des ensembles de processus limités (par exemple, agent administrateur + contrôleur de cluster uniquement). ### Utilisation #### Accès à Tableau Server Après l’installation, accédez à Tableau Server en fonction de la configuration de votre service : - **ClusterIP :** utiliser la redirection de port ou l’ingress - **NodePort :** accès via `:` - **LoadBalancer :** accès via l’adresse IP externe fournie #### Utilisation de commandes TSM \# Get pod name POD\_NAME=$(kubectl get pods -l app.kubernetes.io/component=primary -o jsonpath='{.items\[0\].metadata.name}') # Run tabcmd kubectl exec -it $POD\_NAME -- tsm status kubectl exec -it $POD\_NAME -- tsm configuration get #### Utilisation de tabcmd \# Get pod name POD\_NAME=$(kubectl get pods -l app.kubernetes.io/component=primary -o jsonpath='{.items\[0\].metadata.name}') # Run tabcmd kubectl exec -it $POD\_NAME -- tabcmd login -u admin -p password kubectl exec -it $POD\_NAME -- tabcmd sites #### Affichage des fichiers journaux Tableau Server \# Primary node logs kubectl logs -l app.kubernetes.io/component=primary -f # Worker node logs (multi-node) kubectl logs -l app.kubernetes.io/component=worker -f # All logs kubectl logs -l app.kubernetes.io/instance=tableau-server -f #### Accès à l’interpréteur de commandes \# Get pod name POD\_NAME=$(kubectl get pods -l app.kubernetes.io/component=primary -o jsonpath='{.items\[0\].metadata.name}') # Open shell kubectl exec -it $POD\_NAME -- /bin/bash ### Mise à niveau #### Mise à niveau du graphique Helm de Tableau Server helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/values.yaml #### Mise à niveau avec de nouvelles valeurs helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/new-values.yaml ### Automatisation de la topologie post-installation (hook) Pour les installations multi-nœud, ce graphique peut exécuter une tâche « hook » post-installation/post-mise à niveau qui : - Attend que les nœuds worker soient enregistrés dans TSM - Définit l’affectation du processus worker `clustercontroller` - Exécute `tsm pending-changes apply -iw --ignore-prompt` lorsque des modifications sont en attente Configuration : hooks: autoApplyWorkerTopology: enabled: true kubectlImage: "bitnami/kubectl:latest" timeoutSeconds: 3600 Paramètres par défaut : - désactivé dans `values.yaml` - Dans `values-multinode.yaml`, cochez `hooks.autoApplyWorkerTopology.enabled` (peut être `true` ou `false` selon la version ; activez pour une configuration de worker `clustercontroller` sans intervention) Vérifier l’exécution du hook : kubectl get jobs -n default kubectl get pods -n default -l job-name=tableau-server-hook-topology kubectl logs -n default job/tableau-server-hook-topology Secours manuel en cas de désactivation ou d’échec du hook : exécutez `tsm topology set-process` pour chaque nœud worker TSM (généralement node2 à node(1+N) lorsque vous avez N workers ; confirmez les ID avec `tsm topology list-nodes -v`) : kubectl exec -n default tableau-server-primary-0 -- sh -lc ' tsm topology set-process -n node2 -pr clustercontroller -c 1 tsm topology set-process -n node3 -pr clustercontroller -c 1 # Add one line per additional worker node, e.g. for four workers: # tsm topology set-process -n node4 -pr clustercontroller -c 1 # tsm topology set-process -n node5 -pr clustercontroller -c 1 tsm pending-changes apply -iw --ignore-prompt tsm topology list-nodes -v tsm status -v **Remarque** : utilisez `-iw` pour `tsm pending-changes apply`. L’option `-ig` n’est pas valide dans cet environnement. ### Désinstallation helm uninstall tableau-server **Avertissement :** cette opération supprimera toutes les ressources, y compris les volumes persistants. Veillez à sauvegarder vos données avant de désinstaller. #### Étapes de validation Avant la publication ou lors de la modification du graphique, exécutez : 1. Lint : helm lint helm/tableau-server -f helm/tableau-server/values-single.yaml helm lint helm/tableau-server -f helm/tableau-server/values-multinode.yaml 2. Modèle (essai) : helm template tableau-server helm/tableau-server -f helm/tableau-server/values-single.yaml helm template tableau-server helm/tableau-server -f helm/tableau-server/values-multinode.yaml 3. Test d’installation (facultatif) : 1. Dans un espace de noms de test, exécutez `helm install` avec values-single ou values-multinode. 2. Exécutez `kubectl rollout status` (pour StatefulSet, attendez que le pod soit prêt) et des tests de vérification de base (par exemple `tsm status` ou HTTP vers le service). Pour un dépannage détaillé, consultez [Graphique Helm de Tableau Server - Résolution des problèmes](https://help.tableau.com/v0.0/server-linux/fr-fr/server-helm-troubleshooting.htm). ## Ressources supplémentaires - [Documentation de Tableau Server](https://help.tableau.com/current/server-linux/fr-fr/) - [Documentation de Helm](https://helm.sh/docs/) - [Mise à niveau du graphique Helm](https://helm.sh/docs/helm/helm_upgrade/)