Блог

Главная - Вопросы по программированию - Как предотвратить Многократный Вызов контейнера функций AWS Lambda

Как предотвратить Многократный Вызов контейнера функций AWS Lambda

#python #aws-lambda #aws-lambda-containers

Вопрос:

[ОБНОВЛЕНИЕ 1:] Когда я увеличил время ожидания до 1 минуты, CloudWatch отобразил следующее в середине, после двух успешных запусков сценария, а затем один:

 REPORT RequestId: xxx-xxx   Duration: 7670.23 ms    Billed Duration: 7671 ms    Memory Size: 128 MB Max Memory Used: 36 MB  
RequestId: xxx-xxx Error: Runtime exited without providing a reason
Runtime.ExitError

Оригинальный пост

У меня есть лямбда-функция, которая запускается через пользовательский образ контейнера. Суть одного скрипта Python в нем заключается в следующем:

 # imports

def lambda_handler(event, context):
    # read a JSON file from S3, check an FTP server for some info, and prepare a JSON response
    # if file not found or some other error, handle exception, prepare appropriate JSON response
    # return JSON response

# Here be helper functions

if __name__ == '__main__':
    lambda_helper(None, None)
    # also tried response = lambda_helper(None, None)

Это первое состояние в пошаговой функции, которое будет регулярно запускаться событиями CloudWatch и, следовательно, не требует какого-либо ввода.

Он вызывается из контейнера как

 CMD ["python", "script.py"]

Когда я тестирую эту функцию с консоли, я вижу все ожидаемые сообщения журнала в CloudWatch, включая последнее, которое указывает на успешное выполнение, однако этот процесс повторяется пару раз и в целом рассматривается как сбой (красный баннер сверху).

Время ожидания истекает через 3 секунды, потому что это ограничение по умолчанию, но не раньше, чем скрипт успешно запустится пару раз. Нет проблем с памятью (используется 20-30 МБ из 128 МБ) или других ошибок.

В более ранней версии вызов to lambda_handler был заключен внутри sys.exit() , но после прочтения некоторых тем об этом , мешающих тому, как Лямбда обрабатывает функцию, я удалил ее. Единственная разница тогда заключалась в том, что я мог видеть ответ JSON в CloudWatch, тогда как теперь я вижу только сообщения журнала.

Я прочитал тонну тем и документации, но все еще не могу решить эту проблему. Любая помощь будет оценена по достоинству.

Ответ №1:

Отвечая на мой собственный вопрос.

По-видимому, если вы хотите использовать базовый образ, отличный от того, что предлагает AWS, вы должны выполнить свой код в «Клиенте интерфейса среды выполнения AWS». Первоначально я использовал изображение на Python-Alpine и попытался выполнить действия, описанные в конце этого поста в блоге, но в процессе сборки возникли ошибки по причинам, которые я не изучал. Затем я создал другой образ из Debian Buster на основе инструкций отсюда, и после некоторой «очистки» файла Dockerfile в соответствии с моим приложением это сработало.

Метки: