Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thumbor 6.5.2 #45

Closed

Conversation

leviwilson
Copy link

Originally I'd opened up #44 as I was having troubles being able to successfully build the lambda package from source. Some of the issues that I encountered are documented in there.

Description

This pull request bumps the thumbor dependency from 6.4.2 ➡️ 6.5.2. The version jump additionally fixes #43 in that it is now able to work with CCITT Fax4 TIFF images.

Additionally, in light of the issues I encountered with being able to successfully build the lambda function I dockerized the build so that it is repeatable.

In addition to the base dependencies that were originally in the README, I had to also pull in other dependencies into the docker image (pngcrust, gifsicle, pngquant, etc.) so that the lambda function wouldn't complain in the CloudWatch logs. Feedback welcome!

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

https://hub.docker.com/r/naftulikay/circleci-lambda-rust/builds/b2quu7btj8md9zlbf36fd59/ gave me a little
bit of a hint in which image to lock.

Just need to find which version of it uses 7.51.0. This is the error I get now:

pycurl: libcurl link-time version (7.51.0) is older than compile-time version (7.53.1)

Where 7.53.1 is the same as what curl --version shows.
Noticed in the build output that it was failing to locate some of
the imaging libraries that it was trying to yum install.

Realized that on amazonlinux 2 that the command to enable epel
is slightly different.
pip.req was removed in pip >= 10
FROM amazonlinux:2017.03.1.20170812

# lock yum to the same repository version
RUN sed -i 's/releasever=.*/releasever=2017.03/g' /etc/yum.conf
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that the build is repeatable, I locked the releasever to 2017.03 vs. latest. In particular, the issue was when building the pycurl library from source since that when you yum install libcurl-devel if it pulls latest, when the lambda function runs you get an error that the linked version of libcurl differs from the compiled version of libcurl.

To get around that, I just pinned the yum repository to that version.


# pycurl
RUN yum install -y nss-devel
ENV PYCURL_SSL_LIBRARY=nss
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pycurl is built from source. I also has to specify nss as the SSL library. Originally when I tried openssl, when it ran in lambda it complained that the compiled version used openssl but the runtime used nss.

RUN wget http://dl.fedoraproject.org/pub/epel/6/x86_64/Packages/l/libimagequant-2.5.2-5.el6.x86_64.rpm && \
yum localinstall libimagequant-2.5.2-5.el6.x86_64.rpm -y && rm libimagequant*rpm && \
wget http://dl.fedoraproject.org/pub/epel/6/x86_64/Packages/p/pngquant-2.5.2-5.el6.x86_64.rpm && \
yum localinstall pngquant-2.5.2-5.el6.x86_64.rpm -y && rm pngquant*rpm
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not able to find optipng or pngquant in yum search. In order to get around errors in including those when running the build script, I grabbed them directly from here. Now when I run it doesn't complain in the build script at the end.

zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip pngquant
zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip jpegtran
zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip optipng
zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip pngcrush
zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip gifsicle
zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip mozjpeg
zip -q -g /lambda/deployment/dist/env/../serverless-image-handler.zip imgmin

When I didn't have these dependencies, the output would say something to the effect of nothing to do here (when it couldn't find the dependencies).

WORKDIR /lambda/deployment

ENTRYPOINT ["./build-s3-dist.sh"]
CMD ["source-bucket-base-name"]
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This defaults the bucket to source-bucket-base-name; passing any other value when you docker run will override this.

@@ -1,7 +1,7 @@
# coding: utf-8

from setuptools import setup, find_packages
from pip.req import parse_requirements
from pip._internal.req import parse_requirements
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pip >= 10 does not expose pip.req and instead it was moved to _internal.

@@ -213,7 +213,7 @@ def request_thumbor(original_request, session):

def process_thumbor_responde(thumbor_response, vary):
if thumbor_response.status_code != 200:
return response_formater(status_code=response.status_code)
return response_formater(status_code=thumbor_response.status_code)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe using response here was a mistake; at one point when running my lambda function when I had an issue with tc_aws it hit this code path and blew up saying that response wasn't a global.

I believe thumbor_response is what was intended here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this was fixed in #34 as well

'botocore==1.3.7',
'tornado_botocore==1.0.2',
'botocore==1.8',
'tornado_botocore==1.3.2',
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

botocore, tornado_botocore as well as tc_aws needed to be bumped to get around the pip >= 10 issue

@leviwilson
Copy link
Author

@stevemorad did you get a chance to look over this at all?

@simllll
Copy link

simllll commented Jan 3, 2019

Any news on this?

@leviwilson
Copy link
Author

@simllll I've not heard anything back from anyone whether this is a good idea or not.

I did this PR before there was new / recent activity in the repo. I realize there's conflicts here but hadn't addressed them because I was waiting to hear back on some feedback.

Particularly wanted to get some feedback on the docker setup as I struggled a lot with getting it able to build a working lambda function so I wanted to document it in the Dockerfile.

@leviwilson leviwilson mentioned this pull request Feb 12, 2019
juliankmazo added a commit to snappr/serverless-image-handler that referenced this pull request Feb 12, 2019
- [Lambda supported versions](https://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html)
- [Docker repo](https://hub.docker.com/_/amazonlinux/)

Also modified the docker file to fix some libraries. A lot of help from aws-solutions#45
@timkelty
Copy link

timkelty commented May 1, 2019

Can we please move on this, or something like it?

Movement on any patches has been very slow, so it would great if it were easier for people to build their own. Dockerizing the dependencies helps immensely.

/cc @hyandell @hayesry

@shsenior
Copy link
Contributor

Resolved with v4.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CCITT Group 4 TIFF Images / Pillow and AWS Lambda
4 participants