AWS Lambda не находит общий объектный файл в Layer

#java #amazon-web-services #aws-lambda #selenium-chromedriver #shared-libraries

#java #amazon-веб-сервисы #aws-лямбда #селен-хромовый преобразователь #совместно используемые библиотеки

Вопрос:

Я пытаюсь создать лямбда-функцию, которая запускает тесты Selenium на Java как часть конвейера CI / CD в AWS. Однако после того, как функция установит Chromedriver, произойдет сбой, поскольку файл .so, который требуется Chromedriver, отсутствует:

 /tmp/chrome_driver7811961600494562711/chromedriver: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory
 

Я читал, что вы можете включать собственные библиотеки через программные уровни в Lambda, и я понимаю, что вы должны скомпилировать его в среде Amazon Linux, как описано здесь .

Однако после архивирования файла и создания моего слоя он по-прежнему не получает доступ к библиотеке и выдает ту же ошибку. Я также пытался поместить его в различные каталоги zip-файла, например /opt , , /opt/lib , а также установить LD_LIBRARY_PATH переменную в функции, но по-прежнему безуспешно. Любая помощь приветствуется.

Комментарии:

1. Я думаю, вам следует поместить разделяемую библиотеку /lib64/ в.Кроме того, не зная, как вы развертываете свой lambda, вы можете просто создать образ docker, который вы можете протестировать локально, используя java lambda docker image . Должен быть быстрее и полностью тестируемым локально.

2. /lib64 тоже не сработало. Я развертываю его через консоль AWS. Я просто не понимаю, почему существует так много разных ответов на этот вопрос, и ни один из них, похоже, не работает…

Ответ №1:

Ладно, я наконец-то понял это. Прочитав больше документации, я нашел 2 ключевых момента:

Во-первых, из https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html , LD_LIBRARY_PATH по умолчанию установлено значение:

/lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib

И, во-вторых, от https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-path :

Слои извлекаются в /opt каталог в среде выполнения функции.

Итак, соединив эти 2 факта вместе, я пришел к выводу, что если я помещу зависимости /lib внутри слоя, они окажутся внутри /opt/lib , то есть внутри LD_LIBRARY_PATH , и вуаля — это сработало.

Комментарии:

1. Я просто хочу уточнить, потому что я уже давно ломаю над этим голову: вы буквально перемещаете файлы .so в папку с именем lib и заархивируете ее, и это работает? Клянусь, я пробовал это, и это не сработало.

2. ДА. Несколько вещей, которые нужно проверить: убедитесь, что вы не переопределяете LD_LIBRARY_PATH в переменных среды. Скорее всего, отсутствует более 1 зависимости, поэтому убедитесь, что ошибка не связана с другой. Убедитесь, что вы используете 64-разрядные версии вместо 32-разрядной, иначе вы получите похожую ошибку — обязательно разверните ее, чтобы прочитать полный текст ошибки.

3. Какую базовую ОС, по вашему мнению, использует Amazon Linux? CentOS?

4. @Axl Amazon Linux — это собственная ОС. Но когда вы вводите cat /etc/*release , он говорит ID_LIKE="centos rhel fedora" , так что, я думаю, это отчасти основано на этом. Но если вы спрашиваете, как я получил необходимые библиотеки, я запустил docker-образ Amazon Linux 2 локально и извлек их оттуда после установки с помощью yum.

5. У меня была такая же проблема, и мне нужно было изменить время выполнения лямбда-функции с «Runtime. DOTNET_CORE_3_1 » в » время выполнения. ПРЕДОСТАВЛЕНО». Я не смог найти официальную документацию о том, какие библиотеки предоставляются в разных средах выполнения. Но обнаружил, что в соответствии со следующим потоком reddit libglib.so.1 отсутствует во времени выполнения reddit.com/r/aws/comments/bxzzov /…