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:
Erstellen eines Dienstes. CREATE SERVICE, EXECUTE JOB SERVICE
Ändern eines Dienstes. ALTER SERVICE, DROP SERVICE
Informationen zu einem Dienst abrufen. SHOW SERVICES, DESCRIBE SERVICE
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 $$;
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';
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" $$;
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';
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;
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:
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>
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:
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: …
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');
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
undendpoint_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
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
Erläuterungen zu dieser Spezifikation:
Für die Variable
character_name
wird der boolesche Parameter auffalse
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 auftrue
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 Wertfalse
.
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, ... ] );
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]' );
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 );
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
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
…
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"}' );
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"
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"]$$ );
Ä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:
…
…
$$;
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
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 desspec_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;
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:
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>
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>
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
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';
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():
...
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
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;
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>"
],
]
}
Der Container gibt dann die Ausgabe in folgendem Format zurück:
{
"data":[
[0, "a"],
[1, "b"],
…
[ row_index, output_column1]
]
}
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');
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
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 hereErlä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>
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. |