Snowpark Container Services : utilisation des tâches¶

Créer un service de longue durée¶

Utilisez CREATE SERVICE pour créer un service de longue durée.

• Dans la plupart des cas, vous créez un service en indiquant une spécification en ligne, comme illustré ci-dessous :

  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

• Créez un service en faisant référence à une spécification de service stockée dans une zone de préparation Snowflake. Lorsque vous déployez le service dans un environnement de production, vous pouvez appliquer le principe de séparation des préoccupations et charger la spécification dans une zone de préparation, en fournissant les informations de zone de préparation dans la commande CREATE SERVICE, comme indiqué :

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

  Copy

Exécuter un service de tâche¶

Utilisez EXECUTE JOB SERVICE pour créer un service de tâche. Par défaut, cette commande s’exécute de manière synchrone et renvoie une réponse après la sortie de tous les conteneurs du service de tâche. Vous pouvez éventuellement spécifier le paramètre ASYNC pour exécuter le service de tâche de manière asynchrone.

• Exécutez un service de tâche à l’aide d’une spécification en ligne :

  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

  Vous pouvez éventuellement exécuter cette tâche de manière asynchrone à l’aide de la propriété ASYNC.

  EXECUTE JOB SERVICE
     IN COMPUTE POOL tutorial_compute_pool
     NAME = example_job_service
     ASYNC = TRUE
     FROM SPECIFICATION $$
     ...
     $$;
  

  Copy

• Exécutez un service de tâche en utilisant les informations de la zone de préparation :

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

  Copy

Utilisation de modèles de spécifications¶

Il peut arriver que vous souhaitiez créer plusieurs services en utilisant la même spécification, mais avec des configurations différentes. Par exemple, vous supposez que vous définissez une variable d’environnement dans une spécification de service et vous souhaitez créer plusieurs services en utilisant la même spécification mais des valeurs différentes pour la variable d’environnement.

La spécification de modèles vous permet de définir des variables pour des valeurs de champ dans la spécification. Lorsque vous créez un service, vous fournissez des valeurs pour ces variables.

Dans un modèle de spécification, vous spécifiez des variables comme valeurs pour les différents champs de la spécification. Utilisez la syntaxe {{ variable_name }} pour spécifier ces variables. Ensuite, dans la commande CREATE SERVICE, spécifiez le paramètre USING pour définir les valeurs de ces variables.

Par exemple, le modèle de spécification en ligne de la commande CREATE SERVICE suivante utilise une variable nommée tag_name pour le nom de la balise d’image. Vous pouvez utiliser cette variable pour spécifier une balise d’image différente pour chaque service. Dans cet exemple, le paramètre USING définit la variable tag_name sur la valeur latest.

CREATE SERVICE echo_service
  IN COMPUTE POOL tutorial_compute_pool
  FROM SPECIFICATION $$
  spec:
    containers:
    - name: echo
      image: myorg-myacct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:{{ tag_name }}
        ...
    endpoints:
    - name: ...
      ...
  $$
  USING (tag_name=>'latest');

Si vous choisissez d’enregistrer le modèle de spécification dans une zone de préparation Snowflake de votre compte, vous pouvez pointer vers l’emplacement du modèle dans la commande CREATE SERVICE :

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

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

Exemples¶

Ces exemples illustrent la création de services à l’aide de modèles de spécification. Les commandes CREATE SERVICE présentées dans ces exemples utilisent la spécification en ligne.

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 );

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

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

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"}' );

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"

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"]$$ );

Activer la mise à l’échelle automatique¶

Pour configurer Snowflake afin qu’il évalue automatiquement le nombre d’instances de service en cours d’exécution, procédez comme suit :

1. Spécifiez les exigences en matière de CPU pour votre instance de service dans le fichier de spécification du service. Pour plus d’informations, voir le champ container.resources.

   Exemple

   resources:
     requests:
      cpu: <cpu-units>
   

   Copy

2. Lors de l’exécution de la commande CREATE SERVICE, définissez les paramètres MIN_INSTANCES et MAX_INSTANCES. Vous pouvez également utiliser ALTER SERVICE pour modifier ces valeurs. La mise à l’échelle automatique se produit lorsque MAX_INSTANCES est supérieur à MIN_INSTANCES.

Snowflake commence par créer le nombre minimum d’instances de service sur le pool de calcul spécifié. Snowflake augmente ou réduit ensuite le nombre d’instances de service en fonction d’un seuil d’utilisation de 80 % du CPU. Snowflake surveille en permanence l’utilisation du CPU dans le pool de calcul, en regroupant les données d’utilisation de toutes les instances de service en cours d’exécution.

Lorsque l’utilisation agrégée du CPU (pour toutes les instances de service) dépasse 80 %, Snowflake déploie une instance de service supplémentaire dans le pool de calcul. Si l’utilisation agrégée du CPU tombe en dessous de 80 %, Snowflake réduit son activité en supprimant une instance de service en cours d’exécution. Snowflake utilise une fenêtre de stabilisation de cinq minutes pour éviter les mises à l’échelle fréquentes.

Notez les comportements de mise à l’échelle suivants :

• La mise à l’échelle des instances de service est limitée par les paramètres MIN_INSTANCES et MAX_INSTANCES configurés pour le service.

• Si une mise à l’échelle est nécessaire et que les nœuds du pool de calcul n’ont pas la capacité de ressources nécessaire pour démarrer une autre instance de service, la mise à l’échelle automatique du pool de calcul peut être déclenchée. Pour plus d’informations, voir Mise à l’échelle automatique des nœuds d’un pool de calcul.

• Si vous spécifiez les paramètres MAX_INSTANCES et MIN_INSTANCES lors de la création d’un service, mais que vous ne spécifiez pas les exigences en matière de mémoire et de CPU pour votre instance de service dans le fichier de spécification du service, aucune mise à l’échelle automatique ne se produit ; Snowflake démarre avec le nombre d’instances spécifié par le paramètre MIN_INSTANCES et ne fera pas de mise à l’échelle automatique.

Suspension d’un service¶

Un service qui fonctionne depuis longtemps consomme des ressources de pool de calcul et engendre des coûts, mais vous pouvez suspendre le service lorsqu’il n’effectue pas de performances significatives. Lorsqu’aucun service ou job n’est actif sur un nœud de pool de calcul, le mécanisme de suspension automatique de Snowflake suspend le pool afin de réduire les coûts.

Pour suspendre un service, vous pouvez soit appeler explicitement ALTER SERVICE … SUSPEND pour suspendre un service, soit définir la propriété AUTO_SUSPEND_SECS en utilisant CREATE SERVICE ou ALTER SERVICE pour définir la durée d’inactivité après laquelle Snowflake suspend automatiquement le service.

Lorsque la propriété AUTO_SUSPEND_SECS est définie, Snowflake suspend automatiquement un service s’il n’est pas déjà suspendu et s’il est inactif pendant plus de AUTO_SUSPEND_SECS secondes. Un service est inactif lorsque les deux conditions suivantes sont remplies :

• Aucune requête en cours d’exécution n’inclut un appel de fonction de service à ce service.

• Le statut du service est RUNNING.

Lorsque Snowflake suspend un service, il arrête toutes les instances de service sur le pool de calcul. Si aucun autre service ne s’exécute sur le pool de calcul et si la suspension automatique est configurée pour le pool de calcul, Snowflake suspend également les nœuds du pool de calcul. Vous évitez ainsi de devoir payer pour un pool de calcul inactif.

Notez également ce qui suit :

• La suspension automatique n’est pas prise en charge pour les services de tâche.

• La suspension automatique n’est pas prise en charge sur les services avec des points de terminaison publics car Snowflake ne suit actuellement que le trafic des fonctions de service et non le trafic d’entrée pour décider quand un service est inactif.

Résiliation du service¶

Lorsque vous suspendez un service (ALTER SERVICE … SUSPEND) ou supprimez un service (DROP SERVICE), Snowflake met fin à toutes les instances de service. De même, lorsque vous mettez à niveau le code de service (ALTER SERVICE … <fromSpecification>), Snowflake applique des mises à niveau progressives en mettant fin et en redéployant une instance de service à la fois.

Lors de la fin d’une instance de service, Snowflake envoie d’abord un signal SIGTERM à chaque conteneur de service. Le conteneur a la possibilité de traiter le signal et de s’arrêter correctement avec une fenêtre de 30 secondes. Sinon, après la période de grâce, Snowflake termine tous les processus du conteneur.

Mise à jour du code de service de redéploiement du service¶

Une fois qu’un service est créé, utilisez la commande ALTER SERVICE … <fromSpecification> pour mettre à jour le code du service et redéployer le service.

Commencez par charger le code d’application modifié dans votre référentiel d’images. Exécutez ensuite la commande ALTER SERVICE, soit en fournissant la spécification de service en ligne, soit en spécifiant le chemin d’accès à un fichier de spécification dans la zone de préparation Snowflake. Par exemple :

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

Dès réception de la requête, Snowflake redéploie le service en utilisant le nouveau code.

Si vous êtes le propriétaire du service, la sortie de la commande DESCRIBE SERVICE inclut la spécification du service, qui inclut le condensé d’image (la valeur du champ sha256 dans la spécification), comme indiqué ci-dessous :

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 peut avoir un impact sur les communications (voir Utilisation d’un service) avec le service.

• Si ALTER SERVICE … <fromSpecification> supprime un point de terminaison ou supprime les autorisations pertinentes requises pour utiliser un point de terminaison (voir serviceRoles dans la référence de spécification), l’accès au service échouera. Pour plus d’informations, voir Utilisation d’un service.

• Pendant que la mise à niveau est en cours, de nouvelles connexions peuvent être acheminées vers la nouvelle version. Si la nouvelle version du service n’est pas rétrocompatible, elle perturbera toute utilisation active du service. Par exemple, les requêtes en cours utilisant une fonction de service peuvent échouer.

Privilèges nécessaires à l’exécution du service (rôle de propriétaire du service)¶

Le rôle qui crée un service est le rôle de propriétaire du service. Le service exécute toutes les SQL dans le contexte de ce rôle. Pour plus d’informations, voir Utilisation d’un jeton OAuth pour exécuter SQL.

Si un service nécessite un privilège (par exemple, pour accéder à un objet de la base de données ou pour effectuer une opération sur cet objet), le rôle de propriétaire doit se voir accorder ce privilège.

Dans la communication de service à service, le rôle du propriétaire détermine quels points de terminaison du service de destination sont accessibles (voir Rôles de service).

Privilèges nécessaires pour effectuer des opérations sur le service¶

Si un rôle doit effectuer une opération sur un service (par exemple, suspendre le service), ce rôle doit se voir accorder le privilège d’effectuer cette opération.

Chaque référence de commande SQL fournit les exigences en matière de contrôle d’accès pour les commandes. Pour plus d’informations, voir SHOW SERVICES, ALTER SERVICE, et DROP SERVICE.

Privilèges nécessaires pour accéder aux points de terminaison du service (rôles de service)¶

Un service peut exposer un ou plusieurs points de terminaison auxquels les clients accèdent en envoyant des requêtes. Le rôle de propriétaire du service a un accès complet au service et à ses points de terminaison. Pour permettre à d’autres rôles d’accéder aux points de terminaison, vous devez leur accorder les privilèges appropriés. Snowflake prend en charge la définition de « rôles de service » dans la spécification du service pour gérer l’accès aux points terminaison exposés.

Voici quelques exemples où un rôle a besoin d’un rôle de service :

• Le rôle de propriétaire d’une fonction de service nécessite un rôle de service qui accorde l’accès au point terminaison auquel la fonction de service fait référence. Sinon, vous ne pouvez pas créer la fonction de service. Si le rôle de propriétaire de la fonction de service perd son autorisation après la création de la fonction de service, les requêtes utilisant cette fonction de service échoueront avec une erreur d’autorisation.

• Dans les communications de service à service, le rôle de propriétaire du service a besoin du rôle de service qui accorde l’accès au point de terminaison d’un autre service pour appeler ce point de terminaison.

• Un utilisateur effectuant des requêtes d’entrée depuis l’extérieur de Snowflake vers un point de terminaison public exposé par un service doit se voir attribuer un rôle de service pour autoriser l’accès à ce point de terminaison.

Pour permettre à un rôle (par exemple some_role) d’accéder à un point de terminaison de service, procédez comme suit :

1. Accordez le privilège USAGE pour la base de données et le schéma où le service est créé. Ces privilèges permettent de résoudre les noms des objets du schéma. Dans ce cas, l’objet est le service.

   Par exemple, les commandes suivantes accordent les privilèges USAGE à un rôle (some_role).

   GRANT USAGE ON DATABASE my_db TO ROLE some_role;
   GRANT USAGE ON SCHEMA my_schema TO ROLE some_role;
   

   Copy

2. Accordez le rôle de service qui a l’autorisation d’accès aux points de terminaison (voir GRANT SERVICE ROLE).

   Vous avez ces options :

   • Accordez l’accès à tous les points de terminaison que le service expose à l’aide du rôle de service all_endpoints_usage, un rôle de service prédéfini que Snowflake crée pour chaque service. Le nom d’un rôle de service utilise cette syntaxe : service-name!service-role.

     GRANT SERVICE ROLE my_service!all_endpoints_usage TO ROLE some_role;
     

     Copy

   • Accordez l’accès à des points de terminaison spécifiques que le service expose. Pour ce faire, vous devez définir un ou plusieurs rôles de service dans la spécification, avec des autorisations pour des points de terminaison spécifiques. Accordez ensuite ces rôles de service pour gérer l’accès affiné au point de terminaison.

     Dans la commande CREATE SERVICE suivante, la spécification en ligne définit deux points de terminaison (ep1 et ep2) et un rôle de service (ep1_role) qui n’a accès qu’au point de terminaison ep1.

     USE DATABASE my_db;
     USE SCHEMA my_schema;
     
     
     CREATE SERVICE my_service
     IN COMPUTE POOL tutorial_pool
     FROM SPECIFICATION $$
     spec:
       containers:
       - name: echo
         image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
       endpoints:
       - name: ep1
         port: 8000
         public: true
       - name: ep2
         port: 8082
         public: true
     serviceRoles:
     - name: ep1_role
       endpoints:
       - ep1
     $$
     

     Copy

     Désormais, pour accorder à some_role l’accès au point de terminaison ep1, attribuez le rôle de service ep1_role comme indiqué :

     GRANT SERVICE ROLE my_service!ep1_role TO ROLE some_role;
     

     Copy

Fonctions de service : utilisation d’un service à partir d’une requête SQL¶

Une fonction de service est une fonction définie par l’utilisateur (UDF) que vous créez à l’aide de CREATE FUNCTION (Snowpark Container Services). Cependant, au lieu d’écrire directement le code de l’UDF, vous associez l’UDF à votre point de terminaison de service. Notez que vous ne pouvez associer une fonction de service qu’à un point de terminaison de service prenant en charge le protocole HTTP (voir Champ spec.endpoints (facultatif)).

Par exemple, dans le tutoriel 1, vous créez un service nommé echo_service qui expose un point de terminaison (echoendoint) tel que défini dans la spécification du service :

spec:
…
  endpoints:
  - name: echoendpoint
    port: 8080

echoendpoint est un nom de point de terminaison convivial qui représente le port correspondant (8080). Pour communiquer avec ce point de terminaison de service, vous créez une fonction de service en fournissant les paramètres SERVICE et ENDPOINT comme indiqué :

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

Le paramètre AS fournit le chemin HTTP vers le code de service. Vous obtenez cette valeur de chemin à partir du code du service. Par exemple, les lignes de code suivantes proviennent de service.py dans Tutoriel 1.

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

Vous appelez la fonction de service dans une instruction SELECT telle que la suivante :

SELECT service_function_name(<parameter-list>);

Snowflake dirige la requête vers le point de terminaison et le chemin du service associé.

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

SELECT service_func(col1, col2) FROM input_table;

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

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

ALTER FUNCTION my_echo_udf(VARCHAR) SET
   MAX_BATCH_ROWS = 15
   MAX_BATCH_RETRIES = 5;

USE ROLE service_owner;
GRANT USAGE ON DATABASE service_db TO ROLE func_owner;
GRANT USAGE ON SCHEMA my_schema TO ROLE func_owner;
GRANT SERVICE ROLE ON service service_db.my_schema.my_service!all_endpoints_usage 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 DATABASE service_db TO ROLE func_user;
GRANT USAGE ON SCHEMA my_schema TO ROLE func_user;
GRANT USAGE ON FUNCTION test_udf(varchar) TO ROLE func_user;
USE ROLE func_user;
SELECT my_test_udf('abcd');

Entrée : utilisation d’un service en dehors de Snowflake¶

Vous pouvez déclarer un ou plusieurs points de terminaison comme étant publics dans la spécification du service pour permettre aux utilisateurs d’utiliser le service à partir du public. Notez que les utilisateurs doivent être des utilisateurs Snowflake dans le même compte Snowflake que celui qui a créé le service.

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

Notez que l’entrée n’est autorisée qu’avec un point de terminaison HTTP (voir Champ spec.endpoints (facultatif)).

Communications de service à service¶

Les instances de service peuvent communiquer directement entre elles sur TCP (y compris HTTP). Ceci est vrai tant pour les instances qui appartiennent au même service que pour les instances qui appartiennent à des services différents.

Les instances ne peuvent recevoir de communications (requêtes) que sur les points de terminaison déclarés dans la spécification du service. Le client (le service qui envoie la requête) doit disposer des rôles et des autorisations nécessaires pour se connecter à ce point de terminaison (voir Privilèges nécessaires pour accéder aux points de terminaison du service (rôles de service)).

• Par défaut, une instance de service peut se connecter à d’autres instances du même service sur les points de terminaison déclarés. En termes plus généraux, le rôle de propriétaire d’un service a des autorisations pour se connecter aux points de terminaison des services ayant le même rôle de propriétaire.

• Pour qu’un service client puisse se connecter à un point de terminaison d’un service dont le rôle propriétaire est différent, le rôle propriétaire du service client a besoin du rôle de service qui accorde l’accès au point de terminaison d’un autre service pour appeler ce point de terminaison. Pour plus d’informations, voir Privilèges nécessaires pour accéder aux points de terminaison du service (rôles de service).

• Si vous souhaitez empêcher vos services de communiquer entre eux (pour des raisons de sécurité, par exemple), utilisez différents rôles Snowflake pour créer ces services.

Une instance de service peut être jointe en utilisant soit l’adresse IP du service, soit les adresses IP de l’instance de service.

• Les requêtes utilisant l’adresse IP du service sont routées vers un répartiteur de charge qui, à son tour, achemine les requêtes vers une instance de service sélectionnée de manière aléatoire.

• Les requêtes utilisant l’adresse IP de l’instance de service sont routées directement vers l’instance de service concernée. Vous devez utiliser l’IP de l’instance de service lorsque vous vous connectez à un point de terminaison défini à l’aide du champ portRange (voir Champ spec.endpoints (facultatif)).

Les deux adresses IP peuvent être découvertes à l’aide du nom DNS que Snowflake attribue automatiquement à chaque service. Notez qu’il n’est pas possible d’utiliser DNS pour se connecter à une instance spécifique. Par exemple, il n’est pas logique de construire une URL en utilisant le nom de l’instance de service DNS, car il n’y a aucun moyen d’utiliser le nom de l’instance de service DNS pour faire référence à une instance de service spécifique.

Les adresses IP de l’instance de service sont indiquées dans la sortie de la commande SHOW SERVICE INSTANCES IN SERVICE lorsque le bundle de changements de comportement 2025_01 est activé.

Pour un exemple de communication de service à service, voir Tutoriel 3.

Notez que si un point de terminaison de service est créé uniquement pour permettre des communications de service à service, le protocole TCP doit être utilisé (voir Champ spec.endpoints (facultatif)).

<service-name>.<hash>.svc.spcs.internal

instances.<service-name>.<hash>.svc.spcs.internal