L’un des apports principaux des innovations récentes de la data-science est la manière dont des projets, malgré leur complexité, peuvent facilement être converti en projets pérennes à partir d’un prototype bien construit. En s’inspirant de l’approche devops , méthode de travail qui consiste à adopter un certain nombre de gestes pour automatiser la production de livrables ou de tests dès la conception du produit, les data-scientists ont adopté une méthode de travail très efficace pour favoriser la réutilisation de leur travail par d’autres équipes que celles à l’origine de la conception du protype initial.

Cette approche devops a été reprise et étendue pour donner un autre buzz-word, le MLops. Il s’agit d’une approche qui vise à créer et mettre à disposition des modèles de machine learning de manière fiable et automatisée à chaque nouvelle étape du projet, en parallèle de la mise à jour du code ayant produit ces output.

Ces nouvelles méthodes de travail permettent des gains substantiels de productivité pour les équipes développant des modèles et réduit fortement le coût de reprise d’un code par une équipe en charge de sa pérenisation. Ce coût est en effet le principal frein à la mise en production de nouveaux projets ce qui peut représenter un gâchis non négligeable de temps et de ressources. Comme nous l’expliquons avec Romain Avouac dans un cours de dernière année de l’ENSAE (https://ensae-reproductibilite.netlify.app/), l’adoption de certaines bonnes pratiques de développement de code et d’une démarche exploitant les dernières innovations de la data-science peut substantiellement augmenter les chances d’un succès d’un projet. Le nouveau paradigme, qui consiste à intégrer en amont du projet certaines contraintes de la production et tester continuellement la manière dont les livrables évoluent, évite que la mise en production d’un projet, qui est coûteuse en temps et en ressources, n’aboutisse qu’au moment où le projet est déjà caduc (car les données ou les besoins ont évolués…).

L’intégration continue: une opportunité pour les data-scientists

On retrouve régulièrement l’acronyme CI/CD pour illustrer cette nouvelle méthode de travail dans le monde du développement logiciel :

• l’intégration continue (CI pour continuous integration) est une pratique consistant, de manière automatique, à fréquemment tester les effets d’une modification faite à un code ou à un document faisant parti d’un projet informatique.

• le déploiement en continu (CD pour continuous delivery) consiste à intégrer de manière automatisée la production d’un ou plusieurs livrables (environnement portable, application, site web, etc.) à chaque modification du code associé à un projet informatique.

Cette pratique permet ainsi de détecter de manière précoce des possibilités de bug ou l’introduction d’un changement non anticipé. Tout comme Git, cette pratique devient un standard dans les domaines collaboratifs.

L’intégration continue permet de sécuriser le travail, puisqu’elle offre un filet de sécurité (par exemple un test sur une machine à la configuration arbitraire), mais permet aussi de déployer en temps réel certaines évolutions. On parle parfois de déploiement en continu, complémentaire de l’intégration continue. Cette approche réduit ainsi la muraille de Chine entre un analyste de données et une équipe de développeurs d’application. Elle offre donc plus de contrôle, pour le producteur d’une analyse statistique, sur la valorisation de celle-ci.

Cette approche consiste une excellente opportunité pour les data-scientists d’être en mesure de valoriser leurs projets auprès de publics aux exigences différentes. Pour des développeurs, le data-scientist pourra fournir une image Docker (environnement portable où l’ensemble des dépendances et des configurations systèmes pour faire tourner un code sont contrôlés) permettant à d’autres d’exécuter facilement le code d’un projet. Pour faciliter la réutilisation d’un modèle par d’autres data-scientists, il devient de plus en plus fréquent d’exposer un modèle sous forme d’API: les personnes désirant réutiliser le modèle peuvent directement l’appliquer en accédant à une prédiction par le biais d’une API ce qui évite d’avoir à fournir le jeu d’entraînement si ce dernier est sensible. Pour toucher des publics moins familiers du code, la mise à disposition de sites web interactifs valorisant certains résultats d’un projet peut être intéressante. Cette approche très exigeante d’utiliser un même projet pour toucher des cibles très différentes est grandement facilitée par le déploiement en continu et la mise à disposition de librairies ou d’infrastructures dédiées dans le monde de l’open-source.

Tout en restant éco-responsable (voir partie XXX), cela permet de mieux valoriser des projets pour réduire les coûts à le maintenir et le faire évoluer. Le cours de dernière année de l’ENSAE que je développe avec Romain Avouac (https://ensae-reproductibilite.netlify.app/) présente beaucoup plus de détails sur cette question.

L’intégration continue en pratique

L’intégration continue fonctionne très bien sur Gitlab et sur Github. A chaque interaction avec le dépôt distant (push), une série d’instruction définie par l’utilisateur est exécutée. Python et R s’intègrent très bien dans ce paradigme grâce à un certain nombre d’images de base (concept sur lequel nous allons revenir) qui peuvent être customisées pour répondre à une certaine configuration nécessaire pour exécuter des codes (voir ici pour quelques éléments sur R. C’est une méthode idéale pour améliorer la reproductibilité d’un projet: les instructions exécutées le sont dans un environnement isolé et contrôlé, ce qui diffère d’une machine personnelle.

Comment fonctionne l’intégration continue ?

L’intégration continue repose sur le système de la dockerisation ou conteneurisation. La technologie sous jacente s’appelle Docker. Il s’agit d’une technologie qui permet la construction de machines autosuffisantes (que l’on nomme containeurs) répliquant un environnement contrôlé (que l’on nomme image).

On parle de pipelines pour désigner une suite de tâches pour partir de 0 (généralement une machine Linux à la configuration minimale) et aboutir à l’issue d’une série d’instructions définies par l’utilisateur.

L’objectif est de trouver une image la plus parcimonieuse possible, c’est-à-dire à la configuration minimale, qui permet de faire tourner le code voulu. Les Actions Github consistuent un modèle sur lequel il est facile de s’appuyer lorsqu’on a des connaissances limitées concernant `Docker. Il est également très simple de construire son image de rien, ce qui est la démarche choisie dans l’autre cours de l’ENSAE que nous donnons avec Romain Avouac (https://ensae-reproductibilite.netlify.app/).

Quand on utilise un dépôt Github ou Gitlab , des services automatiques d’intégration continue peuvent être utilisés:

• Gitlab CI: solution pleinement intégrée à un dépôt Gitlab. Très généraliste et permettant des pipelines très complexes (voir l’intégration continue du projet utilitR, une documentation pour R). Il est également possible de l’utiliser avec un dépôt stocké sur Github. L’inconvénient de cette approche est qu’elle est assez lente.
• Github Actions: c’est l’alternative (relativement récente) au service d’intégration continue de Gitlab uniquement basée sur les technologies Github. La très forte dynamique de développement a rendu ce service incontournable. Un grand nombre de scripts pré-définis et paramétrables facilitent l’entrée dans le monde de l’intégration continue.

Historiquement, il existait d’autres services d’intégration continue, notamment Travis CI ou AppVeyor¹

Fonctionnement des actions Github

Les actions Github fonctionnent par couches successives au sein desquelles on effectue un certain nombre d’instructions. La meilleure manière d’apprendre les actions Github est, certes, de lire la documentation officielle mais surtout, à mon avis, de regarder quelques pipelines pour comprendre la démarche.

L’un des intérêts des Github Actions est la possibilité d’avoir un pipeline proposant une intrication de langages différents pour avoir une chaine de production qui propose les outils les plus efficaces pour répondre à un objectif en limitant les verrous techniques.

Par exemple, le pipeline de ce cours, disponible sur Github propose une intrication des langages Python et R avec des technologies Anaconda (pour contrôler l’environnement Python comme expliqué dans les chapitres précédents) et Javascript (pour le déploiement d’un site web avec le service tiers Netlify)². Cette chaîne de production multi-langage permet que les mêmes fichiers sources génèrent un site web et des notebooks disponibles sur plusieurs environnements.

name: Docker Build and Website Deploy

on:
  push:
    branches:
      - main
      - master

jobs:
  blogdown:
    name: Render-Blog
    runs-on: ubuntu-latest
    container: linogaliana/python-datascientist:latest
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.ref }}
          repository: ${{github.event.pull_request.head.repo.full_name}}
      - name: Configure safe.directory  # Workaround for actions/checkout#760
        run: git config --global --add safe.directory /__w/python-datascientist/python-datascientist
      - shell: bash
        run: |
          conda info
          conda list
      - name: Build to md
        run: |
          quarto render --to hugo
          mv content/course/manipulation/index.md content/course/manipulation/_index.md
          mv content/course/visualisation/index.md content/course/visualisation/_index.md
          mv content/course/modelisation/index.md content/course/modelisation/_index.md
          mv content/course/index.md content/course/_index.md
          python build/wc_website.py
          python build/tweak_markdown.py
          hugo
      - name: Install npm
        uses: actions/setup-node@v2          
        with:
          node-version: '14'        
      - name: Deploy to Netlify
        # NETLIFY_AUTH_TOKEN and NETLIFY_SITE_ID added in the repo's secrets
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
          BRANCHE_REF: ${{ github.event.pull_request.head.ref }}
        run: |
          npm init -y
          npm install --unsafe-perm=true netlify-cli -g
          netlify init
          netlify deploy --prod --dir="public" --message "Deploy master"
      - uses: actions/upload-artifact@v1
        with:
          name: public
          path: public/

Les couches qui constituent les étapes du pipeline portent ainsi le nom de steps. Un step peut comporter un certain nombre d’instructions ou exécuter des instructions pré-définies. L’une de ces instructions prédéfinies est, par exemple, l’installation de Python ou l’initialisation d’un environnement conda. La documentation officielle de Github propose un fichier qui peut servir de modèle pour tester un script Python voire l’uploader de manière automatique sur Pypi.

Intégration continue avec Python: tester un notebook

Cette section n’est absolument pas exhaustive. Au contraire, elle ne fournit qu’un exemple minimal pour expliquer la logique de l’intégration continue. Il ne s’agit ainsi pas d’une garantie absolue de reproductibilité d’un notebook.

Github propose une action officielle pour utiliser Python dans un pipeline d’intégration continue. Elle est disponible sur le MarketPlace Github. Il s’agit d’un bon point de départ, à enrichir.

Le fichier qui contrôle les instructions exécutées dans l’environnement Actions doit se trouver dans le dossier .github/workflows/ (⚠️ ne pas oublier le point au début du nom du dossier). Il doit être au format YAML avec une extension .yml ou .yaml. Il peut avoir n’importe quel nom néanmoins il vaut mieux lui donner un nom signifiant, par exemple prod.yml pour un fichier contrôlant une chaîne de production.

Lister les dépendances

Avant d’écrire les instructions à exécuter par Github, il faut définir un environnement d’exécution car Github ne connaît pas la configuration Python dont vous avez besoin.

Il convient ainsi de lister les dépendances nécessaires dans un fichier requirements.txt (si on utilise un environnement virtuel) ou un fichier environment.yml (si on préfère utiliser un environnement conda). Bien que le principe sous-jacent soit légèrement différent, ces fichiers ont la même fonction: permettre la création d’un environnement ex-nihilo avec un certain nombre de dépendances pré-installées³.

Si on fait le choix de l’option environment.yml, le fichier prendra ainsi la forme suivante, à enrichir en fonction de la richesse de l’environnement souhaité. :

channels:
  - conda-forge

dependencies:
  - python>=3.10
  - jupyter
  - jupytext
  - matplotlib
  - nbconvert
  - numpy
  - pandas
  - scipy
  - seaborn

Le même fichier sous le format requirements.txt aura la forme suivante:

jupyter
jupytext
matplotlib
nbconvert
numpy
pandas
scipy
seaborn

Sous leur apparente équivalence, au-delà de la question du formatage, ces fichiers ont deux différences principales :

• la version minimale de Python est définie dans le fichier environment.yml alors qu’elle ne l’est pas dans un fichier requirements.txt. C’est parce que le second installe les dépendances dans un environnement déjà existant par ailleurs alors que le premier peut servir à créer l’environnement avec une certaine configuration de Python ;
• le mode d’installation des packages n’est pas le même. Avec un environment.yml on installera des packages via conda alors qu’avec un requirements.txt on privilégiera plutôt pip⁴.

Dans le cas de l’environnement conda, le choix du channel conda-forge vise à contrôler le dépôt utilisé par Anaconda.

Ne pas oublier de mettre ce fichier sous contrôle de version et de l’envoyer sur le dépôt par un push.

Créer un environnement reproductible dans Github Actions

Deux approches sont possibles à ce niveau, selon le degré de reproductibilité désiré⁵:

• Créer l’environnement via une action existante. L’action conda-incubator/setup-miniconda@v2 est un bon point de départ.
• Créer l’environnement dans une image Docker.

La deuxième solution permet de contrôler de manière beaucoup plus fine l’environnement dans lequel Python s’éxécutera ainsi que la manière dont l’environnement sera créé⁶. Néanmoins, elle nécessite des connaissances plus poussées dans la principe de la conteneurisation qui peuvent être coûteuses à acquérir. Selon l’ambition du projet, notamment les réutilisation qu’il désire, un data-scientist pourra privilégier telle ou telle option. Les deux solutions sont présentées dans l’exemple fil-rouge du cours que nous donnons avec Romain Avouac (https://ensae-reproductibilite.netlify.app/application/).

Tester un notebook myfile.ipynb

Dans cette partie, on va supposer que le notebook à tester s’appelle myfile.ipynb et se trouve à la racine du dépôt. Les dépendances pour l’exécuter sont listées dans un fichier requirements.txt.

Le modèle suivant, expliqué en dessous, fournit un modèle de recette pour tester un notebook. Supposons que ce fichier soit présent dans un chemin .github/workflows/test-notebook.yml

name: Test notebook execution using Github Actions

on: [push]

jobs:
  build-linux:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.10
      uses: actions/setup-python@v3
      with:
        python-version: '3.10'
      - shell: bash
      run: |
                python --version
    - name: Install dependencies
      run:
        pip install -r requirements.txt
        pip install jupyter nbconvert
    - name: Test jupyter from command line
      run:
        jupyter nbconvert --execute --to notebook --inplace myfile.ipynb
    - uses: actions/upload-artifact@v3
      with:
        name: Notebook
        path: myfile.ipynb
        retention-days: 5

name: Test notebook execution using Github Actions

on: [push]

jobs:
  build-linux:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.10
      uses: actions/setup-python@v3
      with:
        python-version: '3.10'
    - name: Add conda to system path
      run: |
        # $CONDA is an environment variable pointing to the root of the miniconda directory
        echo $CONDA/bin >> $GITHUB_PATH        
    - name: Install dependencies
      run: |
        conda env update --file environment.yml --name base
        conda install jupyter nbconvert        
    - name: Test jupyter from command line
      run:
        jupyter nbconvert --execute --to notebook --inplace myfile.ipynb
    - uses: actions/upload-artifact@v3
      with:
        name: Notebook
        path: myfile.ipynb
        retention-days: 5

Dans les deux cas, la démarche est la même:

• on récupère les fichiers présents dans le dépôt (action checkout) ;
• on installe Python ;
• on installe les dépendances pour exécuter le code. Dans l’approche conda, il est également nécessaire de faire quelques configurations supplémentaires (notamment ajouter conda aux logiciels reconnus par la ligne de commande) ;
• on teste le notebook en ligne de commande et remplace celui existant, sur la machine temporaire, par la version produite sur cet environnement neutre.
• on rend possible le téléchargement du notebook produit automatiquement pendant 5 jours⁷. Ceci repose sur les artefacts qui sont un élément récupéré des machines temporaires qui n’existent plus dès que le code a fini d’être exécuté.

Ces actions sont exécutées à chaque interaction avec le dépôt distant (push), quelle que soit la branche. A partir de ce modèle, il est possible de raffiner pour, par exemple, automatiquement faire un commit du notebook validé et le pusher via le robot Github⁸

Mettre à disposition en continu des valorisations du projet

Les projets de valorisation de données prennent des formes très variées et s’adressent à des publics multiples dont les attentes peuvent être très diverses. Ne pas attendre la finalisation d’un projet pour mettre en oeuvre certains livrables est une méthode efficace pour ne pas se retrouver noyé, au dernier moment, sous des demandes et de nouvelles contraintes.

La production en continu de livrables est donc une méthode très prisée dans le monde de la donnée. Les principaux fournisseurs de services d’intégration continue, à commencer par Github et Gitlab proposent des services pour le déploiement en continu. Cependant, ceux-ci ne sont adaptés qu’à certains types de livrables, principalement la mise à disposition de sites internet, et il peut être intéressant d’utiliser des services externes ou une infrastructures Kubernetes selon les moyens à dispositon et les besoins des utilisateurs.

Les services de mise à disposition de Github et Gitlab

Github et Gitlab, les deux plateformes de partage de code, proposent non seulement des services gratuits d’intégration continue mais aussi des services de mise à disposition de sites web pleinement intégrés aux services de stockage de code.

Ces services, Gitlab Pages et Github Pages, auxquels on peut associer le service externe Netlify qui répond au même principe⁹ permettent, à chaque modification du code source d’un projet, de reconstruire le site web (le livrable) qui peut être directement produit à partir de certains fichiers (des slides revealJS par exemple) ou qui sert d’output à l’intégration continue après compilation de fichiers plus complexes (des fichiers quarto par exemple).

Chaque dépôt sur Github ou Gitlab peut ainsi être associé à un URL de déploiement disponible sur internet. A chaque commit sur le dépôt, le site web qui sert de livrable est ainsi mis à jour. La version déployée à partir de la branche principale peut ainsi être considérée comme la version de production alors que les branches secondaires peuvent servir d’espace bac à sable pour vérifier que des changements dans le code source ne mettent pas en péril le livrable. Cette méthode, qui sécurise la production d’un livrable sous forme de site web, est ainsi particulièrement appréciable.

Les services externes disponibles sans infrastructure spéciale

Pour fonctionner, l’intégration continue nécessite de mettre en oeuvre des environnements normalisés. Comme évoqué précédemment, la technologie sous-jacente est celle de la conteneurisation. Les images qui servent de point de départ au lancement d’un conteneur sont elles-mêmes mises à disposition dans des espaces communautaires (des registres d’images). Il en existe plusieurs, les plus connus étant le dockerhub ou le registry de Gitlab. Ces registres servent d’espaces de stockage pour des images, qui sont des objets volumineux (potentiellement plusieurs Gigas) mais aussi d’espace de mutualisation en permettant à d’autres de réutiliser une image prête à l’emploi ou, au contraire, à partir de laquelle on peut ajouter un certain nombre de couches pour obtenir l’environnement minimal de reproductibilité. Il est possible d’utiliser certaines actions Github prête à l’emploi pour constuire une image Docker à partir d’un fichier Dockerfile. Après avoir crée une connexion entre un compte sur la plateforme Github et l’autre sur DockerHub, une mise à disposition automatisée d’un livrable sous forme d’image Docker est ainsi possible.

Une image Docker peut offrir une grande variété d’output. Elle peut servir uniquement à mettre à disposition un environnement de reproductibilité mais elle peut servir à mettre à disposition, pour les personnes maîtrisant Docker, des output plus raffinés. Par exemple, dans le cours que nous donnons à l’ENSAE, nous montrons comment docker peut servir à mettre à disposition à un utilisateur tiers une application minimaliste (construite avec flask) qu’il fera tourner sur son ordinateur.

Si une image Docker peut être très utile pour la mise à disposition, elle nécessite pour sa réutilisation un niveau avancé d’expertise en programmation. Cela ne conviendra pas à tous les publics. Certains ne désireront que bénéficier d’une application interactive où ils pourrons visualiser certains résultats en fonction d’actions comme des filtres sur des sous-champs ou le choix de certaines plages de données. D’autres publics seront plutôt intéressé par la réutilisation d’un programme ou des résultats d’un modèle sous forme d’API mais n’auront pas l’infrastructure interne pour faire tourner le code d’origine ou une image Docker. C’est pour répondre à ces limites qu’il peut devenir intéressant, pour une équipe de data-science de développer une architecture kubernetes interne, si l’organisation en a les moyens, ou de payer un fournisseur de service, comme AWS, qui permet cela.

Kubernetes: le sommet de la pente du déploiement

Kubernetes est une technologie qui pousse la logique de la conteneurisation à son paroxysme. Il s’agit d’un système open-source, développé par Google, permettant d’automatiser le déploiement, la mise à l’échelle et la gestion d’applications conteneurisées. Grâce à Kubernetes, une application, par exemple un site web proposant de la réactivité, peut être mise à disposition et reporter les calculs, lorsqu’ils sont nécessaires, sur un serveur. L’utilisation de Kubernetes dans un projet de data-science permet ainsi d’anticiper à la fois l’interface d’une application valorisant un projet mais aussi le fonctionnement du back-office, par exemple en testant la capacité de charge de cette application. Une introduction à Kubernetes orienté donnée peut être trouvée dans le cours dédié à la mise en production que nous donnons avec Romain Avouac et dans ce post de blog très bien fait.

Dans les grandes organisations, où les rôles sont plus spécialisés que dans les petites structures, ce ne sont pas nécessairement les data-scientists qui devront maîtriser Kubernetes mais plutôt les data-architect ou les data-engineer. Néanmoins, les data-scientists devront être capable de dialoguer avec eux et mettre en oeuvre une méthode de travail adaptée (celle-ci reposera en principe sur l’approche CI/CD). Dans les petites structures, les data-scientist peuvent être en mesure de mettre en oeuvre le déploiement en continu. En revanche, il est plus rare, dans ces structures, où les moyens humains de maintenance sont limités, que les serveurs sur lesquels fonctionnent Kubernetes soient détenus en propres. En général, ils sont loués dans des services de paiement à la demande de type AWS.

Références

• https://ensae-reproductibilite.netlify.app/
• https://towardsdatascience.com/from-jupyter-to-kubernetes-refactoring-and-deploying-notebooks-using-open-source-tools-19f99585e923

Annexe: la même approche d’intégration continue avec Travis

Travis est un système d’intégration continue qui était populaire avant l’émergence des Github Actions. La manière équivalente de procéder sur Travis par rapport à celle présentée précedemment serait:

# Modèle de fichier .travis.yml
language: python
python:
  - "3.10"

install:
  - sudo apt-get update
  # We do this conditionally because it saves us some downloading if the
  # version is the same.
  - if [[ "$TRAVIS_PYTHON_VERSION" == "2.7" ]]; then
      wget https://repo.continuum.io/miniconda/Miniconda2-latest-Linux-x86_64.sh -O miniconda.sh;
    else
      wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O miniconda.sh;
    fi
  - bash miniconda.sh -b -p $HOME/miniconda
  - export PATH="$HOME/miniconda/bin:$PATH"
  - hash -r
  - conda config --set always_yes yes --set changeps1 no
  - conda update -q conda
  # Useful for debugging any issues with conda
  - conda info -a
  - conda env create -n test-environment python=$TRAVIS_PYTHON_VERSION -f environment.yml
  - source activate test-environment

script:
  - jupytext --to py --execute myfile.ipynb