Referenz der Dienstspezifikation

Die Spezifikation der Snowpark Container Services befindet sich in YAML (https://yaml.org/spec/). Sie gibt Snowflake die notwendigen Informationen, um Ihren Dienst oder Job zu konfigurieren und auszuführen.

Die allgemeine Syntax ist wie folgt:

spec:
  containers:                           # container list
  - name: <name>
    image: <image-name>
    command:                            # optional list of strings
      - <cmd>
      - <arg1>
    args:                               # optional list of strings
      - <arg2>
      - <arg3>
      - ...
    env:                                # optional
        <key>: <value>
        <key>: <value>
        ...
    readinessProbe:                     # optional
        port: <TCP port-num>
        path: <http-path>
    volumeMounts:                       # optional list
      - name: <volume-name>
        mountPath: <mount-path>
      - name: <volume-name>
        ...
    resources:                          # optional
        requests:
          memory: <memory-reserved>
          nvidia.com/gpu: <count>
          cpu: <cpu-units>
        limits:
          memory: <memory-reserved>
          nvidia.com/gpu: <count>
          cpu: <cpu-units>
    secrets:                            # optional list
      - snowflakeSecret:
        secretKeyRef:
        envVarName:                      # specify this or directoryPath
        directoryPath:                   # specify this or envVarName
  endpoints:                             # optional endpoint list
    - name: <name>
      port: <TCP port-num>
      public: <true / false>
      protocol : < TCP / HTTP / HTTPS >
    - name: <name>
      ...
  volumes:                               # optional volume list
    - name: <name>
      source: local | @<stagename> | memory
      size: <amount-of-memory>           # specify if memory is the volume source
    - name: <name>
      source: local | @<stagename> | memory
      size: <amount-of-memory>           # specify if memory is the volume source
      ...
  logExporters:
    eventTableConfig:
      logLevel: <INFO | ERROR | NONE>
Copy

Allgemeine Richtlinien

Eine Dienst-/Jobspezifikation hat auf oberster Ebene die folgenden spec-Felder:

  • spec.containers (erforderlich): Eine Liste von einem oder mehreren Anwendungscontainern. Ihre containerisierte Anwendung muss mindestens einen Container haben.

  • spec.endpoints (optional): Eine Liste der Endpunkte, die der Dienst öffentlich bereitstellt. Sie können einen öffentlichen Endpunkt wählen, der den Netzwerkzugang (Eingehende Daten) zum Dienst ermöglicht.

  • spec.volumes (optional): Eine Liste von Speichervolumes, die von den Containern verwendet werden sollen.

  • spec.logExporters (optional): Dieses Feld verwaltet die Ebene der Containerprotokolle, die in die Ereignistabelle Ihres Kontos exportiert werden.

Für die name-Felder (Container-, Endpunkt- und Volume-Namen) gelten die folgenden Formatrichtlinien:

  • Kann bis zu 63 Zeichen lang sein

  • Kann eine Sequenz von alphanumerischen Kleinbuchstaben oder „-“-Zeichen enthalten

  • Muss mit einem alphabetischen Zeichen beginnen

  • Muss mit einem alphanumerischen Zeichen enden

Achtung

Kunden müssen sicherstellen, dass bei der Nutzung des Snowflake-Dienstes keine personenbezogenen Daten (außer für ein Objekt „Benutzer“), sensible Daten, exportkontrollierte Daten oder andere regulierte Daten als Metadaten in die Spezifikationsdatei eingegeben werden. Weitere Informationen dazu finden Sie unter Metadatenfelder in Snowflake.

In den folgenden Abschnitten werden die einzelnen spec-Felder der obersten Ebene erläutert.

Feld spec.containers (erforderlich)

Das Feld containers enthält eine Liste der OCI-Container in Ihrer Anwendung. Für jeden Container sind nur die Felder name und image Pflichtfelder. Das Feld image bezieht sich auf den Namen des Images, das Sie in ein Snowflake-Image-Repository Ihres Snowflake-Kontos hochgeladen haben. Beispiel:

spec:
  containers:
    - name: echo
      image: /tutorial_db/data_schema/tutorial_repository/echo_service:dev
Copy

Wenn Sie einen Dienst (oder einen Job) erstellen, führt Snowflake diese Container auf einem Einzelknoten im angegebenen Computepool aus, der dieselbe Netzwerkschnittstelle nutzt. Sie können mehrere Dienstinstanzen ausführen; in diesem Fall wird jeder Satz dieser Container als Dienstinstanz bezeichnet.

Bemerkung

Snowpark Container Services erfordert derzeit Images der linux/amd64-Plattform.

In den folgenden Abschnitten werden die Typen von containers-Feldern erläutert.

Felder containers.command und containers.args

Verwenden Sie diese optionalen Felder, um den Einstiegspunkt des Containers (den Befehl, den der Container zusammen mit allen Parametern ausführt) zu überschreiben, der in Dockerfile (Teil Ihres Anwendungsimages) definiert ist, ohne dass Sie Ihr Anwendungsimage neu erstellen müssen:

  • containers.command übersteuert den ENTRYPOINT von Dockerfile. Auf diese Weise können Sie eine andere ausführbare Datei in dem Container ausführen.

  • containers.args übersteuert den CMD von Dockerfile. Auf diese Weise können Sie dem Befehl (der ausführbaren Datei) verschiedene Argumente bereitstellen.

Beispiel

Ihre Dockerfile-Datei enthält den folgenden Code:

ENTRYPOINT ["python3", "main.py"]
CMD ["Bob"]
Copy

Diese Dockerfile-Einträge führen den python3-Befehl aus und übergeben zwei Argumente: main.py und Bob. Sie können diese Werte in der Spezifikationsdatei wie folgt überschreiben:

  • Um ENTRYPOINT zu überschreiben, fügen Sie das Feld containers.command in die Spezifikationsdatei ein:

    spec:
      containers:
      - name: echo
        image: <image_name>
        command:
        - python3.9
        - main.py
    
    Copy
  • Um das Argument „Bob“ zu überschreiben, fügen Sie das Feld containers.args in die Spezifikationsdatei ein:

    spec:
      containers:
      - name: echo
        image: <image_name>
        args:
          - Alice
    
    Copy

Feld containers.env

Verwenden Sie das Feld containers.env, um Umgebungsvariablen anzugeben, die an alle Prozesse in Ihrem Container übergegeben werden:

spec:
  containers:
  - name: <name>
    image: <image_name>
    env:
      ENV_VARIABLE_1: <value1>
      ENV_VARIABLE_2: <value2>
      
      
Copy

Beispiel

In Tutorial 1 liest der Anwendungscode (echo_service.py) die Umgebungsvariablen mit Standardwerten, wenn der Wert nicht explizit gesetzt ist.

CHARACTER_NAME = os.getenv('CHARACTER_NAME', 'I')
SERVER_PORT = os.getenv('SERVER_PORT', 8080)
Copy
  • CHARACTER_NAME: Wenn der Echo-Dienst eine HTTP POST-Anforderung mit einer Zeichenfolge (z. B. „Hallo“) empfängt, gibt der Dienst „I said Hello“ (Ich sagte Hallo) zurück. Sie können diesen Standardwert in der Spezifikationsdatei überschreiben. Wenn Sie beispielsweise den Wert auf „Bob“ setzen, gibt der Echo-Dienst die Antwort „Bob said Hello“ (Bob sagte Hallo) zurück.

  • SERVER_PORT: In dieser Standardkonfiguration überwacht der Echo-Dienst Port 8080. Sie können den Standardwert überschreiben und einen anderen Port angeben.

Die folgende Spezifikationsdatei übersteuert diese beiden Umgebungsvariablenwerte:

spec:
  containers:
  - name: echo
    image: <image_name>
    env:
      CHARACTER_NAME: Bob
      SERVER_PORT: 8085
  endpoints:
  - name: echo-endpoint
    port: 8085
Copy

Sie müssen aber Folgendes beachten: Da Sie die Portnummer, den Ihr Dienst überwacht, geändert haben, hat die Spezifikation auch den Endpunkt (Feldwert endpoints.port) aktualisiert.

Feld containers.readinessProbe

Verwenden Sie das containers.readinessProbe-Objekt, um Snowflake einen Bereitschaftstest in Ihrer Anwendung bereitzustellen. Snowflake ruft diesen Test auf, um festzustellen, ob Ihre Anwendung bereit ist, Anforderungen zu bedienen.

Snowflake stellt eine HTTP-GET-Anforderung an den angegebenen Bereitschaftstest mit dem angegebenen Port und Pfad und wartet darauf, dass Ihr Dienst einen HTTP 200-OK-Status zurückgibt, um sicherzustellen, dass nur funktionstüchtige Container den Datenverkehr bedienen.

Verwenden Sie die folgenden Felder, um die erforderlichen Informationen anzugeben:

  • port: Der Netzwerkport, den der Dienst auf Anforderungen des Bereitschaftstests hin überwacht. Dieser Port muss nicht als Endpunkt deklariert sein.

  • path: Snowflake stellt HTTP-GET-Anforderungen an den Dienst mit diesem Pfad.

Beispiel

In Tutorial 1 implementiert der Anwendungscode (echo_python.py) den folgenden Bereitschaftstest:

@app.get("/healthcheck")
def readiness_probe():
Copy

Dementsprechend enthält die Spezifikationsdatei das Feld containers.readinessProbe:

spec:
  containers:
  - name: echo
    image: <image_name>
    env:
      SERVER_PORT: 8088
      CHARACTER_NAME: Bob
    readinessProbe:
      port: 8088
      path: /healthcheck
  endpoints:
  - name: echo-endpoint
    port: 8088
Copy

Der vom Bereitschaftstest angegebene Port muss kein konfigurierter Endpunkt sein. Ihr Dienst könnte einen anderen Port nur für den Zweck des Bereitschaftstests überwachen.

Feld containers.volumeMounts

Da die Felder spec.volumes und spec.containers.volumeMounts zusammenarbeiten, werden sie zusammen in einem Abschnitt erläutert. Weitere Informationen dazu finden Sie unter Feld spec.volumes (optional).

Feld containers.resources

Snowflake legt fest, wie die verfügbaren Computepool-Ressourcen zur Ausführung Ihrer Anwendung verwendet werden sollen. Es wird empfohlen, die Ressourcenanforderungen für Ihre Dienstinstanzen ausdrücklich anzugeben und in der Spezifikation entsprechende Limits festzulegen. Beachten Sie, dass die von Ihnen angegebenen Ressourcen durch die Instanz-Familie der Knoten in Ihrem Computepool eingeschränkt sind. Weitere Informationen dazu finden Sie unter CREATE COMPUTE POOL.

Snowflake stellt sicher, dass die durch containers.resources.requests spezifizierten Ressourcen bereitgestellt werden und verhindert außerdem, dass der Dienst mehr als die in containers.resources.limits angegebenen Limits verwendet. Sie können Anforderungen und Grenzen für die folgenden Ressourcen festlegen:

  • memory: Dies ist der für Ihren Anwendungscontainer benötigte Arbeitsspeicher. Für die Angabe der Werte kann eine dezimale oder eine binäre Einheit verwendet werden. Beispielsweise steht „2G“ für eine Anforderung von 2.000.000.000 Bytes. Weitere Informationen dazu finden Sie unter Allgemeine Informationen zu Maßeinheiten.

  • cpu: Dies bezieht sich auf virtuelle Verarbeitungseinheiten (vCPU). Beispielsweise ist die 1 CPU-Einheit gleichbedeutend mit 1 vCPU. Erlaubt sind auch Anforderungen von Bruchteilen, wie „0.5“, die auch als „500m“ ausgedrückt werden können. Weitere Informationen dazu finden Sie unter Allgemeine Informationen zu Maßeinheiten.

  • nvidia.com/gpu: Wenn GPUs erforderlich sind, müssen diese angefordert werden, und es muss auch ein limit-Wert für dieselbe Menge angegeben werden. Wenn Ihr Container keine Anforderungen und Limits für die GPU-Kapazität angibt, ist kein Zugriff auf GPUs möglich. Die Anzahl der GPUs, die Sie anfordern können, ist durch die maximale Anzahl von GPUs begrenzt, die von dem Instanz-Typ in INSTANCE_TYPE unterstützt wird, den Sie beim Erstellen eines Computepools auswählen. Weitere Informationen dazu finden Sie unter CREATE COMPUTE POOL.

Wenn Snowflake die Ressourcen, die explizit in der Spezifikationsdatei enthalten sind, nicht zuweisen kann, können Sie die Dienste zwar erstellen (mit CREATE SERVICE), aber der Dienststatus zeigt an, dass der Dienst aufgrund unzureichender Ressourcen nicht geplant werden kann.

Beispiel 1

In der folgenden Spezifikation beschreibt das Feld containers.resources die Ressourcenanforderungen für den Container:

spec:
  containers:
  - name: resource-test-gpu
    image: ...
    resources:
      requests:
        memory: 2G
        cpu: 0.5
        nvidia.com/gpu: 1
      limits:
        memory: 4G
        nvidia.com/gpu: 1
Copy

In diesem Beispiel wird Snowflake aufgefordert, dem Container mindestens 2 GB Arbeitsspeicher, eine GPU und einen halben CPU-Kern zuzuweisen. Gleichzeitig darf der Container nicht mehr als 4 GB Arbeitsspeicher und eine GPU verwenden.

Beispiel 2

  • Sie erstellen einen Computepool mit zwei Knoten, wobei jeder Knoten 16 GB Arbeitsspeicher und eine GPU hat:

    CREATE COMPUTE POOL tutorial_compute_pool
      MIN_NODES = 2
      MAX_NODES = 2
      INSTANCE_FAMILY = gpu_nv_s
    
    Copy
  • Sie erstellen einen Dienst, der Snowflake auffordert, zwei Instanzen des Dienstes auszuführen:

    CREATE SERVICE echo_service
      MIN_INSTANCES=2
      MAX_INSTANCES=2
      IN COMPUTE POOL tutorial_compute_pool
      FROM @<stage_path>
      SPEC=<spec-file-stage-path>;
    
    Copy

    Sowohl MIN_INSTANCES als auch MAX_INSTANCES werden auf 2 gesetzt. Daher wird Snowflake zwei Instanzen des Dienstes ausführen.

Wenn Sie die Ressourcenanforderungen nicht explizit in Ihre Anwendungsspezifikation aufnehmen, entscheidet Snowflake, ob diese Instanzen auf demselben Knoten oder auf verschiedenen Knoten im Computepool ausgeführt werden sollen.

  • Sie geben den Ressourcenbedarf an und fordern 10 GB Arbeitsspeicher für den Container:

    - name: resource-test
      image: ...
      resources:
        requests:
          memory: 10G
    
    Copy

    Ihr Computepool-Knoten verfügt über 16 GB Arbeitsspeicher, wobei Snowflake nicht zwei Container auf demselben Knoten ausführen kann. Snowflake führt die beiden Dienstinstanzen auf separaten Knoten im Computepool aus.

  • Die Anforderung für den Container ist 1 GB Arbeitsspeicher und eine GPU:

    spec:
      containers:
      - name: resource-test-gpu
        image: ...
        resources:
          requests:
            memory: 2G
            nvidia.com/gpu: 1
          limits:
            nvidia.com/gpu: 1
    
    Copy

    Sie fordern eine GPU pro Container an, und jeder Knoten hat nur eine GPU. In diesem Fall kann Snowflake nicht beide Dienste auf einem Knoten einplanen, obwohl der Arbeitsspeicher kein Problem darstellt. Diese Anforderung zwingt Snowflake dazu, die beiden Dienstinstanzen auf zwei separaten Computepool-Knoten auszuführen.

Feld containers.secrets

secrets:                            # optional list
  - snowflakeSecret:
    secretKeyRef:
    envVarName:                      # specify this or directoryPath
    directoryPath:                   # specify this or envVarName
Copy

Verwenden Sie containers.secrets, um Snowflake Geheimnisobjekte zu übergeben, die der Container zum Authentifizieren verwenden kann, wenn ein Dienst oder Job mit externen Endpunkten (außerhalb von Snowflake) kommuniziert. Weitere Informationen dazu finden Sie unter Verwenden von Snowflake-Geheimnissen zur Übergabe von Anmeldeinformationen an einen Container.

  • snowflakeSecret (erforderlich): Name eines Geheimnisobjekts von Snowflake.

  • secretKeyRef: Der Name des Schlüssels im Geheimnis. Wenn dieses Feld angegeben wird, übergibt Snowflake den mit dieser Schlüsselreferenz verbundenen Wert an den Container. Erforderlich für grundlegende Authentifizierungsgeheimnisse, die als Umgebungsvariablen eingebunden sind. Sie geben dieses Feld nur an, wenn Sie Geheimnisse an Umgebungsvariablen in Containern übergeben.

  • envVarName: Der Name der Umgebungsvariablen, die das Geheimnis enthält. Entweder dieses oder das Feld directoryPath ist erforderlich.

  • directoryPath: Der Verzeichnispfad im Container, in den die Geheimnisse kopiert werden sollen. Snowflake füllt eine Datei für jeden Geheimnisschlüssel in diesem angegebenen Verzeichnis. Wenn Sie directoryPath angeben, geben Sie nicht secretKeyRef an. Entweder dieses oder das Feld envVarName ist erforderlich.

Weitere Informationen dazu finden Sie unter Übergeben von Snowflake-Geheimnissen an einen Container.

Feld spec.endpoints (optional)

Verwenden Sie das Feld spec.endpoints, um eine Liste von Namen für die TCP-Netzwerkports anzugeben, die Ihre Anwendung öffentlich bereitstellt. Snowpark Container Services können null bis viele Endpunkte bereitstellen. Verwenden Sie die folgenden Felder, um einen Endpunkt zu beschreiben:

  • name: Eindeutiger Name des Endpunkts. Wenn Sie sich in einer Dienstfunktion auf den Endpunkt beziehen, geben Sie diesen Namen an.

  • port: Der Netzwerkport, den Ihre Anwendung auf Anforderungen hin überwacht.

  • protocol: Das Protokoll, das der Endpunkt unterstützt. Folgende Werte werden unterstützt: TCP, HTTP und HTTPS. Das Standardprotokoll ist HTTP. Das Protokoll muss HTTP oder HTTPS sein, wenn dieser Endpunkt öffentlich oder das Ziel einer Dienstfunktion ist (siehe Verwenden eines Dienstes).

  • public: Wenn dieser Endpunkt über das Internet zugänglich sein soll, setzen Sie dieses Feld auf true.

Bemerkung

Snowflake führt für den öffentlichen Zugriff Authentifizierungs- und Autorisierungsprüfungen durch, die nur Snowflake-Benutzern mit entsprechender Berechtigung die Verwendung des Dienstes ermöglichen.

Beispiel

Im Folgenden finden Sie die Anwendungsspezifikation, die in Tutorial 1 verwendet wird:

spec:
  container:
  - name: echo
    image: <image-name>
    env:
      SERVER_PORT: 8000
      CHARACTER_NAME: Bob
    readinessProbe:
      port: 8000
      path: /healthcheck
  endpoint:
  - name: echoendpoint
    port: 8000
    public: true
Copy

Dieser Anwendungscontainer stellt einen Endpunkt öffentlich zur Verfügung. Der Container enthält auch das optionale Feld public, um den Zugriff auf den Endpunkt von außerhalb von Snowflake (Internetzugang) zu ermöglichen. Standardmäßig ist public auf false eingestellt.

Feld spec.volumes (optional)

Dieser Abschnitt erklärt die beiden Felder spec.volumes und spec.containers.volumeMounts. volumes definiert ein freigegebenes Dateisystem. Der Wert von volumeMount definiert, wo ein Volume in einem Container erscheint. Mehrere Container können das gleiche Volume gemeinsam nutzen. Daher ist volumes ein Feld auf spec-Ebene, und volumeMount ist Teil einer Container-Spezifikation.

Verwenden Sie diese Felder, um sowohl die Volumes als auch die Volumebereitstellungen zu beschreiben.

  • Verwenden Sie spec.volumes, um die für Ihre Container verfügbaren Volumes anzugeben. volumes ist eine Liste. Das heißt, es kann mehrere Volumes geben. Verwenden Sie die folgenden Felder, um ein Volume zu beschreiben:

    • name: Eindeutiger Name des Volumes. Er wird mit spec.containers.volumeMounts.name bezeichnet.

    • source: Dies kann local, memory oder "@<stagename>" sein.

    • uid: Bei einem Snowflake-Stagingbereichs-Volume ist dies die „uid“ der eingebundenen Datei.

    • gid: Bei einem Snowflake-Stagingbereichs-Volume ist dies die „gid“ der eingebundenen Datei.

    • size: Bei einem Arbeitsspeicher-Volume ist dies die Größe des Volumes.

  • Verwenden Sie spec.containers.volumeMounts, um anzugeben, wo die angegebenen Volumes im Dateisystem des Containers eingebunden sind. containers.volumeMounts ist ebenfalls eine Liste. Das heißt, jeder Container kann mehrere Volume-Bereitstellungen haben. Verwenden Sie die folgenden Felder, um eine Volume-Bereitstellung zu beschreiben:

    • name: Der Name des einzubindenden Volumes. Ein einzelner Container kann mehrfach auf dasselbe Volume verweisen.

    • mountPath: Der Dateipfad, unter dem das Volume für den Container eingebunden werden soll.

Snowflake unterstützt die folgenden Volume-Typen für Anwendungscontainer: lokale Volumes, Arbeitsspeicher und Snowflake-Stagingbereich.

  • Lokales Volume: Container in einer Dienstinstanz können einen lokalen Datenträger zur Freigabe von Dateien verwenden. Wenn Ihre Anwendung beispielsweise aus zwei Containern besteht – einem Anwendungscontainer und einem Protokollanalysator – kann die Anwendung Protokolle in das lokale Volume schreiben, und der Protokollanalysator kann die Protokolle lesen.

    Wenn Sie mehrere Instanzen eines Dienstes ausführen, müssen Sie beachten, dass nur Container, die zu einer Dienstinstanz gehören, Volumes gemeinsam nutzen können. Container, die zu verschiedenen Dienstinstanzen gehören, können Volumes nicht gemeinsam verwenden.

  • Arbeitsspeicher: Sie können ein RAM-gestütztes Dateisystem für die Verwendung im Container verwenden.

  • Snowflake-Stagingbereich: Sie können einen Snowflake-Stagingbereich erstellen und damit Containern schnellen Zugriff auf bereitgestellte Stagingdateien geben. Für das Einbinden eines Snowflake-Stagingbereichs gelten die folgenden Bedingungen:

    • Externe Stagingbereiche werden nicht unterstützt. Es werden nur interne Snowflake-Stagingbereiche mit SSE-Verschlüsselung (siehe Interne Stagingbereichsparameter) unterstützt. Verwenden Sie CREATE STAGE, um einen solchen Stagingbereich zu erstellen:

      CREATE STAGE my_stage ENCRYPTION = (type = 'SNOWFLAKE_SSE');
      
      Copy
    • Sie können einen Stagingbereich, z. B. @my_stage, oder ein Unterverzeichnis in einem Stagingbereich, z. B. @my_stage/folder, einbinden. Sie können aber keine Datei in einem Stagingbereich, z. B. @my_stage/folder/file, einbinden.

    • Die Dienstrolle bestimmt die Berechtigungen, die Containern für den Zugriff auf einen eingebundenen Stagingbereich erteilt werden. Die Dienstrolle ist die Rolle, mit der der Dienst oder Job erstellt wird. Es ist auch die Rolle, die von Dienst oder Job für alle Snowflake-Interaktionen verwendet.

      Wenn die Dienstrolle beispielsweise nicht über die WRITE-Berechtigung für einen Stagingbereich verfügt, ist die Einbindung dieses Stagingbereichs schreibgeschützt. Das heißt, die Container können die Dateien nur aus dem Stagingbereich lesen. Wenn die Dienstrolle die WRITE-Berechtigung für einen Stagingbereich hat, unterstützt die Einbindung dieses Stagingbereich sowohl das Lesen als auch das Schreiben. Snowflake lädt Dateiaktualisierungen asynchron hoch.

    • Ein Container, der einen Snowflake-Stagingbereich einbindet, wird normalerweise als Root-Benutzer ausgeführt. Es kann jedoch vorkommen, dass Ihr Container als Nicht-Root-Benutzer ausgeführt wird. Beispiel:

      • Wenn Ihre Anwendung eine Drittanbieter-Bibliothek verwendet, benutzt die Bibliothek einen Nicht-Root-Benutzer, um den Anwendungscode innerhalb des Containers auszuführen.

      • Sie können Ihre Anwendung auch aus anderen Gründen, z. B. aus Sicherheitsgründen, als Nicht-Root-Benutzer innerhalb des Containers ausführen.

        Um mögliche Fehler im Zusammenhang mit den Dateibenutzerrechten zu vermeiden, ist es wichtig, die UID (Benutzer-ID) und die GID (Gruppen-ID) des Containers als Teil der Spezifikation festzulegen. Dies ist besonders wichtig für Container, die einen bestimmten Benutzer und eine bestimmte Gruppe zum Starten oder Ausführen der Anwendung innerhalb des Containers verwenden. Durch Festlegen der entsprechenden UID und GID können Sie einen Container verwenden, der als ein Nicht-Root-Benutzer ausgeführt wird. Beispiel:

        spec:
          ...
        
          volumes:
          - name: stagemount
            source: "@test"
            uid: <UID-value>
            gid: <GID-value>
        
        Copy

        Snowflake verwendet diese Informationen, um den Stagingbereich mit den entsprechenden Berechtigungen einzubinden.

        So erhalten Sie die UID und GID des Containers:

        1. Führen Sie den Container lokal mit docker run aus.

        2. Suchen Sie die Container-ID mit dem Befehl docker container list. Hier ist ein Ausschnitt einer Beispielausgabe:

          CONTAINER ID   IMAGE                       COMMAND
          —----------------------------------------------------------
          a6a1f1fe204d  tutorial-image         "/usr/local/bin/entr…"
          
        3. Führen Sie den Befehl docker id innerhalb des Containers aus, um die Werte von UID und GID zu erhalten:

          docker exec -it <container-id> id
          
          Copy

          Beispielausgabe:

          uid=0(root) gid=0(root) groups=0(root)
          

Beispiel

Ihre Anwendung für maschinelles Lernen umfasst die folgenden zwei Container:

  • Container app für die Hauptanwendung

  • Container logger-agent, der Protokolleinträge sammelt und sie zu Amazon S3 hochlädt

Diese Container verwenden die folgenden zwei Volumes:

  • Volume local: Diese Anwendung schreibt Protokolleinträge, die der Logger-Agent liest.

  • Snowflake-Stagingbereich @model_stage: Die Hauptanwendung liest Dateien aus diesem Stagingbereich.

In der folgenden Beispielspezifikation bindet der Container app sowohl das Volume logs als auch das Volume models ein, und der Container logging-agent bindet nur das Volume logs ein:

spec:
  containers:
  - name: app
    image: <image1-name>
    volumeMounts:
    - name: logs
      mountPath: /opt/app/logs
    - name: models
      mountPath: /opt/models
  - name: logging-agent
    image: <image2-name>
    volumeMounts:
    - name: logs
      mountPath: /opt/logs
  volumes:
  - name: logs
    source: local
  - name: models
    source: "@model_stage"
Copy

Wenn mehrere Instanzen des Dienstes ausgeführt werden, verwenden die Container logging-agent und app innerhalb einer Dienstinstanz das Volume logs gemeinsam. Das Volume logs ist nicht für mehrere Dienstinstanzen freigegeben.

Wenn Ihr app-Container zusätzlich zu diesen Volumes auch ein 2-GB-Arbeitsspeicher-Volume verwendet, überarbeiten Sie die Spezifikation, um das Volume in die volumes-Liste aufzunehmen, und fügen Sie außerdem eine weitere Volume-Bereitstellung in die volumeMounts-Liste des app-Containers ein:

spec:
  containers:
  - name: app
    image: <image1-name>
    volumeMounts:
    - name: logs
      mountPath: /opt/app/logs
    - name: models
      mountPath: /opt/models
    - name: my-mem-volume
      mountPath: /dev/shm
  - name: logging-agent
    image: <image2-name>
    volumeMounts:
    - name: logs
      mountPath: /opt/logs
  volumes:
  - name: logs
    source: local
  - name: models
    source: "@model_stage"
  - name: "my-mem-volume"
    source: memory
    size: 2G
Copy

Wenn Sie memory als Volume source angeben, müssen Sie auch das Feld volumes.size spezifizieren, um die Größe des Arbeitsspeichers anzugeben. Weitere Informationen zu den Größeneinheiten für Arbeitsspeicher, die Sie verwenden können, finden Sie unter Allgemeine Informationen zu Maßeinheiten.

Feld spec.logExporters (optional)

Verwenden Sie spec.logExporters, um zu konfigurieren, wie Snowflake Ihre Anwendungsprotokolle erfasst. Snowflake erfasst die Ausgaben des Codes Ihres Anwendungscontainers, die an die Standardausgabe oder den Standardfehler gehen.

Snowflake exportiert diese Protokolleinträge in eine Ereignistabelle in Ihrem Konto. Weitere Informationen dazu finden Sie unter Zugriff auf lokale Containerprotokolle. Geben Sie mit spec.logExporters.eventTableConfig an, welche Protokolle in der Ereignistabelle gespeichert werden sollen:

logExporters:
  eventTableConfig:
    logLevel: < INFO | ERROR | NONE >
Copy

Folgende logLevel-Werte werden unterstützt:

  • INFO: Alle Benutzerprotokolleinträge exportieren.

  • ERROR: Nur Fehlerprotokolleinträge exportieren. Snowflake exportiert nur die Protokolle aus dem „stderr“-Stream.

  • NONE (Standard): Es werden keine Protokolleinträge in die Ereignistabelle exportiert.

Allgemeine Informationen zu Maßeinheiten

Eine Dienstspezifikation enthält an mehreren Stellen numerische Werte. Snowpark Container Services unterstützt eine Vielzahl von Einheiten, um diese Werte auszudrücken. Für große und kleine Werte können Sie, wie gezeigt, binäre und dezimale Maßeinheiten verwenden. In der folgenden Liste steht „#“ für einen Ganzzahlwert (Integer).

  • Binäreinheiten:

    • numberKi bedeutet number*1024. Beispielsweise ist memory: 4Ki äquivalent zu memory: 4096.

    • numberMi bedeutet number*1024^2.

    • numberGi bedeutet number*1024^3.

  • Dezimaleinheiten:

    • numberk bedeutet number*10^3. Beispielsweise ist memory: 4k äquivalent zu memory: 4000.

    • numberM bedeutet number*10^6.

    • numberG bedeute number*10^9.

  • Bruchteileinheiten:

    • numberm bedeutet number*0.001. Beispielsweise ist cpu: 500m äquivalent zu cpu: 0.5.