Takie pytanie do osób zajmujących się AWS. Namnorzyło mi się ostatnio funkcji AWS Lambda w projekcie. Dotychczasowo w moim monorepo miałem skrypt który jednocześnie deployował wszystkie Lambdy do AWS (lub jedną wybraną) i tak sobie działało, pilnowałem kiedy i co jest deployowane. Ale jest to trochę męczące. Dlatego tutaj pytanie do państwa mam, jaką macie strategie deploymentu Lambd? Macie to podpięte do jakiegoś CI/CD gdzie po pushu czegokolwiek do projektu wrzucacie aktualizacje Lambdy do AWS czy może robicie to ręcznie jak ja dotychczas albo jeszcze jakiś inny sposób macie?
Mógłbym to podpiąć do swojego CodePipeline ale trochę denerwuje mnie fakt, że historia zmian Lambdy byłaby zakłamana, bo aktualizowana byłaby nawet wtedy gdy nie było w niej zmian (kod funkcji trzymany jest w S3 - każdy nowy build to nowy zip lądujący w S3 - nawet gdy nie ma zmian w kodzie - tutaj kwestie odgrywa timestamp mark przy tworzeniu zipa).
A S3 nie posiada przypadkiem mechanizmu wersjonowania uploadowanych plików i zamiast jechać po timestampie, spróbować użyć wersjonowania z S3?
A te lambdy mają właścicieli? Dlaczego Ty jaki DevOps zarządzasz lambdami?
Nie jest tylko devopsem, to by było za nudna robota :v
Nie mam doświadczenia z serverlessem, ale chyba zacząłbym tutaj
bo aktualizowana byłaby nawet wtedy gdy nie było w niej zmian
pytaniem, czy traktujesz swoje funkcje jako niezależnie "nanoserwisy", czy może masz grupy funkcji, które celowo wdrażasz jednocześnie. No i z tym .zip który jest wrzucany nawet jak nie było zmian, to chyba jakiś szczegół techniczny - nie czaję gdzie tutaj problem, masz wiele funkcji w jednym repo, ale nie da się wykryć, czy była zmiana, więc deploy leci zawsze?
EDIT: piszesz że rolę odgrywa timestamp w zipie - wiem że wtedy np. Terraform widzi to jako zmianę i wymusza redeploy. Zobacz czy jesteś w stanie zrobić reproducible build, poresetować te timestampy do 0, może to obejdzie ten problem?
Ja bym na Twoim miejscu napisał skrypt, który można uruchomić lokalnie deployAll, który robi deploy wszystkich lambd, jeśli się zmieniły. Musiałbyś to jakoś zprawdzić, czy zdeployowana wersja jest inna. Albo po kodzie źródłowym, albo jakimś hashu albo jak tam wolisz.
Potem taki skrypt można odpalić "on-push" w swoim hostingu repozytorium (np. github actions).
@Riddle Te lambdy nie są ze sobą w żaden sposób powiązane biznesowo to dlaczego chcesz je powiązać (couple) na poziomie Twojego skryptu czy CI/CD? Zazwyczaj problem z Lambdami jest taki, gdzie je umieścić a nie jak je uruchamiać. Jedni tworzą oddzielne repozytoria, a inni zarządzają je z poziomu repozytoriów które je wywołują itd. Szczerze, to jedno repo ze wszystkimi lambdami wygląda tragicznie.
dmw napisał(a):
@Riddle Te lambdy nie są ze sobą w żaden sposób powiązane biznesowo to dlaczego chcesz je powiązać (couple) na poziomie Twojego skryptu czy CI/CD? Zazwyczaj problem z Lambdami jest taki, gdzie je umieścić a nie jak je uruchamiać. Jedni tworzą oddzielne repozytoria, a inni zarządzają je z poziomu repozytoriów które je wywołują itd. Szczerze, to jedno repo ze wszystkimi lambdami wygląda tragicznie.
Z couplingiem masz rację, jeśli faktycznie te lambdy nie są powiązane, to ten skrypt powinien deplować jedną z nich. Ale tak czy tak powinien sprawdzić czy ta sama wersja już jest w lambdzie, i czy należy ją ponownie wrzucić.
Jednak z tego co pisał autor wątku, to wygląda tak jakby te lambdy jednak były zależne od siebie.
mam pare projektow gdzie mam monorepo i rozne usługi w tym lambdy. Jak potrzebuje dzielić piepline ze wzgledu ze jakies moduly są niezalezne to robie osobne kroki w zależności co się zmieniło. W gitlabie np po prostu wskazuje scieżke do folderu i gdy cokolwiek ponizej sie zmieni dany step jest osiagalny przez workflow.
Do tego wersjonowaniem steruje przez tagi. Jezeli chce wydać wersję to po prostu tworzę taga o odpowiednim formacie i deploy leci automatycznie. A czasami jest to sterowane branchem np zawsze zmiana na main trigeruje deploy a co sie odpali zalezy od filtrów w danym stepie.