Skip to content

Run fetchers with Tekton in Kubernetes

Follows #694 (closed)

Part of #666

Description

GitLab Runner in Kubernetes has several drawbacks, the most important is the impossibility of using dynamic storage volumes, leading to use a NFS server with pretty bad file I/O performance, leading to issues like #785.

Tekton has been tried successfully to replace GitLab Runner to run fetchers. This issue describes and tracks the tasks.

Tasks

Pour la bascule

  • convert the pipeline to Tekton
  • deploy JSON-data to DBnomics Kubernetes instance #747 (closed)
  • deploy JSON-data to DBnomics production instance (cf below)
  • Adapter les fetchers stars dont OECD
  • Adapter les autres fetchers
  • Remplacer les cp par des rsync, car pour des données de plusieurs 10aines de Go ce sera beaucoup plus rapide.
  • Déployer Tekton Dashboard
  • Persister les logs des pipelines Tekton (via Loki) pour être interrogés par Tekton Dashboard
  • Enlever les affinity/antiAffinity de base, afin que DBnomics puisse fonctionner sur un seul node (minikube ou k3s).
  • Appeler le script de validation des données après le convert (@cbenz )
  • séparer le download du convert pour économiser des ressources
  • Rendre standard les fetchers non-standard (FAO et JHU avec download.sh)
  • Permettre de démarrer la pipeline au convert tout en lisant les source-data depuis un bucket (en les répliquant sur un volume, ou en utilisant un proxy file-system vers S3) (e.g. CEPII)
  • Gérer les fetchers avec mode incrémental (Enedis, Eurostat, IMF, INSEE) : la pipeline passe des paramètres aux scripts download et convert (--from-datetime et --previous-category-tree)
  • Corriger les fetchers qui lisent les données précédentes (Eurostat, Destatis, autres ?) (indices : dulwich, shutil, --full, --all-datasets)
  • Rétablir l'info "updated at" sur le front (l'API doit lire ces infos depuis S3)

Avant de fermer l'issue

  • résilier alpos (s3.db.nomics.world)
  • ramener les .gitlab-ci.yml de chaque fetcher à AutoDevOps pour construire l'image de conteneur, ou bien une CI commune sourcée, et supprimer les jobs download/convert/index/validate

Post-bascule

  • Tester l'interopérabilité sur le cloud OVH
  • Empêcher une pipeline de démarrer si une autre est déjà en cours pour le même fetcher
  • Find how to define many schedule times per cronjob, or use many cronjobs for INSEE
  • Importer l'historique Git des source-data et json-data
  • supprimer les PipelineRuns qui sont "successful" pour libérer les volumes {fetcher-name}-source-data et {fetcher-name}-json-data (cf Tekton Cleanup ou https://codeberg.org/hjacobs/kube-janitor)
  • measure fetchers real resource usage
  • supporter et visualiser les erreurs partielles ("error artifact")

Documentation

  • What are the possible properties on the JSON object sent by CronJobs?

Deprecated

This is a long-lived issue; some tasks were deprecated during its completion. They are kept here for the record.

Tasks

  • Pushing data to JSON-data repositories should deploy it to DBnomics production instance. However the switch from the original GitLab Runner pipeline to the GitLab Runner + Kubernetes one removed the webhooks on the JSON-data repositories. They will have to be set-up again (cf #694 (closed))
  • Ne lancer le convert d'un fetcher que si le download a changé le git des source-data. désormais un fetcher écrit dans des répertoires vides
  • (n'est plus applicable) Modifier le pipeline afin de ne pas multiplier les tâches de sync en fonction de la mémoire des fetchs. Pour cela, les tasks (ou steps) doivent retourner un flag et la task/step suivant doit être conditionné à ce flag
  • (n'est plus applicable depuis le passage à S3) Améliorer les message de commit
  • (n'est plus applicable depuis le passage à S3) Lorsqu'on lance un sync-json-data ou un sync-source-data, il arrive que le script ne détecte pas l'existence du repository et lance un git clone. Peut-être est ce que le volume n'est pas encore complètement monté. Si le répertoire n'existe pas il faudrait donc faire un sleep de 10s par exemple et réessayer
  • Installer une version cloud (multi nodes) de Solr non, solr-operator ne gérant pas les "configsets", on reste en mono-nœud. On verra plus tard soit avec une prochaine version de solr-operator, soit en utilisant Solr helm chart.
  • (utilisation de Tekton dashboard à place) port the Dashboard to Tekton pipelines
  • (n'est plus applicable depuis le passage à S3) Avoir plusieurs capacités mémoires pour les scripts de sync, si git prend beaucoup de mémoire.
  • Avoir une sauvegarde. Est-ce utile, sachant que Scaleway s'occupe d'avoir des volumes avec un block storage redondant ? Pas de sauvegarde car MinIO est distribué avec Erasure Coding

Caveats

Edited by Christophe Benz