не надо так.

смайл просто будет слишком большой, поэтому точку добавил

а зачем он? у всех суббота, вечер люди отдыхают, захотят ответят, не захотят не ответят, от количества смайлов ничего не изменится кроме отношения к вам. Тут помогают потому что могут и хотят, а не потому что кто-то должен решить ваши проблемы. В следующий раз просто дам RO.

я извиняюсь, я ничего такого не написал в этом чате - просто отправил смайл, почему ко мне сразу должны люди относиться предвзяться из-за смайла? я ведь ничего не сделал.

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

provider:
  name: aws

  ecr:
    images:
      test-package:
        path: ./test-package

Во время сборки docker image можно использовать build args
https://docs.docker.com/engine/reference/commandline/build/#set-build-time-variables---build-arg
"You can use ENV instructions in a Dockerfile to define variable values. These values persist in the built image. However, often persistence is not what you want. Users want to specify variables differently depending on which host they build an image on."

build-args направили меня на это обсужение:
https://forum.serverless.com/t/serverless-aws-custom-image-ecr/14228
Но что то не похоже, что там есть какое то прямое решение этой проблемы
Lambda с ECR относительно новая фича, может быть еще не завезли всё что необходимо
Судя по вот этой строчке https://github.com/serverless/serverless/blob/89b813da51cedf80ca66ae4b4ad269edf8614ec0/lib/plugins/aws/provider.js#L1819
никакие build-args не ожидаются
Я бы отправлялся куда то в https://github.com/serverless/serverless/issues и искал информацию дальше там

P.S. я не работал с serverless framework, но возможно информация выше будет полезной в этой проблеме
И это скорее вопрос к самому serverless, чем к AWS или Docker

Спасибо

Спасибааа

Всем привет, есть около сотни репок со статикой nodejs, они щас собираются и деплояться на s3 бакет, хотелось бы версионинг какой то прикрутить и возможность отката в случае чего, что думаю :
Сделать один package.json который будет собирать всю статику, залить эту статику в elastic beanstalk где уже можно будет прикрутить версии и реализовать blue green , либо же можно все так же на s3 деплоить и к нему прикрутить cloudfront но тут не знаю как реализовать доступность статики при ее обновлении, или подскажите лучший вариант куда выливать статику , собирать ее в один артифакт и версионировать , с возможность отката и high availability, важный момент, CDN’нов у нас много по этому на нем не хотелось бы что то реализовывать

S3 из коробки умеет версионировать

Использовать гит теги с версией для деплоя в прод продолжая деплоить в S3 + CloudFront?
Если нужен откат, то пересобирать с предыдущей версией

Ну да, только я бы не хотел завязываться на cloudfront переключениях дистрибутов, потому что CDN’нов у нас много и нужна какая то синхронизация что бы на всех сразу пошло обновление assets

Постепенно, не сразу все, и кешировать на CDN мы не будем

Меня больше интересует момент :
Вот есть около сотни репок с nodejs приложениями, я их собираю и деплою на s3 , для дева это ок, но вот как мне завернуть все эти артефакты в один? И деплоить на прод

В деплой добавить шаг инвалидации?

+я бы хотел этот один «метапакет» версионировать и поставлять на прод, и вслушаемся чего откатываться на прошлую версию

Я представлял это себе что будет какой то package.json в котором я буду перечислять компоненты в зависимостях и их версии, а потом собирать однин больной клиентский пакет

Можно создать дженкинс джобу которая будет тянуть код из множества разных гит реп и дальше как угодно его крутить

Кто то использовал lambda edge?

Либо собирать готовые пакеты для каждой из реп и класть их в хранилище артефактов и дальше уже вытягивать обратно в отдельной джобе деплоя в прод через тот же package.json