minimalcompact / thumbor Goto Github PK

Could you provide a Docker Hub Image for the 6.7.5 release please?

Thank you 🍺

Hi! Just noticed the AUTO_PNG_TO_JPG configuration variable cannot be set via environment variable. Seems like thumbor added it a while ago, but it never made it to the image.

See: https://thumbor.readthedocs.io/en/latest/configuration.html#auto-png-to-jpg

Any chance this could be added? Or was it removed on purpose?

I checked https://github.com/MinimalCompact/thumbor/blob/master/thumbor/conf/thumbor.conf.tpl

AUTO_WEBP is in there, but not AUTO_PNG_TO_JPG.

Thanks a lot!

How can I add a custom image loader?

Hi there,

i recently switched to your thumbor image. Now I get the following for some big images:

nginx_1     | nginx.1    | 2020/05/30 03:35:59 [error] 56#56: *7870 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.5.1, server: localhost, request: "GET /dV1EGhpGw6RV4JX6jGeYkZhJ3M0=/fit-in/12000x12000/filters:quality(100)/hochzeit-julia-und-ulrich-3.jpg HTTP/1.1", upstream: "http://192.168.96.2:80/dV1EGhpGw6RV4JX6jGeYkZhJ3M0=/fit-in/12000x12000/filters:quality(100)/hochzeit-julia-und-ulrich-3.jpg", host: "images.xxx.xx"

I request 5 images at the same time. They are like 10mb each unpacked 65mb (5800x3968)

do i need to increase the nginx timeouts? Do you have an idea how to do it with jwilder/proxy ?
don't we have to use the fastcgi upstream?

I'm currently setting up this image with Kubernetes, and have run into some issues.

Are there any reasons why there is a differing approach to quoting the environment variables in the template file?
Some are quoted, e.g. METRICS and some are not, e.g. TC_AWS_ENDPOINT.

Would you accept a PR "fixing" the broken ones? This is causing me no end of headaches trying to pass environment variables.

https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

Hello, I was hoping there would be a way to use this awesome docker image with The Atlantic's Video engine plugin

https://github.com/theatlantic/thumbor-video-engine

Hi,
running you image in kube cluster, it works great until it doesn't.
not that many request per second. but some of them are gifs. here is my configuration.

- name: STORAGE_EXPIRATION_SECONDS
            value: "60"
          - name: IGNORE_SMART_ERRORS
            value: "True"
          - name: THUMBOR_NUM_PROCESSES
            value: "1"
          - name: ALLOW_UNSAFE_URL
            value: "False"
          - name: SECURITY_KEY
            value: ".........................."

is there a way to let thumbor know what is system maximum memory limit?
because i've set on kube config limit 3Gb but the only thing cluster can do is to recycle pod.
thus i have 25 restarts over night....

i've experienced same problem with mongodb a while ago. the solution was to let mongodb know engine how much memory is the maximum available memory in system. Because apparently it only can fetch cluster memory limit but not the pod limit.

p.s. eventually recycled pod able to handle heavy request without eating that much memory. so it is possible. but i wasn't able to find any memory related env var in thumbor config...

Maybe I missed something, and there are 404 errors like this:

thumbor_stack_nginx-proxy.1.volqnjkijlcs@mg1 | nginx.1 | 2019/06/04 13:13:26 [error] 38#38: *43 open() "/usr/share/nginx/html/1Rm6SK3Eg8_RMcBqf5coRrFAbi0=/28e98d7f8f6727c010152821085cf4c7cd794c4.jpg" failed (2: No such file or directory), client: 10.255.0.2, server: localhost, request: "GET /1Rm6SK3Eg8_RMcBqf5coRrFAbi0=/28e98d7f8f6727c010152821085cf4c7cd794c4.jpg HTTP/1.1", host: "xxx.xxx.cn"

And I use minio as S3 storage for this.

Hi,

Are you planning to support deployment to Kubernetes ?

Thanks

I believe this is the same issue mentioned in the thumb-community/aws repo, however that post looks like it's been collecting dust since 2018

thumbor-community/aws#132

Hoping it might get a bit more traction here. Line numbers and some details are different (as expected) but use case and behavior sound identical.

Use case:

• running with STORAGE set to tc_aws.storages.s3_storage
• not providing credentials, so that boto can load the credentials from EC2 IAM role (https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#iam-role)

Result:

2020-05-05 17:58:22 tornado.application:ERROR Future exception was never retrieved: Traceback (most recent call last):

  File "/usr/local/lib/python2.7/site-packages/tornado/gen.py", line 307, in wrapper

    yielded = next(result)

  File "/usr/local/lib/python2.7/site-packages/thumbor/handlers/imaging.py", line 31, in check_image

    exists = yield gen.maybe_future(self.context.modules.storage.exists(kw['image'][:self.context.config.MAX_ID_LENGTH]))

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 483, in wrapper

    future.result()

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 238, in result

    raise_exc_info(self._exc_info)

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 471, in wrapper

    result = f(*args, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/tc_aws/aws/storage.py", line 109, in exists

    self.storage.get(file_abspath, callback=return_data)

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 483, in wrapper

    future.result()

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 238, in result

    raise_exc_info(self._exc_info)

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 471, in wrapper

    result = f(*args, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/tc_aws/aws/bucket.py", line 71, in get

    Key=self._clean_key(path),

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 170, in call

    callback=callback

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 126, in _make_api_call

    callback=callback

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 117, in _make_request

    callback=callback

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 77, in _send_request

    request = self.endpoint.create_request(request_dict, operation_model)

  File "/usr/local/lib/python2.7/site-packages/botocore/endpoint.py", line 116, in create_request

    operation_name=operation_model.name)

  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 356, in emit

    return self._emitter.emit(aliased_event_name, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 228, in emit

    return self._emit(event_name, kwargs)

  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 211, in _emit

    response = handler(**kwargs)

  File "/usr/local/lib/python2.7/site-packages/botocore/signers.py", line 90, in handler

    return self.sign(operation_name, request)

  File "/usr/local/lib/python2.7/site-packages/botocore/signers.py", line 157, in sign

    auth.add_auth(request)

  File "/usr/local/lib/python2.7/site-packages/botocore/auth.py", line 425, in add_auth

    super(S3SigV4Auth, self).add_auth(request)

  File "/usr/local/lib/python2.7/site-packages/botocore/auth.py", line 357, in add_auth

    raise NoCredentialsError

NoCredentialsError: Unable to locate credentials

2020-05-05 17:58:32 tornado.application:ERROR Future exception was never retrieved: Traceback (most recent call last):

  File "/usr/local/lib/python2.7/site-packages/tornado/gen.py", line 307, in wrapper

    yielded = next(result)

  File "/usr/local/lib/python2.7/site-packages/thumbor/handlers/imaging.py", line 31, in check_image

    exists = yield gen.maybe_future(self.context.modules.storage.exists(kw['image'][:self.context.config.MAX_ID_LENGTH]))

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 483, in wrapper

    future.result()

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 238, in result

    raise_exc_info(self._exc_info)

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 471, in wrapper

    result = f(*args, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/tc_aws/aws/storage.py", line 109, in exists

    self.storage.get(file_abspath, callback=return_data)

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 483, in wrapper

    future.result()

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 238, in result

    raise_exc_info(self._exc_info)

  File "/usr/local/lib/python2.7/site-packages/tornado/concurrent.py", line 471, in wrapper

    result = f(*args, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/tc_aws/aws/bucket.py", line 71, in get

    Key=self._clean_key(path),

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 170, in call

    callback=callback

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 126, in _make_api_call

    callback=callback

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 117, in _make_request

    callback=callback

  File "/usr/local/lib/python2.7/site-packages/tornado_botocore/base.py", line 77, in _send_request

    request = self.endpoint.create_request(request_dict, operation_model)

  File "/usr/local/lib/python2.7/site-packages/botocore/endpoint.py", line 116, in create_request

    operation_name=operation_model.name)

  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 356, in emit

    return self._emitter.emit(aliased_event_name, **kwargs)

  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 228, in emit

    return self._emit(event_name, kwargs)

  File "/usr/local/lib/python2.7/site-packages/botocore/hooks.py", line 211, in _emit

    response = handler(**kwargs)

  File "/usr/local/lib/python2.7/site-packages/botocore/signers.py", line 90, in handler

    return self.sign(operation_name, request)

  File "/usr/local/lib/python2.7/site-packages/botocore/signers.py", line 157, in sign

    auth.add_auth(request)

  File "/usr/local/lib/python2.7/site-packages/botocore/auth.py", line 425, in add_auth

    super(S3SigV4Auth, self).add_auth(request)

  File "/usr/local/lib/python2.7/site-packages/botocore/auth.py", line 357, in add_auth

    raise NoCredentialsError

NoCredentialsError: Unable to locate credentials```

see python-pillow/Pillow#3441 and thumbor/thumbor#1102

wheel-based Pillow versions > 5.0.0 have a performance regression. This affected docker images of this project with tag > 6.4.2

@kkopachev offered a workaround we can implement. (need to consider backporting the 6.5.1 tag, but not sure if there's any important reason to keep using 6.5.1 when 6.5.2 is available)

... because there is an environment setting missing

  - DETECTORS=['thumbor.detectors.face_detector','thumbor.detectors.feature_detector']

such as in the swarm example:

See: https://thumbor.readthedocs.io/en/latest/enabling_detectors.html

Why don't see Location in response header when use fetch but test on postman i see it.

I am using a tag that was derived from the latest commit in the master branch of the project
(commit4c9f8f4), after updating my previous version (which was apsl/thumbor).
I am using lastest Docker version with aws plugin (using S3 Storage), and when running some API calls I get:
POST returns 201 code, although I don't see the image being stored in S3 (worked in previous version)
GET returns 504, (NOT 404, meaning the server finds the image but cannot return it? Maybe connectivity problem?)

I believe the configuration should be fine (regarding connectivity to S3), since both API calls worked in previous version.

Configuration is added:

ALLOW_UNSAFE_URL False
AWS_ACCESS_KEY_ID MY_AWS_ACCESS_KEY
AWS_SECRET_ACCESS_KEY MY_AWS_SECRET_ACCESS_KEY
LOG_LEVEL warn
MAX_AGE 86400
STORAGE tc_aws.storages.s3_storage
TC_AWS_STORAGE_BUCKET MY_BUCKET
TC_AWS_STORAGE_ROOT_PATH path
UPLOAD_DELETE_ALLOWED True
UPLOAD_ENABLED True
UPLOAD_MAX_SIZE 9999999999999999
UPLOAD_PHOTO_STORAGE tc_aws.storages.s3_storage
UPLOAD_PUT_ALLOWED True

Added variables when testing new thumbor version:

RESULT_STORAGE tc_aws.result_storages.s3_storage
LOADER tc_aws.loaders.s3_loader
TC_AWS_LOADER_BUCKET vo-thumbor-bucket
TC_AWS_LOADER_ROOT_PATH path
TC_AWS_MAX_RETRY 5
TC_AWS_RESULT_STORAGE_BUCKET vo-thumbor-bucket
TC_AWS_RESULT_STORAGE_ROOT_PATH path

Any Ideas?
Thanks

It seems that the gifv plugin requires a specific ffmpeg version.

Hi,

I'm trying MinimalCompact/thumbor container with tag 6.7.0 and It seems to me that nginx_proxy uses bad direcotry for webp (auto) images. It uses result_storage/webp but should be result_storage/auto_webp.

vs

https://github.com/thumbor/thumbor/blob/ad8d3813bcd6875b890e43c1c39955d6a47b2c22/thumbor/result_storages/file_storage.py#L101

Hi, could you please upgrade to Thumbor 6.6.0 ?
Thanks.

I was trying this service for a project, and noticed the following:

1. minimalcompact/thumbor worked in the first go. I was able to resize and modify images. However, i wanted the service to be fronted by a NGINX caching layer.

2. I then tried minimalcompact/thumbor-nginx-proxy-cache. The command used was:

sudo docker run -p 8052:80 -v /var/run/docker.sock:/tmp/docker.sock:ro /home/anshul/temp_cache_dir:/var/cache/nginx minimalcompact/thumbor-nginx-proxy-cache

Here, the container starts, and accepts request at 8052, but I get an NGINX 503 Service Unavailable. Any obvious step that I'm missing, maybe?

I'm trying the example image from docs as follows:
localhost:8052/unsafe/400x0/https%3A%2F%2Fgithub.com%2Fthumbor%2Fthumbor%2Fraw%2Fmaster%2Fexample.jpg

and the startup logs are shown below:

Thanks.

We have a production service that uses an image whose parent is apsl/thumbor:6.4.2-simd-avx2.

Recently, we've had issues building this image due to the EOL-ing of Debian jessie.

I noticed that minimalcompact/thumbor:6.4.2-simd-avx2 is already on Debian stretch 👍and we are considering whether to use this as the parent image instead.

I am comparing the single Dockerfile in this project and the multiple Dockerfiles in the apsl project. Could you help me understand the differences (as slight as they may be)?

Hello,

is it somehow possible to easily add additional plugins to thumbor running in this image?

I want to use tc_prometheus but it does not seem to be included.

regards,

Simon

everything looked good at the beginning than everything collapsed.

running container like this:

sudo docker run -p 80:80 -e MAX_AGE=0 -e RESULT_STORAGE='thumbor.result_storages.no_storage' -e STORAGE='thumbor.storages.no_storage' -e STORAGE_EXPIRATION_SECONDS=0 -e IGNORE_SMART_ERRORS='True' -e THUMBOR_NUM_PROCESSES=2 -e ALLOW_UNSAFE_URL='False' -e SECURITY_KEY='{my secret key}' /tmp/docker-data:/data --restart always -d minimalcompact/thumbor

in less than a day /var/lib/docker/overlay2 consumed 11G. Not that many requests, i would say less than 1 request in a second.

was able to reclaim all space only after i've removed container and did docker system prune -a

please let me know if need more info

We use thumbor with image sources that are secured with basic authorisation. Since thumbor doesn't support such option out of the box, we have to use something additionally around it.

Recently I found your suggestion to inject a header in front of thumbor here:
thumbor/thumbor#1100

But since in a package there is nginx-proxy as a frontend proxy, could you extend its functionality with the option to pass a user:password or a hash to be injected in an upstreaming request to thumbor? Then we don't need to set up any additional containers and this option could be useful for some other artisans as well ;)

Using the REDIS_STORAGE_SERVER_PASSWORD and REDIS_QUEUE_SERVER_PASSWORD env variables results in NameError exceptions within thumbor.

I guess this is because they are not quoted in thumbor.conf.tpl?

I overcame this by using REDIS_STORAGE_SERVER_PASSWORD="'mypassword'"

But there is a fatal error with remotecv as no password is able to be passed via https://github.com/MinimalCompact/thumbor/blob/master/remotecv/docker-entrypoint.sh

It is supported though https://github.com/thumbor/remotecv/blob/master/remotecv/worker.py#L76

Hi,

i run it like this:
docker run -p 80:80 -e MAX_AGE=0 -e STORAGE_EXPIRATION_SECONDS=0 -e IGNORE_SMART_ERRORS='True' -e THUMBOR_NUM_PROCESSES=2 -e ALLOW_UNSAFE_URL='False' -e SECURITY_KEY='{my-secret-key-here}' -v /tmp/docker-data:/data --restart always -d minimalcompact/thumbor

folder /tmp/docker-data is getting polluted with files, nothing is removed. So i had to create cron task which drops everything out of there.

if i run it without -v /tmp/docker-data:/data - docker volume takes all available space and host dies.

pretty sure that in original thumbor STORAGE_EXPIRATION_SECONDS=0 - should force it to remove all temp files as soon as they served.

have no need in any kind of cache inside of thumbor because we have multiple caching layers in front of it and thumbor is the last stage.

Please let me know if you need anything else from me.

Thank you for creating this great image!

I recently created some simple tests to cover nginx-proxy caching (#47) using bats-core, and integrated them into the automated build/test/push process on Semaphore 2.0.

Probably makes sense to write a few more tests to cover common scenarios, but not sure exactly what should be tested (it doesn't make sense to duplicate tests that thumbor core is doing, so focus only on the docker images)

root@thumbor-qa-5df6d9845c-54kpg:~# /docker-entrypoint.sh circus
---> Starting thumbor solo...
usage: server.py [-h] [--version] [-p PORT] [-i IP] [-f FD] [-c CONF]
[-k KEYFILE] [-l LOG_LEVEL] [-a APP] [-d]
[--use-environment USE_ENVIRONMENT]
server.py: error: argument -p/--port: invalid int value: 'tcp://100.69.107.104:80'

Some documentation in configuration would be highly appreciated because now it's almost 0 besides installation and the recipes.

Hello guys,

I'm talking about the multiprocessing docker container here.
I checked the memory used by docker container while only running without any processing and it was taking ~400 MB of memory.
My concern is, how much memory should i reserve for the container for running without any problem if i'm aiming more than 1000 requests/sec and assuming images to be of size less than 10 MB?

Thanks

The nginx-proxy image is used for proxying thumbor and primarily for caching (+ easier handling of CORS perhaps). It's built on top of https://github.com/jwilder/nginx-proxy with the caching parts based on APSL's original implementation.

It serves well, but recently I'm having second thoughts if this is the best approach. Reasons:

• many of the recent bugs/fixes were related to it
• partly it's not the "our fault", because thumbor changed how they handle caching, which forced us to use js plugins to calculate the cached image location (thanks to @korneevm! see #19 and #21)
• then there were some left-over bugs related to AUTO_WEBP and Content-Type headers (thanks to @limuhob see #53 #49 and more...)

Those aren't the core issues however in my opinion, but rather a symptom. Why?

The caching is relying on thumbor to store cached images in a results storage folder, and then fetch them if they exist using try_files. This works well, but has some limitations. For example:

• content-type headers are unknown just from looking at the cached file. We essentially "guess" them based on the filename (e.g. if it has ".png" in the filename then it's an image/png), or the filter... But if we serve a file that has no extension and no filter (not very common, but can happen), then we just can't serve the right content-type header
• WEBP again is an edge-case and depends on browser headers + result storage
• there's quite a bit of "code" (nginx configuration) to deal with this. For example calculating the hash of the request via JS to find the cached file, plus all the content-type handling etc
• In order to work, nginx-proxy and thumbor must share the "data" folder where result storage is kept

It feels a bit like re-inventing the wheel here. After all, nginx has built-in proxy caching functionality, so why not rely on it?

I played around with it a bit, and I think it can be a simpler, more elegant and just as performant (or perhaps even more) if we simply use the built-in proxy_cache directives.

Advantages:

• No need to save results storage in thumbor, caching is independent
• caching disk space / retention etc are also independent
• no need to share a volume or "find" the results cache files, nginx takes care of it by itself
• content-type header cached "for free". Nginx "remembers" it as far as I can tell (TODO: check what happens with WEBP, but I imagine it would work)
• less modification to the nginx.tmpl file compared to the base

Disadvantages:

• Need for custom variables for proxy settings (e.g. cache storage size, expiration, etc), or let the users "bring their own" proxy.conf file? (but that won't be very useful)
• breaks backwards-compatibility if we simply change how nginx-proxy works... So maybe introduce a new proxy? then there are two, so which one to pick?? the transition might be tricky... need to think about it

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

Hi there,
I want to migrate from APSL/docker-thumbor image and looking for a way of using instance of thumbor itself, without any additional features such as nginx-proxy-cache etc.. Is this possible to do it with this image without building your own? Tried so far to expose 8888 only but seems to not work.

Thanks in advance

This is branching off of #34 (comment)

If I am going to use thumbor image as a base for my custom thumbor container and add custom thumbor plugin, I need a way to extend configuration.
Current way to do it is to copy original config tpl from the image (or github), edit it and add on build stage or mount in runtime. Problem with it is that I have to always copy fresh config.tpl with every new release and apply my changes to it.
It is time consuming and error prone.

Would be great if there was a way to specify directory from where we can read all tpl files, aggregate them together, apply env vars and generate one final config file.
Or another approach is described in #4 (comment) involves script to output all env variables to config file. There might be problems where some variables are actually python arrays, etc, so not clear how to map string env vars into something like arrays and booleans.

So, I've got nginx-proxy-cache, thumbor and remotecv set up with images only loaded from S3.

As I understand so far, using smart crop will return the image immediately with a basic crop and nginx will not cache the result while remotecv works away.

Upon reload, thumbor will smart crop the image and nginx will cache the result this time.

What if I want to put CloudFront at the top of the stack? It will cache the first unsmart image.

Can I get nginx to pass on the no cache headers from the first request?

Hi, I want to know if the remotecv support tc_aws, such as minio. According to the requiresments, I didn't find the tc_aws related infomation.

Thumbor changed result_storage filename format and files has no longer type extensions (.jpeg, .png). Therefor nxing-proxy returns default content-type application/octet-stream instead of e.g. image/jpg.

I cannot load any pictures from my s3 bucket. I have my aws credentials configured on my machine but it is not working.

Stacktrace
2018-11-12 16:16:47 tornado.application:ERROR Uncaught exception
Traceback (most recent call last):
File "/home/ubuntu/.local/lib/python2.7/site-packages/tornado/http1connection.py", line 238, in _read_message
delegate.finish()
File "/home/ubuntu/.local/lib/python2.7/site-packages/tornado/http1connection.py", line 680, in finish
return self._delegate.finish()
File "/home/ubuntu/.local/lib/python2.7/site-packages/tornado/simple_httpclient.py", line 510, in finish
self.headers["Location"])
File "/home/ubuntu/.local/lib/python2.7/site-packages/tornado/httputil.py", line 229, in getitem
return self._dict[_normalized_headers[name]]
KeyError: 'Location'
2018-11-12 16:16:47 thumbor:ERROR ERROR retrieving image from S3 589142/96ru63491.jpg: {'ResponseMetadata': {'HTTPStatusCode': 599, 'HTTPHeaders': {}}, 'Error': {'Message': '', 'Code': '599'}}
2018-11-12 16:16:47 tornado.access:ERROR 502 GET /unsafe/300x200/589142/96ru63491.jpg (x.x.x.x) 101.27ms

thumbor 6.7.1 switched from the 'raven' to 'sentry-sdk' package. pretty sure the 6.7.5 tag on this image is broken for sentry users

ImportError: No module named sentry_sdk when starting up

#73 jumped straight from 6.7.0 to 6.7.5 without addressing changes.

https://github.com/thumbor/thumbor/releases/tag/6.7.1
https://github.com/thumbor/thumbor/pull/1167/files

I want set response header Access-Control-Allow-Origin on system

Is there any benefits of running circus inside container to be able to run multiple thumbor processes per container?
It's usually easy enough to run more containers with single thumbor in each.
That seems to add some complexity to the config.

I suspect it might help in cases where thumbor has blocking operation happening on main tornado thread and not on thread pool, but that should be identified and fixed in thumbor itself.

Any opinions here?

This repo seems to have a nice collection of optimizer plugins: https://github.com/thumbor/thumbor-plugins

Hello

I am running this container on EKS (Amazon Kubernetes) and it now lets you access credentials via a web token as documented here https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#assume-role-with-web-identity-provider

In order to use it, the python sdk needs to be upgraded to at least a version listed here
https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html

I can't believe no one else hasn't run into this, but I'm failing to find a reference.

Included in docker-compose.yml
PROMETHEUS_SCRAPE_PORT: "8000"

Inclusion of
METRICS: "tc_prometheus.metrics.prometheus_metrics"
in my docker-compose.yml results in metrics being displayed at localhost:8000/metrics, but I also get errors in my logs.

thumbor_1  | Traceback (most recent call last):
thumbor_1  |   File "/usr/local/lib/python2.7/runpy.py", line 174, in _run_module_as_main
thumbor_1  |     "__main__", fname, loader, pkg_name)
thumbor_1  |   File "/usr/local/lib/python2.7/runpy.py", line 72, in _run_code
thumbor_1  |     exec code in run_globals
thumbor_1  |   File "/usr/local/lib/python2.7/site-packages/thumbor/server.py", line 154, in <module>
thumbor_1  |     main(sys.argv[1:])
thumbor_1  |   File "/usr/local/lib/python2.7/site-packages/thumbor/server.py", line 145, in main
thumbor_1  |     with get_context(server_parameters, config, importer) as context:
thumbor_1  |   File "/usr/local/lib/python2.7/site-packages/thumbor/server.py", line 104, in get_context
thumbor_1  |     importer=importer
thumbor_1  |   File "/usr/local/lib/python2.7/site-packages/thumbor/context.py", line 43, in __init__
thumbor_1  |     self.metrics = importer.metrics(config)
thumbor_1  |   File "/usr/local/lib/python2.7/site-packages/tc_prometheus/metrics/prometheus_metrics.py", line 19, in __init__
thumbor_1  |     start_http_server(config.PROMETHEUS_SCRAPE_PORT)
thumbor_1  |   File "/usr/local/lib/python2.7/site-packages/prometheus_client/exposition.py", line 193, in start_http_server
thumbor_1  |     httpd = _ThreadingSimpleServer((addr, port), CustomMetricsHandler)
thumbor_1  |   File "/usr/local/lib/python2.7/SocketServer.py", line 420, in __init__
thumbor_1  |     self.server_bind()
thumbor_1  |   File "/usr/local/lib/python2.7/BaseHTTPServer.py", line 108, in server_bind
thumbor_1  |     SocketServer.TCPServer.server_bind(self)
thumbor_1  |   File "/usr/local/lib/python2.7/SocketServer.py", line 434, in server_bind
thumbor_1  |     self.socket.bind(self.server_address)
thumbor_1  |   File "/usr/local/lib/python2.7/socket.py", line 228, in meth
thumbor_1  |     return getattr(self._sock,name)(*args)
thumbor_1  | socket.error: [Errno 98] Address already in use

Removal of this env var results in localhost:8000/metrics showing "This page isn't working", but in DEBUG mode I can see thumbor metrics

thumbor_1  | 2020-08-20 16:16:31 thumbor:DEBUG METRICS: timing: response.time:1127
thumbor_1  | 2020-08-20 16:16:31 thumbor:DEBUG METRICS: timing: response.time.304:1127
thumbor_1  | 2020-08-20 16:16:31 thumbor:DEBUG METRICS: inc: response.status.304:1
thumbor_1  | 2020-08-20 16:16:31 thumbor:DEBUG METRICS: inc: response.format.webp:1
thumbor_1  | 2020-08-20 16:16:31 thumbor:DEBUG METRICS: timing: response.time.webp:1127
thumbor_1  | 2020-08-20 16:16:31 thumbor:DEBUG METRICS: inc: response.bytes.webp:8942

Has anyone else run into this?

In the standard configuration, Thumbor, inside this Docker image (and probably outside it as well), logs everything to stderr, even if it's not errors.

If you define a log level of info, I would hope and expect that everything up until log level INFO gets logged to stdout, and just WARN and ERROR gets logged to stderr.

When using log aggregation tools, such a configuration would be very convenient. A standard query for such tools (Azure Log Analytics, GrayLog,...) is for example "show the last 100 errors" which is often "polluted" by INFO logs from thumbor.

Thnx a lot for you docker image.
Do you plan upgrade to 6.5.2?

https://github.com/thumbor/thumbor/releases/tag/6.5.2

next change looks great

Support Graceful shutdown on SIGTERM and SIGINT(@Globegitter)

Hello there! Thank you for creating and maintaining this docker image.
I'm working on a webpack loader which uses thumbor to solve the Art Direction problem in websites development.

The loader works fine on linux environments with a local thumbor installation, but I'm trying to add Windows and Mac support and docker seems our best shot to unify the DX. Right now, we are testing the Windows integration.

Unluckily, it seems that using the file loader to work with images into a folder mounted via --mount option isn't working.
Right now I'm manually testing the system before automatizing the process and all I can get are 404 errors.

This is the command I use to launch the container
docker run -p 8888:80 --name ril-thumbor --env-file .thumbor-env --mount type=bind,source="$(pwd)",target=/app/loader,readonly --rm minimalcompact/thumbor

.thumbor-env

LOADER=thumbor.loaders.file_loader
RESULT_STORAGE_EXPIRATION_SECONDS=86400
STORES_CRYPTO_KEY_FOR_EACH_IMAGE=True
LOG_LEVEL=debug
DETECTORS=['thumbor.detectors.face_detector','thumbor.detectors.profile_detector','thumbor.detectors.feature_detector']

I use docker exec -it ril-thumbor bash to enter the container and check what's going on inside.

What works

• The container starts correctly and thumbor starts listening and answering the requests when I hit localhost:8888
• Thumbor configuration, as found into /app/thumbor.conf, seems correct, all options provided via env file are correctly overriden
• The current directory is correctly mounted into /app/loader (which is the default FILE_LOADER_ROOT_PATH) and I can access and read the content of the mounted folder when connected via bash
• If I use a different loader, eg the default http loader, thumbor works as expected

What doesn't work

Any request result in a 404 error, which leads me to think something is wrong with the path (the root path, the one we provide, or both).
We already successfully use thumbor in this way when it's installed locally, the only difference being FILE_LOADER_ROOT_PATH set to /home/ (absolute paths to images are provided except the initial /home/ part).

What URLs I tried, by accessing them via Chrome browser:

• http://localhost:8888/unsafe/500x150/smart/src/assets/images/my-image.jpg: this should be the correct one, AFAIK
• http://localhost:8888/unsafe/500x150/smart/my-image.jpg: we moved the image into /app/loader to check if the problem was about the path slashes, still 404, seems that's not the problem
• http://localhost:8888/unsafe/500x150/smart/app/loader/src/assets/images/my-image.jpg: random guess
• http://localhost:8888/unsafe/500x150/smart/loader/src/assets/images/my-image.jpg: random guess
• http://localhost:8888/unsafe/500x150/src/assets/images/my-image.jpg: random guess
• http://localhost:8888/unsafe/500x150//src/assets/images/my-image.jpg: strange random guess

Thumbor isn't providing any useful info even with debug log level, especially I cannot find a way to make thumbor tell me where it's actually searching the image, so I'm just going on blindly.

Thumbor log with DEBUG level

2020-08-04 07:02:45 thumbor:DEBUG METRICS: inc: response.count:1
2020-08-04 07:02:45 thumbor:DEBUG METRICS: inc: storage.miss:1
2020-08-04 07:02:45 tornado.access:WARNING 404 GET /unsafe/500x150/smart/src/assets/images/my-image.jpg (172.17.0.1) 3.21ms
2020-08-04 07:02:45 thumbor:DEBUG METRICS: timing: response.time:2
2020-08-04 07:02:45 thumbor:DEBUG METRICS: timing: response.time.404:2
2020-08-04 07:02:45 thumbor:DEBUG METRICS: inc: response.status.404:1

Other possible causes:

• there is some obscure option of thumbor configuration which is set by default on the docker image which isn't set into a normal thumbor installation
• the bind mount from a Windows host cause some esoteric path conflicts which I'm not aware of (even if I thought Docker main job was to avoid these problems)

Does this ring any bell to you? Have you run into something like this in the past?

I am really new to docker and I could not find anything about variables on your setup instructions.
Can you please link me to the right place to find out the variables that this docker accepts?

Thanks!