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.

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 pour plus de détails.

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 <namespace>, par exemple tableau ou default) :

helm install tableau-server ./helm/tableau-server \
  -n <namespace> \
  --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 <namespace> \
--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 <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <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 pour plus de détails.

   kubectl get csidriver efs.csi.aws.com
   aws eks describe-addon \
     --cluster-name <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <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: <fs-xxxxxxxxxxxxxxxxx>
   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 pour résoudre <your-node-instance-role> à 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 pour plus de détails.

   kubectl get csidriver efs.csi.aws.com
   aws eks describe-addon \
     --cluster-name <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <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 et Service de coordination Tableau Server.

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

deploymentMode: "single"
primary:
  replicaCount: 1
worker:
  replicaCount: 0

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

image:
  repository: tableau_server_image
  tag: "latest"
  pullPolicy: IfNotPresent
  pullSecrets: []

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 secrets.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.

# 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'

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

• Guide de déploiement ingress-nginx

• Prise en main de cert-manager

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

# 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

# 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

# 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

# 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.

Ressources supplémentaires

• Documentation de Tableau Server
• Documentation de Helm
• Mise à niveau du diagramme de Helm