Bring Your Own Container

Creare o specificare queste interfacce necessarie per utilizzare una distribuzione modello.

• La distribuzione del modello supporta solo l'immagine del contenitore presente nel registro OCI.
• Assicurarsi che l'immagine del contenitore esista nel registro OCI durante tutto il ciclo di vita della distribuzione del modello. L'immagine deve esistere per garantire la disponibilità nel caso in cui un'istanza venga riavviata automaticamente o il team del servizio esegua l'applicazione delle patch.
• Con BYOC sono supportati solo i container docker.
• Data Science utilizza l'artifact modello compresso per portare la logica di punteggio del modello ML e prevede che sia disponibile nel catalogo dei modelli Data Science.
• La dimensione dell'immagine del contenitore è limitata a 16 GB in formato non compresso.
• Data Science aggiunge un task HEALTHCHECK prima di avviare il contenitore, in modo che il criterio HEALTHCHECK non debba essere aggiunto in modo esplicito nel file Docker perché viene sostituito. Il controllo dello stato inizia a essere eseguito 10 minuti dopo l'avvio del contenitore, quindi controlla /health ogni 30 secondi, con un timeout di tre secondi e tre nuovi tentativi per controllo.
• Affinché il criterio HEALTHCHECK Docker riesca, è necessario installare un package curl nell'immagine del contenitore.
• L'utente che crea la risorsa di distribuzione del modello deve avere accesso all'immagine del contenitore in OCI Registry per utilizzarla. In caso contrario, creare un criterio IAM di accesso utente prima di creare una distribuzione modello.
• Il docker CMD o Entrypoint deve essere fornito tramite l'API o il Dockerfile, che esegue il bootstrap del server Web.
• Il timeout definito dal servizio per l'esecuzione del contenitore è di 10 minuti, quindi assicurarsi che il contenitore di servizio di inferenza inizi (in buono stato) entro questo intervallo di tempo.
• Eseguire sempre il test del contenitore a livello locale prima di eseguire la distribuzione nel cloud utilizzando una distribuzione modello.

Le immagini in un registro Docker sono identificate da un repository, un nome e una tag. Inoltre, Docker offre a ogni versione di un'immagine un digest alfanumerico univoco. Quando si esegue il push di un'immagine Docker aggiornata, si consiglia di assegnare all'immagine aggiornata un nuovo tag per identificarla, anziché riutilizzare un tag esistente. Tuttavia, anche se si esegue il PUSH di un'immagine aggiornata e si assegna lo stesso nome e lo stesso tag di una versione precedente, la nuova versione sottoposta a PUSH ha un digest diverso rispetto alla versione precedente.

Quando si crea una risorsa di distribuzione del modello, specificare il nome e la tag di una versione particolare di un'immagine su cui basare la distribuzione del modello. Per evitare incongruenze, la distribuzione del modello registra il digest univoco di tale versione dell'immagine. È inoltre possibile fornire il digest dell'immagine quando si crea una distribuzione del modello.

Per impostazione predefinita, quando si esegue il push di una versione aggiornata di un'immagine nel registro Docker con lo stesso nome e lo stesso tag della versione originale dell'immagine su cui si basa la distribuzione del modello, continua a utilizzare il digest originale per estrarre la versione originale dell'immagine. Se si desidera che la distribuzione del modello estragga la versione successiva dell'immagine, è possibile modificare in modo esplicito il nome dell'immagine con una tag e un digest utilizzati dalla distribuzione del modello per identificare la versione dell'immagine da estrarre.

Creare un file zip artifact e salvarlo con il modello nel catalogo modelli. L'artifact include il codice per utilizzare il contenitore ed eseguire le richieste di inferenza.

Il contenitore deve esporre un endpoint /health per restituire lo stato del server di inferenza e un endpoint /predict per l'inferenza.

Il seguente file Python nell'artifact modello definisce questi endpoint utilizzando un server Flask con porta 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)

Puoi utilizzare qualsiasi immagine da OCI Container Registry. Di seguito è riportato un dockerfile di esempio che utilizza il server 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

Creare un file requirements.txt con i seguenti pacchetti nella stessa directory di Dockerfile:

flask
flask-restful
joblib

Eseguire il comando docker build:

docker build -t ml_flask_app_demo:1.0.0 -f Dockerfile .

Assicurarsi che l'artifact modello e il codice inferenza si trovino nella stessa directory del Dockerfile. Eseguire il contenitore sul computer locale. È necessario fare riferimento ai file memorizzati sul computer locale attivando la directory del modello locale su /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

Inviare una richiesta di integrità per verificare che il contenitore sia in esecuzione entro i 10 minuti definiti dal servizio:

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

Eseguire il test inviando una richiesta di previsione:

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

Prima di poter eseguire il push e il pull delle immagini in e da Oracle Cloud Infrastructure Registry (noto anche come Container Registry), è necessario disporre di un token di autorizzazione per Oracle Cloud Infrastructure. La stringa del token di autenticazione viene visualizzata solo quando viene creata, quindi assicurarsi di copiare immediatamente il token di autenticazione in una posizione sicura.

1. Per visualizzare i dettagli nella console: nella barra di navigazione, selezionare il menu Profilo, quindi selezionare Impostazioni utente o Profilo personale, a seconda dell'opzione visualizzata.
2. Nella pagina Token di autenticazione selezionare Genera token.
3. Immettere una descrizione descrittiva per il token di autenticazione. Evitare di fornire informazioni riservate.
4. Selezionare Genera token. Viene visualizzato il nuovo token di autenticazione.
5. Copiare immediatamente il token di autenticazione in una posizione sicura in cui è possibile recuperarlo in seguito. Il token di autenticazione non verrà più visualizzato nella console.
6. Chiudere la finestra di dialogo Genera token.
7. Aprire una finestra di terminale sul computer locale.
8. Accedi a Container Registry in modo da poter creare, eseguire, testare, etichettare e inviare l'immagine del contenitore.

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

9. Tagare l'immagine del contenitore locale:

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

10. Push dell'immagine del contenitore:

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

    Nota
    
    

    Assicurarsi che la risorsa di distribuzione del modello disponga di un criterio per il principal risorsa in modo da poter leggere l'immagine dal registro OCI dal compartimento in cui è stata memorizzata l'immagine. Fornire l'accesso alla distribuzione del modello a un contenitore personalizzato mediante il principal risorsa

Le operazioni di aggiornamento BYOC sono aggiornamenti parziali di tipo unione superficiale.

Un campo di livello superiore scrivibile deve essere sostituito completamente quando viene visualizzato nel contenuto della richiesta e conservato invariato. Ad esempio, per una risorsa come la seguente:

{ 
    "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"]
}

Aggiornamento riuscito con i seguenti elementi:

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

Risultati in uno stato in cui serverPort e environmentVariables vengono sovrascritti dal contenuto dell'aggiornamento (inclusa la distruzione dei dati presenti in precedenza in campi in profondità assenti nel contenuto dell'aggiornamento). Il file image viene conservato invariato perché non è stato visualizzato nel contenuto dell'aggiornamento e entrypoint viene cancellato da un elenco vuoto esplicito:

{ 
    "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"]
}

Un aggiornamento riuscito con { "environmentConfigurationDetails": null or {} } non comporta la sovrascrittura di alcun elemento. Una sostituzione completa al livello superiore cancella tutti i valori che non sono presenti nel contenuto della richiesta in modo da evitare che. Tutti i campi sono facoltativi nell'oggetto di aggiornamento, pertanto se non si fornisce l'immagine non è necessario annullare l'impostazione dell'immagine nella distribuzione. Data Science sostituisce i campi di secondo livello solo se non sono nulli.

Se non si imposta un campo nell'oggetto richiesta (passando un valore nullo), Data Science non considererà tale campo per trovare la differenza e sostituirlo con il valore di campo esistente.

Per reimpostare un valore di qualsiasi campo, passare un oggetto vuoto. Per i campi elenco e tipo di mappa, Data Science può accettare un elenco vuoto ([]) o un mapping ({}) come indicazione per cancellare i valori. In ogni caso, null non significa cancellare i valori. Tuttavia, è sempre possibile modificare il valore in qualcos'altro. Per utilizzare una porta predefinita e annullare l'impostazione del valore del campo relativo, impostare in modo esplicito la porta predefinita.

L'aggiornamento ai campi elenco e mappa è una sostituzione completa. Data Science non guarda all'interno degli oggetti per i singoli valori.

Per immagine e digest, Data Science non consente di cancellare il valore.