Integrationstests mit Szenarien für Container-Kompositionen (glt24)

Chaos Computer Club - recent events feed (high quality)

Hinter Web-Diensten steht häufig eine Zusammenstellung verschiedener Komponenten wie Webserver, Datenbanken oder selbst entwickelter Software. Der Vortrag zeigt wie das Backend der Videokonferenzsoftware OpenTalk in Integrationstests verschiedene Szenarien mit unterschliedlichen Container-Kompositionen implementiert. Um ein Videokonferenzsystem auf Basis der Open-Source-Software [OpenTalk](https://opentalk.eu/) zur Verfügung zu stellen, werden verschiedene Komponenten verwendet, die häufig in Containern laufen: - Die "Kernkomponente" [*OpenTalk Controller*](https://gitlab.opencode.de/opentalk/controller) (eine oder mehrere Instanzen davon) - Das [*OpenTalk Web-Frontend*](https://gitlab.opencode.de/opentalk/web-frontend) - [Janus](https://janus.conf.meetecho.com/) als WebRTC-Service - [PostgreSQL](https://www.postgresql.org/)-Datenbankservice - [RabbitMQ](https://www.rabbitmq.com/) zum Austausch von Nachrichten zwischen den Komponenten - [Redis](https://redis.io/) zur Speicherung der laufenden Videokonferenzen - OIDC-Provider, meist [Keycloak](https://www.keycloak.org/) - [*OpenTalk SMTP-Mailer*](https://gitlab.opencode.de/opentalk/smtp-mailer) zum Versand von Einladungs-Mails - [*OpenTalk Obelisk*](https://gitlab.opencode.de/opentalk/obelisk) als Dial-In-Service - [*OpenTalk Recorder*](https://gitlab.opencode.de/opentalk/recorder) zum Aufnehmen oder Streamen von Videokonferenzen Für die eigenen Komponenten waren bereits in weiten Teilen Unit-Tests vorhanden, die von der CI ausgeführt werden. Integrationstests, welche das Backend auf die korrekte Abarbeitung von Web-Requests und Websocket-Verbindungen in verschiedenen Szenarien prüfen, fehlten jedoch weitgehend. Beispiele für solche Szenarien sind: - Simples Setup mit einem *OpenTalk Controller* und den Beispiel-Accounts *Alice*, *Bob*, *Charlie*, *Dave* und *Erin* - Komplexeres Setup mit mehreren *OpenTalk Controllern* - Ausfallsszenarien (z.B. nachstellen dass *RabbitMQ* während des Betriebs ausfällt und wieder verfügbar wird) Der Vortrag skizziert, wie solch ein Integrationstest aussieht. Es wird gezeigt wie Szenarien aufgebaut sind und welche Methoden wir verwenden um den Code les- und wartbar zu halten. Ansätze die wir wieder verworfen oder ersetzt haben, werden kurz angeschnitten, und was wir daraus gelernt haben. Über Technische und organisatorische Hürden, die wir überwinden mussten oder noch überwinden müssen, wird klarerweise auch berichtet. Die gezeigten Code-Beispiele sind zum Großteil in [Rust](https://www.rust-lang.org/), da der Backend-Teil von OpenTalk in Rust geschrieben ist. Wenngleich Kenntnis dieser Sprache von Vorteil ist, sind die Beispiele in einer Form gehalten, die auch ohne spezifisches Vorwissen gut genug verständlich sein sollte. about this event: https://pretalx.linuxtage.at/glt24/talk/YQKPAS/