Deploying Drupal 7 with read-only DocumentRoot, especially concerning image handling

Question

I'm deploying a Drupal 7 application in an environment where the web server's DocumentRoot is mounted read-only (so Drupals root directories and all directories below are not writable). For storing files a separate directory outside of DocumentRoot is provided which is mounted read/write. This directory is accessible from a separate web server instance (which only serves static files without executing PHP code, e.g. static.example.com).

What I did:

• setting file_public_path to said writabke directory
• implementing hook_file_url_alter to modify URIs in the public scheme to point to the separate web server instance

Everything seems to work fine (CSS, ...), except for delivering images. Drupal's concept for delivering images is whenever a requested image resolution isn't found on disk, the thumbnailing mechanism is invoked instead. The thumbnailer creates a new image, which is delivered to the requesting browser and stored below sites/default/files. Subsequent requests deliver the image directly from the disk (using Apache's rewrite rules, so PHP isn't involved any more).

Since we are using varnish in front of the web server, I'd prefer a different way of handling images:

• images are served from a different virtual host (e.g. image.example.com)
• thumbnailed images are never written to disk
• instead a Cache-Control header is sent using a reasonable long max-age value, so varnish's LRU expiration mechanism can keep the often used images in memory and discard unused images

Any ideas how to accomplish this?

Answer 1

When an generated image is not available, the page callback is image_style_deliver(). This callback first generate the image (after some access and concurrency checks) and then stream the file as response (through the file_transfer() function).

Using hook_menu_alter(), you can override the image generation callback to redirect to the static domain once the image has been generated. Ensuring the generated files are always served from the static domain. On the static server, you can add a rewrite rule to redirect request for a not yet generated image to the non-static domain. Ensuring the files are generated, even when requested from the static domain. Because of the redirections, Varnish should be able to cache the files as soon as they have been generated.

Edit: Not creating the image derivatives as files on disk does not seems to be an option. Drupal uses its Image Toolkits wrapper API (GD and ImageMagik are usually used a backend) to generate the image and this API does not seems to offer a way to generate images in memory. If you really want/need to remove the generated files, you can do it in a cron job using image_style_flush() via hook_cron().

Answer 2

A response of sorts:

1.~images are served from a different virtual host (e.g. image.example.com)

You can use NFS to mount Drupal's sites/default/files directory to an images.example.com document root, or perhaps an equivalent network directory mount method for your OS.

2.~thumbnailed images are never written to disk

I don't know if that is possible in Drupal, maybe you can override the file stream wrapper handler, so that relevant file operations are handled differently.

3.~instead a Cache-Control header is sent using a reasonable long max-age value, so varnish's LRU expiration mechanism can keep the often used images in memory and discard unused images

The virtual definition host for images.example.com can set the relevant response headers for Varnish to cache those images.