K3s
Kubernetes leve ..
K3s
O K3s é uma distribuição leve e certificada do Kubernetes, projetada para ambientes com recursos limitados, computação de borda, dispositivos IoT e cenários de desenvolvimento. Criado pela Rancher Labs (agora parte da SUSE), ele empacota tudo o que é necessário para executar o Kubernetes em um único binário com menos de 100 MB.
Isso torna o K3s significativamente mais leve do que o Kubernetes padrão, mantendo compatibilidade total com as APIs e os recursos do Kubernetes. Ele requer pouca memória (mínimo de 512 MB) e oferece operações simplificadas com dependências reduzidas.
O K3s vem com componentes integrados, como o controlador de Ingress Traefik, o provisionador de armazenamento local e o balanceador de carga de serviço. É perfeito para desenvolvimento, CI/CD, implantações na borda e dispositivos ARM, mas ainda assim está pronto para produção com recursos de alta disponibilidade.

Componentes Principais do K3s
Componentes do Plano de Controle
O plano de controle inclui o API Server (endpoint da API do Kubernetes para gerenciamento do cluster), o Controller Manager (gerencia loops de controle centrais para replicação, endpoints e namespaces) e o Scheduler (atribui pods aos nós com base na disponibilidade de recursos).
O K3s pode usar etcd ou SQLite leve como datastore para o estado do cluster, tornando-o mais flexível do que o Kubernetes padrão.
Componentes do Nó
Cada nó executa o agente Kubelet, que gerencia o ciclo de vida dos pods. O Containerd já vem integrado como runtime de contêiner para execução dos contêineres.
O Kube-proxy gerencia o proxy de rede e a rede de serviços em todo o cluster.
Complementos Integrados
O K3s inclui o Traefik Ingress Controller para rotear o tráfego HTTP/HTTPS externo para os serviços. O Local Path Provisioner permite o provisionamento dinâmico de volumes persistentes usando armazenamento local.
O CoreDNS fornece DNS de cluster para descoberta de serviços. O Service Load Balancer gerencia serviços do tipo LoadBalancer sem exigir integrações externas com provedores de nuvem.
Rede
O Flannel serve como o plugin CNI (Container Network Interface) padrão para a rede de pods. As Network Policies controlam o fluxo de tráfego entre pods e serviços para maior segurança.

Pod do Servidor Pentaho
Executa o servidor de aplicações Tomcat com o Pentaho Server 11
Baseado em Debian Trixie Slim com OpenJDK 21 JRE
Build Docker em múltiplas etapas para otimizar o tamanho da imagem
Exposto internamente na porta 8080
Inclui sondas de readiness e liveness para monitoramento de integridade
Limites de recursos configurados para estabilidade de CPU e memória

Fornece o backend de banco de dados relacional para três bancos de dados críticos:
Jackrabbit (jcr_user): Java Content Repository armazenando todo o conteúdo do Pentaho (relatórios, dashboards, fontes de dados, transformações, jobs)
Quartz (pentaho_user): Agendador que gerencia jobs, gatilhos, calendários e histórico de execução
Hibernate (hibuser): configuração de segurança, logging de auditoria, sessões de usuário, além de dois schemas especializados:
pentaho_dilogs: logging de execução de ETL com logs de jobs, métricas de transformações e dados de desempenho de etapas
pentaho_operations_mart: data mart dimensional para análise da plataforma com tabelas de dimensão e fato
Dados persistidos por meio de PersistentVolumeClaim para sobreviver a reinicializações
Inicialização automatizada por meio de scripts SQL montados via ConfigMap


O Pentaho Server requer três bancos de dados separados, cada um atendendo a uma finalidade distinta:
jackrabbit
jcr_user
Java Content Repository (JCR) - Armazena todo o conteúdo do Pentaho, incluindo relatórios, painéis, fontes de dados, esquemas de análise e arquivos do usuário. Este é o principal armazenamento de conteúdo do repositório Pentaho.
quartz
pentaho_user
Quartz Scheduler - Gerencia todos os jobs, gatilhos e calendários agendados. Contém tabelas para definições de jobs (QRTZ6_JOB_DETAILS), gatilhos (QRTZ6_TRIGGERS), histórico de execução e locks de coordenação de cluster.
hibernate
hibuser
Hibernate Repository - Hospeda a configuração de segurança, logs de auditoria, dados de sessão do usuário e contém dois esquemas adicionais: pentaho_dilogs (log de execução ETL) e pentaho_operations_mart (data mart analítico).
O banco de dados hibernate contém esquemas especializados para monitoramento operacional:
pentaho_dilogs: Captura informações detalhadas de execução ETL, incluindo logs de jobs, logs de transformações, métricas de desempenho de etapas e registros de erros. Essencial para depurar fluxos de trabalho de integração de dados e monitorar a saúde do pipeline.
pentaho_operations_mart: Um data mart dimensional para análises sobre o uso do Pentaho. Contém tabelas de dimensão (DIM_DATE, DIM_TIME, DIM_EXECUTOR) e tabelas fato (FACT_EXECUTION, FACT_STEP_EXECUTION) para analisar a utilização da plataforma, tendências de desempenho e atividade do usuário.
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 do usuário. Considere usar pg_dump para backups lógicos ou snapshots do volume para opções completas de recuperação.
Rede
Comunicação Interna:
Ambos os pods são executados dentro do
pentahonamespaceServiços ClusterIP fornecem nomes DNS internos estáveis
PostgreSQL acessível em
postgresql.pentaho.svc.cluster.local:5432Pentaho 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
Hostname configurável e roteamento baseado em caminho
Suporte opcional à terminação TLS/SSL
O Tomcat gerencia pools de conexão definidos no context.xml. Cada pool atende a uma finalidade específica:
jdbc/Hibernate
repository:5432/hibernate
Segurança, Usuários, Funções
jdbc/Quartz
repository:5432/quartz
Agendamento de Jobs
jdbc/jackrabbit
repository:5432/jackrabbit
Repositório de Conteúdo
jdbc/Audit
repository:5432/hibernate
Registro de Auditoria
jdbc/live_logging_info
repository:5432/hibernate
Logs de Runtime ETL
jdbc/PDI_Operations_Mart
repository:5432/hibernate
Análises Operacionais
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-pathprovisionador de armazenamentoProvisiona volumes no sistema de arquivos local do nó
Criação e vinculação automáticas de volumes
ConfigMaps:
Scripts de inicialização do banco de dados (5 arquivos SQL)
Configurações do Pentaho (parâmetros da JVM, configurações do Tomcat)
Segredos:
Credenciais do PostgreSQL (postgres_password, pentaho_user, pentaho_password)
Strings de conexão JDBC
Codificado em Base64 por segurança
Antes de começar a implantação no K3s, certifique-se de ter concluído a Configuração: Contêineres do Pentaho
Execute as etapas a seguir para implantar o Pentaho Server em um K3s de nó único com o repositório PostgreSQL 15.
Preparar o Ambiente
A seção "Prepare Environment" descreve as etapas iniciais de configuração necessárias antes de implantar o Pentaho Server 11 no K3s:
copiar os assets de implantação para o seu diretório pessoal,
preparar o arquivo ZIP do Pentaho Server Enterprise Edition, verificar se o arquivo está no lugar,
confirmar que o K3s está instalado e em execução corretamente
Certifique-se de ter baixado: pentaho-server-ee-11.0.0.0-237.zip
Crie o diretório e copie os assets.
Copie o arquivo pentaho-server-ee-11.0.0.0-237.zip para o diretório /docker/stagedArtefacts.
Se você implantou um Pentaho Server de arquivo, então copie de:
/opt/pentaho/software/pentaho-server-ee-version
Caso contrário, baixe o pacote de Portal do Cliente Pentaho.
Verifique o arquivo.
Verifique a instalação do K3s.

O Pentaho Server requer uma licença válida. O
.envarquivo contém uma LICENSE_URL apontando para o servidor de licença Flexera. Certifique-se de que seus direitos de licença estejam ativos antes da implantação.
Sem uma licença válida, o Pentaho Server será iniciado, mas muitos recursos serão desativados. Verifique o status da sua licença antes de prosseguir com implantações em produção.
Principais Diferenças
Orquestração
Docker Compose
Kubernetes (K3s)
Configuração
.env arquivo + docker-compose.yml
manifests do Kubernetes (YAML)
Segredos
segredos do Docker ou Vault
Segredos do Kubernetes
Rede
rede bridge do Docker
rede do cluster K3s + Traefik Ingress
Armazenamento
volumes do Docker
PersistentVolumeClaims (PVCs)
Escalonamento
Manual (docker compose up --scale)
Declarativo (réplicas na implantação)
Verificações de integridade
HEALTHCHECK do Docker
sondas de readiness/liveness do Kubernetes
Scripts de Inicialização
Montagem de volume em /docker-entrypoint-initdb.d
ConfigMap montado no pod do PostgreSQL
Tarefas Pré-implantação
A seção Tarefas de Pré-voo descreve as etapas essenciais de preparação necessárias 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 o identificador da versão do Pentaho e o 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ínima (padrão 4 GB) e heap máxima (padrão 8 GB).
Adicione a URL do servidor de licença 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 o registry.
Depois de configurado, copie este modelo para .env para uso pelo processo de build.
Diretório softwareOverride
A softwareOverride/ diretório dentro de docker-build/ fornece um mecanismo para personalizar as configurações do Pentaho. Essas personalizações são incorporadas à imagem Docker durante o processo de build.
Os arquivos são organizados em diretórios numerados e processados em ordem alfabética.
A 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.
A 2_repository/ o diretório contém configurações de conexão com o banco de dados para os repositórios Jackrabbit (JCR), Quartz (agendador) e Hibernate. O 3_security/ diretório está vazio nesta implantação K3s, já que não há integração com Vault.
A 4_others/ o diretório contém scripts modificados do Tomcat (startup.sh, setenv.sh), server.xml e outras configurações no nível da aplicação.
Você pode, opcionalmente, atualizar o driver JDBC do PostgreSQL baixando-o do Maven Central ou copiando-o da coleção de drivers de banco de dados do workshop. Coloque o driver atualizado em softwareOverride/1_drivers/tomcat/lib/.
Configurar .env
Edite o .env.template
Insira os seguintes detalhes:
PENTAHO_VERSION
11.0.0.0-237
versão do Pentaho Server
EDIÇÃO
ee
Versão Enterprise
INCLUIR_DEMO
1
Incluir dados de demonstração
TAG_DA_IMAGEM
pentaho/pentaho-server:11.0.0.0-237
tag da imagem Docker
PENTAHO_MIN_MEMORY
4096m
tamanho mínimo do heap da JVM
PENTAHO_MAX_MEMORY
8192m
tamanho máximo do heap da JVM
PENTAHO_DI_JAVA_OPTIONS
"-Dfile.encoding=utf8 -Djava.awt.headless=true"
PENTAHO_IMAGE_NAME
pentaho/pentaho-server
nome da imagem Docker
TZ
America/NY
Fuso horário do servidor
DB_TYPE
postgres
DB_HOST
postgres
DB_PORT
5432
Porta HTTP do PostgreSQL
ENVIAR PARA O REGISTRY
false
Envia diretamente para o registry do K3s
CARREGAR_NO_K3S
true
Carrega diretamente no K3s
EXECUTAR TESTES
true
LICENSE_URL
(vazio)
URL do servidor de licença EE
Salvar:
Criar .env
softwareOverride
A softwareOverride/ diretório fornece um mecanismo poderoso para personalizar o Pentaho Server sem modificar a instalação principal. Os arquivos são copiados para a instalação do Pentaho durante a inicialização do contêiner, processados em ordem alfabética pelo nome do diretório.
O driver JDBC do PostgreSQL está incluído na distribuição do Pentaho. Se você precisar atualizar:
Baixe em Maven Central
Coloque em
softwareOverride/1_drivers/tomcat/lib/
Ou
Copie de Workshop--Installation/'Database Drivers'/
Construir e Enviar Imagem do Pentaho
O script build.sh é um wrapper automatizado de build que:
Valida pré-requisitos - Verifica se o Docker está instalado
Verifica os arquivos necessários - Confirma que o ZIP do Pentaho existe em stagedArtifacts/
Detecta plugins automaticamente - Encontra os 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 corretos
Mostra informações da imagem - Exibe o tamanho e os detalhes da imagem após o build
Opcional: Testa a imagem - Executa um teste básico do contêiner (você pode pular isso)
Opcional: Envia para o registry - Envia para o registry do Docker (apenas com a flag -p)
Esta é a abordagem recomendada para construir imagens Docker do Pentaho. Ele usa um único .env arquivo para configurar tudo - semelhante à implantação com Docker Compose.
Você pode modificar o build com as seguintes opções:
-v
--version VERSION
Versão do Pentaho (padrão: 11.0.0.0-237)
-t
--tag TAG
Tag da imagem Docker (padrão: pentaho/pentaho-server:VERSION)
-e
--edition EDITION
ee ou ce (padrão: ee)
-d
--demo
Incluir conteúdo de demonstração (padrão: não)
-p
--push
Enviar para o registry após o build
-h
--help
Enviar para o registry após o build
Construir e enviar a imagem do Pentaho Server diretamente para o registry do K3s.

1. Build da Imagem Docker: A implantação usa uma imagem de contêiner do Pentaho Server construída sob medida:
A build.sh script:
Valida pré-requisitos e arquivos necessários
Detecta plugins automaticamente (PAZ, PIR, PDD)
Executa build Docker em múltiplas etapas
Opcionalmente envia para o armazenamento de imagens do K3s
2. Gerenciamento de Configuração:
.envarquivo contém configurações específicas da implantação (versões, credenciais, memória JVM)softwareOverride/diretório fornece overlays de configuração processados em ordem numeradaDriver JDBC do PostgreSQL incluído por padrão, com opção de atualização
Scripts personalizados do Tomcat para otimização da inicialização do contêiner
Charts do Helm
Helm é o gerenciador de pacotes do Kubernetes, frequentemente chamado de "apt/yum para Kubernetes". Ele simplifica a implantação e o gerenciamento de aplicativos Kubernetes por meio de:
Empacotamento: Agrupando recursos relacionados do Kubernetes
Modelagem: Parametrizando manifestos para reutilização entre ambientes
Versionamento: Gerenciando versões e atualizações do aplicativo
Gerenciamento de Releases: Acompanhando implantações e permitindo reversões

Layout do Diretório
Abaixo está uma explicação do diretório pentaho responsável por uma implantação Helm.
Chart.yaml
Este arquivo define a identidade, a versão e os metadados do chart usados pelo Helm.
Ele serve como a "definição do pacote" do chart Helm, semelhante ao package.json (npm) ou ao Chart.lock (dependências do Helm).
Função: o Chart.yaml informa ao Helm o que este chart é, qual versão ele possui, qual aplicação ele implanta e fornece metadados pesquisáveis para os repositórios de charts.
O Helm usa este arquivo para rastrear versões do chart, gerenciar dependências e exibir informações quando os usuários pesquisam ou instalam charts.
values.yaml
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 personalizam como um aplicativo ou serviço é implantado no cluster - coisas como contagem de réplicas, versões de imagem, 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 modelos do chart para gerar os manifests finais do Kubernetes. Você pode substituir valores específicos no momento da implantação 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 modelos subjacentes do chart.
templates
namespace.yaml
Cria um namespace isolado do Kubernetes para conter todos os recursos do Pentaho
secret.yaml
Armazena credenciais sensíveis do banco de dados (senhas) criptografadas no Kubernetes
config-*.yaml
Configura 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 os bancos de dados PostgreSQL (jackrabbit, quartz, hibernate) na primeira inicialização
pvc.yaml
Solicita volumes de armazenamento persistente para dados do PostgreSQL e dados/soluções opcionais do Pentaho
*-deployment.yaml
Implanta o Pentaho Business Analytics Server com contêiner de inicialização, sondas de integridade e limites de recursos. Implanta o servidor de banco de dados PostgreSQL 15 com inicialização automática e armazenamento persistente
*-service.yaml
Roteia o tráfego HTTP/HTTPS externo para o Pentaho Server por meio do controlador de Ingress Traefik. Expõe a porta 5432 do PostgreSQL como um endpoint DNS estável para o Pentaho se conectar.
ingress.yaml
Roteia o tráfego HTTP/HTTPS externo para o Pentaho Server por meio do controlador de Ingress Traefik
Implantar
A arquitetura consiste em dois pods principais executados dentro de um namespace dedicado ao Pentaho:
um pod do Pentaho Server (Tomcat no 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.
Antes de prosseguir, certifique-se de ter concluído as Etapas 1 - 3. Você deve ter uma imagem do Pentaho Server + imagens do repositório PostgreSQL 15 enviadas para o repositório K3s.
Verificação rápida.
Verifique se a imagem do Pentaho está disponível.

Implantação Padrão
O fluxo de implantação progride por quatro etapas:
preparando o ambiente com o pacote da Enterprise Edition do Pentaho em estágio e verificando o K3s.
configurando variáveis de ambiente e overrides de software durante as tarefas de pré-voo.
construindo e enviando uma imagem Docker personalizada para o runtime de contêineres do K3s.
por fim implantando a pilha completa usando charts Helm ou um
deploy.shscript automatizado que orquestra a criação de namespace, segredos, ConfigMaps, armazenamento persistente e roteamento Ingress via Traefik.
Também aborda a estrutura do chart Helm, um conjunto de scripts auxiliares para backup, verificações de integridade, monitoramento de recursos e validação da implantação, além de vários métodos de acesso, incluindo encaminhamento de porta, Ingress baseado em hostname e IP direto do nó.
Instale usando charts Helm.

Scripts Auxiliares
A implantação do Pentaho no K3s inclui uma coleção de scripts auxiliares no 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_dumpexecutado dentro do pod do PostgreSQL.restore-postgres.sh: Restaura os bancos de dados do Pentaho a partir de arquivos de backup, útil para recuperação de desastres, clonagem de ambiente ou migração de dados entre clusters.
health-check.sh: Executa uma verificação rápida de integridade em tempo de execução, cobrindo prontidão do pod, disponibilidade do serviço, 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 toppara 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, consultas ativas, tamanhos de tabelas e a saúde geral do banco de dados.
verify-k3s.sh: Valida a infraestrutura subjacente do K3s (status dos nós, classes de armazenamento, ingress do Traefik e componentes principais) antes de tentar uma implantação do Pentaho.
Makefile: Fornece comandos de conveniência como
make health,make status,make logs,make port-forward, emake destroypara um gerenciamento de cluster mais simplificado.
Layout do Diretório
Esta configuração de implantação do K3s oferece vários recursos importantes:
Implantação Kubernetes totalmente autônoma no K3s leve
Inicialização automatizada do banco de dados com scripts SQL do PostgreSQL
Verificações de integridade nativas do Kubernetes e ordenação de inicialização
PersistentVolumeClaims para o banco de dados e o conteúdo do Pentaho
Processo de build da imagem Docker com otimização em múltiplos estágios
Limites de recursos (CPU/memória) para estabilidade
Modelos de manifestos Kubernetes prontos para produção
Driver JDBC do PostgreSQL incluído
Procedimentos fáceis de backup e restauração por meio de scripts utilitários
Configuração de ingress para roteamento do Traefik
Arquivos do Diretório Raiz
Arquivos de Documentação:
README.md - A documentação principal de entrada, 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 do 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 da classe de armazenamento necessária antes de implantar o Pentaho.
Orquestração e Implantação:
deploy.sh - Script automatizado de implantação que orquestra o fluxo completo de implantação no K3s, incluindo criação de namespace, geração de secrets, aplicação de manifestos e verificações de prontidão dos serviços.
destroy.sh - Script de limpeza que remove com segurança todos os recursos do K3s, incluindo implantações, serviços, PersistentVolumeClaims e namespaces, útil para cenários de nova implantação ou desmontagem.
Makefile - Contém alvos de comandos de conveniência para operações comuns do K3s, como implantar, destruir, verificar status e visualizar logs. Os usuários podem executar make help para ver todos os comandos disponíveis.
docker-build
A docker-build/ diretório contém todos os componentes necessários para construir a imagem do contêiner do Pentaho Server que será implantada no K3s:
Arquivos de Documentação:
README.md - Documentação completa do build cobrindo o processo de criação da imagem Docker, a arquitetura de build em múltiplos estágios, opções de configuração, solução de problemas e melhores práticas para criar 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 desejam construir e testar rapidamente a imagem do Pentaho sem ler a documentação completa. Inclui comandos comuns de build e fluxos de trabalho típicos.
ENV-CONFIGURATION.md - Guia de referência de configuração abrangente 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 e 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 envia para um registry com a -p flag.
.env.example - Arquivo modelo de configuração contendo todas as variáveis de ambiente disponíveis para o processo de build do Docker. Os usuários copiam isto para .env e personalizam os valores de acordo com suas necessidades específicas de implantação, incluindo versão do Pentaho, tags da imagem e opções de build.
Dockerfile - Definição de build em múltiplos estágios usando debian:trixie-slim como imagem base com OpenJDK 21 JRE. Cria imagens otimizadas separando o ambiente de build do ambiente de execução, reduzindo o tamanho final da imagem enquanto mantém todos os componentes necessários do Pentaho. A abordagem em múltiplos estágios minimiza vulnerabilidades de segurança e melhora a eficiência do build.
test-compose.yml - Ambiente local de teste com Docker Compose que permite testar a imagem Docker construída localmente antes de implantá-la no K3s. Isso é útil para validar alterações de configuração, testar plugins personalizados ou depurar problemas de inicialização sem a sobrecarga de uma implantação completa no K3s.
Scripts de inicialização do contêiner:
entrypoint/ - Diretório contendo scripts de inicialização e startup do contêiner:
docker-entrypoint.sh - Script principal de inicialização do contêiner que é executado quando o contêiner inicia. Lida com o processamento de variáveis de ambiente, personalização de arquivos de configuração a partir de
softwareOverride/, validação da conexão com o banco de dados, verificações de integridade 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, a configuração da JVM, as definições de memória e inicia os serviços do Pentaho Server. Este script é chamado por
docker-entrypoint.shapós a preparação do ambiente ser concluída.
Sobreposições de configuração:
softwareOverride/ - Diretório de sobreposições de configuração que é incorporado 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 com o banco de dados para todos os repositórios do Pentaho, incluindo Jackrabbit (JCR), Quartz (agendador) e Hibernate (segurança/auditoria). Contém um README.md explicando os arquivos de configuração do repositório e seus propósitos.
3_security/ - Vazio nesta implantação do K3s, pois a integração com o HashiCorp Vault não é usada. Em ambientes de produção, isso conteria arquivos de autenticação, autorização e configuração de segurança.
4_others/ - Scripts modificados do Tomcat (startup.sh, setenv.sh), server.xml, web.xml e outras configurações no nível da aplicação. Contém um README.md documentando as modificações personalizadas do Tomcat e seus propósitos.
Artefatos em estágio:
stagedArtifacts/ - Diretório de preparação 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 do Pentaho e como prepará-lo corretamente.
db_init_postgres
A db_init_postgres/ diretório contém scripts de inicialização do PostgreSQL que criam todos os bancos de dados de repositório necessários do Pentaho. Esses scripts são montados no contêiner do PostgreSQL e executados automaticamente na primeira inicialização:
1_create_jcr_postgresql.sql - Cria o Jackrabbit Content Repository (JCR) banco de dados. O JCR armazena todo o conteúdo do Pentaho, incluindo relatórios, painéis, fontes de dados, esquemas 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 Quartz Scheduler banco de dados. 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 de 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 Hibernate Repository banco de dados. Armazena dados de autenticação de usuários, informações de autorização, funções, 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 de Integração de Dados (DI). Captura informações detalhadas de execução de ETL, incluindo logs de jobs, logs de transformações, métricas de desempenho de etapas e registros de erros. Essencial para depurar fluxos de trabalho de integração de dados e monitorar a saúde do pipeline.
5_pentaho_mart_postgresql.sql - Cria o pentaho_operations_mart schema dentro do banco de dados Hibernate. Este data mart dimensional armazena análises operacionais sobre o uso do Pentaho Server, incluindo tabelas de dimensão (DIM_DATE, DIM_TIME, DIM_EXECUTOR) e tabelas fato (FACT_EXECUTION, FACT_STEP_EXECUTION) para analisar a utilização da plataforma, tendências de desempenho e padrões de atividade do usuário.
manifests
A manifests/ diretório contém todas as definições de recursos do Kubernetes organizadas por área funcional. Esses arquivos YAML definem o estado declarativo da sua implantação no K3s:
namespace.yaml - Cria o pentaho namespace dedicado 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 da aplicação
postgres-init-scripts.yaml - ConfigMap contendo os cinco scripts de inicialização do PostgreSQL do
db_init_postgres/diretório, montado no pod do PostgreSQL
pentaho/ - Recursos Kubernetes do Pentaho Server:
deployment.yaml - Define a implantação do Pentaho Server incluindo especificações do contêiner, solicitações/limites de recursos, variáveis de ambiente, montagens de volume, probes de readiness/liveness e contagem de réplicas
service.yaml - Serviço 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 a implantação do PostgreSQL 15 com especificações do contêiner, PersistentVolumeClaims para armazenamento de dados, montagem de scripts de inicialização e configuração do banco de dados
service.yaml - Serviço ClusterIP expondo o PostgreSQL na porta 5432 dentro do cluster para conexões de banco de dados 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 para os dados do PostgreSQL (
postgres-pvc) e para as soluções/dados do Pentaho (pentaho-pvc), usando a classe de armazenamento local-path do K3s para dados persistentes entre reinicializações dos pods
ingress/ - Configuração de acesso externo:
ingress.yaml - Recurso de Ingress do Traefik definindo regras de roteamento HTTP/HTTPS externas para expor o Pentaho Server fora do cluster K3s, incluindo hostname, roteamento de caminho e configuração TLS, se aplicável
scripts
A scripts/ diretório contém utilitários de operação e manutenção para gerenciar a implantação do Pentaho no K3s:
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 do PostgreSQL. Os backups recebem timestamp e são compactados com gzip para armazenamento eficiente.
restore-postgres.sh - Utilitário de restauração de banco de dados para recuperar os bancos de dados do Pentaho a partir de arquivos de backup. Útil para recuperação de desastres, clonagem de ambiente ou migração de dados entre clusters K3s. Lida com descompactação e restauração via kubectl exec e psql.
Monitoramento e validação:
health-check.sh - Script de verificação de integridade que confirma que tanto o PostgreSQL quanto o Pentaho Server estão em execução e respondendo corretamente. Verifica o status do pod, probes de readiness e realiza testes básicos de conectividade.
monitor-resources.sh - Utilitário de monitoramento de recursos que acompanha o 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 verifica contagem de conexões com o banco, consultas ativas, tamanhos de tabelas e métricas de saúde do banco por meio de consultas SQL executadas no pod do PostgreSQL.
validate-deployment.sh - Script abrangente de validação da implantação que confirma se todos os recursos do K3s foram criados corretamente, se os pods estão em execução, se os serviços estão acessíveis, se os volumes persistentes estão vinculados e se toda a implantação está operacional.
verify-k3s.sh - Script de verificação da infraestrutura K3s que verifica a instalação do K3s, o status dos nós, as classes de armazenamento, o controlador de ingress Traefik e os componentes principais do K3s antes de tentar a implantação do Pentaho.
Principais diferenças: K3s vs Docker
Orquestração
Docker Compose
Kubernetes (K3s)
Configuração
.env arquivo + docker-compose.yml
manifests do Kubernetes (YAML)
Segredos
segredos do Docker ou Vault
Segredos do Kubernetes
Rede
rede bridge do Docker
rede do cluster K3s + Traefik Ingress
Armazenamento
volumes do Docker
PersistentVolumeClaims (PVCs)
Escalonamento
Manual (docker compose up --scale)
Declarativo (réplicas na implantação)
Verificações de integridade
HEALTHCHECK do Docker
sondas de readiness/liveness do Kubernetes
Scripts de Inicialização
Montagem de volume em /docker-entrypoint-initdb.d
ConfigMap montado no pod do PostgreSQL
Execução da implantação
A deploy.sh script automatiza todo o fluxo de trabalho:
Verifica se o K3s está em execução
Cria namespace
Aplica todos os manifestos na ordem correta
Monitora a inicialização dos pods
Valida a prontidão dos serviços
Fornece resumo da implantação com URLs de acesso
1. Criação do namespace:
Cria um ambiente lógico isolado para todos os recursos do Pentaho.
2. Geração de secrets:
Armazena as credenciais do PostgreSQL e as strings de conexão JDBC como Secrets do Kubernetes.
3. Provisionamento de armazenamento:
Cria PersistentVolumeClaims para os dados do PostgreSQL e o conteúdo do Pentaho.
4. Criação de ConfigMap:
Monta scripts de inicialização do PostgreSQL e a configuração do Pentaho.
5. Implantação do PostgreSQL:
Implanta o pod do PostgreSQL com:
Scripts de inicialização montados (criação automática do banco de dados na primeira inicialização)
Volume persistente para dados
Verificações de integridade e limites de recursos
Serviço ClusterIP para conectividade interna
6. Implantação do Pentaho Server:
Implanta o pod do Pentaho com:
Imagem Docker personalizada
Variáveis de ambiente do ConfigMap e Secrets
Montagens de volume para soluções/dados
Probes de readiness/liveness
Serviço ClusterIP
7. Configuração de ingress:
Configura o roteamento do Traefik para acesso externo.
Execute o deploy.sh

Este script unificado cuida de todo o processo 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, armazenamento)
Implantação do banco de dados PostgreSQL
Implantação do Pentaho Server
Configuração de ingress
Verificações de integridade e relatório de status
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 do containerd do K3s
Comandos rápidos com Makefile
Também há vários scripts que ajudarão a validar a implantação:
Script abrangente de validação pós-implantação que verifica se todos os componentes da implantação do Pentaho no K3s estão configurados corretamente e em execução. O que ele verifica (6 categorias)
Namespace
Verifica se o namespace pentaho existe
Pods
O pod do PostgreSQL está em execução
O pod do Pentaho Server está em execução
Mostra o status atual se não estiver em execução
Serviços
O serviço PostgreSQL existe
O serviço 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 soluções
Todos devem estar com 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-se ao pod do PostgreSQL
Testa os 3 bancos de dados do Pentaho:
* jackrabbit - repositório de conteúdo JCR
* quartz - agendador de tarefas
* hibernate - repositório de configuração
Executa a consulta SELECT 1 em cada um
Execute o seguinte
validate-deployment.shscript.

Verificação de saúde
Script rápido de verificação de saúde para uma implantação Pentaho em execução - mais rápido e leve que a validação completa, focado no status de saúde em tempo de execução.
Namespace
Verifica se o namespace pentaho existe
Encerra imediatamente se o namespace estiver ausente (crítico)
Prontidão do Pod
O pod do PostgreSQL está pronto (não apenas em execução)
O pod do Pentaho Server está pronto
Verificações
status containerStatuses[0].ready
Serviços
O serviço PostgreSQL existe
O serviço Pentaho Server existe
Conectividade com o banco de dados
O PostgreSQL está respondendo às consultas
Todos os 3 bancos de dados existem:
* jackrabbit
* quartz
* hibernate
Usa
psql -lqtpara listar os bancos de dados
Saúde da aplicação web
Teste HTTP em tempo real da página de login do Pentaho
Usa port-forward para acessar o serviço
Espera resposta HTTP 200
Testa: http://localhost:8080/pentaho/Login
Uso de recursos
Mostra uso de CPU/memória via
kubectl top podsTrata com elegância a ausência do metrics-server

Encaminhamento de porta (recomendado para teste/desenvolvimento)
O método mais simples usando kubectl para encaminhar uma porta local para o serviço Pentaho:
URL de acesso: http://localhost:8080/pentaho
Você também pode usar uma porta alternativa se a 8080 estiver ocupada:
Ingress com hostname (pentaho.local)
Usa o controlador de ingress Traefik integrado do K3s com acesso no estilo DNS:
Configuração:
(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 necessidade de DNS)
Acesse diretamente pelo endereço IP de qualquer nó do cluster sem configurar o /etc/hosts:
URL de acesso: http://<node-ip>/pentaho
Isso funciona porque o ingress inclui uma regra baseada em caminho que não requer hostname.
Comando prático do Makefile
O projeto inclui um atalho no Makefile:
Isso configura automaticamente o encaminhamento de porta para localhost:8080.
Credenciais padrão
admin
password
⚠️ Altere estas para implantações em produção!
Referência rápida
Encaminhamento de porta
Desenvolvimento/Teste
http://localhost:8080/pentaho
Ingress (hostname)
Produção com DNS
http://pentaho.local/pentaho
Ingress (IP direto)
Teste sem DNS
http://<node-ip>/pentaho
Atualizado
Isto foi útil?

