> For the complete documentation index, see [llms.txt](https://academy.pentaho.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-fr/installation/containers/k3s.md). # K3s {% hint style="info" %} #### K3s K3s est une distribution Kubernetes légère et certifiée, conçue pour les environnements à ressources limitées, l’edge computing, les appareils IoT et les scénarios de développement. Créé par Rancher Labs (désormais partie de SUSE), il regroupe tout ce qui est 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é totale avec les API et les fonctionnalités de Kubernetes. Il nécessite très peu de mémoire (512 Mo minimum) et offre des opérations simplifiées avec moins de dépendances. K3s est livré avec des composants intégrés comme le contrôleur d’ingress Traefik, le provisionneur de stockage local et le répartiteur de charge de service. Il est parfait pour le développement, la 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é. {% endhint %}

Architecture du serveur K3s et Pentaho

{% tabs %} {% tab title="Composants principaux de K3s" %} {% hint style="info" %} #### Composants principaux de K3s **Composants du plan de contrôle** Le plan de contrôle comprend le serveur API (point de terminaison de l’API Kubernetes pour la gestion du cluster), le gestionnaire de contrôleurs (gère les boucles de contrôle principales pour la réplication, les endpoints et les namespaces) et le planificateur (attribue les pods aux nœuds en fonction de la disponibilité des ressources). K3s peut utiliser soit etcd soit SQLite, plus léger, 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é comme moteur d’exécution des conteneurs. Kube-proxy gère le proxy réseau et la mise en réseau des services dans l’ensemble du cluster. **Compléments 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 à l’aide du stockage local. CoreDNS fournit le DNS du cluster pour la découverte des services. Le répartiteur de charge de service gère les services de type LoadBalancer sans nécessiter d’intégrations externes avec un fournisseur cloud. **Mise en réseau** Flannel sert de plugin CNI (Container Network Interface) par défaut pour la mise en réseau des pods. Les politiques réseau contrôlent le flux de trafic entre les pods et les services pour une sécurité renforcée. {% endhint %}

Composants K3s

{% endtab %} {% tab title="Pod du serveur Pentaho" %} {% hint style="info" %} #### Pod du serveur Pentaho * 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 une taille d’image optimisée * Exposé en interne sur le port 8080 * Inclut des sondes de readiness et de liveness pour la surveillance de l’état * Limites de ressources configurées pour la stabilité du CPU et de la mémoire {% endhint %}

Pod Pentaho

{% endtab %} {% tab title="Pod PostgreSQL" %} {% hint style="info" %} Fournit le backend de base de données relationnelle pour trois bases de données critiques : * **Jackrabbit** (jcr\_user) : Java Content Repository stockant tout le contenu Pentaho (rapports, tableaux de bord, sources de données, transformations, tâches) * **Quartz** (pentaho\_user) : Planificateur gérant les tâches, les déclencheurs, les 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 de l’exécution ETL avec les journaux des tâches, les métriques de transformation et les données de performance des étapes * **pentaho\_operations\_mart**: data mart dimensionnel pour l’analytique de la plateforme avec des tables de dimensions et de faits * Données conservées via PersistentVolumeClaim pour survivre aux redémarrages * Initialisation automatisée via des scripts SQL montés depuis ConfigMap {% endhint %}

Pod PostgreSQL

Architecture de la base de données PostgreSQL

Pentaho Server requiert trois bases de données distinctes, chacune remplissant un rôle spécifique :
Base de donnéesPropriétaireObjectif et contenu
jackrabbitjcr_userJava Content Repository (JCR) - Stocke tout le contenu Pentaho, y compris les rapports, tableaux de bord, sources de données, schémas d’analyse et fichiers utilisateurs. Il s’agit du stockage principal du contenu pour le référentiel Pentaho.
quartzpentaho_userQuartz Scheduler - Gère toutes les tâches planifiées, les déclencheurs et les calendriers. Contient les tables pour les définitions de tâches (QRTZ6_JOB_DETAILS), les déclencheurs (QRTZ6_TRIGGERS), l’historique d’exécution et les verrous de coordination du cluster.
hibernatehibuserHibernate Repository - Héberge la configuration de sécurité, la journalisation d’audit, les données de session utilisateur et contient deux schémas supplémentaires : pentaho_dilogs (journalisation de l’exécution ETL) et pentaho_operations_mart (datamart analytique).
{% hint style="info" %} La base de données hibernate contient des schémas spécialisés pour la supervision opérationnelle : **pentaho\_dilogs**: Capture des informations détaillées sur l’exécution ETL, notamment les journaux des tâches, les journaux de transformation, les métriques de performance des étapes et les enregistrements d’erreurs. Indispensable pour déboguer les workflows d’intégration de données et surveiller l’état du pipeline. **pentaho\_operations\_mart**: Un datamart dimensionnel pour l’analytique sur l’utilisation de Pentaho. Contient des tables de dimension (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 place 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 instantanés de volume pour des options de restauration complètes. {% endhint %} {% endtab %} {% tab title="Réseau" %} {% hint style="info" %} #### Mise en réseau **Communication interne :** * Les deux pods s’exécutent dans le `pentaho` namespace * Les services ClusterIP fournissent des noms DNS internes stables * PostgreSQL accessible à `postgresql.pentaho.svc.cluster.local:5432` * Pentaho 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 * Nom d’hôte configurable et routage basé sur le chemin * Prise en charge facultative de la terminaison TLS/SSL {% endhint %} Tomcat gère les pools de connexions définis dans context.xml. Chaque pool a un objectif spécifique :
Nom du poolCible de connexionUtilisé pour
jdbc/Hibernaterepository:5432/hibernateSécurité, utilisateurs, rôles
jdbc/Quartzrepository:5432/quartzPlanification des tâches
jdbc/jackrabbitrepository:5432/jackrabbitRéférentiel de contenu
jdbc/Auditrepository:5432/hibernateJournalisation d’audit
jdbc/live_logging_inforepository:5432/hibernateJournaux d’exécution ETL
jdbc/PDI_Operations_Martrepository:5432/hibernateAnalytique des opérations
{% endtab %} {% tab title="ConfigMaps de stockage" %} {% hint style="info" %} #### Stockage **PersistentVolumeClaims (PVC) :** * `postgres-pvc`: répertoire de données PostgreSQL (`/var/lib/postgresql/data`) * `pentaho-pvc`: répertoires de solutions et de données Pentaho **Classe de stockage :** * Utilise le `local-path` provisionneur de stockage intégré de K3s * Provisionne 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, paramètres Tomcat) **Secrets :** * Identifiants PostgreSQL (postgres\_password, pentaho\_user, pentaho\_password) * Chaînes de connexion JDBC * Encodés en Base64 pour la sécurité {% endhint %} {% endtab %} {% endtabs %} {% hint style="danger" %} Avant de commencer le déploiement K3s, assurez-vous d’avoir terminé la configuration : [Conteneurs Pentaho](/pentaho-11-installation-en/pentaho-11-installation-fr/configuration/pentaho-containers.md) {% endhint %} Suivez les étapes suivantes pour déployer Pentaho Server sur un K3s mono-nœud avec le dépôt PostgreSQL 15. {% tabs %} {% tab title="1. Préparer l’environnement " %} {% hint style="info" %} #### Préparer l’environnement La section « Préparer l’environnement » décrit les étapes initiales nécessaires avant de déployer Pentaho Server 11 sur K3s : * copie des ressources de déploiement dans votre répertoire personnel, * mise en place du fichier ZIP de Pentaho Server Enterprise Edition, vérification de la présence du fichier, * confirmation que K3s est correctement installé et en cours d’exécution {% endhint %} {% hint style="danger" %} Assurez-vous d’avoir téléchargé : `pentaho-server-ee-11.0.0.0-237.zip` {% endhint %} 1. Créer le répertoire et copier les ressources. ```bash cd cd ~/Workshop--Installation/Pentaho-Containers/K3s/Pentaho-K3s-PostgreSQL/scripts chmod +x ./install-to-home.sh ``` 2. Copiez le fichier pentaho-server-ee-11.0.0.0-237.zip dans le répertoire /docker/stagedArtefacts. {% hint style="info" %} Si vous avez déployé un serveur Pentaho archivé, copiez depuis : `/opt/pentaho/software/pentaho-server-ee-version` Sinon, téléchargez le paquet depuis le [Portail client Pentaho](https://support.pentaho.com/hc/en-us). {% endhint %} ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts cp /opt/pentaho/software/server/pentaho-server-ee-11.0.0.0-237.zip . ``` 3. Vérifiez le fichier. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts ls -al ``` 4. Vérifiez l'installation de K3s. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./verify-k3s.sh ``` ```sh # Vérification normale (ce que vous lancerez la plupart du temps) ./scripts/verify-k3s.sh # Sortie détaillée pour le débogage ./scripts/verify-k3s.sh --verbose # Mode silencieux pour les scripts/l’automatisation ./scripts/verify-k3s.sh --quiet # Obtenir de l’aide ./scripts/verify-k3s.sh --help ```

verify-k3s.sh

5. Pentaho Server nécessite une licence valide. Le `.env` fichier contient une URL LICENSE\_URL pointant vers le serveur de licences Flexera. Assurez-vous que vos droits de licence sont actifs avant le déploiement. {% hint style="warning" %} 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 aux déploiements en production. {% endhint %} **Différences clés**
AspectDéploiement DockerDéploiement K3s
OrchestrationDocker ComposeKubernetes (K3s)
Configuration.env fichier + docker-compose.ymlmanifestes Kubernetes (YAML)
SecretsSecrets Docker ou VaultSecrets Kubernetes
Mise en réseauréseau bridge Dockerréseau du cluster K3s + Ingress Traefik
Stockagevolumes DockerPersistentVolumeClaims (PVC)
Mise à l’échelleManuelle (docker compose up --scale)Déclarative (réplicas dans le déploiement)
Vérifications de santéHEALTHCHECK Dockersondes readiness/liveness Kubernetes
Scripts d’initialisationMontage de volume vers /docker-entrypoint-initdb.dConfigMap monté dans le pod PostgreSQL
{% endtab %} {% tab title="2. Tâches préalables" %} {% hint style="info" %} #### Tâches de pré-déploiement La section des tâches préalables décrit les étapes essentielles de préparation nécessaires avant de déployer Pentaho Server 11 dans des conteneurs K3s. **Configurer les variables d’environnement** Modifiez 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. Configurez les identifiants de la base de données PostgreSQL et les paramètres de connexion. Définissez l’allocation mémoire JVM avec un tas minimum (4 Go par défaut) et un tas maximum (8 Go par défaut). Ajoutez l’URL de votre serveur de licence Enterprise Edition si applicable. Configurez les options de build, notamment l’édition de l’image (EE/CE), la détection des plugins et les paramètres d’envoi vers le registre. Une fois configuré, copiez ce modèle vers `.env` pour être utilisé par le processus de build. **Répertoire softwareOverride** La `softwareOverride/` répertoire dans `docker-build/` fournit un mécanisme de personnalisation des 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 pilote JDBC PostgreSQL (inclus par défaut), et vous pouvez y placer des pilotes JDBC supplémentaires. La **2\_repository/** Le répertoire contient les configurations de connexion à la base de données pour Jackrabbit (JCR), Quartz (ordonnanceur) et les dépôts 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 de l’application. Vous pouvez éventuellement mettre à niveau le pilote JDBC PostgreSQL en le téléchargeant depuis Maven Central ou en le copiant depuis la collection de pilotes de base de données du workshop. Placez le pilote mis à jour dans `softwareOverride/1_drivers/tomcat/lib/`. {% endhint %} *** **Configurer .env** 1. Modifier le fichier .env.template ```bash cd cd ~/Pentaho-Server-PostgreSQL nano .env.template ``` 2. Saisissez les détails suivants :
VariablePar défautDescription
PENTAHO_VERSION11.0.0.0-237Version du serveur Pentaho
EDITIONeeVersion Entreprise
INCLUDE_DEMO1Inclure les données de démonstration
IMAGE_TAGpentaho/pentaho-server:11.0.0.0-237Tag de l'image Docker
PENTAHO_MIN_MEMORY4096mTaille minimale du heap JVM
PENTAHO_MAX_MEMORY8192mTaille maximale du heap JVM
PENTAHO_DI_JAVA_OPTIONS"-Dfile.encoding=utf8 -Djava.awt.headless=true"
PENTAHO_IMAGE_NAMEpentaho/pentaho-serverNom de l'image Docker
TZAmerica/NYFuseau horaire du serveur
DB_TYPEpostgres
DB_HOSTpostgres
DB_PORT5432Port HTTP PostgreSQL
PUSH_TO REGISTRYfauxPousse directement vers le registre K3s
LOAD_INTO_K3SvraiCharge directement dans K3s
EXÉCUTER LES TESTSvrai
LICENSE_URL(vide)URL du serveur de licence EE
3. Enregistrer : ``` CTRL + o Entrée CTRL + x ``` 4. Créer .env ```bash cd cd ~/Pentaho-Server-PostgreSQL cp .env.template .env ``` *** **softwareOverride** {% hint style="info" %} 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 au démarrage du conteneur, puis traités par ordre alphabétique selon le nom du répertoire. {% endhint %} ```` ``` softwareOverride/ ├── 1_drivers/ # Pilotes JDBC et connecteurs de données │ ├── tomcat/lib/ │ │ └── postgresql-42.x.x.jar # Pilote JDBC PostgreSQL (inclus) │ └── pentaho-solutions/drivers/ # Pilotes big data (.kar files) ├── 2_repository/ # Configuration du référentiel de base de données │ ├── pentaho-solutions/system/ │ │ ├── hibernate/hibernate-settings.xml │ │ ├── jackrabbit/repository.xml │ │ └── scheduler-plugin/quartz/quartz.properties │ └── tomcat/webapps/pentaho/META-INF/context.xml ├── 3_security/ # Authentification et autorisation │ └── pentaho-solutions/system/ │ ├── applicationContext-spring-security-hibernate.properties │ └── applicationContext-spring-security-memory.xml ├── 4_others/ # Tomcat, valeurs par défaut et divers │ ├── pentaho-solutions/system/ │ │ ├── defaultUser.spring.properties │ │ ├── pentaho.xml │ │ └── security.properties │ └── tomcat/ │ ├── bin/startup.sh │ └── webapps/pentaho/WEB-INF/web.xml └── 99_exchange/ # Échange de données utilisateur (non traité automatiquement) ``` ```` Le pilote JDBC PostgreSQL est inclus dans la distribution Pentaho. Si vous devez le mettre à niveau : 1. Téléchargez depuis [Maven Central](https://repo1.maven.org/maven2/org/postgresql/postgresql/) 2. Placez-le dans `softwareOverride/1_drivers/tomcat/lib/` Ou Copiez depuis Workshop--Installation/'Database Drivers'/ ```bash cd cd ~/Workshop--Installation/'Database Drivers' cp postgresql-42.7.8.jar ~/Pentaho-Server-PostgreSQL/softwareOverride/1_drivers/tomcat/lib ``` {% endtab %} {% tab title="3. Construire et pousser l’image" %} {% hint style="info" %} #### 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 - Confirme que le ZIP Pentaho existe dans stagedArtifacts/ * Détecte automatiquement les plugins - Trouve les plugins PAZ, PIR, PDD * Confirme le build - Affiche ce qui sera construit et demande une confirmation * Exécute docker build - Lance le build avec les arguments appropriés * Affiche les informations de l’image - Affiche la taille et les détails de l’image après le build * Facultatif : teste l’image - Exécute un test de conteneur de base (vous pouvez ignorer cette étape) * Facultatif : pousse vers le registre - Pousse vers le registre Docker (uniquement avec l’option -p) C’est l’ **approche recommandée** pour construire les images Docker Pentaho. Elle utilise un seul `.env` fichier pour tout configurer - de manière similaire au déploiement Docker Compose. {% endhint %} Vous pouvez modifier le build avec les options suivantes :
Option (courte)Option (longue)Description
-v--version VERSIONVersion de Pentaho (par défaut : 11.0.0.0-237)
-t--tag TAGÉtiquette de l’image Docker (par défaut : pentaho/pentaho-server:VERSION)
-e--edition EDITIONee ou ce (par défaut : ee)
-d--demoInclure le contenu de démonstration (par défaut : non)
-p--pushPousser vers le registre après le build
-h--helpPousser vers le registre après le build
1. Construire et pousser l’image du serveur Pentaho directement dans le registre K3s. ```bash # Build avec les valeurs par défaut basées sur .env cd cd ~/Pentaho-K3s-PostgreSQL/docker-build ./build.sh ```

Construire et pousser l’image du serveur Pentaho

{% hint style="info" %} **1. Build de l’image Docker :** Le déploiement utilise une image de conteneur Pentaho Server construite sur mesure : ``` docker-build/ ├── Dockerfile (build multi-étapes) ├── build.sh (script de build automatisé) ├── stagedArtifacts/ (ZIP de Pentaho Server) └── softwareOverride/ (couches de configuration) ├── 1_drivers/ (pilote JDBC PostgreSQL) ├── 2_repository/ (configurations de base de données) ├── 3_security/ (authentification) └── 4_others/ (personnalisations Tomcat) ``` La `build.sh` script : * Valide les prérequis et les fichiers requis * Détecte automatiquement les plugins (PAZ, PIR, PDD) * Exécute un build Docker multi-étapes * Pousse éventuellement vers le stockage d’images K3s **2. Gestion de la configuration :** * `.env` le fichier contient des paramètres spécifiques au déploiement (versions, identifiants, mémoire JVM) * `softwareOverride/` répertoire fournit des couches de configuration traitées dans l’ordre numérique * pilote JDBC PostgreSQL inclus par défaut, avec possibilité de mise à niveau * Scripts Tomcat personnalisés pour l’optimisation du démarrage du conteneur {% endhint %} {% endtab %} {% tab title="4. Charts Helm" %} {% hint style="info" %} #### 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 : **Empaquetage**: Regrouper les ressources Kubernetes associées **Gabaritage**: Paramétrer les manifestes pour les réutiliser dans différents environnements **Gestion des versions**: Gérer les versions de l'application et les mises à niveau **Gestion des publications**: Suivre les déploiements et permettre les retours en arrière {% endhint %}

Charts Helm

{% tabs %} {% tab title="1. Répertoires" %} {% hint style="info" %} #### Structure des répertoires Voici une explication du répertoire pentaho responsable d’un déploiement Helm. {% endhint %} ``` pentaho/ # Répertoire racine du chart ├── Chart.yaml # Métadonnées du chart (nom, version, description) ├── values.yaml # Valeurs de configuration par défaut ├── templates/ # Modèles de manifestes Kubernetes │ ├── _helpers.tpl # Fonctions utilitaires de modèles (non rendues) │ ├── NOTES.txt # Instructions après installation │ ├── namespace.yaml # Création du namespace │ ├── secret.yaml # Données sensibles (mots de passe, clés) │ ├── configmap-*.yaml # Données de configuration │ ├── pvc.yaml # Requêtes de volumes persistants │ ├── *-deployment.yaml # Déploiements de pods │ ├── *-service.yaml # Définitions des services │ └── ingress.yaml # Règles de routage Ingress └── files/ # Fichiers non-modèles (scripts SQL, configurations) └── db_init/ # Scripts d’initialisation PostgreSQL ``` **Chart.yaml** {% hint style="info" %} Ce fichier définit l’identité, la version et les métadonnées du chart utilisées par Helm. Il sert de « définition de paquet » pour le chart Helm, de manière 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 référentiels de charts. Helm utilise ce fichier pour suivre les versions des charts, gérer les dépendances et afficher des informations lorsque les utilisateurs recherchent ou installent des charts. {% endhint %} **values.yaml** {% hint style="info" %} 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é dans le cluster - comme le nombre de réplicas, les versions des 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 modèles du chart pour générer les manifestes Kubernetes finaux. Vous pouvez remplacer des valeurs spécifiques au moment du déploiement en utilisant `--set` des options ou en fournissant un fichier de valeurs personnalisé avec `-f`, ce qui en fait un mécanisme flexible pour gérer des configurations spécifiques à un environnement (par ex. développement vs production) sans modifier les modèles du chart sous-jacent. {% endhint %} *** **templates**
YAMLDescription
namespace.yamlCrée un namespace Kubernetes isolé pour contenir toutes les ressources Pentaho
secret.yamlStocke les identifiants sensibles de base de données (mots de passe) chiffrés dans Kubernetes
config-*.yamlConfigure les variables d’environnement Pentaho (mémoire JVM, paramètres de base de données, chemins, fuseau horaire) Contient des scripts SQL pour initialiser les bases de données PostgreSQL (jackrabbit, quartz, hibernate) au premier démarrage
pvc.yamlDemande des volumes de stockage persistants pour les données PostgreSQL et, éventuellement, les données/solutions Pentaho
*-deployment.yamlDéploie Pentaho Business Analytics Server avec un conteneur d’initialisation, des sondes de santé et des limites de ressources. Déploie le serveur de base de données PostgreSQL 15 avec initialisation automatique et stockage persistant
*-service.yamlRoute le trafic HTTP/HTTPS externe vers Pentaho Server via le contrôleur d’Ingress Traefik. Expose le port PostgreSQL 5432 comme point de terminaison DNS stable auquel Pentaho peut se connecter.
ingress.yamlRoute le trafic HTTP/HTTPS externe vers Pentaho Server via le contrôleur d’Ingress Traefik
{% endtab %} {% tab title="2. Déploiement" %} {% hint style="info" %} #### Déployer L’architecture se compose de 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 de données essentielles - Jackrabbit pour le stockage de contenu, Quartz pour la planification des tâches, et Hibernate pour la sécurité et la journalisation d’audit. {% endhint %} {% hint style="danger" %} Avant de continuer, assurez-vous d’avoir terminé les étapes 1 à 3. Vous devriez avoir une image Pentaho Server + des images du dépôt PostgreSQL 15 poussées vers le dépôt K3s. {% endhint %} 1. Vérification rapide. ```bash # Vérifier la version de Helm (nécessite 3.0+) helm version # Vérifier le cluster Kubernetes kubectl cluster-info kubectl get nodes # Vérifier les classes de stockage disponibles kubectl get storageclass ``` 2. Vérifiez que l’image Pentaho est disponible. ```bash # Vérifier sudo k3s ctr images ls | grep pentaho ```

image Pentaho Server dans le dépôt K3s

*** {% hint style="info" %} #### Déploiement par défaut Le flux de déploiement se déroule en quatre étapes : * préparation de l’environnement en mettant en place le package Pentaho Enterprise Edition et en vérifiant K3s. * configuration des variables d’environnement et des remplacements logiciels pendant les tâches préalables. * construction et envoi d’une image Docker personnalisée dans le runtime de conteneurs K3s. * puis déploiement final de l’ensemble de la pile à l’aide soit de charts Helm, soit d’un `deploy.sh` script automatisé qui orchestre la création du namespace, les secrets, les ConfigMaps, le stockage persistant et le routage d’ingress Traefik. Couvre également la structure du chart Helm, une suite de scripts d’assistance 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, notamment le port-forwarding, l’ingress basé sur le nom d’hôte et l’IP directe du nœud. {% endhint %} 1. Installer à l’aide des charts Helm. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/helm-chart helm install pentaho ./pentaho ```

Déployer Pentaho Server - Chart Helm

{% endtab %} {% endtabs %} {% endtab %} {% tab title="Scripts d’assistance" %} {% hint style="info" %} #### Scripts d’assistance Le déploiement Pentaho sur K3s inclut une collection de scripts d’assistance dans le `scripts/` répertoire pour les opérations et la maintenance quotidiennes : * **backup-postgres.sh :** Crée des dumps compressés et horodatés de toutes les bases de données Pentaho (Jackrabbit, Quartz, Hibernate) à l’aide de `pg_dump` exécuté à l’intérieur du pod PostgreSQL. * **restore-postgres.sh :** Restaure les bases de données Pentaho à partir de fichiers de sauvegarde, utile pour la reprise après sinistre, le clonage d’environnement ou la migration de données entre clusters. * **health-check.sh :** Effectue une vérification rapide de l’état d’exécution couvrant la disponibilité du pod, la disponibilité du service, la connectivité à la base de données et un test HTTP en direct sur 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 du CPU et de la mémoire sur tous les pods Pentaho à l’aide de `kubectl top` pour aider à identifier les contraintes de ressources ou les possibilités d’optimisation. * **monitor-postgres.sh :** Surveille les métriques spécifiques à PostgreSQL, notamment le nombre de connexions, les requêtes actives, la taille des tables et l’état général de la base de données. * **verify-k3s.sh :** Valide l’infrastructure K3s sous-jacente (état des nœuds, classes de stockage, ingress Traefik et composants principaux) avant de tenter un déploiement Pentaho. * **Makefile :** Fournit des commandes pratiques telles que `make health`, `make status`, `make logs`, `make port-forward`, et `make destroy` pour une gestion simplifiée du cluster. {% endhint %} {% tabs %} {% tab title="1. Répertoires" %} {% hint style="info" %} #### Structure des répertoires Cette configuration de déploiement K3s offre plusieurs capacités importantes : * Déploiement Kubernetes totalement autonome sur le K3s léger * Initialisation automatisée de la base de données avec des scripts SQL PostgreSQL * Vérifications de santé et ordre de démarrage natifs à Kubernetes * 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é * Modèles de manifests Kubernetes prêts pour la production * Pilote JDBC PostgreSQL inclus * Procédures de sauvegarde et de restauration faciles via des scripts utilitaires * Configuration d’ingress pour le routage Traefik {% endhint %} *** **Fichiers du répertoire racine** ``` Pentaho-K3s-PostgreSQL/ ├── deploy.sh # Script principal de déploiement ├── destroy.sh # Script de nettoyage ├── Makefile # Commandes rapides (make help) ├── README.md # Ce fichier ├── DEPLOYMENT.md # Guide de déploiement détaillé ├── K3s-INSTALLATION.md # Instructions d’installation de K3s ``` {% hint style="info" %} **Fichiers de documentation :** **README.md** - La documentation principale, fournissant un aperçu du projet, des instructions de démarrage rapide, les prérequis et des informations générales d’utilisation pour l’atelier de déploiement K3s. **DEPLOYMENT.md** - Guide de déploiement détaillé couvrant le flux complet de déploiement K3s, y compris les prérequis, les instructions étape par étape et les procédures de vérification après 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 mise en place de la classe de stockage requise avant de déployer Pentaho. **Orchestration et déploiement :** **deploy.sh** - Script de déploiement automatisé qui orchestre le flux complet de déploiement K3s, y compris la création du namespace, la génération des 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, y compris les déploiements, services, persistent volume claims 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 le déploiement, la suppression, la vérification de l’état et l’affichage des journaux. Les utilisateurs peuvent exécuter `make help` pour voir toutes les commandes disponibles. {% endhint %} *** **docker-build** ``` ├── docker-build/ # Build de l’image Docker │ ├── build.sh # Script de compilation │ ├── Dockerfile # Définition de l’image │ ├── README.md # Documentation complète du build │ ├── QUICK-START.md # Guide de démarrage rapide du build │ ├── ENV-CONFIGURATION.md # Guide de configuration de .env │ ├── .env.example # Modèle de configuration │ ├── test-compose.yml # Tests Docker locaux │ ├── entrypoint/ # Scripts de démarrage du conteneur │ │ ├── docker-entrypoint.sh │ │ └── start-pentaho-docker.sh │ ├── softwareOverride/ # Superpositions de configuration (intégrées dans l’image) │ │ ├── 1_drivers/ # Pilote JDBC PostgreSQL │ │ ├── 2_repository/ # Configurations de base de données │ │ │ └── README.md │ │ ├── 3_security/ # (vide - pas de Vault) │ │ └── 4_others/ # Scripts Tomcat modifiés │ │ └── README.md │ └── stagedArtifacts/ # Placez le ZIP Pentaho ici │ └── README.md ``` {% hint style="info" %} La **docker-build/** le répertoire contient tous les composants nécessaires pour construire l’image conteneur du 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 de build multi-étapes, les options de configuration, le dépannage et les bonnes pratiques pour construire des images Pentaho Server pour un déploiement K3s. **QUICK-START.md** - Guide de démarrage 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 complet pour le `.env.example` fichier, détaillant toutes les variables d’environnement disponibles, leurs rôles, leurs valeurs par défaut et la manière dont elles influencent le processus de build Docker et l’image résultante. **Fichiers de build et de configuration :** **build.sh** - Script d’encapsulation de build automatisé qui valide les prérequis, vérifie les fichiers requis (ZIP Pentaho dans `stagedArtifacts/`) `docker build`, affiche les informations de l’image après la compilation et peut éventuellement la pousser vers un registre avec l’ `-p` drapeau. **.env.example** - Fichier modèle de configuration contenant toutes les variables d’environnement disponibles pour le processus de build Docker. Les utilisateurs doivent le copier vers `.env` et personnaliser les valeurs selon leurs besoins de déploiement spécifiques, y compris la version 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 d’exécution, 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 la déployer sur K3s. C’est utile pour valider les 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 au lancement du conteneur. Gère le traitement des variables d’environnement, la personnalisation des fichiers de configuration depuis `softwareOverride/`, la validation de la connexion à la base de données, les vérifications de santé et orchestre la séquence de démarrage du Pentaho Server. * **start-pentaho-docker.sh** - Script de démarrage spécifique à Pentaho qui gère l’initialisation de Tomcat, la configuration JVM, les paramètres mémoire et démarre les services du Pentaho Server. Ce script est appelé par `docker-entrypoint.sh` après la fin de la préparation de l’environnement. **Superpositions de configuration :** **softwareOverride/** - Répertoire de superpositions de configuration intégré 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 pour garantir une 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 ou connecteurs de données supplémentaires peuvent être placés ici. * **2\_repository/** - Configurations de connexion à la base de données pour tous les référentiels Pentaho, y compris Jackrabbit (JCR), Quartz (planificateur) et Hibernate (sécurité/audit). Contient un **README.md** expliquant les fichiers de configuration du référentiel et leurs rôles. * **3\_security/** - Vide dans ce déploiement K3s, car l’intégration HashiCorp Vault n’est pas utilisée. Dans les 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 rôles. **Artifacts de staging :** **stagedArtifacts/** - Répertoire de staging où les utilisateurs placent le package d’installation du Pentaho Server (`pentaho-server-ee-11.0.0.0-237.zip`) avant de construire l’image Docker. Contient un **README.md** avec des instructions sur l’endroit où obtenir le package Pentaho et comment le placer correctement en staging. {% endhint %} *** **db\_init\_postgres** ``` ├── db_init_postgres/ # Scripts SQL d’initialisation PostgreSQL │ ├── 1_create_jcr_postgresql.sql │ ├── 2_create_quartz_postgresql.sql │ ├── 3_create_repository_postgresql.sql │ ├── 4_pentaho_logging_postgresql.sql │ └── 5_pentaho_mart_postgresql.sql ``` {% hint style="info" %} La **db\_init\_postgres/** le répertoire contient les scripts d’initialisation PostgreSQL qui créent toutes les bases de données de référentiel Pentaho requises. Ces scripts sont montés dans le conteneur PostgreSQL et s’exécutent automatiquement lors du premier démarrage : **1\_create\_jcr\_postgresql.sql** - Crée le **Référentiel de contenu Jackrabbit (JCR)** base de données. Le JCR stocke tout le contenu Pentaho, y compris les rapports, tableaux de bord, sources de données, schémas d’analyse, transformations, jobs et fichiers utilisateur. Il s’agit du principal système de gestion de contenu du référentiel Pentaho. **2\_create\_quartz\_postgresql.sql** - Configure le **Ordonnanceur Quartz** base de données. Quartz gère tous les jobs planifiés, les déclencheurs et les calendriers dans Pentaho Server, y compris les planifications de génération de rapports, les exécutions de jobs ETL et d’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 **Référentiel Hibernate** base de données. Celle-ci stocke les données d’authentification des utilisateurs, les informations d’autorisation, les rôles, les permissions et d’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 de la base de données Hibernate pour l’audit et la journalisation Data Integration (DI). Capture des informations détaillées sur l’exécution ETL, notamment les journaux de jobs, les journaux de transformations, les métriques de performance des étapes et les enregistrements d’erreurs. Essentiel pour déboguer les flux de travail d’intégration de données et surveiller l’état 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 de Pentaho Server, y compris 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 les schémas d’activité des utilisateurs. {% endhint %} *** **manifests** ``` ├── manifests/ # Manifests Kubernetes │ ├── namespace.yaml # Namespace Pentaho │ ├── configmaps/ │ │ ├── pentaho-config.yaml │ │ └── postgres-init-scripts.yaml │ ├── pentaho/ │ │ ├── deployment.yaml │ │ └── service.yaml │ ├── postgres/ │ │ ├── deployment.yaml │ │ └── service.yaml │ ├── secrets/ │ │ └── secrets.yaml # (ignoré par git) │ ├── storage/ │ │ └── pvc.yaml │ └── ingress/ │ └── ingress.yaml ``` {% hint style="info" %} 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 Pentaho Server comme les paramètres JVM, les réglages Tomcat et les propriétés de l’application * **postgres-init-scripts.yaml** - ConfigMap contenant les cinq scripts d’initialisation PostgreSQL du `db_init_postgres/` répertoire, monté dans le pod PostgreSQL **pentaho/** - Ressources Kubernetes du Pentaho Server : * **deployment.yaml** - Définit le déploiement du Pentaho Server, y compris 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 Pentaho Server sur le port 8080 à l’intérieur du cluster, fournissant un DNS interne stable et un équilibrage de charge **postgres/** - Ressources Kubernetes de la base de données PostgreSQL : * **deployment.yaml** - Définit le déploiement PostgreSQL 15 avec les spécifications du conteneur, les persistent volume claims 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 à l’intérieur du cluster pour les connexions à la base de données du Pentaho Server **secrets/** - Stockage d’identifiants sensibles : * **secrets.yaml** - Ressource Kubernetes Secret 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 la persistance des données entre les redémarrages des pods **ingress/** - Configuration d’accès externe : * **ingress.yaml** - Ressource Traefik Ingress définissant les règles de routage HTTP/HTTPS externes pour exposer Pentaho Server en dehors du cluster K3s, y compris le nom d’hôte, le routage par chemin et la configuration TLS le cas échéant {% endhint %} *** **scripts** ``` └── scripts/ # Scripts utilitaires ├── backup-postgres.sh # Sauvegarde de base de données ├── restore-postgres.sh # Restauration de base de données ├── health-check.sh # Vérification de santé ├── monitor-resources.sh # Surveillance des ressources ├── monitor-postgres.sh # Surveillance PostgreSQL ├── validate-deployment.sh # Validation du déploiement └── verify-k3s.sh # Vérification de K3s ``` {% hint style="info" %} La **scripts/** le répertoire contient des utilitaires d’exploitation et de maintenance pour gérer le déploiement Pentaho sur K3s : **Gestion de base de données :** **backup-postgres.sh** - Utilitaire automatisé de sauvegarde PostgreSQL qui crée des dumps compressés de toutes les bases de données Pentaho (jackrabbit, quartz, hibernate) à l’aide de `kubectl exec` pour exécuter `pg_dump` dans le 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 de données Pentaho à partir de fichiers de sauvegarde. Utile pour la reprise après sinistre, le clonage d’environnement 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 de santé qui confirme que PostgreSQL et Pentaho Server s’exécutent et répondent correctement. Vérifie l’état 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 du CPU, de la mémoire et du stockage sur tous les pods Pentaho à l’aide de `kubectl top` et des métriques de ressources, aidant à identifier les contraintes de ressources ou les possibilités d’optimisation. **monitor-postgres.sh** - Script de surveillance spécifique à PostgreSQL qui vérifie le nombre de connexions à la base de données, les requêtes actives, la taille des tables et les métriques de santé de la base de données 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 s’exécutent, que les services sont accessibles, que les volumes persistants sont liés et que l’ensemble du déploiement fonctionne. **verify-k3s.sh** - Script de vérification de l’infrastructure K3s qui vérifie l’installation de K3s, l’état des nœuds, les classes de stockage, le contrôleur d’ingress Traefik et les composants principaux de K3s avant de tenter un déploiement Pentaho. {% endhint %} *** **Différences clés : K3s vs Docker**
AspectDéploiement DockerDéploiement K3s
OrchestrationDocker ComposeKubernetes (K3s)
Configuration.env fichier + docker-compose.ymlmanifestes Kubernetes (YAML)
SecretsSecrets Docker ou VaultSecrets Kubernetes
Mise en réseauréseau bridge Dockerréseau du cluster K3s + Ingress Traefik
Stockagevolumes DockerPersistentVolumeClaims (PVC)
Mise à l’échelleManuelle (docker compose up --scale)Déclarative (réplicas dans le déploiement)
Vérifications de santéHEALTHCHECK Dockersondes readiness/liveness Kubernetes
Scripts d’initialisationMontage de volume vers /docker-entrypoint-initdb.dConfigMap monté dans le pod PostgreSQL
{% endtab %} {% tab title="2. Déploiement" %} {% hint style="info" %} #### Exécution du déploiement La `deploy.sh` le script automatise l’ensemble du flux de travail : * 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 :** ```bash kubectl create namespace pentaho ``` Crée un environnement logique isolé pour toutes les ressources Pentaho. **2. Génération des secrets :** ```bash kubectl apply -f manifests/secrets/secrets.yaml ``` Stocke les identifiants PostgreSQL et les chaînes de connexion JDBC sous forme de Secrets Kubernetes. **3. Provisionnement du stockage :** ```bash kubectl apply -f manifests/storage/pvc.yaml ``` Crée des PersistentVolumeClaims pour les données PostgreSQL et le contenu Pentaho. **4. Création des ConfigMaps :** ```bash kubectl apply -f manifests/configmaps/ ``` Monte les scripts d’initialisation PostgreSQL et la configuration Pentaho. **5. Déploiement PostgreSQL :** ```bash kubectl apply -f manifests/postgres/ ``` Déploie le pod PostgreSQL avec : * Scripts d’initialisation montés (création automatique de la base de données au premier démarrage) * Volume persistant pour les données * Vérifications de santé et limites de ressources * Service ClusterIP pour la connectivité interne **6. Déploiement du Pentaho Server :** ```bash kubectl apply -f manifests/pentaho/ ``` Déploie le pod Pentaho avec : * Image Docker personnalisée * Variables d’environnement provenant de ConfigMap et de Secrets * Montages de volumes pour solutions/données * Probes de readiness/liveness * Service ClusterIP **7. Configuration de l’ingress :** ```bash kubectl apply -f manifests/ingress/ingress.yaml ``` Configure le routage Traefik pour l’accès externe. {% endhint %} 1. Exécuter le ```sh cd cd ~/Pentaho-K3s-PostgreSQL ./deploy.sh ```

Déployer Pentaho Server

{% hint style="info" %} Ce script unifié gère l’ensemble du processus de déploiement de Pentaho Server sur K3s, y compris : * Import de l’image Docker dans le runtime de conteneurs K3s * Création des ressources Kubernetes (namespace, secrets, configmaps, stockage) * Déploiement de la base de données PostgreSQL * Déploiement de Pentaho Server * Configuration de l’ingress * Vérifications de santé et rapport d’état ``` Utilisation : ./deploy.sh # Nouveau déploiement avec import de l’image ./deploy.sh --skip-import # Déployer sans importer l’image ./deploy.sh --update-only # Mettre à jour uniquement le déploiement existant ./deploy.sh --clean # Supprimer les anciennes images avant le déploiement ``` 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 {% endhint %} *** **Commandes rapides avec Makefile** ```bash make help # Afficher toutes les commandes disponibles make full-deploy # Construire, importer et déployer (flux complet) make health # Exécuter la vérification de santé make status # Afficher l’état du déploiement make logs # Voir les journaux Pentaho make port-forward # Accéder à Pentaho sur localhost:8080 make destroy # Supprimer le déploiement ``` *** Il existe aussi tout un ensemble de scripts qui aideront à valider le déploiement : {% tabs %} {% tab title="Valider le déploiement" %} {% hint style="info" %} 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 fonctionnent correctement. Ce qu’il vérifie (6 catégories) **Namespace** * Vérifie que le namespace pentaho existe **Pods** * Le pod PostgreSQL est en cours d’exécution * Le pod Pentaho Server est en cours d’exécution * Affiche l’état actuel s’il n’est pas en cours d’exécution **Services** * Le service PostgreSQL existe * Le service Pentaho Server existe **PersistentVolumeClaims (3 PVC)** * postgres-data-pvc (10Gi) - Fichiers de base de données * pentaho-data-pvc (10Gi) - Pentaho * data pentaho-solutions-pvc (5Gi) - Référentiel de solutions * Tous doivent être à l’état « 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 de données Pentaho : \* jackrabbit - dépôt de contenu JCR \* quartz - planificateur de tâches \* hibernate - dépôt de configuration * Exécute une requête SELECT 1 sur chacune {% endhint %} 1. Exécutez ce qui suit `validate-deployment.sh` script. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```

Valider le déploiement

{% endtab %} {% tab title="Vérification de l'état de santé" %} {% hint style="info" %} #### Vérification de l'état de santé Script de vérification rapide de l'état de santé pour une installation Pentaho en cours d'exécution — plus rapide et plus léger qu'une validation complète, axé sur l'état de santé à l'exécution. Namespace * Vérifie que le namespace pentaho existe * Quitte immédiatement si l'espace de noms est manquant (critique) Disponibilité du pod * Le pod PostgreSQL est prêt (pas seulement en cours d'exécution) * Le pod Pentaho Server est prêt * Vérifications `état containerStatuses[0].ready` Services * Le service PostgreSQL existe * Le service Pentaho Server existe Connectivité à la base de données * PostgreSQL répond aux requêtes Les 3 bases de données existent : \* jackrabbit \* quartz \* hibernate * Utilise `psql -lqt` pour lister les bases de données État de santé de l'application Web * Test HTTP en direct de la page de connexion Pentaho * Utilise le port-forward pour accéder au service * Attend une réponse HTTP 200 * Teste : Utilisation des ressources * Affiche l'utilisation CPU/mémoire via `kubectl top pods` * Gère gracieusement l'absence de metrics-server {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./health-check.sh ```

Vérification de l'état de santé

{% endtab %} {% tab title="Surveiller les ressources" %} {% hint style="info" %} #### Surveiller les ressources x {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```
{% endtab %} {% tab title="Serveur Pentaho" %} {% hint style="info" %} #### Accéder au serveur Pentaho {% endhint %} **Redirection de port (recommandée pour les tests/le développement)** La méthode la plus simple consiste à utiliser kubectl pour rediriger un port local vers le service Pentaho : ```bash kubectl port-forward -n pentaho svc/pentaho-server 8080:8080 ``` **URL d'accès :** `http://localhost:8080/pentaho` Vous pouvez également utiliser un autre port si le 8080 est occupé : ```bash kubectl port-forward -n pentaho svc/pentaho-server 9080:8080 # Puis accédez à : http://localhost:9080/pentaho ``` *** **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 :** ```bash echo "10.0.0.1 pentaho.local" | sudo tee -a /etc/hosts ``` *(Remplacez 10.0.0.1 par l'adresse IP réelle de votre nœud)* **URL d'accès :** `http://pentaho.local/pentaho` *** **Ingress via l'adresse IP directe du nœud (aucun DNS requis)** Accédez directement via l'adresse IP de n'importe quel nœud du cluster sans configurer /etc/hosts : **URL d'accès :** `http:///pentaho` Cela fonctionne car l'ingress inclut une règle basée sur le chemin qui ne nécessite pas de nom d'hôte. *** **Commande de raccourci Makefile** Le projet inclut un raccourci Makefile : ```bash make port-forward ``` Cela configure automatiquement une redirection de port vers localhost:8080. *** **Identifiants par défaut** | Nom d'utilisateur | Mot de passe | | ----------------- | ------------ | | admin | password | ⚠️ Modifiez-les pour les déploiements en production ! *** **Référence rapide** | Méthode | Idéal pour | URL | | -------------------- | ------------------- | ------------------------------- | | Redirection de port | Développement/Tests | `http://localhost:8080/pentaho` | | Ingress (nom d'hôte) | Production avec DNS | `http://pentaho.local/pentaho` | | Ingress (IP directe) | Tests sans DNS | `http:///pentaho` | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-fr/installation/containers/k3s.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.