CKAN 2.12.0 sur Coolify

Portail complet avec DataStore et import tabulaire. Le déploiement conserve les responsabilités de l’application tout en confiant l’exposition HTTPS et le cycle du service à Coolify.

La composition comprend CKAN web, worker CKAN, DataPusher, PostgreSQL, Solr et Redis. Les services d’initialisation terminent leur tâche avant le fonctionnement courant ; les services web, workers et magasins d’état restent actifs. Les dépendances de démarrage s’appuient sur des contrôles de santé lorsqu’un service doit être réellement prêt avant le suivant.

L’état à protéger comprend les bases CKAN et DataStore, les fichiers CKAN, l’index Solr reconstructible et la file Redis. Les volumes nommés survivent au redéploiement des conteneurs. Ils doivent être inventoriés avec leur chemin, leur propriétaire et leur rôle afin que la sauvegarde couvre l’ensemble fonctionnel, pas seulement la base relationnelle.

Un seul service reçoit le domaine public principal. Les communications entre conteneurs utilisent les noms de services Docker et leurs ports internes. L’URL canonique de l’application doit correspondre à l’adresse utilisée par le navigateur ; les URL internes restent réservées aux échanges de service à service. Coolify termine TLS et transmet les en-têtes de proxy nécessaires. 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 domaines et valeurs non sensibles peuvent être configurés comme variables d’environnement. Les mots de passe, clés de signature et jetons doivent utiliser les générateurs de secrets de Coolify et conserver le même identifiant partout où une valeur partagée est attendue. Les valeurs générées font partie de l’identité du déploiement : elles ne doivent pas être recréées sans examiner l’état déjà persistant. 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.

La validation a couvert connexion administrateur, organisation, jeu de données, import d’un CSV de 1 193 lignes, aperçu DataStore, API, recherche, worker, redéploiement. Le contrôle commence par les états de santé, puis traverse un parcours réel dans l’application. Cette séquence vérifie ensemble le routage, l’authentification, l’écriture, la lecture, les tâches de fond et la conservation des données.

Exporter les deux bases postgresql et les fichiers ; reconstruire ou sauvegarder solr selon l’objectif de reprise. Une sauvegarde exploitable est produite en dehors des volumes courants, horodatée et associée à la version de l’application. La restauration s’effectue dans des volumes isolés avant toute substitution du service principal. Le test se termine par la lecture d’un objet métier connu dans l’interface.

Lire les notes de version et la procédure amont, créer une sauvegarde restaurable, dupliquer la configuration dans un environnement isolé, mettre à jour les images et exécuter les migrations. Le même parcours fonctionnel est rejoué avant promotion. Une image précédente n’est pas un mécanisme de retour arrière lorsque le schéma ou les données ont été transformés. 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.

Si le proxy répond mais que l’application reste indisponible, vérifier l’état du service public, son port interne et le domaine canonique. Si les migrations ne progressent pas, examiner la base, les identifiants partagés et le service qui possède le cycle d’initialisation. Si les workers sont instables, contrôler la file, le cache et les commandes propres au produit. Une erreur de persistance se diagnostique à partir des volumes montés et des permissions, sans supprimer les données. Le stockage de fichiers complète cet ensemble.

L’équipe suit la disponibilité du domaine, la santé des services, l’espace disque, la croissance de la base, les files de tâches et la date du dernier point de reprise. Les alertes doivent conduire à une action précise : relancer un traitement, augmenter une capacité, corriger un certificat, purger un cache ou déclencher une sauvegarde. 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.

Les changements de configuration sont datés et relus avant déploiement. Un registre d’exploitation indique la version, la personne responsable, les intégrations actives, les fenêtres de maintenance et la procédure de contact en cas d’incident. La validation ne s’est pas arrêtée à la page d’accueil.

Limiter l’exposition réseau au service public, protéger les interfaces d’administration et attribuer des comptes nominatifs. Les permissions applicatives suivent les rôles métier ; les accès au serveur et à Coolify restent réservés aux administrateurs. Les secrets ne sont ni placés dans le fichier téléchargé ni partagés dans les journaux. 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.

Les métriques utiles couvrent disponibilité, erreurs, temps de réponse, espace disque, connexions à la base et profondeur des files. Les journaux ont une durée de conservation définie et évitent les données personnelles inutiles. Une alerte n’est utile que si elle est reliée à une personne, un seuil et une action. Cette chaîne a permis de distinguer l’état sain de PostgreSQL de l’initialisation réelle du DataStore et de l’index Solr.

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.