# K3s {% hint style="info" %} #### 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é. {% endhint %}

{% 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 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é. {% endhint %}

{% endtab %} {% tab title="Pod Pentaho Server" %} {% hint style="info" %} #### 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 {% endhint %}

{% 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) : 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 {% endhint %}

*Architecture de la base de données PostgreSQL*

Pentaho Server nécessite trois bases de données distinctes, chacune ayant un rôle spécifique :

Base de données	Propriétaire	But et contenu
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).

{% hint style="info" %} 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. {% endhint %} {% endtab %} {% tab title="Réseau" %} {% hint style="info" %} #### Mise en réseau **Communication interne :** * Les deux pods s’exécutent au sein du `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 * Routage configurable par nom d’hôte et par chemin * Prise en charge optionnelle de terminaison TLS/SSL {% endhint %} Tomcat gère des pools de connexions définis dans context.xml. Chaque pool a un usage spécifique :

Nom du pool	Cible de connexion	Utilisé pour
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

{% 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 solutions et données Pentaho **Classe de stockage :** * Utilise le `local-path` provisionneur de stockage * 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, 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é {% endhint %} {% endtab %} {% endtabs %} {% hint style="danger" %} Avant de commencer le déploiement K3s, assurez-vous d’avoir complété la configuration : [Conteneurs Pentaho](https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-fr/configuration/conteneurs-pentaho) {% endhint %} Parcourez les étapes suivantes pour déployer Pentaho Server sur un K3s mono-nœud avec un 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 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 {% 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 assets. ```bash cd cd ~/Workshop--Installation/Pentaho-Containers/K3s/Pentaho-K3s-PostgreSQL/scripts chmod +x ./install-to-home.sh ``` 2. Copiez le pentaho-server-ee-11.0.0.0-237.zip dans le répertoire /docker/stagedArtefacts. {% hint style="info" %} 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](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 que le fichier existe. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts ls -al ``` 4. Vérifier l’installation de K3s. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./verify-k3s.sh ``` ```sh # Vérification normale (ce que vous exécuteriez la plupart du temps) ./scripts/verify-k3s.sh # Sortie détaillée pour le débogage ./scripts/verify-k3s.sh --verbose # Mode silencieux pour scripts/automatisation ./scripts/verify-k3s.sh --quiet # Obtenir de l’aide ./scripts/verify-k3s.sh --help ```

5. Pentaho Server requiert une licence valide. Le `.env` fichier contient une 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 à des déploiements en production. {% endhint %} **Principales différences**

Aspect	Déploiement Docker	Déploiement K3s
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

{% endtab %} {% tab title="2. Tâches préalables" %} {% hint style="info" %} #### 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/`. {% endhint %} *** **Configurer .env** 1. Éditez le .env.template ```bash cd cd ~/Pentaho-Server-PostgreSQL nano .env.template ``` 2. Saisissez les détails suivants :

Variable	Par défaut	Description
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

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 lors du démarrage du conteneur, traités par ordre alphabétique des noms de répertoires. {% 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 dépôt 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, paramètres 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 à jour : 1. Télécharger depuis [Maven Central](https://repo1.maven.org/maven2/org/postgresql/postgresql/) 2. Placer dans `softwareOverride/1_drivers/tomcat/lib/` Ou Copier 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 - 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. {% endhint %} Vous pouvez modifier le build avec les options suivantes :

Option (court)	Option (long)	Description
-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

1. Construire et pousser l’image du Pentaho Server directement dans le registry K3s. ```bash # Construire avec les valeurs par défaut basées sur .env cd cd ~/Pentaho-K3s-PostgreSQL/docker-build ./build.sh ```

{% hint style="info" %} **1. Construction 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 Pentaho Server) └── softwareOverride/ (surcouches de configuration) ├── 1_drivers/ (driver JDBC PostgreSQL) ├── 2_repository/ (configs 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 la construction Docker multi-étapes * Pousse éventuellement vers le store d’images K3s **2. Gestion de la configuration :** * `.env` le 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 {% 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 : **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 {% endhint %}

{% tabs %} {% tab title="1. Répertoires" %} {% hint style="info" %} #### Structure des répertoires Ci-dessous 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 manifests Kubernetes │ ├── _helpers.tpl # Fonctions d’aide au template (non rendues) │ ├── NOTES.txt # Instructions post-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 # Persistent volume claims │ ├── *-deployment.yaml # Déploiements de pods │ ├── *-service.yaml # Définitions de services │ └── ingress.yaml # Règles de routage Ingress └── files/ # Fichiers non-template (scripts SQL, configs) └── db_init/ # Scripts d’initialisation PostgreSQL ``` **Chart.yaml** {% hint style="info" %} 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. {% 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é 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. {% endhint %} *** **templates**

YAML	Description
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

{% endtab %} {% tab title="2. Déployer" %} {% hint style="info" %} #### 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. {% endhint %} {% hint style="danger" %} 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. {% endhint %} 1. Vérification rapide. ```bash # Vérifier la version de Helm (requiert 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érifier que l’image Pentaho est disponible. ```bash # Vérifier sudo k3s ctr images ls | grep pentaho ```

Image Pentaho Server dans le repository K3s

*** {% hint style="info" %} #### 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.sh` script 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. {% endhint %} 1. Installer en utilisant les charts Helm. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/helm-chart helm install pentaho ./pentaho ```

{% endtab %} {% endtabs %} {% endtab %} {% tab title="Scripts d’aide" %} {% hint style="info" %} #### 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_dump` exé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 top` pour 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`, 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 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 {% 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 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. {% endhint %} *** **docker-build** ``` ├── docker-build/ # Construction de l’image Docker │ ├── build.sh # Script de build │ ├── Dockerfile # Définition de l’image │ ├── README.md # Documentation complète du build │ ├── QUICK-START.md # Guide de build rapide │ ├── ENV-CONFIGURATION.md # Guide de configuration .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/ # Surcouches de config (intégrées dans l’image) │ │ ├── 1_drivers/ # Driver JDBC PostgreSQL │ │ ├── 2_repository/ # Configs 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 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.sh` aprè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. {% 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 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. {% 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 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 {% 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 d'état ├── 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 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. {% endhint %} *** **Différences clés : K3s vs Docker**

Aspect	Déploiement Docker	Déploiement K3s
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

{% endtab %} {% tab title="2. Déployer" %} {% hint style="info" %} #### 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 :** ```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 en tant que 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'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 :** ```bash kubectl apply -f manifests/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 :** ```bash kubectl apply -f manifests/ingress/ingress.yaml ``` Configure le routage Traefik pour l'accès externe. {% endhint %} 1. Exécutez le deploy.sh ```sh cd cd ~/Pentaho-K3s-PostgreSQL ./deploy.sh ```

{% hint style="info" %} 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 ``` Utilisation : ./deploy.sh # Déploiement frais avec import d'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 de déployer ``` 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 # Affiche toutes les commandes disponibles make full-deploy # Construire, importer et déployer (workflow complet) make health # Exécuter la vérification d'état make status # Afficher le statut du déploiement make logs # Voir les logs de Pentaho make port-forward # Accéder à Pentaho sur localhost:8080 make destroy # Supprimer le déploiement ``` *** Il y a aussi plusieurs 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 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 {% endhint %} 1. Exécutez le script suivant `validate-deployment.sh` . ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```

{% endtab %} {% tab title="Vérification d'état" %} {% hint style="info" %} #### 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 -lqt` pour 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 : ; 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 ```

{% 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 %} **Port Forward (recommandé pour tests/développement)** La méthode la plus simple utilisant 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 aussi utiliser un port alternatif si 8080 est occupé : ```bash kubectl port-forward -n pentaho svc/pentaho-server 9080:8080 # Puis accéder : 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'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:///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 : ```bash make port-forward ``` Ceci configure automatiquement le port forwarding vers localhost:8080. *** **Identifiants par défaut** | Nom d'utilisateur | Mot de passe | | ----------------- | ------------ | | admin | password | ⚠️ Changez-les pour les déploiements en production ! *** **Référence rapide** | Méthode | Idéal pour | URL | | -------------------- | ------------------- | ------------------------------- | | 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:///pentaho` | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | |