> For the complete documentation index, see [llms.txt](https://academy.pentaho.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-pt-br/instalacao/conteineres/k3s.md). # K3s {% hint style="info" %} #### K3s K3s é uma distribuição Kubernetes certificada e leve, projetada para ambientes com recursos limitados, computação de borda, dispositivos IoT e cenários de desenvolvimento. Criada pela Rancher Labs (agora parte da SUSE), empacota tudo que é necessário para executar Kubernetes em um único binário abaixo de 100MB. Isso torna o K3s significativamente mais leve que o Kubernetes padrão, mantendo compatibilidade total com as APIs e recursos do Kubernetes. Requer memória mínima (512MB mínimo) e oferece operações simplificadas com dependências reduzidas. K3s vem com componentes integrados como o controlador de ingresso Traefik, o provisionador de armazenamento local e o balanceador de carga de serviço. É perfeito para desenvolvimento, CI/CD, implantações de borda e dispositivos ARM, mas permanece pronto para produção com recursos de alta disponibilidade. {% endhint %}

Arquitetura K3s & Pentaho Server

{% tabs %} {% tab title="Componentes principais do K3s" %} {% hint style="info" %} #### Componentes principais do K3s **Componentes do plano de controle** O plano de controle inclui o API Server (ponto de extremidade da API do Kubernetes para gerenciamento do cluster), Controller Manager (gerencia os loops de controle principais para replicação, endpoints e namespaces) e Scheduler (atribui pods aos nós com base na disponibilidade de recursos). O K3s pode usar etcd ou o leve SQLite como datastore para o estado do cluster, tornando-o mais flexível que o Kubernetes padrão. **Componentes de nó** Cada nó executa o agente Kubelet que gerencia o ciclo de vida dos pods. O Containerd está incorporado como runtime de contêiner para executar containers. O Kube-proxy gerencia o proxy de rede e a conectividade de serviços em todo o cluster. **Add-ons embutidos** O K3s inclui o Traefik Ingress Controller para rotear tráfego HTTP/HTTPS externo para os serviços. O Local Path Provisioner possibilita provisionamento dinâmico de volumes persistentes usando armazenamento local. CoreDNS fornece DNS de cluster para descoberta de serviços. O Service Load Balancer gerencia serviços do tipo LoadBalancer sem exigir integrações com provedores de nuvem externos. **Rede** O Flannel atua como o plugin CNI (Container Network Interface) padrão para a rede de pods. Network Policies controlam o fluxo de tráfego entre pods e serviços para maior segurança. {% endhint %}

Componentes do K3s

{% endtab %} {% tab title="Pod do Pentaho Server" %} {% hint style="info" %} #### Pod do Pentaho Server * Executa o servidor de aplicações Tomcat com Pentaho Server 11 * Construído sobre Debian Trixie Slim com OpenJDK 21 JRE * Build Docker multi-stage para otimização do tamanho da imagem * Exposto internamente na porta 8080 * Inclui probes de readiness e liveness para monitoramento de integridade * Limites de recursos configurados para estabilidade de CPU e memória {% endhint %}

Pod Pentaho

{% endtab %} {% tab title="Pod PostgreSQL" %} {% hint style="info" %} Fornece backend de banco de dados relacional para três bancos de dados críticos: * **Jackrabbit** (jcr\_user): Repositório de Conteúdo Java que armazena todo o conteúdo do Pentaho (relatórios, dashboards, fontes de dados, transformações, jobs) * **Quartz** (pentaho\_user): Agendador que gerencia jobs, triggers, calendários e histórico de execução * **Hibernate** (hibuser): Configuração de segurança, logs de auditoria, sessões de usuários, além de dois schemas especializados: * **pentaho\_dilogs**: Registro de execução de ETL com logs de jobs, métricas de transformações e dados de desempenho de passos * **pentaho\_operations\_mart**: Data mart dimensional para análises da plataforma com tabelas de dimensão e fatos * Dados persistidos através de PersistentVolumeClaim para sobreviver a reinicializações * Inicialização automatizada via scripts SQL montados por ConfigMap {% endhint %}

Pod PostgreSQL

Arquitetura do banco de dados PostgreSQL

O Pentaho Server requer três bancos de dados separados, cada um servindo a um propósito distinto:
Banco de dadosProprietárioPropósito & Conteúdo
jackrabbitjcr_userJava Content Repository (JCR) - Armazena todo o conteúdo do Pentaho incluindo relatórios, dashboards, fontes de dados, schemas de análise e arquivos de usuários. Este é o armazenamento principal de conteúdo do repositório Pentaho.
quartzpentaho_userQuartz Scheduler - Gerencia todos os jobs agendados, triggers e calendários. Contém tabelas para definições de jobs (QRTZ6_JOB_DETAILS), triggers (QRTZ6_TRIGGERS), histórico de execução e locks de coordenação de cluster.
hibernatehibuserHibernate Repository - Hospeda configuração de segurança, logs de auditoria, dados de sessão de usuários, e contém dois schemas adicionais: pentaho_dilogs (registro de execução de ETL) e pentaho_operations_mart (data mart analítico).
{% hint style="info" %} O banco de dados hibernate contém schemas especializados para monitoramento operacional: **pentaho\_dilogs**: Captura informações detalhadas de execução de ETL incluindo logs de jobs, logs de transformações, métricas de desempenho de passos e registros de erros. Essencial para depuração de fluxos de integração de dados e monitoramento da saúde do pipeline. **pentaho\_operations\_mart**: Um data mart dimensional para análises do uso do Pentaho. Contém tabelas de dimensão (DIM\_DATE, DIM\_TIME, DIM\_EXECUTOR) e tabelas de fatos (FACT\_EXECUTION, FACT\_STEP\_EXECUTION) para analisar utilização da plataforma, tendências de desempenho e atividade de usuários. Para implantações em produção, implemente backups regulares do volume Docker repository-data. O banco de dados jackrabbit é o mais crítico pois contém todo o conteúdo dos usuários. Considere usar pg\_dump para backups lógicos ou snapshots de volume para opções de recuperação completas. {% endhint %} {% endtab %} {% tab title="Rede" %} {% hint style="info" %} #### Rede **Comunicação interna:** * Ambos os pods rodam dentro do `pentaho` namespace * Serviços ClusterIP fornecem nomes DNS internos estáveis * PostgreSQL acessível em `postgresql.pentaho.svc.cluster.local:5432` * Pentaho Server acessível em `pentaho-server.pentaho.svc.cluster.local:8080` **Acesso externo:** * O Traefik Ingress Controller roteia o tráfego externo para o Pentaho Server * Roteamento configurável por hostname e baseado em caminhos * Suporte opcional para terminação TLS/SSL {% endhint %} O Tomcat gerencia pools de conexão definidos em context.xml. Cada pool atende a um propósito específico:
Nome do PoolAlvo da ConexãoUsado Para
jdbc/Hibernaterepository:5432/hibernateSegurança, Usuários, Papéis
jdbc/Quartzrepository:5432/quartzAgendamento de Jobs
jdbc/jackrabbitrepository:5432/jackrabbitRepositório de Conteúdo
jdbc/Auditrepository:5432/hibernateLogs de Auditoria
jdbc/live_logging_inforepository:5432/hibernateLogs de Execução de ETL
jdbc/PDI_Operations_Martrepository:5432/hibernateAnalytics de Operações
{% endtab %} {% tab title="ConfigMaps de armazenamento" %} {% hint style="info" %} #### Armazenamento **PersistentVolumeClaims (PVCs):** * `postgres-pvc`: Diretório de dados do PostgreSQL (`/var/lib/postgresql/data`) * `pentaho-pvc`: Diretórios de soluções e dados do Pentaho **Classe de armazenamento:** * Usa o `local-path` provisionador de armazenamento * Providencia volumes no sistema de arquivos local do nó * Criação e binding automático de volumes **ConfigMaps:** * Scripts de inicialização do banco de dados (5 arquivos SQL) * Configurações do Pentaho (parâmetros JVM, configurações do Tomcat) **Secrets:** * Credenciais do PostgreSQL (postgres\_password, pentaho\_user, pentaho\_password) * Strings de conexão JDBC * Codificadas em Base64 por segurança {% endhint %} {% endtab %} {% endtabs %} {% hint style="danger" %} Antes de iniciar a implantação no K3s, certifique-se de ter concluído a Preparação: [Contêineres Pentaho](/pentaho-11-installation-en/pentaho-11-installation-pt-br/configuracao/conteineres-do-pentaho.md) {% endhint %} Execute os passos a seguir para implantar o Pentaho Server em um K3s single-node com repositório PostgreSQL 15. {% tabs %} {% tab title="1. Preparar o Ambiente " %} {% hint style="info" %} #### Preparar o Ambiente A seção "Preparar o Ambiente" descreve os passos iniciais necessários antes de implantar o Pentaho Server 11 no K3s: * copiar os ativos de implantação para seu diretório home, * preparar o arquivo ZIP do Pentaho Server Enterprise Edition, verificando que o arquivo está no lugar, * confirmar que o K3s está corretamente instalado e em execução {% endhint %} {% hint style="danger" %} Certifique-se de ter baixado: `pentaho-server-ee-11.0.0.0-237.zip` {% endhint %} 1. Crie o diretório & copie os ativos. ```bash cd cd ~/Workshop--Installation/Pentaho-Containers/K3s/Pentaho-K3s-PostgreSQL/scripts chmod +x ./install-to-home.sh ``` 2. Copie o pentaho-server-ee-11.0.0.0-237.zip para o diretório /docker/stagedArtefacts. {% hint style="info" %} Se você implantou um Pentaho Server em Archive então copie de: `/opt/pentaho/software/pentaho-server-ee-version` Caso contrário, baixe o pacote do [Portal do Cliente Pentaho](https://support.pentaho.com/hc/en-us). {% endhint %} ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts cp /opt/pentaho/software/server/pentaho-server-ee-11.0.0.0-237.zip . ``` 3. Verifique que o arquivo. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts ls -al ``` 4. Verifique a instalação do K3s. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./verify-k3s.sh ``` ```sh # Verificação normal (o que você executaria na maior parte do tempo) ./scripts/verify-k3s.sh # Saída detalhada para depuração ./scripts/verify-k3s.sh --verbose # Modo silencioso para scripts/automação ./scripts/verify-k3s.sh --quiet # Obter ajuda ./scripts/verify-k3s.sh --help ```

verify-k3s.sh

5. O Pentaho Server requer uma licença válida. O `.env` arquivo contém um LICENSE\_URL apontando para o servidor de licenças Flexera. Certifique-se de que seus direitos de licença estejam ativos antes da implantação. {% hint style="warning" %} Sem uma licença válida, o Pentaho Server iniciará, mas muitos recursos serão desativados. Verifique o status da sua licença antes de prosseguir com implantações em produção. {% endhint %} **Diferenças-chave**
AspectoImplantação DockerImplantação K3s
OrquestraçãoDocker ComposeKubernetes (K3s)
Configuração.env arquivo + docker-compose.ymlManifests do Kubernetes (YAML)
SecretsSegredos Docker ou VaultKubernetes Secrets
RedeRede bridge do DockerRede do cluster K3s + Traefik Ingress
ArmazenamentoVolumes DockerPersistentVolumeClaims (PVCs)
EscalonamentoManual (docker compose up --scale)Declarativo (replicas no deployment)
Verificações de integridadeDocker HEALTHCHECKProbes de readiness/liveness do Kubernetes
Scripts de inicializaçãoMontagem de volume para /docker-entrypoint-initdb.dConfigMap montado no pod PostgreSQL
{% endtab %} {% tab title="2. Tarefas pré-voo" %} {% hint style="info" %} #### Tarefas Pré-voo A seção Tarefas Pré-voo descreve os passos essenciais de preparação necessários antes de implantar o Pentaho Server 11 em contêineres K3s. **Configurar variáveis de ambiente** Edite o `.env.example` arquivo dentro do `docker-build/` diretório com suas configurações específicas de implantação. Isso inclui identificador da versão do Pentaho e nome/tag da imagem Docker. Configure as credenciais do banco de dados PostgreSQL e os parâmetros de conexão. Defina a alocação de memória da JVM com heap mínimo (padrão 4GB) e heap máximo (padrão 8GB). Adicione a URL do servidor de licenças da Enterprise Edition se aplicável. Configure opções de build incluindo edição da imagem (EE/CE), detecção de plugins e configurações de push para registro. Uma vez configurado, copie este template para `.env` para uso pelo processo de build. **Diretório softwareOverride** O `softwareOverride/` diretório dentro de `docker-build/` fornece um mecanismo para customizar as configurações do Pentaho. Essas customizações são incorporadas na imagem Docker durante o processo de build. Os arquivos são organizados em diretórios numerados e processados em ordem alfabética. O **1\_drivers/** o diretório contém o driver JDBC do PostgreSQL (incluído por padrão), e você pode colocar drivers JDBC adicionais aqui. O **2\_repository/** o diretório contém configurações de conexão de banco de dados para os repositórios Jackrabbit (JCR), Quartz (scheduler) e Hibernate. O **3\_security/** diretório está vazio nesta implantação K3s já que não há integração com Vault. O **4\_others/** o diretório contém scripts Tomcat modificados (startup.sh, setenv.sh), server.xml e outras configurações a nível de aplicação. Você pode opcionalmente atualizar o driver JDBC do PostgreSQL baixando do Maven Central ou copiando da coleção de drivers de banco de dados do workshop. Coloque o driver atualizado em `softwareOverride/1_drivers/tomcat/lib/`. {% endhint %} *** **Configurar .env** 1. Edite o .env.template ```bash cd cd ~/Pentaho-Server-PostgreSQL nano .env.template ``` 2. Insira os seguintes detalhes:
VariávelPadrãoDescrição
PENTAHO_VERSION11.0.0.0-237Versão do Pentaho Server
EDITIONeeVersão Enterprise
INCLUDE_DEMO1Incluir dados de demonstração
IMAGE_TAGpentaho/pentaho-server:11.0.0.0-237Tag da imagem Docker
PENTAHO_MIN_MEMORY4096mTamanho mínimo do heap da JVM
PENTAHO_MAX_MEMORY8192mTamanho máximo do heap da JVM
PENTAHO_DI_JAVA_OPTIONS"-Dfile.encoding=utf8 -Djava.awt.headless=true"
PENTAHO_IMAGE_NAMEpentaho/pentaho-serverNome da imagem Docker
TZAmerica/NYFuso horário do servidor
DB_TYPEpostgres
DB_HOSTpostgres
DB_PORT5432Porta HTTP do PostgreSQL
PUSH_TO REGISTRYfalseEnvia diretamente ao Registro do K3s
LOAD_INTO_K3StrueCarrega diretamente no K3s
RUN TESTStrue
LICENSE_URL(vazio)URL do servidor de licenças EE
3. Salvar: ``` CTRL + o Enter CTRL + x ``` 4. Criar .env ```bash cd cd ~/Pentaho-Server-PostgreSQL cp .env.template .env ``` *** **softwareOverride** {% hint style="info" %} O `softwareOverride/` o diretório fornece um mecanismo poderoso para customizar o Pentaho Server sem modificar a instalação principal. Arquivos são copiados para a instalação do Pentaho durante a inicialização do contêiner, processados em ordem alfabética por nome de diretório. {% endhint %} ```` ``` softwareOverride/ ├── 1_drivers/ # drivers JDBC e conectores de dados │ ├── tomcat/lib/ │ │ └── postgresql-42.x.x.jar # driver JDBC do PostgreSQL (incluído) │ └── pentaho-solutions/drivers/ # drivers de big data (.kar files) ├── 2_repository/ # configuração do repositório de banco de dados │ ├── pentaho-solutions/system/ │ │ ├── hibernate/hibernate-settings.xml │ │ ├── jackrabbit/repository.xml │ │ └── scheduler-plugin/quartz/quartz.properties │ └── tomcat/webapps/pentaho/META-INF/context.xml ├── 3_security/ # autenticação e autorização │ └── pentaho-solutions/system/ │ ├── applicationContext-spring-security-hibernate.properties │ └── applicationContext-spring-security-memory.xml ├── 4_others/ # Tomcat, padrões e diversos │ ├── pentaho-solutions/system/ │ │ ├── defaultUser.spring.properties │ │ ├── pentaho.xml │ │ └── security.properties │ └── tomcat/ │ ├── bin/startup.sh │ └── webapps/pentaho/WEB-INF/web.xml └── 99_exchange/ # Troca de dados do usuário (não processado automaticamente) ``` ```` O driver JDBC do PostgreSQL está incluído na distribuição Pentaho. Se você precisar atualizar: 1. Baixe de [Maven Central](https://repo1.maven.org/maven2/org/postgresql/postgresql/) 2. Coloque em `softwareOverride/1_drivers/tomcat/lib/` Ou Copie de Workshop--Installation/'Database Drivers'/ ```bash cd cd ~/Workshop--Installation/'Database Drivers' cp postgresql-42.7.8.jar ~/Pentaho-Server-PostgreSQL/softwareOverride/1_drivers/tomcat/lib ``` {% endtab %} {% tab title="3. Build & Push da Imagem" %} {% hint style="info" %} #### Build & Push da Imagem Pentaho O script build.sh é um wrapper de build automatizado que: * Valida pré-requisitos - Verifica se o Docker está instalado * Verifica arquivos necessários - Verifica se o ZIP do Pentaho existe em stagedArtifacts/ * Detecta plugins automaticamente - Encontra plugins PAZ, PIR, PDD * Confirma o build - Mostra o que será construído e pede confirmação * Executa docker build - Executa o build com os argumentos adequados * Mostra informação da imagem - Exibe tamanho da imagem e detalhes após o build * Opcional: Testa a imagem - Executa um teste básico de contêiner (você pode pular isto) * Opcional: Envia ao registro - Faz push para um registro Docker (apenas com a flag -p) Esta é a **abordagem recomendada** para construir imagens Docker do Pentaho. Usa um único `.env` arquivo para configurar tudo - similar à implantação com Docker Compose. {% endhint %} Você pode modificar o build com as seguintes opções:
Opção (curta)Opção (Longa)Descrição
-v--version VERSIONVersão do Pentaho (padrão: 11.0.0.0-237)
-t--tag TAGTag da imagem Docker (padrão: pentaho/pentaho-server:VERSION)
-e--edition EDITIONee ou ce (padrão: ee)
-d--demoIncluir conteúdo demo (padrão: não)
-p--pushEnviar ao registro após o build
-h--helpEnviar ao registro após o build
1. Build & Push da imagem do Pentaho Server diretamente no Registro do K3s. ```bash # Build com padrões baseados no .env cd cd ~/Pentaho-K3s-PostgreSQL/docker-build ./build.sh ```

Build & Push da imagem do Pentaho Server

{% hint style="info" %} **1. Build da imagem Docker:** A implantação usa uma imagem de contêiner do Pentaho Server construída customizada: ``` docker-build/ ├── Dockerfile (build multi-stage) ├── build.sh (script de build automatizado) ├── stagedArtifacts/ (ZIP do Pentaho Server) └── softwareOverride/ (overlays de configuração) ├── 1_drivers/ (driver JDBC do PostgreSQL) ├── 2_repository/ (configs de banco de dados) ├── 3_security/ (autenticação) └── 4_others/ (customizações do Tomcat) ``` O `build.sh` script: * Valida pré-requisitos e arquivos necessários * Detecta plugins automaticamente (PAZ, PIR, PDD) * Executa build Docker multi-stage * Opcionalmente envia para o repositório de imagens do K3s **2. Gestão de Configuração:** * `.env` o arquivo contém configurações específicas da implantação (versões, credenciais, memória JVM) * `softwareOverride/` o diretório fornece overlays de configuração processados em ordem numerada * Driver JDBC do PostgreSQL incluído por padrão, com opção de atualização * Scripts Tomcat customizados para otimização de inicialização do contêiner {% endhint %} {% endtab %} {% tab title="4. Helm Charts" %} {% hint style="info" %} #### Helm Charts Helm é o gerenciador de pacotes para Kubernetes, frequentemente referido como "apt/yum para Kubernetes." Ele simplifica a implantação e o gerenciamento de aplicações Kubernetes através de: **Empacotamento**: Agrupar recursos relacionados do Kubernetes **Templateamento**: Parametrizar manifests para reutilização em diferentes ambientes **Versionamento**: Gerenciar versões de aplicações e upgrades **Gerenciamento de Releases**: Rastrear implantações e possibilitar rollbacks {% endhint %}

Helm Charts

{% tabs %} {% tab title="1. Diretórios" %} {% hint style="info" %} #### Layout de diretório Abaixo está uma explicação do diretório pentaho responsável por uma implantação via Helm. {% endhint %} ``` pentaho/ # Diretório raiz do chart ├── Chart.yaml # Metadados do chart (nome, versão, descrição) ├── values.yaml # Valores padrão de configuração ├── templates/ # Templates dos manifests do Kubernetes │ ├── _helpers.tpl # Funções helper do template (não renderizadas) │ ├── NOTES.txt # Instruções pós-instalação │ ├── namespace.yaml # Criação do namespace │ ├── secret.yaml # Dados sensíveis (senhas, chaves) │ ├── configmap-*.yaml # Dados de configuração │ ├── pvc.yaml # Persistent volume claims │ ├── *-deployment.yaml # Deployments de pods │ ├── *-service.yaml # Definições de serviços │ └── ingress.yaml # Regras de roteamento de Ingress └── files/ # Arquivos não-template (scripts SQL, configs) └── db_init/ # Scripts de inicialização do PostgreSQL ``` **Chart.yaml** {% hint style="info" %} Este arquivo define a identidade do chart, versão e metadados usados pelo Helm. Serve como a "definição de pacote" para o chart Helm, similar ao package.json (npm) ou Chart.lock (dependências do Helm). Papel: O Chart.yaml informa ao Helm o que é este chart, qual a sua versão, qual aplicação ele implanta e fornece metadados pesquisáveis para repositórios de charts. O Helm usa este arquivo para rastrear versões do chart, gerenciar dependências e exibir informações quando usuários buscam ou instalam charts. {% endhint %} **values.yaml** {% hint style="info" %} Em uma implantação K3s (Kubernetes leve), o `values.yaml` arquivo serve como o arquivo central de configuração para charts Helm. Ele define parâmetros e configurações padrão que customizam como uma aplicação ou serviço é implantado no cluster - coisas como contagens de réplicas, versões de imagens, limites de recursos, tipos de serviço, regras de ingress, variáveis de ambiente e configurações de armazenamento persistente. Quando você executa `helm install` ou `helm upgrade`, o Helm mescla os valores deste arquivo com os templates do chart para gerar os manifests finais do Kubernetes. Você pode sobrescrever valores específicos no momento do deploy usando `--set` flags ou fornecendo um arquivo de valores personalizado com `-f`, tornando-o um mecanismo flexível para gerenciar configurações específicas de ambiente (por exemplo, dev vs. produção) sem modificar os templates subjacentes do chart. {% endhint %} *** **templates**
YAMLDescrição
namespace.yamlCria um namespace Kubernetes isolado para conter todos os recursos do Pentaho
secret.yamlArmazena credenciais sensíveis do banco de dados (senhas) criptografadas no Kubernetes
config-*.yamlConfigura variáveis de ambiente do Pentaho (memória JVM, configurações do banco de dados, caminhos, fuso horário) Contém scripts SQL para inicializar bancos de dados PostgreSQL (jackrabbit, quartz, hibernate) na primeira inicialização
pvc.yamlSolicita volumes de armazenamento persistente para dados do PostgreSQL e, opcionalmente, dados/solutions do Pentaho
*-deployment.yamlFaz o deploy do Pentaho Business Analytics Server com init container, probes de saúde e limites de recursos. Faz o deploy do servidor de banco de dados PostgreSQL 15 com inicialização automática e armazenamento persistente
*-service.yamlRoteia tráfego HTTP/HTTPS externo para o Pentaho Server via controlador de ingress Traefik. Expõe a porta 5432 do PostgreSQL como um endpoint DNS estável para o Pentaho se conectar.
ingress.yamlRoteia tráfego HTTP/HTTPS externo para o Pentaho Server via controlador de ingress Traefik
{% endtab %} {% tab title="2. Deploy" %} {% hint style="info" %} #### Deploy A arquitetura consiste em dois pods principais executando dentro de um namespace dedicado ao Pentaho: um pod Pentaho Server (Tomcat em Debian com OpenJDK 21) e um pod PostgreSQL hospedando três bancos de dados essenciais - Jackrabbit para armazenamento de conteúdo, Quartz para agendamento de jobs, e Hibernate para segurança e logging de auditoria. {% endhint %} {% hint style="danger" %} Antes de prosseguir, certifique-se de ter completado os Passos 1 - 3. Você deve ter uma imagem do Pentaho Server + imagens de repositório do PostgreSQL 15 enviadas para o repositório do K3s. {% endhint %} 1. Verificação rápida. ```bash # Verificar versão do Helm (requer 3.0+) helm version # Verificar cluster Kubernetes kubectl cluster-info kubectl get nodes # Verificar classes de armazenamento disponíveis kubectl get storageclass ``` 2. Verifique se a imagem do Pentaho está disponível. ```bash # Verificar sudo k3s ctr images ls | grep pentaho ```

Imagem do Pentaho Server no repositório K3s

*** {% hint style="info" %} #### Deployment Padrão O fluxo de implantação avança por quatro etapas: * preparar o ambiente posicionando o pacote Pentaho Enterprise Edition e verificando o K3s. * configurar variáveis de ambiente e sobrescritas de software durante tarefas de pre-flight. * construir e enviar uma imagem Docker personalizada para o runtime de contêiner do K3s. * finalmente implantar a stack completa usando charts Helm ou um automatizado `deploy.sh` script que orquestra a criação de namespace, secrets, ConfigMaps, armazenamento persistente e roteamento de ingress Traefik. Também cobre a estrutura do chart Helm, um conjunto de scripts auxiliares para backup, verificações de saúde, monitoramento de recursos e validação de implantação, juntamente com múltiplos métodos de acesso incluindo port-forwarding, ingress por hostname e IP direto do nó. {% endhint %} 1. Instalar usando charts Helm. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/helm-chart helm install pentaho ./pentaho ```

Implantar Pentaho Server - Helm Chart

{% endtab %} {% endtabs %} {% endtab %} {% tab title="Scripts Auxiliares" %} {% hint style="info" %} #### Scripts Auxiliares A implantação Pentaho no K3s inclui uma coleção de scripts auxiliares em `scripts/` diretório para operações e manutenção do dia a dia: * **backup-postgres.sh:** Cria dumps compactados com timestamp de todos os bancos de dados do Pentaho (Jackrabbit, Quartz, Hibernate) usando `pg_dump` executado dentro do pod PostgreSQL. * **restore-postgres.sh:** Restaura bancos de dados do Pentaho a partir de arquivos de backup, útil para recuperação de desastres, clonagem de ambientes ou migração de dados entre clusters. * **health-check.sh:** Realiza uma verificação rápida de saúde em tempo de execução cobrindo readiness dos pods, disponibilidade de serviços, conectividade com o banco de dados e um teste HTTP ao vivo na página de login do Pentaho. * **validate-deployment.sh:** Executa uma auditoria abrangente em seis categorias: namespace, pods, serviços, PersistentVolumeClaims, ConfigMaps e configuração de ingress. * **monitor-resources.sh:** Acompanha o uso de CPU e memória em todos os pods do Pentaho usando `kubectl top` para ajudar a identificar restrições de recursos ou oportunidades de otimização. * **monitor-postgres.sh:** Monitora métricas específicas do PostgreSQL incluindo contagem de conexões, queries ativas, tamanhos de tabelas e saúde geral do banco de dados. * **verify-k3s.sh:** Valida a infraestrutura subjacente K3s (status dos nós, classes de armazenamento, ingress Traefik e componentes principais) antes de tentar um deploy do Pentaho. * **Makefile:** Fornece comandos de conveniência como `make health`, `make status`, `make logs`, `make port-forward`, e `make destroy` para gerenciamento simplificado do cluster. {% endhint %} {% tabs %} {% tab title="1. Diretórios" %} {% hint style="info" %} #### Layout de diretório Esta configuração de implantação K3s fornece várias capacidades importantes: * Implantação Kubernetes completamente autocontida em K3s leve * Inicialização automatizada do banco de dados com scripts SQL do PostgreSQL * Checks de saúde nativos do Kubernetes e ordenação de inicialização * PersistentVolumeClaims para dados do banco e conteúdo do Pentaho * Processo de build de imagem Docker com otimização multi-stage * Limites de recursos (CPU/memória) para estabilidade * Templates de manifest prontos para produção * Driver JDBC do PostgreSQL incluído * Procedimentos fáceis de backup e restauração via scripts utilitários * Configuração de Ingress para roteamento Traefik {% endhint %} *** **Arquivos do Diretório Raiz** ``` Pentaho-K3s-PostgreSQL/ ├── deploy.sh # Script principal de implantação ├── destroy.sh # Script de limpeza ├── Makefile # Comandos rápidos (make help) ├── README.md # Este arquivo ├── DEPLOYMENT.md # Guia detalhado de implantação ├── K3s-INSTALLATION.md # Instruções de configuração do K3s ``` {% hint style="info" %} **Arquivos de Documentação:** **README.md** - Documento de entrada principal fornecendo visão geral do projeto, instruções de início rápido, pré-requisitos e informações gerais de uso para o workshop de implantação K3s. **DEPLOYMENT.md** - Guia detalhado de implantação cobrindo o fluxo completo de implantação no K3s, incluindo pré-requisitos, instruções passo a passo e procedimentos de verificação pós-implantação. **K3s-INSTALLATION.md** - Instruções de configuração e instalação do K3s cobrindo preparação do sistema, instalação do K3s, configuração de rede e configuração de classes de armazenamento necessárias antes de implantar o Pentaho. **Orquestração & Implantação:** **deploy.sh** - Script de implantação automatizado que orquestra o fluxo completo de implantação no K3s incluindo criação de namespace, geração de secrets, aplicação de manifests e checagens de disponibilidade dos serviços. **destroy.sh** - Script de limpeza que remove com segurança todos os recursos do K3s incluindo deployments, services, PersistentVolumeClaims e namespaces, útil para reimplantação ou cenários de desmontagem. **Makefile** - Contém alvos de comando de conveniência para operações comuns do K3s, como implantar, destruir, checar status e visualizar logs. Usuários podem executar `make help` para ver todos os comandos disponíveis. {% endhint %} *** **docker-build** ``` ├── docker-build/ # Build da imagem Docker │ ├── build.sh # Script de build │ ├── Dockerfile # Definição da imagem │ ├── README.md # Documentação completa do build │ ├── QUICK-START.md # Guia rápido de build │ ├── ENV-CONFIGURATION.md # Guia de configuração .env │ ├── .env.example # Template de configuração │ ├── test-compose.yml # Teste Docker local │ ├── entrypoint/ # Scripts de inicialização do container │ │ ├── docker-entrypoint.sh │ │ └── start-pentaho-docker.sh │ ├── softwareOverride/ # Overlays de configuração (embutidos na imagem) │ │ ├── 1_drivers/ # Driver JDBC do PostgreSQL │ │ ├── 2_repository/ # Configs do banco de dados │ │ │ └── README.md │ │ ├── 3_security/ # (vazio - sem Vault) │ │ └── 4_others/ # Scripts Tomcat modificados │ │ └── README.md │ └── stagedArtifacts/ # Coloque o ZIP do Pentaho aqui │ └── README.md ``` {% hint style="info" %} O **docker-build/** diretório contém todos os componentes necessários para construir a imagem do container do Pentaho Server que será implantada no K3s: **Arquivos de Documentação:** **README.md** - Documentação completa do build cobrindo o processo de build da imagem Docker, arquitetura de build multi-stage, opções de configuração, solução de problemas e melhores práticas para construir imagens do Pentaho Server para implantação no K3s. **QUICK-START.md** - Guia rápido de build fornecendo instruções passo a passo para usuários que querem construir e testar rapidamente a imagem do Pentaho sem ler a documentação completa. Inclui comandos de build comuns e fluxos de trabalho típicos. **ENV-CONFIGURATION.md** - Guia de referência abrangente de configuração para o `.env.example` arquivo, detalhando todas as variáveis de ambiente disponíveis, seus propósitos, valores padrão e como elas afetam o processo de build do Docker e a imagem resultante. **Arquivos de Build & Configuração:** **build.sh** - Script wrapper de build automatizado que valida pré-requisitos, verifica arquivos necessários (ZIP do Pentaho em `stagedArtifacts/`), detecta plugins automaticamente (PAZ, PIR, PDD), confirma o build com o usuário, executa `docker build`, mostra informações da imagem após o build, e opcionalmente faz push para um registry com a `-p` flag. **.env.example** - Arquivo template de configuração contendo todas as variáveis de ambiente disponíveis para o processo de build Docker. Usuários copiam isto para `.env` e personalizam valores para suas necessidades específicas de implantação incluindo versão do Pentaho, tags de imagem e opções de build. **Dockerfile** - Definição de build multi-stage usando `debian:trixie-slim` como imagem base com OpenJDK 21 JRE. Cria imagens otimizadas separando o ambiente de build do ambiente de runtime, reduzindo o tamanho final da imagem enquanto mantém todos os componentes necessários do Pentaho. A abordagem multi-stage minimiza vulnerabilidades de segurança e melhora a eficiência do build. **test-compose.yml** - Ambiente de teste Docker Compose local que permite testar a imagem Docker construída localmente antes de implantar no K3s. Isso é útil para validar alterações de configuração, testar plugins personalizados ou depurar problemas de inicialização sem o overhead de uma implantação completa no K3s. **Scripts de Inicialização do Container:** **entrypoint/** - Diretório contendo scripts de inicialização e inicialização do container: * **docker-entrypoint.sh** - Script principal de inicialização do container que é executado quando o container inicia. Trata do processamento de variáveis de ambiente, personalização de arquivos de configuração a partir de `softwareOverride/`, validação de conexão com o banco de dados, checks de saúde e orquestra a sequência de inicialização do Pentaho Server. * **start-pentaho-docker.sh** - Script de inicialização específico do Pentaho que gerencia a inicialização do Tomcat, configuração da JVM, configurações de memória, e inicia os serviços do Pentaho Server. Este script é chamado por `docker-entrypoint.sh` após a preparação do ambiente estar completa. **Overlays de Configuração:** **softwareOverride/** - Diretório de overlays de configuração que é embutido na imagem Docker durante o processo de build. Os arquivos são organizados em diretórios numerados e processados em ordem alfabética para garantir a sequência correta de aplicação: * **1\_drivers/** - Driver JDBC do PostgreSQL (incluído por padrão) para conectividade com o banco de dados. Drivers JDBC adicionais ou conectores de dados podem ser colocados aqui. * **2\_repository/** - Configurações de conexão de banco de dados para todos os repositórios do Pentaho incluindo Jackrabbit (JCR), Quartz (scheduler) e Hibernate (security/audit). Contém um **README.md** explicando os arquivos de configuração do repositório e seus propósitos. * **3\_security/** - Vazio nesta implantação K3s já que a integração com HashiCorp Vault não é usada. Em ambientes de produção, isto conteria arquivos de autenticação, autorização e configuração de segurança. * **4\_others/** - Scripts Tomcat modificados (startup.sh, setenv.sh), server.xml, web.xml e outras configurações a nível de aplicação. Contém um **README.md** documentando as modificações customizadas do Tomcat e seus propósitos. **Artefatos Posicionados (Staged Artifacts):** **stagedArtifacts/** - Diretório de staging onde os usuários colocam o pacote de instalação do Pentaho Server (`pentaho-server-ee-11.0.0.0-237.zip`) antes de construir a imagem Docker. Contém um **README.md** com instruções sobre onde obter o pacote Pentaho e como posicioná-lo corretamente. {% endhint %} *** **db\_init\_postgres** ``` ├── db_init_postgres/ # Scripts SQL de init do PostgreSQL │ ├── 1_create_jcr_postgresql.sql │ ├── 2_create_quartz_postgresql.sql │ ├── 3_create_repository_postgresql.sql │ ├── 4_pentaho_logging_postgresql.sql │ └── 5_pentaho_mart_postgresql.sql ``` {% hint style="info" %} O **db\_init\_postgres/** diretório contém scripts de inicialização do PostgreSQL que criam todos os bancos de dados de repositório do Pentaho necessários. Estes scripts são montados no container PostgreSQL e executam automaticamente na primeira inicialização: **1\_create\_jcr\_postgresql.sql** - Cria o **Banco de Dados do Jackrabbit Content Repository (JCR)** (database). O JCR armazena todo o conteúdo do Pentaho incluindo relatórios, dashboards, data sources, schemas de análise, transformações, jobs e arquivos de usuário. Este é o principal sistema de gerenciamento de conteúdo para o repositório do Pentaho. **2\_create\_quartz\_postgresql.sql** - Configura o **Banco de Dados do Quartz Scheduler** (database). O Quartz gerencia todos os jobs agendados, triggers e calendários dentro do Pentaho Server, incluindo agendas de geração de relatórios, execuções de jobs ETL e outros processos automatizados. Contém tabelas críticas como `QRTZ6_JOB_DETAILS`, `QRTZ6_TRIGGERS`, e histórico de execução. **3\_create\_repository\_postgresql.sql** - Cria o **Banco de Dados do Repositório Hibernate** (database). Este armazena dados de autenticação de usuários, informações de autorização, papéis, permissões e outras informações relacionadas à segurança gerenciadas pelo subsistema de segurança do Pentaho. **4\_pentaho\_logging\_postgresql.sql** - Estabelece o **pentaho\_dilogs** schema dentro do banco de dados Hibernate para auditoria e logging do Data Integration (DI). Captura informações detalhadas de execução de ETL incluindo logs de jobs, logs de transformações, métricas de performance de steps e registros de erro. Essencial para depurar fluxos de integração de dados e monitorar a saúde dos pipelines. **5\_pentaho\_mart\_postgresql.sql** - Cria o **pentaho\_operations\_mart** schema dentro do banco de dados Hibernate. Este data mart dimensional armazena analytics operacionais sobre o uso do Pentaho Server, incluindo tabelas de dimensão (`DIM_DATE`, `DIM_TIME`, `DIM_EXECUTOR`) e tabelas de fatos (`FACT_EXECUTION`, `FACT_STEP_EXECUTION`) para analisar a utilização da plataforma, tendências de performance e padrões de atividade dos usuários. {% endhint %} *** **manifests** ``` ├── manifests/ # Manifests do Kubernetes │ ├── namespace.yaml # Namespace do Pentaho │ ├── configmaps/ │ │ ├── pentaho-config.yaml │ │ └── postgres-init-scripts.yaml │ ├── pentaho/ │ │ ├── deployment.yaml │ │ └── service.yaml │ ├── postgres/ │ │ ├── deployment.yaml │ │ └── service.yaml │ ├── secrets/ │ │ └── secrets.yaml # (ignorado pelo git) │ ├── storage/ │ │ └── pvc.yaml │ └── ingress/ │ └── ingress.yaml ``` {% hint style="info" %} O **manifests/** diretório contém todas as definições de recursos do Kubernetes organizadas por área funcional. Estes arquivos YAML definem o estado declarativo da sua implantação K3s: **namespace.yaml** - Cria o namespace dedicado `pentaho` para isolar todos os recursos relacionados ao Pentaho de outras cargas de trabalho do K3s, proporcionando separação lógica e organização de recursos. **configmaps/** - Recursos ConfigMap para dados de configuração não sensíveis: * **pentaho-config.yaml** - Configurações do Pentaho Server como parâmetros da JVM, configurações do Tomcat e propriedades de aplicação * **postgres-init-scripts.yaml** - ConfigMap contendo os cinco scripts de inicialização do PostgreSQL do diretório `db_init_postgres/` montado no pod PostgreSQL **pentaho/** - Recursos Kubernetes do Pentaho Server: * **deployment.yaml** - Define o deployment do Pentaho Server incluindo especificações de container, requests/limits de recursos, variáveis de ambiente, mounts de volumes, probes de readiness/liveness e contagem de réplicas * **service.yaml** - Service ClusterIP expondo o Pentaho Server na porta 8080 dentro do cluster, fornecendo DNS interno estável e balanceamento de carga **postgres/** - Recursos Kubernetes do banco de dados PostgreSQL: * **deployment.yaml** - Define o deployment do PostgreSQL 15 com especificações de container, PersistentVolumeClaims para armazenamento de dados, montagem dos scripts de inicialização e configuração do banco de dados * **service.yaml** - Service ClusterIP expondo o PostgreSQL na porta 5432 dentro do cluster para conexões de banco do Pentaho Server **secrets/** - Armazenamento de credenciais sensíveis: * **secrets.yaml** - Recurso Kubernetes Secret contendo credenciais codificadas em base64 para PostgreSQL (`postgres_password`, `pentaho_user`, `pentaho_password`) e strings de conexão JDBC. **Este arquivo é ignorado pelo git por segurança.** **storage/** - Definições de armazenamento persistente: * **pvc.yaml** - Definições de PersistentVolumeClaim tanto para dados do PostgreSQL (`postgres-pvc`) quanto para soluções/dados do Pentaho (`pentaho-pvc`), usando a storage class local-path do K3s para dados persistentes através de reinicializações de pods **ingress/** - Configuração de acesso externo: * **ingress.yaml** - Recurso Traefik Ingress definindo regras de roteamento HTTP/HTTPS externas para expor o Pentaho Server fora do cluster K3s, incluindo hostname, roteamento por path e configuração TLS se aplicável {% endhint %} *** **scripts** ``` └── scripts/ # Scripts utilitários ├── backup-postgres.sh # Backup de banco de dados ├── restore-postgres.sh # Restauração de banco de dados ├── health-check.sh # Verificação de saúde ├── monitor-resources.sh # Monitoramento de recursos ├── monitor-postgres.sh # Monitoramento do PostgreSQL ├── validate-deployment.sh # Validação da implantação └── verify-k3s.sh # Verificação do K3s ``` {% hint style="info" %} O **scripts/** diretório contém utilitários operacionais e de manutenção para gerenciar a implantação K3s do Pentaho: **Gerenciamento de Banco de Dados:** **backup-postgres.sh** - Utilitário automatizado de backup do PostgreSQL que cria dumps compactados de todos os bancos de dados do Pentaho (jackrabbit, quartz, hibernate) usando `kubectl exec` para executar `pg_dump` dentro do pod PostgreSQL. Backups são com timestamp e compactados com gzip para armazenamento eficiente. **restore-postgres.sh** - Utilitário de restauração de banco de dados para recuperar bancos do Pentaho a partir de arquivos de backup. Útil para recuperação de desastres, clonagem de ambientes ou migração de dados entre clusters K3s. Lida com descompressão e restauração via `kubectl exec` e `psql`. **Monitoramento & Validação:** **health-check.sh** - Script de verificação de saúde que valida que tanto o PostgreSQL quanto o Pentaho Server estão em execução e respondendo corretamente. Verifica status dos pods, probes de readiness e realiza testes básicos de conectividade. **monitor-resources.sh** - Utilitário de monitoramento de recursos que acompanha uso de CPU, memória e armazenamento em todos os pods do Pentaho usando `kubectl top` e métricas de recursos, ajudando a identificar restrições de recursos ou oportunidades de otimização. **monitor-postgres.sh** - Script de monitoramento específico do PostgreSQL que checa contagem de conexões do banco, queries ativas, tamanhos de tabelas e métricas de saúde do banco via queries SQL executadas no pod PostgreSQL. **validate-deployment.sh** - Script abrangente de validação de implantação que confirma que todos os recursos do K3s foram criados corretamente, pods estão em execução, serviços estão acessíveis, volumes persistentes estão vinculados, e toda a implantação está operacional. **verify-k3s.sh** - Script de verificação da infraestrutura K3s que checa a instalação do K3s, status dos nós, classes de armazenamento, controlador de ingress Traefik e componentes principais do K3s antes de tentar a implantação do Pentaho. {% endhint %} *** **Principais Diferenças: K3s vs Docker**
AspectoImplantação DockerImplantação K3s
OrquestraçãoDocker ComposeKubernetes (K3s)
Configuração.env arquivo + docker-compose.ymlManifests do Kubernetes (YAML)
SecretsSegredos Docker ou VaultKubernetes Secrets
RedeRede bridge do DockerRede do cluster K3s + Traefik Ingress
ArmazenamentoVolumes DockerPersistentVolumeClaims (PVCs)
EscalonamentoManual (docker compose up --scale)Declarativo (replicas no deployment)
Verificações de integridadeDocker HEALTHCHECKProbes de readiness/liveness do Kubernetes
Scripts de inicializaçãoMontagem de volume para /docker-entrypoint-initdb.dConfigMap montado no pod PostgreSQL
{% endtab %} {% tab title="2. Deploy" %} {% hint style="info" %} #### Execução do deploy O `deploy.sh` script automatiza todo o fluxo de trabalho: * Verifica se o K3s está em execução * Cria namespace * Aplica todos os manifests na ordem correta * Monitora a inicialização dos pods * Valida disponibilidade dos serviços * Fornece resumo da implantação com URLs de acesso **1. Criação do Namespace:** ```bash kubectl create namespace pentaho ``` Cria um ambiente lógico isolado para todos os recursos do Pentaho. **2. Geração de Secrets:** ```bash kubectl apply -f manifests/secrets/secrets.yaml ``` Armazena credenciais do PostgreSQL e strings de conexão JDBC como Secrets do Kubernetes. **3. Provisionamento de Armazenamento:** ```bash kubectl apply -f manifests/storage/pvc.yaml ``` Cria PersistentVolumeClaims para dados do PostgreSQL e conteúdo do Pentaho. **4. Criação de ConfigMap:** ```bash kubectl apply -f manifests/configmaps/ ``` Monta scripts de inicialização do PostgreSQL e configuração do Pentaho. **5. Deploy do PostgreSQL:** ```bash kubectl apply -f manifests/postgres/ ``` Faz o deploy do pod PostgreSQL com: * Scripts de init montados (criação automática do banco na primeira inicialização) * Volume persistente para dados * Checks de saúde e limites de recursos * Service ClusterIP para conectividade interna **6. Deploy do Pentaho Server:** ```bash kubectl apply -f manifests/pentaho/ ``` Faz o deploy do pod Pentaho com: * Imagem Docker personalizada * Variáveis de ambiente vindas de ConfigMap e Secrets * Mounts de volume para solutions/dados * Probes de readiness/liveness * Service ClusterIP **7. Configuração de Ingress:** ```bash kubectl apply -f manifests/ingress/ingress.yaml ``` Configura o roteamento Traefik para acesso externo. {% endhint %} 1. Execute o deploy.sh ```sh cd cd ~/Pentaho-K3s-PostgreSQL ./deploy.sh ```

Implantar Pentaho Server

{% hint style="info" %} Este script unificado trata do processo completo de implantação do Pentaho Server no K3s, incluindo: * Importação da imagem Docker para o runtime de contêiner do K3s * Criação de recursos Kubernetes (namespace, secrets, configmaps, storage) * Implantação do banco de dados PostgreSQL * Implantação do Pentaho Server * Configuração de Ingress * Checks de saúde e relatório de status ``` Uso: ./deploy.sh # Implantação nova com importação da imagem ./deploy.sh --skip-import # Implantar sem importar a imagem ./deploy.sh --update-only # Apenas atualizar implantação existente ./deploy.sh --clean # Remover imagens antigas antes de implantar ``` Pré-requisitos: * K3s instalado e em execução * Imagem Docker construída: pentaho/pentaho-server:11.0.0.0-237 * kubectl configurado para acessar o cluster K3s * Acesso sudo para operações containerd do K3s {% endhint %} *** **Comandos Rápidos com Makefile** ```bash make help # Mostra todos os comandos disponíveis make full-deploy # Build, import e deploy (fluxo completo) make health # Executa verificação de saúde make status # Mostra status da implantação make logs # Visualiza logs do Pentaho make port-forward # Acessa o Pentaho em localhost:8080 make destroy # Remove a implantação ``` *** Também há um monte de scripts que ajudam a validar a implantação: {% tabs %} {% tab title="Validar Implantação" %} {% hint style="info" %} Script abrangente de validação pós-implantação que verifica se todos os componentes da implantação Pentaho K3s estão corretamente configurados e em execução. O que ele verifica (6 Categorias) **Namespace** * Verifica se o namespace pentaho existe **Pods** * Pod PostgreSQL está Running * Pod Pentaho Server está Running * Mostra status atual se não estiver em execução **Services** * Service PostgreSQL existe * Service Pentaho Server existe **PersistentVolumeClaims (3 PVCs)** * postgres-data-pvc (10Gi) - Arquivos do banco de dados * pentaho-data-pvc (10Gi) - Pentaho * data pentaho-solutions-pvc (5Gi) - Repositório de solutions * Todos devem estar em status "Bound" **ConfigMaps** * pentaho-config - Variáveis de ambiente * postgres-init - Scripts de inicialização do banco de dados **Ingress** * pentaho-ingress - Configuração de roteamento do Traefik **Testes de Conectividade com o Banco de Dados** * Conecta ao pod PostgreSQL * Testa os 3 bancos do Pentaho: \* jackrabbit - repositório de conteúdo JCR \* quartz - scheduler de jobs \* hibernate - repositório de configuração * Executa a query SELECT 1 em cada um {% endhint %} 1. Execute o seguinte `validate-deployment.sh` script. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```

Validar implantação

{% endtab %} {% tab title="Verificação de integridade" %} {% hint style="info" %} #### Verificação de integridade Script rápido de verificação de integridade para implantações Pentaho - mais rápido e leve que a validação completa, focado no status de execução. Namespace * Verifica se o namespace pentaho existe * Encerra imediatamente se o namespace estiver ausente (crítico) Prontidão do Pod * Pod PostgreSQL está pronto (não apenas em execução) * Pod do Pentaho Server está pronto * Verificações `status containerStatuses[0].ready` Services * Service PostgreSQL existe * Service Pentaho Server existe Conectividade com o banco de dados * PostgreSQL está respondendo a consultas Todos os 3 bancos de dados existem: \* jackrabbit \* quartz \* hibernate * Usa `psql -lqt` para listar bancos de dados Saúde da aplicação web * Teste HTTP ao vivo para a página de login do Pentaho * Usa port-forward para acessar o serviço * Espera resposta HTTP 200 * Testes: ; Uso de recursos * Mostra uso de CPU/memória via `kubectl top pods` * Trata graciosamente a ausência do metrics-server {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./health-check.sh ```

Verificação de integridade

{% endtab %} {% tab title="Monitorar recursos" %} {% hint style="info" %} #### Monitorar recursos x {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```
{% endtab %} {% tab title="Pentaho Server" %} {% hint style="info" %} #### Acessando o Pentaho Server {% endhint %} **Encaminhamento de Porta (Recomendado para Testes/Desenvolvimento)** O método mais simples usando kubectl para encaminhar uma porta local para o serviço Pentaho: ```bash kubectl port-forward -n pentaho svc/pentaho-server 8080:8080 ``` **URL de acesso:** `http://localhost:8080/pentaho` Você também pode usar uma porta alternativa se 8080 estiver ocupada: ```bash kubectl port-forward -n pentaho svc/pentaho-server 9080:8080 # Então acesse: http://localhost:9080/pentaho ``` *** **Ingress com nome de host (pentaho.local)** Usa o controlador ingress Traefik embutido do K3s com acesso no estilo DNS: **Configuração:** ```bash echo "10.0.0.1 pentaho.local" | sudo tee -a /etc/hosts ``` *(Substitua 10.0.0.1 pelo IP real do seu nó)* **URL de acesso:** `http://pentaho.local/pentaho` *** **Ingress via IP direto do nó (sem DNS)** Acesse diretamente através do IP de qualquer nó do cluster sem configurar /etc/hosts: **URL de acesso:** `http:///pentaho` Isto funciona porque o ingress inclui uma regra baseada em caminho que não requer um nome de host. *** **Comando conveniente no Makefile** O projeto inclui um atalho no Makefile: ```bash make port-forward ``` Isto configura automaticamente o encaminhamento de porta para localhost:8080. *** **Credenciais padrão** | Nome de usuário | Senha | | --------------- | -------- | | admin | password | ⚠️ Altere estes para implantações em produção! *** **Referência rápida** | Método | Melhor para | URL | | ----------------------- | ---------------------- | ------------------------------- | | Encaminhamento de porta | Desenvolvimento/Testes | `http://localhost:8080/pentaho` | | Ingress (nome de host) | Produção com DNS | `http://pentaho.local/pentaho` | | Ingress (IP direto) | Teste sem DNS | `http:///pentaho` | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-pt-br/instalacao/conteineres/k3s.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.