--- schema_version: "1" id: 0fd1a14c6f41304a5be6cdd631b1543f244dc4c920a875bceb4de7106fae97d8 title: Scalabilità dinamica in un contenitore - Gestione componenti in background di Tableau Server collection: tableau version: next locale: it-it portal_url: https://docs.salesforce.com/tableau/next/it-it/server-linux/server-backgrounder-autoscaling.md canonical_url: https://help.tableau.com/v0.0/server-linux/it-it/server-backgrounder-autoscaling.htm source_site: help.tableau.com content_type: documentation content_hash: 75d343ebadaa834866e2fc3d799bcda5b3264a778243272d44db1cc20d1add5a description: Configure dynamic scaling of Backgrounders for Tableau Server in a container. --- [Passa al contenuto principale](#main-content) # Scalabilità dinamica in un contenitore - Gestione componenti in background di Tableau Server ## Introduzione La scalabilità dinamica di Gestione componenti in background in un contenitore consente l’applicazione di varie strategie di scalabilità alla gestione componenti in background e ai processi pianificati in Tableau Server. La scalabilità automatica in questo contesto significa che i servizi possono essere ridimensionati in modo indipendente per gestire carichi di attività variabili senza richiedere l’intervento umano o influire sui tempi di funzionamento di altri sistemi di server. I contenitori di Tableau Server che contengono nodi completi di processi di Tableau Server continueranno a essere eseguiti come sistemi monolitici. Al contrario, un insieme più piccolo di servizi per contenitore indipendenti disaccoppiati che comprende il ruolo del servizio di "gestione componenti in background" sarà scalabile dinamicamente e gestirà il carico di calcolo che normalmente verrebbe gestito dai contenitori di Tableau Server. I servizi di gestione componenti in background sono responsabili dell’elaborazione delle attività di sistema che includono estrazioni di aggiornamento/creazione, invio di sottoscrizioni, controllo di avvisi basati sui dati e molti processi di manutenzione. Se in alcuni casi, ad esempio, sarebbe vantaggioso aggiornare un numero elevato di insiemi di dati o elaborare una serie di avvisi basati sui dati molto costosi a livello di calcolo, ora è possibile sfruttare Kubernetes per incrementare la potenza di calcolo per completare queste attività in modo efficiente. Questa guida tratta i requisiti di configurazione e distribuzione per la gestione componenti in background con scalabilità automatica in Kubernetes. Questo documento è un supplemento alla documentazione per [Tableau Server in un contenitore](https://help.tableau.com/v0.0/server-linux/it-it/server-in-container.htm). ## Prerequisiti La gestione componenti in background con scalabilità automatica è disponibile solo in Kubernetes ed è basata su Tableau Server in contenitori. Per utilizzare la funzionalità di gestione componenti in background con scalabilità automatica, è necessario soddisfare alcuni prerequisiti: - Tableau Server deve disporre delle funzionalità di Advanced Management. Per maggiori informazioni, consulta [Informazioni su Tableau Advanced Management su Tableau Server](https://help.tableau.com/v0.0/server-linux/it-it/itm_intro.htm). - È necessario utilizzare le licenze basate sui ruoli. Non sono supportate le licenze core. Per informazioni sulle licenze, consulta [Informazioni sui modelli di licenza e i codici prodotto](https://help.tableau.com/v0.0/server-linux/it-it/license_product_keys.htm). - Devono essere abilitate le seguenti funzionalità di Advanced Management: - [Archivio file esterno di Tableau Server](https://help.tableau.com/v0.0/server-linux/it-it/server_external_filestore_storage.htm) - [Repository esterno di Tableau Server](https://help.tableau.com/v0.0/server-linux/it-it/server_external_repo.htm) - Devi disporre di un cluster Kubernetes versione 1.20 o successiva e comprendere come utilizzarlo e gestirlo. ## Limitazioni - Questa funzionalità funziona solo come parte di una distribuzione basata su Linux. - I processi di flusso non sono supportati nella gestione componenti in background con scalabilità automatica. I processi di flusso vengono gestiti nei servizi di gestione componenti in background che continuano a essere eseguiti nel contenitore Tableau Server. ## Creazione di immagini dei pod di Tableau Server e della gestione componenti in background Il primo passo per l’utilizzo della gestione componenti in background con scalabilità automatica è la creazione di immagini del servizio che includono l’installazione di Tableau Server. Queste immagini includono l’immagine di Tableau Server e le immagini per i servizi separati di gestione componenti in background e supporto. Puoi utilizzare lo stesso strumento di compilazione utilizzato per creare l’immagine completa del contenitore di Tableau Server, ma la versione dello strumento deve essere la 2022.3.0 o successiva, devi disporre di una licenza Advanced Management e devi utilizzare un flag speciale durante la creazione delle immagini. 1. Per creare le immagini del servizio, eseguire questo comando: build-image --accepteula -i --backgrounder-images In questo modo viene creato Tableau Server e quattro nuove immagini. Queste immagini aggiuntive contengono servizi individuali che includono il nuovo pod di gestione componenti in background con scalabilità automatica. Il comando `docker images` elenca le immagini create nel repository Docker locale: 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 Le immagini hyper, gateway, backgrounder e dataserver includono il nuovo pod di gestione componenti in background. Tutte e cinque queste immagini condividono driver personalizzati, script di installazione e proprietà. Per maggiori informazioni, consulta [Personalizzazione dell’immagine](https://help.tableau.com/v0.0/server-linux/it-it/server-in-container_setup-tool.htm#CustomizingImage). 2. Pubblica tutte queste immagini nel tuo repository di immagini interno per la distribuzione. ## Guida alla distribuzione Le seguenti informazioni forniscono il contesto per la distribuzione di Tableau Server in un contenitore e con gestione componenti in background con scalabilità automatica. Queste informazioni presuppongono che tu comprenda e sappia già come distribuire Tableau Server in un contenitore autonomo. Per maggiori informazioni, consulta [Tableau Server in un contenitore](https://help.tableau.com/v0.0/server-linux/it-it/server-in-container.htm). I tre file di configurazione di Kubernetes nella sezione Configurazione di Kubernetes sono modelli che possono essere utilizzati per configurare la distribuzione. Le altre sezioni di questa guida trattano i requisiti e i dettagli della distribuzione. L’implementazione di Tableau Server e della gestione componenti in background con scalabilità automatica deve essere semplice come l’implementazione dei file compilati della Configurazione di Kubernetes che si trovano in fondo a questa guida: kubectl apply -f ### Processi di gestione componenti in background I pod di gestione componenti in background assistono Tableau Server in un contenitore a calcolare carichi di lavoro pianificati aggiuntivi in parallelo. La gestione componenti in background gestisce i carichi di lavoro di aggiornamento delle estrazioni, sottoscrizione, avviso, flusso e sistema. La distribuzione dei processi tra i pod di gestione componenti in background significa che saranno disponibili maggiori risorse di calcolo per consentire a Tableau Server di gestire altre attività, ad esempio attività utente interattive come il rendering di cartelle di lavoro e dashboard. I processi di flusso sono l’unico tipo d processo di gestione componenti in background che non viene eseguito nella gestione componenti in background. Per informazioni dettagliate sui processi di gestione componenti in background, consulta [Gestire i processi in background in Tableau Server](https://help.tableau.com/v0.0/server-linux/it-it/server_backgrounder_job_management.htm). I pod di gestione componenti in background possono gestire qualunque tipo di carico, ad eccezione dei processi di flusso, che devono essere eseguiti nei contenitori Tableau Server principali, che continuano ad eseguire il servizio di gestione componenti in background. La funzionalità dei ruoli dei nodi offre agli utenti la possibilità di dedicare i pod di gestione componenti in background a tipi di processi specifici. Questa funzionalità è un’estensione della funzionalità dei ruoli dei nodi su Tableau server. La descrizione dettagliata dei diversi ruoli dei nodi è disponibile qui. Per impostazione predefinita, i processi di flusso sono disabilitati sui pod di gestione componenti in background (ovvero il ruolo è impostato su "no-flows") poiché i pod di gestione componenti in background non sono in grado di eseguire i processi di flusso. Per configurare i ruoli dei nodi per la gestione componenti in background, devi impostare la variabile di ambiente `NODE_ROLES` come parte di kubeconfig per il contenitore che esegue il servizio di gestione componenti in background. Ad esempio, per impostare la gestione componenti in background affinché esegua solo processi di aggiornamento delle estrazioni, configura la variabile di ambiente `NODE_ROLES` per gli aggiornamenti delle estrazioni come illustrato di seguito: #### 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 I pod di Tableau Server avranno almeno una gestione componenti in background configurata nella loro topologia, che è richiesta per garantire che ci sia sempre una posizione per l’esecuzione dei processi di gestione componenti in background. Per impostazione predefinita, TSM richiede che sia sempre presente una gestione componenti in background in grado di gestire qualunque ruolo di processo in background. In alcuni scenari, puoi fare in modo che i pod di gestione componenti in background gestiscano tutti i processi di un tipo particolare. A tale scopo, devi impostare la chiave di configurazione del server `topology.roles_handle_all_jobs_constraint_disabled` su `true`, per disabilitare il requisito che prevede che la topologia TSM gestisca tutti i tipi di processo. Con questo parametro impostato, il ruolo della gestione componenti in background per l’istanza di gestione componenti in background di Tableau Server potrebbe essere impostato su `no-extract-refreshes` e il ruolo per i pod di gestione componenti in background potrebbe essere impostato su `extract-refreshes`, che garantirebbe che tutti i processi di aggiornamento delle estrazioni siano eseguiti solo sui pod di gestione componenti in background. **Nota:** la disabilitazione di questo vincolo consente di configurare ruoli in base ai quali alcuni tipi di processi non vengono mai pianificati. La configurazione del ruolo della gestione componenti in background TSM e dei processi di gestione componenti in background deve essere impostato con attenzione perché TSM non verificherà più che tutti i tipi di processi di gestione componenti in background possano essere pianificati. ### Pod di Tableau Server in un contenitore I contenitori con Tableau Server come parte dei pod di gestione componenti in background con scalabilità automatica vengono distribuiti quasi nello stesso modo di Tableau Server in un contenitore esistente. Ci sono alcune modifiche ai requisiti: - È _necessaria_ una condivisione file di rete per trasferire la configurazione tra il contenitore di Tableau Server e i pod di gestione componenti in background. - Devi abilitare e utilizzare la funzionalità Archivio file esterno. Anche in questo caso è necessaria una condivisione file di rete. ### Pod di gestione componenti in background I pod di gestione componenti in background consistono di quattro contenitori di servizi indipendenti utilizzati congiuntamente: **gateway**, **hyper**, **dataserver** e **backgrounder**. Puoi distribuire questi pod come tipici pod di container Kubernetes indipendenti. I pod hanno i seguenti requisiti: - I pod di gestione componenti in background devono essere in grado di raggiungere il nodo di Tableau Server utilizzando la risoluzione DNS del nome host. - È necessario fornire condivisioni file di rete Archivio file esterno e Clone. **Nota:** i pod di gestione componenti in background sono configurati con un contenitore di inizializzazione per attendere fino a quando il contenitore di Tableau Server ha prodotto correttamente l’output di configurazione del clone prima di proseguire con l’esecuzione. #### Log I servizi dei pod di gestione componenti in background (come Tableau Server) scrivono ancora i log principalmente sul disco. Poiché i pod di gestione componenti in background possono essere ridimensionati o espansi, sono temporanei perciò è essenziale assicurarsi che i log siano memorizzati fuori dai pod. Molti clienti con ambienti K8s esistenti utilizzano già un servizio di aggregazione dei log di qualche tipo per raccogliere i log dai pod distribuiti. Esempi di servizi di aggregazione dei log sono Splunk e fluentd. È vivamente consigliabile che i clienti utilizzino qualche tipo di servizio di aggregazione dei log per raccogliere i log dai loro pod di gestione componenti in background. Per semplificare la gestione dei log, la kubeconfig che forniamo configura ciascun servizio nel pod per la scrittura in un volume di log condiviso. Il percorso della directory in ciascun contenitore di servizi è specificato dalla variabile di ambiente `ROOT_LOG_DIR`. Se devi aprire un caso di supporto e fornire i log, dovrai fornire due insiemi di log: ziplog raccolti dai contenitori principali di Server e i log dei pod di gestione componenti in background (recuperati dal servizio di aggregazione dei log o mediante il processo manuale indicato di seguito). I clienti che non sono in grado di utilizzare un servizio di aggregazione dei log, possono recuperarli manualmente dai pod. **Nota:**i log dei pod che non hanno utilizzato una Persistent Volume Claim per il volume che contiene i log andranno persi quando il pod viene ridimensionato. Tutti i pod pertinenti sono disponibili nella directory `/var/log/tableau` (configurabile tramite la variante di ambiente `ROOT_LOG_DIR`) all’interno del pod di gestione componenti in background. È consigliabile montare un PersistantVolumeClaim in questa posizione in modo che i log siano disponibili quando il pod viene eliminato. ##### Raccogliere i log quando il pod di gestione componenti in background è in esecuzione: Crea un file tar dei log all’interno del contenitore: kubectl exec -it -- bash -c "tar -czf /docker/user/backgrounder-pod-logs.tar.gz /var/log/tableau" Copia il file tar all’esterno del contenitore: kubectl cp :docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz ##### Raccogliere i log quando il pod di gestione componenti in background si è chiuso (o non si è avviato) Allega i pod di lunga durata con montaggio PersistantVolumeClaim utilizzato per i log di distribuzione dei pod di gestione componenti in background. Un esempio di configurazione: 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 Crea un file tar dei log all’interno del contenitore: kubectl exec -it -- bash -c "tar -czf /backgrounder-pod-logs.tar.gz /var/log/tableau" Copia il file tar all’esterno del contenitore: kubectl cp :/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz #### Modifiche live alla configurazione Se apporti modifiche a Tableau Server in un contenitore (ad esempio utilizzando la riga di comando tsm) e desideri che quelle modifiche alla configurazione siano rappresentate nei pod di gestione componenti in background, devi eseguire il comando `[tsm settings clone](https://help.tableau.com/v0.0/server-linux/it-it/cli_settings_tsm.htm#TSMSettingsClone)` per produrre un nuovo insieme di file di configurazione del clone ("payload del clone"). 1. Utilizza TSM per apportare modifiche al pod di Tableau Server in un contenitore e applica le modifiche di configurazione al server. 2. Esegui il comando indicato di seguito sul pod di Tableau Server in un contenitore: \## Run this command in the Tableau Server in a Container pod. tsm settings clone -d $CLONE\_ARTIFACT\_DIR Questo comando crea un nuovo insieme di file di configurazione e lo scrive nella posizione dell’unità NFS del clone. 3. Ridistribuisci i pod di gestione componenti in background. I pod devono essere configurati per l’utilizzo dell’unità NFS del clone e raccoglieranno la nuova configurazione. ### Strategie di scalabilità I pod di gestione componenti in background possono essere scalati in Kubernetes con numerose tecniche e strategie. Forniamo un esempio di strategia di scalabilità che modifica la dimensione del pool dei pod di gestione componenti in background in base a una pianificazione temporale. Tieni presente che l’utilizzo di CPU e memoria **non** sono buone metriche per la scalabilità dei pod di gestione componenti in background. L’utilizzo di memoria e CPU non illustrano in modo accurato il carico complessivo sul cluster. Ad esempio, l’utilizzo di un pod di gestione componenti in background potrebbe essere massimo durante l’aggiornamento di un’estrazione, ma potrebbero non esserci ulteriori processi in attesa nella coda dei processi della gestione componenti in background. In questo caso la scalabilità automatica non migliorerebbe la velocità effettiva dei processi. #### Scalabilità pianificata I meccanismi standard di Kubernetes che utilizzano i processi cron consentono di pianificare una soluzione di scalabilità. Un esempio di configurazione di Kubernetes di questo tipo è disponibile nella sezione Configurazione di Kubernetes riportata di seguito. ## Configurazione di Kubernetes ### Nuove variabili di ambiente Oltre alle variabili di ambiente standard del contenitore di Tableau Server (vedi [Opzioni di configurazione iniziali](https://help.tableau.com/v0.0/server-linux/it-it/server-in-container_image.htm#InitialConfigOptions-container)), vi sono alcune nuove variabili di ambiente necessarie da impostare nella Configurazione di Kubernetes.
Variabile di ambienteValore consigliatoDescrizione
FILESTORE_MOUNT_PATH/docker/dataenginePercorso di montaggio della directory dell’archivio file esterno. Questa directory deve puntare alla directory NFS dataengine montata all’interno di ciascun contenitore Tableau distribuito. Per maggiori informazioni sull’archivio file esterno, consulta Archivio file esterno di Tableau Server. Il valore dovrebbe essere lo stesso per l’istanza di Tableau Server in un pod Contenitore e nel pod Gestione componenti in background.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsPercorso di montaggio della directory di configurazione del clone. Questa directory deve puntare a un directory NFS montata all’interno di ciascun contenitore Tableau. Tableau Server emetterà dati di configurazione che i pod di gestione componenti in background utilizzano per diventare membri del cluster.
ROOT_LOG_DIR/var/log/tableau(Solo pod di gestione componenti in background)

Percorso della directory dei log comuni per tutti i servizi in esecuzione in un pod di gestione componenti in background.

### Porte dei pod di gestione componenti in background I pod di gestione componenti in background sono costituiti da quattro servizi, ciascuno dei quali è impostato per impostazione predefinita per l’esecuzione su una porta specifica. Se desideri modificare la porta a cui si collega il servizio all’interno del contenitore, devi fornire la chiave che corrisponde all’assegnazione della porta del servizio. Nella maggior parte dei casi questo tipo di configurazione non dovrebbe essere necessario, a meno che non sia presente un contenitore sidecar o qualche altro tipo di componente aggiunto al pod e che entra in conflitto con una delle porte dei servizi. | Variabile di ambiente per la porta | Impostazione predefinita | | --- | --- | | `BACKGROUNDER_PORT` | `8600` | | `DATASERVER_PORT` | `8400` | | `HYPER_PORT` | `8200` | | `GATEWAY_PORT` | `8080` | Dataserver inoltre utilizza la porta 8300, che non può essere riconfigurata. ### Directory di rete condivisa Questa distribuzione di Tableau Server richiede due condivisioni di rete per il corretto funzionamento. In tutti i modelli di configurazione Tableau Server e gestione componenti in background o Kubernetes sono presenti queste directory: - **Directory Dataengine** (`FILESTORE_MOUNT_PATH`): i pod di gestione componenti in background richiedono la funzionalità Archivio file esterno. Questa condivisione di rete contiene estrazioni e altri artefatti basati su file che vengono condivisi tra Tableau Server e i pod di gestione componenti in background. - **Directory Clone** (`CLONE_ARTIFACT_DIR`): Tableau Server scrive la connessione statica e le informazioni di configurazione su una condivisione di rete. I pod di gestione componenti in background utilizzano queste informazioni per diventare membri del cluster di Tableau Server. Nelle future versioni non definitive questa configurazione sarà incorporata nel ciclo di vita standard della configurazione di Kubernetes. **Importante:** se intendi ridistribuire l’intero cluster (incluso un nuovo contenitore di Tableau Server), devi eliminare i contenuti del montaggio NFS del clone (in caso contrario i pod di gestione componenti in background tenteranno di collegarsi al server precedente). ### Esempi di configurazione di Kubernetes **Nota:** gli esempi di configurazione includono l’uso di una sonda di preparazione. Puoi utilizzare la sonda di preparazione quando la distribuzione del contenitore di Tableau Server è una distribuzione TSM a nodo singolo (la distribuzione può includere più pod di gestione componenti in background). Non puoi utilizzare una sonda di preparazione nelle distribuzioni di Tableau Server in un contenitore a più nodi. #### Configurazione del contenitore di 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 #### Configurazione del pod di gestione componenti in background \--- 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: {} #### Configurazione della scalabilità pianificata 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 #### Processo di Kubernetes per pulire la configurazione del clone (facoltativo) Questo è un comodo processo di Kubernetes che è possibile utilizzare durante i test. Se desideri eliminare la configurazione del clone prodotta da Tableau Server in un contenitore tra distribuzioni distinte, puoi eseguire un processo simile a questo per pulire l’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