Dear list, I'd appreciate your wisdom. My company uses a 2-tier web architecture for those parts of the website that are dynamic:
* Presentation (pres.) server (in our parlance the "frontend" server) - responsible for content generation. * API server (in our parlance the "backend" server) - performs business logic, supplies business objects to the presentation server, handles AJAX requests directly. We wish to implement a means of deploying new code (pres. and API versions that have been tested together, referred to as logical versions 'X' and 'Y') to a subset of a group servers balanced by a single haproxy instance. We will then measure the live performance of the new vs old code before completing the deployment or rolling back. In summary: * There should be user affinity to pres. version 'X' or 'Y'. * An API request from the browser with affinity to pres. 'X' should ideally go to an API server running 'X', falling back to any available version. Ditto 'Y'. * An API request from a pres server running version 'X' should ideally go to an API server running 'X', falling back to any available version. Ditto 'Y'. We have implemented this as follows: * Browser <-> server affinity managed using a cookie inserted by haproxy * Server <-> server affinity managed an http header set by the pres. server indicating preferred API server version. The config representing the above is https://gist.github.com/f7075d6fb1b5d00ddf52: Note that this represents the configuration in the old vs new state, the configuration for each step of the release process is templated. Does this solution (which works in the lab) seem sane and has it avoided re-inventing any wheels? Thanks, Ben Tisdall.
