Golang für Ihre Serverless-Projekte verwenden

In einem meiner früheren Blogs habe ich geschrieben, warum ich für meine Lambda-Funktionen zu kompilierten Sprachen gewechselt habe. Die Verwendung von Golang für Ihre Lambda-Funktionen bringt jedoch einige Herausforderungen mit sich. In diesem Blog möchte ich über die Herausforderungen berichten, die ich gesehen habe, und darüber, wie man sie entschärfen kann.

Spoiler, ich verwende ein Makefile

Ich verwende in meinen Projekten immer ein Makefile. Wenn Sie wissen möchten, warum, habe ich dazu auch einen Blog geschrieben. Ich erwähne dies, bevor wir uns mit den Herausforderungen beschäftigen, damit der Fokus auf der Lösung und nicht auf der Technologie liegt.

Jede Funktion ist ein eigenes Modul?

Wenn Sie ein CLI-Tool entwickeln, ist Ihre Projektstruktur recht einfach. Sie haben eine Datei im Stammverzeichnis des Projekts und mindestens eine Datei, die die Geschäftslogik enthält. Wenn Sie ein serverloses Projekt erstellen, ändert sich dies. Das liegt daran, dass jede Lambda-Funktion ein eigenes Modul sein muss. Daher müssen Sie für jede Funktion einen Ordner erstellen und jeder Ordner enthält seine eigenen go.mod und main.go Dateien, die ein eigenes Modul bilden.

Abhängigkeiten verwalten

Die erste Herausforderung, die mir aufgefallen ist, ist die Verwaltung von Abhängigkeiten. Diese ist nun über Ihre Lambda-Funktionen verstreut. Das bedeutet mehr Wartungsaufwand für Ihr Projekt. Außerdem führt dies zu Problemen in Ihrer IDE. Da Ihre IDE ein einzelnes Modul erwartet und nicht mehrere, kommt sie durcheinander.

Sie können dieses Problem lösen, indem Sie einen Arbeitsbereich mit mehreren Modulen einrichten. Im Wesentlichen müssen Sie eine Datei go.work im Stammverzeichnis Ihres Projekts erstellen. Dann können Sie auf Ihre Ordner verweisen, die die Module enthalten. Ihre IDE sollte nun in der Lage sein, alle Ihre Module zu verstehen und die Abhängigkeiten für Sie zu verwalten.

Um sicherzustellen, dass Ihre Abhängigkeiten auf dem neuesten Stand sind und wir nur die einbeziehen, die wir tatsächlich verwenden, können Sie go get -u und go mod tidy ausführen. Allerdings müssen Sie dies für jedes einzelne Modul tun. Aus diesem Grund verwende ich das folgende Makefile-Ziel:

.PHONY: tidy
tidy: ## Run go get -u and go mod tidy for all modules
   $(info [+] Running go get -u and go mod tidy)
   find . -name go.mod -execdir go get -u ;
   find . -name go.mod -execdir go mod tidy ;

Dieser Befehl sucht nach jedem Ordner, der eine go.mod Datei enthält, und führt diese 2 Befehle in diesem Ordner für Sie aus. So können Sie diesen Befehl einfach und leicht öfter ausführen.

Laufende Tests

Ich bin ein Fan von TDD (testgetriebene Entwicklung), also habe ich natürlich Tests für meine Lambda-Funktionen geschrieben. Ein Beispiel dafür finden Sie im Blog "Stubbing AWS Service calls in Golang", den ich geschrieben habe. Aber mit diesem Multi-Modul-Workspace ist es schwierig, alle Tests auszuführen.

Wenn Sie go test ./... ausführen, werden nur die Tests ausgeführt, die Sie im Stammverzeichnis Ihres Projekts haben. Und nicht in den Modulen, die von Ihren Lambda-Funktionen verwendet werden. Eine Möglichkeit wäre, in Ihren Lambda-Ordner zu navigieren und den Befehl dort auszuführen. Da dies jedoch zusätzliche Schritte erfordert, ist die Wahrscheinlichkeit, dass Sie dies tun, geringer als bei einem einzigen einfachen Befehl.

Aus diesem Grund verwende ich das folgende Makefile-Ziel:

.PHONY: test
test:
   $(info [+] Running unit tests)
   find . -name go.mod -execdir go test ./... -coverprofile=coverage.out -covermode count ;

Wie bei der Verwaltung der Abhängigkeiten suchen wir auch hier nach jeder go.mod Datei. Und führen den Befehl in diesem Ordner aus. Es wird auch eine Datei erzeugt. Da die Datei jedoch nur die Abdeckung des getesteten Moduls enthält, müssen wir sie miteinander kombinieren:

reports/coverage.out:
   find . -name coverage.out -type f -exec sh -c 'cat {} | if [ "$1" = "{}" ]; then cat {}; else tail -n +2 {}; fi' sh {} ; > reports/coverage.temp
   echo "mode: count" | cat - reports/coverage.temp > reports/coverage.out
   rm reports/coverage.temp

Wir suchen nun nach jeder coverage.out Datei und nehmen den gesamten Inhalt minus der ersten Zeile. Wir legen alle diese Zeilen in einer einzigen Datei ab und fügen dann die erste Zeile wieder hinzu.

Wenn Sie nun Ihre Abdeckung z.B. in GitLab visualisieren möchten. Sie benötigen eine Cobertura XML-Datei:

reports/coverage.xml: reports/coverage.out
   $(info Collecting Code Coverage)
   go run github.com/boumenot/gocover-cobertura < reports/coverage.out > reports/coverage.xml

Wir verwenden einfach das Modul gocover-cobertura, um die Datei in das benötigte XML-Format zu konvertieren, und schon sind Sie startklar.

Fazit

Es ist möglich, ein Setup mit mehreren Modulen zu haben und einen einfachen und einzigen Befehl zu verwenden, um Aktionen wie die Ausführung Ihrer Tests durchzuführen. Allerdings müssen Sie einige Skripte pflegen, zum Beispiel in einem Makefile. Ein vollständig funktionierendes Beispiel finden Sie auf Github.

Foto von alleksana