Problembehandlung bei Snowpark Container Services¶

Fehler „invalid consent request“ (ungültige Zustimmungsanforderung) beim Zugriff auf einen öffentlichen Dienstendpunkt.

In der aktuellen Implementierung authentifiziert Snowflake den aktuellen Benutzer anhand seiner Standardrolle. Ursache des Fehler ist wahrscheinlich, dass der Benutzer eine der Rollen mit umfangreichen Berechtigung, wie ACCOUNTADMIN, SECURITYADMIN oder ORGADMIN, als Standardrolle verwendet (siehe Blockieren bestimmter Rollen für die Verwendung der Integration). Verwenden Sie den Befehl ALTER USER, um die Standardrolle für den Benutzer zu ändern, und versuchen Sie es erneut.

docker login-Authentifizierungsfehler.

Verwenden Sie im Befehl docker login keinen Hostnamen in Großbuchstaben und dann im Befehl docker push, docker pull einen Hostnamen in Kleinbuchstaben. Die Docker-CLI speichert Anmeldeinformationen exakt wie eingegeben (also unter Berücksichtigung der Groß-/Kleinschreibung). Verwandtes Docker-CLI-Problem.

docker push-Fehler: Kein Host in Anforderungs-URL.

Wenn Sie mit der Docker-CLI interagieren, müssen Sie die Unterstriche in Ihrem Kontonamen in einer URL immer durch Bindestriche ersetzten. Die Docker-CLI gibt einen Fehler zurück, wenn Hostnamen Unterstriche enthalten (auch wenn cURL funktioniert). Im folgenden Docker-Push wird zum Beispiel „my_acct“ als Kontoname angegeben:

docker push myorg-my_acct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/service_to_service

Docker gibt folgenden Fehler zurück:

Get "https:/v2/": http: no Host in request URL.

Sie können auch den Befehl SHOW IMAGE REPOSITORIES verwenden, um eine gültige Repository-URL zu erhalten.

Angehaltener Computepool steckt im Status STOPPING fest.

Das Ausführen von Diensten verhindert, dass der Computepool angehalten wird. Halten Sie alle verbliebenen aktiven Dienste im Computepool mit dem Befehl ALTER COMPUTE POOL an:

ALTER COMPUTE POOL <pool_name> STOP ALL

Ein aktiver Dienst antwortet nicht mehr auf Anforderungen (von einer Dienstfunktion oder einem öffentlichen Endpunkt). Der Status des Dienstes wurde von „Aktiv“ in „Ausstehend“ geändert.

Dies könnte ein Anzeichen für einen Ressourcenmangel auf den Computepool-Knoten sein. Wenn Ihre Container ressourcenintensiv (CPU/Arbeitsspeicher) sind, sollten Sie in der Dienst-/Jobspezifikation explizit Ressourcenanforderungen angeben, um zu verhindern, dass zu viele Dienste/Jobs auf einem einzigen Knoten platziert werden.

In der derzeitigen Implementierung können Sie nur Anforderungen hinsichtlich des Arbeitsspeichers spezifizieren.

Wenn ein Knoten im Computepool beispielsweise 64 GB RAM hat, würde die Anforderung von mehr als 32 GB für Ihren Dienst/Job garantieren, dass nur ein Dienst oder Job gleichzeitig auf einem Knoten ausgeführt werden kann. Weitere Informationen zu den Fähigkeiten der einzelnen Instanztypen finden Sie unter CREATE COMPUTE POOL.

Wenn Sie eine Anforderung an den öffentlichen Endpunkt des Dienstes übermitteln, verwenden Sie im HTTP-Authentifizierungsheader keine Anführungszeichen.

Probleme mit Timeouts und doppelter Ausführung bei Dienstfunktionen.

Wenn ein einzelner Aufruf einer Dienstfunktion länger als 30 Sekunden dauert, versucht Snowflake die Funktion erneut auszurufen, und nach einigen Wiederholungen schlägt die Funktion mit einem Timeout-Fehler fehl. Sie könnten unerwartete Ergebnisse erhalten, wenn die Funktionsimplementierung im Container nicht idempotent ist. Ziehen Sie die asynchrone Ausführung in Betracht, indem Sie einen anderen HTTP-Code (202) zurückgeben, der ein längeres Timeout erlaubt. Weitere Informationen dazu finden Sie unter Asynchroner Remotedienst.

Der Aufruf einer Dienstfunktion gibt den Fehler „service not found“ (Dienst nicht gefunden) zurück, aber der Befehl SHOW SERVICES zeigt, dass der Dienst existiert.

Prüfen Sie, ob der mit der Dienstfunktion verbundene Dienst gelöscht (DROP SERVICE) und neu erstellt (CREATE SERVICE) wurde. Wenn dies der Fall ist, müssen Sie die Dienstfunktion neu erstellen, damit sie auf den neuen Dienst verweist.