Forum Discussion

boneyard's avatar
boneyard
Icon for MVP rankMVP
Mar 17, 2014

irule development - fixed variables within iRule context

looking for some input how others are handling such a situation.

 

with irule development you are often working with at least two irules in a certain environment (single bigip). of course multiple environments (dev, test, prod) is better but not always possible.

 

so i have:

 

  • irule (attached to most virtual servers)

     

  • irule-new (attached to a single "test" virtual server)

     

what i like is to have irule code which can be copied without any changes from irule-new to irule as the method "to put it into production".

 

this of course causes issues when you have differences between the old and new environment surrounding the bigip. for example a new header, are different URI, .... another thing are "fixed" variables you use per irule, a debug level, a path, a pool. so variables you want to set once and then use through the whole irule.

 

you can use static variables but these have a bigip wide effect, so that cant be used to have difference on iRule level. different static variables for the current and new irule are possible, but that means changing the irule code when moving to another irule.

 

datagroups are an option, but those are also bigip wide. in some cases i use datagroups with a variable per host, but that doesnt scale very well.

 

so how do you keep your variables within a single iRule context?

 

application delivery
design
devops
fixed
irule
iRules
variable
  • boneyard's avatar
    boneyard
    Icon for MVP rankMVP
    Mar 21, 2014

    thanks to the both of you, good ideas.

     

    anyone got anything else up their sleeve? or is this pretty much the way to go?

     

  • cdougall_14195's avatar
    cdougall_14195
    Icon for Cirrus rankCirrus
    Mar 18, 2014

    So here's the way that we use a shared iRule for whole subset of VIPs. This uses the Virtual name that the client connected to in order to identify a specific Data group with a matching (almost matching, a few mods) name.

    set vsname [string trimright [join [lreplace [split [getfield [split [virtual name]] / [llength [split [virtual name] /] ] ] -] end end ""] -] -]
set dgnameTmp "[string trimright [string range [virtual name] 0 [string last - [virtual name]]] "-"]"
set dgname [append dgnameTmp "-DG"]
if {$static::log_debug}{
    log local0. "Data Group Tmp Name is: $dgnameTmp"  
    log local0. "Data Group Name is: $dgname"  
}

    Long and short, if you Virtual was named "this-is-a-foo-house-80" your datagroup name would be "this-is-a-foo-house-DG". That way you can set any variables you want for that specific instance right there.

  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Mar 17, 2014

    Hi Boneyard - we have 2 production sites and a single test site. Within the test site (on a single test F5) we run 4 test streams called fn1-fn4. Having a consistent naming standard for LTM units and for virtual servers has been very useful. I use CLIENT_ACCEPTED to set variables. I use switch statements to determine environments, which means that, technically, it's not the most efficient method, however like you, I want a single piece of code to move between environments, and I see the sacrifice of a few CPU cycles as worth it. Obviously an alternative would be to have a separate CLIENT_ACCEPTED iRule per environment....;-

     

    when CLIENT_ACCEPTED {
     Switch on the device name - this tells us whether we are in test or prod
    switch -glob [info hostname] {
    "xxx*" -
    "yyy*" {
         This is a prod site
        set debug 0
        set dg_name "dg_ip_classification"
    }
    default {
         We're in test - determine testing stream
        switch -glob [virtual] {
            "*fn1" {
                set debug 0
                set dg_name "dg_ip_classification_fn1"
            }
            "*fn2" {
                set debug 0
                set dg_name "dg_ip_classification_fn2"
            }
            "*fn3" {
                set debug 0
                set dg_name "dg_ip_classification_fn3"
            }
            "*fn4" {
                set debug 0
                set dg_name "dg_ip_classification_fn4"
            }
        }
    }
    }
}