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 GUI we 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 we created back in iWorkflow 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-Tenant access 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 Explained the 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 Service Catalog 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: POST https://{{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.jsonF5 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 by WebConcepts. 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 called iControl 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’s iControl 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 in iWorkflow 101 (episode #02) - Install and Setup you 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 hereNetOps 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!iWorkflow 101 (episode #1) - The Architecture Explained [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. F5® iWorkflow™ accelerates the deployment of applications and services while reducing exposure to operational risk. The iWorkflow™ 101 series has been created to share common workflows for the purpose of accelerating your organizations journey towards integration, automation, and continuous deployment. In episode #1 of the iWorkflow™ 101 series we take a high-level look at the various themes and components of the iWorkflow™ platform to aid in understanding its operation. Who’s it for? iWorkflow™ is for anyone interested in: the rapid deployment of performance, high-availability, and security policy the simplification of policy execution through abstraction of complexity extending continuous deployment practices to include scalability and security reducing exposure to operational risk These points hold true whether you’re a traditional infrastructure administrator managing F5 BIG-IP’s directly, a platform architect or engineer responsible for presenting resources to business units, or an application architect or developer looking to rapidly deploy new apps and services as part of the continuous deployment pipeline, while ensuring they remain fast, highly-available, and secure. Architectural Walkthrough New theme’s introduced in this episode: Application Services Application Services Templates Services Template Catalogues Tenants Clouds Workflows Application Services If you are familiar with F5 BIG-IP’s then you already know about Application Services. If not, they are the Layer 4 – 7 features and functions delivered by the BIG-IP application delivery controller. Such application services include: High-availability monitoring and resilience Load-balancing DNS Services DDoS mitigation Application/Data security Access control Scaling and optimization Context switching / app routing and much more. For more information on application delivery controllers and the services they both provide please visit: F5® BIG-IP Application Services Templates An application services template defines a configuration, while accepting deployment-specific information at the time of execution. At this stage its important to introduce the Declarative Model, and a simple way to explain this is to talk about McDonalds… When you enter a McDonalds restaurant you are presented with a range of meal options. Lets say you were to choose a Big Mac meal, which includes fries and a soft drink. The “meal" itself is the template: you get a Big Mac, fries, and a soft drink. Sure, you can choose which soft drink you get (cola, lemonade, water), you can even select a dipping sauce (ketchup, honey mustard, sweet chili, etc), but you are not required to define the Big Mac, nor are you able to order items outside of the meal options–try asking for a Pizza instead of Fries! The declarative model provides an abstraction to the meal creation process alleviating the customer from much the complexity. In contrast to the declarative model we have the imperative model. Using the McDonalds scenario again, an imperative model would require that you order every single ingredient individually, in addition to explaining how they are prepared, and how they are put together to make the meal. Back to Services Templates, the declarative model allows for infrastructure administrators and architects to define sets of common deployment configurations and expose such templates to teams that may not be skilled in application delivery policy. Organizations can then realize the benefits of advanced functionality while avoiding lengthy deployment delays, as such an architecture eliminates the need for business units to become experts in every technology. Instead, approved, repeatable policies can be deployed directly by operations staff, or by 3rd party orchestration systems, at the time of application deployment. In 2011, F5® released iApps (F5’s application services templates) to eliminate much of the manual process and repetition involved in configuring the BIG-IP application delivery controller. For more information on the benefits of services templates, please read: “Why you need service templates”. For technical details on F5 iApps, navigate here. Services Template Catalogue A Services Template Catalogue presents the application services templates to the deployment staff. The deployment could be performed manually by an employee via the iWorkflow™ GUI, or by 3 rd party systems communicating with the iWorkflow™ iControl REST API. In either scenario, both the administrator and 3rd party system are interfacing with the Services Template Catalogue. Connectors The connectors provide the communication between iWorkflow and other systems. For example, the local BIG-IP connector provides a tenant with destination BIG-IP’s upon which to deploy policy. The Cisco APIC and VMware NSX connectors provide for the deployment of BIG-IP application services within Cisco ACI and VMware NSX environments. Lastly, the Integration SDK, allows organizations to build their own integrations and functionality. Tenants A services template catalogue, and the destination devices and environments, are presented through the iWorkflow™ Tenant feature. Consider a Tenant as a grouping of Application Services Templates, Connectors, Devices, and the Users and Groups with the appropriate permissions to deploy application services upon them. Such a grouping vastly simplifies the management of fine-grained access control, while limiting the user’s exposure to the complexity of the environment. Workflows In the context of iWorkflow™, workflows are the end-to-end execution of a system’s or operator’s intent to deploy policy. In the case of an iWorkflow Tenant, the execution starts directly with iWorkflow™, via the GUI or iWorkflow™ REST API. However, in the case of a 3rd party system the workflow starts from within that system which executes the application services template deployment through iWorkflow™. Workflow walkthrough Stitching these themes together, following is a step-by-step walkthrough of a simple workflow: When talking about workflows we start with the intent, and work through to the executed policy. This intent could be that of a 3 rd party system, or of an iWorkflow Operator manually deploy an iApp. With that in mind, referring to the number diagram above, lets now walk through the various elements of a workflow: To the administrators and 3 rd party systems from which iWorkflow™ takes instruction, there are two interfaces: a) the iWorkflow™ GUI, and b) the iWorkflow™ iControl REST API. The iControl REST API may be interfaced by 3rd party systems or by sys-admins using various scripting options or desktop REST API clients. Detailed examples of using each will be provided in future iWorkflow 101 episodes found here on DevCentral: iWorkflow Home The “Service Template Catalogue” presents the local, administrator-defined services templates that have been permitted for the tenant. Exactly which options are configurable at the time of deployment, within each template, is predetermined by the iWorkflow™ administrator. Consequently, the simplicity, or complexity, of each template, and how they are implemented per iWorkflow tenant, is extensively configurable to match an organizations requirements. The “Services Templates” themselves, the F5 iApps, that are presented via the “Service Template Catalogue”. How much of their functionality that is exposed via the Service Template Catalogue is configurable, and thus simplifying how administrators can accommodate the varying capabilities of the iWorkflow Operators: be they 3 rd party systems or sys-admins. The iWorkflow™ platform itself that hosts the Services Templates, the presentation of the Service Template Catalogue, and the iWorkflow™ Connectors, while also managing the multi-tenancy, role-based access control, and what elements of which templates should be exposed where and to whom. Its quite amazing, really! iWorkflow™ communicates with the BIG-IP ADC’s via the BIG-IP iControl REST API. The F5 BIG-IP Application Delivery Controllers (ADCs) themselves. These devices, physical or virtual, consume the performance, availability, and security policies that were defined by the services templates, and enforce that desired behavior. The Provider / Tenant model There are two distinct iWorkflow™ personas: the iWorkflow Administrator, and of the iWorkflow Tenant. The iWorkflow™ administrator creates and manages the various objects of the iWorkflow™ platform that are required to execute a workflow. Once configured, these object are provided to the tenants. Such objects include: BIG-IP Devices Connectors Services Template Catalogues Users/Groups Tenants Licenses The iWorkflow™ Administrator is not able to create, delete or modify these objects. The role of the Tenant is to execute the deployment of performance, high-availability, and security policies via the service template catalogue, as configured/permitted by the iWorkflow™ Administrator. This is typically referred to as a Provider/Tenant model. iWorkflow Administrator As shown in the diagram below (top right corner), the “admin” user is logged in and that user is an iWorkflow™ Administrator. An administrator has the ability to add BIG-IP Devices, create Connectors, add Catalogue entries, and more. iWorkflow Tenant In this example the user “user1” is logged in. Note that it no-longer states that an “Administrator” is logged in, as per the previous image (in the top right-hand corner). In this example, the iWorkflow Tenant has been configured with access to the “myConn1”, local Connector. “user1” does not have the ability to create, delete, or modify Connectors. Only to deploy pre-determined policy to BIG-IP Devices via the "myConn1” connector. Summary Using application services templates, organizations can eliminate repetitive effort during deployments. This enables them to accelerate time to market for new applications and services, reduce exposure to operational risk, and enable infrastructure consumers (the business) to self-serve: deliver performance, high-availability, and security policy at speed. For more information, return to the DevCentral iWorkflow Home page.iWorkflow 101 (episode #2) - Install and Setup
Last weeks episode, The Architecture Explained, drew a lot of attention. The most frequent request was for video content showing the iWorkflow interface and how the Tenants and connectors are configured (if you don’t understand those themes, take a look at Episode #1). Well, this week we’ll do precisely that and take a look at the interface. To avoid ending up with one long video I’m going to break it into two parts: Install and Licensing of the iWorkflow Platform Overview of the Administrative GUI and basic Setup Acquiring a copy of iWorkflow iWorkflow will be available for download mid-June. When released, it will be made available via https://downloads.f5.com/ NOTE: iWorkflow is not available as a hardware appliance. For the purpose of this demonstration I’ll be importing the OVA image into VMware Fusion v7.1.2 on my MacBook running Apple OS X 10.11.5 (El Capitan). Initial Setup iWorkflow boots just like any Linux-based virtual machine. To start working with its administrative interface, you’ll need to connect it to a network. You require: Management IP Address/Netmask Default Gateway (Optional) DNS (Optional) If you want to automate some of the license activation process, you will require DNS and a Default Gateway that can reach F5’s activations servers. I have listed them as ‘Optional' here because you can manually copy and paste the licensing data to activate. For the purpose of this demonstration I will go through the activation process manually to show all the steps. The environment we are building out will look as follows: Details of the environment: LAB Domain: n8lab.local Management: 10.128.1.x/24 Internet (external): 10.128.10.x/24 Servers (internal): 10.128.20.x/24 iWorkflow™ 2.0 Management – 10.128.1.130 BIG-IP™ v11.6 HF6 Management – 10.128.1.128 External Self IP – 10.128.10.10 Internal Self IP – 10.128.20.10 Virtual IP – 10.128.10.20 Web Server #1 – 10.128.20.1:8080 Web Server #2 – 10.128.20.1:8081 Install & License In the following video we will cover all of the steps to install and license the iWorkflow platform: Discover a BIG-IP Device Now that we have iWorkflow licensed and networked we need to configure it for use. The next step in this episode will be to discover a device (a BIG-IP) which will be used in next weeks episode titled, "iWorkflow 101- episode #3 - Deploying a Services Template via the iWorkflow GUI”. Once we’ve discovered a BIG-IP device, we need to create the conduit through which a Tenant deploys application services templates (F5 iApps). These conduits, or connectors, are referred to as iWorkflow Clouds. iWorkflow supports a number of Clouds but, for this 101 episode we’ll use the BIG-IP connector, which is suitable for most environments. In the following video we’ll take a look at the Administrative GUI, show how to import a BIG-IP Device, and lastly, create a connector and Tenant to support deploying application delivery policy. Conclusion Three main things to remember: NTP - very important to keep iWorkflow and the BIG-IPs in time sync Registration key: we’ll provide an evaluation license process once iWorkflow is released in mid-June. NTP - in case I didn’t mention this already. In the next episode we will create a Tenant Catalog with an Application Services Template. We will then login to the iWorkflow platform as a Tenant and deploy our first configuration.iWorkflow 101 (episode #3) - Deploying a service template via the Tenant GUI
NOTE: This iWorkflow 101 episode assumes that you already have a licensed F5 BIG-IP Device (physical or virtual) and F5 ® iWorkflow™ platform. These steps are covered in iWorkflow 101 (episode #2): Install and Setup. To better understand the concepts used in this episode, please visit: iWorkflow 101 (episode #1): The Architecture Explained In this third episode we shall deploy a basic, load-balanced HTTP server configuration. While this is only a basic configuration, performing the deployment manually could take hours via the GUI or command-line. However, with iWorkflow we have a platform that, once configured, will eliminate almost all of the effort of future application-delivery policy deployments. As depicted in the following diagram, we will prepare the iWorkflow platform with so that an iWorkflow Tenant can deploy the "f5.http" services template. In the previous episode we added a BIG-IP Device to iWorkflow, created an iWorkflow Cloud connector, an iWorkflow Tenant, and User/Role access. No we bring them all together to demonstrate the architectural simplification and reduced exposure to operational risk by creating a Services Catalog for the Tenant. The Lab Environment The following lab environment (.n8lab.local) will be used as the basis of this and future iWorkflow 101 episodes. It may vary a little when the use-cases require so, but such will be specified when applicable: Networks: Domain: n8lab.local Management: 10.128.1.x/24 Internet (external): 10.128.10.x/24 Servers (internal): 10.128.20.x/24 iWorkflow™ Management – 10.128.1.130 BIG-IP™ Management – 10.128.1.128 External Self IP – 10.128.10.10 Internal Self IP – 10.128.20.10 Virtual IP – 10.128.10.20 Web Server #1 – 10.128.20.1:8080 Web Server #2 – 10.128.20.2:8080 This is a Two Part exercise This iWorkflow 101 episodes two parts. Why? At the end of Episode #1 (The Architecture Explained), we introduced the two operational personas of iWorkflow: The Administrator and the Tenant. The Administrator implements the required objects (adds BIG-IP’s, Clouds/Connectors, Users/Roles, Templates, Catalogs, etc) to make the iWorkflow platform operational. Once complete, the iWorkflow Tenant deploys the application services templates onto BIG-IP application delivery controllers. This is referred to as a Provider / Tenant model. The preparation of the iWorkflow platform must happen at least one. However, once prepared, an iWorkflow operator may use it repeatedly without administrator involvement. Part #1 – Prepare the iWorkflow™ platform for the Tenant First we must prepare the iWorkflow™ platform for iWorkflow™ Tenant use. While there are a number of roles available on iWorkflow™, they fall into two categories: iWorkflow Administrators and iWorkflow Tenants. Administrators manage the platform and its resources. Tenants use the platform to deploy the performance, high-availability, and security policies. To prepare iWorkflow for Tenants we must first perform an initial setup of the environment. Login as an Administrator using the default administrative account credentials are: Username: admin Password: admin. Additional “Administrator” role accounts can be created should you require them. Navigate to the “Cloud” section from the drop-down list at the top: Click the + on the “Catalog” heading. This will enable you to create a new application services template (F5 iApp). The following diagram illustrates the creation of a new Catalogue Entry. In the example below, you can see the “f5.http” iApp that we will use for todays episode. This, and other iApps, were inherited from the BIG-IP during the discovery process in iWorkflow 101 - Episode #2 - Install and Setup. Prior to the discovery of the first BIG-IP, the iWorkflow platform holds no iApps. Important to now are the "Input Parameters" and the “Tenant Editable” check boxes, show below. How many options are available for editing is determined by the “Input Parameters” option you choose. Accept Defaults (show in the diagram above) provides no fields for editing. Common Options provides a short list of most commonly edited settings available in the iApps. All Options does precisely that. It displays a LOT of options. The Tenant Editable check-boxes determine which fields will be visible to the Tenant. The administrator decides which options to pass through, or which options to set and NOT pass through, to the Tenant. The administrator can get a preview of what the Tenant will see by clicking the Tenant Preview button while editing the template. Save when finished. For more details on the process watch the video at the end of this article. Part #2 – Deploying application services via iWorkflow™ Login on as the iWorkflow Tenant we created in Episode #2 (we called them User1). Navigate to the “Cloud” section and click the + in the “Services” tab. Now you see the Tenant perspective of the iWorkflow platform and how an application services template is used to rapidly, repeatedly deploy application-delivery services policy: Note the addition of the “Port” field. This is not "Tenant Editable" by default. As you will see in the video below, we’ve marked this field as Tenant Editable as part of the demonstration, which is why you can see it above. To see it all in action, watch the video below! Here’s Part #1 and Part #2 in a video:Lightboard Lessons: BIG-IP in the public cloud
In this episode, Jason talks about some of common ways people refer to "cloud" and how BIG-IP fits into those molds in the Amazon, Google, and Microsoft cloud offerings. Resources BIG-IP VE Setup - Amazon Web Services BIG-IP VE Setup - Google Cloud BIG-IP VE Setup - Microsoft Azure Getting Started with Ansible AWS Cloud Formation Templates iWorkFlow 101 Series (Youtube)What is iWorkflow?
tl;dr - F5's iWorkflow is no longer a supported product and is superceeded by Application Services 3 Extension (AS3). For more AS3 information please see Application Services 3 Extension Documentation . Vocabulary To understand iWorkflow we need to define a few terms that will show up in the product: Clouds - The connectors for BIG-IP ADC services to iWorkflow. Use by Service Templates to connect Tenants to iApps. Tenants - A permission-defined role within iWorkflow. Tenants map users and user groups to service templates through cloud assignments. iApp Templates - Application templates used in deployment and management of multiple ADC features and objects. iApp templates deployed in iWorkflow are used to create one or more Service Templates. Service Templates - Service Templates are the customer visible options of an iApp available for deployment within a specific cloud connection. L4-L7 Services - These are the deployed from service templates by the tenants of iWorkflow. How It Works iWorkflow consolidates BIG-IP environments into a REST API accessible solution for your orchestration system. Managing access and services are made through role-based access controls (RBAC). Using iApps, orchestration providers will deploy applications through iApp-defined service catalogs. iWorkflow maintains the connections to your cloud and on-premise BIG-IP infrastructure and manages the access that each business unit will need to successfully deploy one or more applications. iWorkflow installs to your preferred virtual environment connects via F5's iControlREST API to existing BIG-IP ADC services through one of the following: Existing L3 Connections (Datacenter/AWS/Azure/3rd Party Cloud Providers) Cisco APIC VMWare NSX BIG-IP Virtual Clustered Multiprocessing (vCMP) iWorkflow administrators will create a service catalog for his users to access through their orchestration providers or directly through the iWorkflow GUI. An high level deployment workflow is shown below. Using iControlREST for interfacing with BIG-IP and your orchestration providers, iWorkflow allows BIG-IP to participate in fast Agile DevOps workflows. RBAC allows security, network, and development teams access to their areas of administration all controlled by iWorkflow. For further reading on how iWorkflow integrates into your existing infrastructure and development plans, please review the below links. If there is more you would like to see related to iWorkflow please drop us a line and we'll be happy to assist. iWorkflow on DevCentral - The best repository for all things iWorkflow (Requires Login) iApp Template Development Tips and Techniques (Requires Login) iWorkflow 101 and 201 Series on Youtube (relax and learn to the sweet satin sounds of Nathan Pearce)iWorkflow 201 (episode #4) - Developing iApps for iWorkflow
In this episode we provide some instructions on developing iApp templates for use on iWorkflow. In the early versions of iWorkflow (before v2.1.0), the platform inherited its iApp templates from BIG-IP devices. By popular demand, this is no longer a requirement, and iApp templates can be installed directly onto your iWorkflow platform. With this came a few new features that we need to share with you, especially the iApp versioning. Many customers requested iApp versioning so they could track iApp functionality as they evolved their architecture. Without versioning, this is a bit of a nightmare! Watch this video to understand: How to version your iApps. How to specify which BIG-IP versions your iApp supports (minimum/maximum/unsupported) The Application Tier settings Links references in this video: Versioning iApps: http://f5-automation-labs.readthedocs.io/en/v2.0/appendix_a/howto_update_iapp_for_iWorkflow_2_1.html Specifying BIG-IP versions supported by your iApp: https://devcentral.f5.com/wiki/iworkflow.howtosamples_importing_iapp_templates_to_iworkflow.ashx
