Бессерверная платформа, служба Python слишком велика

У меня есть очень простой сервис Serverless Framework. В сервисе я использую плагин serverless-python-requirements для развертывания. Я успешно могу выполнить развертывание с моего локального компьютера, но развертывание не выполняется в моем конвейере CI/CD:

UPDATE_FAILED: AzurePhishSimReportFunctionLambdaFunction (AWS::Lambda::Function) Обработчик ресурсов вернул сообщение: «Размер разархивированного файла должен быть меньше 262144000 байт (служба: Lambda, код состояния: 400, идентификатор запроса: 2b53c48c-adb8-45b8-8844-8bfb317612bb)» (RequestToken: 126200f8-fd75-9bd8-4c0e-6ebf4d0c4e 40 , HandlerErrorCode: InvalidRequest)

При развертывании с моей локальной машины сервис заархивирован в небольшой пакет:

Загрузка файла службы azure-phishing-simulation-reporter.zip на S3 (16,58 МБ)

Однако при развертывании из CI/CD пакет значительно больше:

Загрузка файла службы azure-phishing-simulation-reporter.zip на S3 (136,71 МБ)

Насколько я понимаю, это может быть из-за локального кэширования, однако следующее предложенное решение не имело никакого эффекта. https://forum.serverless.com/t/разные-размеры-пакетов-при-развертывании/7819/2. Тем не менее, меня это не слишком беспокоит, так как я планирую развертывание через CI/CD.

Печальная реальность — у сервиса есть только три требования высокого уровня:

azure-phishing-simulation-reporter ➜  /bin/cat Pipfile
...

[packages]
requests = "*"
boto3 = "*"
msal = "*"

...

Глядя на каталог требований, становится ясно, что botocore (dep для boto3) и криптография (dep для всех трех) являются основной проблемой:

azure-phishing-simulation-reporter ➜  du -s .serverless/requirements/* | sort -nr
154592  .serverless/requirements/botocore
31528   .serverless/requirements/cryptography
2088    .serverless/requirements/boto3
1264    .serverless/requirements/pycparser
976 .serverless/requirements/dateutil
936 .serverless/requirements/charset_normalizer
920 .serverless/requirements/urllib3
800 .serverless/requirements/cffi
632 .serverless/requirements/msal
600 .serverless/requirements/s3transfer
576 .serverless/requirements/certifi
568 .serverless/requirements/idna
440 .serverless/requirements/requests
424 .serverless/requirements/_cffi_backend.cpython-39-darwin.so
160 .serverless/requirements/jwt
160 .serverless/requirements/jmespath
72  .serverless/requirements/six.py
16  .serverless/requirements/bin
8   .serverless/requirements/requirements.txt

Хотя это возможно, я читал, что полагаться на среду выполнения AWS Lambda для предоставления библиотеки boto3 и библиотеки запросов в комплекте с botocore — плохая практика: https://github.com/serverless/serverless-python-requirements/issues/ 304#issuecomment-455359902

Всем привет. Я SA для AWS.

Наша ведущая практика заключается в том, чтобы поставлять вашу собственную версию boto с кодом вашего приложения либо как часть zip-файла обработчика, либо как слой (для более крупных проектов).

Теперь к тому, что я пытался сделать, а это практически каждый вариант, встроенный в плагин serverless-python-requirements (https://www.serverless.com/plugins/serverless-python-requirements):

• молния
• стройный
• слои

Я также пытался исключить файлы/каталоги с помощью следующего блока в serverless.yml:

package:
  patterns:
    - '!.git/**'
    - '!test/**'
    - '!e2e/**'
    - '!src/**'
    - '!node_modules/**'
    - '!venv/**'
    - '!__pycache__/**'
    - '!requirements.txt'
    - '!Pipfile'
    - '!Pipfile.lock'
    - '!README.md'

Ничего не работает. Я чувствую, что это должна быть простая проблема для решения, и меня разочаровывает то, что собственные библиотеки AWS в основном ответственны за создание раздутых пакетов развертывания, которые не соответствуют их собственным ограничениям по размеру. Я возлагал большие надежды на использование слоев и был потрясен, увидев, что слой крошечный по сравнению с пакетом развертывания:

Загрузка файла службы azure-phishing-simulation-reporter.zip на S3 (119,5 МБ)

Загрузка файла службы pythonRequirements.zip на S3 (17,77 МБ)

Руководство по правильному способу обойти это приветствуется!