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 l'image de conteneur résidant dans le registre OCI.
• Assurez-vous que l'image de conteneur existe dans le registre OCI 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 correctifs.
• Seuls les conteneurs docker sont pris en charge par BYOC.
• Le service de science des données utilise l'artefact de modèle compressé pour apporter la logique de notation du modèle d'apprentissage automatique et s'attend à ce qu'il soit disponible dans le catalogue de modèles du service de science des données.
• La taille de l'image du conteneur est limitée à 16 Go sous forme non compressée.
• Le service de science des données ajoute une tâche HEALTHCHECK avant de démarrer le conteneur afin que la politique HEALTHCHECK n'ait pas à être ajoutée explicitement dans le fichier Docker, car elle est remplacée. La vérification de l'état commence à s'exécuter 10 minutes après le démarrage du conteneur, puis vérifie /health toutes les 30 secondes, avec une temporisation de trois secondes et trois nouvelles tentatives par vérification.
• Un ensemble curl doit être installé dans l'image de conteneur pour que la politique HEALTHCHECK Docker réussisse.
• L'utilisateur qui crée la ressource de déploiement de modèle doit avoir accès à l'image de conteneur dans le registre OCI pour pouvoir l'utiliser. Dans le cas contraire, créez une politique IAM d'accès utilisateur avant de créer un déploiement de modèle.
• Le docker CMD ou Entrypoint doit être fourni au moyen de l'API ou du fichier Dockerfile, qui démarre le serveur Web.
• La temporisation définie 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 sain) dans cette période.
• Testez toujours le conteneur localement avant de le déployer dans le nuage à l'aide d'un déploiement de modèle.

Les images dans un registre Docker sont identifiées par un référentiel, un nom et un marqueur. En outre, Docker attribue un condensé alphanumérique unique à chaque version d'une image. Lors de la transmission d'une image Docker mise à jour, nous recommandons d'affecter un nouveau marqueur à l'image mise à jour pour l'identifier, plutôt que de réutiliser un marqueur existant. Cependant, même si vous poussez une image mise à jour et que vous lui donnez le même nom et le même marqueur que ceux d'une version précédente, la nouvelle version poussée a un condensé différent de la version précédente.

Lorsque vous créez une ressource de déploiement de modèle, spécifiez le nom et le marqueur d'une version particulière d'une image sur laquelle baser le déploiement de modèle. Pour éviter les incohérences, le déploiement de modèle enregistre le condensé unique de cette version de l'image. Vous pouvez également fournir le condensé de l'image lors de la création d'un déploiement de modèle.

Par défaut, lorsque vous poussez une version mise à jour d'une image vers le registre Docker avec le même nom et le même marqueur que la version initiale de l'image sur laquelle le déploiement de modèle est basé, il continue d'utiliser le condensé initial pour extraire la version initiale de l'image. Si vous voulez 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 un marqueur et un condensé 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 de faire fonctionner le conteneur et d'exécuter les demandes d'inférence.

Le conteneur doit exposer un point d'extrémité /health pour retourner l'état du serveur d'inférence et un point d'extrémité /predict pour l'inférence.

Le fichier Python suivant dans l'artefact de modèle définit ces points d'extrémité à 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 du registre de conteneurs pour OCI. 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 ensembles 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 machine locale. Vous devez faire référence aux fichiers stockés sur votre machine locale 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 par le service :

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

Tester en envoyant une demande de prédiction :

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

Avant de pouvoir pousser des images vers et depuis Oracle Cloud Infrastructure Registry (également appelé Registre de conteneurs), vous devez avoir un jeton d'autorisation Oracle Cloud Infrastructure. Vous voyez uniquement la chaîne du jeton d'authentification lors de sa création. Copiez-la immédiatement dans un emplacement sécurisé.

1. Pour voir les détails dans la console : Dans la barre de navigation, sélectionnez le menu Profil, puis Paramètres de l'utilisateur ou Mon profil, selon l'option que vous voyez.
2. Dans la page Jetons d'authentification, sélectionnez Générer un jeton.
3. Entrez une description conviviale pour le jeton d'authentification. Évitez d'entrer 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é où vous pourrez l'extraire plus tard. Vous ne verrez plus le jeton d'authentification dans la console.
6. Fermez la boîte de dialogue Générer un jeton.
7. Ouvrez une fenêtre de terminal sur votre ordinateur local.
8. Connectez-vous au registre de conteneurs pour pouvoir créer, exécuter, tester, marquer et pousser l'image du conteneur.

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

9. Marquez l'image de conteneur local :

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

10. Poussez l'image de conteneur :

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

    Note
    
    

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

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

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é autrement inchangé. 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ésultats dans un état où serverPort et environmentVariables sont remplacés par le contenu de la mise à jour (y compris la destruction des données précédemment présentes dans des champs profonds absents du contenu de la mise à jour). La valeur image est conservée inchangée car elle n'apparaissait pas dans le contenu de la mise à jour et la valeur entrypoint est effacée 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, de sorte que si vous ne fournissez pas l'image, elle ne doit pas annuler la définition de l'image dans le déploiement. Le service de science des données ne remplace les champs de deuxième niveau que s'ils ne sont pas nuls.

Ne pas définir de champ dans l'objet de demande (transmission d'une valeur nulle) signifie que le service de science des données ne tiendra pas compte de ce champ pour rechercher la différence et le remplacer par la valeur de champ existante.

Pour réinitialiser une valeur d'un champ, transmettez un objet vide. Pour les champs de type liste et mappage, le service de science des données peut accepter une liste vide ([]) ou un mappage ({}) comme indication pour effacer les valeurs. Dans tous les cas, null ne signifie pas effacer les valeurs. Cependant, vous pouvez toujours changer la valeur pour quelque chose d'autre. Pour utiliser un port par défaut et annuler la définition de la valeur du champ, définissez explicitement le port par défaut.

La mise à jour de la liste et des champs de mappage est un remplacement complet. Le service de science des données ne recherche pas les valeurs individuelles dans les objets.

Pour l'image et le condensé, le service de science des données ne vous permet pas d'effacer la valeur.