Unité 4.3 : Intégration de diffusion d'événements

Introduction

Vous connectez le service API de TaskBoard à son worker en arrière-plan. Lorsqu'un utilisateur crée, déplace ou ferme une tâche, le API ne doit pas bloquer l'envoi d'un e-mail ou d'une webhook. Au lieu de cela, le API produit un événement task-changed pour Kafka et retourne immédiatement, tandis qu'un service worker séparé consomme ces événements et déclenche des notifications. Cela découple le chemin de la requête des effets secondaires lents et vous permet de mettre à l'échelle le worker de manière indépendante.

IONOS Event Streams for Apache Kafka exécute Apache Kafka 4.0.0, donc vos bibliothèques clientes Kafka existantes fonctionnent sans modification. Ce qui diffère d'un courtier autogéré est la connexion : le plan de données nécessite une authentification mutuelle TLS, et non SASL ou texte brut, et les adresses du courtier et les certificats proviennent du Cluster que vous avez provisionné dans l'unité 2.5. Cette unité commence par la connexion cliente, puis construit la conception de sujet, la livraison fiable, la gestion des lettres mortes et la mise à l'échelle des consommateurs, le tout par rapport au flux d'événements TaskBoard.

1. Connexion des clients avec mTLS

Le plan de données IONOS Kafka est sécurisé avec une authentification mutuelle TLS. Les deux côtés s'authentifient mutuellement : votre client vérifie le certificat du courtier contre l'autorité de certification du Cluster, et le courtier vérifie le certificat de votre client, qui est signé par l'autorité de certification du Cluster. Il n'y a pas d'écouteur en texte brut ou SASL/PLAIN. Chaque producteur et consommateur présente un certificat client.

Vous récupérez les informations d'identification, l'autorité de certification, la clé privée du client et le certificat du client, à partir du point d'accès du Cluster. Ce sont les mêmes valeurs que le Cluster expose via ses adresses de courtier et l'accès API. Chaque certificat client est valable pendant 365 jours, donc la rotation des certificats appartient à votre carnet de bord opérationnel avant la fin de l'année.

1.1 Configuration de la connexion du client

Un client Kafka auto-géré utilise security.protocol=SSL avec un truststore (pour l'autorité de certification du Cluster) et un keystore (pour le certificat du client et la clé). La documentation IONOS montre le fichier de propriétés du client canonique : le Cluster est configuré pour utiliser les certificats, et le client Kafka utilise ces certificats pour s'authentifier auprès du serveur, qui est également configuré pour utiliser les certificats Cluster.

security.protocol=SSL
ssl.truststore.type=PKCS12
ssl.truststore.location=ca-cert.p12
ssl.truststore.password=changeit
ssl.endpoint.identification.algorithm=

ssl.keystore.type=PKCS12
ssl.keystore.location=admin.p12
ssl.keystore.password=adminp12pass

Notez que ssl.endpoint.identification.algorithm est laissé vide. Parce que le Cluster utilise une autorité de certification privée plutôt que des certificats signés publiquement, la vérification du nom d'hôte contre les adresses du courtier est désactivée ici. Le truststore valide la chaîne à la place.

1.2 Connexion du producteur en Python

La bibliothèque confluent-kafka accepte les mêmes clés SSL. Pointez le client vers les adresses du courtier à partir de votre sortie Terraform et fournissez le CA, le certificat et la clé sous forme de fichiers PEM.

from confluent_kafka import Producer

# Broker addresses come from the ionoscloud_kafka_cluster Terraform output.
conf = {
    "bootstrap.servers": "192.168.1.101:9093,192.168.1.102:9093,192.168.1.103:9093",
    "security.protocol": "ssl",
    "ssl.ca.location": "ca-cert.pem",
    "ssl.certificate.location": "client-cert.pem",
    "ssl.key.location": "client-key.pem",
    "ssl.endpoint.identification.algorithm": "none",
    "client.id": "taskboard-api",
}

producer = Producer(conf)

Le Cluster exécute trois courtiers à travers la topologie Cluster, donc listez les trois dans bootstrap.servers pour la résilience de la connexion. Le client n'a besoin que d'un courtier accessible pour démarrer, mais la liste de tous les trois évite un point de défaillance unique lors du démarrage.

2. Conception de sujet et de partition

La conception de sujet est où les contraintes spécifiques à IONOS commencent à avoir un impact. Utilisez un sujet par type d'événement plutôt qu'un seul sujet de type firehose, car les consommateurs s'abonnent aux événements qui les concernent et vous pouvez définir la rétention et le partitionnement par préoccupation. Pour TaskBoard, vous créez un task-changed sujet pour le worker, et plus tard un task-changed.dlq sujet de lettres mortes.

2.1 Création de sujets via le API

L'outil de gestion Kafka API est régional et séparé du cloudapi. L'hôte suit le modèle https://kafka.<region>.ionos.com, et contrairement au plan de données, l'outil de gestion API s'authentifie avec un jeton Bearer, et non mTLS. Créez un sujet avec POST /clusters/{clusterId}/topics :

curl -X POST \
  'https://kafka.de-txl.ionos.com/clusters/e69b22a5-8fee-56b1-b6fb-4a07e4205ead/topics' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer '"$IONOS_TOKEN" \
  --data '{
    "properties": {
      "name": "task-changed",
      "replicationFactor": 3,
      "numberOfPartitions": 6,
      "logRetention": { "retentionTime": 604800000 }
    }
  }'

Les paramètres du corps sont name (le seul champ obligatoire), replicationFactor, numberOfPartitions, et les paramètres logRetention. Lisez les sujets avec GET /clusters/{clusterId}/topics et GET /clusters/{clusterId}/topics/{topicId}, qui retournent name, replicationFactor, numberOfPartitions, et logRetention. La suppression est DELETE /clusters/{clusterId}/topics/{topicId} et retourne 202 Accepted, puisque la suppression est asynchrone.

2.2 Nombre de partitions et contraintes de réplication

Choisissez le nombre de partitions comme un multiple de 3 (3, 6, 9, 12, etc.) pour éviter une répartition inégale des partitions sur les trois courtiers. Un nombre de partitions qui n'est pas un multiple du nombre de courtiers laisse un courtier transporter plus de partitions que les autres, ce qui fausse la charge.

Le facteur de réplication recommandé est 3, correspondant à la topologie à trois courtiers, mais il s'agit d'une recommandation IONOS, et non d'une valeur par défaut imposée par le système ; vous devez définir replicationFactor explicitement lors de la création d'un sujet. Avec un facteur de réplication 3, le Cluster conserve trois copies de chaque message, de sorte que le sujet survive à la perte d'un courtier sans perte de données. La rétention de sujet par défaut est de 604800000 ms (7 jours). La définition de retentionTime sur -1 n'applique aucune limite de temps, dans ce cas, la rétention est limitée uniquement par le stockage Cluster que vous avez provisionné (par exemple 750 Go sur la taille S, 1200 Go sur la taille M).

Le tableau suivant mappe les paramètres du corps du sujet à leur rôle lorsque vous concevez un sujet.

Les partitions sont importantes au-delà du stockage. Le nombre de partitions est le plafond dur pour le parallélisme des consommateurs dans un groupe de consommateurs, donc dimensionnez-le pour le débit maximal actuel, puisque l'augmentation des partitions plus tard modifie la mise en correspondance clé-partition et perturbe les garanties d'ordre.

3. Fiabilité du producteur

Un producteur fire-and-forget abandonne les messages en cas de perturbation du courtier. Pour les événements de tâche de TaskBoard, où la perte d'un événement signifie une notification manquée, configurez le producteur pour la durabilité avant d'optimiser le débit.

3.1 Acks, idempotence et clés

Définissez acks=all pour que le producteur attende que tous les réplicas synchronisés confirment une écriture avant de la considérer comme réussie. Combiné avec un facteur de réplication 3, cela signifie qu'un message est durable à travers les courtiers avant que votre code ne passe à l'étape suivante. Activez le producteur idempotent pour que les réessais ne créent pas de doublons du côté du courtier.

from confluent_kafka import Producer
import json

conf = {
    "bootstrap.servers": "192.168.1.101:9093,192.168.1.102:9093,192.168.1.103:9093",
    "security.protocol": "ssl",
    "ssl.ca.location": "ca-cert.pem",
    "ssl.certificate.location": "client-cert.pem",
    "ssl.key.location": "client-key.pem",
    "ssl.endpoint.identification.algorithm": "none",
    "acks": "all",
    "enable.idempotence": True,
    "retries": 5,
    "linger.ms": 20,
    "batch.size": 65536,
}
producer = Producer(conf)

def on_delivery(err, msg):
    if err:
        # Persist for replay; never silently drop.
        print(f"delivery failed: {err}")
    else:
        print(f"delivered to {msg.topic()} [{msg.partition()}] @ {msg.offset()}")

def emit_task_changed(task_id: str, event: dict):
    producer.produce(
        topic="task-changed",
        key=task_id.encode("utf-8"),   # same task -> same partition -> ordered
        value=json.dumps(event).encode("utf-8"),
        on_delivery=on_delivery,
    )
    producer.poll(0)

Clés par task_id routent tous les événements d'une tâche vers la même partition, ce qui préserve l'ordre par tâche. Sans clé, Kafka distribue les enregistrements de manière round-robin et un événement "tâche fermée" pourrait être traité avant "tâche créée".

3.2 Traitement par lots et vidange

linger.ms et batch.size échangent quelques millisecondes de latence pour un débit beaucoup plus élevé en traitant les enregistrements par partition. Il est toujours nécessaire de flush() avant la sortie du processus, sinon les enregistrements tamponnés sont perdus.

# At shutdown, block until all buffered messages are delivered or fail.
remaining = producer.flush(timeout=10)
if remaining > 0:
    raise RuntimeError(f"{remaining} messages not delivered before shutdown")

4. Groupes de consommateurs, décalages et sémantique de livraison

Le worker TaskBoard lit task-changed en tant que groupe de consommateurs. Chaque consommateur du même groupe partage les partitions, donc l'ajout d'un worker Pods met à l'échelle le débit jusqu'au nombre de partitions. Un quatrième consommateur sur un sujet à 3 partitions reste inactif.

4.1 Au moins une fois avec des validations manuelles

Pour la livraison de notifications, au moins une fois est la valeur par défaut appropriée : traiter le message, puis valider le décalage. Si le worker plante après le traitement mais avant la validation, le message est relivré et la notification peut se déclencher deux fois, ce que vous pouvez sécuriser avec une clé d'idempotence. Le contraire, valider avant de traiter (au plus une fois), risque de perdre des événements en cas de plantage.

from confluent_kafka import Consumer, KafkaException
import json

conf = {
    "bootstrap.servers": "192.168.1.101:9093,192.168.1.102:9093,192.168.1.103:9093",
    "security.protocol": "ssl",
    "ssl.ca.location": "ca-cert.pem",
    "ssl.certificate.location": "client-cert.pem",
    "ssl.key.location": "client-key.pem",
    "ssl.endpoint.identification.algorithm": "none",
    "group.id": "taskboard-notifier",
    "enable.auto.commit": False,        # manual commit = control over semantics
    "auto.offset.reset": "earliest",
}
consumer = Consumer(conf)
consumer.subscribe(["task-changed"])

while True:
    msg = consumer.poll(1.0)
    if msg is None:
        continue
    if msg.error():
        raise KafkaException(msg.error())
    event = json.loads(msg.value())
    send_notification(event)            # do the work first
    consumer.commit(msg)                # then commit only this offset

enable.auto.commit=False est le choix clé. L'auto-validation avance les offsets sur une minuterie, quelle que soit la réussite du traitement, ce qui supprime silencieusement les messages dont le traitement a échoué.

4.2 Mise à l'échelle et rééquilibrage du consommateur

Le nombre de partitions est le plafond de parallélisme. Pour mettre à l'échelle le worker TaskBoard sur Managed Kubernetes (voir Unité 3.2), augmentez le nombre de répliques de déploiement jusqu'au nombre de partitions, et chaque nouveau pod rejoint le groupe taskboard-notifier et se voit attribuer un sous-ensemble de partitions via un rééquilibrage. Lors d'un rééquilibrage, les partitions cessent brièvement d'être consommées, donc gardez le traitement idempotent et les validations fréquentes pour minimiser le retraitement.

Dimensionnez les partitions en fonction de votre nombre maximal de consommateurs dès le départ. Vous pouvez ajouter des partitions plus tard, mais cela réorganise la mise en correspondance des clés avec les partitions et rompt l'ordre des clés en vol.

5. Gestion des lettres mortes et discipline de schéma

Non tous les messages peuvent être traités. Une charge utile malformée ou une panne en aval entraînera des échecs répétitifs lors de la réexpédition, et un message poison que vous réessayez indéfiniment bloque toute la partition.

5.1 Modèle de sujet de lettres mortes

Routez les messages qui épuisent leurs réessais vers un sujet de lettres mortes dédié, task-changed.dlq, puis validez l'offset d'origine afin que la partition principale continue à fonctionner. Vous inspectez la DLQ plus tard, corrigez la cause et répondez éventuellement.

from confluent_kafka import Producer, Consumer
import json

dlq = Producer(conf_producer)  # same mTLS settings as the main producer

def process_with_dlq(consumer, msg, max_attempts=3):
    attempts = int(dict(msg.headers() or {}).get("x-attempts", b"0") or 0)
    try:
        send_notification(json.loads(msg.value()))
        consumer.commit(msg)
    except Exception as exc:
        if attempts + 1 >= max_attempts:
            dlq.produce(
                "task-changed.dlq",
                key=msg.key(),
                value=msg.value(),
                headers={"x-error": str(exc), "x-attempts": str(attempts + 1)},
            )
            dlq.flush(5)
            consumer.commit(msg)        # advance past the poison message
        else:
            raise                        # let it redeliver for a transient error

Faites la distinction entre les échecs transitoires (une temporisation du service de notification, qui mérite une réessai) et les échecs permanents (un événement malformé, qui va directement à la DLQ). Le réessai aveugle des échecs permanents bloque la partition ; le renvoi aveugle des échecs transitoires entraîne la perte d'événements récupérables.

5.2 Contrats d'événements avec JSON Schéma

Les producteurs et les consommateurs sont déployés de manière indépendante, donc la charge utile de l'événement est un contrat entre eux. Définissez-le avec JSON Schéma et validez-le des deux côtés. Faites évoluer le schéma de manière additive : ajoutez des champs facultatifs, ne supprimez ni ne renommez les champs existants, afin que les anciens consommateurs continuent à fonctionner tandis que les nouveaux producteurs sont expédiés.

import jsonschema

TASK_CHANGED_V1 = {
    "type": "object",
    "required": ["task_id", "action", "occurred_at"],
    "properties": {
        "task_id": {"type": "string"},
        "action": {"enum": ["created", "moved", "closed"]},
        "occurred_at": {"type": "string", "format": "date-time"},
        "assignee": {"type": "string"},   # added in v1.1, optional = safe
    },
    "additionalProperties": False,
}

def validate_event(event: dict):
    jsonschema.validate(event, TASK_CHANGED_V1)  # raises ValidationError on breach

Transportez une version de schéma dans l'événement ou un en-tête afin que les consommateurs puissent se brancher dessus pendant une fenêtre de migration. Cette discipline est ce qui vous permet de modifier la forme de l'événement TaskBoard sans un redéploiement coordonné et synchronisé du producteur et du travailleur.

API Référence Carte Rapide

Points de terminaison clés pour la gestion API de Kafka. L'hôte est régional, par exemple https://kafka.de-txl.ionos.com :

Authentification de gestion API : Authorization: Bearer <token> Authentification du plan de données (producteurs/consommateurs) : authentification mutuelle TLS avec certificat client

Code Lab

Objectif : Produire et consommer les événements TaskBoard task-changed sur un IONOS Kafka Cluster avec un groupe de consommateurs, des validations d'offset manuelles, et un routage de lettres mortes en cas d'échec.

Prérequis :

• Compte IONOS Cloud avec jeton API (IONOS_TOKEN)
• Un Kafka Cluster provisionné à partir de l'unité 2.5 avec des adresses de courtier disponibles
• Python 3.10+ avec confluent-kafka et jsonschema installés
• Le CA Cluster, le certificat client et la clé client enregistrés sous forme de fichiers PEM

Étape 1 : Récupérer les adresses de courtier et les informations d'accès

CLUSTER_ID="e69b22a5-8fee-56b1-b6fb-4a07e4205ead"
curl -s -X GET \
  "https://kafka.de-txl.ionos.com/clusters/$CLUSTER_ID" \
  -H "Authorization: Bearer $IONOS_TOKEN" | python3 -m json.tool

Le texte à traduire est vide, veuillez fournir le texte à traduire.

{
  "id": "e69b22a5-8fee-56b1-b6fb-4a07e4205ead",
  "properties": { "name": "...", "version": "4.0.0", "size": "S",
    "connections": [ { "brokerAddresses": ["192.168.1.101/24", ...] } ] }
}

Étape 2 : Créer les rubriques principales et de lettres mortes

for T in task-changed task-changed.dlq; do
  curl -s -X POST "https://kafka.de-txl.ionos.com/clusters/$CLUSTER_ID/topics" \
    -H "Content-Type: application/json" -H "Authorization: Bearer $IONOS_TOKEN" \
    --data "{\"properties\":{\"name\":\"$T\",\"replicationFactor\":3,\"numberOfPartitions\":6}}"
done

Le texte à traduire est vide, veuillez fournir le texte à traduire.

{"id":"ae085c4c-...","type":"topic","properties":{"name":"task-changed",
 "replicationFactor":3,"numberOfPartitions":6}}

Étape 3 : Produire un événement de changement de tâche

producer.produce("task-changed", key=b"task-42",
    value=b'{"task_id":"task-42","action":"created","occurred_at":"2026-06-05T10:00:00Z"}')
producer.flush(10)
print("produced")

Le texte à traduire est vide, veuillez fournir le texte à traduire pour que je puisse vous donner la traduction en français.

delivered to task-changed [3] @ 0
produced

Étape 4 : Consommer avec un groupe de consommateurs et un commit manuel

consumer.subscribe(["task-changed"])
msg = consumer.poll(5.0)
print(msg.topic(), msg.partition(), msg.offset(), msg.value())
consumer.commit(msg)

Le texte à traduire est vide, veuillez fournir le texte à traduire.

task-changed 3 0 b'{"task_id":"task-42",...}'

Étape 5 : Déclencher une lettre morte sur une charge utile incorrecte

producer.produce("task-changed", key=b"task-99", value=b'{not valid json')
producer.flush(10)
# Consumer's process_with_dlq routes it to task-changed.dlq after max_attempts

Le texte à traduire est vide, veuillez fournir le texte à traduire.

delivered to task-changed.dlq [1] @ 0

Étape 6 : Vérifier que le sujet de lettres mortes a reçu le message

dlq_consumer.subscribe(["task-changed.dlq"])
m = dlq_consumer.poll(5.0)
print(dict(m.headers()), m.value())

Le texte à traduire est vide, veuillez fournir le texte à traduire.

{'x-error': b'...', 'x-attempts': b'3'} b'{not valid json'

Liste de validation :

• [ ] task-changed et task-changed.dlq sujets créés avec un facteur de réplication 3
• [ ] Le producteur livre avec acks=all et l'idempotence activée
• [ ] Le consommateur valide les décalages manuellement après traitement
• [ ] Un message mal formé atterrit dans le sujet de lettres mortes, et non dans une boucle de réessai infinie

Nettoyage :

for ID in $(curl -s "https://kafka.de-txl.ionos.com/clusters/$CLUSTER_ID/topics" \
  -H "Authorization: Bearer $IONOS_TOKEN" | python3 -c \
  "import sys,json;[print(t['id']) for t in json.load(sys.stdin)['items']]"); do
  curl -s -X DELETE "https://kafka.de-txl.ionos.com/clusters/$CLUSTER_ID/topics/$ID" \
    -H "Authorization: Bearer $IONOS_TOKEN"
done

Pièges courants

1. Utilisation de SASL ou de texte brut au lieu de mTLS

   • Problème : Le client se bloque lors de la connexion ou échoue avec SSL handshake failed, même si les informations d'identification semblent correctes.
   • Pourquoi cela se produit-il : Le plan de données IONOS n'accepte que la mutualisation TLS. Il n'y a pas d'écouteur SASL/PLAIN ou de texte brut, et les courtiers utilisent une autorité de certification privée, donc un magasin de confiance par défaut les rejette.
   • Correction : Définissez security.protocol=ssl, fournissez le Cluster CA en tant que ssl.ca.location, le certificat client et la clé, et désactivez la vérification du nom d'hôte avec ssl.endpoint.identification.algorithm=none.

2. Auto-commit renvoyant silencieusement les messages échoués

   • Problème : Certaines notifications de tâche ne se déclenchent jamais, mais aucune erreur n'apparaît dans les journaux et le retard du consommateur est nul.
   • Pourquoi cela se produit-il : Avec enable.auto.commit=True, les décalages avancent sur une minuterie, quel que soit le succès de send_notification, donc un message qui a provoqué une exception est marqué comme consommé.
   • Correction : Définissez enable.auto.commit=False et appelez consumer.commit(msg) uniquement après le succès du traitement, en routant les échecs permanents vers le sujet de la lettre morte.

3. Nombre de partitions non multiple du nombre de courtiers

   • Problème : Un courtier affiche une charge CPU et une charge disque plus élevée que les deux autres, et le débit atteint un plateau en dessous des attentes.
   • Pourquoi cela se produit-il : Avec 3 courtiers, un sujet créé avec 4 ou 5 partitions se distribue de manière inégale, donc un courtier héberge un leader de partition supplémentaire.
   • Correction : Créez des sujets avec un nombre de partitions qui est un multiple de 3 (3, 6, 9, 12) afin que les partitions soient réparties uniformément sur les trois courtiers.

Résumé

Vous pouvez maintenant intégrer IONOS Event Streams for Apache Kafka dans le code d'application comme une partie de première classe de l'architecture TaskBoard. Vous connectez les producteurs et les consommateurs sur des TLS mutuels en utilisant des adresses de courtiers et des certificats de votre Cluster provisionné, créez des rubriques à travers la gestion régionale API avec une authentification Bearer, et concevez des paramètres de partition et de réplication qui respectent la topologie à trois courtiers. En outre, vous disposez d'un producteur fiable avec une idempotence et acks=all, d'un groupe de consommateurs avec des validations manuelles au moins une fois, d'une rubrique de lettres mortes pour les messages poisonnés, et de contrats de schéma JSON qui permettent au producteur et au consommateur d'évoluer de manière indépendante.

Points clés :

• Le plan de données Kafka nécessite des TLS mutuels avec un certificat client ; la gestion API utilise des jetons Bearer. Ce sont deux modèles d'authentification différents sur deux points de terminaison différents.
• Les comptes de partition de rubrique doivent être des multiples de 3 pour être répartis uniformément sur les trois courtiers ; le facteur de réplication recommandé est 3, mais vous devez le définir explicitement puisqu'il ne s'agit pas d'une valeur par défaut imposée par le système.
• La livraison au moins une fois provient de la désactivation de l'auto-validation et de la validation des décalages uniquement après un traitement réussi ; rendez le traitement idempotent pour tolérer la réexpédition.
• Le nombre de partitions est le plafond dur de la parallélisme du consommateur ; dimensionnez les partitions pour la charge de pointe avant de déployer, car l'ajout de partitions plus tard perturbe l'ordre des clés.
• Les rubriques de lettres mortes isolent les messages poisonnés afin qu'une charge utile incorrecte ne bloque pas sa partition, et le schéma JSON impose le contrat producteur-consommateur.

Terminologie importante :

• mTLS (TLS mutuel) : Le client et le courtier s'authentifient mutuellement avec des certificats ; la seule méthode d'authentification du plan de données IONOS, avec des certificats clients valides pendant 365 jours.
• Groupe de consommateurs : Un ensemble de consommateurs partageant le travail des partitions d'une rubrique, l'unité de mise à l'échelle horizontale pour le worker TaskBoard.
• Validation des décalages : Enregistrer la position à laquelle un consommateur a traité ; valider après le traitement donne une livraison au moins une fois.
• Rubrique de lettres mortes (DLQ) : Une rubrique distincte pour les messages qui échouent au traitement après des réessais, gardant la partition principale débloquée.
• Facteur de réplication : Le nombre de copies de chaque partition sur les courtiers ; 3 sur IONOS, correspondant à la topologie à trois courtiers Cluster, afin que la rubrique survive à une perte de courtier. Vous pouvez utiliser TLS, API, et JSON pour améliorer la haute disponibilité et la fiabilité de vos applications. Les produits Kafka et Cluster sont essentiels pour la mise en œuvre d'une architecture robuste et évolutivité. Enfin, n'oubliez pas d'utiliser Event Streams for Apache Kafka, TLS, et Cluster pour garantir la sécurité et la conformité de vos données.

Prochaines étapes

Continuer l'apprentissage : Unité 4.4 : AI Model Hub Intégration

Sujets connexes :

• Unité 2.5 : Provisionnement de bases de données et de services de diffusion
• Unité 3.2 : Kubernetes Déploiement et opérations