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

Dynamic cantaloupe sidecar. #8

Draft
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

robertkeizer
Copy link
Collaborator

This relates to the following PRs:

Effectively this sets up the cantaloupe system as a sidecar to the iiif python flask app.

@digitaldogsbody
Copy link
Collaborator

Copying over a couple of comments from Slack just so they are here as well:

Since this is now a sidecar, I'm assuming the ENV variable that gets set is using an IP? I've checked out the behavior of the code locally using netcat to stand in for Cantaloupe and it looks ok, but we are presented with an issue for running the container locally.

Spinning up a local development copy using the PR branch, but using the DNS name cantaloupe.prod.archive.org in the ENV variable gives the "no configured resolver" error as described in #5, and using the IP doesn't work due to the missing Host header required by the load balancer (seen in #2).

It would be good to come up with a way that the container can also be run locally. One immediate idea that springs to mind is adding another line to the start.sh that, based on a second ENV variable, could add the resolver x.y.z.a; line to the nginx config, which in conjunction with passing the DNS name of the cantaloupe server in the existing ENV should be enough.

@digitaldogsbody
Copy link
Collaborator

One other thing I've noticed - there are various headers that need to be set in order for Cantaloupe to produce the correct id values in its info.json responses:

        # Settings to ensure Cantaloupe creates the right ids
        # https://cantaloupe-project.github.io/manual/5.0/deployment.html#Reverse-Proxying
        proxy_set_header X-Forwarded-Host iiif.archive.org;
        proxy_set_header X-Forwarded-Path /image;
        proxy_set_header X-Forwarded-For $remote_addr;

X-Forwarded-For is really just for logging so it's not strictly required, but the other two are.

With X-Forwarded-Host we might be able to do some magic with so that it works with the inbound request domain, which would make things a bit easier for testing in various locations against the same target server.

X-Forwarded-Path is required because the reverse proxy is sitting at /iiif/image and Cantaloupe is just at /iiif, so without this the returned ids will come back missing the /image part (see https://www-iiif.dev.archive.org/iiif/image/3/0-0-1%2F0_0%20(1).png/info.json)

@glenrobson
Copy link
Collaborator

Leaving this open but in the 14th Sept catch up we discussed closing this after merging the post-meeting-fixes branch as this should have all of the changes in. If we check once this is merged we will see if there is anything we missed.

@digitaldogsbody
Copy link
Collaborator

I've checked through this and I'm pretty confident that everything we needed from here is now in main through other PRs.

There are a couple of things we might want to pull out:

  • Rob's addition to README.md explaining the Nomad deployment
  • The .gitlab-ci.yml, which might be needed when the code is pulled through to IA's internal git infrastructure
  • The settings.cfg file which is used for template substitution of the Cantaloupe address in start.sh to make the deployed config file that lives in iiify/config/

@robertkeizer any pointers for the last two?

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.

3 participants