Wie baut man gute debug-setups über mehrere Repos mit vielen Komponenten?

[NJay]

Hallo,

ich habe aktuell ein recht kompliziertes Problem vor mir und aktuell keine Lösung. Arbeite an der Uni und da ist man als Junior oft faktisch der Senior, kann also niemanden Fragen, der mehr Ahnung hat als ich.

Wir haben hier mehrere Anwendungen, die wir selbst entwickeln. Diese Anwendungen sind in mehreren Git Repos verteilt (in einer GitLab-Instanz). Teilweise konnten stark voneinander abhängige Komponenten in Monorepos zusammen legen, doch alles in ein Repo ist (aktuell) leider nicht möglich, da gewisse Projektpartner manche Komponenten aktuell noch "geheim" halten wollen, wir den rest aber Open-Source haben möchten.

Um das ganze zu betreiben startet man nun also Komponente A, B, C und Komponente D. Komponente D kann nun aber 2 bis N mal gestartet werden, in beliebigen Topologien. Es handelt sich hier um ein Netzwerk aus Komponente D. Für jede Verbindung von zwei Komponenten D benötigt man nun je mindestens zweimal Komponente E. Es werden also ziemlich viele parallel laufende Komponenten. Zum laufen lassen in eienr lokalen Umgebung dank docker absolut kein Problem.

Jetzt haben wir natürlich hin und wieder mal Bugs drinnen. Bisher wurde vor allem mit log-debugging gearbeitet, aber das stößt natürlich langsam an seine Grenzen.

Doch wie baut man jetzt ein gutes debug-setup? Im klassischen Monorepo und einer kleinen Webanwendung ist das kein Problem. Alles im selben Repo, jeder Code wird genau einmal parallel aufgerufen.

Ich habe schon etwas gebastelt und es würde erstmal reichen, die skalierbare Komponente D genau zweimal zu haben. Außerdem kann man andere Komponenten einfach ohne debugger in Docker laufen lassen, da sie sehr stabil sind und nahezu nie für Probleme sorgen. Aber es gibt eben mindestens zwei Komponenten, die im debugger laufen sollten.

Weiteres Problem: Das Setup sollte Robust und einfach bedienbar sein. Ich hatte (als das setup noch kleiner war) schon zweimal Debug-Setups gebaut, aber durch Configdrift und schnelle Entwicklung war es so schnell veraltet, da das Setup zu selten genutzt wurde. Außerdem sollte es nicht zu kompliziert sein, wenn man erst 5 Seiten Doku durchlesen muss will es wieder keiner nutzen (außer er muss) und es passiert das selbe.

Meine bisher beste Idee wäre es, Tracing z.B. mit OpenTelemitry einzubauen um unsere soliden Logausgaben zu Bundeln und immerhin den Flow in den Anwendungen nachvollziehbar zu machen. Ist kein debugger, aber besser als nichts, skaliert und wäre auch für deployments (die wir aktuell noch nicht haben) auch gut.

Hat jemand Ideen? Es geht mir nicht um ganz genaue Tips, aber Schlagwörter zum recherchieren oder Links zu guten Blogartikeln wären gut.

Tech-Stack und Setup zusammengefasst:

• Golang
• gRPC
• Viele docker-container
• Mehrere parallele Repos

Vielen Dank!

 

[aluis]

Ich würde die CI/CD-Pipeline viel weiter ausbauen, einen zentrales Logging aufbauen, evt. ein Buildserver, und nochmal das ganze genau evaluieren, ob Microservices wirklich der perfekte Ansatz ist.

Wenn du schon GitLab hast, dann setze darauf und bau es weiter aus.

 

[dasBaum_CH]

Puh das kann endlose Diskussionen geben. Was ich bisher gesehen hab: Komponenten wie logging, debugger, etc. als "base" in den repos/projekten verlinken. Also sicherstellen das die Grundlegendenkomponenten bei allen diesselben sind.
Zudem wurde https://mirrord.dev/ verwendet um die Applikation im Container zu debuggen.

Als DevOps war ich mehr im Infrastruktur Bereich als im Dev unterwegs. Hoffe du kannst was damit anfangen.

 

[NJay]

Ich würde die CI/CD-Pipeline viel weiter ausbauen, einen zentrales Logging aufbauen, evt. ein Buildserver,

Wir haben CI/CD-Pipelines, die den Code bauen, testen (Unit und Integrationtests) und so weiter. Aber das hat ja mit lokalem debuggen nichts zu tun. Es geht explizit darum lokal den Code debuggen zu können.

So haben wir ein neues Feature eingebaut und nun failen manchmal die Integrationtests. Wenn man es lokal ausprobiert tritt der Fehelr oft auf, wenn man zwei gewisse API calls hintereinander macht. Nun soll als nächster Schritt der debugger angeworfen werden um das Problem eben zu finden und zu beheben.

und nochmal das ganze genau evaluieren, ob Microservices wirklich der perfekte Ansatz ist.

Wir haben keine Microservices. Es handelt sich um Software, die auf vielen dedizierten Geräten laufen wird, welche aber miteinander reden müssen.

Puh das kann endlose Diskussionen geben. Was ich bisher gesehen hab: Komponenten wie logging, debugger, etc. als "base" in den repos/projekten verlinken. Also sicherstellen das die Grundlegendenkomponenten bei allen diesselben sind.

Das ist nicht das problem, alle nutzen schon halbwegs standardisierte Tools. Es geht aber darum wie man mit den Tools ein gutes Debugsetup baut.

Zudem wurde https://mirrord.dev/ verwendet um die Applikation im Container zu debuggen.

Danke schaue ich mir mal an. Wir müssen zwar nicht zwangsläufig in containern debuggen, eventuell hilft es aber trotzdem.

 

[dasBaum_CH]

Achso... ja dann würd ich doch mal schauen ob es einen passenden Debugger für Go gibt und ob der in deiner IDE konfigurieren lässt. Zum Teil kann man ja diverse Settings der IDE ins Repo reinnehmen so das jeder die gleichen Settings verwendet.

Ohne gross ne Ahnung von Go zu haben, aber da gibts Plugins für Debugger um Breakpoints zu erstellen, vielleicht hilft es? https://github.com/golang/vscode-go/wiki/debugging#features

 

[NJay]

Achso... ja dann würd ich doch mal schauen ob es einen passenden Debugger für Go gibt und ob der in deiner IDE konfigurieren lässt. Zum Teil kann man ja diverse Settings der IDE ins Repo reinnehmen so das jeder die gleichen Settings verwendet.

Sorry, aber du solltest meinen Post nochmal lesen. Ich weiß, wie man go debuggt und habe auch schon viele Setups erstellt, auch welche wo vorher Scripts ausführen, etc.

Ich bekomme es auch hin ein Setup für uns zu bauen. Aber das ganze wird schnell unübersichtlich und kompliziert. Um mich selbst zu zitieren:

Weiteres Problem: Das Setup sollte Robust und einfach bedienbar sein. Ich hatte (als das setup noch kleiner war) schon zweimal Debug-Setups gebaut, aber durch Configdrift und schnelle Entwicklung war es so schnell veraltet, da das Setup zu selten genutzt wurde. Außerdem sollte es nicht zu kompliziert sein, wenn man erst 5 Seiten Doku durchlesen muss will es wieder keiner nutzen (außer er muss) und es passiert das selbe.

Mir geht es um Pattern und Tools um Debug-Setups für große verteilte Systeme zu entwickeln die gleichzeitig gut wartbar sind, aber für alle anderen auch einfach nutzbar. Bringt ja nichts, wen ich gut debuggen kann, alle anderen aber erst zwei 90 minütige Schulungen bei mir brauchen.

 

[BeBur]

ich habe aktuell ein recht kompliziertes Problem vor mir und aktuell keine Lösung. Arbeite an der Uni und da ist man als Junior oft faktisch der Senior, kann also niemanden Fragen, der mehr Ahnung hat als ich.

Nur zur Allgemeinen Einordnung: Meiner Wahrnehmung nach gibt es sehr oft gar nicht die eine best practice, die der Senior kennt aber der Junior nicht und die dir den ganzen Ärger erspart. Sieht man auch gut an diversen Trends (Microservice, Anti-Monorepo, ...) die für 99,9% der Projekte gar keinen Sinn ergeben und dann paar Jahre später auch nahezu niemand mehr so baut. Möglichst einfach halten und das was funktioniert ist gut und richtig.

Generell denke ich mir, ist eine Lösung prinzipiell begrenzt wenn die auf "Configdrift und schnelle Entwicklung" aufbaut. Da sollte man sich auf Schnittstellen einigen, die möglichst stabil bleiben und dann auch in der Pipeline verwendet/abgefragt werden. Bringt aber natürlich nichts, wenn sich niemand berufen fühlt in die Idee zu investieren und du dann letztendlich nur am hinterherrennen bist (einfach mal knallen lassen...). Aber wenn jemand jede Woche am Logging Interface rumschraubt in seinem Projekt, dann hilft dir keine Technologie. Selbiges beim Setup.

Die Gitrepos sind da mMn ein untergeordnetes Thema. Auch wenn alles in einem Repo wäre würdest du doch ca. 10 Dockercontainer starten und deren Zusammenspiel debuggen müssen. Generell bietet git aber doch mechanismen für sowas an (sub-modules)? Habe damit aber noch nie gearbeitet. Oder halt ein Skript, was die notwendigen Repos zieht und dann alles startet. Das ist vermutlich das, was du gemacht hattest. Wie gesagt, ich denke der Ansatz war nicht das Problem...

 

[NJay]

Aber wenn jemand jede Woche am Logging Interface rumschraubt in seinem Projekt, dann hilft dir keine Technologie. Selbiges beim Setup.

Das ist leider aktuell nicht zu verhindern. Es wird besser, aber wir tappen aktuell bei der Entwicklung noch sehr im dunkeln und probieren Dinge aus, da wir uns in einem Bereich bewegen, wo es einfach keine Referenz gibt. In der Form hat es vorher einfach noch niemand gebaut, so ist Forschung halt.

Ich bin aber deutlich weiter gekommen. Ich habe delve (https://github.com/go-delve/delve) genommen, um einen debugger jederzeit an das normal laufende Entwicklungssetup anzuhängen.
Bedeutet ich starte einfach die normale Umgebung in docker, kann mich aber jederzeit mit VSCode an einzelne Container attachen. Klappt gut.

Ein Problem habe ich noch, da sich alle Instanzen den selben Code teilen, teilen sie sich auch die Breakpoints in VSCode. Ich würde nun gerne unterschiedliche Breakpoints für jede Instanz setzen. Gibt es hier Empfehlungen?