Aller au contenu
use-cases / inter-container-ipc-without-the-broker / hero
PIPE · CONTENEUR-À-CONTENEUR

IPC inter-conteneurs sans le broker

Le service A redirige sa sortie vers un chemin. Le service B la récupère depuis le même chemin. Le pipe achemine les octets entre les deux conteneurs en temps réel. Pas de Redis, pas de groupe de consommateurs, pas de daemon broker à entretenir.

Lire la documentation pipe
use-cases / inter-container-ipc-without-the-broker / mechanism

Comment le pipe remplace le broker

Deux verbes HTTP et un chemin. L'une ou l'autre extrémité peut se connecter en premier ; le pipe attend jusqu'à cinq minutes la contrepartie puis fait passer les octets. Pas de file, pas d'offset, pas de groupe.

01 · POIGNÉE DE MAIN

L'une ou l'autre extrémité peut se connecter en premier

Producteur hors ligne ? Le consommateur fait GET et attend. Consommateur hors ligne ? Le producteur fait PUT et attend. Le pipe maintient la connexion jusqu'à cinq minutes jusqu'à ce que la contrepartie arrive.

02 · BACKPRESSURE

La connexion TCP est la file

Quand le consommateur est lent, le kernel ralentit le flux du producteur. Pas de profondeur de file à monitorer, pas de high-watermark à régler. Le socket est le buffer.

03 · STATELESS

Oublie les messages une fois livrés

Le compromis honnête : rien n'est persisté. Pour de la file durable, ce n'est pas la solution. Pour du fan-out conteneur-à-conteneur rapide, le broker vient de disparaître.

producer.sh · consumer.sh
# Container A — producer streams jobs to the pipe
service-a | curl -T - https://api.hoody.com/api/v1/pipe/jobs

# Container B — consumer reads from the same path
curl https://api.hoody.com/api/v1/pipe/jobs | service-b

# Either side can connect first.
# The pipe holds the connection up to 5 minutes
# until the counterpart arrives, then streams through.

PUT (ou POST) envoie. GET reçoit. Les octets n'atterrissent sur aucun disque — ils traversent le câble du producteur au consommateur, le pipe les transmet en vol.

use-cases / inter-container-ipc-without-the-broker / fanout

Ajoutez un troisième lecteur. Puis un quatrième.

Quand un logger ou un collecteur de métriques a besoin des mêmes événements, augmentez ?n et ajoutez un curl. Pas de configuration broker, pas de groupe de consommateurs, pas de secret d'auth à faire tourner. Le nouveau lecteur existe simplement.

pipe/jobs · lecteurs?n=4 · TOUT EN FAN-OUT
  • + AJOUTÉ
    consumer-aloggermetricsaudit
    curl ?n=4 — rejoint le fan-out
  • = STABLE
    producer
    service-a | curl -T - ?n=4
  • − SUPPRIMÉ
    redisconsumer-group.ymlbroker.conf
    pas de broker, pas de config

Un lecteur lent applique de la backpressure au producteur ; il ne bloque pas les autres. Jusqu'à 256 lecteurs par chemin.

use-cases / inter-container-ipc-without-the-broker / advantages

Ce que l'URL vous donne et que le broker prenait

Le broker existait parce que deux conteneurs ne pouvaient pas se parler directement. Avec le pipe, ils le peuvent. Tout ce que le broker ajoutait — auth, clients, ops — disparaît.

  • Pas de daemon à opérer

    Rien à déployer, monitorer, ou upgrader. Le pipe est la plateforme ; l'URL est la seule API.

  • Auth bearer, pas des creds broker

    Un token Hoody, scopé par projet. Pas de username, mot de passe ou fichier ACL par broker.

  • Même câble, n'importe quel langage

    Tout ce qui parle HTTP peut produire ou consommer — bash, Python, Go, un téléphone, un navigateur. Pas de bibliothèque cliente.

  • Pas d'état persisté

    Les messages vivent en vol, pas au repos. Pas de disque à remplir, pas de politique de rétention, pas de question RGPD sur les données en file.

  • La backpressure est le protocole

    TCP ralentit le producteur quand le consommateur le plus lent prend du retard. Pas de tableau de bord de lag parce qu'il n'y a pas de lag — juste un débit de flux.

  • Les conteneurs restent découplés

    Producteur et consommateur ne voient jamais leurs IPs respectives. Ils partagent une URL. Déplacez l'un ou l'autre vers un autre hôte sans recâbler.

use-cases / inter-container-ipc-without-the-broker / punchline

Le broker est l'URL. L'URL est le broker.

La couche du milieu s'effondre. Ce qui était un daemon stateful avec credentials, clients et runbook est désormais un chemin. Le diagramme d'architecture a une boîte de moins.

ÉTAIT LÀ
  • cluster redisauth, replicas, failover
  • consumer-group.ymloffsets, partitions
  • SDK broker dans chaque servicebibliothèque cliente par langage
EST LÀ
/api/v1/pipe/jobs

une URL, un curl, un verbe HTTP

Lire la documentation pipe
use-cases / inter-container-ipc-without-the-broker / replaces

Ce que cela remplace

L'infrastructure vers laquelle les équipes se tournent quand un conteneur doit passer des octets à un autre. Chacune ajoute un daemon, une config et une rotation d'astreinte. Le pipe ne facture rien de tout cela.

  • Redis pub/subDaemon, auth, clients par langage
  • RabbitMQCluster à opérer pour des octets en vol
  • NATSUn autre protocole, un autre sidecar
  • ZeroMQBibliothèque dans chaque service, pas d'URL
  • Daemons de routage personnalisésService sur mesure à maintenir en vie
  • Services streaming gRPCSchéma, codegen, surcoût TLS mutuel
  • Brokers Apache KafkaCouche de stockage pour des messages que vous ne gardez pas
use-cases / inter-container-ipc-without-the-broker / cta

Monter Redis pour que deux conteneurs se parlent ? Ou partager une URL.

Voir l'API pipe
use-cases / inter-container-ipc-without-the-broker / related

Découvrez les autres