PBC - Automation and Orchestration - Workbook - 2019-03-19

Automation & Orchestration
for BIG-IP
Partner Exercise Guide
Document version 13.1.J

Written for: TMOS® Architecture v13.1.x
Virtual images:
BIGIP-13.1.0.2-0.0.5.ALL-scsi.ova
BIGIP-13.1.1-0.0.4.ALL-scsi.ova
BIGIQ-6.0.1.0.0.813-scsi.ova
F5 Worldwide Field Enablement Last Updated: 03/13/2019

Learn More, Sell More, Sell Faster
©2019 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in
certain other countries. Other F5 trademarks are identified at f5.com.
Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or
affiliation, express or implied, claimed by F5.
These training materials and documentation are F5 Confidential Information and are subject to the F5 Networks Reseller Agreement. You
may not share these training materials and documentation with any third party without the express written permission of F5.
F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 3

Table of Contents
Table of Contents
Table of Contents ................................................................................................................................ 5
Imperative Automation: BIG-IP iControl REST API .................................................................................... 7

Imperative Automation Instructor Presentation .................................................................................. 7
Exercise 1 – Exploring the BIG-IP iControl REST API .............................................................................. 9
Abstracting Services using AS3 and Ansible............................................................................................ 33

Abstracting Services Instructor Presentation ..................................................................................... 33
Exercise 2 – Abstracting Services using AS3 and Ansible .................................................................... 34
BIG-IP Cloud Edition App Templates & Analytics .................................................................................... 63

BIG-IP Cloud Edition Instructor Presentation ..................................................................................... 63
Exercise 3 – BIG-IP Cloud Edition App Templates ............................................................................... 64
Appendix – Lab Diagram ........................................................................................................................ 77

BIG-IP iControl REST API Instructor Presentation
Imperative Automation: BIG-IP iControl REST API

Imperative Automation Instructor Presentation
NOTES
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________

Exercise 1 – Explore iControl REST API
Exercise 1 – Exploring the BIG-IP iControl REST API

• Required virtual images: BIGIP_A_v13.1.x
• Estimated completion time: 70 minutes
Task 1 – Access Your Class Application Portal

Use a web browser to access your class application portal.
− Open the email from your instructor containing the class application links, and then click
the link assigned to you. This opens your class application portal.
− For the Linux Jumphost image, click RDP, and then download to your desktop.
− Start the RDP session you downloaded and log in using ubuntu / supernetops.
− If RDP connects ok, skip to Task 2.
− If RDP doesn’t connect then do steps below from the portal session.
o Click the Console link for your Linux Jumphost and login using password supernetops.
o Open the icon on desktop labeled Terminal

o Issue the command sudo /etc/init.d/xrdp restart
− Start the RDP session again and log in using password supernetops.

Task 2 – Explore the API using the TMOS Web Interface

In this lab we will explore the BIG-IP iControl REST API using an interface that is built-into TMOS.
This utility is useful for understanding how TMOS objects map to the REST API. The interfaces
implement full Create, Read, Update and Delete (CRUD) functionality. However, in practicality it’s far
easier to use this interface as a ‘Read’ tool rather than trying to Create objects directly.
NOTE: It’s beneficial to have GUI/SSH sessions open to BIG-IP devices while going through this lab.
Feel free to verify the actions taken in the lab against the GUI or SSH. You can also watch the
following BIG-IP logs:
/var/log/ltm and
/var/log/restjavad.0.log
− Open Google Chrome and navigate to the following bookmarks: BIG-IP A GUI, and BIG-IP B
GUI. Bypass any SSL errors that appear and ensure you see the login screen for each bookmark.
− Navigate to the URL https://10.1.1.10/mgmt/toc (or click the BIG-IP A REST TOC bookmark).
Note: The /mgmt/toc path in the URL is available on all TMOS versions 11.6 or newer.
− Authenticate to the interface using the default credentials (admin/admin)

− You are presented with a top-level list of various REST resources.
− At the top of the page there is a search box that can be used to find items.

− Type ‘sys’ in the search box and then scroll down and click on the following links under iControl
REST Resources. We will input values to these resources in the next section.
o sys/dns
o sys/management-ip
o sys/ntp
o sys/version
− Take note of the full path to each resource. Here is how the path is broken down:
/ mgmt / tm / sys / dns

Find the ‘/mgmt/tm/sys/provision’ Collection and click it.
− You should see a listing of the Resources that are part of the provision collection.
− Click the ‘gtm, apm, asm and ltm’ collections to view their attributes.
− Both asm and ltm should have the level set to nominal where others are set to none.

Task 3 – Setup the Postman tool
− Open the Postman tool by clicking the icon of the desktop of your Linux Jumphost. The
initial window may take a few moments to appear.
The Postman client receives very frequent updates. If you are prompted to update the client please
click the Remind me later button to skip updating the version installed in your lab environment
− Open the Postman Settings windows by clicking File ‣ Settings
− Verify your client is configured to allow self-signed certificates by

setting SSL certificate verification to OFF.
− Click the X in the top right of the Settings window.

− A Postman Collection lets you group individual REST requests together. This Postman collection
can then be shared and imported. To import a Postman Collection, you would click
the Import button in the top left of the Postman window.

− We have already done the Import in this lab environment, so you should see a collection
named F5 Programmability: Class 1 in your Postman Collections sidebar. Postman
automatically resizes its GUI depending on its window size. It might be necessary to use the
short Ctrl + \ (on Windows) or click the show sidebar icon at the bottom left corner of
postman if you do not see the sidebar.
− To assist in multi-step procedures we make heavy use of the Environments capability in

Postman. This capability allows us to set various global variables that are then substituted into a
request before it’s sent. Like the Collection, you can Import an Environment file by
clicking Import. This has already been done for this lab environment.

− This has also already been done, but to set your environment to F5 Programmability: Class
1 you would use the menu at the top right of your Postman window.
Task 4 – HTTP BASIC Authentication

One of the basic concepts related to interaction with REST API’s is how a particular consumer is
authenticated to the system. BIG-IP supports two types of authentication: HTTP BASIC and Token
based. It’s important to understand both of these authentication mechanisms, as consumers of the API
will often make use of both types depending on the use case.
In this task we will use Postman to send API requests using HTTP BASIC authentication. As its name
implies this method of authentication encodes the user credentials via the existing BASIC authentication
method provided by the HTTP protocol. The mechanism this method uses is insertion of an HTTP
header named ‘Authorization’ with a value that is built by Base 64 encoding the string
“<username>:<password>”. The resulting header takes this form:
Authorization: Basic YWRtaW46YWRtaW4=
It should be noted that cracking the method of authentication is TRIVIAL; as a result API calls should
always be performed using HTTPS rather than HTTP.
− Click the Collections tab on the left side of the screen, expand the F5 Programmability:
Class 1 collection on the left side of the screen, expand the Lab 1.2 – API
Authentication & 'example' Templates folder.

− Click the Step 1: HTTP BASIC Authentication item. Click the Authorization tab and
select Basic Auth as the Type. Fill in the username and password ( admin/admin) and
click the Send button.
− Click the Headers tab and examine the HTTP header. Notice that the number of Headers
in the Headers tab changed from 1 to 2. This is because Postman automatically created
the HTTP header and updated your request to include it.
− Click the Body tab in the Response, if the request succeeded you should be presented
with a listing of the /mgmt/tm/ltm Organizing Collection.

− Click the Test Results tab and ensure all the tests for this request have passed.
− Update the credentials and specify an INCORRECT password. Send the request again
and examine the response.
− Check the Test Results tab and notice that our Unit Tests for this request are now failing
(as expected).

Task 5 – Token Based Authentication

One of the disadvantages of BASIC Authentication is that credentials are sent with each and every
request. This can result in a much greater attack surface being exposed unnecessarily. As a result Token
Based Authentication (TBA) is preferred in many cases. This method only sends the credentials once, on
the first request. The system then responds with a unique token for that session and the consumer then
uses that token for all subsequent requests. BIG-IP supports token-based authentication that drops down
to the underlying authentication subsystems available in TMOS. As a result the system can be
configured to support external authentication providers (RADIUS, TACACS, AD, etc) and those
authentication methods can flow through to the REST API. In this task we will demonstrate TBA using
the local authentication database. For more information about external authentication providers see the
section titled “About external authentication providers with iControl REST” in the iControl REST
API User Guide available at https://devcentral.f5.com
− Click the Step 2: Retrieve Authentication Token item in the Lab 1.2 Folder.
− Notice that we send a POST request to the /mgmt/shared/authn/login endpoint.
− Click the Body tab and examine the JSON that we will send to BIG-IP to provide
credentials and the authentication provider.
− Modify the JSON body and add the required credentials, admin/admin, then click the ‘Send’
button.

− Examine the response status code. If authentication succeeded, then a token was generated
and the response will have a 200 OK status. If the status code is 401, check your credentials:
− Once you receive a 200 OK status code examine the response body. The various attributes show
the parameters assigned to the particular token. Find the ‘token’ attribute and copy it into your
clipboard (Ctrl+c) for use in the next step:
− Click the ‘Step 3: Verify Authentication Works’ item in the Lab 1.2 Postman collection.
− Click the ‘Headers’ tab and paste the token value copied above as the VALUE for the ‘X-F5-Auth-
Token’ header. This header is required for all requests when using token based authentication.

− Click the ‘Send’ button. If your request is successful you should see a ‘200 OK’ status and a
listing of the ‘ltm’ Organizing Collection.
− We will now update your Postman environment to use this auth token for the rest of the lab.
− Click the gear in the top right of the Postman window and click ‘Manage Environments’.
− Click the ‘F5 Programmability: Class 1’ item:
− Update the value for ‘bigip_a_auth_token’ by Pasting (Ctrl-v) in your auth token:
− Click the ‘Update’ button and then close the ‘Manage Environments’ window. Your subsequent
requests will now automatically include the token.
− Click the ‘Step 4: Set Authentication Token Timeout’ item in the Lab 1.2 Postman collection.
This request will PATCH your token Resource (check the URI) and update the timeout attribute
to complete the lab easily. Verify that the timeout has been changed to 36000 in response.

− Examine the request type and JSON Body and then click the ‘Send’ button. Verify that the
timeout has been changed to ‘36000’ in the response:
Task 6 – Set BIG-IP Device Settings

This task will focus on configuration of the following items:
• NTP, DNS and Hostname settings
• Physical Interfaces and L2 Connectivity (VLAN, VXLAN, etc.)
• L3 Connectivity (Self IPs, Routing, etc.)
The following table lists the device settings we will configure for BIG-IP-A:
Type Details
hostname bigip-a.f5.local
DNS nameServers 4.2.2.2 and 8.8.8.8
NTP 0.pool.ntp.org
VLAN Internal Interface: 1.1 Tag: 10
VLAN External Interface: 1.2 Tag: 20
Self IP: Internal Address: 10.1.10.10/24
VLAN: Internal
Self IP: External Address: 10.1.20.10/24
VLAN: External
In the first steps we will modify the device hostname and disable the GUI Setup Wizard. The
Resource that contains these settings is/mgmt/tm/sys/global-settings.
Perform the following steps to complete this task:
− Expand the Lab 1.3 - Review/Set Device Settings folder in the Postman collection.
− Click the Step 1: Get System Global-Settings request. Click the Send button and review
the response Body to see what the current settings on the device are. Examine the resulting
response to understand what settings are currently applied.
− Click the Step 2: Set System Global-Settings request. This item uses a PATCH request to
the global-settings resource to modify the attributes contained within it. We will update
the guiSetup and hostname attribute.
o Click on Body. Review the JSON body and modify the hostname attribute to set the
hostname to bigip-a.f5.local
o Also notice that we are disabling the GUI Setup Wizard as part of the same request:
− Click the Send button and review the response Body. You should see that the attributes
modified above have been updated by looking at the response. You can also GET the global-
settings by sending the Step 1: Get System Global-Settings request again to verify they
have been updated.
This task will make use of JSON arrays. Much like the previous task we can update system
DNS and NTP settings by sending a PATCH request to the correct resource in the sys
Organizing Collection. The relevant Resources for this task are:
URL TYPE
/mgmt/tm/sys/dns DNS Settings
/mgmt/tm/sys/ntp NTP Settings

− Click the Step 3: Get System DNS Settings item in the folder. Click Send and review the
current settings.
− Click the Step 4: Set System DNS Settings item in the folder. Click Body. Review the JSON
body to verify the name server IPs 4.2.2.2 and 8.8.8.8 are listed. Additionally, add a search
domain of f5.local. You will modify a JSON array to add a search domain:

− Click the Send button and verify the requested changes were successfully implemented by
looking at the response or by sending the Step 3:Get System DNS Settings request again.
− Click the Step 5: Get System NTP Settings item in the folder. Click Send and review the
current settings.
− Click the Step 6: Set System NTP Settings item in the folder. Click Body. Review the JSON
body to verify the NTP servers with hostnames 0.pool.ntp.org and 1.pool.ntp.org are
contained in the servers attribute (another JSON array!).
− Click the Send button and verify the requested changes were successfully implemented by
looking at the response or sending the Step 5: GetSystem NTP Settings again.
Perform the following steps to configure the VLAN objects/resources:

− Expand the Lab 1.4 - Basic Network Connectivity folder in the Postman collection.
− Click the Step 1: Create Internal VLAN request in the folder. Click Body and examine the
JSON request body; the values for creating the Internal VLAN are listed.
− Click the Send button to create the Internal VLAN.
− Click the Step 2: Create External VLAN request in the folder. Examine the Body and click
the Send button.
− Click the Step 3: Get VLANs request in the folder. Click the Send button to GET the VLAN
collection. Examine the response to make sure both VLANs have been created.
Perform the following steps to configure the Self IP objects/resources:

− Click the Step 4: Create Internal Self IP request in the folder. Click Body and examine
the JSON body; the values for creating the Self-Internal Self IP have already been populated.
− Click the Send button to create the Self IP.
− Click the Step 5: Create External Self IP request in the folder and click Send.
− Click the Step 6: Get Self IPs item in the collection. Click the Send button to GET the Self IP
collection. Examine the response to make sure both Self IPs have been created and associated
with the appropriate vlan.
Perform the following steps to configure the Route object/resource:

− Before creating the route, we double check the content of the routing table. Click
the Step 7: Get Routes item in the collection. Click the Send button to GET the routes
collection. Examine the response to make sure there is no route.
− Click the Step 8: Create a Route item in the collection. Click Body and examine the JSON
body; the values for creating the default route have already been populated.
− Click the Send button to create the route.

− Click the Step 9: Get Routes item in the collection again. Click the Send button to GET the
routes collection. Examine the response to make sure the route has been created.
Task 7 – Building Workflows with Postman Collections

As you have seen in the previous labs, we can use the Collections and Folders features of the
Postman client to group REST requests logically. Additionally, as you’ve seen most of the examples
so far have consisted of executing a sequence of REST request to achieve some outcome. In this lab,
we will use a feature in Postman called the Collection Runner (Runner) to execute a sequence
of REST requests. Using the Runner we can rapidly prototype REST requests into an Imperative
Workflow that can be executed without user intervention. The purpose of this exercise is to
provide an example of how new workflows can be built from scratch or existing workflows can be
modified. Additionally, we will use some Postman Javascript Tests to programmatically populate
environment variables with the output of our workflow.
− The collection we will run in this task will populate some environment variables with various
data about the BIG-IP system. First, let’s examine the Environment Variables that are currently
set. Click the icon in the top right of the Postman window. Notice that there are no
variables starting with the name lab1.5_:
− Click the Lab 1.5 - Building Imperative Workflows folder to expand it

− Click the Step 1: Get BIG-IP Software Version request. Click the Tests tab and examine
the Javascript code and comments:
The Javascript code in the Test script will populate an environment variable based on
the response from the BIG-IP system.
− Click the Runner button at the top left of your Postman window:
− Select the F5 Programmability: Class 1 Collection then

the Lab 1.5 - Building Imperative Workflows folder. Next, be sure the environment is
set to F5 Programmability: Class 1 and Persist Variables is selected:

Your Runner window should look like:
As you can see from the screenshot or your own Collection Runner screen, we will be
sending 3 requests (Steps 1-3 in Lab 1.5). Each request has a unit test implemented in
JavaScript to ensure it’s ok to continue to the next request when using the Collection
Runner. The Runner will step through each request unless one of the tests fails.
− Click the Run Lab 1.5 - Buil… button
− The results window will now populate. You will see each request in the folder is sent and its
associated test results are displayed on the screen. The last request in the folder includes some
Javascript code to dump the results to the screen:

− Next, switch back to the main Postman window. Click the button again and examine the
environment variables. Notice that three new variables starting with the name lab1.5_ have
been populated. You may need to scroll down to see these variables:
It is normal for the values of Software Version, CPU Count and Base MAC Address to be different
from the screenshot(s).

Task 8 – Build a Basic LTM Config using REST Transactions

Transactions are very useful in cases where you would like to have discrete REST operations to act as a
batch operation. As a result, the nature of a transaction is that either all the operations succeed or none of
them do (all-or-nothing). This is very useful when we are creating a configuration that is linked together
because it allows roll back of operations in case one fails. All the commands issued are queued one after
the other in the transaction. We will also review how to change the order of a queued command or
remove a single command from the queued list before committing.
Transactions are essential to ensure that an Imperative process is Atomic in nature. Transactions have a
default timeout of 120 seconds. Taking longer than the timeout period to execute a transaction will
result in automatic deletion of the transaction. To avoid having to redo the steps in this task, please first
read through the steps below and execute each of them in a timely manner.
Note: In the web version of this course there is a Lab 1.6 Build a Cluster folder in
Postman. For time constraints, we are skipping ahead to Lab 1.7.
− Expand the Lab 1.7 - Build a Basic LTM Config using Transactions folder in the
Postman collection:

− Click the Step 1: Create a Transaction request. Examine the URL and JSON Body. We will
send a POST to the /mgmt/tm/transaction endpoint with an empty JSON body to create a new
transaction.
− Click the Send button to send the request. Examine the response and find the transId
attribute. Additionally, notice that there are timeouts for both the submission of the transaction
and how long it would take to execute. Please be aware that upon exceeding the
timeoutSeconds period, the transId will be silently removed:
The transId value has been automatically populated for you in the
bigip_transaction_id environment variable:

− Click the Step 2: Add to Transaction: Create a HTTP Monitor request in the folder. This
request is similar to a non-transaction enabled request in terms of the POST request method,
URI and JSON body. The difference is that, a header named X-F5-REST-Coordination-Id with
the value of the transId attribute is added to the transaction:
− Click the Send button and examine the response.

− Examine and click Send on Steps 3-6 in the folder.
− Click Step 7: View the Transaction Queue. Examine the request type and URI and
click Send. This request shows the current list of ordered commands in the transaction.
− Click the Step 8: View Queued Command 4 from Transaction request. Examine the request
method and URI. We will GET command number 4 from the transaction queue.

− Click the Step 9: Change Eval Order 4 -> 1 request in the folder. Examine the request
method, URI, JSON body, then click Send. We will PATCH our transaction resource and change
the value of the evalOrder attribute from 4 to 1 to move to the first position of the transaction
queue:
Requests in the ordered transaction queue must obey the order of operations present in the
underlying BIG-IP system. When sending the Header X-F5-REST-Coordination-Id, the
system assumes that you want to ADD an entry in the transaction queue. You MUST remove
this header if you want to issue any other transaction queue changes (such as deleting an entry
from the queue, changing the order, or committing a transaction).
− Click the Step 10: View the Transaction Queue Changes request in the folder. Verify that
command number 4 has moved into position 1 and the order of all other commands has been
updated accordingly.

− Click the Step 11: Commit the Transaction request in the folder. Examine the request type,
URI and JSON body. We will PATCH our transaction resource and change the value of
the state attribute to submit the transaction:
− Click the Send button and examine the response. The state may already be COMPLETED,
however, it’s a good practice to explicitly check for this.
− Click the Step 12: View the Transaction Status request in the folder and click
the Send button. Verify that the state of the transaction is COMPLETED
− You can verify the configuration was created on the BIG-IP device via the BIG-IP A GUI
at https://10.1.1.10
− Verify that the virtual server works by opening http://10.1.20.120 in Chrome web browser
− Once we have a working config we need to save it to the config files. Click the Step 13: Save
to Config Files request in the folder and click the Send button.

Abstracting Services Instructor Presentation
Abstracting Services using AS3 and Ansible

Abstracting Services Instructor Presentation
NOTES
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________

Exercise 2 – Abstracting Services using AS3 and Ansible

• Required virtual images: BIGIP_A_v13.0.0, LAMP_v4
TASK 1 – Installing the App Services 3 Extension

In this Module, we will continue working with the BIG-IP REST interface. However, we will now
introduce F5 Declarative Interfaces built with the App Services 3 Extension (AS3). The AS3
Extension is built on top of the extensible iControl LX framework. iControl LX is based on
Node.js and implements a declarative, application-centric schema for deploying Layer 4-7
Application Services on BIG-IP devices.
For further information on the App Services 3 Extension and iControl LX see:
• GitHub Repository: https://github.com/F5Networks/f5-appsvcs-extension

• Documentation: http://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/3/
• iControl LX overview: https://devcentral.f5.com/wiki/icontrollx.homepage.ashx
Note: This module requires the BIG-IP A network configuration that was completed in Exercise 1.
iControl LX Extensions use the common Redhat Package Manager (RPM) distribution format.
To install an extension you need to first obtain the RPM file associated with the extension.
AS3 RPMs are available at https://github.com/f5networks/f5-appsvcs-extension/releases
AS3 can be installed in a few ways:
• using the iControl REST API

• using the BIG-IP GUI (TMUI)
• using a command prompt
− If needed, re-open your RDP session to the Linux JumpHost desktop.

− To view installed iControl LX Extensions in the BIG-IP GUI you must first enable this functionality.
To do this, log in to the system via SSH (ssh root@10.1.1.10) using root / default and execute:
touch /var/config/rest/iapps/enable
− No reboot is required. This will enable the iApps ‣ Package Management LX menu:

− Clicking Package Management LX will show a table of installed iControl LX Extensions. The
table will be empty until iControl LX Extension packages have been imported.
− This lab work will be performed from Lab 2.2 - Install AS3 onto BIG-IP folder in the
Postman Collection
− Send the Step 1: Get Installed iControl LX Extensions request to view extensions
installed on the BIG-IP device:
Note: If you get an Auth Token failure then redo Lab 1.2 Step 2: from Exercise 1. Remember to paste the
new Auth Token into the Environment variable for bigipA.
− Review the JSON response Body. The JSON payload shows extensions that are installed on the
BIG-IP device in the items array. In this case we have no extensions installed so the items array
is empty.
− Using the Chrome web browser open a new tab and click the AS3 Release bookmark.

− Click the file with the .rpm extension to download it. The file will be located in the
/home/ubuntu/Downloads folder on your JumpHost.
− Click the Step 2: Upload AS3 Extension RPM request.

− Click the Body tab, then click the Choose Files button:
− Select the previously downloaded RPM file located in the Downloads folder on your jumphost.
Then click the Send button to upload the RPM file to the BIG-IP system:
− Review the Test Results to ensure the file upload was successful:
− Click the Step 3: Create AS3 Extension Install Task request and click Send. This
request will command the iControl LX framework to install the RPM uploaded in the previous
step. Because the installation task is an asynchronous operation, we need to check the status of
the task in the next step.
− Click the Step 4: Get AS3 Install Task Status request and click Send.

− Check the Response Body and ensure the task status is FINISHED:
− Click the Step 5: Get AS3 Version Info request and click Send. Review
the Response Body to ensure the AS3 is installed and has started:
Task 2 – Application Service Deployments with AS3

Now that AS3 has been installed on your BIG-IP device, we can deploy new Layer 4 to 7 App Services.
First we’ll review the structure of an AS3 declaration. Then we will Create a Basic HTTP Service,
demonstrate two ways to Modify/Mutate the service by changing the pool member states and adding
pool members, and finally Delete the service. Once we’ve demonstrated these tasks, we’ll introduce
more complex deployment options with iRules, Custom Profiles, Certificates, and an ASM Policy.

This lab work will be performed from Lab 2.3 – Application Service Deployments with AS3
folder in the Postman Collection
− Send the Step 1: Get Deployed AS3 Services request to view current declarations on the
BIG-IP device:
− Review the JSON Response Body. AS3 does not currently have any declarations deployed on the
BIG-IP device. This is indicated in the message attribute:

− Click Step 2: Deploy HTTP_Service. Review the Request JSON Body. The JSON body of the
POST contains the declaration AS3 uses to deploy the service.
− Click the Send button to Create HTTP_Service:
− Review the Response JSON Body to verify if the Service has been deployed. AS3 will return a
status for each Tenant in the declaration along with various statistics. Pay special attention to
the message attribute. In this case the value is success, indicating that the configuration was
deployed to the BIG-IP device successfully. Additionally the implemented declaration is echoed
back so it can be used to auditing and verification as needed:

We’ve just progressed into a Declarative instantiation, by defining the end state and relying on
the AS3 to handle the order of operations and configuration of specific objects. By doing this, we
have drastically reduced the amount of Domain Specific Knowledge required to interact
with the device. In the next module, we will combine this concept with Abstraction to further
simplify the interface the service consumer has to interact with.
− To demonstrate Idempotency, let’s repeat this operation. Click the Send button again
to Create HTTP_Service. Review the Response JSON Body and notice that this time
the message attribute has a value of no change. Because the input declaration did not change,
AS3 simply validated the declaration but did not perform any operations on the BIG-IP device.
− Now that the service has been deployed, let’s review the BIG-IP configuration. You can validate
by sending the Step 1: Get Deployed AS3Services request again.

− In the TMUI GUI, you will now see a Partition has been created that corresponds to
the Tenant1 tenant in our declaration. We must first select this partition in TMUI to view
objects associated with it:
− Examine the Virtual Server that was created by clicking Local Traffic ‣ Virtual Servers ‣
Virtual Server List ‣ serviceMain. The configuration is simple, but it does contain the key
components for an HTTP service (Listener, HTTP Profile, Monitor, Pool, and Pool Members):
− The service is available and active; you can connect to the Virtual Server using Chrome web
browser at http://10.1.20.121 and examine its responses:

Task 3 – Modify our Deployed Service

In this task, we will show how deployments can be modified with AS3. It is important to
understand that AS3 acts on the Full declaration for each tenant. Updates to deployments can
be achieved in two ways:
1. Update the full declaration document and POST the entire declaration
to /mgmt/shared/appsvcs/declare. AS3 will perform a diff operation and apply delta
changes to the BIG-IP system to achieve the desired state.
2. Update an existing declaration by using the PATCH method along with RFC6902 JSON
patch commands. This allows you to edit the most recent declaration AS3 has deployed.
Once the RFC6902 PATCH is applied the resulting full declaration is processed using the
same diff operation as above.
Using the PATCH mechanism can result in a source-of-truth violation if upstream orchestration systems are
not updating their stored version of the declaration document. The implications of this should be fully
understood and accounted for if using PATCH as part of a larger orchestrated workflow.
− Click on Step 3: POST to Modify HTTP_Service. Review the Request URL and JSON Body.
Notice that we are sending a POST to the/mgmt/shared/appsvcs/declare endpoint. We will
send the Full declaration document with the pool members updated so they are NOT enabled:

− Click the Send button to Modify the previously deployed HTTP_Service:
− In the BIG-IP GUI click Local Traffic ‣ Pools ‣ Pool List ‣ Pool1 ‣ Members. Notice that
there are no members listed in the table. Since AS3 is a fully declarative interface it does not
configure pool members when their enable state is false as we specified in the declaration.
The Virtual Server is no longer passing traffic at http://10.1.20.121 because no Members are
available in the Pool:
− Click on Step 4: PATCH to Modify Service_HTTP. Notice that we are using the PATCH
method to the /mgmt/shared/appsvcs/declare endpoint. Review the JSON Body. Notice that
we are sending an array of three operations using the RFC6902 JSON Patch format. The first two
operations in the array will update the enable state to true for our existing pool members. The
third operation adds a new Member to the Pool:

− Click the Send button to update HTTP_Service. Review the Response Body and review
the declaration to see how it was updated.
− In the BIG-IP GUI click Local Traffic ‣ Pools ‣ Pool List ‣ Pool1 ‣ Members. Notice that
there are now three members listed in the table.
− Test the Virtual Server again at http://10.1.20.121

Task 4 – Deploy an HTTPS Service

− Click the Step 5: Deploy Service_HTTPS request and review the Request JSON Body to see
how the service was declared. Notice that we are performing a PATCH to the declaration and
with an add operation:
− Send the Step 5: Deploy Service_HTTPS request to deploy an HTTPS Service with an
SSL/TLS Key, Certificate and Certificate Bundle specified in the declaration.

− Review the configured Virtual Servers in the TMUI GUI. AS3 created a new Virtual Server to
redirect TCP/80 traffic to TCP/443 and configured the Virtual Server to listen on TCP/443
− The configuration of the Virtual Server now uses an SSL/TLS Client profile. The deployment is
now providing SSL Offload for the backend compute nodes.

− Open Chrome and access the service with http://10.1.20.122. It should redirect you
to https://10.1.20.122.
− Send the Step 6: Modify Service_HTTPS to add WAF Policy request to link a policy that
will be used with the Application Security Manager (ASM) module. Review the JSON Body to see
how the policy was attached:
− This deployment recognizes the need for Security from the beginning of the application lifecycle.
It lays the groundwork for Continuous Improvement by having the policy reside in a
repository. It allows us to treat resources as code leading to an Infrastructure as Code (IaC)
methodology. As the policy is updated in the repository, additional automation and
orchestration can be enabled to deploy the policy into the environment. The result is an ability
to rapidly build, test and iterate Layer 7 security policies and guarantee deployment into the
environment.

− In the TMUI GUI, you will notice a ASM policy has been applied to the Virtual Server. In
Application Security, we will see that the policy is applied and set to Blocking mode.
− ASM Policy attached to Virtual Server:
− ASM WAF Policy:

− Click the Step 7: POST to Delete All Services request. Review the JSON Body and notice
that we have declared an empty tenant:
− Click the Send button to remove all services and the Tenant1 partition.
− Send the Step 8: Get Deployed AS3 Services request. Notice you receive a message
indicating no declaration was found.
Task 5 – Deploying AS3 Declarations with Ansible Tower

In the rest of Exercise 2, we will explore how to utilize F5’s AS3 extension with an orchestration
platform such as Ansible Tower. Tower is a workflow orchestration tool which provides an enterprise
solution on top of Ansible including an API, GUI, RBAC, and many other features.
L1-3 Networking and Device Onboarding are highly specific to the particular environment the BIG-IP
instances are deployed on. The onboarding process for various platforms and ecosystems is very different
due to differences in the L1-3 capabilities and APIs of each platform. As a result F5 publishes specific
documentation and guidance for each of these environments:
• Public Cloud - AWS/Azure/GCP/etc.: http://clouddocs.f5.com/cloud/public/v1/

• Private Cloud - OpenStack: http://clouddocs.f5.com/cloud/openstack/
• VMware: https://f5.com/solutions/technology-alliances/vmware
F5 BIG-IP also supports integration with Container Ecosystems. However, in these

environments Ansible Tower may not be required. For more information you can refer to:
• Container Ecosystems:
o Cloud Foundry: http://clouddocs.f5.com/containers/latest/cloudfoundry/
o Kubernetes: http://clouddocs.f5.com/containers/latest/kubernetes
o Mesos Marathon: http://clouddocs.f5.com/containers/latest/marathon
o RedHat OpenShift: http://clouddocs.f5.com/containers/latest/openshift/

L4-7 Application Service Delivery is accomplished by:
• Providing templates within Ansible Tower as a Service Catalog to interact with AS3.
• Utilizing Ansible Tower’s Roll Based Access Control (RBAC) to divide workloads based on user
functions.
The labs in the module will focus on the high-level features in place to achieve full L4-7 automation.
In this Module we will provision Ansible Tower to deploy and modify the AS3 declarations you learned
about in Module 2. The focus of Module 2 was to demonstrate application deployment directly on to
the BIG-IP. Tower will allow the administrator to build an interface and API for users based on their
current role within the organization.
For example, in Module 2 we pushed AS3 declarations, updated pool members, and provided the user
access to modify the full AS3 declaration. This approach would provide each user the same
administrative privileges and may not scale within organizations with separate user functions.
To solve this problem Ansible Tower allows the administrator to create Templates which can provide
further Abstraction of the AS3 declarations. The administrator can enforce specific Tenants or
parameters to be used based on the user running the Template. This abstraction allows the templates
to be integrated directly into the business based CI/CD toolchains and workflows.
In this task we will use the Runner to execute a series of requests contained in the Lab 3.1–Ansible Tower
Onboarding folder.
− Click the Runner button at the top left of your Postman window:

− Select the F5 Programmability: Class 1 Collection then the Lab 3.1 – Ansible Tower
Onboarding folder. Next, be sure the environment is set to F5 Programmability: Class 1:
− Click the Run Lab 3.1 - Ansib… button.

− The results window will now populate. You will see each request in the folder is sent and it’s
associated test results are displayed on the screen. Onboarding Ansible Tower will take about a
minute. You can follow the progress by scrolling down the results window.
− Once the Run Summary button appears the folder has finished running. You should have 0
failures and the last item in the request list should be named
Step 6: Permissions (Pool Member Del Ops).

− At this point you can log into Ansible Tower using Chrome at https://10.1.1.12 and
admin/admin credentials. Browse the main UI tabs to see the different topics covered at the
top of this lab (Projects, Inventories, Templates, etc).
− Select the Settings Icon in the top right corner to view the RBAC items that were created such as
Organization, Teams, Users, and Credentials.

− Open the Ansible Tower GUI in Chrome by navigating to https://10.1.1.12 and login using
T1-admin-user/default credentials.
− Click TEMPLATES in the top menu bar of tower. Notice that there are only two templates now
visible as you are no longer logged in as the Tower admin but as the Tenant1 admin. In this Role
you are able to view what is currently deployed within your Tenant and also POST a new
declaration to AS3 for your Tenant.
− Select the Rocket-Ship Icon next to the Template titled Tenant1_Deploy_Config.

− The model that comes up is the Survey. This takes in the variables which will be passed to
the Ansible Playbook. This example takes two parameters.
o Tenant: This is limited by the RBAC policies that were deployed through Postman. You
are not able to change this value which reduces the blast radius of changes made to your
Tenant (Tenant1).

o Template FIle: This is the source-of-truth JSON file that we will be deploying. For now set
this to f5-https-offload-app.
Select
the LAUNCH button to deploy this configuration.
− Tower will bring you to a page to view the Job running. Wait for the Status located in the top
left to become Green and Successful. - At this point the JSON file was deployed to the BIG-IP.
− Open a Chrome window/tab to the BIG-IP A GUI at https://10.1.1.10 and login with
admin/admin credentials. Navigate to Local Traffic ‣ Virtual Servers. It will take a minute, but
make sure to select Tenant1 Partition in the top right-hand corner to view your AS3 Tenant. You
should see the Application that was created with AS3.

− The template we ran called Tenant1_Deploy_Config calls an Ansible Playbook called

tenant_template.yaml. The key points to notice are:
o tenant_body: This is where Ansible is looking up the base AS3 application.

o body: This object refers to a Jinja2 template. This allows ansible to place variables
provided in the Tower Survey into the AS3 declaration. We will review the Jinja2
template in the next step.
1 ---
2 - name: Update Tenant
3 hosts: bigip
4 gather_facts: false
5 connection: local
6
7 vars:
8 tenant_body: "{{ lookup('url', 'https://<<repo-location>>/{{ f5_template }}.
9 json', split_lines=False) }}"
10 uri_method: "POST"
11 tasks:
12 ##### AS3 POST #####
13 - name: URI POST Tenant
14 uri:
15 url: "https://{{ inventory_hostname }}/mgmt/shared/appsvcs/declare"
16 method: "{{ uri_method }}"
17 user: "admin"
18 password: "admin"
19 validate_certs: no
body: "{{ lookup('template', '../j2/tenant_base.j2') }}"
20
body_format: json
− Lets examine the Jinja2 template that is called by the playbooks below.
o tenant: This is where the Tenant/Partition is inserted into the AS3 playbook. This
prevents the user from editing someone elses Tenant.
o tenant_body: The JSON Source-of-Truth is inserted here.

o Together the two objects above create a complete AS3 Declaration for Tenant1.
1 {
2 "class": "AS3",
3 "action": "deploy",
4 "persist": true,
5 "declaration": {
6 "class": "ADC",
7 "schemaVersion": "3.2.0",
8 "id": "testid",
9 "label": "test-label",
10 "remark": "test-remark",
11 "{{tenant}}":
12 {{tenant_body}}
13 }
14 }
− This same logic could be followed for grouping multiple applications Together under 1
declaration. Testing has been performed to demonstrate AS3s ability to deploy hundreds of
Applications through a single declaration.
− Navigate to Templates in the GUI and select the Rocket-Ship Icon next to the Template
titled Tenant1_View_Config.

− This Template does not have a survey associated with it. When the Job Completes you will be
able to click directly on the JSON output to review the current AS3 Config.
− Open the Ansible Tower GUI in Chrome by navigating to https://10.1.1.12 and login
using T1-ops-user/default credentials.

− Navigate to the Templates section in the Web UI. Notice the difference in Templates available to
the Operations User. This is where breaking up roles to match your organization can really add
value when using Tower. There can be Templates designated for Security, Network Admins, App
Owners, etc.
− Select the Rocket-Ship Icon next to the Template titled Tenant1_Pool_Add_Member

− A Survey will appear asking you to specify the following fields and press LAUNCH:
o Application: This is the AS3 Application Name: Enter A2

o Pool Name: Name of the App Pool: Enter web_pool
o New Member: IP of new Pool Member: Enter 10.1.10.125

− Once you see the Status Success message on the Job Output open a Chrome window/tab to
the BIG-IP A GUI at https://10.1.1.10 and login with admin/admin credentials. Navigate
to Local Traffic ‣ Pools. Make sure to select Tenant1 Partition in the top right hand corner to view
your AS3 Tenant. You should see web_pool listed with 3 members in the pool.
− Click on the 3 pool members to see the one we just added.
− Navigate to the Templates section in the Web UI and Select the Rocket-Ship Icon next to the
Template titled Tenant1_Pool_Delete_Member.

− A Survey will appear asking you to specify the following fields and press LAUNCH:
o Index of Member: IP of new Pool Member: Enter 2
the BIG-IP A GUI at https://10.1.1.10 and login with admin/admin credentials. Navigate
to Local Traffic ‣ Pools. Make sure to select Tenant1 Partition in the top righthand corner to view
your AS3 Tenant. You should see web_pool listed with 2 members again in the pool.
− You have now successfully Added and Removed 10.1.10.125 from the AS3 Application using
Ansible Tower.

− Navigate to the Templates section in the Web UI and Select the Rocket-Ship Icon next to the
Template titled Tenant1_Update_All_Members.
− Before the Survey launches this time, Tower will ask you to fill in extra-vars. This vars will
represent how you would like the pool to be after the Template pushes. You can add or remove
members from the blank as long as the syntax is followed. In this example we are Replacing the
existing members with the same IP but now port 80 instead of 8001.

− Select NEXT and the Survey will appear. Specify the following fields and then to press LAUNCH
the BIG-IP A GUI at https://10.1.1.10 and login with admin/admin credentials. Navigate to
Local Traffic ‣ Pools. Make sure to select Tenant1 Partition in the top righthand corner to view
your AS3 Tenant. You should see web_pool listed with 2 members again but with port 80.
As a quick review, in Exercise 1 we learned the base concepts required to automate the F5 BIG-IP
platform. In Exercise 2 we learned how to automate the F5 BIG-IP platform using a declarative model
with AS3 and Ansible. In the next section we will discuss BIG-IP Cloud Edition.

BIG-IP Cloud Edition Instructor Presentation
BIG-IP Cloud Edition App Templates & Analytics

BIG-IP Cloud Edition Instructor Presentation
NOTES
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________

Exercise 3 – BIG-IP Cloud Edition App Templates & Analytics
Exercise 3 – BIG-IP Cloud Edition App Templates

• Required virtual images: BIGIP_v13.1.1, BIG-IQ v6.0.1 and LAMP_v4
TASK 1 – Verify the BIG-IP Cloud Edition Lab Environment

BIG-IP Cloud Edition has already been partially setup in this lab environment using BIG-IP B, and two BIG-IQ’s.
During this task you will explore the lab environment to see the configuration that was previously setup.
− If needed, re-open your RDP session to the Linux JumpHost desktop.

− Open a web browser and login to BIG-IP B https://10.1.1.11 using admin / admin.F5demo.com.
− Notice in the upper left corner that BIG-IP B is Managed by BIG-IQ.
− Navigate to System > Resource Provisioning and notice that Local Traffic (LTM), Application
Security (ASM) and Application Visibility and Reporting (AVR) are Provisioned.
− Navigate to Local Traffic > Virtual Servers and notice there are 4 Virtual Servers.

− Navigate to Local Traffic > Pools and notice there are 3 Pools.
− Also notice that both the App141 Virtual Server and pool_0 have a Path of Common/App141.
− Navigate to Security > Security Policies and notice there is a policy named linux-high.
− On a 2nd browser tab, log in to BIG-IQ DCD https://10.1.1.14 using admin / admin.F5demo.com.
− Navigate to System > This Device > General Properties and notice the Hostname for this BIG-IQ
is set to bigiqDCD.f5demo.com.
− Navigate to System > Software Management and notice this devices type is Data Collection,
where bigiqCM. f5demo.com is Standalone.
− Log out of bigiqDCD, https://10.1.1.14 and close this browser tab.

− Op a 2nd browser tab, log in to BIG-IQ CM https://10.1.1.13 using admin / admin.F5demo.com.
− Navigate to System > BIG-IQ Data Collection Devices and notice that bigiqDCD. f5demo.com
has already been added as a Data Collection Device.

− Navigate to Devices > BIG-IP Devices and notice that bigipB.f5demo.com has already been
added as a BIG-IP Device at IP Address 10.1.10.11.
− Navigate to Configuration > Local Traffic > Virtual Servers and notice 4 Virtual Servers.
− The App141 Virtual Server and pool_0 were created by BIG-IQ using an Application Template.
− Navigate to Applications > Applications and click the link for App141.

− Under Application Services click Traffic Management, then click Configuration. Notice that the
App141 Virtual Servers are listed and vs_443 maps to the pool.
− Test each of the Virtual Servers to make sure they return valid web pages.
o http://10.1.20.130
o https://10.1.20.131
o https://10.1.20.141
− http://10.1.20.141 should only redirect to https.
TASK 2 – Use Role Based Access Control (RBAC) for App Templates
Create several new admin user accounts on the BIG-IQ system with limited roles, and then use those new user
accounts to view and change the Application configurations.
− If needed, re-log in to BIG-IQ CM at https://10.1.1.13 , using admin / admin.F5demo.com.

− Select the System > User Management > Users page, and then click Add.
− Create a user account using the following information, and then click Save & Close.
Username David
Full Name David NetOps admin
Password and Confirm Admin
Roles Application Editor -> move to Selected

− Create another user using the following information, and then click Save & Close.
Username Paula
Full Name Paula App141 admin
Roles App141 Manager -> move to Selected
− Create another user using the following information, and then click Save & Close.
Username Chris
Full Name Chris SecOps Manager
Roles Service Catalog Editor & Web App Security
Manager -> move to Selected
− Log out of the BIG-IQ system as admin, and then log back in as Paula.
− Notice Paula can see App141 but doesn’t have a Create button for new Applications.
− Log out of the BIG-IQ system as Paula, and then log back in as David.
− Under Applications > Applications, click the Create button, and then select the Default-f5-
HTTPS-offload-lb-template from pulldown menu.
− There is a screen shot on the next page of the entries below for validation.
− Enter the following information, but don’t click Create yet.
General Properties > Name App150

Traffic Environment > BIG-IP bigipB.f5demo.com and then click the
button to Collect HTTP Statistics
Servers > IP Address:Port
10.1.10.102:8002 then click + button
Servers > IP Address:Port 10.1.10.103:8002
Load Balancer > Name App150_vs_443
..…. > Destination Address 10.1.20.150
HTTP Redirect > Name App150_redirect_vs_80

− Your Application screen should look like below but don’t click Create yet.

− Before you click Create, click the View Sample API Request button in upper right corner.
− This is the REST API code BIG-IQ will send to BIG-IP B. It should look familiar from Exercise 1.
− Click the Close button to exit this window.

− Now go ahead and click the Create button.
− After the App150 window appears, click the back arrow  .
− David should now see both App141 and App150 listed.
− Log out of the BIG-IQ system as David, and then log back in as Paula.
− Paula should only see App141 and not App150.
− On a 2nd browser tab access BIG-IP B https://10.1.1.11 , using admin / admin.F5demo.com.
− Select Local Traffic > Virtual Servers. It may take a bit but App150_vs should get added.

TASK 3 – Use BIG-IQ Analytics to Troubleshoot

Generate traffic to App141 and note status is Green. Add a new pool member and note status goes Critical.
− Log out of BIG-IQ CM https://10.1.1.13 as Paula and log in as David.

− Click the link for App150 and note that App150 Health currently shows No Data.
− On a 2nd browser tab access https://10.1.20.150 and refresh the page many times.
− Note that App150 Health changes to Good (Green).
− Click the Servers object, then the Configuration tab.

− Click the Create button, enter IP Address 10.1.100.102 and port 8002, and click Create.
− Wait for this Application change to deploy.

− Check BIG-IP B, Local Traffic > Network Map, and wait for 3rd App150 pool member.
− Back on browser tab for https://10.1.20.150, refresh the page many times.
− After a bit of time the Health of App150 should change to Critical (Red). The reason is the new
Pool Member (Server) doesn’t exist. The correct IP Address is 10.1.10.102.
− On BIG-IP B, Local Traffic > Network Map, watch for 10.1.100.102:8002 to be marked red.
− Also on BIG-IQ, you should see the Server 10.1.100.102:8002 get marked red.
− Last, in the Active Alerts on BIG-IQ you should see Server 10.1.100.102:8002 is offline.
− Select the server 10.1.100.102, port 8002, and click Delete.
− You don’t need to wait for this Application change to deploy.
− Click the Create button, enter IP Address 10.1.10.101 and port 8002, and click Create.
− Wait for this Application change to deploy.
− Check BIG-IP B, Local Traffic > Network Map, and wait for 10.1.10.102:8002 pool member.
− Back on browser tab for https://10.1.20.150, refresh the page many times.
− After a bit of time the Health of App150 should change back to Good (Green).

TASK 4 – Create a WAF protected App using Templates

Create a new App that applies a WAF Security Policy also.
− Login to BIG-IQ CM at https://10.1.1.13 , using Chris / admin as credentials.

− Navigate to Configuration > Security > Web Application Security > Policies and note that
currently the Default Policy for Templates is templates-default and that linux_high is not
Available for Templates.
− Click the link for linux_high, check the box Make available in Application Templates and then
click Save & Close.
− Navigate to Applications > Service Catalog, click the link for Default-f5-HTTPS-WAF-lb-template.
− Click the Clone button in upper part of screen.

− Enter a name of linux-high-WAF and then click Clone.
− Once the Clone is created, select Security Policies, then choose linux-high from the Attached
ASM Policy pull-down menu and click Save & Close.
− Finally, check the box in front of the linux-high-WAF Service Catalog and click Publish.
− Log out as Chris and log back in as David.

− Under Applications, click the Create button, and select the linux-high-WAF Template.

− Enter the following information and click the Create button.
General Properties > Name App160
General Properties > Domain App160.f5demo.com
Traffic Environment > BIG-IP bigipB.f5demo.com and then click the
button to Collect HTTP Statistics
Servers > IP Address:Port
10.1.10.100:8001 then click + button
Servers > IP Address:Port 10.1.10.101:8001
WAF & Load Balancer > Name App160_vs_443
HTTP Redirect > Name App160_redirect_vs_80
− After the App160 window appears, click the back arrow  .

− David should see all three of App141, App150 and App160 listed.
− Click the link for App160, then select Security under Application Services.
− It will take some time to apply the security policy to App160. When the circle next to
Transparent stops spinning you can go on to next step.
− To switch from Transparent to Blocking mode, click Start Blocking.
− After Web Application Security changes to Blocking, click the back arrow  .

− Notice that the Security setting for App160 shows Protected, where both App141 and App150
show Not Protected.
− On a 2nd browser tab access BIG-IP B https://10.1.1.11 , using admin / admin.F5demo.com.
− Select Local Traffic > Virtual Servers, and notice the App160 Virtual Servers have been added.
− Click the link for App160_vs_443, and note that linux_high is set in Security > Policies tab.
You have finished the lab…

Appendix 3 – vLab Diagram
Appendix – Lab Diagram
Linux JumpHost
VMnet1 IP: 10.1.1.20
VMnet2 IP: 10.1.20.20
VLAN: external VLAN: external

Self IP: 10.1.20.10 Self IP: 10.1.20.11
Mgmt IP: 10.1.1.10 Mgmt IP: 10.1.1.11
BIGIP_A_v13.1.0.2 BIGIP_B_v13.1.1
VLAN: internal VLAN: internal
Self IP: 10.1.10.10 Self IP: 10.1.10.11
Mgmt IP: 10.1.1.13 Mgmt IP: 10.1.1.14
BIGIQ_CM_v6.0.1 BIGIQ_DCD_v6.0.1
Linux Server VLAN: internal VLAN: internal
Self IP: 10.1.10.13 Self IP: 10.1.10.14
10.1.10.100
10.1.10.101
10.1.10.102
10.1.10.103

PBC - Automation and Orchestration - Workbook - 2019-03-19

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PBC - Automation and Orchestration - Workbook - 2019-03-19

Caricato da

Copyright:

Formati disponibili

Automation & Orchestration

Partner Exercise Guide

Document version 13.1.J

F5 Worldwide Field Enablement Last Updated: 03/13/2019

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 3

Imperative Automation: BIG-IP iControl REST API .................................................................................... 7

Abstracting Services using AS3 and Ansible............................................................................................ 33

BIG-IP Cloud Edition App Templates & Analytics .................................................................................... 63

Appendix – Lab Diagram ........................................................................................................................ 77

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 5

Imperative Automation: BIG-IP iControl REST API

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 7

Exercise 1 – Exploring the BIG-IP iControl REST API

Task 1 – Access Your Class Application Portal

o Open the icon on desktop labeled Terminal

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 9

Task 2 – Explore the API using the TMOS Web Interface

− Authenticate to the interface using the default credentials (admin/admin)

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 10

/ mgmt / tm / sys / dns

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 11

Task 3 – Setup the Postman tool

− Open the Postman Settings windows by clicking File ‣ Settings

− Verify your client is configured to allow self-signed certificates by

− Click the X in the top right of the Settings window.

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 12

− To assist in multi-step procedures we make heavy use of the Environments capability in

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 13

Task 4 – HTTP BASIC Authentication

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 14

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 15

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 16

Task 5 – Token Based Authentication

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 17

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 18

− Click the ‘F5 Programmability: Class 1’ item:

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 19

Task 6 – Set BIG-IP Device Settings

/mgmt/tm/sys/dns DNS Settings

/mgmt/tm/sys/ntp NTP Settings

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 21

Perform the following steps to configure the VLAN objects/resources:

Perform the following steps to configure the Self IP objects/resources:

Perform the following steps to configure the Route object/resource:

− Click the Send button to create the route.

Task 7 – Building Workflows with Postman Collections

− Click the Lab 1.5 - Building Imperative Workflows folder to expand it

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 23

− Select the F5 Programmability: Class 1 Collection then

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 24

Your Runner window should look like:

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 25

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 26

Task 8 – Build a Basic LTM Config using REST Transactions

Perform the following steps to complete this task:

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 27

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 28

− Click the Send button and examine the response.

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 29

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 30

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 31

Abstracting Services using AS3 and Ansible

F5 WWFE Lab Guide – F5 Automation and Orchestration boot camp Page | 33

Exercise 2 – Abstracting Services using AS3 and Ansible