Utilisation de votre propre conteneur

Créez ou spécifiez les interfaces requises pour utiliser un déploiement de modèle.

• Le déploiement de modèle prend uniquement en charge les images de conteneur résidant dans OCI Registry.
• Assurez-vous que l'image de conteneur existe dans OCI Registry tout au long du cycle de vie du déploiement de modèle. L'image doit exister pour garantir la disponibilité si une instance redémarre automatiquement ou si l'équipe de service applique des patches.
• Seuls les conteneurs docker sont pris en charge avec BYOC.
• Data Science utilise l'artefact de modèle compressé pour apporter la logique de scoring de modèle ML et s'attend à ce qu'il soit disponible dans le catalogue de modèles Data Science.
• La taille de l'image de conteneur est limitée à 16 Go sous forme non compressée.
• Data Science ajoute une tâche HEALTHCHECK avant de démarrer le conteneur. La stratégie HEALTHCHECK n'a donc pas besoin d'être ajoutée explicitement dans le fichier Docker car elle est remplacée. La vérification de l'état démarre 10 minutes après le démarrage du conteneur, puis vérifie /health toutes les 30 secondes, avec un délai d'expiration de trois secondes et trois tentatives par vérification.
• Un package curl doit être installé dans l'image de conteneur pour que la stratégie Docker HEALTHCHECK réussisse.
• L'utilisateur qui crée la ressource de déploiement de modèle doit avoir accès à l'image de conteneur dans OCI Registry pour pouvoir l'utiliser. Sinon, créez une stratégie IAM d'accès utilisateur avant de créer un déploiement de modèle.
• Le fichier docker CMD ou Entrypoint doit être fourni via l'API ou le fichier Dockerfile, qui démarre le serveur Web.
• Le délai d'expiration défini par le service pour l'exécution du conteneur est de 10 minutes. Assurez-vous donc que le conteneur de service d'inférence démarre (est en bon état) au cours de cette période.
• Testez toujours le conteneur localement avant de le déployer vers le cloud à l'aide d'un déploiement de modèle.

Les images d'un registre Docker sont identifiées par un référentiel, un nom et une balise. En outre, Docker attribue à chaque version d'image un condensé alphanumérique unique. Lors de la propagation d'une image Docker mise à jour, nous vous recommandons de fournir à l'image mise à jour une nouvelle balise pour l'identifier, plutôt que de réutiliser une balise existante. Toutefois, même si vous propagez une image mise à jour avec le même nom et la même balise qu'une version antérieure, la nouvelle version propagée dispose d'un condensé différent de la version précédente.

Lorsque vous créez une ressource de déploiement de modèle, indiquez le nom et la balise d'une version particulière d'une image sur laquelle baser le déploiement de modèle. Pour éviter toute incohérence, le déploiement de modèle enregistre la synthèse unique de cette version de l'image. Vous pouvez également fournir la synthèse de l'image lors de la création d'un déploiement de modèle.

Par défaut, lorsque vous propagez une version mise à jour d'une image vers le registre Docker avec les mêmes nom et balise que la version d'origine de l'image sur laquelle le déploiement de modèle est basé, il continue à utiliser le condensé d'origine pour extraire la version d'origine de l'image. Si vous souhaitez que le déploiement de modèle extraie la version ultérieure de l'image, vous pouvez modifier explicitement le nom de l'image avec une balise et une synthèse que le déploiement de modèle utilise pour identifier la version de l'image à extraire.

Créez un fichier ZIP d'artefact et enregistrez-le avec le modèle dans le catalogue de modèles. L'artefact inclut le code permettant d'utiliser le conteneur et d'exécuter les demandes d'inférence.

Le conteneur doit exposer une adresse /health pour renvoyer l'état du serveur d'inférence et une adresse /predict pour l'inférence.

Le fichier Python suivant dans l'artefact de modèle définit ces adresses à l'aide d'un serveur Flask avec le port 5000 :

# We now need the json library so we can load and export json data
import json
import os
import numpy as np
from sklearn.discriminant_analysis import LinearDiscriminantAnalysis
from sklearn.neural_network import MLPClassifier
import pandas as pd
from joblib import load
from sklearn import preprocessing
import logging

from flask import Flask, request

# Set environnment variables
WORK_DIRECTORY = os.environ["WORK_DIRECTORY"]
TEST_DATA = os.path.join(WORK_DIRECTORY, "test.json")
MODEL_DIR = os.environ["MODEL_DIR"]
MODEL_FILE_LDA = os.environ["MODEL_FILE_LDA"]
MODEL_PATH_LDA = os.path.join(MODEL_DIR, MODEL_FILE_LDA)

# Loading LDA model
print("Loading model from: {}".format(MODEL_PATH_LDA))
inference_lda = load(MODEL_PATH_LDA)

# Creation of the Flask app
app = Flask(__name__)


# API 1
# Flask route so that we can serve HTTP traffic on that route
@app.route('/health')
# Get data from json and return the requested row defined by the variable Line
def health():
    # We can then find the data for the requested row and send it back as json
    return {"status": "success"}

# API 2
# Flask route so that we can serve HTTP traffic on that route
@app.route('/predict',methods=['POST'])
# Return prediction for both Neural Network and LDA inference model with the requested row as input
def prediction():
    data = pd.read_json(TEST_DATA)
    request_data = request.get_data()
    print(request_data)
    print(type(request_data))
    if isinstance(request_data, bytes):
        print("Data is of type bytes")
        request_data = request_data.decode("utf-8")
    print(request_data)
    line = json.loads(request_data)['line']
    data_test = data.transpose()
    X = data_test.drop(data_test.loc[:, 'Line':'# Letter'].columns, axis = 1)
    X_test = X.iloc[int(line),:].values.reshape(1, -1)

    clf_lda = load(MODEL_PATH_LDA)
    prediction_lda = clf_lda.predict(X_test)

    return {'prediction LDA': int(prediction_lda)}


if __name__ == "__main__":
    app.run(debug=True, host='0.0.0.0', port = 5000)

Vous pouvez utiliser n'importe quelle image à partir d'OCI Container Registry. Voici un exemple de fichier Dockerfile qui utilise le serveur Flask :

FROM jupyter/scipy-notebook
  
USER root
RUN \
  apt-get update && \
  apt-get -y install curl
  
ENV WORK_DIRECTORY=/opt/ds/model/deployed_model
ENV MODEL_DIR=$WORK_DIRECTORY/models
RUN mkdir -p $MODEL_DIR
  
ENV MODEL_FILE_LDA=clf_lda.joblib
  
COPY requirements.txt /opt/requirements.txt
RUN pip install -r /opt/requirements.txt

Créez un fichier requirements.txt avec les packages suivants dans le même répertoire que Dockerfile :

flask
flask-restful
joblib

Exécutez la commande docker build :

docker build -t ml_flask_app_demo:1.0.0 -f Dockerfile .

Assurez-vous que l'artefact de modèle et le code d'inférence se trouvent dans le même répertoire que le fichier Dockerfile. Exécutez le conteneur sur votre ordinateur local. Vous devez vous référer aux fichiers stockés sur votre ordinateur local en montant le répertoire de modèle local sur /opt/ds/model/deployed_model :

docker run -p 5000:5000 \
  --health-cmd='curl -f http://localhost:5000/health || exit 1' \
  --health-interval=30s \
  --health-retries=3 \
  --health-timeout=3s \
  --health-start-period=1m \
  --mount type=bind,src=$(pwd),dst=/opt/ds/model/deployed_model \
  ml_flask_app_demo:1.0.0 python /opt/ds/model/deployed_model/api.py

Envoyez une demande d'état pour vérifier que le conteneur est en cours d'exécution dans les 10 minutes définies pour le service :

curl -vf http://localhost:5000/health

Effectuez un test en envoyant une demande de prédiction :

curl -H "Content-type: application/json" -X  POST http://localhost:5000/predict --data '{"line" : "12"}'

Pour pouvoir propager et extraire des images dans Oracle Cloud Infrastructure Registry (également appelé Container Registry), vous devez disposer d'un jeton d'autorisation Oracle Cloud Infrastructure. La chaîne du jeton d'authentification apparaît uniquement lors de sa création. Assurez-vous donc de copier immédiatement le jeton d'authentification vers un emplacement sécurisé.

1. Pour afficher les détails dans la console : dans la barre de navigation, sélectionnez le menu Profil, puis Paramètres utilisateur ou Mon profil, en fonction de l'option affichée.
2. Sur la page Jetons d'authentification, sélectionnez Générer un jeton.
3. Entrez la description conviviale du jeton d'authentification. Evitez de saisir des informations confidentielles.
4. Sélectionnez Générer un jeton. Le nouveau jeton d'authentification s'affiche.
5. Copiez immédiatement le jeton d'authentification vers un emplacement sécurisé duquel vous pourrez l'extraire ultérieurement. Le jeton d'authentification ne sera plus affiché dans la console.
6. Fermez la boîte de dialogue Générer un jeton.
7. Ouvrez une fenêtre de terminal sur l'ordinateur local.
8. Connectez-vous à Container Registry afin de pouvoir créer, exécuter, tester, baliser et propager l'image de conteneur.

   docker login -u '<tenant-namespace>/<username>' <region>.ocir.io

9. Balisez l'image de conteneur local :

   docker tag <local_image_name>:<local_version> <region>.ocir.io/<tenancy_ocir_namespace>/<repository>:<version>

10. Transmettez l'image de conteneur :

    docker push <region>.ocir.io/<tenancy>/byoc:1.0

    Remarque
    
    

    Assurez-vous que la ressource de déploiement de modèle dispose d'une stratégie pour le principal de ressource afin qu'elle puisse lire l'image à partir d'OCI Registry à partir du compartiment dans lequel vous avez stocké l'image. Octroi à un déploiement de modèle de l'accès à un conteneur personnalisé à l'aide du principal de ressource

Les opérations de mise à jour BYOC sont des mises à jour partielles de type fusion peu profondes.

Un champ de niveau supérieur accessible en écriture doit être complètement remplacé lorsqu'il apparaît défini dans le contenu de la demande et conservé sans modification. Par exemple, pour une ressource telle que :

{ 
    "environmentConfigurationDetails": {
        "environmentConfigurationType": "OCIR_CONTAINER",  
        "serverPort": 5454,
        "image": "iad.ocir.io/testtenancy/md_byoc_ref_iris_data:1.0.1",
        "imageDigest": "sha256:a9c8468cb671929aec7ad947b9dccd6fe8e6d77f7bcecfe2e10e1c935a88c2a5",
        "environmentVariables": {
            "a": "b",
            "c": "d",
            "e": "f"
        },
        "entrypoint": [ "python", "-m", "uvicorn", "a/model/server:app", "--port", "5000","--host","0.0.0.0"]
        "cmd": ["param1"]
}

Mise à jour réussie avec les éléments suivants :

{
    "environmentConfigurationDetails": {
        "serverPort": 2000, 
        "environmentVariables": {"x":"y"},
        "entrypoint": []
    }
}

Résultat : un état dans lequel serverPort et environmentVariables sont écrasés par le contenu de mise à jour (y compris la destruction des données précédemment présentes dans les champs profonds absents du contenu de mise à jour). image est conservé sans modification car il n'apparaît pas dans le contenu de mise à jour et entrypoint est effacé par une liste vide explicite :

{ 
    "environmentConfigurationDetails": {
        "environmentConfigurationType": "OCIR_CONTAINER",  
        "serverPort": 2000,
        "image": "iad.ocir.io/testtenancy/md_byoc_ref_iris_data:1.0.1",
        "imageDigest": "sha256:a9c8468cb671929aec7ad947b9dccd6fe8e6d77f7bcecfe2e10e1c935a88c2a5",
        "environmentVariables": {"x": "y"},
        "entrypoint": []
        "cmd": ["param1"]
}

Une mise à jour réussie à l'aide de { "environmentConfigurationDetails": null or {} } n'entraîne aucun remplacement. Un remplacement complet au niveau supérieur efface toutes les valeurs qui ne sont pas présentes dans le contenu de la demande afin d'éviter cela. Tous les champs sont facultatifs dans l'objet de mise à jour. Par conséquent, si vous ne fournissez pas l'image, vous ne devez pas annuler la définition de l'image dans le déploiement. Data Science ne remplace les champs de deuxième niveau que s'ils ne sont pas NULL.

Ne pas définir de champ dans l'objet de demande (en transmettant une valeur NULL) signifie que Data Science ne prendra pas en compte ce champ pour trouver la différence et le remplacement par la valeur de champ existante.

Pour réinitialiser la valeur d'un champ, transmettez un objet vide. Pour les champs de liste et de type de correspondance, Data Science peut accepter une liste vide ([]) ou une correspondance ({}) comme indication pour effacer les valeurs. Dans tous les cas, null ne signifie pas effacer les valeurs. Cependant, vous pouvez toujours remplacer la valeur par une autre valeur. Pour utiliser un port par défaut et annuler la définition de sa valeur de champ, définissez explicitement le port par défaut.

La mise à jour des champs de liste et de carte est un remplacement complet. Data Science ne recherche pas de valeurs individuelles dans les objets.

Pour l'image et la synthèse, Data Science ne vous permet pas d'effacer la valeur.