iWorkflow 201 (episode #02) - Deploying a services template via the iControl REST API [End of Life]
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. In iWorkflow 101 (episode #03) - Deploying a services template via the Tenant GUI we deployed an L4 - L7 Service onto a BIG-IP device via the iWorkflow Tenant web interface. In that episode we logged into the iWorkflow platform as an Administrator and setup a BIG-IP Connector, created a Tenant, and added an L4 - l7 Service Template to the Tenant Catalog. We then logged in to the iWorkflow Platform GUI as a Tenant and deployed L4 - L7 Service via the Tenant catalog. Oh the fun we had! Well, in this episode we will perform the Tenant deployment via the iControl REST API. The lab environment For this episode we will be communicating with “iworkflow1.n8lab.local” on “10.128.1.130". Communication with the iWorkflow REST API with be performed using the Google Chrome app, POSTMAN. For more details on using POSTMAN to communicate with the REST API please review the previous episode:iWorkflow 201 (episode #01) - Introducing the iControl REST API. Understanding iWorkflow Roles: the Provider/Tenant model Before we execute any more commands, its time for a quick refresh on iWorkflow’s Provider/Tenant model. In iWorkflow 101 (episode #03) - Deploying a service template via the Tenant GUIwe split the article into two parts. Part 1 was performed by using iWorkflow administrator credentials and in that part we configured the platform by adding connectors, templates, catalog’s, users, etc. These steps made the platform ready for service deployments. Next, covered in Part 2 of the article, we logged in using iWorkflow Tenant credentials and deployed an L4 - L7 Service. An Administrator cannot deploy an application delivery policy onto a BIG-IP and a Tenant cannot modify the operation or integration of the iWorkflow platform. These roles apply just the same via the REST API as they do in the GUI. For this episode, iworkflow1.n8lab.local has two users on it: 1) the default ‘admin’ account, which is an iWorkflow Administrator role, and 2) the 'User1'Tenant account wecreated back iniWorkflow 101 (episode #2) - Install and Setup. To review the differing behavior of these roles lets first perform a GET request to the following REST collection as an administrator role: https://ip_address/mgmt/shared/resolver/device-groups/cm-cloud-managed-devices/devices You’ll receive a list of devices including the members of the iWorkflow cluster and the bigip.n8lab.local depicted in the diagram at the start of the article. Now, perform the same transaction after changing the user credentials from “admin" to “User1”: Execute the command again. You will receive an error like the following: The Tenant doesn’t have permission to access ALL of the iWorkflow resources. This is by design. iWorkflow provides highly-granular, per-Tenantaccess control. While we will go through the iWorkflow role-based access control (RBAC) in detail in a future episode, it is important to understand that a Provider/Tenant model is in play and that it applies to the iWorkflow REST API just as it does to the iWorkflow GUI. While there are a few minor exceptions to this rule, the default access policy applied to a User account is inherited from the iWorkflow Tenant(s) that the User has been granted access. Note in the diagram above that access is specific to the Tenant name and its child sub-collections and resource. For example, in the diagram above, the resources all start with: /mgmt/cm/cloud/tenants/MyTenant/ Anywho, more on RBAC in a different episode! So, how does a Tenant view its available resources? Take a look at the iWorkflow Connectors:https://10.128.1.130/mgmt/cm/cloud/tenants/MyTenant/connectors As discussed in iWorkflow 101 (episode #1) - The Architecture Explainedthe iWorkflow connectors are the conduits to BIG-IP resources, in addition to third-party environments like Cisco ACI and VMware NSX. The connectors are created by iWorkflow Administrators under the ‘Clouds’ tab and are then associated with iWorkflow Tenants. In this environment we have only a ‘Local’ BIG-IP connector. You may be asking why the Tenant cannot list the BIG-IP devices in their connector. This is because the Tenants job is to deploy L4 - L7 Services, which are pushed to the available BIG-IP’s. The Tenant doesn’t manage the BIG-IPs. Put another way, this is not a BIG-IP/device centric perspective and such enables a simpler self-service model. With the iWorkflow Tenant/Provider model refresh out of the way lets get back to deploying an L4 - L7 Service via REST. Token Auth & Some POSTMAN Pro-tips We introduced the POSTMAN tool in the last episode. POSTMAN isn’t the only tool that can communicate with iWorkflow. You can take any of these examples and perform them via scripting languages or directly from 3rd party orchestration tools. I use POSTMAN to show examples while remaining both scripting language and orchestration tool agnostic. In the following video we will explain POSTMAN collections and environment variables. To show how these work we will walk through the exercise of using iWorkflow Auth Tokens so you no longer need to send your credentials back and for the across the network for every request. So, sit back and learn how to use iWorkflow Auth Tokens while also learning how to be really efficient with POSTMAN. NOTE: If you’re trying these exercises out in a lab then, like me, you are probably using self-signed SSL certificates on your iWorkflow platform. POSTMAN doesn’t handle these as gracefully as a web browser so you might want to take a look at this (instructions for Mac, Windows, and Linux):http://blog.getpostman.com/2014/01/28/using-self-signed-certificates-with-postman/ Review: The iWorkflow REST API calls made in this video (using the environment variables for “iWorkflow_Mgmt_IP" and “iWorkflow1_Auth_Token”) were: https://{{iWorkflow_Mgmt_IP}}/mgmt/shared/authn/login https://{{iWorkflow_Mgmt_IP}}/mgmt/shared/authz/tokens/{{iWorkflow1_Auth_Token}} https://{{iWorkflow_Mgmt_IP}}/mgmt/cm/cloud/tenants Links referenced in this video: The “F5_iWorkflow_REST_Commands” GitHub repository can be found here:https://github.com/npearce/F5_iWorkflow_REST_API_Commands The RAW files that were imported from GitHub in the video above are here (you can import these yourself): The POSTMAN environment:https://raw.githubusercontent.com/npearce/F5_iWorkflow_REST_API_Commands/master/iWorkflow%20Lab.postman_environment.json The Auth Token POSTMAN Collection:https://raw.githubusercontent.com/npearce/F5_iWorkflow_REST_API_Commands/master/F5%20iWorkflow%20REST%20API%20-%20Auth%20Tokens.postman_collection.json Pre-launch check-list We’re using the same n8lab.local environment (see diagram at the top) that starred in previous episodes. Within n8lab.local we’ve already discovered a BIG-IP device, created a local BIG-IP Cloud connector, and an iWorkflow Tenant. That’s the ‘administrator’ role tasks taken care of (FYI: those administrator tasks can also be performed via REST). So, lets now perform the Tenant L4 - L7 Service deployment via the iWorkflow REST API! Step #1: The iWorkflow Tenant REST perspective Lest take a walk through the iWorkflow objects via the REST API. There are some small exceptions to this rule but, MOST of the Tenant activity happens below the Tenant assigned REST collection. In this lab, that refers to child resources and sub-collections of: https://{{iWorkflow_Mgmt_IP}}/mgmt/cm/cloud/tenants/myTenant1/ NOTE: Before we go making any transactions remember, if you’ve downloaded the POST collection from Github, make sure the current Auth Token is for the “User1” credentials and not the “admin” user. Refer to the diagram below: You’ll see after the credentials change that if you try and run “List Tenants” in the Auth Token POSTMAN collection it will fail. The Tenant User is not permitted to see all the tenants. Hence, calling this /mgmt/cm/cloud/tenants REST collection will report a 401 Unauthorized error. However, if you reference a specific REST collection that the Tenant User is assigned to, you will receive happy data. Using the ‘User1’ Auth Token, lets call "/mgmt/cm/cloud/tenants/myTenant1" List the L4 - L7 Services deployed by this Tenant: “/mgmt/cm/cloud/tenants/myTenant1/services/iapp/" Step #2: Review the resources In the iWorkflow 101 series we’ve already established that “User1" has been associated with “myTenant1” (an iWorkflow Tenant is a collection of resources that facilitates service deployments). We saw that myTenant1 has a local BIG-IP connector, and an L4 - L7 ServiceCatalog that contains the L4 - L7 Service Template “f5.http_ServiceTypeA”. We’ve looked at these resources via the GUI so now we can take a look at them via the REST API. In the video below we take a look at the resources available to “User1” in the following order: The Roles this user has been granted:/mgmt/shared/authz/roles The connectors associated with myTenant1: “/mgmt/cm/cloud/tenants/myTenant1/connectors" There servers deployed through myTenant1 (both Virtual's and Pool members): “/mgmt/cm/cloud/tenants/myTenant1/virtual-servers/" The L4 - L7 Service Templates available to User1 through its Tenant assignments (we only have one Tenant in this lab):/mgmt/cm/cloud/tenant/templates/iapp/ The L4 - L7 Services that have been deployed already using the myTenant1 service templates:/mgmt/cm/cloud/tenants/myTenant1/services/iapp/ Having familiarized ourselves with the various iWorkflow objects we used in the 101 series, we may now deploy an L4 - L7 Service via the iWorkflow REST API. Step #3: Deploying an L4 - L7 Service Time to hit the Go button. As per the video below, to deploy an L4 - L7 Service, we POST to to the Tenant resource (.../myTenant/services/iapp). For example, to deploy using the“f5.http_ServiceTypeA” service templates, which is in the “myTenant1” service catalog, we would execute a POST with a JSON payload as follows: POSThttps://{{iWorkflow1_Mgmt_IP}}/mgmt/cm/cloud/tenants/myTenant1/services/iapp { "name":"myTestDeployment", "tenantTemplateReference":{ "link":"https://localhost/mgmt/cm/cloud/tenant/templates/iapp/f5.http_ServiceTypeA" }, "properties":[ { "id":"cloudConnectorReference", "value":"https://localhost/mgmt/cm/cloud/connectors/local/bea388b8-46f8-4363-9f89-d8920ea8931f" } ], "tables":[ { "name":"pool__hosts", "columns":["name"], "rows":[["acme.com"]] }, { "name":"pool__members", "columns":["addr", "port"], "rows":[ ["10.128.20.1", "8080"], ["10.128.20.2", "8080"] ] } ], "vars":[ { "name":"pool__addr", "value":"10.128.10.21" } ] } Note the reference to the Service Template and the connector within the JSON body of the post. This is followed by the deployment specific details. Watch it all happen in the video below. The POSTMAN collection for this episode can be imported from Github using this link: https://raw.githubusercontent.com/npearce/F5_iWorkflow_REST_API_Commands/master/F5%20iWorkflow%20REST%20API%20-%20Tenant%20L4%20-%20L7%20Service%20Deployment.postman_collection.json
Application Service stats not yet reported in iWorkflow L4-L7 services deployed
Hi, I have deployed an iApp services (by the scratch template's implementation) through Workflow(2.1.0). On the LTM target I get it implemented, with virtual server in status GREEN, but on iWorkflow from the General Properties of this service, I get this message "Application Service stats not yet reported." If i use an "working" template provided with F5(), the message is Application Service is healthy. Reading the code of working template, I saw the following lines could solve it: iapp_conf create sys icall script publish_stats definition \{ $icall_script_src \} iapp_conf create sys icall handler periodic publish_stats interval 60 script publish_stats Are same references around?
F5 insertion to ACi
Do I need Big-IQ to work on F5-IP LTM in ACi with iworkflow? I am able to insert the F5-LTM and everthing works fine. I am planning to proceed to L4-L7 services (ACi) and import iWorkflow. What would be the impact while importing the package? is there interuption in F5 system? Thanks and regards,
redirection issue on irule code
Have created the irule for redirection from http://pfc-pp.prodactive/jkhg/#/ to pfc.pp.cloud, while redirecting to pfc.pp.cloud i could see # value is not removed i get the result https://pfc.pp.cloud/#/ i want to remove as well # have to redirect to https://pfc.pp.cloud can you please help me on this when HTTP_REQUEST { if {[HTTP::uri] starts_with "/jkhg"} { HTTP::uri [string map {"/jkhg" ""} [HTTP::uri]] HTTP::respond 302 Location "https://pfc.pp.cloud[HTTP::uri]" TCP::close } else { HTTP::respond 302 Location "https://pfc.pp.cloud[[HTTP::uri]" TCP::close } }F5 iWorkflow and Cisco ACI : True application centric approach in application deployment (End Of Life)
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. On June 15 th , 2016, F5 released iWorkflow version 2.0, a virtual appliance platform designed to deploy application with greater agility and consistency. F5 iWorkflow Cisco APIC cloud connector provides a conduit allowing APIC to deploy F5 iApps on BIG-IP. By leveraging iWorkflow, administrator has the capability to customize application template and expose it to Cisco APIC thru iWorkflow dynamic device package. F5 iWorkflow also support Cisco APIC Chassis and Device Manager features. Administrator can now build Cisco ACI L4-L7 devices using a pair of F5 BIG-IP vCMP HA guest with a iWorkflow HA cluster. The following 2-part video demo shows: (1) How to deploy iApps virtual server in BIG-IP thru APIC and iWorkflow (2) How to build Cisco ACI L4-L7 devices using F5 vCMP guests HA and iWorkflow HA cluster F5 iWorkflow, BIG-IP and Cisco APIC software compatibility matrix can be found under: https://support.f5.com/kb/en-us/solutions/public/k/11/sol11198324.html Check out iWorkflow DevCentral page for more iWorkflow info: https://devcentral.f5.com/s/wiki/iworkflow.homepage.ashx You can download iWorkflow from https://downloads.f5.comiWorkflow 201 (episode #01) - Introducing the iControl REST API
Welcome to the first episode in the iWorkflow 201 series. The iWorkflow 101 series focussed on the GUI-driven operation of the iWorkflow platform whereas the 201 series focuses on performing tasks via the iControl REST API. This first episode is dedicated to those not familiar with using APIs but wanting to make that leap from GUI or Command-line Interface (CLI) management. Consequently, most of the episode will be focussed on introducing the tools you need, with some lessons on how to use them. Finally, at the end of the episode we’ll make our first API call to the iWorkflow platform. Background Reading If this is your first time venturing away from the GUI/CLI, or maybe you just want a refresh, I recommend you watch this great REST API introduction video posted byWebConcepts. In this video you'll see how you can communicate with popular on-line services including Facebook, Google Maps, and Instagram via their REST APIs: It really is that straight forward. In short, you’re using the internet, but not through the traditional web browser. So, now you understand the importance of a REST API, lets move onto the tools. The toolset Introducing POSTMAN! POSTMAN is a Google Chrome browser application. Its great for getting to know REST API’s as it requires no scripting languages. It is a pure REST client. No, it is not the only REST tool out there. However, its supported on a number of platforms and is very straight forward. For your convenience, following are the POSTMAN Setup and Intro instruction videos: POSTMAN Install POSTMAN API Response Viewer iWorkflow iControl REST API Introduction Ok, you’ve got the tools installed and are now are ready to go. So, lets now move on to F5’s RESTful API implementation which is callediControl REST. You will notice, on DevCentral, that there is also a SOAP/XML version of iControl. We implemented this on BIG-IP devices, back in 2001–before REST existed and before iWorkflow. Hence, the BIG-IP device has both the iControl SOAP API and the iControl REST API. iWorkflow, on the other hand, only supports F5’siControl REST framework. Also worth noting, the iWorkflow platform communicates with BIG-IP devices using the BIG-IP iControl REST API. If you watched the video iniWorkflow 101 (episode #02) - Install and Setupyou will have noticed that the iWorkflow platform updates the BIG-IP REST Framework on older BIG-IP versions that require it. In that video I was communicating with BIG-IP version 11.6 so the REST Framework update was performed. The lab environment NOTE: While we will look at iWorkflow Clusters in a future 201 REST API episode it is not important in this episode and all communication will be with iworkflow1.n8lab.local on 10.128.1.130 First Contact Just as in the 1996 feature-length Star Trek episode “Star Trek: First Contact", its time to query the iWorkflow platform. And our first URI to call will be for a list of devices known to iWorkflow. The URI: https://10.128.1.130/mgmt/shared/resolver/device-groups/cm-cloud-managed-devices/devices Lets start off by posting this request into POSTMAN. If you hit send before providing the login credentials then you will receive the following: This is to be expected. You can provide the login credentials under the Authorization tab just below the request URL as show in the following diagram: With those details added, run the query again and you should receive a JSON response like the following. In this diagram we can see properties of the iWorkflow platform: Scrolling further down you can also see the BIG-IP and the other two iWorkflow platforms from the iWorkflow cluster. Here it is in a video: Summary Congratulations!! You’re now talking to your iWorkflow platform via its iControl REST API. If you cannot wait for the next episode, where we will deploy and application services policy via REST, you may want to start looking at the iWorkflow API Reference at the bottom of this page on DevCentral:https://devcentral.f5.com/s/wiki/iWorkflow.HomePage.ashx UPDATE: if you want to grab a POSTMAN collection to import into your environment, visit my GitHub page here
Testing network bandwidth with and without F5 connection.
I wanted to test network bandwidth using iperf tool with and without F5 connection. Without F5 is straightforward. With F5 : I added the node I wanted to test, Created a Pool with service port for iperf (5201 in my case) and the node that I added, Selected the icmp for health monitoring, Created the VIP with the same service port and selected the pool that I created for iperf. But when I tested using the VIP the client failed to connect to the server. I'm a newbie to F5. Not sure what I am missing. Please help!
Bigiq 6.0 or ansible
We've decided to do orchestration&automation of deployment of creation/modify/delete of virtual services, and we were using iWorkflow. Since F5 does not support anymore iworkflow we are about going to Bigiq 6.0 but we have still the doubt of ANSIBLE since we want to orchestrate other not F5 networking devices.NetOps Meets DevOps - The State of Network Automation Survey
We want to understand your company’s current application architectures and the adoption of continuous delivery and continuous deployment practices within your organization. Please answer some brief questions about: How important automation is to your application deployments Drivers for continuous delivery and continuous deployment (CD/CD) Current challenges and concerns with respect to network and security operations How your future initiatives are shaping your plans for network and security automation Usage of automation tools across public and private cloud Please note that your responses will be confidential and reported only in aggregate. As a thank you for participating, you will receive a copy of the final aggregate survey results and, a lucky participant will receive a $500 Amazon gift card. All information will remain confidential This survey is being administered by an independent research company on behalf of F5 and Red Hat. Your answers will be kept strictly confidential and your feedback will be combined with the feedback from all respondents worldwide. UPDATE: The report has now been finalized and can be found here: NetOps Meets DevOps - The State of Network Automation Many thanks from the DevCentral Team!
