http://qiita.com/tf_qiita/items/90b4ec315d179b5d9b9c
Note that I solved the above problem.
When using EC2 Run Command from Lambda, Run Command executes the version set in the initial state of the instance, not the Python executable ** that is enabled in the target EC2 instance. (For Amazon Linux, it is currently 2.7.12)
Therefore, when executing a version of Python that is different from the standard, specify the executable file with the full path in the Run Command described in Lambda as shown below. In the example below, the environment built in pyenv is specified. Since Lambda is executed as root, pyenv is built as root, but if you specify it directly and execute it, you should build a user for execution.
lambda.py
ssm.send_command(
InstanceIds = instances,
DocumentName = "AWS-RunShellScript",
Parameters = {
"commands": [
"/root/.pyenv/versions/anaconda3-4.4.0/bin/python /work/hoge.py",
],
"executionTimeout": ["3600"]
},
)
In step 1, the required version (environment) is executed without adding the path of Python to be executed to the environment variable, so the library cannot be imported as it is.
Therefore, you can load the library by adding the site-packages path at the beginning of the script on the EC2 side called from Lambda.
In the example below, site-packages under the environment specified in step 1 is specified.
ec2.py
import sys
sys.path.append("/root/.pyenv/versions/anaconda3-4.4.0/lib/python3.6/site-packages/")
From the beginning, I assumed that it was a problem around the path, but it took time to isolate the cause on the Lambda side and the EC2 side. Also, is it unique to managed services, such as wasting effort in investigating whether the version is provided as a function? There was a failure. Similar low-layer stumbling blocks are foreseen in the future, but in that case I would like to recall this experience and return to the basics.
Recommended Posts