K3s
Kubernetes leve ..
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.
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.
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
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
O Pentaho Server requer três bancos de dados separados, cada um servindo a um propósito distinto:
jackrabbit
jcr_user
Java 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.
quartz
pentaho_user
Quartz 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.
hibernate
hibuser
Hibernate 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).
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.
Rede
Comunicação interna:
Ambos os pods rodam 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
Roteamento configurável por hostname e baseado em caminhos
Suporte opcional para terminação TLS/SSL
O Tomcat gerencia pools de conexão definidos em context.xml. Cada pool atende a um propósito específico:
jdbc/Hibernate
repository:5432/hibernate
Segurança, Usuários, Papéis
jdbc/Quartz
repository:5432/quartz
Agendamento de Jobs
jdbc/jackrabbit
repository:5432/jackrabbit
Repositório de Conteúdo
jdbc/Audit
repository:5432/hibernate
Logs de Auditoria
jdbc/live_logging_info
repository:5432/hibernate
Logs de Execução de ETL
jdbc/PDI_Operations_Mart
repository:5432/hibernate
Analytics de Operações
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 armazenamentoProvidencia 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
Antes de iniciar a implantação no K3s, certifique-se de ter concluído a Preparação: Contêineres Pentaho
Execute os passos a seguir para implantar o Pentaho Server em um K3s single-node com repositório PostgreSQL 15.
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
Certifique-se de ter baixado: pentaho-server-ee-11.0.0.0-237.zip
Crie o diretório & copie os ativos.
Copie o pentaho-server-ee-11.0.0.0-237.zip para o diretório /docker/stagedArtefacts.
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.
Verifique que o arquivo.
Verifique a instalação do K3s.
O Pentaho Server requer uma licença válida. O
.envarquivo 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.
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.
Diferenças-chave
Orquestração
Docker Compose
Kubernetes (K3s)
Configuração
.env arquivo + docker-compose.yml
Manifests do Kubernetes (YAML)
Secrets
Segredos Docker ou Vault
Kubernetes Secrets
Rede
Rede bridge do Docker
Rede do cluster K3s + Traefik Ingress
Armazenamento
Volumes Docker
PersistentVolumeClaims (PVCs)
Escalonamento
Manual (docker compose up --scale)
Declarativo (replicas no deployment)
Verificações de integridade
Docker HEALTHCHECK
Probes de readiness/liveness do Kubernetes
Scripts de inicialização
Montagem de volume para /docker-entrypoint-initdb.d
ConfigMap montado no pod PostgreSQL
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/.
Configurar .env
Edite o .env.template
Insira os seguintes detalhes:
PENTAHO_VERSION
11.0.0.0-237
Versão do Pentaho Server
EDITION
ee
Versão Enterprise
INCLUDE_DEMO
1
Incluir dados de demonstração
IMAGE_TAG
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
PUSH_TO REGISTRY
false
Envia diretamente ao Registro do K3s
LOAD_INTO_K3S
true
Carrega diretamente no K3s
RUN TESTS
true
LICENSE_URL
(vazio)
URL do servidor de licenças EE
Salvar:
Criar .env
softwareOverride
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.
O driver JDBC do PostgreSQL está incluído na distribuição Pentaho. Se você precisar atualizar:
Baixe de Maven Central
Coloque em
softwareOverride/1_drivers/tomcat/lib/
Ou
Copie de Workshop--Installation/'Database Drivers'/
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.
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 demo (padrão: não)
-p
--push
Enviar ao registro após o build
-h
--help
Enviar ao registro após o build
Build & Push da imagem do Pentaho Server diretamente no Registro do K3s.
1. Build da imagem Docker: A implantação usa uma imagem de contêiner do Pentaho Server construída customizada:
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:
.envo 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 numeradaDriver 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
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
Layout de diretório
Abaixo está uma explicação do diretório pentaho responsável por uma implantação via Helm.
Chart.yaml
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.
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 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.
templates
namespace.yaml
Cria um namespace Kubernetes isolado 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 bancos de dados PostgreSQL (jackrabbit, quartz, hibernate) na primeira inicialização
pvc.yaml
Solicita volumes de armazenamento persistente para dados do PostgreSQL e, opcionalmente, dados/solutions do Pentaho
*-deployment.yaml
Faz 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.yaml
Roteia 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.yaml
Roteia tráfego HTTP/HTTPS externo para o Pentaho Server via controlador de ingress Traefik
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.
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.
Verificação rápida.
Verifique se a imagem do Pentaho está disponível.
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.shscript 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ó.
Instalar usando charts Helm.
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_dumpexecutado 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 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, 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, emake destroypara gerenciamento simplificado do cluster.
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
Arquivos do Diretório Raiz
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.
docker-build
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.shapó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.
db_init_postgres
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.
manifests
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
scripts
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.
Principais Diferenças: K3s vs Docker
Orquestração
Docker Compose
Kubernetes (K3s)
Configuração
.env arquivo + docker-compose.yml
Manifests do Kubernetes (YAML)
Secrets
Segredos Docker ou Vault
Kubernetes Secrets
Rede
Rede bridge do Docker
Rede do cluster K3s + Traefik Ingress
Armazenamento
Volumes Docker
PersistentVolumeClaims (PVCs)
Escalonamento
Manual (docker compose up --scale)
Declarativo (replicas no deployment)
Verificações de integridade
Docker HEALTHCHECK
Probes de readiness/liveness do Kubernetes
Scripts de inicialização
Montagem de volume para /docker-entrypoint-initdb.d
ConfigMap montado no pod PostgreSQL
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:
Cria um ambiente lógico isolado para todos os recursos do Pentaho.
2. Geração de Secrets:
Armazena credenciais do PostgreSQL e strings de conexão JDBC como Secrets do Kubernetes.
3. Provisionamento de Armazenamento:
Cria PersistentVolumeClaims para dados do PostgreSQL e conteúdo do Pentaho.
4. Criação de ConfigMap:
Monta scripts de inicialização do PostgreSQL e configuração do Pentaho.
5. Deploy do PostgreSQL:
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:
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:
Configura o roteamento Traefik para acesso externo.
Execute o deploy.sh
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
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
Comandos Rápidos com Makefile
Também há um monte de scripts que ajudam a validar a implantação:
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
Execute o seguinte
validate-deployment.shscript.
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 -lqtpara 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: http://localhost:8080/pentaho/Login
Uso de recursos
Mostra uso de CPU/memória via
kubectl top podsTrata graciosamente a ausência do metrics-server
Encaminhamento de Porta (Recomendado para Testes/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 8080 estiver ocupada:
Ingress com nome de host (pentaho.local)
Usa o controlador ingress Traefik embutido 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 DNS)
Acesse diretamente através do IP de qualquer nó do cluster sem configurar /etc/hosts:
URL de acesso: http://<node-ip>/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:
Isto configura automaticamente o encaminhamento de porta para localhost:8080.
Credenciais padrão
admin
password
⚠️ Altere estes para implantações em produção!
Referência rápida
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://<node-ip>/pentaho
Atualizado
Isto foi útil?