Closed vincentsarago closed 9 months ago
if the containers are based on amazonlinux2 we can simply do
FROM lambgeo/lambda-gdal:3.2-al2
FROM public.ecr.aws/lambda/python:3.8
# Bring C libs from lambgeo/lambda-gdal image
COPY --from=gdal /opt/lib/ /opt/lib/
COPY --from=gdal /opt/include/ /opt/include/
COPY --from=gdal /opt/share/ /opt/share/
COPY --from=gdal /opt/bin/ /opt/bin/
ENV \
GDAL_DATA=/opt/share/gdal \
PROJ_LIB=/opt/share/proj \
GDAL_CONFIG=/opt/bin/gdal-config \
GEOS_CONFIG=/opt/bin/geos-config \
PATH=/opt/bin:$PATH
The more I think about it, the more I think this is a documentation issue. We will just need to explain how to build the container with the snipset ☝️
And maybe an example too...
The more I think about it, the more I think this is a documentation issue. We will just need to explain how to build the container with the snipset point_up
They also allow debian containers. Why not use the original gdal container and just include AWS' Lambda Runtime?
@meyer1994 by using your own container (read here, not built from the official amazonlinux image), you'll need to add the lambda API. That's another solution which could also be 👌.
The example dockerfile in https://github.com/lambgeo/docker-lambda#1-create-dockerfile works (or at least seems too! I probably need to test more) for this if you replace the zip commands with:
CMD [ "handler.handler" ]
where you have file handler.py with function handler
inside
And if there was the desire to have a roll-your-own image, you would need to copy the lambda_entrypoint.sh file from Lambda base image and set that as the ENTRYPOINT, so the CMD can define the handler path.
So apologies for semi-hijacking this thread but I just wanted to share that I had quite a bit of difficulty (day or so) trying to build and thought I'd share the solution/dockerfile that worked for me here in case anyone else is trying to build in a similar way and getting stuck.
I used 'cdk deploy' rather than zip. Also 'cdk destroy --all' and 'docker system prune -a' came in handy to clean up images as out of space seemed to become an issue.
FROM ghcr.io/lambgeo/lambda-gdal:3.8 as gdal
# This example assume that you are creating a lambda package for python 3.10
FROM public.ecr.aws/lambda/python:3.10
# Bring C libs from lambgeo/lambda-gdal image
COPY --from=gdal /opt/lib/ /var/lang/lib/
COPY --from=gdal /opt/include/ /var/lang/include/
COPY --from=gdal /opt/share/ /var/lang/share/
COPY --from=gdal /opt/bin/ /var/lang/bin/
ENV \
GDAL_DATA=/var/lang/share/gdal \
PROJ_LIB=/var/lang/share/proj \
GDAL_CONFIG=/var/lang/bin/gdal-config \
GEOS_CONFIG=/var/lang/bin/geos-config \
PATH=/var/lang/bin:$PATH
ENV LD_LIBRARY_PATH=/var/lang/lib:$LD_LIBRARY_PATH
ENV AWS_ACCESS_KEY_ID=***********
ENV AWS_SECRET_ACCESS_KEY=****************
# Copy all files in ./src
COPY src ${LAMBDA_TASK_ROOT}/
# Install GCC
RUN rm -rf /var/cache/yum
RUN yum clean all && yum -y update && yum -y install gcc gcc-c++ unzip curl zip
RUN pip install GDAL==$(gdal-config --version) --global-option=build_ext --global-option="-I/var/lang/include" --global-option="-L/var/lang/lib"
WORKDIR /tmp
# Install AWS CLI
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \
unzip awscliv2.zip && \
./aws/install && \
rm -rf /tmp/*
WORKDIR ${LAMBDA_TASK_ROOT}
# Set the CMD to your handler.
CMD [ "main.handler" ]
One thing that also helped working this out was building in debug mode -> the last few lines get changed to this (or some variant)
RUN pip install GDAL==$(gdal-config --version) --global-option=build_ext --global-option="-I/var/lang/include" --global-option="-L/var/lang/lib"
# Install ptvsd for debugging
RUN pip install ptvsd
# # Install AWS CLI
# RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \
# unzip awscliv2.zip && \
# ./aws/install
EXPOSE 5678
# Set the CMD to your handler with ptvsd for debugging
ENTRYPOINT [ "python", "-m", "ptvsd", "--host", "0.0.0.0", "--port", "5678", "--wait", "--multiprocess" ]
# Set the CMD to your handler.
CMD [ "-m", "main" ]
https://aws.amazon.com/fr/blogs/aws/new-for-aws-lambda-container-image-support/