Utilisation de votre propre conteneur

Vous pouvez créer et utiliser un conteneur personnalisé (Utiliser votre propre conteneur ou BYOC) pour la création d'un travail et de ses exécutions.

La taille maximale d'une image de conteneur que vous pouvez utiliser avec les tâches est de 25 Go. La taille de l'image de conteneur ralentit le temps de provisionnement de la tâche en raison de l'extraction du conteneur à partir du registre de conteneurs. Nous vous recommandons d'utiliser les plus petites images de conteneur possibles.

Pour exécuter le travail, vous devez créer votre Dockerfile et une image. Vous commencez par un fichier Dockerfile qui utilise une version réduite de l'image Python. Le fichier Dockerfile permet de créer des sous-versions locales et distantes. Vous utilisez la sous-version locale pour tester localement le code. Lors du développement local, vous n'avez pas besoin de créer de nouvelle image à chaque modification de code.
Note

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 le fichier Dockerfile lorsque vous pensez avoir terminé le code et souhaitez 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.

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. Veillez à la copier immédiatement dans un emplacement sécurisé.

  1. Pour voir les détails : 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électionnezGé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
    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 dans lequel il est prêt à être exécuté 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 de l'API vers le répertoire d'origine des utilisateurs du 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 racine, vous modifiez le chemin d'accès à /root/.oci.

    docker run --rm -v $HOME/.oci:/home/datascience/.oci -v $PWD:/app byoc python /app/job_logs.py
    
    Le test local avec le code est 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 d'API OCI est toujours requis.

    docker run --rm -v $HOME/.oci:/home/datascience/.oci -v $PWD:/app byoc
  9. Entrer et parcourir le code de conteneur
    docker run -it byoc sh
    ls
    exit
  10. Marquez votre 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. Poussez votre image de conteneur :
    docker push <region>.ocir.io/<tenancy>/byoc:1.0
  12. Assurez-vous que les travaux comportent une politique pour le principal de ressource afin qu'il puisse lire l'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. Cela n'est requis que si vous utilisez la vérification de signature d'image.
  14. (Facultatif) Assurez-vous que les travaux comportent une politique pour le principal de ressource afin de lui permettre d'utiliser le service de chambre forte à partir du compartiment dans lequel les clés de chambre forte pour la signature d'image sont stockées. La politique n'est nécessaire que pour la vérification de la 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 une tâche à l'aide de la fenêtre contextuelle de configuration de l'environnement. Voir l'étape 9 sous Création d'un travail.
    • BYOC version 1 : Créez un travail à l'aide de la variable d'environnement de travail, 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
      Note

      BYOC version 1 est maintenant obsolète et n'est pas la méthode recommandée.