K3s
Kubernetes léger ..
K3s
K3s est une distribution Kubernetes certifiée et légère conçue pour les environnements à ressources limitées, l'informatique en périphérie, les appareils IoT et les scénarios de développement. Créée par Rancher Labs (désormais partie de SUSE), elle regroupe tout le nécessaire pour exécuter Kubernetes dans un seul binaire de moins de 100 Mo.
Cela rend K3s nettement plus léger que Kubernetes standard tout en conservant une compatibilité complète avec les API et fonctionnalités Kubernetes. Il nécessite peu de mémoire (512 Mo minimum) et offre des opérations simplifiées avec des dépendances réduites.
K3s inclut des composants intégrés tels que le contrôleur d’ingress Traefik, le provisionneur de stockage local et un équilibreur de charge de service. Il est parfait pour le développement, le CI/CD, les déploiements en périphérie et les appareils ARM, tout en restant prêt pour la production avec des capacités de haute disponibilité.
Composants principaux de K3s
Composants du plan de contrôle
Le plan de contrôle inclut l’API Server (point de terminaison API Kubernetes pour la gestion du cluster), le Controller Manager (gère les boucles de contrôle principales pour la réplication, les endpoints et les namespaces) et le Scheduler (attribue les pods aux nœuds en fonction de la disponibilité des ressources).
K3s peut utiliser soit etcd soit le léger SQLite comme magasin de données pour l’état du cluster, ce qui le rend plus flexible que Kubernetes standard.
Composants des nœuds
Chaque nœud exécute l’agent Kubelet qui gère le cycle de vie des pods. Containerd est intégré en tant que runtime de conteneur pour exécuter les conteneurs.
Kube-proxy gère le proxy réseau et le réseau de services à travers le cluster.
Add-ons intégrés
K3s inclut le contrôleur d’ingress Traefik pour router le trafic HTTP/HTTPS externe vers les services. Le Local Path Provisioner permet le provisionnement dynamique de volumes persistants en utilisant le stockage local.
CoreDNS fournit le DNS du cluster pour la découverte de services. Le Service Load Balancer gère les services de type LoadBalancer sans nécessiter d’intégrations avec des fournisseurs cloud externes.
Mise en réseau
Flannel sert de plugin CNI (Container Network Interface) par défaut pour le réseau des pods. Les Network Policies contrôlent le flux de trafic entre pods et services pour renforcer la sécurité.
Pod Pentaho Server
Exécute le serveur d’applications Tomcat avec Pentaho Server 11
Construit sur Debian Trixie Slim avec OpenJDK 21 JRE
Build Docker multi-étapes pour optimiser la taille de l’image
Exposé en interne sur le port 8080
Inclut des probes de readiness et de liveness pour la surveillance de la santé
Limites de ressources configurées pour la stabilité CPU et mémoire
Fournit le backend de base de données relationnelle pour trois bases de données critiques :
Jackrabbit (jcr_user) : dépôt Java Content Repository stockant tout le contenu Pentaho (rapports, tableaux de bord, sources de données, transformations, jobs)
Quartz (pentaho_user) : scheduler gérant les jobs, triggers, calendriers et l’historique d’exécution
Hibernate (hibuser) : configuration de sécurité, journalisation d’audit, sessions utilisateur, plus deux schémas spécialisés :
pentaho_dilogs: journalisation d’exécution ETL avec logs de jobs, métriques de transformation et données de performance des étapes
pentaho_operations_mart: Data mart dimensionnel pour l’analytique de la plateforme avec tables de dimensions et de faits
Données persistées via PersistentVolumeClaim pour survivre aux redémarrages
Initialisation automatisée via scripts SQL montés depuis un ConfigMap
Pentaho Server nécessite trois bases de données distinctes, chacune ayant un rôle spécifique :
jackrabbit
jcr_user
Java Content Repository (JCR) - Stocke tout le contenu Pentaho incluant rapports, tableaux de bord, sources de données, schémas d’analyse et fichiers utilisateur. Il s’agit du stockage principal du dépôt Pentaho.
quartz
pentaho_user
Quartz Scheduler - Gère tous les jobs planifiés, déclencheurs et calendriers. Contient des tables pour les définitions de job (QRTZ6_JOB_DETAILS), les triggers (QRTZ6_TRIGGERS), l’historique d’exécution et les verrous de coordination de cluster.
hibernate
hibuser
Hibernate Repository - Héberge la configuration de sécurité, les journaux d’audit, les données de session utilisateur, et contient deux schémas additionnels : pentaho_dilogs (journalisation d’exécution ETL) et pentaho_operations_mart (data mart analytique).
La base de données hibernate contient des schémas spécialisés pour la surveillance opérationnelle :
pentaho_dilogs: Capture des informations détaillées d’exécution ETL incluant les journaux de jobs, journaux de transformations, métriques de performance des étapes et enregistrements d’erreurs. Essentiel pour le débogage des workflows d’intégration de données et la surveillance de la santé des pipelines.
pentaho_operations_mart: Un data mart dimensionnel pour l’analyse de l’utilisation de Pentaho. Contient des tables de dimensions (DIM_DATE, DIM_TIME, DIM_EXECUTOR) et des tables de faits (FACT_EXECUTION, FACT_STEP_EXECUTION) pour analyser l’utilisation de la plateforme, les tendances de performance et l’activité des utilisateurs.
Pour les déploiements en production, mettez en œuvre des sauvegardes régulières du volume Docker repository-data. La base de données jackrabbit est la plus critique car elle contient tout le contenu utilisateur. Envisagez d’utiliser pg_dump pour des sauvegardes logiques ou des snapshots de volumes pour des options de récupération complètes.
Mise en réseau
Communication interne :
Les deux pods s’exécutent au sein du
pentahonamespaceLes services ClusterIP fournissent des noms DNS internes stables
PostgreSQL accessible à
postgresql.pentaho.svc.cluster.local:5432Pentaho Server accessible à
pentaho-server.pentaho.svc.cluster.local:8080
Accès externe :
Le contrôleur d’ingress Traefik route le trafic externe vers Pentaho Server
Routage configurable par nom d’hôte et par chemin
Prise en charge optionnelle de terminaison TLS/SSL
Tomcat gère des pools de connexions définis dans context.xml. Chaque pool a un usage spécifique :
jdbc/Hibernate
repository:5432/hibernate
Sécurité, Utilisateurs, Rôles
jdbc/Quartz
repository:5432/quartz
Ordonnancement des jobs
jdbc/jackrabbit
repository:5432/jackrabbit
Dépôt de contenu
jdbc/Audit
repository:5432/hibernate
Journalisation d’audit
jdbc/live_logging_info
repository:5432/hibernate
Journaux d’exécution ETL
jdbc/PDI_Operations_Mart
repository:5432/hibernate
Analytique des opérations
Stockage
PersistentVolumeClaims (PVC) :
postgres-pvc: répertoire de données PostgreSQL (/var/lib/postgresql/data)pentaho-pvc: répertoires solutions et données Pentaho
Classe de stockage :
Utilise le
local-pathprovisionneur de stockageProvisionne les volumes sur le système de fichiers local du nœud
Création et liaison automatiques des volumes
ConfigMaps :
Scripts d’initialisation de base de données (5 fichiers SQL)
Paramètres de configuration Pentaho (paramètres JVM, réglages Tomcat)
Secrets :
Identifiants PostgreSQL (postgres_password, pentaho_user, pentaho_password)
Chaînes de connexion JDBC
Encodées en Base64 pour la sécurité
Avant de commencer le déploiement K3s, assurez-vous d’avoir complété la configuration : Conteneurs Pentaho
Parcourez les étapes suivantes pour déployer Pentaho Server sur un K3s mono-nœud avec un dépôt PostgreSQL 15.
Préparer l'environnement
La section "Préparer l’environnement" décrit les étapes d’installation initiales requises avant de déployer Pentaho Server 11 sur K3s :
copier les assets de déploiement dans votre répertoire personnel,
stager le fichier ZIP de Pentaho Server Enterprise Edition, vérifier que le fichier est en place,
confirmer que K3s est correctement installé et en cours d’exécution
Assurez-vous d’avoir téléchargé : pentaho-server-ee-11.0.0.0-237.zip
Créer le répertoire et copier les assets.
Copiez le pentaho-server-ee-11.0.0.0-237.zip dans le répertoire /docker/stagedArtefacts.
Si vous avez déjà déployé un Pentaho Server Archive, copiez depuis :
/opt/pentaho/software/pentaho-server-ee-version
Sinon, téléchargez le package depuis le Portail client Pentaho.
Vérifiez que le fichier existe.
Vérifier l’installation de K3s.
Pentaho Server requiert une licence valide. Le
.envfichier contient une LICENSE_URL pointant vers le serveur de licences Flexera. Assurez-vous que vos droits de licence sont actifs avant le déploiement.
Sans licence valide, Pentaho Server démarrera mais de nombreuses fonctionnalités seront désactivées. Vérifiez l’état de votre licence avant de procéder à des déploiements en production.
Principales différences
Orchestration
Docker Compose
Kubernetes (K3s)
Configuration
.env fichier + docker-compose.yml
manifests Kubernetes (YAML)
Secrets
secrets Docker ou Vault
Kubernetes Secrets
Mise en réseau
réseau pont Docker
réseau de cluster K3s + Ingress Traefik
Stockage
volumes Docker
PersistentVolumeClaims (PVCs)
Mise à l’échelle
Manuelle (docker compose up --scale)
Déclarative (replicas dans le deployment)
Contrôles de santé
Docker HEALTHCHECK
probes readiness/liveness Kubernetes
Scripts d’initialisation
Montage de volume vers /docker-entrypoint-initdb.d
ConfigMap monté sur le pod PostgreSQL
Tâches préalables
La section Tâches préalables décrit les étapes de préparation essentielles nécessaires avant de déployer Pentaho Server 11 dans des conteneurs K3s.
Configurer les variables d’environnement
Modifier le .env.example fichier dans le docker-build/ répertoire avec vos paramètres spécifiques au déploiement. Cela inclut l’identifiant de version Pentaho et le nom/étiquette de l’image Docker.
Configurer les identifiants de la base de données PostgreSQL et les paramètres de connexion. Définir l’allocation mémoire JVM avec un heap minimum (par défaut 4 Go) et un heap maximum (par défaut 8 Go).
Ajouter l’URL de votre serveur de licences Enterprise Edition si applicable. Configurer les options de build, y compris l’édition de l’image (EE/CE), la détection des plugins et les paramètres de push vers le registry.
Une fois configuré, copiez ce modèle vers .env pour l’utiliser lors du processus de build.
Répertoire softwareOverride
La softwareOverride/ répertoire à l’intérieur de docker-build/ fournit un mécanisme pour personnaliser les configurations Pentaho. Ces personnalisations sont intégrées dans l’image Docker pendant le processus de build.
Les fichiers sont organisés dans des répertoires numérotés et traités par ordre alphabétique.
La 1_drivers/ le répertoire contient le driver JDBC PostgreSQL (inclus par défaut) et vous pouvez y placer des drivers JDBC supplémentaires.
La 2_repository/ le répertoire contient les configurations de connexion aux bases de données pour Jackrabbit (JCR), Quartz (scheduler) et Hibernate. Le 3_security/ répertoire est vide dans ce déploiement K3s puisqu’il n’y a pas d’intégration Vault.
La 4_others/ le répertoire contient des scripts Tomcat modifiés (startup.sh, setenv.sh), server.xml et d’autres configurations au niveau application.
Vous pouvez éventuellement mettre à niveau le driver JDBC PostgreSQL en le téléchargeant depuis Maven Central ou en le copiant depuis la collection de drivers de la workshop. Placez le driver mis à jour dans softwareOverride/1_drivers/tomcat/lib/.
Configurer .env
Éditez le .env.template
Saisissez les détails suivants :
PENTAHO_VERSION
11.0.0.0-237
Version de Pentaho Server
EDITION
ee
Version Enterprise
INCLUDE_DEMO
1
Inclure des données de démonstration
IMAGE_TAG
pentaho/pentaho-server:11.0.0.0-237
Tag de l’image Docker
PENTAHO_MIN_MEMORY
4096m
Taille minimale du heap JVM
PENTAHO_MAX_MEMORY
8192m
Taille maximale du heap JVM
PENTAHO_DI_JAVA_OPTIONS
"-Dfile.encoding=utf8 -Djava.awt.headless=true"
PENTAHO_IMAGE_NAME
pentaho/pentaho-server
Nom de l’image Docker
TZ
America/NY
Fuseau horaire du serveur
DB_TYPE
postgres
DB_HOST
postgres
DB_PORT
5432
Port HTTP de PostgreSQL
PUSH_TO REGISTRY
false
Pousse directement vers le registry K3s
LOAD_INTO_K3S
true
Charge directement dans K3s
RUN TESTS
true
LICENSE_URL
(vide)
URL du serveur de licences EE
Enregistrer :
Créer .env
softwareOverride
La softwareOverride/ Le répertoire fournit un mécanisme puissant pour personnaliser Pentaho Server sans modifier l'installation principale. Les fichiers sont copiés dans l'installation Pentaho lors du démarrage du conteneur, traités par ordre alphabétique des noms de répertoires.
Le pilote JDBC PostgreSQL est inclus dans la distribution Pentaho. Si vous devez le mettre à jour :
Télécharger depuis Maven Central
Placer dans
softwareOverride/1_drivers/tomcat/lib/
Ou
Copier depuis Workshop--Installation/'Database Drivers'/
Construire et pousser l’image Pentaho
Le script build.sh est un wrapper de build automatisé qui :
Valide les prérequis - Vérifie que Docker est installé
Vérifie les fichiers requis - Vérifie que le ZIP Pentaho existe dans stagedArtifacts/
Détecte automatiquement les plugins - Trouve les plugins PAZ, PIR, PDD
Confirme le build - Montre ce qui sera construit et demande confirmation
Exécute docker build - Lance la construction avec les arguments appropriés
Affiche les informations d’image - Montre la taille et les détails de l’image après la construction
Optionnel : teste l’image - Exécute un test de conteneur basique (vous pouvez l’ignorer)
Optionnel : pousse vers le registry - Pousse vers le registry Docker (uniquement avec le flag -p)
Ceci est l’ approche recommandée pour construire les images Docker Pentaho. Elle utilise un seul .env fichier pour tout configurer - similaire au déploiement Docker Compose.
Vous pouvez modifier le build avec les options suivantes :
-v
--version VERSION
Version Pentaho (par défaut : 11.0.0.0-237)
-t
--tag TAG
Étiquette d’image Docker (par défaut : pentaho/pentaho-server:VERSION)
-e
--edition EDITION
ee ou ce (par défaut : ee)
-d
--demo
Inclure le contenu démo (par défaut : non)
-p
--push
Pousser vers le registry après la construction
-h
--help
Pousser vers le registry après la construction
Construire et pousser l’image du Pentaho Server directement dans le registry K3s.
1. Construction de l’image Docker : Le déploiement utilise une image de conteneur Pentaho Server construite sur mesure :
La build.sh script :
Valide les prérequis et les fichiers requis
Détecte automatiquement les plugins (PAZ, PIR, PDD)
Exécute la construction Docker multi-étapes
Pousse éventuellement vers le store d’images K3s
2. Gestion de la configuration :
.envle fichier contient les paramètres spécifiques au déploiement (versions, identifiants, mémoire JVM)softwareOverride/le répertoire fournit des surcouches de configuration traitées par ordre numérotéDriver JDBC PostgreSQL inclus par défaut, avec option de mise à niveau
Scripts Tomcat personnalisés pour optimiser le démarrage du conteneur
Charts Helm
Helm est le gestionnaire de paquets pour Kubernetes, souvent appelé « apt/yum pour Kubernetes ». Il simplifie le déploiement et la gestion des applications Kubernetes en :
Packaging: Regroupant les ressources Kubernetes associées
Templating: Paramétrant les manifests pour réutilisabilité entre environnements
Versioning: Gérant les versions d’application et les mises à niveau
Gestion des releases: Suivant les déploiements et permettant les rollbacks
Structure des répertoires
Ci-dessous une explication du répertoire pentaho responsable d’un déploiement Helm.
Chart.yaml
Ce fichier définit l’identité du chart, sa version et les métadonnées utilisées par Helm.
Il sert de « définition de package » pour le chart Helm, similaire à package.json (npm) ou Chart.lock (dépendances Helm).
Rôle : Chart.yaml indique à Helm ce qu’est ce chart, quelle est sa version, quelle application il déploie, et fournit des métadonnées consultables pour les dépôts de charts.
Helm utilise ce fichier pour suivre les versions du chart, gérer les dépendances et afficher des informations lorsque les utilisateurs recherchent ou installent des charts.
values.yaml
Dans un déploiement K3s (Kubernetes léger), le values.yaml fichier sert de fichier de configuration central pour les charts Helm. Il définit les paramètres et réglages par défaut qui personnalisent la manière dont une application ou un service est déployé sur le cluster - des éléments comme le nombre de réplicas, les versions d’images, les limites de ressources, les types de services, les règles d’ingress, les variables d’environnement et les configurations de stockage persistant.
Lorsque vous exécutez helm install ou helm upgrade, Helm fusionne les valeurs de ce fichier avec les templates du chart pour générer les manifests Kubernetes finaux. Vous pouvez remplacer des valeurs spécifiques au moment du déploiement en utilisant --set flags ou en fournissant un fichier values personnalisé avec -f, ce qui en fait un mécanisme flexible pour gérer des configurations spécifiques à l’environnement (ex. dev vs production) sans modifier les templates de chart sous-jacents.
templates
namespace.yaml
Crée un namespace Kubernetes isolé pour contenir toutes les ressources Pentaho
secret.yaml
Stocke les identifiants sensibles de base de données (mots de passe) chiffrés dans Kubernetes
config-*.yaml
Configure les variables d’environnement Pentaho (mémoire JVM, paramètres base de données, chemins, timezone) Contient des scripts SQL pour initialiser les bases PostgreSQL (jackrabbit, quartz, hibernate) au premier démarrage
pvc.yaml
Demande des volumes de stockage persistants pour les données PostgreSQL et, en option, les données/solutions Pentaho
*-deployment.yaml
Déploie le Pentaho Business Analytics Server avec init container, probes de santé et limites de ressources. Déploie le serveur PostgreSQL 15 avec initialisation automatique et stockage persistant
*-service.yaml
Route le trafic HTTP/HTTPS externe vers Pentaho Server via le contrôleur d’ingress Traefik. Expose le port PostgreSQL 5432 comme point DNS stable pour que Pentaho s’y connecte.
ingress.yaml
Route le trafic HTTP/HTTPS externe vers Pentaho Server via le contrôleur d’ingress Traefik
Déployer
L’architecture consiste en deux pods principaux s’exécutant dans un namespace Pentaho dédié :
un pod Pentaho Server (Tomcat sur Debian avec OpenJDK 21) et
un pod PostgreSQL hébergeant trois bases essentielles - Jackrabbit pour le stockage de contenu, Quartz pour la planification des jobs, et Hibernate pour la sécurité et la journalisation d’audit.
Avant de poursuivre, assurez-vous d’avoir complété les étapes 1 à 3. Vous devez avoir une image Pentaho Server + images du dépôt PostgreSQL 15 poussées vers le repository K3s.
Vérification rapide.
Vérifier que l’image Pentaho est disponible.
Déploiement par défaut
Le workflow de déploiement progresse selon quatre étapes :
préparer l’environnement en mettant en scène le package Pentaho Enterprise Edition et en vérifiant K3s.
configurer les variables d’environnement et les surcouches logicielles pendant les tâches préalables.
construire et pousser une image Docker personnalisée dans le runtime de conteneurs K3s.
pour enfin déployer la pile complète en utilisant soit des charts Helm soit un
deploy.shscript automatisé qui orchestre la création du namespace, les secrets, les ConfigMaps, le stockage persistant et le routage ingress Traefik.
Couvre également la structure du chart Helm, une suite de scripts d’aide pour la sauvegarde, les vérifications de santé, la surveillance des ressources et la validation du déploiement, ainsi que plusieurs méthodes d’accès incluant le port-forwarding, l’ingress basé sur le hostname et l’IP directe du nœud.
Installer en utilisant les charts Helm.
Scripts d’aide
Le déploiement K3s Pentaho inclut une collection de scripts d’aide dans le répertoire scripts/ pour les opérations et la maintenance quotidiennes :
backup-postgres.sh : Crée des dumps compressés horodatés de toutes les bases Pentaho (Jackrabbit, Quartz, Hibernate) en utilisant
pg_dumpexécuté à l’intérieur du pod PostgreSQL.restore-postgres.sh : Restaure les bases Pentaho à partir de fichiers de sauvegarde, utile pour la reprise après sinistre, le clonage d’environnements ou la migration de données entre clusters.
health-check.sh : Effectue un contrôle de santé rapide à l’exécution couvrant la readiness des pods, la disponibilité des services, la connectivité de la base de données et un test HTTP en direct contre la page de connexion Pentaho.
validate-deployment.sh : Exécute un audit complet sur six catégories : namespace, pods, services, PersistentVolumeClaims, ConfigMaps et configuration d’ingress.
monitor-resources.sh : Suit l’utilisation CPU et mémoire de tous les pods Pentaho en utilisant
kubectl toppour aider à identifier les contraintes de ressources ou des opportunités d’optimisation.monitor-postgres.sh : Surveille les métriques spécifiques à PostgreSQL incluant le nombre de connexions, les requêtes actives, la taille des tables et la santé générale de la base de données.
verify-k3s.sh : Valide l’infrastructure K3s sous-jacente (statut des nœuds, classes de stockage, ingress Traefik et composants principaux) avant d’essayer un déploiement Pentaho.
Makefile : Fournit des commandes utilitaires telles que
make health,make status,make logs,make port-forward, etmake destroypour une gestion simplifiée du cluster.
Structure des répertoires
Cette configuration de déploiement K3s fournit plusieurs capacités importantes :
Déploiement Kubernetes complètement autonome sur K3s léger
Initialisation automatique des bases de données avec des scripts SQL PostgreSQL
Contrôles de santé natifs Kubernetes et ordonnancement de démarrage
Persistent volume claims pour la base de données et le contenu Pentaho
Processus de build d’image Docker avec optimisation multi-étapes
Limites de ressources (CPU/mémoire) pour la stabilité
Templates de manifests Kubernetes prêts pour la production
Pilote JDBC PostgreSQL inclus
Procédures faciles de sauvegarde et restauration via des scripts utilitaires
Configuration d’ingress pour le routage Traefik
Fichiers du répertoire racine
Fichiers de documentation :
README.md - La documentation d’entrée principale fournissant une vue d’ensemble du projet, des instructions de démarrage rapide, les prérequis et des informations d’utilisation générales pour l’atelier de déploiement K3s.
DEPLOYMENT.md - Guide de déploiement détaillé couvrant le workflow complet de déploiement K3s, y compris les prérequis, les instructions étape par étape et les procédures de vérification post-déploiement.
K3s-INSTALLATION.md - Instructions de configuration et d’installation de K3s couvrant la préparation du système, l’installation de K3s, la configuration réseau et la configuration de la classe de stockage requises avant de déployer Pentaho.
Orchestration et déploiement :
deploy.sh - Script de déploiement automatisé qui orchestre le workflow complet de déploiement K3s incluant la création de namespace, la génération de secrets, l’application des manifests et les vérifications de disponibilité des services.
destroy.sh - Script de nettoyage qui supprime en toute sécurité toutes les ressources K3s incluant déploiements, services, PersistentVolumeClaims et namespaces, utile pour les scénarios de redéploiement ou de démontage.
Makefile - Contient des cibles de commandes pratiques pour les opérations K3s courantes comme déployer, détruire, vérifier le statut et consulter les logs. Les utilisateurs peuvent exécuter make help pour voir toutes les commandes disponibles.
docker-build
La docker-build/ le répertoire contient tous les composants nécessaires pour construire l’image du conteneur Pentaho Server qui sera déployée sur K3s :
Fichiers de documentation :
README.md - Documentation complète du build couvrant le processus de construction de l’image Docker, l’architecture du build multi-étapes, les options de configuration, le dépannage et les bonnes pratiques pour construire des images Pentaho Server pour le déploiement K3s.
QUICK-START.md - Guide de build rapide fournissant des instructions étape par étape pour les utilisateurs qui souhaitent construire et tester rapidement l’image Pentaho sans lire la documentation complète. Inclut les commandes de build courantes et les flux de travail typiques.
ENV-CONFIGURATION.md - Guide de référence de configuration complet pour le .env.example fichier, détaillant toutes les variables d'environnement disponibles, leurs objectifs, valeurs par défaut, et comment elles affectent le processus de build Docker et l'image résultante.
Fichiers de build et de configuration :
build.sh - Script wrapper de build automatisé qui valide les prérequis, vérifie la présence des fichiers requis (ZIP Pentaho dans stagedArtifacts/), détecte automatiquement les plugins (PAZ, PIR, PDD), confirme le build avec l'utilisateur, exécute docker build, affiche les informations de l'image après le build, et pousse éventuellement vers un registre avec le -p paramètre.
.env.example - Fichier modèle de configuration contenant toutes les variables d'environnement disponibles pour le processus de build Docker. Les utilisateurs copient ceci vers .env et personnalisent les valeurs pour leurs besoins de déploiement spécifiques, y compris la version de Pentaho, les tags d'image et les options de build.
Dockerfile - Définition de build multi-étapes utilisant debian:trixie-slim comme image de base avec OpenJDK 21 JRE. Crée des images optimisées en séparant l'environnement de build de l'environnement runtime, réduisant la taille finale de l'image tout en conservant tous les composants Pentaho nécessaires. L'approche multi-étapes minimise les vulnérabilités de sécurité et améliore l'efficacité du build.
test-compose.yml - Environnement local de test Docker Compose qui vous permet de tester l'image Docker construite localement avant de déployer sur K3s. Utile pour valider des changements de configuration, tester des plugins personnalisés ou déboguer des problèmes de démarrage sans la surcharge d'un déploiement K3s complet.
Scripts de démarrage du conteneur :
entrypoint/ - Répertoire contenant les scripts d'initialisation et de démarrage du conteneur :
docker-entrypoint.sh - Script principal de démarrage du conteneur qui s'exécute lorsque le conteneur démarre. Gère le traitement des variables d'environnement, la personnalisation des fichiers de configuration depuis
softwareOverride/, la validation des connexions à la base de données, les vérifications d'état, et orchestre la séquence de démarrage du serveur Pentaho.start-pentaho-docker.sh - Script de démarrage spécifique à Pentaho qui gère l'initialisation de Tomcat, la configuration de la JVM, les paramètres mémoire, et démarre les services du serveur Pentaho. Ce script est appelé par
docker-entrypoint.shaprès que la préparation de l'environnement soit terminée.
Superpositions de configuration :
softwareOverride/ - Répertoire des overlays de configuration qui est intégré à l'image Docker pendant le processus de build. Les fichiers sont organisés dans des répertoires numérotés et traités par ordre alphabétique pour garantir la séquence d'application correcte :
1_drivers/ - Pilote JDBC PostgreSQL (inclus par défaut) pour la connectivité à la base de données. Des pilotes JDBC supplémentaires ou des connecteurs de données peuvent être placés ici.
2_repository/ - Configurations de connexion aux bases de données pour tous les dépôts Pentaho incluant Jackrabbit (JCR), Quartz (planificateur) et Hibernate (sécurité/audit). Contient un README.md expliquant les fichiers de configuration des dépôts et leurs objectifs.
3_security/ - Vide dans ce déploiement K3s car l'intégration HashiCorp Vault n'est pas utilisée. Dans des environnements de production, cela contiendrait des fichiers de configuration d'authentification, d'autorisation et de sécurité.
4_others/ - Scripts Tomcat modifiés (startup.sh, setenv.sh), server.xml, web.xml et autres configurations au niveau de l'application. Contient un README.md documentant les modifications personnalisées de Tomcat et leurs objectifs.
Artefacts mis en scène :
stagedArtifacts/ - Répertoire de staging où les utilisateurs placent le paquet d'installation du serveur Pentaho (pentaho-server-ee-11.0.0.0-237.zip) avant de construire l'image Docker. Contient un README.md avec des instructions sur où obtenir le paquet Pentaho et comment le mettre en scène correctement.
db_init_postgres
La db_init_postgres/ le répertoire contient des scripts d'initialisation PostgreSQL qui créent toutes les bases de données de dépôt Pentaho requises. Ces scripts sont montés dans le conteneur PostgreSQL et s'exécutent automatiquement au premier démarrage :
1_create_jcr_postgresql.sql - Crée le Jackrabbit Content Repository (JCR) base de données. Le JCR stocke tout le contenu Pentaho incluant rapports, tableaux de bord, sources de données, schémas d'analyse, transformations, jobs et fichiers utilisateur. C'est le système principal de gestion de contenu pour le dépôt Pentaho.
2_create_quartz_postgresql.sql - Met en place le Quartz Scheduler base de données. Quartz gère tous les jobs planifiés, triggers et calendriers au sein du serveur Pentaho, y compris les plannings de génération de rapports, les exécutions de jobs ETL et autres processus automatisés. Contient des tables critiques comme QRTZ6_JOB_DETAILS, QRTZ6_TRIGGERS, et l'historique d'exécution.
3_create_repository_postgresql.sql - Crée le Hibernate Repository base de données. Celle-ci stocke les données d'authentification des utilisateurs, les informations d'autorisation, les rôles, les permissions et autres informations liées à la sécurité gérées par le sous-système de sécurité de Pentaho.
4_pentaho_logging_postgresql.sql - Établit le pentaho_dilogs schéma dans la base de données Hibernate pour l'audit et la journalisation de l'Intégration de Données (DI). Capture des informations détaillées d'exécution ETL incluant les logs de job, logs de transformation, métriques de performance des étapes et enregistrements d'erreurs. Essentiel pour déboguer les workflows d'intégration de données et surveiller la santé des pipelines.
5_pentaho_mart_postgresql.sql - Crée le pentaho_operations_mart schéma dans la base de données Hibernate. Ce data mart dimensionnel stocke des analyses opérationnelles sur l'utilisation du serveur Pentaho, incluant des tables de dimensions (DIM_DATE, DIM_TEMPS, DIM_EXECUTOR) et des tables de faits (FACT_EXECUTION, FACT_STEP_EXECUTION) pour analyser l'utilisation de la plateforme, les tendances de performance et les modèles d'activité des utilisateurs.
manifests
La manifests/ le répertoire contient toutes les définitions de ressources Kubernetes organisées par domaine fonctionnel. Ces fichiers YAML définissent l'état déclaratif de votre déploiement K3s :
namespace.yaml - Crée le pentaho namespace dédié pour isoler toutes les ressources liées à Pentaho des autres charges de travail K3s, offrant une séparation logique et une organisation des ressources.
configmaps/ - Ressources ConfigMap pour les données de configuration non sensibles :
pentaho-config.yaml - Paramètres de configuration du serveur Pentaho tels que paramètres JVM, paramètres Tomcat et propriétés applicatives
postgres-init-scripts.yaml - ConfigMap contenant les cinq scripts d'initialisation PostgreSQL du répertoire
db_init_postgres/monté dans le pod PostgreSQL
pentaho/ - Ressources Kubernetes pour le serveur Pentaho :
deployment.yaml - Définit le déploiement du serveur Pentaho incluant les spécifications du conteneur, les demandes/limites de ressources, les variables d'environnement, les montages de volumes, les probes de readiness/liveness et le nombre de réplicas
service.yaml - Service ClusterIP exposant le serveur Pentaho sur le port 8080 au sein du cluster, fournissant un DNS interne stable et de l'équilibrage de charge
postgres/ - Ressources Kubernetes pour la base de données PostgreSQL :
deployment.yaml - Définit le déploiement PostgreSQL 15 avec les spécifications du conteneur, les PersistentVolumeClaims pour le stockage des données, le montage des scripts d'initialisation et la configuration de la base de données
service.yaml - Service ClusterIP exposant PostgreSQL sur le port 5432 au sein du cluster pour les connexions de la base de données Pentaho
secrets/ - Stockage des identifiants sensibles :
secrets.yaml - Ressource Secret Kubernetes contenant des identifiants encodés en base64 pour PostgreSQL (
postgres_password,pentaho_user,pentaho_password) et les chaînes de connexion JDBC. Ce fichier est ignoré par git pour des raisons de sécurité.
storage/ - Définitions de stockage persistant :
pvc.yaml - Définitions de PersistentVolumeClaim pour les données PostgreSQL (
postgres-pvc) et les solutions/données Pentaho (pentaho-pvc), utilisant la classe de stockage local-path de K3s pour des données persistantes entre redémarrages de pods
ingress/ - Configuration d'accès externe :
ingress.yaml - Ressource Ingress Traefik définissant des règles de routage HTTP/HTTPS externes pour exposer le serveur Pentaho en dehors du cluster K3s, incluant le nom d'hôte, le routage par chemin et la configuration TLS si applicable
scripts
La scripts/ le répertoire contient des utilitaires opérationnels et de maintenance pour gérer le déploiement Pentaho sur K3s :
Gestion de la base de données :
backup-postgres.sh - Utilitaire automatisé de sauvegarde PostgreSQL qui crée des dumps compressés de toutes les bases Pentaho (jackrabbit, quartz, hibernate) en utilisant kubectl exec pour exécuter pg_dump à l'intérieur du pod PostgreSQL. Les sauvegardes sont horodatées et compressées avec gzip pour un stockage efficace.
restore-postgres.sh - Utilitaire de restauration de base de données pour récupérer les bases Pentaho à partir de fichiers de sauvegarde. Utile pour la reprise après sinistre, le clonage d'environnements ou la migration de données entre clusters K3s. Gère la décompression et la restauration via kubectl exec et psql.
Surveillance et validation :
health-check.sh - Script de vérification d'état qui vérifie que PostgreSQL et le serveur Pentaho sont tous deux en cours d'exécution et répondent correctement. Vérifie le statut des pods, les probes de readiness, et effectue des tests de connectivité de base.
monitor-resources.sh - Utilitaire de surveillance des ressources qui suit l'utilisation CPU, mémoire et stockage sur tous les pods Pentaho en utilisant kubectl top et les métriques de ressources, aidant à identifier les contraintes de ressources ou les opportunités d'optimisation.
monitor-postgres.sh - Script de surveillance spécifique à PostgreSQL qui vérifie le nombre de connexions à la base, les requêtes actives, la taille des tables et les métriques de santé de la base via des requêtes SQL exécutées dans le pod PostgreSQL.
validate-deployment.sh - Script complet de validation du déploiement qui confirme que toutes les ressources K3s sont correctement créées, que les pods fonctionnent, que les services sont accessibles, que les volumes persistants sont liés, et que l'ensemble du déploiement est opérationnel.
verify-k3s.sh - Script de vérification de l'infrastructure K3s qui contrôle l'installation de K3s, le statut des nœuds, les classes de stockage, le contrôleur d'ingress Traefik, et les composants K3s de base avant de tenter le déploiement de Pentaho.
Différences clés : K3s vs Docker
Orchestration
Docker Compose
Kubernetes (K3s)
Configuration
.env fichier + docker-compose.yml
manifests Kubernetes (YAML)
Secrets
secrets Docker ou Vault
Kubernetes Secrets
Mise en réseau
réseau pont Docker
réseau de cluster K3s + Ingress Traefik
Stockage
volumes Docker
PersistentVolumeClaims (PVCs)
Mise à l’échelle
Manuelle (docker compose up --scale)
Déclarative (replicas dans le deployment)
Contrôles de santé
Docker HEALTHCHECK
probes readiness/liveness Kubernetes
Scripts d’initialisation
Montage de volume vers /docker-entrypoint-initdb.d
ConfigMap monté sur le pod PostgreSQL
Exécution du déploiement
La deploy.sh le script automatise l'ensemble du workflow :
Vérifie que K3s est en cours d'exécution
Crée le namespace
Applique tous les manifests dans le bon ordre
Surveille le démarrage des pods
Valide la disponibilité des services
Fournit un résumé du déploiement avec les URL d'accès
1. Création du namespace :
Crée un environnement logique isolé pour toutes les ressources Pentaho.
2. Génération des secrets :
Stocke les identifiants PostgreSQL et les chaînes de connexion JDBC en tant que Secrets Kubernetes.
3. Provisionnement du stockage :
Crée des PersistentVolumeClaims pour les données PostgreSQL et le contenu Pentaho.
4. Création des ConfigMaps :
Monte les scripts d'initialisation PostgreSQL et la configuration Pentaho.
5. Déploiement PostgreSQL :
Déploie le pod PostgreSQL avec :
Scripts d'init montés (création automatique des bases au premier démarrage)
Volume persistant pour les données
Vérifications d'état et limites de ressources
Service ClusterIP pour la connectivité interne
6. Déploiement du serveur Pentaho :
Déploie le pod Pentaho avec :
Image Docker personnalisée
Variables d'environnement depuis ConfigMap et Secrets
Montages de volumes pour solutions/données
Probes de readiness/liveness
Service ClusterIP
7. Configuration de l'Ingress :
Configure le routage Traefik pour l'accès externe.
Exécutez le deploy.sh
Ce script unifié gère le processus complet de déploiement du serveur Pentaho sur K3s, incluant :
Import d'image Docker dans le runtime de conteneurs K3s
Création des ressources Kubernetes (namespace, secrets, configmaps, storage)
Déploiement de la base de données PostgreSQL
Déploiement du serveur Pentaho
Configuration de l'ingress
Vérifications d'état et rapports de statut
Prérequis :
K3s installé et en cours d'exécution
Image Docker construite : pentaho/pentaho-server:11.0.0.0-237
kubectl configuré pour accéder au cluster K3s
Accès sudo pour les opérations containerd de K3s
Commandes rapides avec Makefile
Il y a aussi plusieurs scripts qui aideront à valider le déploiement :
Script complet de validation post-déploiement qui vérifie que tous les composants du déploiement Pentaho sur K3s sont correctement configurés et en cours d'exécution. Ce qu'il vérifie (6 catégories)
Namespace
Vérifie que le namespace pentaho existe
Pods
Le pod PostgreSQL est en Running
Le pod du serveur Pentaho est en Running
Affiche le statut actuel s'il n'est pas en cours d'exécution
Services
Le service PostgreSQL existe
Le service du serveur Pentaho existe
PersistentVolumeClaims (3 PVCs)
postgres-data-pvc (10Gi) - Fichiers de base de données
pentaho-data-pvc (10Gi) - Pentaho
data pentaho-solutions-pvc (5Gi) - Dépôt de solutions
Tous doivent être en statut "Bound"
ConfigMaps
pentaho-config - Variables d'environnement
postgres-init - Scripts d'initialisation de la base de données
Ingress
pentaho-ingress - Configuration de routage Traefik
Tests de connectivité à la base de données
Se connecte au pod PostgreSQL
Teste les 3 bases Pentaho :
* jackrabbit - dépôt de contenu JCR
* quartz - planificateur de jobs
* hibernate - dépôt de configuration
Exécute une requête SELECT 1 sur chacune
Exécutez le script suivant
validate-deployment.sh.
Vérification d'état
Script de vérification d'état rapide pour un déploiement Pentaho en cours d'exécution - plus rapide et plus léger que la validation complète, axé sur l'état de santé runtime.
Namespace
Vérifie que le namespace pentaho existe
Quitte immédiatement si le namespace est manquant (critique)
Disponibilité des pods
Le pod PostgreSQL est prêt (pas seulement en cours d'exécution)
Le pod du serveur Pentaho est prêt
Vérifications
statut containerStatuses[0].ready
Services
Le service PostgreSQL existe
Le service du serveur Pentaho existe
Connectivité à la base de données
PostgreSQL répond aux requêtes
Les 3 bases existent :
* jackrabbit
* quartz
* hibernate
Utilise
psql -lqtpour lister les bases de données
Santé de l'application Web
Test HTTP en direct vers la page de connexion Pentaho
Utilise port-forward pour accéder au service
Attend une réponse HTTP 200
Tests : http://localhost:8080/pentaho/Login
Utilisation des ressources
Affiche l'utilisation CPU/mémoire via
kubectl top podsGère gracieusement l'absence de metrics-server
Port Forward (recommandé pour tests/développement)
La méthode la plus simple utilisant kubectl pour rediriger un port local vers le service Pentaho :
URL d'accès : http://localhost:8080/pentaho
Vous pouvez aussi utiliser un port alternatif si 8080 est occupé :
Ingress avec nom d'hôte (pentaho.local)
Utilise le contrôleur d'ingress Traefik intégré à K3s avec un accès de type DNS :
Configuration :
(Remplacez 10.0.0.1 par l'IP réelle de votre nœud)
URL d'accès : http://pentaho.local/pentaho
Ingress via IP directe du nœud (pas de DNS requis)
Accédez directement via l'IP de n'importe quel nœud du cluster sans configurer /etc/hosts :
URL d'accès : http://<node-ip>/pentaho
Cela fonctionne parce que l'ingress inclut une règle basée sur le chemin qui ne nécessite pas de nom d'hôte.
Commande pratique dans le Makefile
Le projet inclut un raccourci Makefile :
Ceci configure automatiquement le port forwarding vers localhost:8080.
Identifiants par défaut
admin
password
⚠️ Changez-les pour les déploiements en production !
Référence rapide
Port Forward
Développement/Test
http://localhost:8080/pentaho
Ingress (nom d'hôte)
Production avec DNS
http://pentaho.local/pentaho
Ingress (IP directe)
Test sans DNS
http://<node-ip>/pentaho
Mis à jour
Ce contenu vous a-t-il été utile ?