--- schema_version: "1" id: 9aeda19966d669a85eb7e1dfd286307dbfcc45405bfa284b7dad29bf65484fab title: Dimensionamento dinâmico em um contêiner - Processadores em segundo plano do Tableau Server collection: tableau version: next locale: pt-br portal_url: https://docs.salesforce.com/tableau/next/pt-br/server-linux/server-backgrounder-autoscaling.md canonical_url: https://help.tableau.com/v0.0/server-linux/pt-br/server-backgrounder-autoscaling.htm source_site: help.tableau.com content_type: documentation content_hash: d23f1a2d8048edb1581f7fbc11d9d1d4a029b197719a38b160b9a0f760d2b3ef description: Configure dynamic scaling of Backgrounders for Tableau Server in a container. --- [Pular para o conteúdo principal](#main-content) # Dimensionamento dinâmico em um contêiner - Processadores em segundo plano do Tableau Server ## Introdução O dimensionamento dinâmico do Processador em segundo plano em um contêiner permite que várias estratégias de dimensionamento sejam aplicadas ao processador em segundo plano e aos trabalhos agendados no Tableau Server. O dimensionamento automático nesse contexto significa que os serviços podem ser dimensionados independentemente para lidar com cargas de tarefas variáveis sem exigir intervenção humana ou afetar o tempo de atividade de outros sistemas de servidor. Os contêineres do Tableau Server que tiverem nós completos de processos do Tableau Server continuarão sendo executados como sistemas monolíticos. Em vez disso, um conjunto menor de serviços de contêiner independentes desacoplados que compõem a função de serviço "segundo plano" será dinamicamente escalonável e lidará com a carga computacional que normalmente seria tratada pelos contêineres do Tableau Server. Os serviços de segundo plano são responsáveis por processar tarefas do sistema que incluem atualização/criação de extrações, envio de assinaturas, verificação de alertas de dados e muitos trabalhos de manutenção. Se houver momentos, por exemplo, em que seria vantajoso atualizar um grande número de conjuntos de dados ou calcular uma série de alertas de dados computacionalmente caros, agora você pode aproveitar o Kubernetes para aumentar o poder de computação para concluir essas tarefas com eficiência. Este guia aborda os requisitos de configuração e implantação para Backgrounders de escalonamento automático no Kubernetes. Este documento é um suplemento da documentação do [Tableau Server em um contêiner](https://help.tableau.com/v0.0/server-linux/pt-br/server-in-container.htm). ## Pré-requisitos O escalonamento automático em segundo plano só está disponível no Kubernetes e é baseado no Tableau Server em contêineres. Para usar o recurso de segundo plano de escalonamento automático, você deve atender a certos pré-requisitos: - O Tableau Server deve ter recursos de Advanced Management. Para obter mais informações, consulte [Sobre o Tableau Advanced Management no Tableau Server](https://help.tableau.com/v0.0/server-linux/pt-br/itm_intro.htm). - Você deve estar usando o licenciamento baseado em função. As licenças principais não são suportadas. Para obter detalhes de licenciamento do usuário, consulte [Conhecer os modelos de licença e as chaves do produto](https://help.tableau.com/v0.0/server-linux/pt-br/license_product_keys.htm). - Os seguintes recursos de Advanced Management devem ser ativados: - [Armazenamento de arquivos externo do Tableau Server](https://help.tableau.com/v0.0/server-linux/pt-br/server_external_filestore_storage.htm) - [Repositório externo do Tableau Server](https://help.tableau.com/v0.0/server-linux/pt-br/server_external_repo.htm) - Você deve ter um cluster Kubernetes versão 1.20 ou posterior e entender como usá-lo e gerenciá-lo. ## Limitações - Esse recurso funciona apenas como parte de uma implantação baseada em Linux. - Os trabalhos de fluxo não são compatíveis com os fundos de escalonamento automático. Os trabalhos de fluxo serão tratados pelos serviços de segundo plano que continuam sendo executados no contêiner do Tableau Server. ## Criação de imagens de pods do Tableau Server e Processador em segundo plano A primeira etapa para usar processadores em segundo plano de escalonamento automático em contêineres é criar as imagens de serviço que compõem a instalação do Tableau Server. Essas imagens incluirão a imagem do Tableau Server, bem como imagens para o processador em segundo plano separado e os serviços de suporte. Você usa a mesma ferramenta de compilação usada para criar a imagem abrangente de contêiner do Tableau Server “tudo em um”, mas a ferramenta deve ser a versão 2022.3.0 ou posterior, você deve ter uma licença de Advanced Management e precisa usar uma licença especial sinalizar ao construir as imagens. 1. Para criar as imagens de serviço, execute este comando: build-image --accepteula -i --backgrounder-images Isso cria o Tableau Server e quatro novas imagens. Essas imagens adicionais contêm serviços individuais que compõem o novo pod de plano de fundo escalonável automaticamente. O comando `docker images` lista as imagens criadas no repositório local do docker: 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 As imagens hyper, gateway, backgrounder e dataserver compõem o novo pod do processador em segundo plano. Drivers personalizados, scripts de instalação e propriedades serão compartilhados em todas essas cinco imagens. Para obter mais informações, consulte [Personalização da imagem](https://help.tableau.com/v0.0/server-linux/pt-br/server-in-container_setup-tool.htm#CustomizingImage). 2. Publique todas essas imagens em seu repositório de imagens interno para implantação. ## Guia de Implantação As informações a seguir fornecem contexto sobre como implantar o Tableau Server em um contêiner e com processadores em segundo plano de escalonamento automático. Essas informações pressupõem que você já entende e sabe como implantar o Tableau Server em um contêiner de autocontêiner. Para obter mais informações, consulte [Tableau Server em um contêiner](https://help.tableau.com/v0.0/server-linux/pt-br/server-in-container.htm). Os três arquivos de configuração do Kubernetes na seção Configuração do Kubernetes são modelos que podem ser usados para configurar a implantação. As outras seções deste guia abrangem os requisitos e os detalhes da implantação. A implantação do Tableau Server e dos Processadores em segundo plano de escalonamento automático deve ser tão simples quanto implantar os arquivos de configuração do Kubernetes preenchidos na parte inferior do guia: kubectl apply -f ### Trabalhos do Processador em segundo plano Os pods do Processador em segundo plano ajudam o Tableau Server em um contêiner a computar cargas de trabalho agendadas adicionais em paralelo. O Processador em segundo plano lida com a atualização de extração, assinatura, alerta, fluxo e cargas de trabalho do sistema. Distribuir trabalhos entre os pods do processador em segundo plano significa que haverá mais recursos de computação disponíveis para o Tableau Server lidar com outras tarefas, como atividades interativas do usuário, como renderização de pastas de trabalho e painéis. Os trabalhos de fluxo são o único tipo de trabalho de segundo plano que não é executado no processador em segundo plano. Para obter detalhes sobre trabalhos de segundo plano, consulte [Gerenciar trabalhos do Processador em segundo plano no Tableau Server](https://help.tableau.com/v0.0/server-linux/pt-br/server_backgrounder_job_management.htm) . Os pods de segundo plano podem lidar com qualquer tipo de carga, exceto trabalhos de fluxo, que devem ser executados nos contêineres principais do Tableau Server, que continuam a executar o serviço do processador em segundo plano. O recurso Funções de nó oferece aos usuários a flexibilidade de dedicar pods de backgrounder para tipos específicos de trabalhos. Esse recurso é uma extensão do recurso Funções de nó no Tableau Server. A descrição detalhada sobre diferentes funções de nó pode ser encontrada aqui. Observe que, por padrão, os trabalhos de fluxo são desabilitados nos pods do processador em segundo plano (ou seja, a função é definida como "sem fluxos"), pois os pods do processador em segundo plano não conseguem executar trabalhos de fluxo. Para configurar funções de nó para o processador em segundo plano, você precisa definir a variável de ambiente `NODE_ROLES` como parte do kubeconfig para o contêiner que executa o serviço de processador em segundo plano. Por exemplo, para definir o processador em segundo plano para executar apenas trabalhos de extração e atualização, configure a variável de ambiente `NODE_ROLES` para extrair atualizações conforme mostrado abaixo: #### 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 Os pods do Tableau Server terão pelo menos um processador em segundo plano configurado em sua topologia, o que é necessário para garantir que sempre haja um local para executar trabalhos em segundo plano. Por padrão, o TSM exigirá que haja um processador em segundo plano capaz de lidar com todas as funções da tarefa em segundo plano. Em alguns cenários, você pode querer que os pods do processador em segundo plano lidem com todos os trabalhos de um tipo específico. Para fazer isso, você deve definir a chave de configuração do servidor `topology.roles_handle_all_jobs_constraint_disabled` para `true`, que desativará o requisito de que a topologia do TSM lide com todos os tipos de trabalho. Com esse parâmetro definido, a função de segundo plano para a instância de segundo plano do Tableau Server pode ser definida como `no-extract-refreshes` e a função dos pods do processador em segundo plano pode ser definida como`extract-refreshes`, o que garantiria que todos os trabalhos de atualização de extração sejam executados apenas nos pods do processador em segundo plano. **Observação:** desabilitar essa restrição permite configurar funções de forma que alguns tipos de trabalho nunca sejam agendados. A configuração da função de segundo plano e tarefas de segundo plano do TSM deve ser definida com cuidado porque o TSM não verificará mais se todos os tipos de trabalho de segundo plano podem ser planejados. ### Pods do Tableau Server em um Contêiner Os contêineres com o Tableau Server como parte dos pods do processador em segundo plano de escalonamento automático são implantados quase da mesma maneira que nosso Tableau Server existente em um contêiner. Existem algumas mudanças importantes nos requisitos: - Um compartilhamento de arquivos de rede é _necessário_ para transferir a configuração entre o contêiner do Tableau Server e os pods do processador em segundo plano. - Você deve habilitar e usar o recurso Armazenamento de arquivos externo. Isso também requer um compartilhamento de arquivos de rede dedicado. ### Pods de processador em segundo plano Os pods do processador em segundo plano consistem em quatro contêineres de serviço independentes trabalhando juntos: **gateway**, **hyper**, **dataserver** e **backgrounder**. Você pode implantar esses pods como pods de contêiner independentes típicos do Kubernetes. Os pods têm os seguintes requisitos: - Os pods do processador em segundo plano devem ser capazes de alcançar o nó do Tableau Server usando a resolução DNS do nome do host. - Os compartilhamentos de arquivos de rede de armazenamento de arquivos e clones externos devem ser fornecidos. **Observação:** os pods do processador em segundo plano são configurados com um contêiner de inicialização para aguardar até que o contêiner do Tableau Server tenha produzido com êxito a saída de configuração de clone antes de continuar a execução. #### Registros: Os serviços de pod do processador em segundo plano (como o Tableau Server) ainda gravam registros predominantemente no disco. Como os pods do processador em segundo plano podem ser ampliados e reduzidos, eles são efêmeros, portanto, é essencial garantir que os registros sejam armazenados fora dos pods. Muitos clientes com ambientes K8s existentes já usarão um serviço de agregação de registro de algum tipo para coletar os registros dos pods que eles implantam. Exemplos de serviços de agregação de log são Splunk e fluentd. É altamente recomendável que os clientes usem algum tipo de serviço de agregação de registros para coletar os registros de seus pods de backgrounder. Para facilitar o gerenciamento de registros, o kubeconfig que fornecemos configura cada serviço no pod para gravar em um volume de registros compartilhado. O caminho do diretório em cada contêiner de serviço é especificado pela variável de ambiente `ROOT_LOG_DIR`. Se precisar abrir um caso de suporte e fornecer registros, você fornecerá dois conjuntos de registros: ziplogs coletados dos principais contêineres do servidor e registros dos pods do processador em segundo plano (recuperados de seu serviço de agregação de registros ou usando o processo manual abaixo) . Para clientes que não podem usar um serviço de agregação de registros, os registros podem ser recuperados manualmente dos pods. **Observação:** os registros de qualquer pod, que não usou uma reivindicação de volume persistente para o volume que contém os registros, serão perdidos quando o pod tiver o dimensionamento reduzido! Todos os registros relevantes estão disponíveis no diretório `/var/log/tableau` (configurável através da variável de ambiente `ROOT_LOG_DIR`) dentro do pod do processador em segundo plano. É altamente recomendável que você monte um PersistantVolumeClaim nesse local para que os registros fiquem disponíveis quando o pod morrer. ##### Coletando registros quando o pod do processador em segundo plano está em execução: Crie um arquivo tar dos registros dentro do container: kubectl exec -it -- bash -c "tar -czf /docker/user/backgrounder-pod-logs.tar.gz /var/log/tableau" Copie o tarfile para fora do container: kubectl cp :docker/user/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz ##### Coletando registros quando o pod do processador em segundo plano saiu (ou não foi iniciado) Anexe qualquer pod de longa duração com a montagem PersistantVolumeClaim que é usada para registros de implantação de pod do processador em segundo plano. Um exemplo de configuração: 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 Crie um arquivo tar dos registros dentro do container: kubectl exec -it -- bash -c "tar -czf /backgrounder-pod-logs.tar.gz /var/log/tableau" Copie o tarfile para fora do container: kubectl cp :/backgrounder-pod-logs.tar.gz ./backgrounder-pod-logs.tar.gz #### Alterações de configuração dinâmicas Se você fizer alterações de configuração no Tableau Server em um contêiner (por exemplo, usando a linha de comando tsm) e quiser que essas alterações de configuração sejam representadas em pods do processador em segundo plano, será necessário executar o comando `[tsm settings clone](https://help.tableau.com/v0.0/server-linux/pt-br/cli_settings_tsm.htm#TSMSettingsClone)` para produzir um novo conjunto de arquivos de configuração clone ("carga útil do clone"). 1. Use o TSM para fazer alterações de configuração no Tableau Server em um pod de contêiner e aplique as alterações de configuração ao servidor. 2. Execute os seguintes comandos no Tableau Server em um pod de Contêiner. \## Run this command in the Tableau Server in a Container pod. tsm settings clone -d $CLONE\_ARTIFACT\_DIR Este comando cria um novo conjunto de arquivos de configuração e o grava no local da unidade Clone NFS. 3. Reimplemente seus pods do processador em segundo plano. Os pods devem ser configurados para usar a unidade Clone NFS e selecionarão a nova configuração. ### Estratégias de dimensionamento Os pods do processador em segundo plano podem ser dimensionados no Kubernetes usando uma variedade de técnicas e estratégias. Fornecemos um exemplo de estratégia de dimensionamento que altera o tamanho do pool de pods do processador em segundo plano com base em um cronograma. Observe que a utilização de CPU e memória **não** são boas métricas para dimensionar pods do processador em segundo plano. A utilização de memória e CPU não retrata com precisão a demanda de carga geral no cluster. Por exemplo, um pod do processador em segundo plano pode estar na utilização máxima para atualizar uma extração, mas não há trabalhos adicionais aguardando na fila de trabalhos do processador em segundo plano. Nesse caso, o escalonamento automático não melhoraria o rendimento do trabalho. #### Escalonamento agendado Os mecanismos padrão do Kubernetes que usam trabalhos cron permitem agendar uma solução de dimensionamento. Um exemplo de configuração do Kubernetes para isso é fornecido na seção Configuração do Kubernetes abaixo. ## Configuração de kubernetes ### Variáveis de ambiente novas Além das variáveis de ambiente de contêiner padrão do Tableau Server (consulte [Opções de configuração inicial](https://help.tableau.com/v0.0/server-linux/pt-br/server-in-container_image.htm#InitialConfigOptions-container)), há algumas novas variáveis de ambiente necessárias que devem ser definidas na configuração do Kubernetes.
Variáveis de ambienteValor recomendadoDescrição
FILESTORE_MOUNT_PATH/docker/dataengineLocal de montagem do diretório do Armazenamento de arquivos externo. Esse diretório deve apontar para o diretório NFS do dataengine montado dentro de cada contêiner do Tableau implantado. Para obter mais informações sobre o Armazenamento de arquivos externo, consulte Armazenamento de arquivos externo do Tableau Server. O valor deve ser o mesmo para o Tableau Server em um pod de Contêiner e o pod de Processador em segundo plano.
CLONE_ARTIFACT_DIR/docker/clone/clone-artifactsLocalização de montagem do diretório de configuração do clone. Esse diretório deve apontar para um diretório NFS montado dentro de cada contêiner do Tableau. O Tableau Server gerará dados de configuração que os pods do processador em segundo plano consomem para se tornarem membros do cluster.
ROOT_LOG_DIR/var/log/tableau(Somente pods do processador em segundo plano)

Local do diretório de registro comum para todos os serviços executados em um pod do processador em segundo plano.

### Porta do pod do processador em segundo plano Os pods do processador em segundo plano consistem em quatro serviços, cada um, por padrão, configurado para ser executado em uma porta especificada. Se você deseja alterar a porta à qual o serviço se conecta dentro do contêiner, é necessário fornecer a chave que corresponde à atribuição de porta do serviço. Esse tipo de configuração não deve ser necessário na maioria dos casos, a menos que haja um contêiner sidecar ou algum outro componente adicional que esteja sendo adicionado ao pod e entre em conflito com a porta de um serviço. | Variável de ambiente da porta | Padrão | | --- | --- | | `BACKGROUNDER_PORT` | `8600` | | `DATASERVER_PORT` | `8400` | | `HYPER_PORT` | `8200` | | `GATEWAY_PORT` | `8080` | O Dataserver também usa a porta 8300, que não pode ser reconfigurada. ### Diretório de rede compartilhada Essa implantação do Tableau Server requer dois compartilhamentos de rede para funcionar corretamente. Observe que em todos os modelos de configuração do Tableau Server e Processador em segundo plano do Kubernetes esses diretórios de rede estão presentes: - **Diretório de mecanismo de dados** (`FILESTORE_MOUNT_PATH` ): Os pods do processador em segundo plano requerem o recurso Armazenamento de arquivos externo. Esse compartilhamento de rede contém extrações e outros artefatos baseados em arquivo que serão compartilhados entre o Tableau Server e os pods do processador em segundo plano. - **Clonar diretório** (`CLONE_ARTIFACT_DIR` ): o Tableau Server grava informações estáticas de conexão e configuração em um compartilhamento de rede. Os pods do processador em segundo plano consumirão essas informações para se tornarem membros do cluster do Tableau Server. Em futuros pré-lançamentos, essa configuração será inserida ao ciclo de vida padrão da configuração do Kubernetes. **Importante:** se você quiser reimplantar o cluster inteiramente (incluindo um novo contêiner do Tableau Server), deverá limpar o conteúdo da montagem NFS do clone (caso contrário, os pods do processador em segundo plano tentarão se conectar ao servidor antigo). ### Exemplos de configuração do Kubernetes **Observação:** os exemplos de configuração incluem o uso de uma sondagem de prontidão. Você pode usar a investigação de prontidão quando a implantação do Tableau Server Container for uma implantação TSM de nó único (a implantação pode incluir vários pods de segundo plano). Você não pode usar uma investigação de prontidão com implantações de vários nós do Tableau Server em um contêiner. #### Configuração de contêiner do 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 #### Configuração do pod do processador em segundo plano \--- 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: {} #### Configuração de escalonamento agendado 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 #### Trabalho do Kubernetes para limpar a configuração do clone (opcional) Este é um trabalho de conveniência do Kubernetes que você pode usar durante o teste. Se quiser limpar a configuração de clone produzida pelo Tableau Server em um contêiner entre execuções de implantação distintas, você pode executar um trabalho como este para limpar o 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