connect

Redpanda Connect est un processeur de flux permettant de déplacer des données entre un large éventail de sources et de destinations, avec hydratation, enrichissement, transformation et filtrage en cours de route. Les pipelines sont déclarés dans un seul fichier YAML, ce qui rend une topologie de flux facile à lire, versionner et réviser. Caractéristiques clés décrites dans le README : - Pipelines déclaratifs : toute la topologie tient dans un seul fichier YAML. - Livraison au moins une fois par défaut, à l'aide d'un modèle de transaction en cours de processus sans état persisté sur disque, ce qui, selon le projet, tient même en cas de plantages, de corruption de disque ou d'autres défaillances de serveur. - Un vaste catalogue de connecteurs couvrant les services cloud, les courtiers de messages, les bases de données et HTTP. Les exemples nommés incluent AWS (DynamoDB, Kinesis, S3, SQS, SNS), Azure (Blob, Queue, Table), GCP (Pub/Sub, Cloud Storage, BigQuery), Kafka, NATS (JetStream, Streaming), NSQ, MQTT, AMQP 0.91 (RabbitMQ), AMQP 1, Redis, Cassandra, Elasticsearch, HDFS, HTTP (serveur, client, websockets), MongoDB et SQL (MySQL, PostgreSQL, ClickHouse, MSSQL). - Des connecteurs de capture de données modifiées (CDC) de premier ordre pour Postgres, MySQL, MongoDB, Oracle et MSSQL, afin que les modifications de base de données circulent dans les pipelines sous forme d'événements. - Bloblang, un langage de mapping conçu pour les données de flux, utilisé pour la transformation et le mapping. - Exploitation adaptée au cloud : sans état et évolutif horizontalement, avec métriques et traçage intégrés. Un exemple du README diffuse les modifications Postgres vers des tables Apache Iceberg sur S3, en créant une table Iceberg par table source, et montre les options d'évolution de schéma. Les options d'installation incluent un téléchargement zip Linux, Homebrew sur macOS et une image Docker. Il s'exécute comme un binaire statique unique ou une image de conteneur, invoqué via `rpk connect run ./config.yaml` ou via Docker avec un fichier de configuration monté ou des remplacements en ligne. Observabilité : `/ping` est une sonde de vivacité qui renvoie toujours 200, et `/ready` est une sonde de disponibilité qui renvoie 200 une fois que l'entrée et la sortie sont connectées, sinon 503. Les métriques peuvent être exposées à Statsd, Prometheus, un point de terminaison HTTP JSON et d'autres backends. Les traces OpenTelemetry sont émises nativement pour une visibilité de bout en bout du pipeline. Extensibilité et développement : les API Go publiques sont documentées pour créer des plugins personnalisés, avec un dépôt de plugin d'exemple. La compilation depuis les sources nécessite une version de Go actuellement prise en charge et utilise `task build:all`. Les composants liés à des bibliothèques C externes (par exemple zmq4) sont exclus par défaut et peuvent être activés avec le tag de compilation `x_benthos_extra`. Un Dockerfile multi-étapes produit une image minimale basée sur scratch. Le projet utilise golangci-lint et gofumpt, avec les cibles `task fmt`, `task lint` et `task test` ; la plupart des tests d'intégration lancent des conteneurs Docker et sont ignorés par la tâche de test par défaut.