Błąd importu z pliku cyptography.hazmat.bindings._constant_time import lib

Question

Próbuję utworzyć funkcję aws lambda, aby zalogować się do instancji i zrobić kilka rzeczy. A skrypt działa dobrze poza lambda, ale kiedy pakuję go przy użyciu tych samych instrukcji, co ten https://aws.amazon.com/blogs/compute/scheduling-ssh-jobs-using-aws-lambda/, to nie działa. Zgłasza ten błąd.

libffi-72499c49.so.6.0.4: cannot open shared object file: No such file or directory: ImportError 
Traceback (most recent call last): 
    File "/var/task/lambda_function.py", line 12, in lambda_handler 
    key = paramiko.RSAKey.from_private_key(key) 
    File "/var/task/paramiko/pkey.py", line 217, in from_private_key 
    key = cls(file_obj=file_obj, password=password) 
    File "/var/task/paramiko/rsakey.py", line 42, in __init__ 
    self._from_private_key(file_obj, password) 
    File "/var/task/paramiko/rsakey.py", line 168, in _from_private_key 
    self._decode_key(data) 
    File "/var/task/paramiko/rsakey.py", line 173, in _decode_key 
    data, password=None, backend=default_backend() 
    File "/var/task/cryptography/hazmat/backends/__init__.py", line 35, in default_backend 
    _default_backend = MultiBackend(_available_backends()) 
    File "/var/task/cryptography/hazmat/backends/__init__.py", line 22, in _available_backends 
    "cryptography.backends" 
    File "/var/task/pkg_resources/__init__.py", line 2236, in resolve 
    module = __import__(self.module_name, fromlist=['__name__'], level=0) 
    File "/var/task/cryptography/hazmat/backends/openssl/__init__.py", line 7, in <module> 
    from cryptography.hazmat.backends.openssl.backend import backend 
    File "/var/task/cryptography/hazmat/backends/openssl/backend.py", line 15, in <module> 
    from cryptography import utils, x509 
    File "/var/task/cryptography/x509/__init__.py", line 7, in <module> 
    from cryptography.x509.base import (
    File "/var/task/cryptography/x509/base.py", line 15, in <module> 
    from cryptography.x509.extensions import Extension, ExtensionType 
    File "/var/task/cryptography/x509/extensions.py", line 19, in <module> 
    from cryptography.hazmat.primitives import constant_time, serialization 
    File "/var/task/cryptography/hazmat/primitives/constant_time.py", line 9, in <module> 
    from cryptography.hazmat.bindings._constant_time import lib 
ImportError: libffi-72499c49.so.6.0.4: cannot open shared object file: No such file or directory 

Answer 1

W poleceniach zip w tym samouczku brakuje parametru. Zetknąłem się z tym dokładnie problemem dzisiaj z pysftp, który jest zbudowany na paramiko. libffi-72499c49.so.6.0.4 znajduje się w ukrytym katalogu z kropkami wewnątrz lib64/python2.7/site-packages/.libs_cffi_backend. W zależności od tego, w jaki sposób skompresowałeś zależności w swoim virtualenv, możesz nieumyślnie wykluczyć ten katalog.

1. Najpierw upewnij libffi-devel i openssl-devel są zainstalowane na Amazon Linux instance, inaczej moduł kryptograficzny może nie być prawidłowo kompilacji.

   sudo yum install libffi-devel openssl-devel 
   

Jeśli te pakiety nie zostały zainstalowane wcześniej, usuwać i odbudować swoją virtualenv.

2. Upewnij się, że podczas pakowania pakietów witryny korzystasz z "." zamiast "*", w przeciwnym razie nie będziesz zawierał plików i katalogów, które są ukryte, ponieważ ich nazwy zaczynają się od kropki.

   cd path/to/my/helloworld-env/lib/python2.7/site-packages 
   zip -r9 path/to/zip/worker_function.zip . 
   cd path/to/my/helloworld-env/lib64/python2.7/site-packages 
   zip -r9 path/to/zip/worker_function.zip . 
   

Answer 2

moje 2 centy: jeśli chcesz zbudować & sprawdzić swoją funkcję lambda w środowisku jako podobny do rzeczywistego lambda, jak to możliwe, ale nadal pod kontrolą, chciałbym zaproponować za pomocą LambdaCI's Docker images. Są oparte na zrzutach oryginalnego systemu plików lambda. Mają również warianty specyficzne dla danej wersji (znaczniki build-python2.7 i build-python3.6 są dla nas najbardziej interesujące). Te zdjęcia nie są bardzo małe - ponad 500 MB - ale pozwalają na uniknięcie bólu głowy podczas budowania.

Ważną zaletą Amazona jest to, że wszystkie wersje pakietu itp. Są takie same jak w prawdziwej lambda.

Oto jak ja nie buduje sobie:

cd PROJECT_DIR 
docker run --rm -it -v "$PWD":/var/task lambci/lambda:build-python2.7 bash 
### now in docker 
mkdir deps 
pip install -t deps -r requirements.txt 
# now all dependencies for our package are installed to deps/ directory, 
# without any garbage like wheel or setuptools - unlike when using virtualenv 
zip -r archive.zip MYCODE.py MYMODULE MYMODULE2.py 
cd deps 
# it's important to use . here, not * - or else some dot-starting directories will be omitted 
zip -r ../archive.zip . 
exit 
### now locally 
# just upload archive to lambda, with or without s3 

do zautomatyzowania go GitLab CI, tylko polecić go użyć tego samego Döcker obraz i umieścić te polecenia w deploy sekcji skryptu:

deploy: 
    stage: deploy 
    image: lambci/lambda:build-python2.7 
    script: 
     - mkdir deps 
     - pip install -t deps -r requirements.txt 
     - zip -r archive.zip MYCODE.py MYMODULE MYMODULE2.py 
     - cd deps && zip -r ../archive.zip . && cd .. 
     - aws s3 cp archive.zip ${bucket}/${key} 
     - aws lambda update-function-code --function-name ${func} --s3-bucket ${bucket} --s3-key ${key} 
    variables: 
     bucket: ... 
     key: ... 
     func: ...