Utilisation de votre propre conteneur

Vous pouvez créer et utiliser un conteneur personnalisé (Utiliser votre propre conteneur ou BYOC) à utiliser lorsque vous créez un travail et des traitements de travail.

La taille maximale d'une image de conteneur que vous pouvez utiliser avec des travaux est de 25 Go. La taille de l'image de conteneur ralentit le temps de provisionnement du travail en raison de l'extraction de conteneur à partir de Container Registry. Nous vous recommandons d'utiliser les plus petites images de conteneur possibles.

Pour exécuter le travail, vous devez créer votre propre fichier Dockerfile et créer une image. Vous commencez par Dockerfile, qui utilise l'image mince Python. Le fichier Docker est conçu pour que vous puissiez créer des builds locaux et distants. Utilisez le build local lorsque vous effectuez un test local sur le code. Lors du développement local, vous n'avez pas besoin de créer une image pour chaque modification de code.
Remarque

Ne stockez pas les fichiers dans le répertoire /home/datascience. Lorsque le conteneur est provisionné et exécuté en tant qu'exécution de travail, il est remplacé dans ce répertoire.

Utilisez l'option distante pour exécuter Dockerfile lorsque vous pensez que le code est terminé et que vous voulez l'exécuter en tant que travail, comme dans cet exemple Dockerfile :

ARG type

FROM python:3.8-slim AS base

ENV DATASCIENCE_USER datascience
ENV DATASCIENCE_UID 1000
ENV HOME /home/$DATASCIENCE_USER

RUN python -m pip install \
        parse \
        oci


FROM base AS run-type-local
# nothing to see here

FROM base AS run-type-remote
COPY job_logs.py .
CMD ["python", "job_logs.py"]

FROM run-type-${type} AS final

Voici un exemple de fichier job_logs.py :

import oci
import datetime
import os
import time
import sys
import uuid
from oci.loggingingestion import LoggingClient
from oci.loggingingestion.models import PutLogsDetails, LogEntryBatch, LogEntry

OCI_RESOURCE_PRINCIPAL_VERSION = "OCI_RESOURCE_PRINCIPAL_VERSION"
JOB_RUN_OCID_KEY = "JOB_RUN_OCID"

# switch
class Job:
    def __init__(self):
        rp_version = os.environ.get(OCI_RESOURCE_PRINCIPAL_VERSION, "UNDEFINED")
        if not rp_version or rp_version == "UNDEFINED":
            # RUN LOCAL TEST
            self.signer = oci.config.from_file("~/.oci/config", "BIGDATA")
        else:
            # RUN AS JOB
            self.signer = oci.auth.signers.get_resource_principals_signer()


job = Job()

print(
    "Start logging for job run: {}".format(
        os.environ.get(JOB_RUN_OCID_KEY, "LOCAL")
    )
)
print("Current timestamp in UTC: {}".format(str(datetime.datetime.utcnow())))

print("Delay 5s")

time.sleep(5)

print("... another stdout")

print("Print all environment variables and values")

for item, value in os.environ.items():
    print("{}: {}".format(item, value))

print("Docker Job Done.")
Conseil

Nous avons fourni plusieurs exemples pour vous aider à démarrer.

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. Veillez donc à copier immédiatement le jeton d'authentification vers un emplacement sécurisé.

  1. Pour afficher les détails : dans la barre de navigation, sélectionnez le menu Profil, puis sélectionnez Paramètres utilisateur ou Mon profil, selon l'option que vous voyez.
  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
    OptionDescription
    Exécuter localement

    Crée le fichier docker, mais n'inclut pas le code pour une exécution rapide, un débogage, etc. :

    docker build --build-arg type=local -t byoc .
    Exécuter en tant que travail

    Crée le fichier docker avec le code qu'il est prêt à exécuter en tant que travail :

    docker build --build-arg type=remote -t byoc .
    OptionDescription
    Test local avec l'emplacement du code monté

    La clé d'autorisation d'API du répertoire utilisateur de base docker ./oci est montée. Si vous utilisez un autre utilisateur dans l'image docker, vous devez modifier le chemin /home/datascience/.oci. Par exemple, si vous utilisez un compte root, vous remplacez le chemin par /root/.oci.

    docker run --rm -v $HOME/.oci:/home/datascience/.oci -v $PWD:/app byoc python /app/job_logs.py
    
    Les tests locaux avec le code se trouvent dans le conteneur

    Même lorsque le conteneur est créé à l'aide de l'option remote pour stocker le code dans l'image, pour une exécution locale, le jeton d'authentification de l'API OCI est toujours requis.

    docker run --rm -v $HOME/.oci:/home/datascience/.oci -v $PWD:/app byoc
  9. Entrer et parcourir le code conteneur
    docker run -it byoc sh
    ls
    exit
  10. Balisez l'image de conteneur locale :
    docker login -u '<tenant-namespace>/<username>' <region>.ocir.io
    docker tag byoc:latest<region>.ocir.io/<tenancy-name>/byoc:1.0
  11. Propagez l'image de conteneur :
    docker push <region>.ocir.io/<tenancy>/byoc:1.0
  12. Assurez-vous que les travaux disposent d'une stratégie permettant au principal de ressource de lire OCIR à partir du compartiment dans lequel vous avez stocké l'image.
    allow dynamic-group {<your-dynamic-group-name>} to read repos in compartment {<your-compartment-name>}
  13. (Facultatif) Signez l'image de conteneur. Ceci n'est requis que si vous utilisez la vérification de signature d'image.
  14. (Facultatif) Assurez-vous que les travaux disposent d'une stratégie permettant au principal de ressource d'utiliser le service de coffre à partir du compartiment dans lequel les clés de coffre pour la signature d'image sont stockées. La stratégie est nécessaire uniquement pour la vérification de signature d'image.
    Allow dynamic-group <dynamic-group-name> to use vaults in compartment <compartment-name>
    Allow dynamic-group <dynamic-group-name> to use keys in compartment <compartment-name>
    Allow dynamic-group <dynamic-group-name> to use secret-family in compartment <compartment-name>
  15. Sélectionnez l'une des options suivantes pour créer un travail :
    • BYOC version 2 : créez un travail à l'aide de la fenêtre contextuelle de configuration d'environnement. Reportez-vous à l'étape 9 dans Création d'un travail.
    • BYOC version 1 : créez un travail à l'aide de la variable d'environnement de travail, en pointant vers l'emplacement de l'image de conteneur dans votre OCIR pour l'exécuter en tant que travail :
      CONTAINER_CUSTOM_IMAGE=iad.ocir.io/mytenancyname/byoc:1.0
      Remarque

      BYOC version 1 est désormais en phase d'abandon et n'est pas la méthode recommandée.