привет
может кто подкинет какой хороший гайд/видео по тому, как правильно настраивать ci/cd много-много лямбд

все что я находил - берем одну хело ворлд лямбду, вешаем на нее code deploy и уря. А как сервис из 10-20 лямбд так деплоить?

А у вас там прям независимые микросервисы? Или они все сидят в одном репозитории и их надо все разом обновить?

cloudformation + serverless
можешь создавать n-пайплайнов c cfn и деплоить n-лямбд

или 1, или группировать

смесь первого и 2. В одной репе есть сейчас 2-3 микросервиса
но даже в рамках одного есть допустим 10 лямбд под алб, как это правильно менеджить

пока к этому и пришел, когда каждый микросервис имеет свой пайплайн
но не отвечает на вопрос, как 10лямбд из одного сервиса правильно менеджить

может кто-там больше увлекается serverless то подскажет более удобный подход, мне пока этого хватает

много лямбд менеджат у нас через тераформ и гитлаб, есть список лямбд, под них создаются репы и сиай из темплейта

Serverless framework на npm для этого очень хорошо подходит. Ну и его надо завернуть все равно в пайплайн.
Только один вопросик ради интереса - а почему алб вместо апи гейтвея?

у нас 3 региона под GA, не знаю как сейчас, раньше он умел только alb таргетить

посмотрел, сейчас тоже не умеет

как сделать просто деплой я понимаю(мы cdk используем). я не понимаю как сделать нормально канарейку или блю-грин сразу на 10 лямбд

Ох, с этого и надо было начинать 😊

просто я вообще нигде не могу найти никаких примеров, такое очучение, что каждый делает как умеет)

В моем понимании, такие механизмы подразумевают несколько этапов деплоя с ручным контролем. При чем регулировка то по сути происходит на балансировщике.

Для примера с GA с 3 регионами я даже представляю как это выглядит
1. Выводим два регион из под ГА
2. Апдейтаем один, прогоняем тесты
3. Далее вводим его под га с каким-нибудь маленьким весом
4. Мониторим - все ок, повышаем дальше
5. И так далее для этого и следующих регионов

в целом, это можно даже автоматизировать
но это управлением версиями идет на уровне целого региона

Привет! Может кто-то пытался запустить селениум на лямбде с докер имаджем? Я уже несколько дней промучался и опустил руки) Вот докер файл

FROM public.ecr.aws/lambda/dotnet:5.0
WORKDIR /var/task
RUN curl -SL https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm > chrome.rpm
RUN yum -y install ./chrome.rpm
RUN ln -sf /opt/google/chrome/google-chrome /usr/bin/google-chrome
RUN chmod 755 /usr/bin/google-chrome
COPY --from=build /app/out ./
CMD ["UITest::UITest.Function::FunctionHandler"]

локально отрабатывает через Lambda Runtime Interface Emulator на ура, а в самой лямбде не хочет( ошибка

unknown error: Chrome failed to start: crashed.\n  (chrome not reachable)\n  (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

в логах вот так

...
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
[1609161231.540][SEVERE]: CreatePlatformSocket() failed: Address family not supported by protocol (97)
ChromeDriver was started successfully.
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
[1609161233.754][SEVERE]: CreatePlatformSocket() failed: Address family not supported by protocol (97)
[1609161233.905][SEVERE]: CreatePlatformSocket() failed: Address family not supported by protocol (97)

что может быть в лямбде такого особенного чего нету в ее эмуляторе?

FROM public.ecr.aws/lambda/dotnet:5.0
WORKDIR /var/task
RUN curl -SL https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm > chrome.rpm
RUN yum -y install ./chrome.rpm
RUN ln -sf /opt/google/chrome/google-chrome /usr/bin/google-chrome
RUN chmod 755 /usr/bin/google-chrome
COPY --from=build /app/out ./
CMD ["UITest::UITest.Function::FunctionHandler"]

unknown error: Chrome failed to start: crashed.\n  (chrome not reachable)\n  (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

...
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
[1609161231.540][SEVERE]: CreatePlatformSocket() failed: Address family not supported by protocol (97)
ChromeDriver was started successfully.
Connection refused 127.0.0.1:36987 (127.0.0.1:36987)
[1609161233.754][SEVERE]: CreatePlatformSocket() failed: Address family not supported by protocol (97)
[1609161233.905][SEVERE]: CreatePlatformSocket() failed: Address family not supported by protocol (97)

Мне кажется тут имеет смысл посмотреть в сторону device farm https://aws.amazon.com/device-farm/

не, стоит цель минимизировать затраты на мониторинг) хедлесс браузер в периодической лямбде выглядит как то что нужно. Сейчас юзаю для той же цели периодический фаргейт таск, но к сожалению там приходится платить за NAT, хотелось бы этого избежать

Cloudwatch Canaries?

Так в паблик сабнете запусти