Une application fil rouge pour illustrer l’intérêt d’appliquer graduellement les bonnes pratiques dans une optique de mise en production d’une application de data science.
L’objectif de cette mise en application est d’illustrer les différentes étapes qui séparent la phase de développement d’un projet de celle de la mise en production. Elle permettra de mettre en pratique les différents concepts présentés tout au long du cours.
L’objectif pédagogique principal de cette application est d’adopter un point de vue pragmatique en choisissant des outils et des méthodes de travail qui permettent de réaliser des objectifs ambitieux de valorisation de données. Python sera le trait d’union entre les différentes technologies ou infrastructures que nous utiliserons.
Cette application est un tutoriel pas à pas pour avoir un projet reproductible et disponible sous plusieurs livrables. Toutes les étapes ne sont pas indispensables à tous les projets de data science et il existe des outils alternatifs à ceux présentés. Néanmoins, les outils présentés ont l’avantage d’être très bien intégrés à Python, bien configurés si vous utilisez le SSPCloud comme nous le recommandons, tout en étant agnostiques sur le reste des outils que vous utilisez ; de sorte à ne pas être bloquants si on remplace l’une des briques logicielles par une autre.
Nous nous plaçons dans une situation initiale correspondant à la fin de la phase de développement d’un projet de data science. On a un notebook un peu monolithique, qui réalise les étapes classiques d’un pipeline de machine learning :
L’objectif est d’améliorer le projet de manière incrémentale jusqu’à pouvoir le mettre en production, en le valorisant sous une forme adaptée et en adoptant une méthode de travail fluidifiant les évolutions futures.
La Figure 1 montre que notre point de départ initial, à savoir un notebook, mélange tout. Ceci rend très complexe la mise à jour de notre modèle ou l’exploitation de notre modèle sur de nouvelles données, ce qui est pourtant la raison d’être du machine learning qui est pensé pour l’extrapolation. Si on vous demande de valoriser votre modèle sur de nouvelles données, vous risquez de devoir refaire tourner tout votre notebook, avec le risque de ne pas retrouver les mêmes résultats que dans la version précédente.
La Figure 2 illustre l’horizon auquel nous aboutirons à la fin de cette application. Nous désynchronisons les étapes d’entraînement et de prédiction, en identifiant mieux les pré-requis de chacunes et en adoptant des briques technologiques adaptées à celles-ci. Les noms présents sur cette figure sont encore obscurs, c’est normal, mais ils vous deviendrons familiers si vous adoptez une infrastructure et une méthode de travail à l’état de l’art.
Il est important de bien lire les consignes et d’y aller progressivement. Certaines étapes peuvent être rapides, d’autres plus fastidieuses ; certaines être assez guidées, d’autres vous laisser plus de liberté. Si vous n’effectuez pas une étape, vous risquez de ne pas pouvoir passer à l’étape suivante qui en dépend.
Bien que l’exercice soit applicable sur toute configuration bien faite, nous recommandons de privilégier l’utilisation du SSP Cloud, où tous les outils nécessaires sont pré-installés et pré-configurés. Le service VSCode ne sera en effet que le point d’entrée pour l’utilisation d’outils plus exigeants sur le plan de l’infrastructure: Argo, MLFLow, etc.
A l’heure actuelle, cette application se concentre sur la mise en oeuvre fiable de l’entraînement de modèles de machine learning. Comme vous pouvez le voir, quand on part d’aussi loin qu’un projet monolithique dans un notebook, c’est un travail conséquent d’en arriver à un pipeline pensé pour la production. Cette application vise à vous sensibiliser au fait qu’avoir la Figure 2 en tête et adopter une organisation de travail et faire des choix techniques adéquats, vous fera économiser des dizaines voire centaines d’heures lorsque votre modèle aura vocation à passer en production.
A l’heure actuelle, cette application ne se concentre que sur une partie du cycle de vie d’un projet data ; il y a déjà fort à faire. Nous nous concentrons sur l’entraînement et la mise à disposition d’un modèle à des fins opérationnelles. C’est la première partie du cycle de vie d’un modèle. Dans une approche MLOps, il faut également penser la maintenance de ce modèle et les enjeux que représentent l’arrivée continue de nouvelles données, ou le besoin d’en collecter de nouvelles à travers des annotations, sur la qualité prédictive d’un modèle. Toute entreprise qui ne pense pas cet après est vouée à se faire doubler par un nouveau venu. Une prochaine version de cette application permettra certainement d’illustrer certains des enjeux afférants à la vie en production d’un modèle (supervision, annotations…) sur notre cas d’usage.
Il convient aussi de noter que nous ne faisons que parcourir la surface des sujets que nous évoquons. Ce cours, déjà dense, deviendrait indigeste si nous devions présenter chaque outil dans le détail. Nous laissons donc les curieux approfondir chacun des outils que nous présentons pour découvrir comment en tirer le maximum (et si vous avez l’impression que nous oublions des éléments cruciaux, les issues et pull requests sont bienvenues).
Nous allons prendre comme point de départ un projet livré exclusivement avec un notebook, à la manière d’un challenge Kaggle. Vous pourrez ainsi voir à quel point ce type de livrable est très loin d’être satisfaisant si on veut que le projet soit réutilisable.
Les premières étapes consistent à mettre en place son environnement de travail sur Github:
Générer un jeton d’accès (token) sur GitHub afin de permettre l’authentification en ligne de commande à votre compte. La procédure est décrite ici. Vous ne voyez ce jeton qu’une fois, ne fermez pas la page de suite.
Mettez de côté ce jeton en l’enregistrant dans un gestionnaire de mot de passe ou dans l’espace “Mon compte” du SSP Cloud.
Forker le dépôt Github : https://github.com/ensae-reproductibilite/application en faisant attention à une option :
main branch only” afin de copier également les tags Git qui nous permettront de faire les checkpoint.
Nous recommandons d’utiliser, tout au long de ce projet, l’environnement de développement VSCode. En plus d’être très bien construit, les nombreuses extensions disponibles rendent celui-ci adaptable à tous nos besoins. Comme il s’agit de l’outil sur lequel vous passerez votre quotidien, n’hésitez pas à personnaliser celui-ci grâce aux nombreuses ressources disponibles en ligne1.
Il est maintenant possible de ce lancer dans la création de l’environnement de travail:
VSCode sur le SSP Cloud. Vous pouvez aller dans la page My Services et cliquer sur New service. Sinon, vous pouvez initialiser la création du service en cliquant directement ici. Modifier les options suivantes:
Role, sélectionner le rôle Admin ;Networking, cliquer sur “Enable a custom service port” et laisser la valeur par défaut 5000 pour le numéro du portInit, dans le champ PersonalInit, renseigner l’adresse https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/init.shGithub en utilisant le terminal depuis Visual Studio (Terminal > New Terminal) et en passant directement le token dans l’URL selon cette structure:terminal
$ git clone https://$TOKEN@github.com/$USERNAME/application.gitoù $TOKEN et $USERNAME sont à remplacer, respectivement, par le jeton que vous avez généré précédemment et votre nom d’utilisateur.
Ce script initialise quelques extensions intéressantes pour le développement de projets utilisant Python ou des fichiers textes type Markdown ou YAML: diagnostic, mise en forme automatisée, etc.
#!/bin/bash
# Define the configuration directory for VS Code
VSCODE_CONFIG_DIR="$HOME/.local/share/code-server/User"
# Create the configuration directory if necessary
mkdir -p "$VSCODE_CONFIG_DIR"
# User settings file
SETTINGS_FILE="$VSCODE_CONFIG_DIR/settings.json"
code-server --install-extension yzhang.markdown-all-in-one
code-server --install-extension oderwat.indent-rainbow
code-server --install-extension tamasfe.even-better-toml
code-server --install-extension aaron-bond.better-comments
code-server --install-extension github.vscode-github-actions
# Replace default flake8 linter with project-preconfigured ruff
code-server --uninstall-extension ms-python.flake8
code-server --install-extension charliermarsh.ruff
jq '. + {
"workbench.colorTheme": "Default Dark Modern", # Set the theme
"editor.rulers": [80, 100, 120], # Add specific vertical rulers
"files.trimTrailingWhitespace": true, # Automatically trim trailing whitespace
"files.insertFinalNewline": true, # Ensure files end with a newline
"flake8.args": [
"--max-line-length=100" # Max line length for Python linting
]
}' "$SETTINGS_FILE" > "$SETTINGS_FILE.tmp" && mv "$SETTINGS_FILE.tmp" "$SETTINGS_FILE"Si, dans quelques jours, vous désirez relancer un service avec cette configuration, vous pouvez cliquer sur ce lien:
En cliquant sur l’onglet Git, vous pouvez renseigner directement votre URL de la forme https://github.com/username/depot.git: cela clônera votre dépôt dans le service et injectera le token pour vous économiser l’authentification à venir lors de la phase de push.
Cette première partie vise à rendre le projet conforme aux bonnes pratiques présentées dans le cours.
Elle fait intervenir les notions suivantes :
Git (voir Rappels Git) ;Git et GitHub (voir Rappels Git).Le plan de la partie est le suivant :
On va partir du fichier notebook.py qui reprend le contenu du notebook2 mais dans un script classique. Le travail de nettoyage en sera facilité.
La première étape est simple, mais souvent oubliée : vérifier que le code fonctionne correctement. Pour cela, nous recommandons de faire un aller-retour entre le script ouvert dans VSCode et un terminal pour le lancer.
VSCode le script titanic.py ;python titanic.py)3 pour détecter les erreurs ;terminal
$ python titanic.pyLe code devrait afficher des sorties.
La première erreur rencontrée est une alerte FileNotFoundError, la seconde est liée à un package.
Il est maintenant temps de commit les changements effectués avec Git4 :
terminal
$ git add titanic.py
$ git commit -m "Corrige l'erreur qui empêchait l'exécution"
$ git pushterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli12
rm -f update.sh
On va maintenant améliorer la qualité de notre code en appliquant les standards communautaires. Pour cela, on va utiliser le linter classique PyLint et le formatter Black. Si vous désirez un outil deux en un, il est possible d’utiliser Ruff en complément ou substitut.
Ce nettoyage automatique du code permettra, au passage, de restructurer notre script de manière plus naturelle.
Le linter PyLint renvoie alors une série d’irrégularités, en précisant à chaque fois la ligne de l’erreur et le message d’erreur associé (ex : mauvaise identation). Il renvoie finalement une note sur 10, qui estime la qualité du code à l’aune des standards communautaires évoqués dans la partie Qualité du code.
titanic.py avec PyLint. Regarder la note obtenue.black titanic.py --diff --color pour observer les changements de forme que va induire l’utilisation du formatter Black. Cette étape n’applique pas les modifications, elle ne fait que vous les montrer.BlackPyLint pour diagnostiquer l’amélioration de la qualité du script et le travail qui reste à faire.terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli22
rm -f update.sh
Le code est maintenant lisible, il obtient à ce stade une note formelle proche de 10. Mais il n’est pas encore totalement intelligible ou fiable. Il y a notamment quelques redondances de code auxquelles nous allons nous attaquer par la suite. Néanmoins, avant cela, occupons-nous de mieux gérer certains paramètres du script: jetons d’API et chemin des fichiers.
VSCode actif avec la configuration proposée dans l'application préliminaire, vous pouvez repartir de ce service:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli22
rm -f update.sh
L’exécution du code et les résultats obtenus dépendent de certains paramètres définis dans le code. L’étude de résultats alternatifs, en jouant sur des variantes des (hyper)paramètres, est à ce stade compliquée car il est nécessaire de parcourir le code pour trouver ces paramètres. De plus, certains paramètres personnels comme des jetons d’API ou des mots de passe n’ont pas vocation à être présents dans le code.
Il est plus judicieux de considérer ces paramètres comme des variables d’entrée du script. Cela peut être fait de deux manières:
prenom.py
import argparse
parser = argparse.ArgumentParser(description="Qui êtes-vous?")
parser.add_argument(
"--prenom", type=str, default="Toto", help="Un prénom à afficher"
)
args = parser.parse_args()
print(args.prenom)Exemples d’utilisations en ligne de commande
terminal
$ python prenom.py
$ python prenom.py --prenom "Zinedine"n_trees qui peut éventuellement être paramétrée en ligne de commande et dont la valeur par défaut est 20 ;L’exercice suivant permet de mettre en application le fait de paramétriser un script en utilisant des variables définies dans un fichier YAML.
python-dotenv que nous allons utiliser pour charger notre jeton d’API à partir d’une variable d’environnement.load_dotenv pour charger dans Python nos variables d’environnement à partir d’un fichier (vous pouvez le créer mais ne pas le remplir encore avec les valeurs voulues, ce sera fait ensuite)Python en faisant tourner titanic.py en ligne de commandetitanic.py
jeton_api = os.environ.get("JETON_API", "")
if jeton_api.startswith("$"):
print("API token has been configured properly")
else:
print("API token has not been configured")dotenv.gitignore (cf. Chapitre Git). Ajouter dans ce fichier .env car il ne faut pas committer ce fichier. Au passage ajouter __pycache__/ au .gitignore5, cela évitera d’avoir à le faire ultérieurement ;README.md où vous indiquez qu’il faut créer un fichier .env pour pouvoir utiliser l’API.terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli32
rm -f update.sh
Nous allons mettre en fonctions les parties importantes de l’analyse. Ceci facilitera l’étape ultérieure de modularisation de notre projet. Comme cela est évoqué dans les éléments magistraux de ce cours, l’utilisation de fonctions va rendre notre code plus concis, plus traçable, mieux documenté.
Cet exercice étant chronophage, il n’est pas obligatoire de le réaliser en entier. L’important est de comprendre la démarche et d’adopter fréquemment une approche fonctionnelle6. Pour obtenir une chaine entièrement fonctionnalisée, vous pouvez reprendre le checkpoint.
Pour commencer, cet exercice fait un petit pas de côté pour faire comprendre la manière dont les pipelines scikit sont un outil au service des bonnes pratiques.
Scikit ?
Scikit d’estimation et d’évaluation vous a été donné tel quel. Regardez, ci-dessous, le code équivalent sans utiliser de pipeline Scikit:Le code équivalent sans pipeline
from sklearn.impute import SimpleImputer
from sklearn.preprocessing import MinMaxScaler, OneHotEncoder
from sklearn.compose import ColumnTransformer
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import confusion_matrix
import pandas as pd
import numpy as np
# Définition des variables
numeric_features = ["Age", "Fare"]
categorical_features = ["Embarked", "Sex"]
# PREPROCESSING ----------------------------
# Handling missing values for numerical features
num_imputer = SimpleImputer(strategy="median")
X_train[numeric_features] = num_imputer.fit_transform(X_train[numeric_features])
X_test[numeric_features] = num_imputer.transform(X_test[numeric_features])
# Scaling numerical features
scaler = MinMaxScaler()
X_train[numeric_features] = scaler.fit_transform(X_train[numeric_features])
X_test[numeric_features] = scaler.transform(X_test[numeric_features])
# Handling missing values for categorical features
cat_imputer = SimpleImputer(strategy="most_frequent")
X_train[categorical_features] = cat_imputer.fit_transform(X_train[categorical_features])
X_test[categorical_features] = cat_imputer.transform(X_test[categorical_features])
# One-hot encoding categorical features
encoder = OneHotEncoder(handle_unknown='ignore', sparse_output=False)
X_train_encoded = encoder.fit_transform(X_train[categorical_features])
X_test_encoded = encoder.transform(X_test[categorical_features])
# Convert encoded features into a DataFrame
X_train_encoded = pd.DataFrame(X_train_encoded, columns=encoder.get_feature_names_out(categorical_features), index=X_train.index)
X_test_encoded = pd.DataFrame(X_test_encoded, columns=encoder.get_feature_names_out(categorical_features), index=X_test.index)
# Drop original categorical columns and concatenate encoded ones
X_train = X_train.drop(columns=categorical_features).join(X_train_encoded)
X_test = X_test.drop(columns=categorical_features).join(X_test_encoded)
# MODEL TRAINING ----------------------------
# Defining the model
model = RandomForestClassifier(n_estimators=n_trees)
# Fitting the model
model.fit(X_train, y_train)
# EVALUATION ----------------------------
# Scoring
rdmf_score = model.score(X_test, y_test)
print(f"{rdmf_score:.1%} de bonnes réponses sur les données de test pour validation")
# Confusion matrix
print(20 * "-")
print("matrice de confusion")
print(confusion_matrix(y_test, model.predict(X_test)))Voyez-vous l’intérêt de l’approche par pipeline en termes de lisibilité, évolutivité et fiabilité ?
Créer un notebook qui servira de brouillon. Y introduire le code suivant:
Le code à copier-coller dans un notebook
import pandas as pd
from sklearn.preprocessing import OneHotEncoder, MinMaxScaler
from sklearn.ensemble import RandomForestClassifier
from sklearn.impute import SimpleImputer
from sklearn.pipeline import Pipeline
from sklearn.compose import ColumnTransformer
train = pd.read_csv("train.csv")
test = pd.read_csv("test.csv")
X_train, y_train = train.drop("Survived", axis="columns"), train["Survived"]
X_test, y_test = test.drop("Survived", axis="columns"), train["Survived"]
MAX_DEPTH = None
MAX_FEATURES = "sqrt"
n_trees=20
numeric_features = ["Age", "Fare"]
categorical_features = ["Embarked", "Sex"]
# Variables numériques
numeric_transformer = Pipeline(
steps=[
("imputer", SimpleImputer(strategy="median")),
("scaler", MinMaxScaler()),
]
)
# Variables catégorielles
categorical_transformer = Pipeline(
steps=[
("imputer", SimpleImputer(strategy="most_frequent")),
("onehot", OneHotEncoder()),
]
)
# Preprocessing
preprocessor = ColumnTransformer(
transformers=[
("Preprocessing numerical", numeric_transformer, numeric_features),
(
"Preprocessing categorical",
categorical_transformer,
categorical_features,
),
]
)
# Pipeline
pipe = Pipeline(
[
("preprocessor", preprocessor),
("classifier", RandomForestClassifier(
n_estimators=n_trees,
max_depth=MAX_DEPTH,
max_features=MAX_FEATURES
)),
]
)
pipe.fit(X_train, y_train)Afficher ce pipeline dans une cellule de votre notebook. Cela vous aide-t-il mieux à comprendre les différentes étapes du pipeline de modélisation ?
Comment pouvez-vous accéder aux étapes de preprocessing ?
Le DataFrame à créer pour appliquer un bout de notre pipeline
import numpy as np
new_data = {
"Age": [22, np.nan, 35, 28, np.nan],
"Fare": [7.25, 8.05, np.nan, 13.00, 15.50]
}
new_data = pd.DataFrame(new_data)import pandas as pd
import numpy as np
from sklearn.impute import SimpleImputer
from sklearn.preprocessing import MinMaxScaler
# Définition des nouvelles données
new_data = pd.DataFrame({
"Age": [25, np.nan, 40, 33, np.nan],
"Fare": [10.50, 7.85, np.nan, 22.00, 12.75]
})
# Définition des transformations (même que dans le pipeline)
num_imputer = SimpleImputer(strategy="median")
scaler = MinMaxScaler()
# Apprentissage des transformations sur X_train (assumant que vous l'avez déjà)
X_train_numeric = X_train[["Age", "Fare"]] # Supposons que X_train existe
num_imputer.fit(X_train_numeric)
scaler.fit(num_imputer.transform(X_train_numeric))
# Transformation des nouvelles données
new_data_imputed = num_imputer.transform(new_data)
new_data_scaled = scaler.transform(new_data_imputed)
# Création du DataFrame final
new_data_preprocessed = pd.DataFrame(
new_data_scaled,
columns=["Age_scaled", "Fare_scaled"] # Générer des noms de colonnes adaptés
)
# Affichage du DataFrame
print(new_data_preprocessed)Créer des données préprocessées
import numpy as np
import pandas as pd
new_data = pd.DataFrame({
"Age": [25, np.nan, 40, 33, np.nan],
"Fare": [10.50, 7.85, np.nan, 22.00, 12.75],
"Embarked": ["S", "C", np.nan, "Q", "S"],
"Sex": ["male", "female", "male", np.nan, "female"]
})
new_y = np.random.randint(0, 2, size=len(new_data))
preprocessed_data = pd.DataFrame(
pipe[:-1].transform(new_data),
columns = preprocessor_numeric.get_feature_names_out()
)
preprocessed_dataMaintenant, revenons à notre chaine de production et appliquons des fonctions pour la rendre plus lisible, plus fiable et plus modulaire.
Cette application peut être chronophage, vous pouvez aller plus ou moins loin dans la fonctionalisation de votre script en fonction du temps dont vous disposez.
split ;max_depth et max_features).Le fait d’appliquer des fonctions a déjà amélioré la fiabilité du processus en réduisant le nombre d’erreurs de copier-coller. Néanmoins, pour vraiment fiabiliser le processus, il faudrait utiliser un pipeline de transformations de données.
Ceci n’est pas encore au programme du cours mais le sera dans une prochaine version.
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli42
rm -f update.sh
Cela ne se remarque pas encore vraiment car nous avons de nombreuses définitions de fonctions mais notre chaine de production est beaucoup plus concise (le script fait environ 300 lignes dont 250 de définitions de fonctions génériques). Cette auto-discipline facilitera grandement les étapes ultérieures. Cela aurait été néanmoins beaucoup moins coûteux en temps d’adopter ces bons gestes de manière plus précoce.
Dans la partie précédente, on a appliqué de manière incrémentale de nombreuses bonnes pratiques vues tout au long du cours. Ce faisant, on s’est déjà considérablement rapprochés d’un possible partage du code : celui-ci est lisible et intelligible. Le code est proprement versionné sur un dépôt GitHub.
Cependant, le projet est encore perfectible: il est encore difficile de rentrer dedans si on ne sait pas exactement ce qu’on recherche. L’objectif de cette partie est d’isoler les différentes étapes de notre pipeline. Outre le gain de clarté pour notre projet, nous économiserons beaucoup de peines pour la mise en production ultérieure de notre modèle.
Dans cette partie nous allons continuer les améliorations incrémentales de notre projet avec les étapes suivantes:
Python pour séparer les différentes étapes de notre pipeline ;Nous allons profiter de la modularisation pour adopter une structure applicative pour notre code. Celui-ci n’étant en effet plus lancé que depuis la ligne de commande, on peut considérer qu’on construit une application générique où un script principal (main.py) encapsule des éléments issus d’autres scripts Python.
import_data.py: fonctions d’import et d’exploration de donnéesbuild_features.py: fonctions regroupant la définition des échantillons d’apprentissage et de test ainsi que le pipelinetrain_evaluate.py: fonctions d’évaluation du modèletitanic.py en main.py pour suivre la convention de nommage des projets Python ;main à partir de la ligne de commande :terminal
$ python main.pyterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli52
rm -f update.sh
On dispose maintenant d’une application Python fonctionnelle. Néanmoins, le projet est certes plus fiable mais sa structuration laisse à désirer et il serait difficile de rentrer à nouveau dans le projet dans quelques temps.
├── .gitignore
├── data.csv
├── train.csv
├── test.csv
├── README.md
├── config.yaml
├── import_data.py
├── build_features.py
├── train_evaluate.py
├── titanic.ipynb
└── main.pyComme cela est expliqué dans la partie Structure des projets, on va adopter une structure certes arbitraire mais qui va faciliter l’autodocumentation de notre projet. De plus, une telle structure va faciliter des évolutions optionnelles comme la packagisation du projet. Passer d’une structure modulaire bien faite à un package est quasi-immédiat en Python.
On va donc modifier l’architecture de notre projet pour la rendre plus standardisée. Pour cela, on va s’inspirer des structures cookiecutter qui génèrent des templates de projet. En l’occurrence notre source d’inspiration sera le template datascience issu d’un effort communautaire.
L’idée de cookiecutter est de proposer des templates que l’on utilise pour initialiser un projet, afin de bâtir à l’avance une structure évolutive. La syntaxe à utiliser dans ce cas est la suivante :
terminal
$ pip install cookiecutter
$ cookiecutter https://github.com/drivendata/cookiecutter-data-scienceIci, on a déjà un projet, on va donc faire les choses dans l’autre sens : on va s’inspirer de la structure proposée afin de réorganiser celle de notre projet selon les standards communautaires.
En s’inspirant du cookiecutter data science on va adopter la structure suivante:
application
├── main.py
├── README.md
├── data
│ ├── raw
│ │ └── data.csv
│ └── derived
│ ├── test.csv
│ └── train.csv
├── configuration
│ └── config.yaml
├── notebooks
│ └── titanic.ipynb
└── src
├── data
│ └── import_data.py
├── pipeline
│ └── build_pipeline.py
└── models
└── train_evaluate.pymain.py avec les nouveaux chemins ;terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli62
rm -f update.sh
Le script main.py nécessite un certain nombre de packages pour être fonctionnel. Chez vous les packages nécessaires sont bien sûr installés mais êtes-vous assuré que c’est le cas chez la personne qui testera votre code ?
Afin de favoriser la portabilité du projet, il est d’usage de “fixer l’environnement”, c’est-à-dire d’indiquer dans un fichier toutes les dépendances utilisées ainsi que leurs version. Nous proposons de créer un fichier requirements.txt minimal, sur lequel nous reviendrons dans la partie consacrée aux environnements reproductibles.
Le fichier requirements.txt est conventionnellement localisé à la racine du projet. Ici on ne va pas fixer les versions, on raffinera ce fichier ultérieurement.
requirements.txt
requirements.txt avec la liste des packages nécessairesREADME.md sur l’installation des packages grâce au fichier requirements.txtQuand votre projet passera en production, vous aurez un accès limité à celui-ci. Il est donc important de faire remonter, par le biais du logging des informations critiques sur votre projet qui vous permettront de savoir où il en est (si vous avez accès à la console où il tourne) ou là où il s’est arrêté.
L’utilisation de print montre rapidement ses limites pour cela. Les informations enregistrées ne persistent pas après la session et sont quelques peu rudimentaires.
Pour faire du logging, la librairie consacrée depuis longtemps en Python est… logging. On va néanmoins ici proposer d’utiliser loguru qui est un peu plus simple à configurer (l’instanciation du logger est plus aisée) et plus agréable grâce à ses messages en couleurs qui permettent de visuellement trier les informations.
loguru et l’ajouter au requirements.txtREADME du projet sur Github, remplacer nos print par différents types de messages (info, success, etc.)..gitignore puis tester en ligne de commande votre script. Ouvrir le fichier en question, refaites tourner le script et regardez son évolutoin.loguru de capturer les erreurs des fonctions grâce au système de cache décrit ici. Introduire une erreur dans une des fonctions (par exemple dans split_train_test) avec un code du type raise ValueError("Problème ici")terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli72
rm -f update.sh
Pour cette partie, il faut avoir un service VSCode dont les jetons d’authentification à S3 sont valides. Pour cela, si vous êtes sur le SSPCloud, le plus simple est de recréer un nouveau service avec le bouton suivant
et remplir l’onglet Git comme ça votre VSCode sera pré à l’emploi (cf. application 0).
Une fois que vous avez un VSCode fonctionnel, il est possible de reprendre cette application fil rouge depuis le checkpoint précédent.
VSCode actif avec la configuration proposée dans l'application préliminaire, vous pouvez repartir de ce service:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli72
rm -f update.sh
Enfin, il vous suffira d’ouvrir un terminal et faire pip install -r requirements.txt && python main.py pour pouvoir démarrer l’application.
L’étape précédente nous a permis d’isoler la configuration. Nous avons conceptuellement isolé les données du code lors des applications précédentes. Cependant, nous n’avons pas été au bout du chemin car le stockage des données reste conjoint à celui du code. Nous allons maintenant dissocier ces deux éléments.
S3
Pour mettre en oeuvre cette étape, il peut être utile de comprendre un peu comme fonctionne le SSP Cloud. Vous devrez suivre la documentation du SSP Cloud pour la réaliser. Une aide-mémoire est également disponible dans le cours de 2e année de l’ENSAE Python pour la data science.
Parquet
L’objectif de cette application est de montrer comment utiliser le format Parquet dans une chaîne production ; un objectif somme toute modeste.
Si vous voulez aller plus loin dans la découverte du format Parquet, vous pouvez consulter cette ressource R très similaire à ce cours (oui elle est faite par les mêmes auteurs…) et essayer de faire les exercices avec votre librairie Python de prédilection (PyArrow ou DuckDB)
Le chapitre sur la structure des projets développe l’idée qu’il est recommandé de converger vers un modèle où environnements d’exécution, de stockage du code et des données sont conceptuellement séparés. Ce haut niveau d’exigence est un gain de temps important lors de la mise en production car au cours de cette dernière, le projet est amené à être exécuté sur une infrastructure informatique dédiée qu’il est bon d’anticiper. Schématiquement, nous visons la structure de projet suivante:
A l’heure actuelle, les données sont stockées dans le dépôt. C’est une mauvaise pratique. En premier lieu, Git n’est techniquement pas bien adapté au stockage de données. Ici ce n’est pas très grave car il ne s’agit pas de données volumineuses et ces dernières ne sont pas modifiées au cours de notre chaine de traitement.
La raison principale est que les données traitées par les data scientists sont généralement soumises à des clauses de confidentialités (RGPD, secret statistique…). Mettre ces données sous contrôle de version c’est prendre le risque de les divulguer à un public non habilité. Il est donc recommandé de privilégier des outils techniques adaptés au stockage de données.
L’idéal, dans notre cas, est d’utiliser une solution de stockage externe. On va utiliser pour cela MinIO, la solution de stockage de type S3 offerte par le SSP Cloud. Cela nous permettra de supprimer les données de Github tout en maintenant la reproductibilité de notre projet 7.
Plus concrètement, nous allons adopter le pipeline suivant pour notre projet:
Le scénario type est que nous avons une source brute, reçue sous forme de CSV, dont on ne peut changer le format. Il aurait été idéal d’avoir un format plus adapté au traitement de données pour ce fichier mais ce n’était pas de notre ressort. Notre chaine va aller chercher ce fichier, travailler dessus jusqu’à valoriser celui-ci sous la forme de notre matrice de confusion. Si on imagine que notre chaine prend un certain temps, il n’est pas inutile d’écrire des données intermédiaires. Pour faire cela, puisque nous avons la main, autant choisir un format adapté, à savoir le format Parquet.
S3
Pour commencer, à partir de la ligne de commande, utiliser l’utilitaire MinIO pour copier les données data/raw/data.csv vers votre bucket personnel. Les données intermédiaires peuvent être laissées en local mais doivent être ajoutées au .gitignore.
Structure à adopter:
terminal
$ mc cp data/raw/data.csv s3/$BUCKET_PERSONNEL/ensae-reproductibilite/data/raw/data.csv$BUCKET_PERSONNEL, l’emplacement de votre bucket personnel
Pour se simplifier la vie, dans les prochaines applications, on va utiliser des URL de téléchargement des fichiers (comme si ceux-ci étaient sur n’importe quel espace de stockage) plutôt que d’utiliser une librairie S3 compatible comme boto3 ou s3fs.
Néanmoins, il est utile de les utiliser une fois pour comprendre la logique. Pour aller plus loin sur ces librairies, vous pouvez consulter cette page du cours de 2A de Python pour la data science.
Pour commencer, on va lister les fichiers se trouvant dans un bucket. En ligne de commande, sur notre poste local, on ferait ls (cf. Linux 101). Cela ne va pas beaucoup différer avec les librairies cloud native:
Dans un notebook, copier-coller ce code, le modifier et exécuter:
import s3fs
fs = s3fs.S3FileSystem(client_kwargs={"endpoint_url": "https://minio.lab.sspcloud.fr"})
1MY_BUCKET = "mon_nom_utilisateur_sspcloud"
2CHEMIN = "ensae-reproductibilite/data/raw"
fs.ls(f"s3://{MY_BUCKET}/{CHEMIN}")On va maintenant lire directement une donnée stockée sur S3. Pour illustrer le fait que cela change peu notre code d’être sur un système cloud avec les librairies adaptées, on va lire directement un fichier CSV stocké sur le SSPCloud, sans passer par un fichier en local.
S3
import s3fs
import pandas as pd
fs = s3fs.S3FileSystem(client_kwargs={"endpoint_url": "https://minio.lab.sspcloud.fr"})
with fs.open(f"s3://{MY_BUCKET}/{CHEMIN}") as f:
df = pd.read_csv(f)
dfimport s3fs
from pyarrow import csv
fs = s3fs.S3FileSystem(client_kwargs={"endpoint_url": "https://minio.lab.sspcloud.fr"})
with fs.open(f"s3://{MY_BUCKET}/{CHEMIN}") as f:
df = csv.read_csv(f)
dfimport os
import duckdb
con = duckdb.connect(database=":memory:")
con.execute(
f"""
CREATE SECRET secret (
TYPE S3,
KEY_ID '{os.environ["AWS_ACCESS_KEY_ID"]}',
SECRET '{os.environ["AWS_SECRET_ACCESS_KEY"]}',
ENDPOINT 'minio.lab.sspcloud.fr',
SESSION_TOKEN '{os.environ["AWS_SESSION_TOKEN"]}',
REGION 'us-east-1',
URL_STYLE 'path',
SCOPE 's3://{MY_BUCKET}/'
);
"""
)
query_definition = f"SELECT * FROM read_csv('s3://{MY_BUCKET}/{CHEMIN}')"
con.sql(query_definition)import s3fs
fs = s3fs.S3FileSystem(client_kwargs={"endpoint_url": "https://minio.lab.sspcloud.fr"})
MY_BUCKET = "mon_nom_utilisateur_sspcloud"
path_data = "data/python-ENSAE/dvf.parquet"
pd.read_csv(f"s3://${MY_BUCKET}/${path_data}", filesystem=fs) #remplacer par read_parquetParquet dans notre chaîne
Dans main.py, remplacer le format csv initialement prévu par un format parquet:
data_train_path = os.environ.get("train_path", "data/derived/train.parquet")
data_test_path = os.environ.get("test_path", "data/derived/test.parquet")Et modifier l’écriture des données pour utiliser to_parquet plutôt que to_csv pour écrire les fichiers intermédiaires:
pd.concat([X_train, y_train], axis = 1).to_parquet(data_train_path)
pd.concat([X_test, y_test], axis = 1).to_parquet(data_test_path)S3
Par défaut, le contenu de votre bucket est privé, seul vous y avez accès. Pour pouvoir lire votre donnée, vos applications externes devront utiliser des jetons vous identifiant. Ici, comme nous utilisons une donnée publique, vous pouvez rendre accessible celle-ci à tous en lecture. Dans le jargon S3, cela signifie donner un accès anonyme à votre donnée.
Le modèle de commande à utiliser dans le terminal est le suivant:
terminal
$ mc anonymous set download s3/$BUCKET_PERSONNEL/ensae-reproductibilite/data/raw/en modifiant $BUCKET_PERSONNEL et le chemin en son sein (/ensae-reproductibilite/data/raw/). Les URL de téléchargement seront de la forme https://minio.lab.sspcloud.fr/$BUCKET_PERSONNEL/ensae-reproductibilite/data/raw/data.csv
data_path pour utiliser, par défaut, directement l’URL dans l’import. Modifier, si cela est pertinent, aussi votre fichier .env.1URL_RAW = ""
data_path = os.environ.get("data_path", URL_RAW)URL_RAW un lien de la forme "https://minio.lab.sspcloud.fr/$BUCKET_PERSONNEL/ensae-reproductibilite/data/raw/data.csv"
Ajouter le dossier data/ au .gitignore ainsi que les fichiers *.parquet
Supprimer le dossier data de votre projet et faites git rm --cached -r data
Vérifier le bon fonctionnement de votre application.
Maintenant qu’on a arrangé la structure de notre projet, c’est l’occasion de supprimer le code qui n’est plus nécessaire au bon fonctionnement de notre projet (cela réduit la charge de maintenance8).
Pour vous aider, vous pouvez utiliser vulture de manière itérative pour vous assister dans le nettoyage de votre code.
terminal
$ pip install vulture
$ vulture .terminal
$ vulture .src/data/import_data.py:3: unused function 'split_and_count' (60% confidence)
src/pipeline/build_pipeline.py:12: unused function 'split_train_test' (60% confidence)terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli82
rm -f update.sh
Cette série d’actions n’est pas forcément pertinente pour tous les projets. Elle fait un peu la transition entre la modularité et la portabilité.
Notre code comporte un certain nombre de fonctions génériques. On peut vouloir tester leur usage sur des données standardisées, différentes de celles du Titanic.
Même si la notion de tests unitaires prend plus de sens dans un package, nous pouvons proposer dans le projet des exemples d’utilisation de la fonction, ceci peut être pédagogique.
Nous allons utiliser unittest pour effectuer des tests unitaires. Cette approche nécessite quelques notions de programmation orientée objet ou une bonne discussion avec ChatGPT.
Dans le dossier tests/, créer avec l’aide de ChatGPT ou de Copilot un test pour la fonction split_and_count.
unittest (python -m unittest tests/test_split.py). Corriger le test unitaire en cas d’erreur.terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli92
rm -f update.sh
Lorsqu’on effectue des tests unitaires, on cherche généralement à tester le plus de lignes possibles de son code. On parle de taux de couverture (coverage rate) pour désigner la statistique mesurant cela.
Cela peut s’effectuer de la manière suivante avec le package coverage:
terminal
$ coverage run -m unittest tests/test_create_variable_title.py
$ coverage report -mName Stmts Miss Cover Missing
-------------------------------------------------------------------
src/features/build_features.py 34 21 38% 35-36, 48-58, 71-74, 85-89, 99-101, 111-113
tests/test_create_variable_title.py 21 1 95% 54
-------------------------------------------------------------------
TOTAL 55 22 60%Le taux de couverture est souvent mis en avant par les gros projets comme indicateur de leur qualité. Il existe d’ailleurs des badges Github dédiés.
Notre projet est modulaire, ce qui le rend assez simple à transformer en package, en s’inspirant de la structure du cookiecutter adapté, issu de cet ouvrage.
On va créer un package nommé titanicml qui encapsule tout notre code et qui sera appelé par notre script main.py. La structure attendue est la suivante:
ensae-reproductibilite-application
├── docs ┐
│ ├── main.py │
│ └── notebooks │ Package documentation and examples
│ └── titanic.ipynb │
├── configuration ┐ Configuration (pas à partager avec Git)
│ └── config.yaml ┘
├── README.md
├── pyproject.toml ┐
├── requirements.txt │
├── titanicml │
│ ├── __init__.py │ Package source code, metadata
│ ├── data │ and build instructions
│ │ ├── import_data.py │
│ │ └── test_create_variable_title.py │
│ ├── features │
│ │ └── build_features.py │
│ └── models │
│ └── train_evaluate.py ┘
└── tests ┐
└── test_create_variable_title.py ┘ Package testsensae-reproductibilite-application
├── notebooks
│ └── titanic.ipynb
├── configuration
│ └── config.yaml
├── main.py
├── README.md
├── requirements.txt
└── src
├── data
│ ├── import_data.py
│ └── test_create_variable_title.py
├── features
│ └── build_features.py
└── models
└── train_evaluate.pyIl existe plusieurs frameworks pour construire un package. Nous allons privilégier Poetry à Setuptools.
Pour créer la structure minimale d’un package, le plus simple est d’utiliser le cookiecutter adapté, issu de cet ouvrage.
Comme on a déjà une structure très modulaire, on va plutôt recréer cette structure dans notre projet déjà existant. En fait, il ne manque qu’un fichier essentiel, le principal distinguant un projet classique d’un package : pyproject.toml.
terminal
$ cookiecutter https://github.com/py-pkgs/py-pkgs-cookiecutter.gitauthor_name [Monty Python]: Daffy Duck
package_name [mypkg]: titanicml
package_short_description []: Impressive Titanic survival analysis
package_version [0.1.0]:
python_version [3.9]:
Select open_source_license:
1 - MIT
2 - Apache License 2.0
3 - GNU General Public License v3.0
4 - Creative Commons Attribution 4.0
5 - BSD 3-Clause
6 - Proprietary
7 - None
Choose from 1, 2, 3, 4, 5, 6 [1]:
Select include_github_actions:
1 - no
2 - ci
3 - ci+cd
Choose from 1, 2, 3 [1]:titanicml pour respecter la nouvelle arborescence ;pyproject.toml sur cette base ;pyproject.toml
[tool.poetry]
name = "titanicml"
version = "0.0.1"
description = "Awesome Machine Learning project"
authors = ["Daffy Duck <daffy.duck@fauxmail.fr>", "Mickey Mouse"]
license = "MIT"
readme = "README.md"
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
[tool.pytest.ini_options]
log_cli = true
log_cli_level = "WARNING"
log_cli_format = "%(asctime)s [%(levelname)8s] %(message)s (%(filename)s:%(lineno)s)"
log_cli_date_format = "%Y-%m-%d %H:%M:%S"docs et mettre les fichiers indiqués dedanstitanicml/, créer un fichier __init__.py9__init__.py
from .data.import_data import (
split_and_count
)
from .pipeline.build_pipeline import (
split_train_test,
create_pipeline
)
from .models.train_evaluate import (
evaluate_model
)
__all__ = [
"split_and_count",
"split_train_test",
"create_pipeline",
"evaluate_model"
]pip install -e .docs/main.py pour importer les fonctions de notre package titanicml et tester en ligne de commande notre fichier main.pyterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli102
rm -f update.sh
VSCode actif avec la configuration proposée dans l'application préliminaire, vous pouvez repartir de ce service:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli82
rm -f update.sh
Dans la partie précédente, on a appliqué de manière incrémentale de nombreuses bonnes pratiques vues dans les chapitres Qualité du code et Structure des projets tout au long du cours.
Ce faisant, on s’est déjà considérablement rapprochés d’une possible mise en production : le code est lisible, la structure du projet est normalisée et évolutive, et le code est proprement versionné sur un dépôt GitHub .
A présent, nous avons une version du projet qui est largement partageable. Du moins en théorie, car la pratique est souvent plus compliquée : il y a fort à parier que si vous essayez d’exécuter votre projet sur un autre environnement (typiquement, votre ordinateur personnel), les choses ne se passent pas du tout comme attendu. Cela signifie qu’en l’état, le projet n’est pas portable : il n’est pas possible, sans modifications coûteuses, de l’exécuter dans un environnement différent de celui dans lequel il a été développé.
Dans cette troisème partie de notre travail vers la mise en production, nous allons voir comment normaliser l’environnement d’exécution afin de produire un projet portable. Autrement dit, nous n’allons plus nous contenter de modularité mais allons rechercher la portabilité. On sera alors tout proche de pouvoir mettre le projet en production.
On progressera dans l’échelle de la reproductibilité de la manière suivante:
Docker.Nous allons repartir de l’application 8, c’est-à-dire d’un projet modulaire mais qui n’est pas, à strictement parler, un package (objet des applications optionnelles suivantes 9 et 10).
Pour se replacer dans l’état du projet à ce niveau, il est possible d’utiliser le tag ad hoc.
terminal
$ git stash
$ git checkout appli8Pour qu’un projet soit portable, il doit remplir deux conditions:
Le prochain exercice vise à mettre ceci en oeuvre. Comme expliqué dans le chapitre portabilité, le choix du gestionnaire d’environnement est laissé libre. Il est recommandé de privilégier venv si vous découvrez la problématique de la portabilité.
L’approche la plus légère est l’environnement virtuel. Nous avons en fait implicitement déjà commencé à aller vers cette direction en créant un fichier requirements.txt.
venv
pip freeze en ligne de commande et observer la (très) longue liste de packagetitanic en s’inspirant de la documentation officielle10 ou du chapitre dédiéls pour observer et comprendre le contenu du dossier titanic/bin installéPython maintenant utilisée par votre machine Python exécute bien une commande11 avec:terminal
$ python -c "print('Hello')"import pandas as pdrequirements.txt. Tester à nouveau import pandas as pd pour comprendre la différence.pip freeze et comprendre la différence avec la situation précédente.main.py fonctionne bien. Sinon ajouter les packages manquants dans le requirements.txt et reprendre de manière itérative à partir de la question 7.titanic/ au .gitignore pour ne pas ajouter ce dossier à Git.Après l’activation, vous pouvez vérifier quel python est utilisé de cette manière
terminal
(titanic) $ which pythonterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli11a2
rm -f update.sh
Les environnements conda sont plus lourds à mettre en oeuvre que les environnements virtuels mais peuvent permettre un contrôle plus formel des dépendances.
conda
conda env export en ligne de commande et observer la (très) longue liste de packagetitanic avec conda createPython maintenant utilisée par votre machine Python exécute bien une commande12 avec:terminal
$ python -c "print('Hello')"import pandas as pdrequirements.txt précédemment. Ne pas faire un pip install -r requirements.txt afin de privilégier conda installconda env export et comprendre la différence avec la situation précédente13.main.py fonctionne bien. Sinon installer les packages manquants et reprndre de manière itérative à partir de la question 7.main.py fonctionne, faire conda env export > environment.yml pour figer l’environnement de travail.terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli11b2
rm -f update.sh
shellLes environnements virtuels permettent de mieux spécifier les dépendances de notre projet, mais ne permettent pas de garantir une portabilité optimale. Pour cela, il faut recourir à la technologie des conteneurs. L’idée est de construire une machine, en partant d’une base quasi-vierge, qui permette de construire étape par étape l’environnement nécessaire au bon fonctionnement de notre projet. C’est le principe des conteneurs Docker .
Leur méthode de construction étant un peu difficile à prendre en main au début, nous allons passer par une étape intermédiaire afin de bien comprendre le processus de production.
shell, c’est à dire une suite de commandes Linux permettant de construire l’environnement à partir d’une machine vierge ;Dockerfile dans un deuxième temps. C’est l’objet de l’étape suivante.ubuntu sur le SSP Cloudcdgit checkout appli11ainstall.sh à la racine du projet avec le contenu suivant:install.sh
install.sh
#!/bin/bash
# Install Python
apt-get -y update
apt-get install -y python3-pip python3-venv
# Create empty virtual environment
python3 -m venv titanic
source titanic/bin/activate
# Install project dependencies
pip install -r requirements.txtterminal
$ chmod +x install.shapt)terminal
$ sudo ./install.shmain.py fonctionne correctement dans l’environnement virtuel crééterminal
$ source titanic/bin/activate
$ python3 main.pyterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli12a2
rm -f update.sh
ubuntu sur le SSP Cloudcdgit checkout appli11binstall.sh à la racine du projet avec le contenu suivant:install.sh
install.sh
apt-get -y update && apt-get -y install wget
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh && \
bash Miniconda3-latest-Linux-x86_64.sh -b -p /miniconda && \
rm -f Miniconda3-latest-Linux-x86_64.sh
PATH="/miniconda/bin:${PATH}"
# Create environment
conda create -n titanic pandas PyYAML scikit-learn -c conda-forge
conda activate titanic
PATH="/miniconda/envs/titanic/bin:${PATH}"
python main.pyterminal
$ chmod +x install.shapt)terminal
$ sudo ./install.shmain.py fonctionne correctement dans l’environnement virtuel crééterminal
$ conda activate titanic
$ python3 main.pyterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli12b2
rm -f update.sh
DockerCette application nécessite l’accès à une version interactive de Docker. Il n’y a pas beaucoup d’instances en ligne disponibles.
Nous proposons deux solutions:
Docker sur sa machine ;Sinon, elle peut être réalisée en essai-erreur par le biais des services d’intégration continue de Github ou Gitlab . Néanmoins, nous présenterons l’utilisation de ces services plus tard, dans la prochaine partie.
Maintenant qu’on sait que ce script préparatoire fonctionne, on va le transformer en Dockerfile pour anticiper la mise en production. Comme la syntaxe Docker est légèrement différente de la syntaxe Linux classique (voir le chapitre portabilité), il va être nécessaire de changer quelques instructions mais ceci sera très léger.
On va tester le Dockerfile dans un environnement bac à sable pour ensuite pouvoir plus facilement automatiser la construction de l’image Docker.
Docker
Se placer dans un environnement avec Docker, par exemple Play with Docker
DockerfileLinux, cloner votre dépôt Githubvenv, ce sera:terminal
1$ git stash
$ git checkout appli12aDockerfile (la majuscule au début du mot est importante)Dockerfile vierge depuis la ligne de commande
terminal
$ touch DockerfileDockerfile
terminal
FROM ubuntu:22.04
WORKDIR ${HOME}/titanic
# Install Python
RUN apt-get -y update && \
apt-get install -y python3-pip
# Install project dependencies
COPY requirements.txt .
RUN pip install -r requirements.txt
CMD ["python3", "main.py"]docker build pour créer une image avec le tag my-python-appterminal
$ docker build . -t my-python-appterminal
$ docker imagesREPOSITORY TAG IMAGE ID CREATED SIZE
my-python-app latest 188957e16594 About a minute ago 879MBL’étape de build a fonctionné: une image a été construite.
Mais fait-elle effectivement ce que l’on attend d’elle ?
Pour le savoir, il faut passer à l’étape suivante, l’étape de run.
terminal
$ docker run -it my-python-apppython3: can't open file '/~/titanic/main.py': [Errno 2] No such file or directoryLe message d’erreur est clair : Docker ne sait pas où trouver le fichier main.py. D’ailleurs, il ne connait pas non plus les autres fichiers de notre application qui sont nécessaires pour faire tourner le code, par exemple le dossier src.
CMD, copier les fichiers nécessaires sur l’image afin que l’application dispose de tous les éléments nécessaires pour être en mesure de fonctionner.Dockerfile
terminal
FROM ubuntu:22.04
WORKDIR ${HOME}/titanic
# Install Python
RUN apt-get -y update && \
apt-get install -y python3-pip
# Install project dependencies
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY main.py .
COPY src ./src
CMD ["python3", "main.py"]Refaire tourner l’étape de build
Refaire tourner l’étape de run. A ce stade, la matrice de confusion doit fonctionner 🎉. Vous avez créé votre première application reproductible !
Ici, le cache permet d’économiser beaucoup de temps. Par besoin de refaire tourner toutes les étapes, Docker agit de manière intelligente en faisant tourner uniquement les étapes qui ont changé.
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli132
rm -f update.sh
Imaginez que vous êtes au restaurant et qu’on ne vous serve pas le plat mais seulement la recette et que, de plus, on vous demande de préparer le plat chez vous avec les ingrédients dans votre frigo. Vous seriez quelque peu déçu. En revanche, si vous avez goûté au plat, que vous êtes un réel cordon bleu et qu’on vous donne la recette pour refaire ce plat ultérieurement, peut-être que vous appréciriez plus.
Cette analogie illustre l’enjeu de définir le public cible et ses attentes afin de fournir un livrable adapté. Une image Docker est un livrable qui n’est pas forcément intéressant pour tous les publics. Certains préféreront avoir un plat bien préparé qu’une recette ; certains apprécieront avoir une image Docker mais d’autres ne seront pas en mesure de construire celle-ci ou ne sauront pas la faire fonctionner. Une image Docker est plus souvent un moyen pour faciliter la mise en service d’une production qu’une fin en soi.
Nous allons donc proposer plusieurs types de livrables plus classiques par la suite. Ceux-ci correspondront mieux aux attendus des publics utilisateurs de services construits à partir de techniques de data science. Docker est néanmoins un passage obligé car l’ensemble des types de livrables que nous allons explorer reposent sur la standardisation permise par les conteneurs.
Cette approche nous permettra de quitter le domaine de l’artisanat pour s’approcher d’une industrialisation de la mise à disposition de notre projet. Ceci va notamment nous amener à mettre en oeuvre l’approche pragmatique du DevOps qui consiste à intégrer dès la phase de développement d’un projet les contraintes liées à sa mise à disposition au public cible (cette approche est détaillée plus amplement dans le chapitre sur la mise en production).
L’automatisation et la mise à disposition automatisée de nos productions sera faite progressivement, au cours des prochaines parties. Tous les projets n’ont pas vocation à aller aussi loin dans ce domaine. L’opportunité doit être comparée aux coûts humains et financiers de leur mise en oeuvre et de leur cycle de vie. Avant de faire une production en série de nos modèles, nous allons déjà commencer par automatiser quelques tests de conformité de notre code. On va ici utiliser l’intégration continue pour deux objectifs distincts:
Docker ;linter précédent.Nous allons utiliser Github Actions pour cela. Il s’agit de serveurs standardisés mis à disposition gratuitement par Github . Gitlab , l’autre principal acteur du domaine, propose des services similaires. L’implémentation est légèrement différente mais les principes sont identiques.
VSCode actif avec la configuration proposée dans l'application préliminaire, vous pouvez repartir de ce service:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli132
rm -f update.sh
Avant d’essayer de mettre en oeuvre la création de notre image Docker de manière automatisée, nous allons présenter la logique de l’intégration continue en testant de manière automatisée notre script main.py.
Pour cela, nous allons partir de la structure proposée dans l’action officielle. La documentation associée est ici. Des éléments succincts de présentation de la logique déclarative des actions Github sont disponibles dans le chapitre sur la mise en production. Néanmoins, la meilleure école pour comprendre le fonctionnement de celles-ci est de parcourir la documentation du service et d’observer les actions Github mises en oeuvre par vos projets favoris, celles-ci seront fort instructives !
A partir de l’exemple présent dans la documentation officielle de Github , on a déjà une base de départ qui peut être modifiée. Les questions suivantes permettront d’automatiser les tests et le diagnostic qualité de notre code14
.github/workflows/test.yaml avec le contenu de l’exemple de la documentationrequirements.txt pour installer les dépendances.pylint pour vérifier la qualité du code. Ajouter l’argument --fail-under=6 pour renvoyer une erreur en cas de note trop basse15python main.py) pour tester que la matrice de confusion s’affiche bien.JETON_API. Ne le faites pas commencer par un “$” comme ça vous pourrez regarder la log ultérieurementActions de votre dépôt sur Githubmain.pyterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli142
rm -f update.sh
Maintenant, nous pouvons observer que l’onglet Actions s’est enrichi. Chaque commit va entraîner une série d’actions automatisées.
Si l’une des étapes échoue, ou si la note de notre projet est mauvaise, nous aurons une croix rouge (et nous recevrons un mail). On pourra ainsi détecter, en développant son projet, les moments où on dégrade la qualité du script afin de la rétablir immédiatemment.
DockerMaintenant, nous allons automatiser la mise à disposition de notre image sur DockerHub (le lieu de partage des images Docker). Cela facilitera sa réutilisation mais aussi des valorisations ultérieures.
Là encore, nous allons utiliser une série d’actions pré-configurées.
Pour que Github puisse s’authentifier auprès de DockerHub, il va falloir d’abord interfacer les deux plateformes. Pour cela, nous allons utiliser un jeton (token) DockerHub que nous allons mettre dans un espace sécurisé associé à votre dépôt Github.
Github.applicationSecurityGithub de votre projet, cliquer sur l’onglet Settings et cliquer, à gauche, sur Secrets and variables puis dans le menu déroulant en dessous sur Actions. Sur la page qui s’affiche, aller dans la section Repository secretsDOCKERHUB_TOKEN à partir du jeton que vous aviez créé sur Dockerhub. ValiderDOCKERHUB_USERNAME ayant comme valeur le nom d’utilisateur que vous avez créé sur DockerhubGithub de votre projet, cliquer sur l’onglet Settings et cliquer, à gauche, sur Actions. Donner les droits d’écriture à vos actions sur le dépôt du projet (ce sera nécessaire pour Github Pages)
A ce stade, nous avons donné les moyens à Github de s’authentifier avec notre identité sur Dockerhub. Il nous reste à mettre en oeuvre l’action en s’inspirant de la documentation officielle. On ne va modifier que trois éléments dans ce fichier. Effectuer les actions suivantes:
Docker
.github/workflows/prod.yml qui va build et push l’image sur le DockerHub. Il va être nécessaire de changer légèrement ce modèle :
on de sorte à avoir on: push: branches: - main - devusername/application:latest où username est le nom d’utilisateur sur DockerHub;commit et un push de ces fichiersComme on est fier de notre travail, on va afficher ça avec un badge sur le README (partie optionnelle).
Actions et cliquer sur une des actions listées....Create status badgeMarkdown proposéREADME.md le code markdown proposé
Maintenant, il nous reste à tester notre application dans l’espace bac à sable ou en local, si Docker est installé.
Docker de prédilection.terminal
$ docker run -it username/application:latest🎉 La matrice de confusion doit s’afficher ! Vous avez grandement facilité la réutilisation de votre image.
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli152
rm -f update.sh
Nous avons automatisé les étapes intermédiaires de notre projet. Néanmoins nous n’avons pas encore réfléchi à la valorisation à mettre en oeuvre pour notre projet. On va supposer que notre projet s’adresse à des data scientists mais aussi à une audience moins technique. Pour ces premiers, nous pourrions nous contenter de valorisations techniques, comme des API, mais pour ces derniers il est conseillé de privilégier des formats plus user friendly.
Afin de faire le parallèle avec les parcours possibles pour l’évaluation, nous allons proposer deux valorisations16:
La solution que nous allons proposer pour les sites statiques, Quarto associé à Github Pages, peut être utilisée dans le cadre des parcours “rapport reproductible” ou “dashboard / application interactive”.
Pour ce dernier parcours, d’autres approches techniques sont néanmoins possibles, comme Streamlit. Celles-ci sont plus exigeantes sur le plan technique puisqu’elles nécessitent de mettre en production sur des serveurs conteuneurisés (comme la mise en production de l’API) là où le site statique ne nécessite qu’un serveur web, mis à disposition gratuitement par Github.
La distinction principale entre ces deux approches est qu’elles s’appuient sur des serveurs différents. Un site statique repose sur un serveur web là où Streamlit s’appuie sur serveur classique en backend. La différence principale entre ces deux types de serveurs réside principalement dans leur fonction et leur utilisation:
Streamlit, il s’agit d’un serveur avec l’environnement Python ad hoc pour exécuter le code nécessaire à répondre à toute action d’un utilisateur de l’appliacation.Le premier livrable devenu classique dans un projet impliquant du machine learning est la mise à disposition d’un modèle par le biais d’une API (voir chapitre sur la mise en production). Le framework FastAPI va permettre de rapidement transformer notre application Python en une API fonctionnelle.
VSCode actif avec la configuration proposée dans l'application préliminaire, vous pouvez repartir de ce service:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli152
rm -f update.sh
fastAPI et uvicorn puis les ajouter au requirements.txtmain.py en train.py. Dans ce script, ajouter une sauvegarde du modèle après l’avoir entraîné, sous le format joblib.terminal
$ python train.pypour enregistrer en local votre modèle de production.
Modifier les appels à main.py dans votre Dockerfile et vos actions Github sous peine d’essuyer des échecs lors de vos actions Github après le prochain push.
Ajouter model.joblib au .gitignore car Git n’est pas fait pour ce type de fichiers.
Nous allons maintenant passer au développement de l’API. Comme découvrir FastAPI n’est pas l’objet de cet enseignement, nous donnons directement le modèle pour créer l’API. Si vous désirez tester de vous-mêmes, vous pouvez créer votre fichier sans vous référer à l’exemple
api.py permettant d’initialiser l’API:api.py
src/models/train_evaluation.py
"""A simple API to expose our trained RandomForest model for Tutanic survival."""
from fastapi import FastAPI
from joblib import load
import pandas as pd
model = load('model.joblib')
app = FastAPI(
title="Prédiction de survie sur le Titanic",
description=
"Application de prédiction de survie sur le Titanic 🚢 <br>Une version par API pour faciliter la réutilisation du modèle 🚀" +\
"<br><br><img src=\"https://media.vogue.fr/photos/5faac06d39c5194ff9752ec9/1:1/w_2404,h_2404,c_limit/076_CHL_126884.jpg\" width=\"200\">"
)
@app.get("/", tags=["Welcome"])
def show_welcome_page():
"""
Show welcome page with model name and version.
"""
return {
"Message": "API de prédiction de survie sur le Titanic",
"Model_name": 'Titanic ML',
"Model_version": "0.1",
}
@app.get("/predict", tags=["Predict"])
async def predict(
sex: str = "female",
age: float = 29.0,
fare: float = 16.5,
embarked: str = "S"
) -> str:
"""
"""
df = pd.DataFrame(
{
"Sex": [sex],
"Age": [age],
"Fare": [fare],
"Embarked": [embarked],
}
)
prediction = "Survived 🎉" if int(model.predict(df)) == 1 else "Dead ⚰️"
return predictionterminal
$ uvicorn api:app --reload --host "0.0.0.0" --port 5000README du service, se rendre sur l’URL de déploiement, ajouter /docs/ à celui-ci et observer la documentation de l’API/predictPython avec requests :import request
requests.get(url).json()Python et comprendre l’origine du problème.terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli162
rm -f update.sh
VSCode actif avec la configuration proposée dans l'application préliminaire, vous pouvez repartir de ce service:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli162
rm -f update.sh
A ce stade, nous avons déployé l’API seulement localement, dans le cadre d’un terminal qui tourne en arrière-plan. C’est une mise en production manuelle, pas franchement pérenne. Ce mode de déploiement est très pratique pour la phase de développement, afin de s’assurer que l’API fonctionne comme attendu. Pour pérenniser la mise en production, on va éliminer l’aspect artisanal de celle-ci.
Il est temps de passer à l’étape de déploiement, qui permettra à notre API d’être accessible via une URL sur le web et d’avoir un serveur, en arrière plan, qui effectuera les opérations pour répondre à une requête. Pour se faire, on va utiliser les possibilités offertes par Kubernetes, sur lequel est basé le SSP Cloud.
Pour rendre la structure du projet plus lisible, déplacer api.py -> api/main.py
Créer un script api/run.sh à la racine du projet qui lance le script train.py puis déploie localement l’API
run.sh
api/run.sh
#/bin/bash
python3 train.py
uvicorn api.main:app --reload --host "0.0.0.0" --port 5000Donner au script api/run.sh des permissions d’exécution : chmod +x api/run.sh
Ajouter COPY api ./api pour avoir les fichiers nécessaires au lancement dans l’API dans l’image
Modifier COPY train.py . pour tenir compte du nouveau nom du fichier
Changer l’instruction CMD du Dockerfile pour exécuter le script api/run.sh au lancement du conteneur (CMD ["bash", "-c", "./api/run.sh"])
Mettre à jour votre requirements.txt pour tenir compte des nouveaux packages utilisés
Commit et push les changements
Une fois le CI terminé, récupérer la nouvelle image dans votre environnement de test de Docker et vérifier que l’API se déploie correctement
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli172
rm -f update.sh
Nous avons préparé la mise à disposition de notre API mais à l’heure actuelle elle n’est pas disponible de manière aisée car il est nécessaire de lancer manuellement une image Docker pour pouvoir y accéder. Ce type de travail est la spécialité de Kubernetes que nous allons utiliser pour gérer la mise à disposition de notre API.
Cette partie nécessite d’avoir à disposition une infrastructure cloud.
Créer un dossier deployment à la racine du projet qui va contenir les fichiers de configuration nécessaires pour déployer sur un cluster Kubernetes
En vous inspirant de la documentation, y ajouter un premier fichier deployment.yaml qui va spécifier la configuration du Pod à lancer sur le cluster
deployment/deployment.yaml
deployment/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: titanic-deployment
labels:
app: titanic
spec:
replicas: 1
selector:
matchLabels:
app: titanic
template:
metadata:
labels:
app: titanic
spec:
containers:
- name: titanic
1 image:
ports:
- containerPort: 5000Docker utilisée, sous la forme username/image:latest
service.yaml qui va créer une ressource Service permettant de donner une identité fixe au Pod précédemment créé au sein du clusterdeployment/service.yaml
deployment/service.yaml
apiVersion: v1
kind: Service
metadata:
name: titanic-service
spec:
selector:
app: titanic
ports:
- protocol: TCP
port: 80
targetPort: 5000ingress.yaml qui va créer une ressource Ingress permettant d’exposer le service via une URL en dehors du clusterdeployment/ingress.yaml
deployment/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: titanic-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
# Enable CORS by adding these annotations
nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, DELETE, PATCH, OPTIONS"
nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
nginx.ingress.kubernetes.io/cors-allow-headers: "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization"
nginx.ingress.kubernetes.io/cors-allow-origin: "*"
spec:
ingressClassName: nginx
tls:
- hosts:
1 -
rules:
2 - host:
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: titanic-service
port:
number: 80titanic.kub.sspcloud.fr (mais ne tentez pas celui-là, il est déjà pris 😃)
Appliquer ces fichiers de configuration sur le cluster : kubectl apply -f deployment/
Si tout a correctement fonctionné, vous devriez pouvoir accéder depuis votre navigateur à l’API à l’URL spécifiée dans le fichier deployment/ingress.yaml. Par exemple https://toto.kub.sspcloud.fr/ si vous avez mis celui-ci plus tôt (et https://toto.kub.sspcloud.fr/docs pour la documentation).
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli182
rm -f update.sh
Notre API est accessible sans problème depuis Python ou notre navigateur.
En revanche, si on désire utiliser JavaScript pour créer une application interactive il est indispensable de mettre les lignes un peu obscure sur le CORS dans le fichier ingress.yaml.
Comme c’est un point technique qui ne concerne pas les compétences liées à ce cours, nous avons donné directement les lignes correspondantes dans ce fichier.
On peut remarquer quelques voies d’amélioration de notre approche qui seront ultérieurement traitées:
kubectl apply -f deployment/ à chaque changement de notre code. Autrement dit, lors de cette application, on a amélioré la fiabilité du lancement de notre API mais un lancement manuel est encore indispensable. Comme dans le reste de ce cours, on va essayer d’éviter un geste manuel pouvant être source d’erreur en privilégiant l’automatisation et l’archivage dans des scripts. C’est l’objet de la prochaine étape.A partir de maintenant, il est nécessaire de clarifier la branche principale sur laquelle nous travaillons. De manière traditionnelle, on utilise la branche main. Si vous avez changé de branche, vous pouvez continuer 1/ continuer mais en tenir compte dans les exemples ultérieurs ou 2/ fusionner celle-ci à main.
Si vous avez utilisé un tag pour sauter une ou plusieurs étapes, il va être nécessaire de se placer sur une branche car vous êtes en head detached. Pour cela, après avoir committé les fichiers que vous désirez garder
terminal
dev locale (si elle existe).
dev remote (si elle existe).
dev locale et on se place sur cette branche.
dev et active la synchronisation entre la branche locale et la branche remote.
Qu’est-ce qui peut déclencher une évolution nécessitant de mettre à jour l’ensemble de notre processus de production ?
Regardons à nouveau notre pipeline:
Les inputs de notre pipeline sont donc:
.env de configuration ou les secrets renseignés à Github relèvent de cette catégorie ;Github), les étapes ultérieures (production de l’image Docker, etc.) se lancent. Néanmoins, on veut aussi éviter qu’une erreur puisse donner lieu à une mise en production non-fonctionnelle, on va donc maintenir une action manuelle minimale comme garde-fou.Ici, nous nous plaçons dans le cas simple où les données brutes reçues sont figées. Ce qui peut changer est la manière dont on constitue nos échantillons train/test. Il sera donc utile de logguer les données en question par le biais de MLFlow. Mais il n’est pas nécessaire de versionner les données brutes.
Si celles-ci évoluaient, il pourrait être utile de versionner les données, à la manière dont on le fait pour le code. Git n’est pas l’outil approprié pour cela. Parmi les outils populaires de versionning de données, bien intégrés avec S3, il y a sur le SSPCloud lakefs.
Pour automatiser au maximum la mise en production, on va utiliser un nouvel outil : ArgoCD. Ainsi, au lieu de devoir appliquer manuellement la commande kubectl apply à chaque modification des fichiers de déploiement (présents dans le dossier kubernetes/), c’est l’opérateur ArgoCD, déployé sur le cluster, qui va détecter les changements de configuration du déploiement et les appliquer automatiquement.
C’est l’approche dite GitOps : le dépôt Git du déploiement fait office de source de vérité unique de l’état voulu de l’application, tout changement sur ce dernier doit donc se répercuter immédiatement sur le déploiement effectif.
ArgoCD sur le SSPCloud depuis la page Mes services (catalogue Automation). Laisser les configurations par défaut.GitHub, créer un dépôt application-deployment qui va servir de dépôt GitOps, c’est à dire un dépôt qui spécifie le paramétrage du déploiement de votre application.deployment à votre dépôt GitOps, dans lequel on mettra les trois fichiers de déploiement qui permettent de déployer notre application sur Kubernetes (deployment.yaml, service.yaml, ingress.yaml).GitOps, créez un fichier application.yml avec le contenu suivant, en prenant bien soin de modifier les lignes surlignées avec les informations pertinentes :application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: ensae-mlops
spec:
project: default
source:
1 repoURL: https://github.com/<your_github_username>/application-deployment.git
2 targetRevision: main
3 path: deployment
destination:
server: https://kubernetes.default.svc
4 namespace: user-<your_sspcloud_username>
syncPolicy:
automated:
selfHeal: trueGithub faisant office de dépôt GitOps.
Kubernetes.
Kubernetes. Sur le SSPCloud, cela prend la forme user-${username}.
Github le dépôt GitOps.ArgoCD, cliquez sur New App puis Edit as a YAML. Copiez-collez le contenu de application.yml et cliquez sur Create.ArgoCD le déploiement progressif des ressources nécessaires à votre application sur le cluster. Joli non ?ingress.yml.deployment puisque c’est maintenant votre dépôt de déploiement qui le contrôle.README.md que le déploiement de votre application (dont vous pouvez mettre l’URL dans le README) est contrôlé par un autre dépôt.Si cela a fonctionné, vous devriez maintenant voir votre application dans votre tableau de bord ArgoCD:
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli19a2
rm -f update.sh
A présent, nous avons tous les outils à notre disposition pour construire un vrai pipeline de CI/CD, automatisé de bout en bout. Il va nous suffire pour cela de mettre à bout les composants :
dans la partie 4 de l’application, nous avons construit un pipeline de CI : on a donc seulement à faire un commit sur le dépôt de l’application pour lancer l’étape de build et de mise à disposition de la nouvelle image sur le DockerHub ;
dans l’application précédente, nous avons construit un pipeline de CD : ArgoCD suit en permanence l’état du dépôt GitOps, tout commit sur ce dernier lancera donc automatiquement un redéploiement de l’application.
Il y a donc un élément qui fait la liaison entre ces deux pipelines et qui nous sert de garde-fou en cas d’erreur : la version de l’application.
Jusqu’à maintenant, on a utilisé le tag latest pour définir la version de notre application. En pratique, lorsqu’on passe de la phase de développement à celle de production, on a plutôt envie de versionner proprement les versions de l’application afin de savoir ce qui est déployé. On va pour cela utiliser les tags avec Git, qui vont se propager au nommage de l’image Docker.
prod.yml pour assurer la propagation des tags.Fichier .github/workflows/prod.yml
.github/workflows/prod.yml
name: Construction image Docker
on:
push:
branches:
- main
- dev
tags:
- 'v*.*.*'
jobs:
docker:
runs-on: ubuntu-latest
steps:
-
name: Set up QEMU
uses: docker/setup-qemu-action@v3
-
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
-
name: Docker meta
id: meta
uses: docker/metadata-action@v5
with:
1 images: linogaliana/application
-
name: Login to Docker Hub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
-
name: Build and push
uses: docker/build-push-action@v5
with:
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}api/main.py pour changer un élément de l’interface de votre documentation. Par exemple, mettre en gras un titre.app = FastAPI(
title="Démonstration du modèle de prédiction de survie sur le Titanic",
description=
"<b>Application de prédiction de survie sur le Titanic</b> 🚢 <br>Une version par API pour faciliter la réutilisation du modèle 🚀" +\
"<br><br><img src=\"https://media.vogue.fr/photos/5faac06d39c5194ff9752ec9/1:1/w_2404,h_2404,c_limit/076_CHL_126884.jpg\" width=\"200\">"
)Commit et push les changements.
Tagger le commit effectué précédemment et push le nouveau tag :
terminal
$ git tag v0.0.1
$ git push --tagsGitHub de l’application que ce commit lance bien un pipeline de CI associé au tag v1.0.0. Une fois terminé, vérifier sur le DockerHub que le tag v0.0.1 existe bien parmi les tags disponibles de l’image.La partie CI a correctement fonctionné. Intéressons-nous à présent à la partie CD.
GitOps, mettre à jour la version de l’image à déployer en production dans le fichier deployment/deployment.yamlFichier deployment/deployment.yaml
deployment/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: titanic-deployment
labels:
app: titanic
spec:
replicas: 1
selector:
matchLabels:
app: titanic
template:
metadata:
labels:
app: titanic
spec:
containers:
- name: titanic
1 image: linogaliana/application:v0.0.1
ports:
- containerPort: 5000ArgoCD le statut de votre application. Normalement, l’opérateur devrait avoir automatiquement identifié le changement, et mettre à jour le déploiement pour en tenir compte.
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli19b2
rm -f update.sh
terminal
$ git checkout appli19
$ git checkout -b dev
$ git push origin dev
On va proposer un nouveau livrable pour parler à un public plus large. Pour faire ce site web, on va utiliser Quarto et déployer sur Github Pages.
terminal
$ quarto create project website mysite_quarto.ymlabout.qmd, déplacer index.qmd vers la racine de notre projet.index.qmd par celui-ci et retirer about.qmd des fichiers à compiler.styles.css à la racine du projet.gitignore avec les instructions suivantes/.quarto/
*.html
*_files
_site/quarto preview (ajouter les arguments --port 5000 --host 0.0.0.0 si vous passez par le SSPCloud)Enfin, on va construire et déployer automatiquement ce site web grâce au combo Github Actions et Github Pages:
gh-pages à partir des lignes suivantesgit checkout --orphan gh-pages
git reset --hard # make sure all changes are committed before running this!
git commit --allow-empty -m "Initialising gh-pages branch"
git push origin gh-pages.github/workflows/website.yaml avec le contenu de ce fichierREADME pour indiquer l’URL de votre site web et de votre APIterminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli202
rm -f update.sh
terminal
$ git checkout appli20
$ git checkout -b dev
$ git push origin dev
Maintenant que nous avons tout préparé pour mettre à disposition rapidement un modèle, nous pouvons revenir en arrière pour améliorer ce modèle. Pour cela, nous allons mettre en oeuvre une validation croisée.
Le problème que nous allons rencontrer va être que nous voudrions facilement tracer les évolutions de notre modèle, la qualité prédictive de celui-ci dans différentes situations. Il s’agira d’à nouveau mettre en place du logging mais, cette fois, de suivre la qualité du modèle et pas seulement s’il fonctionne. L’outil MLFlow va répondre à ce problème et va, au passage, fluidifier la mise à disposition du modèle de production, c’est-à-dire de celui qu’on désire mettre à disposition du public.
Pour pouvoir faire ceci, il va falloir changer un tout petit peu notre code applicatif dans sa phase d’entraînement.
train.py pour faire une grid search
train.py
"""
Prediction de la survie d'un individu sur le Titanic
"""
import os
from dotenv import load_dotenv
import argparse
from loguru import logger
import pathlib
from joblib import dump
import pandas as pd
from sklearn.model_selection import GridSearchCV
from src.pipeline.build_pipeline import split_train_test, create_pipeline
from src.models.train_evaluate import evaluate_model
# ENVIRONMENT CONFIGURATION ---------------------------
logger.add("recording.log", rotation="500 MB")
load_dotenv()
parser = argparse.ArgumentParser(description="Paramètres du random forest")
parser.add_argument(
"--n_trees", type=int, default=20, help="Nombre d'arbres"
)
args = parser.parse_args()
URL_RAW = "https://minio.lab.sspcloud.fr/lgaliana/ensae-reproductibilite/data/raw/data.csv"
n_trees = args.n_trees
jeton_api = os.environ.get("JETON_API", "")
data_path = os.environ.get("data_path", URL_RAW)
data_train_path = os.environ.get("train_path", "data/derived/train.parquet")
data_test_path = os.environ.get("test_path", "data/derived/test.parquet")
MAX_DEPTH = None
MAX_FEATURES = "sqrt"
if jeton_api.startswith("$"):
logger.info("API token has been configured properly")
else:
logger.warning("API token has not been configured")
# IMPORT ET STRUCTURATION DONNEES --------------------------------
p = pathlib.Path("data/derived/")
p.mkdir(parents=True, exist_ok=True)
TrainingData = pd.read_csv(data_path)
X_train, X_test, y_train, y_test = split_train_test(
TrainingData, test_size=0.1,
train_path=data_train_path,
test_path=data_test_path
)
# PIPELINE ----------------------------
# Create the pipeline
pipe = create_pipeline(
n_trees, max_depth=MAX_DEPTH, max_features=MAX_FEATURES
)
param_grid = {
"classifier__n_estimators": [10, 20, 50],
"classifier__max_leaf_nodes": [5, 10, 50],
}
pipe_cross_validation = GridSearchCV(
pipe,
param_grid=param_grid,
scoring=["accuracy", "precision", "recall", "f1"],
refit="f1",
cv=5,
n_jobs=5,
verbose=1,
)
pipe = pipe_cross_validation.best_estimator_
# ESTIMATION ET EVALUATION ----------------------
pipe.fit(X_train, y_train)
dump(pipe, 'model.joblib')
# Evaluate the model
score, matrix = evaluate_model(pipe, X_test, y_test)
logger.success(f"{score:.1%} de bonnes réponses sur les données de test pour validation")
logger.debug(20 * "-")
logger.info("Matrice de confusion")
logger.debug(matrix)api/main.py), changer la version du modèle mis en oeuvre en “0.2”v0.0.2deployment/deployment.yaml dans le code GitOps pour utiliser ce tag.terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli212
rm -f update.sh
MLFlowterminal
$ git stash
$ git checkout appli21
MLFlow
Lancer MLFlow depuis l’onflet Mes services du SSPCloud. Attendre que le service soit bien lancé. Cela créera un service dont l’URL est de la forme https://user-{username}.user.lab.sspcloud.fr. Ce service MLFlow communiquera avec les VSCode que vous ouvrirez ultérieurement à partir de cet URL ainsi qu’avec le système de stockage S317.
Regarder la page Experiments. Elle ne contient que Default à ce stade, c’est normal.
Une fois le service MLFlow fonctionnel, lancer un nouveau VSCode pour bénéficier de la connexion automatique entre les services interactifs du SSPCloud et les services d’automatisation comme MLFlow.
Clôner votre projet, vous situer sur la branche de travail.
Dans la section de passage des paramètres de notre ligne de commande, introduire ce morceau de code:
parser = argparse.ArgumentParser(description="Paramètres du random forest")
parser.add_argument(
"--n_trees", type=int, default=20, help="Nombre d'arbres"
)
parser.add_argument(
"--experiment_name", type=str, default="titanicml", help="MLFlow experiment name"
)
args = parser.parse_args()Faire tourner train.py en ligne de commande puis retourner sur l’UI de MLFlow et observer la différence, à gauche.
A la fin du script train.py, ajouter le code suivant
fin de train.py
# LOGGING IN MLFLOW -----------------
input_data_mlflow = mlflow.data.from_pandas(
TrainingData, source=data_path, name="Raw dataset"
)
training_data_mlflow = mlflow.data.from_pandas(
pd.concat([X_train, y_train], axis=1), source=data_path, name="Training data"
)
with mlflow.start_run():
# Log datasets
mlflow.log_input(input_data_mlflow, context="raw")
mlflow.log_input(training_data_mlflow, context="raw")
# Log parameters
mlflow.log_param("n_trees", n_trees)
mlflow.log_param("max_depth", MAX_DEPTH)
mlflow.log_param("max_features", MAX_FEATURES)
# Log best hyperparameters from GridSearchCV
best_params = pipe_cross_validation.best_params_
for param, value in best_params.items():
mlflow.log_param(param, value)
# Log metrics
mlflow.log_metric("accuracy", score)
# Log confusion matrix as an artifact
matrix_path = "confusion_matrix.txt"
with open(matrix_path, "w") as f:
f.write(str(matrix))
mlflow.log_artifact(matrix_path)
# Log model
mlflow.sklearn.log_model(pipe, "model")Ajouter mlruns/* dans .gitignore
Tester train.py en ligne de commande
Observer l’évolution de la page Experiments. Cliquer sur un des run. Observer toutes les métadonnées archivées (hyperparamètres, métriques d’évaluation, requirements.txt dont MLFlow a fait l’inférence, etc.)
Observer le code proposé par MLFlow pour récupérer le run en question. Tester celui-ci dans un notebook sur le fichier intermédiaire de test au format Parquet
En ligne de commande, faites tourner pour une autre valeur de n_trees. Retourner à la liste des runs en cliquant à nouveau sur “titanicml” dans les expérimentations
Dans l’onglet Table, sélectionner plusieurs expérimentations, cliquer sur Columns et ajouter la statistique d’accuracy. Ajuster la taille des colonnes pour la voir et classer les modèles par score décroissants
Cliquer sur Compare après en avoir sélectionné plusieurs. Afficher un scatterplot des performances en fonction du nombre d’estimateurs. Conclure.
terminal
curl -sSL https://raw.githubusercontent.com/ensae-reproductibilite/website/refs/heads/main/chapters/applications/overwrite.sh -o update.sh && chmod +x update.sh
./update.sh appli222
rm -f update.sh
Cette appplication illustre l’un des premiers apports de MLFlow: on garde une trace de nos expérimentations: le modèle est archivé avec les paramètres et des métriques de performance. On peut donc retrouver de plusieurs manières un modèle qui nous avait tapé dans l’oeil.
Néanmoins, persistent un certain nombre de voies d’amélioration dans notre pipeline.
train.py.Les prochaines applications permettront d’améliorer ceci.
MLFlowA l’heure actuelle, notre pipeline est linéaire:
Ceci nous gêne pour faire évoluer notre modèle: on ne dissocie pas ce qui relève de l’entraînement du modèle de son utilisation. Un pipeline plus cyclique permettra de mieux dissocier l’expérimentation de la production:
Si vous avez entraîné plusieurs modèles avec des n_trees différents, utiliser l’interface de MLFlow pour sélectionner le “meilleur”. Cliquer sur le modèle en question et faire l’action “Register Model”. L’enregistrer comme le modèle de “production”
Rendez-vous sur l’onglet Models et observez cet entrepôt de modèles. Cliquez sur le modèle de production. Vous pourrez par ce biais suivre ses différentes versions.
Ouvrir un notebook temporaire et observer le résultat.
import mlflow
import pandas as pd
model_name = "production"
model_version = "latest"
# Load the model from the Model Registry
model_uri = f"models:/{model_name}/{model_version}"
logged_model = mlflow.sklearn.load_model(model_uri)
# GENERATE PREDICTION DATA ---------------------
def create_data(
sex: str = "female",
age: float = 29.0,
fare: float = 16.5,
embarked: str = "S",
) -> str:
"""
"""
df = pd.DataFrame(
{
"Sex": [sex],
"Age": [age],
"Fare": [fare],
"Embarked": [embarked],
}
)
return df
data = pd.concat(
[create_data(age=40), create_data(sex="male")]
)
# PREDICTION ---------------------
logged_model.predict(pd.DataFrame(data))"""A simple API to expose our trained RandomForest model for Tutanic survival."""
from fastapi import FastAPI
import mlflow
import pandas as pd
# Preload model -------------------
model_name = "production"
model_version = "latest"
# Load the model from the Model Registry
model_uri = f"models:/{model_name}/{model_version}"
model = mlflow.sklearn.load_model(model_uri)
# Define app -------------------------
app = FastAPI(
title="Prédiction de survie sur le Titanic",
description=
"Application de prédiction de survie sur le Titanic 🚢 <br>Une version par API pour faciliter la réutilisation du modèle 🚀" +\
"<br><br><img src=\"https://media.vogue.fr/photos/5faac06d39c5194ff9752ec9/1:1/w_2404,h_2404,c_limit/076_CHL_126884.jpg\" width=\"200\">"
)
@app.get("/", tags=["Welcome"])
def show_welcome_page():
"""
Show welcome page with model name and version.
"""
return {
"Message": "API de prédiction de survie sur le Titanic",
"Model_name": 'Titanic ML',
"Model_version": "0.3",
}
@app.get("/predict", tags=["Predict"])
async def predict(
sex: str = "female",
age: float = 29.0,
fare: float = 16.5,
embarked: str = "S"
) -> str:
"""
"""
df = pd.DataFrame(
{
"Sex": [sex],
"Age": [age],
"Fare": [fare],
"Embarked": [embarked],
}
)
prediction = "Survived 🎉" if int(model.predict(df)) == 1 else "Dead ⚰️"
return predictionLes changements principaux de ce code sont:
api/run.sh. En supprimant la ligne relative à l’entraînement du modèle, vous devriez avoir#/bin/bash
uvicorn api.main:app --reload --host "0.0.0.0" --port 5000Mettons en production cette nouvelle version. Cela implique de faire les gestes suivants:
Publier un tag v0.0.3 pour le code applicatif
Mettre à jour notre manifeste dans le dépôt GitOps. En premier lieu, il faut changer la version de référence pour utiliser le tag v0.0.3. De plus, il faut déclarer la variable d’environnement MLFLOW_TRACKING_URI qui indique à Python l’entrepôt de modèles où aller chercher celui en production. La bonne pratique est de définir ceci hors du code, dans un fichier de configuration donc, ce qui est l’objet de notre manifeste deployment.yaml. On peut donc changer de cette manière ce fichier:
apiVersion: apps/v1
kind: Deployment
metadata:
name: titanic-deployment
labels:
app: titanic
spec:
replicas: 1
selector:
matchLabels:
app: titanic
template:
metadata:
labels:
app: titanic
spec:
containers:
- name: titanic
1 image: linogaliana/application:v0.0.3
ports:
- containerPort: 5000
env:
- name: MLFLOW_TRACKING_URI
2 value: https://user-${USERNAME}-mlflow.user.lab.sspcloud.fr
resources:
limits:
memory: "2Gi"
cpu: "1000m"A ce stade, nous avons amélioré la fiabilité de notre application car nous utilisons le meilleur modèle. Néanmoins, nos entraînements sont encore manuels. Là encore il y a des gains à avoir car cela paraît pénible à la longue de devoir systématiquement relancer des entraînements manuellement pour tester des variations de tel ou tel paramètre. Heureusement, nous allons pouvoir automatiser ceci également.
terminal
1$ git stash
$ git checkout appli23
Pour industrialiser nos entraînements, nous allons créer des processus parallèles indépendants pour chaque combinaison de nos hyperparamètres. Pour cela, l’outil pratique sur le SSPCloud est Argo workflows.
Chaque combinaison d’hyperparamètres sera un processus isolé à l’issue duquel sera loggué le résultat dans MLFlow. Ces entraînements auront lieu en parallèle.
argo-workflow/manifest.yamlapiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: titanic-training-workflow-
namespace: user-lgaliana
spec:
entrypoint: main
serviceAccountName: workflow
arguments:
parameters:
# The MLflow tracking server is responsible to log the hyper-parameter and model metrics.
- name: mlflow-tracking-uri
1 value: https://user-lgaliana-argo-workflows.user.lab.sspcloud.fr
- name: mlflow-experiment-name
2 value: titanicml
- name: model-training-conf-list
value: |
[
{ "n_trees": 10, "max_features": "log2" },
{ "n_trees": 20, "max_features": "sqrt" },
{ "n_trees": 20, "max_features": "log2" },
{ "n_trees": 50, "max_features": "sqrt" }
]
templates:
# Entrypoint DAG template
- name: main
dag:
tasks:
# Task 0: Start pipeline
- name: start-pipeline
template: start-pipeline-wt
# Task 1: Train model with given params
- name: train-model-with-params
dependencies: [ start-pipeline ]
template: run-model-training-wt
arguments:
parameters:
- name: max_features
value: "{{item.max_features}}"
- name: n_trees
value: "{{item.n_trees}}"
# Pass the inputs to the task using "withParam"
withParam: "{{workflow.parameters.model-training-conf-list}}"
# Now task container templates are defined
# Worker template for task 0 : start-pipeline
- name: start-pipeline-wt
inputs:
container:
image: busybox
command: [ sh, -c ]
args: [ "echo Starting pipeline" ]
# Worker template for task-1 : train model with params
- name: run-model-training-wt
inputs:
parameters:
- name: n_trees
- name: max_features
container:
3 image: linogaliana/application:v0.0.5
imagePullPolicy: Always
command: [sh, -c]
args: [
"python train.py --n_trees={{inputs.parameters.n_trees}} --max_features={{inputs.parameters.max_features}}"
]
env:
- name: MLFLOW_TRACKING_URI
value: "{{workflow.parameters.mlflow-tracking-uri}}"
- name: MLFLOW_EXPERIMENT_NAME
value: "{{workflow.parameters.mlflow-experiment-name}}"
- name: AWS_DEFAULT_REGION
value: us-east-1
- name: AWS_S3_ENDPOINT
value: minio.lab.sspcloud.frMLFLow dont nous allons avoir besoin (on propose de continuer sur titanicml)
Créer un service label studio pour évaluer la qualité du modèle
Il y a quelques différences entre le VSCode server mis à disposition sur le SSPCloud et la version desktop sur laquelle s’appuient beaucoup de ressources. A quelques extensions prêts (Data Wrangler, Copilot), les différences sont néanmoins minimes.↩︎
L’export dans un script .py a été fait directement depuis VSCode. Comme cela n’est pas vraiment l’objet du cours, nous passons cette étape et fournissons directement le script expurgé du texte intermédiaire. Mais n’oubliez pas que cette démarche, fréquente quand on a démarré sur un notebook et qu’on désire consolider en faisant la transition vers des scripts, nécessite d’être attentif pour ne pas risquer de faire une erreur.↩︎
Il est également possible avec VSCode d’exécuter le script ligne à ligne de manière interactive ligne à ligne (MAJ+ENTER). Néanmoins, cela nécessite de s’assurer que le working directory de votre console interactive est le bon. Celle-ci se lance selon les paramètres préconfigurés de VSCode et les votres ne sont peut-être pas les mêmes que les notres. Vous pouvez changer le working directory dans le script en utilisant le package os mais peut-être allez vous découvrir ultérieurement qu’il y a de meilleures pratiques…↩︎
Essayez de commit vos changements à chaque étape de l’exercice, c’est une bonne habitude à prendre.↩︎
Il est normal d’avoir des dossiers __pycache__ qui traînent en local : ils se créent automatiquement à l’exécution d’un script en Python. Néanmoins, il ne faut pas associer ces fichiers à Git, voilà pourquoi on les ajoute au .gitignore.↩︎
Nous proposons ici d’adopter le principe de la programmation fonctionnelle. Pour encore fiabiliser un processus, il serait possible d’adopter le paradigme de la programmation orientée objet (POO). Celle-ci est plus rebutante et demande plus de temps au développeur. L’arbitrage coût-avantage est négatif pour notre exemple, nous proposons donc de nous en passer. Néanmoins, pour une mise en production réelle d’un modèle, il peut être utle de l’adopter car certains frameworks, à commencer par les pipelines scikit, exigeront certaines classes et méthodes si vous désirez brancher des objets ad hoc à ceux-ci.↩︎
Attention, les données ont été committées au moins une fois. Les supprimer du dépôt ne les efface pas de l’historique. Si cette erreur arrive, le mieux est de supprimer le dépôt en ligne, créer un nouvel historique Git et partir de celui-ci pour des publications ultérieures sur Github. Néanmoins l’idéal serait de ne pas s’exposer à cela. C’est justement l’objet des bonnes pratiques de ce cours: un .gitignore bien construit et une séparation des environnements de stockage du code et des données seront bien plus efficaces pour vous éviter ces problèmes que tout les conseils de vigilance que vous pourrez trouver ailleurs.↩︎
Lorsqu’on développe du code qui finalement ne s’avère plus nécessaire, on a souvent un cas de conscience à le supprimer et on préfère le mettre de côté. Au final, ce syndrôme de Diogène est mauvais pour la pérennité du projet : on se retrouve à devoir maintenir une base de code qui n’est, en pratique, pas utilisée. Ce n’est pas un problème de supprimer un code ; si finalement celui-ci s’avère utile, on peut le retrouver grâce à l’historique Git et les outils de recherche sur Github. Le package vulture est très pratique pour diagnostiquer les morceaux de code inutiles dans un projet.↩︎
Le fichier __init__.py indique à Python que le dossier est un package. Il permet de proposer certaines configurations lors de l’import du package. Il permet également de contrôler les objets exportés (c’est-à-dire mis à disposition de l’utilisateur) par le package par rapport aux objets internes au package. En le laissant vide, nous allons utiliser ce fichier pour importer l’ensemble des fonctions de nos sous-modules. Ce n’est pas la meilleure pratique mais un contrôle plus fin des objets exportés demanderait un investissement qui ne vaut, ici, pas le coût.↩︎
Si vous désirez aussi contrôler la version de Python, ce qui peut être important dans une perspective de portabilité, vous pouvez ajouter une option, par exemple -p python3.10. Néanmoins nous n’allons pas nous embarasser de cette nuance pour la suite car nous pourrons contrôler la version de Python plus finement par le biais de Docker.↩︎
L’option -c passée après la commande python permet d’indiquer à Python que la commande ne se trouve pas dans un fichier mais sera dans le texte qu’on va directement lui fournir.↩︎
L’option -c passée après la commande python permet d’indiquer à Python que la commande ne se trouve pas dans un fichier mais sera dans le texte qu’on va directement lui fournir.↩︎
Pour comparer les deux listes, vous pouvez utiliser la fonctionnalité de split du terminal sur VSCode pour comparer les outputs de conda env export en les mettant en face à face.↩︎
Il est tout à fait normal de ne pas parvenir à créer une action fonctionnelle du premier coup. N’hésitez pas à pusher votre code après chaque question pour vérifier que vous parvenez bien à réaliser chaque étape. Sinon vous risquez de devoir corriger bout par bout un fichier plus conséquent.↩︎
Il existe une approche alternative pour faire des tests réguliers: les hooks Git. Il s’agit de règles qui doivent être satisfaites pour que le fichier puisse être committé. Cela assure que chaque commit remplisse des critères de qualité afin d’éviter le problème de la procrastination.
La documentation de pylint offre des explications supplémentaires. Ici, nous allons adopter une approche moins ambitieuse en demandant à notre action de faire ce travail d’évaluation de la qualité de notre code↩︎
Vous n’êtes pas obligés pour l’évaluation de mettre en oeuvre les jalons de plusieurs parcours. Néanmoins, vous découvrirez que chaque nouveau pas en avant est moins coûteux que le précédent si vous avez mis en oeuvre les réflexes des bonnes pratiques.↩︎
Par conséquent, MLFLow bénéficie de l’injection automatique des tokens pour pouvoir lire/écrire sur S3. Ces jetons ont la même durée avant expiration que ceux de vos services interactifs VSCode. Il faut donc, par défaut, supprimer et rouvrir un service MLFLow régulièrement. La manière d’éviter cela est de créer des service account sur https://minio-console.lab.sspcloud.fr/ et de les renseigner sur la page.↩︎
Comment gérer les checkpoints ?
Pour simplifier la reprise en cours de ce fil rouge, nous proposons un système de checkpoints qui s’appuient sur des tags
Git. Ces tags figent le projet tel qu’il est à l’issue d’un exercice donné.Si vous faites évoluer votre projet de manière expérimentale mais désirez tout de même utiliser à un moment ces checkpoints, il va falloir faire quelques acrobaties
Git. Pour cela, nous mettons à disposition un script qui permet de sauvegarder votre avancée dans un tag donné (au cas où, à un moment, vous vouliez revenir dessus) et écraser la branchemainavec le tag en question. Par exemple, si vous désirez reprendre après l’exercice 9, vous devrez faire tourner le code dans cette boite :Celui-ci sauvegarde votre avancée dans un tag nommé
dev_before_appli9, le pousse sur votre dépôtGithubpuis force votre branche à adopter l’état du tagappli9.