--- schema_version: "1" id: a89a307c224ffe8fb2e3a88a26d1c3c13f85c9d75c55b661b435d9d1599e8c54 title: Déploiement avec un diagramme de Helm collection: tableau version: next locale: fr-ca portal_url: https://docs.salesforce.com/tableau/next/fr-ca/server/server-helm-deploy.md canonical_url: https://help.tableau.com/v0.0/server/fr-ca/server-helm-deploy.htm source_site: help.tableau.com content_type: documentation content_hash: 951f27121ee683a7266e805e48d99b0f2f0dc399c9feefbca0dbee30fef94f12 description: "Important : Cette documentation suppose une connaissance de Helm et des diagrammes de Helm" --- [Passer au contenu principal](#main-content) # Diagramme de Helm de Tableau Server - Déploiement **Important** : Cette documentation suppose une connaissance de Helm et des diagrammes de Helm. Elle ne cherche pas à fournir d’exemples détaillés et prescriptifs. Elle est destinée aux clients qui maîtrisent à la fois Tableau Server, Helm et les diagrammes de Helm. Cette rubrique décrit les grandes étapes du déploiement de Tableau Server sur Kubernetes à l’aide d’un diagramme de Helm. ## Conditions préalables Avant de commencer, vérifiez que vous remplissez les conditions préalables. Pour plus d’informations, consultez [Diagramme de Helm de Tableau Server - Conditions préalables](https://help.tableau.com/v0.0/server/fr-ca/server-helm-prerequisites.htm). ### Télécharger un diagramme de Helm Les diagrammes de Helm sont inclus dans l’outil d’installation de Tableau Server dans un 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-ca/support/releases/server/latest). Après l’extraction, les fichiers de diagrammes de Helm requis se trouvent dans le répertoire `helm/tableau`. ## Présentation rapide de l’utilisation d’un diagramme de Helm pour déployer Tableau Server **Important** : Il s’agit d’une description générale et sommaire du déploiement de Tableau Server à l’aide de diagrammes de Helm. Cette description ne constitue pas une procédure complète. Elle requiert une connaissance préalable de Helm et des diagrammes de Helm. Avant de commencer, vérifiez que vous remplissez les conditions préalables au déploiement de Tableau Server à l’aide des diagrammes de Helm. Consultez [Diagramme de Helm de Tableau Server - Conditions préalables](https://help.tableau.com/v0.0/server/fr-ca/server-helm-prerequisites.htm) pour plus de détails. ### Ajouter votre clé produit à values.yaml Modifiez `values.yaml` et définissez votre clé produit. ### Déployer un Tableau Server à nœud unique Déployez une instance à nœud unique de Tableau Server en exécutant ces commandes dans une 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 un Tableau Server multinœuds Déployez une instance multinœuds de Tableau Server en exécutant ces commandes dans une invite, en utilisant la même convention d’espace de noms que celle indiquée ci-dessus : helm install tableau-server ./helm/tableau-server \\ \-n \\ \--create-namespace \\ -f ./helm/tableau-server/values-multinode.yaml ## Runbook multinœuds 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é. Cette valeur doit être identique à celle de `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 existe. Si le module complémentaire est manquant, créez-le et attendez que son état devienne `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 le Storageclass : Storageclass `efs-bootstrap` : s’applique si ce n’est pas déjà fait. Consultez [Conditions préalables pour Elastic Kubernetes Service (EKS) d’Amazon](https://help.tableau.com/v0.0/server/fr-ca/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. Confirmez le PV de bootstrap statique. `claimRef` doit utiliser le même espace de noms et le même nom PVC généré par le diagramme de Helm (`tableau-server-bootstrap`). Remplacez `fs-...` par l’ID de votre 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 les stratégies en lecture seule du client EFS et de l’instance EC2. Consultez [Conditions préalables pour Elastic Kubernetes Service (EKS) d’Amazon](https://help.tableau.com/v0.0/server/fr-ca/server-helm-prerequisites.htm#EKS-Prereq-storageclass) pour résoudre `` à partir du groupe de nœuds. Storageclass `efs-bootstrap` : s’applique si ce n’est pas déjà fait. Consultez [Conditions préalables pour Elastic Kubernetes Service (EKS) d’Amazon](https://help.tableau.com/v0.0/server/fr-ca/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. Vérifiez que `image.repository`, `image.tag` et les secrets ou la licence sont définis comme requis. 8. Installer le diagramme de Helm Installez le diagramme 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 des données Les PVC de données peuvent afficher `Pending` brièvement jusqu’à ce que les volumes EBS soient connectés. Tous les PVC doivent passer à `Bound`, puis à `Running`, et finalement à `READY 1/1`. 11. Topologie (facultatif) Si le hook de post-installation est désactivé, vous devrez peut-être définir le nœud `clustercontroller` et appliquer les modifications en attente (consulter Automatisation de la topologie post-installation (hook) plus loin dans ce document). La commande `tsm pending-changes apply` peut générer des avertissements concernant la distribution du serveur d’indexation et de recherche ou l’ensemble du service de coordination lorsqu’il existe plusieurs nœuds Tableau. Pour résoudre ces avertissements, suivez les instructions décrites dans [Serveur d’indexation et de recherche](https://help.tableau.com/v0.0/server/fr-ca/server_process_index-and-search.htm) et [Service de coordination Tableau Server](https://help.tableau.com/v0.0/server/fr-ca/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 à nœud unique Le déploiement à nœud unique exécute Tableau Server comme un conteneur monolithique. Utiliser `values-single.yaml` ou définir : deploymentMode: "single" primary: replicaCount: 1 worker: replicaCount: 0 #### Déploiement multinœuds Le déploiement multinœuds exécute un nœud principal et un ou plusieurs nœuds worker. Définissez le nombre de nœuds worker avec `worker.replicaCount` : utilisez 1, 2 ou toute valeur supérieure autorisée par la capacité du groupement et la topologie Tableau. Le diagramme 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 nœuds worker) ou définissez explicitement : deploymentMode: "multinode" primary: replicaCount: 1 worker: replicaCount: 3 # example: three workers Alignement de la topologie : `values-multinode.yaml` est fourni avec un exemple de topologie `config.configJson` (identifiants de nœuds tels que `node1`, `node2`, `node3`). Si vous modifiez `worker.replicaCount` ou si vous réorganisez les services, mettez à jour cette topologie (et toute affectation de processus Tableau connexe) pour que le nombre et les rôles des nœuds TSM correspondent à votre déploiement. Consultez l’aide de Tableau Server pour le regroupement et la disposition des processus. ### Principales options de configuration #### Configuration de l’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 spécifier avec l’option `-f`. `secrets.yaml` : secrets: licenseKey: "YOUR-LICENSE-KEY" tsmRemotePassword: "YOUR-TSM-PASSWORD" tableauUsername: "YOUR-ADMIN-USER" tableauPassword: "YOUR-ADMIN-PASSWORD" Exemple d’installation ou 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 pour le moment. La seule méthode prise en charge consiste à utiliser des valeurs de graphique avec un fichier de valeurs distinct pour les secrets. #### Référentiel PostgreSQL externe Le diagramme de Helm n’active pas de référentiel externe par défaut à l’aide de clés de valeurs spécifiques. Nous vous recommandons de suivre les étapes suivantes pour activer un référentiel externe : 1. Déployez le diagramme et vérifiez l’intégrité du nœud principal. 2. Exécutez les commandes `tsm external repository` de Tableau 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 varie selon la version de Tableau (mode SSL, options de basculement, champs d’identifiants). pour plus d’informations, consultez Référentiel externe Tableau Server et topologie tsm. - Pour les déploiements clients, stockez les identifiants de base de données dans des secrets Kubernetes et évitez le texte brut dans l’historique de l’interpréteur. #### 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 regroupements utilisant un module complémentaire EFS CSI statique (par exemple avec `mounttargetip`), Helm peut gérer à la fois le PV et le 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 `chown/chmods /docker/config/bootstrap`, ce qui permet au processus Tableau (UID/GID 999:998) d’écrire `bootstrap.json` sur les montages EFS partagés dont la valeur par défaut est `root:root`. Lorsque `createPV: true`, le diagramme crée le PV de bootstrap à partir de valeurs (par exemple `tableau-bootstrap-pv`) et l’associe au PVC `tableau-server-bootstrap`. Si vous gérez manuellement le PV de bootstrap, créez d’abord `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 #### Entrée 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’entrée (exemple : contrôleur d’entrée NGINX) 1. Installez un contrôleur d’entrée dans le groupement (requis avant d’activer l’entrée du diagramme). 2. Définissez les valeurs d’entrée 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 qui dirige tableau.example.com vers le point de terminaison de votre contrôleur d’entrée ou équilibreur de charge. 4. Créez un secret TLS (ou utilisez cert-manager) dans l’espace de noms de version. 5. Déployez ou mettez à niveau le diagramme et vérifiez l’entrée : 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’entrée de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/) - [Guide de déploiement 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 diagramme prend en charge les sondes de démarrage, d’activité et de préparation. La sonde de démarrage autorise une première initialisation prolongée (par exemple, failureThreshold : 200 × periodSeconds) avant l’exécution des sondes d’activité ou de 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 des workers multinœuds, le diagramme utilise par défaut `worker.healthChecks.enabled: false` pour éviter de faux échecs de sonde lorsque les workers exécutent des ensembles de processus limités (par exemple, agent administrateur + contrôleur de groupement uniquement). ### Utilisation #### Accès à Tableau Server Après l’installation, accédez à Tableau Server selon la configuration de votre service : - **ClusterIP** : utiliser le transfert de port ou l’entrée - **NodePort** : accéder via `:` - **LoadBalancer** : accéder via l’adresse IP externe fournie #### Utilisation des 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 \# 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 #### Mettre à niveau le diagramme de Helm de Tableau Server helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/values.yaml #### Mettre à 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 multinœuds, ce diagramme peut exécuter une tâche hook de post-installation ou post-mise à niveau qui : - attend que les nœuds worker soient enregistrés dans TSM - définit l’affectation des processus `clustercontroller` des noeuds worker - 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 Valeur par défaut : - désactivé dans `values.yaml` - dans `values-multinode.yaml`, vérifiez `hooks.autoApplyWorkerTopology.enabled` (peut être `true` ou `false` selon la version; activez pour une configuration automatisée du worker `clustercontroller`) Vérifiez 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 Solution de secours manuelle en cas de désactivation ou d’échec du hook : exécution `tsm topology set-process` pour chaque nœud worker du TSM (généralement node2 à node(1+N) pour N workers; confirmez les identifiants 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 toute désinstallation. #### Étapes de validation Avant toute publication ou toute modification du diagramme, 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. Template (répétition) : 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 passe à l’état Ready) et des vérifications de base (par exemple `tsm status` ou HTTP vers le service). Pour plus d’informations sur le dépannage, consultez [Diagramme de Helm de Tableau Server - Dépannage](https://help.tableau.com/v0.0/server/fr-ca/server-helm-troubleshooting.htm). ## Ressources supplémentaires - [Documentation de Tableau Server](https://help.tableau.com/current/server-linux/fr-ca/) - [Documentation de Helm](https://helm.sh/docs/) - [Mise à niveau du diagramme de Helm](https://helm.sh/docs/helm/helm_upgrade/)