iRule design considerations for ISA to BigIP migration.
I hope I'm not out of line posting this here. My apologies if I am. My goal is to get some advice/guidance from the community.
I've recently been asked to assist with a project to migrate an old Microsoft ISA fronted environment into our strategic BigIP environment for the purposes of SSL termination and application routing.
From what I've seen so far in a horrendously long XML output from the ISA boxes, there appear to be over 200 URI translations which have no discernable pattern and are unique to each other.
The public URI /abc translates to /xyz at the application
The public URI /123 translates to /789 at the application
Repeat the above for 200+ unique endpoints and you can see what I'm dealing with. Easily adding new endpoints and removing old ones is also key. This will be performed across a cluster of BigIPs which are standalone units.
This cluster also performs an ASM function so the HTTP class feature will be used as an ASM policy will be applied to each endpoint. My preference is to have a single ASM policy for all the applications (in this instance anyway) but I suspect there may a requirement to break this out in the future (phase2).
Thankfully, there aren't all that many application servers (about a dozen pools from what I can see). As I am working on the basis that a single ASM policy will be required, my thought is to group the application URI's based on their final pool destinations, which should leave me with about 6 HTTP classes in total.
So my topic for possible discussion is how would one consider tackling the above external to internal URI mapping with iRules without it becoming a beast of an iRule and whilst remaining easily maintainable? I'm not a TCL coder (or any coder for that fact) and rather than re-invent the wheel, have sought guidance from the community of experts.
The platforms I'm working on are 8400 BigIP LTMs licensed with ASM and running 10.2.0 HF2.