Upgrade to thumbor 7.0.0

[heynemann]

Hey!

First of all congratulations on the incredible work you've been doing!

Second, we should update MinimalCompact's Docker image to thumbor 7 and python 3.8.

We are already submitting PR to AWS thumbor lib to support python3.7+ and thumbor 7.

Do you need help?
The release notes can be found here https://github.com/thumbor/thumbor/releases/tag/7.0.0a2

[gingerlime]

Hey @heynemann 👋

Really exciting news to see Thumbor 7 getting out of the gate! Huge congratulations and massive thank you for all your hard work.

Thank you for the compliment. I think most credit should go to @kkopachev. I wouldn't be able to do that without him. In a way, I'm just here to support him :)

I'd love to get thumbor 7 dockerized. Since it's in Alpha, I guess we might need to build it manually at first and tag it separately (so latest still points to the latest stable version). I went through the release notes and couldn't find specific instructions on how to deploy/build thumbor 7 however? I guess @kkopachev has this knowledge anyway? So definitely hope he can get involved or lead this? asking nicely... :)

[kkopachev]

Build should be all the same, however I am not sure about remotecv.

[kkopachev]

oh, well. There are more than that. Looked into requirements.txt file and found many extensions not yet upgraded.

remotecv==2.2.2
opencv-engine==1.0.1
tc-aws==6.2.10
tc-core==0.4.0
tc-shortener==0.2.2
thumbor-memcached==5.1.0
tc-mongodb==5.1.0
tc-redis==1.0.1
thumbor-cloud-storage==3.0.0
graphicsmagick-engine==0.1.1
tc_prometheus

tc_aws is getting upgrade soon.
Not sure there is any value in caring graphicsmagick-engine and opencv-engine 🤷‍♂️

[gingerlime]

Thanks @kkopachev !

Isn’t opencv-engine required for remotecv ? In general, I think thumbor 7 is going to break some backwards compatibility and that’s fine. We can also remove some libs that we’re not sure about (definitely in alpha) and then maybe bring them on if we’re sure they work and that they’re helpful?

[kkopachev]

@gingerlime here is a good Dockerfile to start:

FROM python:3.8

RUN pip install thumbor==7.0.0a2

ARG SIMD_LEVEL

RUN PILLOW_VERSION=$(python -c 'import PIL; print(PIL.__version__)') ; \
    if [ "$SIMD_LEVEL" ]; then \
      pip uninstall -y pillow || true && \
      CC="cc -m$SIMD_LEVEL" pip install --no-cache-dir -U --force-reinstall --no-binary=:all: "pillow-SIMD<=${PILLOW_VERSION}.post99" \
      # --global-option="build_ext" --global-option="--debug" \
      --global-option="build_ext" --global-option="--enable-lcms" \
      --global-option="build_ext" --global-option="--enable-zlib" \
      --global-option="build_ext" --global-option="--enable-jpeg" \
      --global-option="build_ext" --global-option="--enable-tiff" ; \
    fi ;

ENTRYPOINT ["python", "-mthumbor.server"]

CMD ["--port=80", "-lDEBUG"]

it even works:

docker build -t thumbor7 .
docker run --rm -it -p 8080:80 thumbor7:latest

2020-02-29 08:05:16 thumbor:WARNING pycurl usage is advised. It could not be loaded properly. Verify install...
2020-02-29 08:05:16 asyncio:DEBUG Using selector: EpollSelector
2020-02-29 08:05:16 root:DEBUG thumbor running at 0.0.0.0:80
2020-02-29 08:05:37 thumbor:DEBUG METRICS: inc: response.count:1
2020-02-29 08:05:37 thumbor:DEBUG METRICS: inc: storage.miss:1
2020-02-29 08:05:40 thumbor:DEBUG METRICS: timing: original_image.fetch.200.thumborize_me:2965
2020-02-29 08:05:40 thumbor:DEBUG METRICS: inc: original_image.status.200:1
2020-02-29 08:05:40 thumbor:DEBUG METRICS: inc: original_image.response_bytes:510239
2020-02-29 08:05:40 thumbor:DEBUG creating tempfile for http%3A//thumborize.me/static/img/beach.jpg in /root/thumbor/storage/be/a20f33f40465140b18eb77d09c420fc801b6d9.db10c5eb1f7742beadf8c10c7bac8be4...
2020-02-29 08:05:40 thumbor:DEBUG moving tempfile /root/thumbor/storage/be/a20f33f40465140b18eb77d09c420fc801b6d9.db10c5eb1f7742beadf8c10c7bac8be4 to /root/thumbor/storage/be/a20f33f40465140b18eb77d09c420fc801b6d9...
2020-02-29 08:05:40 thumbor:DEBUG Stored crypto at /root/thumbor/storage/be/a20f33f40465140b18eb77d09c420fc801b6d9.txt (security key: MY_SECURE_KEY)
2020-02-29 08:05:41 thumbor:DEBUG Format specified: png
2020-02-29 08:05:41 thumbor:DEBUG Image format specified as .png.
2020-02-29 08:05:41 thumbor:DEBUG Content Type of image/png detected.
2020-02-29 08:05:41 tornado.access:INFO 200 GET /unsafe/300x300/filters:format(png)/http://thumborize.me/static/img/beach.jpg (172.17.0.1) 3077.95ms
2020-02-29 08:05:41 thumbor:DEBUG METRICS: timing: response.time:3077
2020-02-29 08:05:41 thumbor:DEBUG METRICS: timing: response.time.200:3077
2020-02-29 08:05:41 thumbor:DEBUG METRICS: inc: response.status.200:1
2020-02-29 08:05:41 thumbor:DEBUG METRICS: inc: response.format.png:1
2020-02-29 08:05:41 thumbor:DEBUG METRICS: timing: response.time.png:3077
2020-02-29 08:05:41 thumbor:DEBUG METRICS: inc: response.bytes.png:162084

[gingerlime]

@kkopachev That's awesome! Thank you!

I'll create a PR with this, and also start working on the build/push pipeline, so we can get it out on docker hub (without affecting latest or stable versions). This should hopefully ease the testing process for thumbor 7, as well as the images that we create here.

[gingerlime]

One problem I already bumped into is using circus. We use it to run thumbor multiprocess (which proved useful so far).

I think the latest version of circus does not support tornado?

I'm getting

ERROR: circus 0.16.1 has requirement tornado<5.0,>=3.0, but you'll have tornado 6.0.3 which is incompatible. when building

and then circus[1] [ERROR] exception unsupported operand type(s) for *: 'AsyncIOMainLoop' and 'float' caught when running it ...

Maybe thumbor 7 has a better multiprocess/multithread story, so circus isn't required? but otherwise, it might be a bit of a loss not being able to use circus. @kkopachev @heynemann any thoughts/suggestions?

[heynemann]

oh, well. There are more than that. Looked into requirements.txt file and found many extensions not yet upgraded.

remotecv==2.2.2
opencv-engine==1.0.1
tc-aws==6.2.10
tc-core==0.4.0
tc-shortener==0.2.2
thumbor-memcached==5.1.0
tc-mongodb==5.1.0
tc-redis==1.0.1
thumbor-cloud-storage==3.0.0
graphicsmagick-engine==0.1.1
tc_prometheus

tc_aws is getting upgrade soon.
Not sure there is any value in caring graphicsmagick-engine and opencv-engine 🤷‍♂

I'm on remotecv next!

[kkopachev]

On circus/multiprocess thing. I was looking into Unix docker listening and saw that ‘server.start()’ call is done with hard coded value 1. Upon reading docs it appears that this is used to define how many processes to start. Passing nothing would bring up number of processes equal to number of cpus.
For me it seems like perfect (and built-in) match.
What do you think, guys? Could do it as non-braking change.

[gingerlime]

@heynemann

Looked into requirements.txt file and found many extensions not yet upgraded.

The Dockerfile actually stops using requirements.txt for now... It's on the TODO list to move things back to the file, but for now I wasn't sure what is needed / what can be upgraded etc, so I just hard-coded the libraries in the Dockerfile temporarily. If you can give us input on what libs/versions are needed, I'd be happy to include them.

@kkopachev

Passing nothing would bring up number of processes equal to number of cpus.

I personally think we should give the user control over this. In some cases, you might want more processes than CPU (e.g. I/O bound cases might benefit from 1.5x cpu or 2x cpu, it's not uncommon). Other cases maybe you have multiple instances and want to limit the number of processes for each instance? e.g. I might have a 16-core VM, but I only want to allocate 4 processes for docker, and the rest for other docker processes? So... I personally feel more comfortable if there's a choice to the user. Of course, a sane default can be 1 or the number of available CPUs, but I think it should be possible to override it easily.

What do you think, guys? Could do it as non-braking change.

If we set it to the number of cpus without configuration, it is a breaking change as far as MinimalCompact I would say. Because so far it's configurable.

EDIT: sorry, maybe I misunderstood you? maybe you mean that we can pass the number of processes to it? if so then it's great 👍

[kkopachev]

Sorry, was not clear enough.
Introduce new cli arg ‘—num-processes‘ default to 1

[heynemann]

I'm working on a performance test suite for thumbor. That will allow us to make these trade-offs much easier.

[gingerlime]

@heynemann cool. Take a look at #14 and the benchmarks folder ... it's very basic, but hope it's helpful in some way for profiling / testing performance?

[sibelius]

what is missing for this upgrade?

[heynemann]

I guess people testing it. Would you be willing to test and provide feedback?

[sibelius]

sure, can we have a Dockerfile-version7? or something like this?

[gingerlime]

#68 (comment)

[gingerlime]

created a new PR / docker image for 7.0.0a5. see #76

[orifito]

Any update on this?

[gingerlime]

I think best to check with the upstream thumbor project. If/when there’s a new version I’d be happy to bake a new image :)

[orifito]

Thanks for the quick response. So the image tagged as 7.0.0a5 can be considered as ready for production?

[gingerlime]

That’s also something to ask upstream.

Intuitively I would not recommend it. I’m still using thumbor 6 in production.

[heynemann]

TBH we're waiting on someone to confirm that this image is working appropriately but have been having a hard time getting help on it.

[heynemann]

Then we'll release 7.0.0 to the public.

[gingerlime]

Hey @heynemann is v7 fully backwards compatible with v6? are there any live installation of thumbor v7 (without docker)?

[gingerlime]

I can try to test the image on our staging environment, but still hope others can confirm using v7 in production in some non-toy setups.

[gingerlime]

Also there's a todo list on #76 that I might need help with ... to be honest it's been a while, so not sure precisely what's important or what I missed ... cc @kkopachev

[heynemann]

It's not entirely compatible :( We've upgraded Tornado to the latest version as well as drop support for python 2. The latter should not introduce problems (unless the plugins and libraries you are using are not python 3 compatible), but the former means there are some breaking changes like the removal of tornado.gen.coroutine.
The transition should be fairly easy nonetheless. It's just not completely pain-free.

[r0bdiabl0]

Hi all. What's the latest with this? It's been over 6 months and I'm sure a lot has happened since. I'm evaluating other image processing tools but would love to continue using Thumbor since our production environments use it everywhere. Having an updated Python3 version will allow us to use some new engines that are faster and support some of the newer file formats.

[heynemann]

Hey @r0bdiabl0 I think it is safe to release a 7.0.0. Will do it later this week.

[pscheit]

ou nice!
@r0bdiabl0 same here, what did you evaluate so far?

[gingerlime]

@heynemann that's great. As far as this repo / docker images, I think I might still need some help. I mentioned it here ... happy to continue working on it so we can have a v7 out. I'm still a little unsure given that v7 isn't entirely backwards-compatible though ...

In terms of alternatives, I'm aware of imgproxy which looks great, but not all features are open-source, and some are paid-only. I also started collaborating recently with imagor. It is written in go, but is API-compatible with thumbor, which I think is great. Performance-wise, it's looking really promising (one benchmark got ~70req/s from thumbor and ~600req/s with imagor).

I'm not trying to start a war :) as the maintainer of these docker images, I'm happy supporting whatever image processing options are out there. Obviously with preference to thumbor (or thumbor-compatible), because that's what we're using in our production environment.

[heynemann]

Working on getting the docker image working. :)

[heynemann]

Regarding imagor I got really flattered that they are doing it! It proves that thumbor is now a protocol for open source imaging servers and not just a project. That said, I believe the level of battle-testedness (is that a word? :D) that thumbor has will take some time to achieve, as well as the extensibility that allows it to conform to any architecture or cloud provider you feel like using (even though many use AWS).
If I can help imagor I will :)

[gingerlime]

You should definitely feel flattered. Thumbor is amazing, and definitely has far more mileage, breadth of options and community. However, it's definitely interesting to see some other options, and some of them offer some performance improvements. Perhaps there's some room for collaboration? cc @cshum

[cshum]

Imagor author here. Congratulations to the Thumbor 7.0.0 release! I cannot wait to try it out.
I am a Go developer. I have also been a fairly heavy thumbor user, which I deployed thumbor to website that serves millions of images (product catalog related).

The initiative of imagor is to create a subset of thumbor's feature optimised for our production use cases, which is oriented towards common web image operations. Shall I need more than that though e.g. face detection, I will probably use thumbor.

I do believe more options is for the better, and I am happy for any kinds of collaborations :).

[heynemann]

Added compatibility mode to thumbor-aws in release 0.4.0. Can you try it @gingerlime? Sorry for the delay. Adding ton of good stuff for thumbor like awesome-thumbor repository. Later I'll add a "thumbor alternatives" category there and put imagor there.

[gingerlime]

See #103