Snowpark Container Services: Verwenden von Diensten

Snowpark Container Services ermöglicht Ihnen die einfache Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen. Nachdem Sie eine Anwendung erstellt und das Anwendungsimage in ein Repository Ihres Snowflake-Kontos hochgeladen haben, können Sie Ihre Anwendungscontainer als Dienst ausführen.

Ein Dienst repräsentiert Snowflake, das Ihre containerisierte Anwendung auf einem Computepool ausführt, der eine Sammlung virtueller Maschinenknoten (VM) ist. Es gibt zwei Typen von Diensten:

  • Langlaufende Dienste. Ein langlaufender Dienst ist wie ein Webservice, der nicht automatisch endet. Nachdem Sie einen Dienst erstellt haben, verwaltet Snowflake den aktiven Dienst. Wenn z. B. ein Dienstcontainer aus irgendeinem Grund anhält, startet Snowflake diesen Container neu, damit der Dienst ohne Unterbrechung ausgeführt wird.

  • Jobdienste. Ein Jobdienst wird beendet, wenn Ihr Code beendet wird, ähnlich wie eine gespeicherte Prozedur. Wenn alle Container beendet werden, ist auch der Jobdienst beendet.

Snowpark Container Services stellt einen Satz von SQL-Befehlen zur Verfügung, mit denen Sie einen Dienst erstellen und verwalten können. Dazu zählen:

Starten von Diensten

Für das Starten eines Dienstes sind mindestens folgende Informationen erforderlich:

  • Ein Name: Name des Dienstes.

  • Eine Dienstspezifikation: Diese Spezifikation liefert Snowflake die Informationen, die zum Konfigurieren und Ausführen Ihres Dienstes erforderlich sind. Die Spezifikation ist eine YAML-Datei.

  • Ein Computepool: Snowflake führt Ihren Dienst in dem angegebenen Computepool aus.

Langlaufenden Dienst erstellen

Verwenden Sie CREATE SERVICE, um einen langlaufenden Dienst zu erstellen.

  • Erstellen Sie einen Dienst unter Verwendung einer Inline-Spezifikation. In den meisten Fällen werden Sie sich bei der Entwicklung für die Inline-Spezifikation entscheiden, wie hier gezeigt:

    CREATE SERVICE echo_service
       IN COMPUTE POOL tutorial_compute_pool
       FROM SPECIFICATION $$
       spec:
         containers:
         - name: echo
           image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:tutorial
           readinessProbe:
             port: 8000
             path: /healthcheck
         endpoints:
         - name: echoendpoint
           port: 8000
           public: true
       $$;
    
    Copy
  • Erstellen Sie einen Dienst unter Verwendung von Stagingbereichsinformationen: Wenn Sie den Dienst jedoch in einer Produktionsumgebung einsetzen, ist es ratsam, das Designprinzip von der Trennung der Zuständigkeiten („Separation of Concerns“) anzuwenden und die Spezifikation in einen Stagingbereich hochzuladen, Stagingbereichsinformationen im CREATE SERVICE-Befehl bereitzustellen, wie hier gezeigt:

    CREATE SERVICE echo_service
      IN COMPUTE POOL tutorial_compute_pool
      FROM @tutorial_stage
      SPECIFICATION_FILE='echo_spec.yaml';
    
    Copy

Jobdienst ausführen

Verwenden Sie EXECUTE JOB SERVICE, um einen Jobdienst zu erstellen. Dieser Befehl wird synchron ausgeführt und gibt eine Antwort zurück, nachdem alle Container des Jobdienstes beendet wurden.

  • Führen Sie einen Jobdienst mit einer Inline-Spezifikation aus:

    EXECUTE JOB SERVICE
       IN COMPUTE POOL tutorial_compute_pool
       NAME = example_job_service
       FROM SPECIFICATION $$
       spec:
         container:
         - name: main
           image: /tutorial_db/data_schema/tutorial_repository/my_job_image:latest
           env:
             SNOWFLAKE_WAREHOUSE: tutorial_warehouse
           args:
           - "--query=select current_time() as time,'hello'"
           - "--result_table=results"
       $$;
    
    Copy
  • Führen Sie einen Jobdienst unter Verwendung von Stagingbereich-Informationen aus:

    EXECUTE JOB SERVICE
      IN COMPUTE POOL tutorial_compute_pool
      NAME = example_job_service
      FROM @tutorial_stage
      SPECIFICATION_FILE='my_job_spec.yaml';
    
    Copy

Mehrere Dienstinstanzen erstellen und automatische Skalierung aktivieren

Standardmäßig führt Snowflake eine Instanz des Dienstes in dem angegebenen Computepool aus. Um umfangreiche Workloads zu bewältigen, können Sie mehrere Dienstinstanzen ausführen, indem Sie die Eigenschaften MIN_INSTANCES und MAX_INSTANCES spezifizieren, die die Mindestanzahl der zu startenden Instanzen des Dienstes und die maximale Anzahl der Instanzen angeben, auf die Snowflake bei Bedarf skalieren kann.

Beispiel

CREATE SERVICE echo_service
   IN COMPUTE POOL tutorial_compute_pool
   FROM @tutorial_stage
   SPECIFICATION_FILE='echo_spec.yaml'
   MIN_INSTANCES=2
   MAX_INSTANCES=4;
Copy

Wenn mehrere Dienstinstanzen ausgeführt werden, stellt Snowflake automatisch einen Load Balancer zum Verteilen der eingehenden Anforderungen bereit.

Bemerkung

Sie können nicht mehr als eine Instanz eines Jobdienstes ausführen.

Führen Sie die folgenden Schritte aus, um Snowflake für die automatische Skalierung der Anzahl der ausgeführten Dienstinstanzen zu konfigurieren:

  1. Geben Sie die CPU und die Anforderungen an Arbeitsspeicher und für Ihre Dienstinstanz an. Weitere Informationen dazu finden Sie unter Feld „container.resources“.

    Beispiel

    resources:
      requests:
       memory: <memory-reserved>
       cpu: <cpu-units>
    
    Copy
  2. Wenn Sie den Befehl CREATE SERVICE ausführen, legen Sie die Parameter MIN_INSTANCES und MAX_INSTANCES fest. Sie können auch ALTER SERVICE verwenden, um diese Werte zu ändern. Die Autoskalierung erfolgt, wenn die angegebene MAX_INSTANCES größer als MIN_INSTANCES ist.

Snowflake beginnt mit der Erstellung der Mindestanzahl von Dienstinstanzen auf dem angegebenen Computepool. Snowflake skaliert dann die Anzahl der Diensteinstanzen anhand eines Schwellenwerts von 80 % (sowohl für CPU als auch für Speicher) hoch oder runter. Snowflake überwacht kontinuierlich die Ressourcennutzung (Arbeitsspeicher oder CPU) innerhalb des Computepools und aggregiert die Nutzungsdaten aller aktuell ausgeführten Dienstinstanzen.

Wenn die aggregierte Ressourcennutzung (für alle Dienstinstanzen) 80 % übersteigt, stellt Snowflake eine zusätzliche Dienstinstanz im Computepool bereit. Wenn die aggregierte Ressourcennutzung unter 80 % fällt, skaliert Snowflake herunter, indem eine der aktiven Dienstinstanzen entfernt wird. Snowflake verwendet ein fünfminütiges Stabilisierungsfenster, um häufiges Skalieren zu verhindern.

Beachten Sie das folgende Skalierungsverhalten:

  • Die Skalierung der Dienstinstanzen wird durch die für den Dienst konfigurierten Parameter MIN_INSTANCES und MAX_INSTANCES eingeschränkt.

  • Wenn ein Hochskalieren erforderlich ist und die Knoten des Computepools nicht über die erforderliche Ressourcenkapazität verfügen, um eine weitere Dienstinstanz zu starten, kann die automatische Skalierung des Computepools ausgelöst werden. Weitere Informationen dazu finden Sie unter Automatisches Skalieren von Computepool-Knoten.

  • Wenn Sie beim Erstellen eines Services die Parameter MAX_INSTANCES und MIN_INSTANCES angeben, aber in der Dienstspezifikationsdatei Ihrer Dienstinstanz keine CPU- und Arbeitsspeicheranforderungen spezifiziert sind, erfolgt keine automatische Skalierung. Snowflake beginnt dann mit der durch den Parameter MIN_INSTANCES angegebenen Anzahl von Instanzen und führt keine automatische Skalierung durch.

Verwenden von Spezifikationsvorlagen

Es kann vorkommen, dass Sie mehrere Dienste mit der gleichen Spezifikation, aber mit unterschiedlichen Konfigurationen erstellen möchten. Nehmen Sie zum Beispiel an, dass Sie in einer Dienstspezifikation eine Umgebungsvariable definieren und Sie mehrere Services erstellen möchten, die dieselbe Spezifikation, aber unterschiedliche Werte für die Umgebungsvariable verwenden.

Spezifikationsvorlagen ermöglichen es Ihnen, Variablen für Feldwerte in der Spezifikation zu definieren. Wenn Sie einen Service erstellen, geben Sie Werte für diese Variablen an.

Die Verwendung von Spezifikationsvorlagen ist ein zweistufiger Prozess:

  1. Erstellen Sie eine Spezifikation mit Variablen als Werte für verschiedene Spezifikationsfelder. Verwenden Sie die Syntax {{ variable_name }}, um diese Variablen anzugeben. Die folgende Spezifikation verwendet zum Beispiel eine Variable namens „tag_name“ für den Namen des Image-Tags, so dass Sie für jeden Dienst ein anderes Image-Tag angeben.

    spec:
      containers:
      - name: echo
        image: myorg-myacct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:{{ tag_name }}
        ...
      endpoints:
      
    
    Copy
  2. Erstellen Sie einen Dienst, indem Sie die Spezifikationsvorlage in einem CREATE SERVICE-Befehl bereitstellen. Sie verwenden SPECIFICATION_TEMPLATE oder SPECIFICATION_TEMPLATE_FILE, um die Vorlage anzugeben. Verwenden Sie den Parameter USING, um den Wert der Variable anzugeben. Die folgende Anweisung verwendet zum Beispiel eine Spezifikationsvorlage aus einem Snowflake-Stagingbereich. Der Parameter USING setzt die Variable tag_name auf den Wert 'latest'.

    CREATE SERVICE echo_service
       IN COMPUTE POOL tutorial_compute_pool
       FROM @STAGE SPECIFICATION_TEMPLATE_FILE='echo.yaml'
       USING (tag_name=>'latest');
    
    Copy

Richtlinien für das Definieren von Variablen in einer Spezifikation

  • Verwenden Sie die Syntax {{ variable_name }}, um Variablen als Feldwerte in der Spezifikation zu definieren.

  • Diese Variablen können Standardwerte haben. Um den Standardwert festzulegen, verwenden Sie die Funktion default in der Variablendeklaration. Die folgende Spezifikation definiert zum Beispiel zwei Variablen (character_name und endpoint_name) mit Standardwerten.

    spec:
      containers:
      - name: echo
        image: <image_name>
        env:
          CHARACTER_NAME: {{ character_name | default('Bob') }}
          SERVER_PORT: 8085
      endpoints:
      - name: {{ endpoint_name | default('echo-endpoint') }}
        port: 8085
    
    Copy

    Zusätzlich können Sie einen optionalen booleschen Parameter für die Funktion default übergeben, um anzugeben, ob Sie den Standardwert verwenden möchten, wenn ein leerer Wert für die Variable übergeben wird. Betrachten Sie folgende Spezifikation:

    spec:
      containers:
      - name: echo
        image: <image_name>
        env:
          CHARACTER_NAME: {{ character_name | default('Bob', false) }}
          SERVER_PORT: 8085
      endpoints:
      - name: {{ endpoint_name | default('echo-endpoint', true) }}
        port: 8085
    
    Copy

    Erläuterungen zu dieser Spezifikation:

    • Für die Variable character_name wird der boolesche Parameter auf false gesetzt. Wenn die Variable also auf eine leere Zeichenfolge (‚‘) für diesen Parameter eingestellt wird, bleibt der Wert leer und der Standardwert („Bob“) wird nicht verwendet.

    • Für die Variable echo_endpoint wird der boolesche Parameter auf true gesetzt. Wenn Sie diesem Parameter einen leeren Wert übergeben, wird daher der Standardwert („echo-endpoint“) verwendet.

    Standardmäßig hat der boolesche Parameter für die Funktion default den Wert false.

Richtlinien für die Übergabe von Werten für Spezifikationsvariablen

Geben Sie im Befehl CREATE SERVICE den Parameter USING an, um Werte für Variablen bereitzustellen. Die allgemeine Syntax für USING lautet:

USING( var_name=>var_value, [var_name=>var_value, ... ] );
Copy

Wobei:

  • var_name unterscheidet zwischen Groß- und Kleinschreibung und sollte ein gültiger Snowflake-Bezeichner sein (siehe Anforderungen an Bezeichner).

  • var_value kann entweder ein alphanumerischer Wert oder ein gültiger JSON-Wert sein.

    Beispiele:

    -- Alphanumeric string and literal values
    USING(some_alphanumeric_var=>'blah123',
          some_int_var=>111,
          some_bool_var=>true,
          some_float_var=>-1.2)
    
    -- JSON string
    USING(some_json_var=>' "/path/file.txt" ')
    
    -- JSON map
    USING(env_values=>'{"SERVER_PORT": 8000, "CHARACTER_NAME": "Bob"}' );
    
    -- JSON list
    USING (ARGS='["-n", 2]' );
    
    Copy
  • Der Parameter USING in CREATE SERVICE muss Werte für die Spezifikationsvariablen bereitstellen (mit Ausnahme der Variablen, für die die Spezifikation Standardwerte vorsieht). In folgenden Fällen wird ein Fehler zurückgegeben:

Beispiele

Diese Beispiele zeigen das Erstellen von Diensten mithilfe von Spezifikationsvorlagen. Die CREATE SERVICE-Befehle in diesen Beispielen verwenden Inline-Spezifikationen.

Beispiel 1: Einfache Werte bereitstellen

In Tutorial 1 erstellen Sie einen Dienst, indem Sie eine Inline-Spezifikation bereitstellen. Das folgende Beispiel ist eine modifizierte Version davon, in der die Spezifikation zwei Variablen definiert: image_url und SERVER_PORT. Beachten Sie, dass die Variable SERVER_PORT an drei Stellen wiederholt wird. Dies hat den zusätzlichen Vorteil der Verwendung von Variablen, die sicherstellen, dass alle Felder, die denselben Wert haben sollen, auch denselben Wert haben.

CREATE SERVICE echo_service
   IN COMPUTE POOL tutorial_compute_pool
   MIN_INSTANCES=1
   MAX_INSTANCES=1
   FROM SPECIFICATION_TEMPLATE $$
      spec:
         containers:
         - name: echo
           image: {{ image_url }}
           env:
             SERVER_PORT: {{SERVER_PORT}}
             CHARACTER_NAME: Bob
           readinessProbe:
             port: {{SERVER_PORT}}
             path: /healthcheck
         endpoints:
         - name: echoendpoint
           port: {{SERVER_PORT}}
           public: true
         $$
      USING (image_url=>' "/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest" ', SERVER_PORT=>8000 );
Copy

In diesem CREATE SERVICE-Befehl liefert der Parameter USING Werte für die beiden Spezifikationsvariablen. Der Wert image_url enthält Schrägstriche und einen Doppelpunkt. Dies sind keine alphanumerischen Zeichen. Daher wird der Wert in dem Beispiel in doppelte Anführungszeichen gesetzt, um ihn zu einem gültigen JSON-Zeichenfolgewert zu machen. Die Spezifikation der Vorlage erweitert die folgende Spezifikation:

spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    env:
      SERVER_PORT: 8000
      CHARACTER_NAME: Bob
    readinessProbe:
      port: 8000
      path: /healthcheck
    endpoints:
    - name: echoendpoint
      port: 8000
      public: true
Copy

Beispiel 2: JSON-Wert bereitstellen

In Tutorial 1 definiert die Spezifikation zwei Umgebungsvariablen (SERVER_PORT und CHARACTER_NAME), wie gezeigt:

spec:
 containers:
 - name: echo
   image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
   env:
     SERVER_PORT: 8000
     CHARACTER_NAME: Bob
   
Copy

Sie können diese Angabe mit Hilfe einer Variable für das Feld env als Vorlage verwenden. So können Sie mehrere Dienste mit unterschiedlichen Werten für die Umgebungsvariablen erstellen. Der folgende CREATE SERVICE-Befehl verwendet eine Variable (env_values) für das Feld „env“.

CREATE SERVICE echo_service
  IN COMPUTE POOL tutorial_compute_pool
  MIN_INSTANCES=1
  MAX_INSTANCES=1
  FROM SPECIFICATION_TEMPLATE $$
     spec:
       containers:
       - name: echo
         image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
         env: {{env_values}}
         readinessProbe:
           port: {{SERVER_PORT}}    #this and next tell SF to connect to port 8000
           path: /healthcheck
       endpoints:
       - name: echoendpoint
         port: {{SERVER_PORT}}
         public: true
        $$
     USING (env_values=>'{"SERVER_PORT": 8000, "CHARACTER_NAME": "Bob"}' );
Copy

Der Parameter USING in CREATE SERVICE liefert einen Wert für die Variable env_values. Der Wert ist eine JSON-Zuordnung, die Werte für die beiden Umgebungsvariablen bereitstellt.

Beispiel 3: Liste als Variablenwert bereitstellen

In Tutorial 2 enthält die Spezifikation das Feld args, das zwei Argumente enthält.

spec:
  container:
  - name: main
    image: /tutorial_db/data_schema/tutorial_repository/my_job_image:latest
    env:
      SNOWFLAKE_WAREHOUSE: tutorial_warehouse
    args:
    - "--query=select current_time() as time,'hello'"
    - "--result_table=results"
Copy

In einer Vorlagenversion der Spezifikation können Sie diese Argumente wie gezeigt als JSON-Liste angeben:

spec:
  container:
  - name: main
    image: /tutorial_db/data_schema/tutorial_repository/my_job_image:latest
    env:
      SNOWFLAKE_WAREHOUSE: tutorial_warehouse
    args: {{ARGS}}
  $$
  USING (ARGS=$$["--query=select current_time() as time,'hello'", "--result_table=results"]$$ );
Copy

Ändern und Löschen von Diensten

Nachdem Sie einen Dienst erstellt haben:

  • Verwenden Sie den Befehl DROP SERVICE, um einen Service aus einem Schema zu entfernen (Snowflake beendet alle Dienstcontainer).

  • Verwenden Sie den Befehl ALTER SERVICE, um zum Beispiel den Service anzuhalten oder fortzusetzen, die Anzahl der aktiven Instanzen zu ändern und Snowflake anzuweisen, Ihren Service unter Verwendung einer neuen Dienstspezifikation neu bereitzustellen.

    Bemerkung

    • Sie können einen Jobdienst nicht ändern.

Beendigung des Dienstes

Wenn Sie einen Service aussetzen (ALTER SERVICE … SUSPEND) oder einen Service beenden (DROP SERVICE), beendet Snowflake alle Dienstinstanzen. Ähnlich verhält es sich, wenn Sie den Dienstcode aktualisieren (ALTER SERVICE … <fromSpecification>), wendet Snowflake fortlaufende Upgrades an, indem es jeweils eine Dienstinstanz beendet und neu bereitstellt.

Wenn eine Dienstinstanz beendet wird, sendet Snowflake zunächst ein SIGTERM-Signal an jeden Dienstcontainer. Der Container hat die Möglichkeit, das Signal zu verarbeiten und mit einem 30-Sekunden-Fenster ordnungsgemäß herunterzufahren. Andernfalls beendet Snowflake nach Ablauf des Zeitraums alle Prozesse im Container.

Aktualisieren des Dienstcodes und erneutes Bereitstellen des Dienstes

Nachdem ein Dienst erstellt wurde, verwenden Sie den Befehl ALTER SERVICE … <fromSpecification>, um den Dienstcode zu aktualisieren und den Dienst erneut bereitzustellen.

Sie laden zunächst den geänderten Anwendungscode in Ihr Image-Repository hoch und rufen dann ALTER SERVICE auf, bei Sie entweder die Dienstspezifikation inline bereitstellen oder den Pfad zu einer Spezifikationsdatei im Snowflake-Stagingbereich angeben. Beispiel:

ALTER SERVICE echo_service
FROM SPECIFICATION $$
spec:
  
  
$$;
Copy

Nach Erhalt der Anforderung stellt Snowflake den Dienst mit dem neuen Code erneut bereit.

Wenn Sie den Befehl CREATE SERVICE … <from-Specification> ausführen, zeichnet Snowflake die spezifische Version des bereitgestellten Images auf. Snowflake setzt in den folgenden Szenarien dieselbe Image-Version ein, auch wenn das Image im Repository aktualisiert wurde:

  • Wenn ein angehaltener Dienst wieder fortgesetzt wird (mit ALTER SERVICE … RESUME).

  • Wenn Autoscaling weitere Dienstinstanzen hinzufügt.

  • Wenn Dienstinstanzen während der Cluster-Wartung neu gestartet werden.

Wenn Sie jedoch ALTER SERVICE … <fromSpecification> aufrufen, wird ausgelöst, dass Snowflake die neueste Version im Repository für dieses Image verwendet.

Wenn Sie der Eigentümer des Services sind, enthält die Ausgabe des Befehls DESCRIBE SERVICE die Dienstspezifikation, die den Image-Digest (den Wert des Feldes sha256 in der Spezifikation) enthält, wie unten gezeigt:

spec:
containers:
- name: "echo"
    image: "/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest"
    sha256: "@sha256:8d912284f935ecf6c4753f42016777e09e3893eed61218b2960f782ef2b367af"
    env:
      SERVER_PORT: "8000"
      CHARACTER_NAME: "Bob"
    readinessProbe:
      port: 8000
      path: "/healthcheck"
endpoints:
- name: "echoendpoint"
    port: 8000
    public: true
Copy

ALTER SERVICE kann die Kommunikation (siehe Verwenden eines Dienstes) mit dem Dienst beeinträchtigen.

  • Wenn ALTER SERVICE … <fromSpecification> einen Endpunkt entfernt oder relevante Berechtigungen entfernt, die für die Nutzung eines Endpunkts erforderlich sind (siehe serviceRoles in Spezifikationsreferenz), schlägt der Zugriff auf den Service fehl. Weitere Informationen finden Sie unter Verwendung eines Dienstes.

  • Während des Upgrades werden neue Verbindungen möglicherweise auf die neue Version geroutet. Wenn die neue Version des Dienstes nicht abwärtskompatibel ist, wird die aktive Nutzung des Dienstes unterbrochen. Zum Beispiel können laufende Abfragen mit einer Dienstfunktion fehlschlagen.

Bemerkung

Bei der Aktualisierung von Dienstcode, der Teil einer nativen App mit Containern ist, können Sie die SYSTEM$WAIT_FOR_SERVICES-Systemfunktion verwenden, um das Skript zur Einrichtung der nativen App anzuhalten, damit die Dienste vollständig aktualisiert werden können. Weitere Informationen dazu finden Sie unter Upgrade einer App mit Containern.

Überwachung fortlaufender Upgrades

Wenn mehrere Dienstinstanzen laufen, führt Snowflake ein fortlaufendes Upgrade in absteigender Reihenfolge auf der Grundlage der ID der Dienstinstanzen durch. Verwenden Sie die folgenden Befehle, um Dienst-Upgrades zu überwachen:

  • DESCRIBE SERVICE und SHOW SERVICES:

    • Die Spalte is_upgrading in der Ausgabe zeigt unter TRUE an, ob der Dienst aktualisiert wird.

    • Die Spalte spec_digest in der Ausgabe stellt den Spec Digest der aktuellen Dienstspezifikation dar. Sie können diesen Befehl in regelmäßigen Abständen ausführen; eine Änderung des spec_digest-Wertes zeigt an, dass ein Dienst-Upgrade ausgelöst wurde. Verwenden Sie den SHOW SERVICE INSTANCES IN SERVICE-Befehl, um zu überprüfen, ob alle Instanzen auf die neueste Version aktualisiert wurden (siehe unten).

  • SHOW SERVICE INSTANCES IN SERVICE:

    • Die status-Spalte in der Ausgabe enthält den Status jeder einzelnen Dienstinstanz, während das fortlaufende Upgrade läuft. Während des Upgrades werden Sie den Status der einzelnen Dienstinstanzen beobachten, wie z. B. TERMINATING zu PENDING und PENDING zu READY.

    • Während des Dienst-Upgrades geben die Befehle SHOW SERVICE INSTANCES IN SERVICE in der Ausgabespalte spec_digest möglicherweise andere Werte zurück als SHOW SERVICES, das immer den neuesten Spec Digest zurückgibt. Es zeigt lediglich an, dass die Aktualisierung des Services läuft und die Dienstinstanzen noch die alte Version des Services ausführen.

Informationen zu Diensten abrufen

Sie können die folgenden Befehle verwenden:

  • Verwenden Sie den Befehl DESCRIBE SERVICE, um die Eigenschaften und den Status eines Dienstes abzurufen.

  • Verwenden Sie den Befehl SHOW SERVICES, um die aktuellen Dienste (einschließlich Jobdienste) aufzulisten, für die Sie Berechtigungen haben. Für jeden Dienst iefert die Ausgabe Eigenschaften und Status des Dienstes. In der Standardeinstellung listet die Ausgabe die Dienste in der aktuellen Datenbank und im aktuellen Schema auf. Sie können alternativ einen der folgenden Bereiche angeben. Beispiel:

    • Listen Sie die Dienste im Konto, in einer bestimmten Datenbank oder in einem bestimmten Schema auf: Verwenden Sie zum Beispiel den Filter IN ACCOUNT, um die Dienste in Ihrem Snowflake-Konto aufzulisten, unabhängig davon, zu welcher Datenbank oder welchem Schema die Dienste gehören. Dies ist nützlich, wenn Sie Snowflake-Dienste in mehreren Datenbanken und Schemas Ihres Kontos erstellt haben. Wie alle anderen Befehle ist auch SHOW SERVICES IN ACCOUNTS von den Berechtigungen abhängig und gibt nur die Dienste zurück, für die die von Ihnen verwendete Rolle über Anzeigeberechtigungen verfügt.

      Sie können auch IN DATABASE oder IN SCHEMA angeben, um die Dienste in der aktuellen (oder angegebenen) Datenbank oder dem Schema aufzulisten.

    • Listen Sie die Dienste auf, die in einem Computepool ausgeführt werden: Verwenden Sie zum Beispiel den Filter IN COMPUTE POOL, um die Dienste aufzulisten, die in einem Computepool ausgeführt werden.

    • Auflistung der Dienste, die mit einem Präfix beginnen oder einem Muster entsprechen: Sie können die Filter LIKE und STARTS WITH anwenden, um die Dienste nach Namen zu filtern.

    • Auflistung von Diensten oder Ausschluss von Diensten aus der Liste: Sie können SHOW JOB SERVICES oder SHOW SERVICES EXCLUDE JOBS verwenden, um nur Dienste aufzulisten oder Dienste auszuschließen.

    Sie können diese Optionen auch kombinieren, um die Ausgabe von SHOW SERVICES anzupassen.

  • Verwenden Sie den Befehl SHOW SERVICE INSTANCES IN SERVICE, um Eigenschaften der Dienstinstanzen abzurufen.

  • Verwenden Sie den SHOW SERVICE CONTAINERS IN SERVICE-Befehl, um die Eigenschaften und den Status der Dienstinstanzen abzurufen.

Überwachen von Diensten

Snowpark Container Services bietet Tools zur Überwachung der Computepools in Ihrem Konto und der darauf ausgeführten Services. Weitere Informationen dazu finden Sie unter Snowpark Container Services: Überwachen von Diensten.

Verwalten des Zugriffs auf Dienstendpunkte

Die Dienst Eigentümerrolle (die Rolle, mit der Sie den Dienst erstellen) hat vollen Zugriff auf den Dienst und die Endpunkte, die der Dienst bereitstellt. Andere Rollen benötigen die Berechtigung USAGE für die Endpunkte, um mit dem Dienst kommunizieren zu können. Beispiel:

  • Die Eigentümerrolle des Clients benötigt die Berechtigung USAGE für den Endpunkt. Client bezieht sich auf eine Dienstfunktion oder einen Dienst, der Anforderungen an Endpunkte eines anderen Dienstes stellt.

    • Um eine Dienstfunktion zu erstellen, die auf einen Endpunkt verweist, benötigt der Benutzer Zugriff auf den Endpunkt. Das heißt, die Eigentümerrolle der Dienstfunktion benötigt die Berechtigung USAGE für den Endpunkt, auf den in CREATE FUNCTION verwiesen wird.

    • Bei der Dienst-zu-Dienst-Kommunikation benötigt die Eigentümerrolle des Clientdienstes (der den Endpunkt des anderen Dienstes aufruft) die Berechtigung USAGE für den Endpunkt.

  • Ein Benutzer, der Dateneingangsanforderungen von außerhalb von Snowflake an einen öffentlichen Endpunkt sendet, benötigt die Berechtigung USAGE für den Endpunkt.

Eine Dienstrolle ist ein Mechanismus, um anderen Rollen Berechtigungen für Dienstendpunkte zu gewähren. Sie haben diese Optionen:

  • Verwenden Sie die Standardrolle für den Service: Snowflake definiert eine Standardrolle für den Service (ALL_ENDPOINTS_USAGE), die die Berechtigung USAGE allen Endpunkten des Services erteilt und diese Standardrolle der Eigentümerrolle des Services zuweist. So kann die Eigentümerrolle auf alle Endpunkte zugreifen, die der Dienst bereitstellt. Sie können diese Standardrolle für den Dienst an andere Rollen vergeben.

  • Erstellen einer Diensrolle: Anstatt mit der Standardrolle Berechtigungen für alle Endpunkte zu erteilen, können Sie eine oder mehrere Dienstrollen in der Dienstspezifikation definieren. Geben Sie in der Definition bestimmte Endpunkte an, für die die Rolle die USAGE-Berechtigung erhält. Mit den Befehlen GRANT SERVICE ROLE und REVOKE SERVICE ROLE können Sie die Dienstrolle an andere Rollen vergeben (oder widerrufen). Sie können auch die Befehle SHOW ROLES IN SERVICE, SHOW GRANTS verwenden, um Informationen über die Grants anzuzeigen.

    Snowflake erstellt die Dienstrollen, wenn Sie einen Dienst erstellen, und löscht sie, wenn Sie den Dienst löschen.

    Durch die Erstellung kundenspezifischer Dienstrollen können Sie unterschiedliche Zugriffsberechtigungen für unterschiedliche Szenarien vergeben. Sie können beispielsweise einem Endpunkt eine Berechtigung für eine Dienstrolle zur Verwendung mit einer Dienstfunktion erteilen. Sie könnten eine weitere Dienstrolle mit Berechtigung für einen öffentlichen Endpunkt erstellen, der mit einem Web UI verwendet wird.

Beachten Sie Folgendes:

  • Wenn Sie mit derselben Rolle mehrere Dienste erstellen, können diese Dienste nahtlos und ohne jegliche Konfigurationsänderungen miteinander kommunizieren, da die Eigentümerrolle Zugriff auf alle Endpunkte hat.

  • Falls ein Dienst mehrere Container hat, können diese über localhost miteinander kommunizieren. Diese Kommunikation ist innerhalb jeder Dienstinstanz lokal und unterliegt nicht der rollenbasierten Zugriffssteuerung.

Die folgenden Abschnitte enthalten weitere Details. Sie können auch ein Tutorial ausprobieren (Berechtigungen für Dienstendpunkte konfigurieren und testen), das eine schrittweise Anleitung zur Erkundung dieses Features enthält.

Gewährung der Berechtigung USAGE auf allen Endpunkten, die die Standardrolle des Dienstes verwenden

Wenn Sie einen Dienst (einschließlich eines Jobdienstes) erstellen, erstellt Snowflake auch eine Standard-Dienstrolle mit dem Namen ALL_ENDPOINTS_USAGE. Diese Rolle hat die USAGE-Berechtigung für alle Endpunkte, die der Dienst zur Verfügung stellt. Sie können anderen Rollen diese Standard-Dienstrolle mit dem Befehl GRANT SERVICE ROLE zuweisen:

GRANT SERVICE ROLE my_echo_service_image!ALL_ENDPOINTS_USAGE TO ROLE some_other_role;
Copy

Benutzer, die some_other_role verwenden, haben die USAGE-Berechtigung für alle Dienstendpunkte.

Wenn Sie einen Dienst löschen, löscht Snowflake alle mit dem Dienst verbundenen Dienstrollen (Standard-Dienstrolle und die in der Dienstspezifikation definierten Dienstrollen) und nimmt alle Dienstrolle-Zuweisungen wieder zurück.

Erteilung der Berechtigung USAGE an bestimmte Endpunkte unter Verwendung von in der Spezifikation definierten Dienstrollen

Verwenden Sie Dienstrollen, um den fein abgestuften Zugriff auf Dienstendpunkte zu verwalten. Sie definieren die Dienstrollen zusammen mit der Liste der Endpunkte, für die sie die USAGE-Berechtigung erhalten, in der Dienstspezifikation.

Das Erteilen von Berechtigungen für bestimmte Endpunkte eines Dienstes erfolgt in zwei Schritten:

  1. Dienstrolle definieren: Verwenden Sie eine Dienstspezifikation, um eine Dienstrolle zu definieren, indem Sie einen Rollennamen und eine Liste von einem oder mehreren Endpunkten angeben, für die Sie die USAGE-Berechtigung erteilen möchten. Im folgenden Spezifikationsfragment definiert beispielsweise das Top-Level-Feld serviceRoles zwei Dienstrollen, jede mit USAGE-Berechtigung für bestimmte Endpunkte.

    spec:
    ...
    serviceRoles:                 # Optional list of service roles
    - name: <svc_role_name1>
      endpoints:                  # endpoints that role can access
      - <endpoint_name1>
      - <endpoint_name2>
    - name: <svc_role_name2>
      endpoints:
      - <endpoint_name3>
      - <endpoint_name4>
    
    Copy
  2. Dienstrolle anderen Rollen zuweisen. Mit dem Befehl GRANT SERVICE ROLE weisen Sie die Dienstrolle anderen Rollen (Konto-, Anwendungs- oder Datenbankrollen) zu. Beispiel:

    GRANT SERVICE ROLE <service-name>!<svc_role_name1> TO ROLE <another-role>
    
    Copy

Verwenden eines Dienstes

Nachdem Sie einen Dienst erstellt haben, können Benutzer desselben Kontos (das den Service erstellt hat) eine der folgenden drei unterstützten Methoden verwenden, um ihn zu nutzen. Der Benutzer benötigt Zugriff auf Rollen mit den erforderlichen Berechtigungen.

  • Nutzen Sie den Service aus einer SQL Abfrage (Funktion): Sie erstellen eine Dienstfunktion, eine benutzerdefinierte Funktion (UDF) , die mit einem Service verbunden ist, und verwenden sie in einer SQL Abfrage, um mit dem Service zu kommunizieren. Ein Beispiel dazu finden Sie unter Tutorial 1.

  • Nutzen Sie den Service von außerhalb von Snowflake (Ingress): Sie können einen oder mehrere Dienstendpunkte als öffentlich deklarieren, um Netzwerk-Ingress-Zugriff auf den Service zu ermöglichen. Ein Beispiel dazu finden Sie unter Tutorial 1.

  • Dienst eines anderen Dienstes verwenden (Dienst-zu-Dienst-Kommunikation): Dienste können miteinander kommunizieren, indem sie den von Snowflake zugewiesenen DNS Dienstnamen für die Dienst-zu-Dienst-Kommunikation verwenden. Ein Beispiel finden Sie unter Tutorial 3.

Bemerkung

  • Ein Jobdienst wird wie ein Job ausgeführt, der beendet wird, wenn er fertig ist. Die Verwendung von Dienstfunktionen oder Ingress zur Kommunikation mit einem Jobdienst wird nicht unterstützt.

    • Sie können eine Dienstfunktion nicht mit einem Endpunkt eines Auftragsdienstes verknüpfen.

    • Sie können keinen Jobdienst mit einer Spezifikation erstellen, die einen öffentlichen Endpunkt definiert.

  • Die Dienst-zu-Dienst-Kommunikation mit Jobdiensten wird unterstützt. Das heißt, Services und Jobdienste können miteinander kommunizieren.

Die folgenden Abschnitte enthalten weitere Details.

Dienstfunktionen: Verwenden eines Dienstes aus einer SQL-Abfrage

Eine Dienstfunktion ist eine benutzerdefinierte Funktion (UDF), die Sie mit CREATE FUNCTION (Snowpark Container Services) erstellen. Anstatt jedoch den Code von UDF direkt zu schreiben, verknüpfen Sie die UDF mit Ihrem Dienstendpunkt. Beachten Sie, dass Sie eine Funktion nur mit einem Dienstendpunkt verknüpfen können, der das Protokoll HTTP oder HTTPS unterstützt.

In Tutorial 1 erstellen Sie beispielsweise einen Dienst namens echo_service, der einen Endpunkt (echoendoint) gemäß der Definition in der Dienstspezifikation bereitstellt:

spec:

  endpoints:
  - name: echoendpoint
    port: 8080
Copy

echoendpoint ist ein benutzerfreundlicher Endpunktname, der den entsprechenden Port (8080) darstellt. Um mit diesem Dienstendpunkt zu kommunizieren, erstellen Sie eine Dienstfunktion, indem Sie die Parameter SERVICE und ENDPOINT wie gezeigt angeben:

CREATE FUNCTION my_echo_udf (text varchar)
   RETURNS varchar
   SERVICE=echo_service
   ENDPOINT=echoendpoint
   AS '/echo';
Copy

Der Parameter AS stellt den HTTP-Pfad zum Dienstcode bereit. Sie erhalten diesen Pfad-Wert aus dem Dienstcode. Die folgenden Zeilen stammen zum Beispiel aus service.py in Tutorial 1.

@app.post("/echo")
def echo():
...
Copy

Wenn Sie die Dienstfunktion aufrufen, leitet Snowflake die Anforderung an den zugehörigen Dienstendpunkt und -pfad weiter.

Bemerkung

Eine Dienstfunktion wird zur Kommunikation mit einem Dienst, aber nicht mit einem Job verwendet. Mit anderen Worten: Sie können nur einen Dienst (keinen Job) mit einer Dienstfunktion verknüpfen.

Angabe der Batch-Größe beim Senden von Daten an einen Dienst zur Erhöhung der Parallelität

Wenn Sie mehrere Instanzen Ihres Dienstes ausführen, können Sie eine Dienstfunktion erstellen, indem Sie den optionalen Parameter MAX_BATCH_ROWS angeben, um die Batchgröße zu begrenzen, d. h. die maximale Anzahl von Zeilen, die Snowflake in einem Batch an den Dienst sendet. Angenommen, MAX_BATCH_ROWS ist 10 und Sie rufen die Dienstfunktion my_echo_udf mit 100 Eingabezeilen auf. Snowflake unterteilt die Eingabezeilen in Batches, wobei jeder Stapel höchstens 10 Zeilen enthält, und sendet eine Serie von Anforderungen an den Dienst mit dem Batch von Zeilen im Anforderungstext. Die Konfiguration der Batchgröße kann hilfreich sein, wenn die Verarbeitung eine nicht unerhebliche Zeit in Anspruch nimmt, und das Verteilen der Zeilen auf alle verfügbaren Server kann ebenfalls hilfreich sein.

Sie können ALTER FUNCTION verwenden, um eine Dienstfunktion zu ändern. Der folgende ALTER FUNCTION-Befehl ändert den Dienstendpunkt, mit dem er verknüpft ist, und die Batchgröße:

ALTER FUNCTION my_echo_udf(VARCHAR)
   SET SERVICE=other_service
   ENDPOINT=otherendpoint
   MAX_BATCH_ROWS=100
Copy

Datenaustauschformat

Für den Datenaustausch zwischen einer Dienstfunktion und einem Anwendungscontainer folgt Snowflake demselben Format, das auch externe Funktionen verwenden (siehe Datenformate). Angenommen, Sie haben Datenzeilen in einer Tabelle (input_table) gespeichert:

"Alex", "2014-01-01 16:00:00"
"Steve", "2015-01-01 16:00:00"

Um diese Daten an Ihren Dienst zu senden, rufen Sie die Dienstfunktion auf, indem Sie diese Zeilen als Parameter übergeben:

SELECT service_func(col1, col2) FROM input_table;
Copy

Snowflake sendet eine Reihe von Anforderung an den Container, wobei die Batches von Datenzeilen im Anforderungstext in diesem Format vorliegen:

{
   "data":[
      [
         0,
         "Alex",
         "2014-01-01 16:00:00"
      ],
      [
         1,
         "Steve",
         "2015-01-01 16:00:00"
      ],
      …
      [
         <row_index>,
         "<column1>",
         "<column2>"
      ],
   ]
}
Copy

Der Container gibt dann die Ausgabe in folgendem Format zurück:

{
   "data":[
      [0, "a"],
      [1, "b"],
      …
      [ row_index,  output_column1]
   ]
}
Copy

Die gezeigte Beispielausgabe geht davon aus, dass das Ergebnis eine einspaltige Tabelle mit Zeilen („a“, „b“ …) ist.

Wenn mehrere Dienstinstanzen ausgeführt werden, können Sie eine Dienstfunktion mit dem Parameter MAX_BATCH_ROWS erstellen, um die Eingabezeilen für die Verarbeitung auf alle verfügbaren Server zu verteilen. Weitere Informationen dazu finden Sie unter Angabe der Batch-Größe beim Senden von Daten an einen Dienst zur Erhöhung der Parallelität.

Erforderliche Berechtigungen zum Erstellen und Verwalten von Dienstfunktionen

Um Dienstfunktionen zu erstellen und zu verwalten, benötigt eine Rolle die folgenden Berechtigungen:

  • Erstellen einer Dienstfunktion: Die aktuelle Rolle muss die Berechtigung USAGE für den Dienst haben, auf den verwiesen wird.

  • Ändern einer Dienstfunktion: Sie können eine Dienstfunktion ändern und sie mit einem anderen Dienst verknüpfen. Die aktuelle Rolle muss die Berechtigung USAGE für den neuen Dienst haben.

  • Verwenden einer Dienstfunktion: Die aktuelle Rolle muss die USAGE-Berechtigung für die Dienstfunktion haben, und die Eigentümerrolle der Dienstfunktion muss die USAGE-Berechtigung für den zugehörigen Dienst haben.

Das folgende Beispielskript zeigt, wie Sie die Berechtigung zum Verwenden einer Dienstfunktion erteilen können:

USE ROLE service_owner;
GRANT USAGE ON service service_db.my_schema.my_service TO ROLE func_owner;

USE ROLE func_owner;
CREATE OR REPLACE test_udf(v VARCHAR)
  RETURNS VARCHAR
  SERVICE=service_db.my_schema.my_service
  ENDPOINT=endpointname1
  AS '/run';

SELECT test_udf(col1) FROM some_table;

ALTER FUNCTION test_udf(VARCHAR) SET
  SERVICE = service_db.other_schema.other_service
  ENDPOINT=anotherendpoint;

GRANT USAGE ON FUNCTION test_udf(varchar) TO ROLE func_user;
USE ROLE func_user;
SELECT my_test_udf('abcd');
Copy

Dateneingang: Verwenden eines Dienstes von außerhalb von Snowflake

Ein Dienst kann einen oder mehrere Endpunkte als öffentlich bereitstellen, damit Benutzer den Dienst über das öffentliche Web nutzen können. In diesem Fall verwaltet Snowflake die Zugriffssteuerung. Beachten Sie, dass Ingress nur mit den Endpunkten HTTP oder HTTPS erlaubt ist.

Markieren Sie den Endpunkt in Ihrer Dienstspezifikationsdatei als öffentlich:

spec
  ...
  endpoints
  - name: <endpoint name>
    port: <port number>
    public: true
Copy

Zugriff auf öffentliche Endpunkte von außerhalb von Snowflake und Authentifizierung

Nicht jeder kann auf die von einem Dienst bereitgestellten öffentlichen Endpunkte zugreifen. Nur Benutzer mit demselben Snowflake-Konto wie der Dienst und mit der Berechtigung USAGE für den öffentlichen Endpunkt können auf den öffentlichen Endpunkt zugreifen. Sie können Dienstrolle verwenden, um diese Berechtigung zu gewähren.

Diese Benutzer können über einen Browser oder programmgesteuert auf den öffentlichen Endpunkt zugreifen. Snowflake verwendet OAuth, um diese Anfragen zu authentifizieren:

  • Zugriff auf einen öffentlichen Endpunkt über einen Browser: Wenn der Benutzer einen Browser verwendet, um auf einen öffentlichen Endpunkt zuzugreifen, bietet Snowflake eine automatische Umleitung für die Benutzerauthentifizierung. Der Benutzer wird aufgefordert, sich anzumelden, und hinter den Kulissen wird durch die Benutzeranmeldung ein OAuth Token von Snowflake erzeugt. Das OAuth-Token wird dann verwendet, um eine Anforderung an den Dienstendpunkt zu senden.

  • Programmgesteuerter Zugriff auf einen öffentlichen Endpunkt: Ihre Anwendung kann die Authentifizierung des Schlüsselpaares verwenden, um Anfragen an den öffentlichen Endpunkt zu authentifizieren. In Ihrem Code generieren Sie ein JSON-Web Token (JWT) aus dem Schlüsselpaar, tauschen das JWT Token mit Snowflake gegen ein OAuth-Token aus und verwenden dann das OAuth-Token zur Authentifizierung von Anfragen an den öffentlichen Endpunkt eines Dienstes.

Tutorial 1 bietet Ihnen schrittweise Anweisungen zum Testen des Zugriffs auf öffentliche Endpunkte.

Die Authentifizierung mit einem Schlüsselpaar, wie in Tutorial 1 gezeigt, ist die empfohlene Methode zur Authentifizierung von Anfragen beim Zugriff auf öffentliche Endpunkte. Der folgende Code kann zur Authentifizierung als Alternative zur Verwendung eines Schlüsselpaars verwendet werden. Es gibt jedoch keine Garantie, dass der Code mit zukünftigen Versionen von Snowflake Connector für Python funktioniert. Dieser Python-Code verwendet den Python-Konnektor, um zunächst ein Sitzungs-Token zu erzeugen, das Ihre Identität darstellt. Der Code verwendet dann das Sitzungs-Token, um sich bei dem öffentlichen Endpunkt anzumelden.

import snowflake.connector
import requests

ctx = snowflake.connector.connect(
   user="<username>",# username
   password="<password>", # insert password here
   account="<orgname>-<acct-name>",
   session_parameters={
      'PYTHON_CONNECTOR_QUERY_RESULT_FORMAT': 'json'
   })

# Obtain a session token.
token_data = ctx._rest._token_request('ISSUE')
token_extract = token_data['data']['sessionToken']

# Create a request to the ingress endpoint with authz.
token = f'\"{token_extract}\"'
headers = {'Authorization': f'Snowflake Token={token}'}
# Set this to the ingress endpoint URL for your service
url = 'http://<ingress_url>'

# Validate the connection.
response = requests.get(f'{url}', headers=headers)
print(response.text)

# Insert your code to interact with the application here
Copy

Erläuterungen zum Code:

  • Wenn Sie Ihre Kontoinformationen nicht kennen (<Organisationsname>-<Kontoname>), lesen Sie das Tutorial Grundlegende Einrichtung.

  • Sie können den ingress_url-Wert des öffentlichen Endpunkts, der vom Dienst bereitgestellt wird, mit SHOW ENDPOINTS abrufen.

Benutzerspezifische Header bei Dateneingangsanforderungen

Wenn eine Anforderungen für einen Eingangsendpunkt eingeht, übergibt Snowflake automatisch den folgenden Header zusammen mit der HTTP-Anforderung an den Container.

Sf-Context-Current-User: <user_name>
Copy

Der Containercode kann den Header optional lesen, weiß, wer der Aufrufer ist, und kann kontextspezifische Anpassungen für verschiedene Benutzer vornehmen. Darüber hinaus kann Snowflake optional den Header Sf-Context-Current-User-Email einschließen. Um diesen Header einzufügen, wenden Sie sich an den Snowflake-Support.

Dienst-zu-Dienst-Kommunikation

Dienste können über den DNS-Namen, den Snowflake jedem Dienst automatisch zuweist, miteinander kommunizieren. Ein Beispiel dazu finden Sie unter Tutorial 3. Beachten Sie, dass, wenn ein Dienstendpunkt nur erstellt wird, um die Kommunikation zwischen Diensten zu ermöglichen, das TCP-Protokoll verwendet werden sollte.

Das DNS-Namensformat ist:

<service-name>.<schema-name>.<db-name>.snowflakecomputing.internal

Verwenden Sie SHOW SERVICES (oder DESCRIBE SERVICE), um den DNS-Namen eines Dienstes zu erhalten. Der obige DNS-Name ist ein vollständiger Name. Dienste, die im selben Schema erstellt wurden, können nur über den <service-name> kommunizieren. Dienste, die sich in derselben Datenbank, aber in unterschiedlichen Schemas befinden, müssen den Schemanamen angeben, z. B. <service-name>.<schema-name>.

Snowflake erlaubt die Netzwerkkommunikation zwischen Diensten, die von der gleichen Rolle erstellt wurden, und blockiert die Netzwerkkommunikation zwischen Diensten, die von verschiedenen Rollen erstellt wurden. Wenn Sie verhindern möchten, dass Ihre Dienste miteinander kommunizieren (z. B. aus Sicherheitsgründen), verwenden Sie verschiedene Snowflake-Rollen, um diese Dienste zu erstellen.

DNS-Namen haben die folgenden Einschränkungen:

  • Ihre Datenbank-, Schema- oder Dienstnamen müssen gültige DNS-Bezeichnungen sein. (Siehe auch https://www.ietf.org/rfc/rfc1035.html#section-2.3.1). Andernfalls wird das Erstellen eines Dienstes fehlschlagen.

  • Snowflake ersetzt einen Unterstrich (_) in den Namen (Datenbank-, Schema- und Dienstname) im DNS-Namen durch einen Bindestrich (-).

  • Ändern Sie nach dem Erstellen eines Dienstes nicht die Datenbank oder den Schemanamen, da Snowflake den DNS-Namen des Dienstes nicht aktualisiert.

  • Ein DNS-Name dient nur der internen Kommunikation innerhalb von Snowflake zwischen Diensten, die in demselben Konto ausgeführt werden. Er ist nicht über das Internet zugänglich.

Berechtigungen

Berechtigung

Verwendung

Anmerkungen

USAGE

Um mit einem Dienst zu kommunizieren, benötigen Sie die USAGE-Berechtigung für den Dienstendpunkt. Erforderlich für das Erstellen einer Dienstfunktion, die Verwendung öffentlicher Endpunkte und die Verbindung von einem anderen Dienst aus.

MONITOR

Ermöglicht das Überwachen eines Dienstes und das Abrufen des Laufzeitstatus.

OPERATE

Ermöglicht das Anhalten oder Fortsetzen einer Aufgabe.

OWNERSHIP

Ermöglicht die volle Kontrolle über den Dienst. Diese Berechtigung kann für ein bestimmtes Objekt immer nur einer Rolle erteilt sein.

ALL [ PRIVILEGES ]

Ermöglicht das Erteilen aller Berechtigungen für den Dienst, außer OWNERSHIP.