- Newest
- Most votes
- Most comments
Hi, don't you have a naming issue of your image like the one reported in https://github.com/serverless/serverless/issues/8636 ?
In this case, the user combined :latestt with @sha and it creates a problem like yours
Best,
Didier
That was my first guess too, but I've tried using the tag and digest and double-checked the naming and it still happens.
Even when using the exact same image path and tag but updating the underlying image in ECR and then trying to publish a new lambda version results in the error. So it seems it's something with the image itself, although the same image works on my local machine.
After some digging it appears that the issue lies when copying the lambda adapter binary from the remote image.
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.7.0 /lambda-adapter /opt/extensions/lambda-adapter
If that binary exists locally and is copied across in the Dockerfile using COPY ./lambda-adapter /opt/extensions/lambda-adapter
everything works. And as mentioned in my original post this only happens when building from BitBucket Pipelines.
Could it be a docker version issue? Locally I tried with 20.10.23 and 23.0.5 and they both work. BitBucket Pipelines users 20.10.24.
In terms of the lambda issue I can only assume that when trying to set the image in the function dashboard that file can't be executed/accessed, or something else to do with how extensions are handled.
Any other ideas?
And after that discovery it appears all that was needed was to copy using a chown
. But why this is only needed in Pipelines I'm not sure.
COPY --chown=root:root --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.7.0 /lambda-adapter /opt/extensions/lambda-adapter
Relevant content
- asked 3 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 7 days ago