Faire fonctionner tout le cycle d’une donnée CKAN

Faire fonctionner tout le cycle d’une donnée CKAN examine une difficulté propre à cette architecture. La composition associe l’application CKAN, un worker RQ, DataPusher, PostgreSQL pour les métadonnées et le DataStore, Solr pour l’index et Redis pour les tâches. Le stockage de fichiers complète cet ensemble. Le domaine public reste attaché à CKAN ; DataPusher et les magasins d’état utilisent le réseau interne et ne doivent pas recevoir de route publique. L’objectif était de conserver le contrat du produit tout en confiant à Coolify le déploiement, les domaines et le renouvellement des conteneurs.

CKAN est une solution de catalogue et portail de données ouvertes adaptée à des usages structurés et à un hébergement maîtrisé. Le choix d’un logiciel existant permet de concentrer l’ingénierie sur l’adaptation, la gouvernance et l’exploitation plutôt que de recréer son cœur fonctionnel.

L’architecture du produit distingue interface, logique métier, traitements différés et états persistants. Cette carte des responsabilités a servi de référence avant toute modification liée à Coolify. CKAN répond à un besoin de catalogue : décrire des jeux de données, publier des ressources, organiser les responsabilités entre producteurs et administrateurs, et rendre l’ensemble découvrable par recherche et API.

Les premiers essais ont révélé des erreurs de substitution dans les fichiers gérés, une confusion entre hôte public et URL interne, et des dépendances de démarrage trop optimistes.

Coolify ajoute son propre proxy, sa gestion des domaines, ses variables magiques, ses fichiers gérés et son cycle de redéploiement. Chaque adaptation devait donc être analysée à la frontière entre la plateforme et le logiciel. Un portail utile commence donc par un schéma de métadonnées, une politique de publication et un circuit de mise à jour, avant le choix des extensions ou de l’habillage.

Le diagnostic a suivi les couches dans l’ordre : validation de la composition, création des services, santé des magasins d’état, fin des tâches d’initialisation, réponse du service public, authentification et parcours fonctionnel. Cette méthode évite de confondre un problème de réseau avec une migration inachevée ou un secret incohérent. La composition associe l’application CKAN, un worker RQ, DataPusher, PostgreSQL pour les métadonnées et le DataStore, Solr pour l’index et Redis pour les tâches.

Les journaux ont été lus par responsabilité. Un échec de la passerelle ne signifie pas nécessairement que la base est en cause ; un conteneur actif ne garantit pas qu’un worker consomme une vraie tâche. Les contrôles ont donc porté sur les effets observables de chaque service. Le stockage de fichiers complète cet ensemble.

La composition finale a corrigé les fichiers montés, séparé l’origine canonique de l’URL interne et donné à chaque composant un contrôle cohérent. Le parcours a traversé organisation, jeu de données, CSV, DataPusher, DataStore, API et Solr.

La correction retenue est la plus petite modification capable de rétablir le contrat du produit. Les services dont l’utilité était démontrée ont été conservés ; les composants ajoutés uniquement par habitude ont été écartés. Le domaine public reste attaché à CKAN ; DataPusher et les magasins d’état utilisent le réseau interne et ne doivent pas recevoir de route publique.

Connexion administrateur, organisation, jeu de données, import d’un csv de 1 193 lignes, aperçu datastore, api, recherche, worker, redéploiement. La validation ne s’est pas arrêtée à la page d’accueil.

Le parcours part d’une ressource neuve et se termine par un redéploiement avec conservation des données. Lorsqu’une sauvegarde et une restauration sont prévues, la vérification se fait dans des volumes isolés et revient à l’interface pour contrôler un objet métier connu. Elle a créé une organisation et un jeu de données, importé un CSV de 1 193 lignes, ouvert l’aperçu DataStore, interrogé l’API, vérifié la recherche et observé le worker après redéploiement.

La base principale, le DataStore et les fichiers forment le cœur de la reprise ; l’index de recherche peut être reconstruit.

Les volumes sont classés selon leur rôle : état autoritatif, fichier métier, file durable, cache reconstructible ou journal opérationnel. Cette classification détermine l’ordre de sauvegarde, l’ordre de restauration et les tests nécessaires avant remise en service. Cette chaîne a permis de distinguer l’état sain de PostgreSQL de l’initialisation réelle du DataStore et de l’index Solr.

Une adaptation fiable commence par comprendre le logiciel, pas par compter les conteneurs. La complexité utile provient des responsabilités réelles : base, recherche, files, tâches, temps réel, passerelle ou stockage. La plateforme doit simplifier leur exploitation sans modifier silencieusement leur contrat. Le Compose doit être relu avec trois contrats en tête : le fichier de configuration CKAN monté comme fichier, les URL internes utilisées par DataPusher et les tâches, et le hook d’initialisation réellement exécuté par l’image.

Les domaines publics, les URL canoniques et les cibles internes doivent rester distincts. Les secrets partagés utilisent une identité stable. Les migrations ont un seul propriétaire. Les contrôles de santé observent la fonction du service et la reprise porte sur tous les états qui rendent l’application utilisable. Les signes dollar placés dans un contenu géré ne suivent pas les mêmes règles que ceux d’une commande Compose ; les échapper mécaniquement peut rendre la configuration invalide.

Le modèle Docker Compose et le guide de déploiement associés permettent de reproduire l’architecture. Pour une nouvelle version, le travail reprend par la lecture des changements amont, une sauvegarde restaurable et un environnement isolé. Le même parcours fonctionnel sert ensuite de test de non-régression. CKAN répond à un besoin de catalogue : décrire des jeux de données, publier des ressources, organiser les responsabilités entre producteurs et administrateurs, et rendre l’ensemble découvrable par recherche et API.

Le passage en exploitation réunit le responsable fonctionnel, l’administrateur de l’application et l’équipe infrastructure. Ensemble, ils confirment les comptes, les droits, le courrier sortant, les domaines, les sauvegardes, la supervision et la procédure d’assistance. Les utilisateurs disposent d’un point d’entrée unique et d’instructions adaptées à leur rôle. Un portail utile commence donc par un schéma de métadonnées, une politique de publication et un circuit de mise à jour, avant le choix des extensions ou de l’habillage.

Une fenêtre de maintenance est définie pour les mises à jour. Les changements de version sont d’abord reproduits sur une copie isolée, puis le parcours critique est rejoué. Les observations sont consignées dans une procédure courte afin que le service ne dépende pas d’une mémoire individuelle. La composition associe l’application CKAN, un worker RQ, DataPusher, PostgreSQL pour les métadonnées et le DataStore, Solr pour l’index et Redis pour les tâches.

Cette étude renforce une règle simple : l’architecture doit être expliquée par les responsabilités qu’elle remplit. Chaque service, volume, variable et contrôle de santé répond à une fonction identifiable. Lorsqu’une modification ne peut pas être reliée à cette carte, elle mérite d’être remise en question. Le stockage de fichiers complète cet ensemble.

La validation doit ensuite suivre la même logique. Elle commence par l’infrastructure, traverse le produit et revient jusqu’à la décision de l’utilisateur. La restauration referme la boucle en montrant que l’organisation peut récupérer son service et ses données après un incident. Le domaine public reste attaché à CKAN ; DataPusher et les magasins d’état utilisent le réseau interne et ne doivent pas recevoir de route publique.

Chaque itération a été traitée comme une hypothèse à vérifier. Une composition valide était d’abord déployée sur une ressource neuve. L’équipe observait ensuite le premier service qui ne remplissait pas sa responsabilité, corrigeait la cause la plus proche et rejouait le parcours depuis le début. Cette chronologie a empêché l’accumulation de modifications sans relation avec le problème. La validation ne s’est pas arrêtée à la page d’accueil.

Les corrections ont été comparées avec l’architecture attendue et avec les effets visibles dans l’application. Lorsqu’un changement améliorait le démarrage mais cassait une fonction, il était rejeté. L’architecture finale conserve ainsi les choix qui satisfont ensemble installation, usage, persistance et reprise. Elle a créé une organisation et un jeu de données, importé un CSV de 1 193 lignes, ouvert l’aperçu DataStore, interrogé l’API, vérifié la recherche et observé le worker après redéploiement.

Trois décisions reviennent dans le cas : choisir le bon service public, attribuer clairement l’initialisation et protéger tout l’état autoritatif. Elles conditionnent le domaine, les contrôles de santé, les dépendances et la stratégie de sauvegarde. Leur formulation explicite facilite le passage de relais vers l’équipe d’exploitation. Cette chaîne a permis de distinguer l’état sain de PostgreSQL de l’initialisation réelle du DataStore et de l’index Solr.

Après la mise en service, les contrôles sont rejoués à intervalles réguliers : connexion, création ou modification d’un objet, traitement différé, redéploiement et lecture des données. Un exercice de restauration planifié vérifie que les sauvegardes restent compatibles avec la version courante et que l’équipe sait reconstruire le service. Le Compose doit être relu avec trois contrats en tête : le fichier de configuration CKAN monté comme fichier, les URL internes utilisées par DataPusher et les tâches, et le hook d’initialisation réellement exécuté par l’image.

La validation ne s’est pas arrêtée à la page d’accueil. Elle a créé une organisation et un jeu de données, importé un CSV de 1 193 lignes, ouvert l’aperçu DataStore, interrogé l’API, vérifié la recherche et observé le worker après redéploiement. Cette chaîne a permis de distinguer l’état sain de PostgreSQL de l’initialisation réelle du DataStore et de l’index Solr.