NYPL's implementation of the Cantaloupe IIIF image server. It is configured to read source images from S3.

This uses Docker to locally to make it as easy as possible for developers to install.

1. cp .env.example .env (and fill in .env with credentials)
2. Optional: To work locally on the shim, edit nginx-configs/image_server_to_iiif.js and comment out line 54 and comment in line 58. (NB: Make sure to revert these changes for deployment.)
3. docker-compose build
4. docker-compose up
5. Test in a browser: http://localhost:8182/iiif/3/53926/full/max/0/default.jpg
6. Test shim in a browser: http://localhost:8080/index.php?id=53926&t=f

This branch looks for source images in the ./images directory, which is mounted in the container at /var/www/images.nypl.org.

Source and derivative images are cached in ./cache, which is mounted into the container at /ifs/prod/iiif-imagecache.

You can download images from the production repo and put them into ./repo using the correct directory structure. If you then connect your local canteloupe instance to the qa filestore, as long as the added images exist in that database, the local shim should be able to serve them. This is useful for testing images that don't render.

• Update nginx-configs/image_server_to_iiif.js for local shim use as mentioned above.
• Configure DB_URL, DB_UNAME, and DB_PASS in .env to connect to the qa or production filestore database
• Download an image from the production image repo to your local.
• Note the image's filepath as you're doing this. You can also find the path by attempting to render the image using the shim locally as long as you're connected to a remote filestore database from local. The filepath will be in the stack trace shown in the browser.
• Create the image's filepath directory in your local repo folder with mkdir -p <path_without_filename> (for example: mkdir -p /B1/B116/AD22/0697/11E2/9D4C/8488/957D/67). Then, copy the downloaded image into the created directory.
• Rebuild your containers and run them. You should now be able to use the local shim to view the downloaded image.

• Install jruby on your local (homebrew is fine on mac)
• Do jruby test/<test_file_name> to run tests

Our branches (in order or stability are):

1. Feature branches are cut from develop.
2. Once the feature branch is ready to be merged, file a pull request of the branch into develop.
3. Branches are "promoted" by merging from less stable to more. (develop -> qa -> production )
4. Always make sure to revert to deployment settings in the secrets.rb before commiting changes to deploy.

We use Bamboo for deployments. The canteloupe.properties.dev config file is applied for qa deployments, and the canteloupe.properties.prod config file is applied for production deployments. The previous properties file on the server is moved to canteloupe.properties.old.

The deployed servers do not run in docker, so the deploy scripts (configured in bamboo) are responsible for repeating the steps in the dockerfile to configure and deploy the new server and restart the service. Each server instance is updated in sequence prevent service downtime.