Answers: <p>James, you are correct in that BIG-IQ replaced Enterprise Manager. However, like Enterprise Manager, BIG-IQ is for 'device/feature' management. For integrating via REST APIs directly, or  to 3rd party automation tools/tool-chains, you should look at F5 iWorkflow (programmable/extensible API gateway).</p>
  
  <p>The team behind iWorkflow are focussed on 'services templates' and 'service catalogs'. These being great ways to rapidly create 'declarative interfaces' that you can hit with single REST calls, versus calling hundreds of 'imperative interfaces' (individual REST end-points) to perform the same task.</p>
  
  <p>Moving to a declarative model will save you from MANY headaches in the future, and will better support automation, and integration with CI/CD pipe-lines. The LAST thing you want is to move all the nuances of your infrastructure into the automation pipe-line itself!! Abstraction through declarative interface will protect you from that pit of despair.</p>
  
  <p>With REST+declarative interfaces, you have a much simpler Infrastructure as Code model in that you are only maintaining JSON blobs for the service templates, and not monolithic configuration files. Double-WIN!</p>
  
  <p>Take a look at calling iApps (F5 services templates) from the REST API. Here's a free on-line training course:</p>
  
  <p><a href="http://f5-automation-labs.readthedocs.io/en/latest/" rel="nofollow noreferrer">http://f5-automation-labs.readthedocs.io/en/latest/</a></p>
  
  <p>Chase = Correct! REST all the way!</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-07-05T15:26:14.263Z
Answers: 2017-07-05T15:26:14.263Z
Answers: Nathan Pearce
Answers: <p>Yes, F5's do support Configuration as Code. Historically, F5 has made an appliance to manage Configuration as Code called "Enterprise Manager" which pragmatically managed client endpoint F5s (LTMs, etc) using the iControl XML API. </p>
  
  <p>They rather quickly discovered this management appliance was terrible and added a more robust REST API to the client appliances for managing devices (LTMs, etc.; also branded as iControl) which is much easier to use and more flexible and then began building a replacement for the Enterprise Manager branded BIG-IQ.</p>
  
  <p>The point being, you can manage that same API using this REST interface. See their tutorial on <a href="https://devcentral.f5.com/wiki/iControlrest.HomePage.ashx" rel="noreferrer">DevCentral</a>. Usually, you can find the exact REST syntax and calls on the DevCentral site on a per-version basis like this one for <a href="https://devcentral.f5.com/d/icontrol-rest-api-user-guide-version-1210" rel="noreferrer">TMOS 12.1.0</a>.</p>
  
  <p>Generally speaking, it is NOT recommended that you use an SCF (Single Configuration File) pretty much ever for a couple of reasons. First, it lacks any supporting files, such as certificates and keys for your SSL profiles or scripted (so-called "external" health monitors), etc. Secondly, it plays poorly if  you use partitioning, as partitions are spread over several files in a foldered structure. These don't consolidate well into an SCF file. You would actually be better off to write TMOS scripts. One of the reasons F5 switched from the bigpipe command to the TMOS shell is that it could be scripted where bigpipe could not be easily scripted. But again, the REST API is preferred. SCFs are really a legacy of version 9 of TMOS and haven't aged well and work poorly in version 12. A significant reason for this is due to the changes in the HA peering between V10 and V11 when they changed to a clustered architecture. It really wreaked havoc on the usability of the SCFs. </p>
  
  <p>Puppet actually has a <a href="https://forge.puppet.com/puppetlabs/f5" rel="noreferrer">module</a> for managing F5s if you use this configuration management tool and salt has a <a href="https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html" rel="noreferrer">runner</a> for it - both using the REST API if you use either of these configuration management tools.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-25T19:26:53.100Z
Answers: Ansible also has [a series of modules](https://docs.ansible.com/ansible/list_of_network_modules.html#f5) for configuring F5s.
Answers: Xiong Chiamiov
Answers: CC BY-SA 3.0
Answers: 2017-06-26T15:54:29.980Z
Answers: J. Doe;  James hit the nail on the head.  REST is the way to go for the programmability and Xiong is also correct for automation tools.  We (F5 employee here) have a git repository that has quite a bit of these tools you'll be looking for (Kubernetes, Ansible, Python....).  Check it all out and if you have questions feel free to contact me here or the DevCentral web site (F5's Developer Community).
Answers: Chase
Answers: CC BY-SA 3.0
Answers: 2017-06-24T22:06:05.220Z
Answers: 2017-06-24T22:06:05.220Z
Answers: James Shewey
Body: <p>Using CasC with F5 would allow for versioned and optionally dynamic network endpoint configuration, saving time and reducing risks.</p>
  
  <p>Does this tool support this? Are Single Configuration Files (SCF, F5 term) the vehicle to do that?</p>
  
Tags: <configuration-management><load-balance><f5>
Title: Does load balancer F5 support CasC (Configuration as Code)?
UserDisplayName: Ta Mu
ThreadText: # Does load balancer F5 support CasC (Configuration as Code)?
  
  (Asked by: username_0 on 2017-06-24)
  
  Using CasC with F5 would allow for versioned and optionally dynamic network endpoint configuration, saving time and reducing risks.
  
  Does this tool support this? Are Single Configuration Files (SCF, F5 term) the vehicle to do that?
  
  **Tags:** configuration-management, load-balance, f5
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-06-24. Score: 11 | Accepted answer
  
  Yes, F5's do support Configuration as Code. Historically, F5 has made an appliance to manage Configuration as Code called "Enterprise Manager" which pragmatically managed client endpoint F5s (LTMs, etc) using the iControl XML API.
  
  They rather quickly discovered this management appliance was terrible and added a more robust REST API to the client appliances for managing devices (LTMs, etc.; also branded as iControl) which is much easier to use and more flexible and then began building a replacement for the Enterprise Manager branded BIG-IQ.
  
  The point being, you can manage that same API using this REST interface. See their tutorial on [DevCentral](https://devcentral.f5.com/wiki/iControlrest.HomePage.ashx). Usually, you can find the exact REST syntax and calls on the DevCentral site on a per-version basis like this one for [TMOS 12.1.0](https://devcentral.f5.com/d/icontrol-rest-api-user-guide-version-1210).
  
  Generally speaking, it is NOT recommended that you use an SCF (Single Configuration File) pretty much ever for a couple of reasons. First, it lacks any supporting files, such as certificates and keys for your SSL profiles or scripted (so-called "external" health monitors), etc. Secondly, it plays poorly if you use partitioning, as partitions are spread over several files in a foldered structure. These don't consolidate well into an SCF file. You would actually be better off to write TMOS scripts. One of the reasons F5 switched from the bigpipe command to the TMOS shell is that it could be scripted where bigpipe could not be easily scripted. But again, the REST API is preferred. SCFs are really a legacy of version 9 of TMOS and haven't aged well and work poorly in version 12. A significant reason for this is due to the changes in the HA peering between V10 and V11 when they changed to a clustered architecture. It really wreaked havoc on the usability of the SCFs.
  
  Puppet actually has a [module](https://forge.puppet.com/puppetlabs/f5) for managing F5s if you use this configuration management tool and salt has a [runner](https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html) for it - both using the REST API if you use either of these configuration management tools.
  
  > **Comments:**
  > **username_3**: Ansible also has [a series of modules](https://docs.ansible.com/ansible/list_of_network_modules.html#f5) for configuring F5s.  
  > **username_4**: J. Doe;  username_2 hit the nail on the head.  REST is the way to go for the programmability and username_3 is also correct for automation tools.  We (F5 employee here) have a git repository that has quite a bit of these tools you'll be looking for (Kubernetes, Ansible, Python....).  Check it all out and if you have questions feel free to contact me here or the DevCentral web site (F5's Developer Community).  
  
  ---
  
  ### Answer by username_1 on 2017-07-05. Score: 4
  
  username_2, you are correct in that BIG-IQ replaced Enterprise Manager. However, like Enterprise Manager, BIG-IQ is for 'device/feature' management. For integrating via REST APIs directly, or to 3rd party automation tools/tool-chains, you should look at F5 iWorkflow (programmable/extensible API gateway).
  
  The team behind iWorkflow are focussed on 'services templates' and 'service catalogs'. These being great ways to rapidly create 'declarative interfaces' that you can hit with single REST calls, versus calling hundreds of 'imperative interfaces' (individual REST end-points) to perform the same task.
  
  Moving to a declarative model will save you from MANY headaches in the future, and will better support automation, and integration with CI/CD pipe-lines. The LAST thing you want is to move all the nuances of your infrastructure into the automation pipe-line itself!! Abstraction through declarative interface will protect you from that pit of despair.
  
  With REST+declarative interfaces, you have a much simpler Infrastructure as Code model in that you are only maintaining JSON blobs for the service templates, and not monolithic configuration files. Double-WIN!
  
  Take a look at calling iApps (F5 services templates) from the REST API. Here's a free on-line training course:
  
  <http://f5-automation-labs.readthedocs.io/en/latest/>
  
  username_4 = Correct! REST all the way!
  
  
  ---
  
  