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.

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 pour plus d’informations.

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 <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 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 <namespace> \
--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 <cluster-name> \  
     --addon-name aws-efs-csi-driver \
     --region <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) 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. 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: <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 le client EFS et les stratégies EC2 en lecture seule. Consultez Conditions préalables pour Amazon Elastic Kubernetes Service (EKS) pour la résolution de <your-node-instance-role> à 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) 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. 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 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 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é

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

# 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 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(Le lien s’ouvre dans une nouvelle fenêtre)

• Guide de déploiement d’ingress-nginx(Le lien s’ouvre dans une nouvelle fenêtre)

• Prise en main de cert-manager(Le lien s’ouvre dans une nouvelle fenêtre)

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

# 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

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.

Ressources supplémentaires

• Documentation de Tableau Server(Le lien s’ouvre dans une nouvelle fenêtre)
• Documentation de Helm(Le lien s’ouvre dans une nouvelle fenêtre)
• Mise à niveau du graphique Helm(Le lien s’ouvre dans une nouvelle fenêtre)