F5 Programmability Training - Index¶

Task 1 – Explore the API using the TMOS Web Interface¶

In this lab we will explore the API using an interface that is built-in to 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 most practical use cases it’s far easier to use this interface as a ‘Read’ tool rather than trying to Create objects directly from it. It’s usually far easier to use TMUI or TMSH to create the object as needed and then use this tool to view the created object with all the correct attributes already populated.

1. Open Google Chrome and navigate to the following bookmarks: BIG-IP A GUI, BIG-IP B GUI and iWorkflow GUI. Bypass any SSL errors that appear and ensure you see the login screen for each bookmark.

   

2. Navigate to the URL https://10.1.1.4/mgmt/toc (or click the BIG-IP A REST TOC bookmark). The ‘/mgmt/toc’ path in the URL is available on all TMOS versions 11.6 or newer.

3. Authenticate to the interface using the default admin/admin credentials.

4. You will now be 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 on the page. Type ‘net’ in the search box and then click on the ‘net’ link under iControl REST Resources:

5. Find the /mgmt/tm/net/route-domain Collection and click it.

6. You will now see a listing of the Resources that are part of the route-domain(s) collection. As you can see the default route domain of 0 is listed. You can also create new objects by clicking the button. Additionally resources can be deleted using the button or edited using the button.

7. Click the 0 resource to view the attributes of route-domain 0 on the device:

   

   Take note of the full path to the resource. Here is how the path is broken down:

   / mgmt / tm / net / route-domain / ~Common~0
   | Root | OC | OC  |  Collection  | Resource
   *OC=Organizing Collection
   

Task 1 - Import the Postman Collection & Environment¶

In this task you will Import a Postman Collection & Environment for this lab. Perform the following steps to complete this task:

1. Open the Postman tool by clicking the icon of the taskbar of your Windows Jumphost

2. Click the ‘Import’ button in the top left of the Postman window

   

3. Click the ‘Import from Link’ tab. Paste the following URL into the text box and click ‘Import’

   https://raw.githubusercontent.com/f5devcentral/f5-automation-labs/master/postman_collections/F5_Automation_Orchestration_Intro.postman_collection.json
   

   

4. You should now see a collection named ‘F5 Automation & Orchestration Intro’ in your Postman Collections sidebar:

   

5. Import the Environment file by clicking ‘Import’ -> ‘Import from Link’ and pasting the following URL and clicking ‘Import’:

   https://raw.githubusercontent.com/f5devcentral/f5-automation-labs/master/postman_collections/INTRO_Automation_Orchestration_Lab.postman_environment.json
   

6. 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. Set your environment to ‘INTRO - Automation & Orchestration Lab’ by using the menu at the top right of your Postman window:

   

Task 2 – HTTP BASIC Authentication¶

In this task we will use the Postman tool 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 to insert 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 (F5 default) rather than HTTP.

Perform the following steps to complete this task:

1. Click the ‘Collections’ tab on the left side of the screen, expand the ‘F5 Automation & Orchestration Intro’ collection on the left side of the screen, expand the ‘Lab 1.2 – API Authentication’ folder:

   

2. 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 ‘Update Request’ button. 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 ‘Headers’ tab and examine the HTTP header:

   

3. Click the ‘Send’ button to send the request. If the request succeeds you should be presented with a listing of the /mgmt/tm/ltm Organizing Collection.

4. Update the credentials and specify an INCORRECT password. Send the request again and examine the response:

   

Task 3 – 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. Both BIG-IP and iWorkflow support 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, however, authentication to external providers is fully supported.

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

Perform the following steps to complete this task:

1. Click the ‘Step 2: Get Authentication Token’ item in the Lab 1.2 Postman Collection

2. Notice that we send a POST request to the /mgmt/shared/authn/login endpoint.

   

3. Click the ‘Body’ tab and examine the JSON that we will send to BIG-IP to provide credentials and the authentication provider:

   

4. Modify the JSON body and add the required credentials (admin/admin). Then click the ‘Send’ button.

5. Examine the response status code. If authentication succeeded and a token was generated the response will have a 200 OK status code. If the status code is 401 then check your credentials:

   Successful:

   • 

   Unsuccessful:

   • 

6. 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:

   

7. 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 to be sent on all requests when using token based authentication.

   

8. Click the ‘Send’ button. If your request is successful you should see a ‘200 OK’ status and a listing of the ltm Organizing Collection.

9. We will now update your Postman environment to use this auth token for the remainder of the lab. Click the Environment menu in the top right of the Postman window and click ‘Manage Environments’:

   

10. Click the ‘INTRO – Automation & Orchestration Lab’ item:

    

11. Update the value for bigip_a_auth_token by Pasting (Ctrl-v) in your auth token:

    

12. Click the ‘Update’ button and then close the ‘Manage Environments’ window. Your subsequent requests will now automatically include the token.

13. 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 so we can complete the lab easily. 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 4 – Get a pool ‘example’ Template¶

In order to assist with REST API interactions you can request a template of the various attributes of a Resource type in a Collection. This template can then be used as the body of a POST, PUT or PATCH request as needed.

Perform the following steps:

1. Click the ‘Step 5: Get ‘example’ of a Pool Resource’ item in the Lab 1.2 Postman collection

2. Examine the URI. Notice the addition of example at the end of the collection name:

   

3. Click ‘Send’ and examine the FULL response. You will see descriptions and then all the attributes for the Pool resource type. The response also shows the default values for the attributes if applicable:

   

Task 1 – Set Device Hostname & Disable GUI Setup Wizard¶

In this task 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:

1. Expand the “Lab 1.3 – Review/Set Device Settings” folder in the Postman collection
2. Click the “Step 1: Get System Global-Settings” item. Click the ‘Send’ button and review the response body to see what the current settings on the device are.
3. Click the “Step 2: Set System Global-Settings” item. 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.
   • Review the JSON body and modify the ‘hostname’ attribute to set the hostname to bigip-a.f5.local
   • Also notice that we are disabling the GUI Setup Wizard as part of the same request:
4. Click the ‘Send’ button and review the response body. You should see that the attributes modified above have been updated. You can also GET the global-settings again to verify they have been updated.

Task 2 – Modify DNS/NTP Settings¶

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:

Perform the following steps to complete this task:

1. Click the “Step 3: Get System DNS Settings” item in the collection. Click ‘Send’ and review the current settings
2. Click the “Step 4: Set System DNS Settings” item in the collection. 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 for both of these attributes.
3. Click the ‘Send’ button and verify the requested changes were successfully implemented
4. Click the “Step 5: Get System NTP Settings” item in the collection. Click ‘Send’ and review the current settings
5. Click the “Step 6: Set System NTP Settings” item in the collection. 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!)
6. Click the ‘Send’ button and verify the requested changes were successfully implemented

Task 3 – Update default user account passwords¶

In this task we will update the passwords for the ‘root’ and ‘admin’ accounts. The process for updating the root account is different then other system accounts due to the special nature of the root account.

To update the root account password we will use a POST to a shared REST worker at /mgmt/shared/authn/root

To update all other system accounts we will PATCH the /mgmt/auth/user/<username> Resource

Perform the following steps to change the root user password:

1. Click the “Step 7: Set root User Password” item in the collection.

2. Notice that we a performing a POST operation to a shared REST worker. Modify the JSON body to update the password to the value “newdefault” and click the ‘Send’ button.

   

3. You can verify the password was changed by opening an SSH session using PuTTY to BIG-IP-A.

4. Repeat the procedure above to change the password back to “default”

Perform the following steps to change the admin user password:

1. Click the “Step 8: Set admin User Password” item in the collection.

2. Notice that we a performing a PATCH operation to admin user Resource. Modify the JSON body to update the password to the value “newadmin” and click the ‘Send’ button.

   

3. You can verify the password was changed by opening an SSH session using PuTTY to BIG-IP-A OR by logging into TMUI in a Chrome browser tab.

4. Repeat the procedure above to change the password back to “admin”

Task 1 – Create VLANs¶

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

1. Expand the “Lab 1.4 – Basic Network Connectivity” folder in the Postman collection.
2. Click the “Step 1: Create a VLAN” item in the collection. Examine the JSON body; the values for creating the Internal VLAN have already been populated.
3. Click the ‘Send’ button to create the VLAN
4. Repeat Step 1, however, this time modify the JSON body to create the External VLAN using the parameters in the table above.
5. Click the “Step 2: Get VLANs” item in the collection. Click the ‘Send’ button to GET the VLAN collection. Examine the response to make sure both VLANs have been created.

Task 2 – Create Self IPs¶

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

1. Click the “Step 3: Create a Self IP” item in the collection. Examine the JSON body; the values for creating the Self-Internal Self IP have already been populated.
2. Click the ‘Send’ button to create the Self IP
3. Repeat Step 1, however, this time modify the JSON body to create the Self-External Self IP using the parameters in the table above.
4. Click the “Step 4: 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.

Task 3 – Create Routes¶

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

1. Click the “Step 5: Create a Route” item in the collection. Examine the JSON body; the values for creating the Default Route have already been populated.
2. Click the ‘Send’ button to create the Route
3. Click the “Step 6: Get Routes” item in the collection. Click the ‘Send’ button to GET the routes collection. Examine the response to make sure the route has been created.

Task 1 – Rename objects and Setup CMI Global Parameters¶

In this task we will complete Items 1&2 from the list high-level procedure at the beginning of the lab. One of the idiosyncrasies of BIG-IP is that when you use the GUI Setup Wizard to set the hostname of the device, the wizard automatically renames the CMI ‘Self’ device to match the hostname. Since we configured the hostname via a REST call earlier this action did not take place.

Perform the following steps to rename the CMI ‘Self’ device:

1. Expand the “Lab 1.5 – Build a Cluster” folder in the Postman collection
2. Click the “Step 1: Rename the CMI Self Device’ item in the collection
3. Examine the URI and JSON body. We are sending a POST request to execute the equivalent of a tmsh mv command to rename the existing object to the /mgmt/tm/cm/device Collection. The name attribute specifies the current name of the object (the factory default name), while the target attribute specifies the new name of the object.
4. Click the ‘Send’ button to rename the Resource.
5. Change the request type from a POST to a GET and click ‘Send’. Examine the response to make sure the name was changed successfully.

Perform the following steps to set CMI Device Parameters

1. Click the “Step 2: Set BIGIP-A CMI Device Parameters” item in the collection. Examine the operation (PATCH), URI and JSON body. We will PATCH the newly renamed object (from the previous step) and assign the Config Sync IP, Unicast Failover Address/Port and Mirroring IPs:

   

2. Click the ‘Send’ button and examine the response to ensure the settings were changed

3. Click the “Step 3: Set BIGIP-B CMI Device Parameters” item in the collection. Examine the operation (PATCH), URI and JSON body. We will PATCH and assign the Config Sync IP, Unicast Failover Address/Port and Mirroring IPs.

   EXTRA CREDIT: How is authentication to BIG-IP-B working if we never got an authentication token? (Hint: we cheated)

4. Click the ‘Send’ button and examine the response to ensure the settings were changed

Task 2 – Add BIG-IP-B as a Trusted Peer¶

The CMI subsystem relies on a PKI based device trust model to establish relationships between BIG-IP systems. In this task we will add BIG-IP-B as a trusted peer of BIG-IP-A. Establishing a trust relationship is automatically a bi-directional operation. As a result, when we establish the trust relationship, BIG-IP-B will automatically establish a trust relationship with BIG-IP-A. This task corresponds to items 3&4 in the high-level procedure.

Perform the following steps to complete this task:

1. Click the “Step 4: Add BIGIP-B Device to CMI Trust on BIGIP-A” item in the collection

2. Examine the operation (POST), URI and JSON body. We are using a special REST worker to add the device to the CMI trust. Additionally the JSON body must be specified in a very specific manner to ensure this step completes successfully. To minimize the chance for error the values have been completed for you already. You should, however, review and understand this step fully before continuing.

3. Click the ‘Send’ button. The response for this request does NOT indicate success, only that the command is running.

4. To check for success we have to check the status of the Sync Group named “device_trust_group”. To do this click the “Step 5: Check Sync Group Status” item in the collection. This request will GET the sync status for all sync groups on the system

5. Click the ‘Send’ button and examine the response. The status should indicate a color of ‘green’, that bigip-b.f5.local is connected and ‘In Sync’ (please notify an instructor of any issue):

   

Task 3 – Create a sync-failover Device Group¶

This task will create a Device Group object that will contain the two BIG-IP systems. The type of device-group will be a ‘sync-failover’ group, however, ‘sync-only’ groups can also be created with the same procedure but different attribute values. This task corresponds to items 5-8 in the high-level procedure.

Perform the following steps to complete this task

1. Click the “Step 6: Create Device Group” item in the collection. Examine the request type, URL and JSON body. We will POST to the ‘/mgmt/tm/cm/device-group’ collection and create a new Resource called DeviceGroup1 that includes both BIG-IP devices and is set to ‘sync-failover’ type. We are also setting the device-group to ‘autosync’ so manual syncing is not required when configuration changes occur:

   

2. Click the ‘Send’ button and examine the response.

3. To check the status of the device-group we have to check the status of the underlying sync group on the system. Click the ‘Step 7: Check Sync Group Status’ item in the collection and click ‘Send’. Examine the response and take note that the system is ‘Awaiting Initial Sync’:

   

4. We will now manually sync DeviceGroup1 to fulfill the need for the Initial Sync. Click the ‘Step 8: Manually Sync DeviceGroup1’ item in the collection. Examine the request type, URL and JSON body. We will POST to the ‘/mgmt/tm/cm/config-sync’ worker and tell it to ‘run’ a config-sync of BIG-IP-A ‘to-group’ DeviceGroup1:

   

5. Click ‘Send’ to initiate the sync

6. Click the ‘Step 9: Check Sync Group Status’ item in the collection and click the ‘Send’ button. Examine the response to make sure that DeviceGroup1 is ‘In Sync’. You may have to click ‘Send’ multiple times as the sync operation can take a while to complete.

Task 4 – Perform Additional Operations¶

The remainder of the steps show how to manipulate various common items related to the HA config. In this task we will change the Traffic Group to use the ‘HA Order’ failover method. We will then initiate a failover and show how to view the status of the traffic-group.

Perform the following steps to complete this task:

1. Click the “Step 10: Get Traffic Group Properties” item in the collection. Examine the URL, we will GET the attributes of the ‘traffic-group-1’ resource from the traffic-group collection. Click the ‘Send’ button and review the response.

2. Click the “Step 11: Change Traffic Group to use HA Order” item in the collection. Examine the request type, URL and JSON body. We will PATCH the existing resource and specify an ‘haOrder’ attribute to change the traffic-group behavior.

3. Click the ‘Send’ button and examine the response to verify the change was successful.

4. Click the “Step 12: Get Traffic Group Failover States” item in the collection and click the ‘Send’ button. Examine the response and determine which device is ‘active’ for the traffic-group:

   

5. Click EITHER the “Step 13A” or “Step 13B” item in the collection depending on which device is ACTIVE for the traffic group. Notice that we are sending the request to the ACTIVE device for the traffic group. Examine the JSON body and click the ‘Send’ button.

6. Click the “Step 14: Get Traffic Group Failover States” item in the collection and click the ‘Send’ button. Examine the response to determine that the failover occurred properly:

   

Task 5 – Create Floating Self IPs¶

To complete the HA config we will now create a Floating Self IP on the Internal VLAN.

Perform the following steps to complete this task:

1. Click the “Step 15: Create a Floating Self IP” item in the collection. Examine the request type, URL and JSON body. We will create a new resource in the /mgmt/tm/net/self collection named ‘Self-Internal-Floating’ and an IP address of 10.1.10.3.
2. Click the ‘Send’ button and examine the response
3. Click the “Step 16: Get Self IPs” item in the collection and click ‘Send’. Examine the response and verify the Self IP was created.

Task 1 – Build a Basic LTM Config¶

Perform the following steps to complete this task:

1. Expand the “Lab 1.6 – Build a Basic LTM Config” folder in the Postman collection
2. Click each Step in the folder and ‘Send’ the request. Verify each component is created on the BIG-IP device using the GUI.
3. After the steps are completed you should be able to connect to http://10.1.20.129 in your browser.

Task 1 – Create a Transaction¶

In this lab we will create a transaction using the REST API. Transactions are very useful in cases where you would want 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. This is very useful when creating a configuration that is linked together because it allows the 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 commiting.

Perform the following steps to complete this task:

1. Expand the ‘Lab 1.7 – Rest API Transactions’ folder in the Postman collection:

   

2. Click the ‘Step 1: Create a Transaction’ item. Examine the URL and JSON body. We will send a POST to the /mgmt/tm/transaction worker with an empty JSON body to create a new transaction.

   

3. Click the ‘Send’ button to send the request. Examine the response and find the ‘transId’ attribute.

   

4. Save the value of this attribute in the bigip_transaction_id environment variable. Additionally notice that there are timeouts for both the submission of the transaction and how long it should take to execute. Be aware that after the ‘timeoutSeconds’ value, this transId will be silently removed:

   

5. Click the ‘Step 2: Add to Transaction: Create a HTTP Monitor’ item in the Postman collection. This request is the same as a non-transaction enabled request in terms of the request type (POST), URI and JSON body. The difference is we add a X-F5-REST-Coordination-Id header with a value of the transId attribute to add it to the transaction:

   

6. Click the ‘Send’ button and examine the response

7. Examine and click ‘Send’ on Steps 3-6 in the collection

8. Click ‘Step 7: View the Transaction queue’. Examine the request type and URI and click ‘Send’. This request allows you to see the current list of commands (ordered) that are in the transaction.

Task 2 – Modify a Transaction¶

1. Click the ‘Step 8: View queued command 4 from Transaction’ item in the collection. Examine the request type and URI. We will GET the queued command number 4 from the transaction list.

   

2. Click the ‘Step 9: Change Eval Order 4 ->1’ item in the collection. Examine the request type, URI and JSON body. We will PATCH our transaction resource and change the value of the ‘evalOrder’ attribute, from 4 to 1, to move at the first position of the transaction queue:

3. Click the ‘Step 10: View the Transaction queue changes’ item in the collection. Examine that the transaction number 4 has moved into position 1 and all other transactions eval order has moved accordingly.

Task 3 – Commit a Transaction¶

1. Click the ‘Step 11: Commit the Transaction’ item in the collection. 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:

   

2. Click the ‘Send’ button and examine the response.

3. Verify the config was created using TMUI or REST requests.

Task 1 – Token Based Authentication¶

In this task we will demonstrate TBA using the local authentication database, however, authentication to external providers is fully supported.

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

Perform the following steps to complete this task:

1. Click the ‘Step 1: Get Authentication Token’ item in the Lab 2.1 Postman Collection

2. Notice that we are sending a POST request to the /mgmt/shared/authn/login endpoint.

   

3. Click the ‘Body’ tab and examine the JSON that we will send to iWorkflow to provide credentials:

   

4. Modify the JSON body and add the required credentials (admin/admin). Then click the ‘Send’ button.

5. Examine the response status code. If authentication succeeded and a token was generated the response will have a 200 OK status code. If the status code is 401 then check your credentials:

   Successful:

   • 

   Unsuccessful:

   • 

6. 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:

   

7. Click the ‘Step 2: Verify Authentication Works’ item in the Lab 2.1 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 to be sent on all requests when using token based authentication.

   

8. Click the ‘Send’ button. If your request is successful you should see a ‘200 OK’ status and a listing of the ‘ltm’ Organizing Collection.

9. We will now update your Postman environment to use this auth token for the remainder of the lab. Click the Environment menu in the top right of the Postman window and click ‘Manage Environments’:

   

10. Click the ‘INTRO – Automation & Orchestration Lab’ item:

    

11. Update the value for ‘iwf_auth_token’ by Pasting (Ctrl-v) in your auth token:

    

12. Click the ‘Update’ button and then close the ‘Manage Environments’ window. Your subsequent requests will now automatically include the token.

13. Click the ‘Step 3: 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 so we can complete the lab easily. 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 1 – Discover BIG-IP Devices¶

Perform the following steps to complete this task:

1. Expand the “Lab 2.2: Discover & License BIG-IP Devices” folder in the Postman collection

2. Open a Google Chrome window/tab to your iWorkflow device (https://10.1.1.6) and login with default credentials (admin/admin). You can use this window to monitor actions while they are being performed in Postman. Find the ‘Devices’ pane and make if viewable if it isn’t already.

3. Click the “Step 1: Discover BIGIP-A Device” item in the Postman collection. This will request will perform a POST to the /mgmt/shared/resolver/device-groups/cm-cloud-managed-devices/devices worker to perform the device discovery process. Examine the JSON body so you understand what data is sent to perform the discovery process:

   

4. Click the ‘Send’ button. Examine the response and monitor the iWorkflow Chrome window you opened previously.

   

5. Copy the ‘uuid’ attribute for BIGIP-A and populate the ‘iwf_bigip_a_uuid’ Postman environment variable with the value:

   

6. Click the “Step 2: Discover BIGIP-B Device” item in the collection.

7. Click the “Step 3: Get Discovered Devices” item in the collection. We will GET the devices collection and verify that both BIG-IP devices show a ‘state’ of ‘ACTIVE’:

   

Task 1 – Create a Tenant and Tenant User¶

In this task we will create a Local Connector that is linked to our BIG-IP devices. The Local Cloud Connector is DSC aware and will automatically detect that the BIG-IP devices are clustered and configure itself accordingly.

Perform the following steps to complete this task:

1. Expand the “Lab 2.3 – Create Tenant & Local Connector” folder in the Postman collection.
2. Click the “Step 1: Create iWorkflow Tenant” item in the collection and click ‘Send’. This request will create a tenant named MyTenant.
3. Click the “Step 2: Create Tenant User” item in the collection and click ‘Send’. This request will create a tenant user.
4. Click the “Step 3: Assign User to Tenant Admin Role” item in the collection and click ‘Send’. This request will assign the Admin role for the MyTenant tenant to the tenant user.

Task 2 - Create a Local Connector¶

1. Click the “Step 4: Create a Local Connector” item in the collection. We will create a new connector by performing a POST to the local connector collection. If you examine the JSON body you can see we are providing a reference to the URL for the BIG-IP-A device (using the UUID environment variable we populated earlier):

   

2. Click the ‘Send’ button to create the connector.

3. Click the “Step 5: Get Local Connectors” item in the collection and click ‘Send’. Examine the output to see how the connector was configured. Take note of the reference to the ‘device-group’. This is how the connector determines the HA state of the underlying BIG-IP devices. Find the ‘connectorId’ of the connector and update your Postman environment to include the ‘connectorId’ as the value of the ‘iwf_connector_uuid’ variable:

   

4. Click the “Step 6: Assign Connector to Tenant” item in the collection. This request will assign this connector to to the ‘MyTenant’ tenant allowing service deployments from that tenant. Click the ‘Send’ button and examine the response.

Task 1 - Install the App Services iApp on iWorkflow¶

iWorkflow serves as the Source-of-Truth for iApp templates. As a result iApp templates that will be used to automate deployments on BIG-IP must be installed on iWorkflow first. Once installed, iWorkflow will automatically determine when a template needs to be installed on BIG-IP and perform the needed actions.

To assist in deployment of the App Services iApp template and its associated sample service templates a Postman collection has been created. We will first import the collection into Postman and then use it to install the template into iWorkflow.

Perform the following steps to complete this task:

1. Import the following collection URL using ‘Import’ -> ‘Import from Link’:

   https://raw.githubusercontent.com/f5devcentral/f5-automation-labs/master/postman_collections/AppSvcs_iApp_Workflows.postman_collection.json
   

2. Expand the AppSvcs_iApp_Workflows collection. Then open the 2_Install_on_iWorkflow folder and click the Install AppSvcs Template on iWorkflow item.

3. You can examine the Body of this request, however, understand that it contains the minified code that comprises the iApp and will not be very readable. This collection uses the underlying variables that have already been set (iwf_mgmt and iwf_auth_token) to make installation simple.

4. Click the ‘Send’ button to install the iApp.

Task 2 – Create the f5-http-lb L4–7 Service Template¶

An L4-7 Service Deployment on iWorkflow is driven by the creation of an L4 – L7 Service Template. These templates allow a provider (administrator) to specify the values of specific fields from an origin iApp presentation layer. Additionally, the provider also defines the tenant interface to the service by marking which fields are ‘Tenant Editable’ and therefore visible during service deployment from the tenant. You can think of a Service Catalog Template as a filter that allows the vast majority of fields to be filled in or defaulted while only exposing the minimal set of fields required to deploy a service.

In this task we will create a Service Catalog Template that utilizes the App Services iApp you just installed.

Perform the following steps to complete this task:

1. Expand the 3_iWorkflow_Service_Templates_Examples folder of the AppSvcs_iApp_Workflows collection

2. Click the “f5-http-lb Template” item in the collection. This request is pre-built and will create a new Service Template using the App Services iApp. Click the ‘Send’ button to create the template.

3. Open a Chrome tab to iWorkflow (https://10.1.1.6) and login with admin/admin credentials. Expand the ‘Service Templates’ pane and double-click the “f5-http-lb” template. Notice various defaults have been populated (e.g. port ‘80’ for the pool__port variable) and some fields have been marked as ‘Tenant Editable’:

   

Task 2 – Tenant L4-7 Service Deployment¶

In this task we will perform CRUD operations based on a deployment of the Service Catalog Template created in the previous task.

Perform the following steps to complete this task:

1. Open a new Chrome tab to iWorkflow (https://10.1.1.6) and login with the credentials Username: tenant, Password: tenant. Expand the ‘L4-L7 Services’ pane.

2. Switch back to F5 Automation & Orchestration Intro Postman Collection and click the “Step 1: Create TENANT Service Deployment” item in Lab 2.4. Examine the URL and JSON body. We will be creating a new Tenant Service Deployment under ‘MyTenant’ with the properties marked as ‘Tenant Editable’ provided:

   

3. Click the ‘Send’ button to create the Service Deployment. Examine the response. The iWorkflow GUI in your Chrome tab will also reflect a new item in the Services pane:

   

4. Open a Chrome tab to BIGIP-A. Click on iApps -> Application Services -> Applications -> example-f5-http-lb to view the config that was deployed on BIG-IP:

   

5. Go back to Postman and click the “Step 2: Get TENANT Service Deployment” item in the collection and click ‘Send’. This item is an example of a Read operation of the service definition. The response should match what you see in the iWorkflow GUI when viewing the properties of a deployment.

6. Click the “Step 3: Modify TENANT Service Deployment” item in the collection. This request is an example of an Update operation. Notice that we are sending a PUT request to the URL representing the service deployment. Examine the JSON body and note that in the ‘pool__Members’ table there is an additional pool member with an IP of 10.1.10.12 that will be added. Click the ‘Send’ button to re-deploy the service:

   

7. Verify that the pool member was added on BIG-IP:

   

8. Go back to Postman and click the “Step 4: Delete TENANT Service Deployment” item. This item will send a DELETE request to the URL for the service deployment. Click ‘Send’ and verify that the deployment has been removed in the iWorkflow and BIG-IP GUIs.

Task 1 – Perform REST operations via the REST Proxy¶

In this task we will perform a sample CRUD operation utilizing the REST Proxy. The intent of this task is to show the basic mechanism used to perform these tasks. Simply changing the URL to include the iWorkflow REST Proxy root for that device could easily change all the Imperative operations we have completed in this lab to use the REST Proxy.

Perform the following steps to complete this task:

1. Expand the “Lab 2.5 – iWorkflow REST Proxy” folder in the Postman collection.

2. Click the “Step 1: Create pool on BIGIP-A”. Examine the request type, URL and JSON body. Essentially we are performing a POST to the ‘/mgmt/tm/ltm/pool’ collection on BIGIP-A. The last part of the URL includes this URI path (the part after ‘…./rest-proxy/’). The JSON body and all other parameters are passed unaltered. Also, notice that we are still using our iWorkflow Token to authenticate, not the BIG-IP one.

   

3. Click the “Send” button and examine the response.

4. Complete steps 2-5 for the remaining items in the “Lab 2.5 – iWorkflow REST Proxy” collection. Examine each request carefully so you understand what is happening.

Task 1 – Install Docker CE¶

Please follow the instructions at https://docs.docker.com/engine/installation/ to install Docker CE.

Once you have completely installed and successfully run the hello-world test you can continue to the next lab.

To test your setup with the hello-world container, you just need to run the following command

docker run hello-world

Example output:

$ sudo docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
78445dd45222: Pull complete
Digest: sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://cloud.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

Task 1 – Obtain the container image¶

Perform the following steps to complete this task:

1. Open a Command Prompt

1. Execute docker pull f5devcentral/f5-super-netops-container:develop-jenkins

   Example output:

   $ docker pull f5devcentral/f5-super-netops-container:develop-jenkins
   develop-jenkins: Pulling from f5devcentral/f5-super-netops-container
   019300c8a437: Pull complete
   2d6b38b56ae7: Pull complete
   5fab9174d5b4: Pull complete
   fc0251c85d81: Pull complete
   d5c1476cba25: Pull complete
   3f563aeb530f: Pull complete
   56717b902584: Pull complete
   3a973f5ee17d: Pull complete
   68d52f474d41: Pull complete
   604d6366bf0b: Pull complete
   b3b4184aef22: Pull complete
   2cebe1f5955c: Pull complete
   2b7bce9d0d9e: Pull complete
   259f696f7766: Pull complete
   6d5f2e57c5b3: Pull complete
   985706ad6d05: Pull complete
   a29f68892227: Pull complete
   7420ee096abd: Pull complete
   0907797bbe90: Pull complete
   5b8f2518bf01: Pull complete
   2940be145e35: Pull complete
   f2cb35cbf665: Pull complete
   5cdfa1779954: Pull complete
   61c1367b68d8: Pull complete
   5bcd8c5223bb: Pull complete
   b0defdb83b82: Pull complete
   Digest: sha256:27563f98bf58c9d26eb5989acaf540a9ad7fb1806e4a4c373ad28769ebe63ef4
   Status: Downloaded newer image for f5devcentral/f5-super-netops-container:develop-jenkins
   

2. Execute docker images

   Example output:

   $ docker images
   REPOSITORY                               TAG                 IMAGE ID            CREATED             SIZE
   f5devcentral/f5-super-netops-container   develop-jenkins     b71fc40407e4        2 weeks ago         490MB
   

Task 2 – Start the container image¶

To start the container we will execute the command:

docker run -p 8080:80 -p 2222:22 -p 10000:8080 --rm -it -e SNOPS_GH_BRANCH=develop f5devcentral/f5-super-netops-container:develop-jenkins

The -p option publishes a L4 port from the container to the host. For example the -p 8080:80 option will redirect port 8080 on the host system to port 80 in the container.

The -it option will make the session interactive and allocate a pseudo-TTY

The -e option will specify a Github Branch, in this case we are pulling from develop

The f5devcentral/f5-super-netops-container:develop-jenkins option is the name associated with the image we obtained in Task 1.

Perform the following steps to complete this task:

1. Execute docker run -p 8080:80 -p 2222:22 -p 10000:8080 --rm -it -e SNOPS_GH_BRANCH=develop f5devcentral/f5-super-netops-container:develop-jenkins

   Note

   The image requires Internet connectivity to download the latest versions of tools and documentation. Please ensure you have proper connectivity from your host prior to starting the image. If you need to use a proxy please refer to the documentation at https://docs.docker.com

   The image will now start and load resources from the Internet. This process may take a while depending on the speed of your connection. When the startup process is complete you will be presented with a root user prompt. You can interact with the image with standard Linux commands. In the next lab we will connect to the image via SSH and HTTP.

   Example startup output:

   container:develop-jenkins
   [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
   [s6-init] ensuring user provided files have correct perms...exited 0.
   [fix-attrs.d] applying ownership & permissions fixes...
   [fix-attrs.d] done.
   [cont-init.d] executing container initialization scripts...
   [cont-init.d] done.
   [services.d] starting services
   [services.d] done.
   [environment] SNOPS_HOST_SSH=2222
   [environment] SNOPS_REPO=https://github.com/f5devcentral/f5-super-netops-container.git
   [environment] SNOPS_AUTOCLONE=1
   [environment] SNOPS_HOST_IP=172.17.0.2
   [environment] SNOPS_ISALIVE=1
   [environment] SNOPS_GIT_HOST=github.com
   [environment] SNOPS_REVEALJS_DEV=0
   [environment] SNOPS_HOST_HTTP=8080
   [environment] SNOPS_IMAGE=jenkins
   [environment] SNOPS_GH_BRANCH=develop
   Reticulating splines...
   Becoming self-aware...
   [cloneGitRepos] Retrieving repository list from https://github.com/f5devcentral/f5-super-netops-container.git#develop
   [updateRepos] Processing /tmp/snops-repo/images/jenkins/fs/etc/snopsrepo.d/jenkins.json
   [updateRepos]  Processing /tmp/snops-repo/images/base/fs/etc/snopsrepo.d/base.json
   [updateRepos] Processing /tmp/user_repos.json
   [cloneGitRepos] Loading repositories from /home/snops/repos.json
   [cloneGitRepos] Found 7 repositories to clone...
   [cloneGitRepos][1/7] Cloning f5-sphinx-theme#master from https://github.com/f5devcentral/f5-sphinx-theme.git
   [cloneGitRepos][1/7]  Installing f5-sphinx-theme#master
   [cloneGitRepos][2/7] Cloning f5-super-netops-container#develop from https://github.com/f5devcentral/f5-super-netops-container.git
   [cloneGitRepos][2/7]  Installing f5-super-netops-container#develop
   [cloneGitRepos][3/7] Cloning f5-application-services-integration-iApp#develop from https://github.com/F5Networks/f5-application-services-integration-iApp.git
   [cloneGitRepos][3/7]  Installing f5-application-services-integration-iApp#develop
   [cloneGitRepos][4/7] Cloning f5-postman-workflows#develop from https://github.com/0xHiteshPatel/f5-postman-workflows.git
   [cloneGitRepos][4/7]  Installing f5-postman-workflows#develop
   [cloneGitRepos][5/7] Cloning f5-automation-labs#master from https://github.com/f5devcentral/f5-automation-labs.git
   [cloneGitRepos][5/7]  Installing f5-automation-labs#master
   [cloneGitRepos][6/7] Cloning ultimate-vimrc#master from https://github.com/amix/vimrc.git
   [cloneGitRepos][6/7]  Installing ultimate-vimrc#master
   [cloneGitRepos][7/7] Cloning reveal-js#master from https://github.com/hakimel/reveal.js.git
   [cloneGitRepos][7/7]  Installing reveal-js#master
                                   .----------.
                                  /          /
                                 /   ______.'
                           _.._ /   /_
                         .' .._/      '''--.
                         | '  '___          `.
                       __| |__    `'.         |
                      |__   __|      )        |
                         | | ......-'        /
                         | | \          _..'`
                         | |  '------'''
                         | |                      _
                         |_|                     | |
    ___ _   _ _ __   ___ _ __          _ __   ___| |_ ___  _ __  ___
   / __| | | | '_ \ / _ \ '__| ______ | '_ \ / _ \ __/ _ \| '_ \/ __|
   \__ \ |_| | |_) |  __/ |   |______|| | | |  __/ || (_) | |_) \__ \
   |___/\__,_| .__/ \___|_|           |_| |_|\___|\__\___/| .__/|___/
             | |                                          | |
             |_|                                          |_|
   
   Welcome to the f5-super-netops-container.  This image has the following
   services running:
   
    SSH  tcp/22
    HTTP tcp/80
   
   To access these services you may need to remap ports on your host to the
   local container using the command:
   
    docker run -p 8080:80 -p 2222:22 -it f5devcentral/f5-super-netops-container:base
   
   From the HOST perspective, this results in:
   
    localhost:2222 -> f5-super-netops-container:22
    localhost:8080 -> f5-super-netops-container:80
   
   You can then connect using the following:
   
    HTTP: http://localhost:8080
    SSH:  ssh -p 2222 snops@localhost
   
   Default Credentials:
   
    snops/default
    root/default
   
   Go forth and automate!
   
   (you can now detach by using Ctrl+P+Q)
   
   [root@f5-super-netops] [/] #
   

Task 3 - Detach/Re-attach the Container¶

When running containers it’s important to understand that it will exit if the foreground process (in this case the shell) exits. For example, if you typed the exit command in the running container it will shutdown. In order to avoid this you should detach from the container once it has completed booting. You can still perform functions by using SSH to access the container as explained in the next lab.

Task 1 – Connect via SSH¶

To connect to the image via SSH we must use the published port specified in the docker run command. To review the command used to start the container was:

docker run -p 8080:80 -p 2222:22 -p 10000:8080 --rm -it -e SNOPS_GH_BRANCH=develop f5devcentral/f5-super-netops-container:develop-jenkins

This will publish the standard SSH service on TCP/22 to TCP/2222 on the Docker host. In the case of the SSH service the following mapping applies:

localhost:2222 -> f5-super-netops-container:22

Additionally the container includes the snops user with a password of default. To connect to the container execute the following command or it’s OS-specific equivalent:

ssh -p 2222 snops@localhost

Host localhost
Port 2222
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Example output:

$ ssh -p 2222 snops@localhost
Warning: Permanently added '[localhost]:2222' (ECDSA) to the list of known hosts.
snops@localhost's password:
                                .----------.
                               /          /
                              /   ______.'
                        _.._ /   /_
                      .' .._/      '''--.
                      | '  '___          `.
                    __| |__    `'.         |
                   |__   __|      )        |
                      | | ......-'        /
                      | | \          _..'`
                      | |  '------'''
                      | |                      _
                      |_|                     | |
 ___ _   _ _ __   ___ _ __          _ __   ___| |_ ___  _ __  ___
/ __| | | | '_ \ / _ \ '__| ______ | '_ \ / _ \ __/ _ \| '_ \/ __|
\__ \ |_| | |_) |  __/ |   |______|| | | |  __/ || (_) | |_) \__ \
|___/\__,_| .__/ \___|_|           |_| |_|\___|\__\___/| .__/|___/
          | |                                          | |
          |_|                                          |_|

Welcome to the f5-super-netops-container.  This image has the following
services running:

 SSH  tcp/22
 HTTP tcp/80

To access these services you may need to remap ports on your host to the
local container using the command:

 docker run -p 8080:80 -p 2222:22 -it f5devcentral/f5-super-netops-container:base

From the HOST perspective, this results in:

 localhost:2222 -> f5-super-netops-container:22
 localhost:8080 -> f5-super-netops-container:80

You can then connect using the following:

 HTTP: http://localhost:8080
 SSH:  ssh -p 2222 snops@localhost

Default Credentials:

 snops/default
 root/default

Go forth and automate!
[snops@f5-super-netops] [~] $

Task 2 – Connect via HTTP¶

To connect to the image via HTTP we must use the published port specified in the docker run command. To review the command used to start the container was:

docker run -p 8080:80 -p 2222:22 -p 10000:8080 --rm -it -e SNOPS_GH_BRANCH=develop f5devcentral/f5-super-netops-container:develop-jenkins

This will publish the standard HTTP service on TCP/80 to TCP/8080 on the Docker host. In the case of the HTTP service the following mapping applies:

localhost:8080 -> f5-super-netops-container:80

To connect via HTTP open a web browser and enter the URL:

http://10.1.1.8:8080/start

You should see a page like this:

Task 3 – Connect via Jenkins¶

To connect to the image via Jenkins we must use the published port specified in the docker run command. To review the command used to start the container was:

docker run -p 8080:80 -p 2222:22 -p 10000:8080 --rm -it -e SNOPS_GH_BRANCH=develop f5devcentral/f5-super-netops-container:develop-jenkins

This will publish the standard Jenkins service on TCP/8080 to TCP/10000 on the Docker host. In the case of the Jenkins service the following mapping applies:

10.1.1.8:10000 -> f5-super-netops-container:8080

To connect via HTTP open a web browser and enter the URL:

http://10.1.1.8:10000

You should see a page like this:

Task 1 - Import the f5-postman-workflows Postman Collection¶

In this task you will Import a Postman Collection that contains Installation helpers, Examples and a automated Test Framework. The collection is installed from the f5-postman-workflows GitHub repository.

Perform the following steps to complete this task:

1. Open the Postman Client on your jumphost by clicking the icon

2. Click the ‘Import’ button in the top left of the Postman window

3. Click the ‘Import from Link’ tab. Paste the following URL into the text box and click ‘Import’

   https://raw.githubusercontent.com/0xHiteshPatel/f5-postman-workflows/master/F5_Postman_Workflows.postman_collection.json

4. You should now see a collection named F5_Postman_Workflows in your Postman Collections sidebar

Task 2 - Install f5-postman-workflows into your Postman Client¶

To utilize the helper functions the framework include we must install those functions into the Postman Client. The installation helpers perform the following tasks:

1. Determine the most current version of the framework
2. Dynamically minify the JavaScript code from the f5-postman-workflows GitHub repository using Google’s Closure Compiler
3. Install the minified JS code into a Postman Global Variable
4. Set a number of Global variables that allow you to configure various options

To install the framework complete the following tasks:

1. Open the F5_Postman_Workflows collection

2. Open the Install folder

3. Select the Check f5-postman-workflows Version item and click ‘Send’

4. Examine the ‘Tests’ portion of the RESPONSE:

   

5. Select the Install/Upgrade f5-postman-workflows item and click ‘Send’

6. Examine the ‘Tests’ again and ensure that Installation was successful:

   

7. Click the ‘Eye’ button in the top right of the Postman window and examine the Global variables that have been populated

   

The f5-postman-workflows framework is now installed in your Postman client.

Task 1 - Import and Explore BIG-IP Collections¶

We will import two collections to Postman using the same steps in the previous labs. The collections will allow us to perform REST API Authentication to BIG-IP devices and then execute Operational actions on the BIG-IP device.

Execute the following steps to complete this task:

1. Click Import -> Import from Link and import these collection URLs:

   • https://raw.githubusercontent.com/0xHiteshPatel/f5-postman-workflows/master/collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json
   • https://raw.githubusercontent.com/0xHiteshPatel/f5-postman-workflows/master/collections/BIG_IP/BIGIP_Operational_Workflows.postman_collection.json

2. You should now have two additional Collections in the sidebar:

   • BIGIP_API_Authentication
   • BIGIP_Operational_Workflows

3. Expand the BIGIP_API_Authentication collection. Within the collection you will see one folder named 1_Authenticate. Folders are used to organize various workflows within a collection. In this case this collection performs exactly one task, authentication, therefore one folder is present.

4. Expand the 1_Authenticate folder. Notice there are three requests in the folder. These three requests will be executed in a synchronous manner (one-after-another).

5. Click the ... icon on the 1_Authenticate folder, then click Edit

   

6. In the following window you will see documentation explaining what the requests in this folder accomplish. Additionally you will see a series of Input and Output variables. Unless marked otherwise it is assumed that all Input variables are required. In this case the bigip_token_timeout variable is optional.

   Folders may also contain output variables that are set to pass data between requests in different collections. In this case the output variable is named bigip_token and contains the authentication token that can be sent in the X-F5-Auth-Token HTTP header to perform authentication.

7. Close the window by clicking ‘Cancel’

8. Repeat the steps above and explore the BIGIP_Operational_Workflows collection, specifically the 4A_Get_BIGIP_Version folder

Task 2 - Manually Chain Folders into a Workflow¶

In this task we will explore how to chain two folders together and manually execute a workflow. This example is simple, but should help illustrate how we can use folders as building blocks that can be assembled or chained together to construct a workflow.

We will use the 1_Authenticate folder in the BIGIP_API_Authentication collection and then pass the authentication token to the 4A_Get_BIGIP_Version folder in the BIGIP_Operational_Workflows collection.

Execute the following steps to complete this task:

1. Create a new Postman environment by clicking the Gear icon -> Manage Environments -> Add.

2. Name the environment Lab 2.2 and populate the following key/value pairs:

   • bigip_mgmt: 10.1.1.4
   • bigip_username: admin
   • bigip_password: admin

3. Click the ‘Add’ button, then close the ‘Manage Environments’ window.

4. Select the Lab 2.2 environment:

   

The preceding steps configured the Input Variables required for all the folders that comprise our workflow. We will now manually execute all the requests in the folders.

1. Expand the BIGIP_API_Authentication -> 1_Authenticate folder.

2. Select the Authenticate and Obtain Token item and click Send

3. Examine the Tests in the response portion of the request. All the tests should be passing. Additionally you should see a test similar to:

   [Populate Variable] bigip_token=....

   

   These test items and their corresponding actions (populating a variable in this case) are generated by the f5-postman-workflows framework.

4. Examine your Postman Environment variables and confirm that the bigip_token variable is present and populated.

   

5. Select the Verify Authentication Works request in the folder and click ‘Send’. Examine the Tests and ensure they are all passing

6. Select the Set Authentication Token Timeout request, click Send and verify all Tests pass.

At this point we have successfully authenticated to our device and stored the authentication token in the bigip_token environment variable. We will now execute a request in a different collection and folder that uses the bigip_token variable value to authenticate and perform its actions.

1. Expand the BIGIP_Operational_Workflows -> 4A_Get_BIGIP_Version folder.

2. Click the Get Software Version request.

3. Click the ‘Headers’ tab. Notice that the value for the X-F5-Auth-Token header is populated with the bigip_token variable value.

   Note

   Postman uses the {{variable_name}} syntax to perform variable value substitution.

   

4. Click ‘Send’ to send the request. Examine the Tests and ensure all tests have passed.

5. Examine your environment variables and note that the bigip_version and bigip_build variables are now populated.

While the example above was simple it should show how we can chain together different collections and folders to assemble custom workflows. The key concepts to understand are:

• The f5-postman-workflows framework and collection test code perform unit tests on the response data and verify the request executed successfully.
• The framework also populates Output Variables as documented so they can be used in subsequent requests as Inputs to assemble a workflow

Next, we will explore how to use this base knowledge to assemble various collections and folders into workflows using Newman and the f5-newman-wrapper.

Task 1 - Explore the workflow JSON format¶

To introduce the format of the workflow file we will use an example that recreates the simple workflow we executed manually in the previous lab. We will explore the file in sections followed by showing the whole file.

1
2
3
4

{
     "name":"Wrapper_Demo_1",
     "description":"Execute a chained workflow that authenticates to a BIG-IP and retrieves it's software version"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
     "globalEnvVars":"../framework/f5-postman-workflows.postman_globals.json",
     "globalOptions": {
         "insecure":true,
         "reporters":["cli"]
     },
     "saveEnvVars":true,
     "outputFile":"Wrapper_Demo_1-run.json",
     "envOutputFile":"Wrapper_Demo_1-env.json"
 }

1
2
3
4
5
6
7

 {
     "globalVars": {
         "bigip_mgmt": "10.1.1.4",
         "bigip_username":"admin",
         "bigip_password":"admin"
     }
 }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

 {
    "workflow": [
        {
            "name":"Authenticate to BIG-IP",
            "options": {
                "collection":".. /collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json",
                "folder":"1_Authenticate"
            }
        },
        {
            "name":"Get BIG-IP Software Version",
            "options": {
                "collection":"../collections/BIG_IP/BIGIP_Operational_Workflows.postman_collection.json",
                "folder":"4A_Get_BIGIP_Version"
            }
        }
    ]
}

1
2
3
4
5
6
7

                {
                        "name":"Authenticate to BIG-IP",
                        "options": {
                                "collection":".. /collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json",
                                "folder":"1_Authenticate"
                        }
                }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

{
        "name":"Wrapper_Demo_1",
        "description":"Execute a chained workflow that authenticates to a BIG-IP    and retrieves it's software version",
        "globalEnvVars":"../framework/f5-postman-workflows.postman_globals.json",
        "globalOptions": {
                "insecure":true,
                "reporters":["cli"]
        },
        "globalVars": {
                "bigip_mgmt": "10.1.1.4",
                "bigip_username":"admin",
                "bigip_password":"admin"
        },
        "saveEnvVars":true,
        "outputFile":"Wrapper_Demo_1-run.json",
        "envOutputFile":"Wrapper_Demo_1-env.json",
        "workflow": [
                {
                        "name":"Authenticate to BIG-IP",
                        "options": {
                                "collection":"..   /collections/BIG_IP/BIGIP_API_Authentication.   postman_collection.json",
                                "folder":"1_Authenticate"
                        }
                },
                {
                        "name":"Get BIG-IP Software Version",
                        "skip":false,
                        "options": {
                                "collection":"..   /collections/BIG_IP/BIGIP_Operational_Workflows.   postman_collection.json",
                                "folder":"4A_Get_BIGIP_Version"
                        }
                }
        ]
}

Task 1 - Run a f5-newman-wrapper Workflow¶

1. Open an SSH session as described in the previous lab

2. Run cd f5-postman-workflows/local

3. Run cp ../workflows/Wrapper_Demo_1.json .

4. Edit the Wrapper_Demo_1.json file with vim and enter the 10.1.1.4 for the value of the bigip_mgmt variable

   "globalVars": {
           "bigip_mgmt": "10.1.1.4",
           "bigip_username":"admin",
           "bigip_password":"admin"
   },
   

5. Run f5-newman-wrapper Wrapper_Demo_1.json

6. Examine the output to see how the workflow was executed. Notice that the same tests that we saw when using Postman are present during this run.

   Example output:

   [snops@f5-super-netops] [~/f5-postman-workflows/local] $ f5-newman-wrapper Wrapper_Demo_1.json
   [Wrapper_Demo_1-2017-03-30-04-08-12] starting run
   [Wrapper_Demo_1-2017-03-30-04-08-12] [runCollection][Authenticate to BIG-IP] running...
   newman
   
   BIGIP_API_Authentication
   
   ❏ 1_Authenticate
   ↳ Authenticate and Obtain Token
     POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 108ms]
     ✓  [POST Response Code]=200
     ✓  [Populate Variable] bigip_token=WYKIVPHCNASNVEC55ZDVNH5OO2
   
   ↳ Verify Authentication Works
     GET https://10.1.1.4/mgmt/shared/authz/tokens/WYKIVPHCNASNVEC55ZDVNH5OO2 [200 OK, 1.23KB, 8ms]
     ✓  [GET Response Code]=200
     ✓  [Current Value] token=WYKIVPHCNASNVEC55ZDVNH5OO2
     ✓  [Check Value] token == WYKIVPHCNASNVEC55ZDVNH5OO2
   
   ↳ Set Authentication Token Timeout
     PATCH https://10.1.1.4/mgmt/shared/authz/tokens/WYKIVPHCNASNVEC55ZDVNH5OO2 [200 OK, 1.23KB, 14ms]
     ✓  [PATCH Response Code]=200
     ✓  [Current Value] timeout=1200
     ✓  [Check Value] timeout == 1200
   
   ┌─────────────────────────┬──────────┬──────────┐
   │                         │ executed │   failed │
   ├─────────────────────────┼──────────┼──────────┤
   │              iterations │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │                requests │        3 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │            test-scripts │        3 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │      prerequest-scripts │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │              assertions │        8 │        0 │
   ├─────────────────────────┴──────────┴──────────┤
   │ total run duration: 297ms                     │
   ├───────────────────────────────────────────────┤
   │ total data received: 1.71KB (approx)          │
   ├───────────────────────────────────────────────┤
   │ average response time: 43ms                   │
   └───────────────────────────────────────────────┘
   [Wrapper_Demo_1-2017-03-30-04-08-12] [runCollection][Get BIG-IP Software Version] running...
   newman
   
   BIGIP_Operational_Workflows
   
   ❏ 4A_Get_BIGIP_Version
   ↳ Get Software Version
     GET https://10.1.1.4/mgmt/tm/sys/software/volume [200 OK, 1.32KB, 16ms]
     ✓  [GET Response Code]=200
     ✓  [Populate Variable] bigip_version=12.1.1
     ✓  [Populate Variable] bigip_build=1.0.196
   [Wrapper_Demo_1-2017-03-30-04-08-12] run completed
   
   ┌─────────────────────────┬──────────┬──────────┐
   │                         │ executed │   failed │
   ├─────────────────────────┼──────────┼──────────┤
   │              iterations │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │                requests │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │            test-scripts │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │      prerequest-scripts │        0 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │              assertions │        3 │        0 │
   ├─────────────────────────┴──────────┴──────────┤
   │ total run duration: 58ms                      │
   ├───────────────────────────────────────────────┤
   │ total data received: 611B (approx)            │
   ├───────────────────────────────────────────────┤
   │ average response time: 16ms                   │
   └───────────────────────────────────────────────┘
   

7. Examine the environment variables that were saved at the end of the run by executing cat Wrapper_Demo_1-env.json

   Example output:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

   { "id": "c0550892-36d4-4412-bf35-a1d9aa8d2efe", "values": [ { "type": "any", "value": "10.1.1.4", "key": "bigip_mgmt" }, { "type": "any", "value": "admin", "key": "bigip_username" }, { "type": "any", "value": "admin", "key": "bigip_password" }, { "type": "any", "value": "WYKIVPHCNASNVEC55ZDVNH5OO2", "key": "bigip_token" }, { "type": "any", "value": "1200", "key": "bigip_token_timeout" }, { "type": "any", "value": "12.1.1", "key": "bigip_version" }, { "type": "any", "value": "1.0.196", "key": "bigip_build" } ] }

Notice that the bigip_version and bigip_build variables were saved. This file is JSON formatted and can easily be used directly by other tools to drive further automation.

Task 1 - Explore Nested Workflows & Variable Remapping¶

By using the ‘children’ array within an item in a workflow you can create nested items. In this task, we will create a more advanced version of the workflow we used in the previous lab. This workflow will perform authentication to two BIG-IP devices and then retrieve the software version running on each.

We will implement a workflow that is best depicted by the following branch diagram:

Start
  |
  |- Authenticate
  |  |- Authenticate to BIG-IP A
  |  |- Authenticate to BIG-IP B
  |
  |- Get BIGIP Version
  |  |- Get BIGIP Version on BIG-IP A
  |  |- Get BIGIP Version on BIG-IP B
  |
Stop

To implement this workflow we need to consider how Input Variables are passed to each item in the workflow. Previously, we saw that the following variables are required to the the 1_Authenticate folder in the BIGIP_API_Authentication collection:

• bigip_mgmt
• bigip_username
• bigip_password

The issue we encounter when building this workflow is that we, at a minimum, have different values for bigip_mgmt because we are trying to communicate with two BIG-IP devices. To address this issue, we could define our input variables as follows:

• bigip_a_mgmt = 10.1.1.4
• bigip_b_mgmt = 10.1.1.5
• bigip_username = admin
• bigip_password = admin

This solves the problem of providing both BIG-IP management addresses, however, it introduces another issue. The 1_Authenticate folder requires that the management IP address be passed in the bigip_mgmt input variable. To solve this issue, we will use variable name remapping to remap a globalVar to a different name before the 1_Authenticate folder is run for each BIG-IP device. To illustrate this, we will add more information to our diagram:

Start
  |
  |- Define globalVars
  |  |- bigip_a_mgmt = 10.1.1.4
  |  |- bigip_b_mgmt = 10.1.1.5
  |  |- bigip_username = admin
  |  |- bigip_password = admin
  |
  |- Authenticate
  |  |- Authenticate to BIG-IP A
  |  |  | Pre-run: Remap bigip_a_mgmt -> bigip_mgmt
  |  |  |     Run: 1_Authenticate folder
  |  |
  |  |- Authenticate to BIG-IP B
  |  |  | Pre-run: Remap bigip_b_mgmt -> bigip_mgmt
  |  |  |     Run: 1_Authenticate folder
  |
  |- Get BIGIP Version
  |  |- Get BIGIP Version on BIG-IP A
  |  |- Get BIGIP Version on BIG-IP B
  |
Stop

We’ve now addressed our issues regarding defining and passing the BIG-IP management address, but have to consider one last problem. The output variable of the 1_Authenticate folder is bigip_token. By default f5-newman-wrapper will store all output variables from one folder and automatically pass them to the next item. In this case, an issue occurs because the Authenticate to BIG-IP B item will overwrite the bigip_token variable that was outputted by the Authenticate to BIG-IP A item. To resolve this issue, we can remap variables AFTER or post-run of an item. We can modify our diagram to handle this issue like this:

Start
  |
  |- Define globalVars
  |  |- bigip_a_mgmt = 10.1.1.4
  |  |- bigip_b_mgmt = 10.1.1.5
  |  |- bigip_username = admin
  |  |- bigip_password = admin
  |
  |- Authenticate
  |  |- Authenticate to BIG-IP A
  |  |  |  Pre-run: Remap bigip_a_mgmt -> bigip_mgmt
  |  |  |      Run: 1_Authenticate folder
  |  |  | Post-run: Remap bigip_token -> bigip_a_token
  |  |
  |  |- Authenticate to BIG-IP B
  |  |  |  Pre-run: Remap bigip_b_mgmt -> bigip_mgmt
  |  |  |      Run: 1_Authenticate folder
  |  |  | Post-run: Remap bigip_token -> bigip_b_token
  |
  |- Get BIGIP Version
  |  |- Get BIGIP Version on BIG-IP A
  |  |- Get BIGIP Version on BIG-IP B
  |
Stop

The last step is to perform some additional pre-run remapping to pass the correct token to the 4A_Get_BIGIP_Version folder to get our BIG-IP software version. Additionally, we will perform some post-run remaps so we can save the output variables for each device:

Start
  |
  |- Define globalVars
  |  |- bigip_a_mgmt = 10.1.1.4
  |  |- bigip_b_mgmt = 10.1.1.5
  |  |- bigip_username = admin
  |  |- bigip_password = admin
  |
  |- Authenticate
  |  |- Authenticate to BIG-IP A
  |  |  |  Pre-run: Remap bigip_a_mgmt -> bigip_mgmt
  |  |  |      Run: 1_Authenticate folder
  |  |  | Post-run: Remap bigip_token -> bigip_a_token
  |  |
  |  |- Authenticate to BIG-IP B
  |  |  |  Pre-run: Remap bigip_b_mgmt -> bigip_mgmt
  |  |  |      Run: 1_Authenticate folder
  |  |  | Post-run: Remap bigip_token -> bigip_b_token
  |
  |- Get BIGIP Version
  |  |- Get BIGIP Version on BIG-IP A
  |  |  |  Pre-run: Remap bigip_a_mgmt -> bigip_mgmt
  |  |  |  Pre-run: Remap bigip_a_token -> bigip_token
  |  |  |      Run: 4A_Get_BIGIP_Version folder
  |  |  | Post-run: Remap bigip_version -> bigip_a_version
  |  |  | Post-run: Remap bigip_build -> bigip_a_build
  |  |
  |  |- Get BIGIP Version on BIG-IP B
  |  |  |  Pre-run: Remap bigip_b_mgmt -> bigip_mgmt
  |     |  Pre-run: Remap bigip_b_token -> bigip_token
  |     |      Run: 4A_Get_BIGIP_Version folder
  |     | Post-run: Remap bigip_version -> bigip_b_version
  |     | Post-run: Remap bigip_build -> bigip_b_build
  |
  |- Save globarVars to file
  |
Stop

Task 2 - Build Complex Workflow JSON¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "name":"Wrapper_Demo_2",
  "description":"Execute a chained workflow that authenticates to two BIG-IPs and retrieves their software version",
  "globalEnvVars":"../framework/f5-postman-workflows.postman_globals.json",
  "globalOptions": {
    "insecure":true,
    "reporters":["cli"]
  },
  "globalVars": {
    "bigip_a_mgmt": "10.1.1.4",
    "bigip_b_mgmt": "10.1.1.5",
    "bigip_username":"admin",
    "bigip_password":"admin"
  },
  "saveEnvVars":true,
  "outputFile":"Wrapper_Demo_2-run.json",
  "envOutputFile":"Wrapper_Demo_2-env.json"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

{
  "workflow": [
    {
      "name":"Authenticate to BIG-IPs",
      "skip":true,
      "children": [
        {
          "name":"Authenticate to BIG-IP A",
          "options": {
            "collection":"../collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json",
            "remapPreRun": {
              "bigip_a_mgmt": "bigip_mgmt"
            },
            "folder":"1_Authenticate",
            "remapPostRun": {
              "bigip_token": "bigip_a_token"
            }
          }
        },
        {
          "name":"Authenticate to BIG-IP B",
          "options": {
            "collection":"../collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json",
            "remapPreRun": {
              "bigip_b_mgmt": "bigip_mgmt"
            },
            "folder":"1_Authenticate",
            "remapPostRun": {
              "bigip_token": "bigip_b_token"
            }
          }
        }
      ]
    }
  ]
}

|- Authenticate
   |- Authenticate to BIG-IP A
   |  |  Pre-run: Remap bigip_a_mgmt -> bigip_mgmt
   |  |      Run: 1_Authenticate folder
   |  | Post-run: Remap bigip_token -> bigip_a_token
   |
   |- Run: Authenticate to BIG-IP B
   |  |  Pre-run: Remap bigip_b_mgmt -> bigip_mgmt
   |  |      Run: 1_Authenticate folder
   |  | Post-run: Remap bigip_token -> bigip_b_token

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

{
   "workflow": [
     {
       "name":"Get BIG-IP Software Versions",
       "skip":true,
       "children": [
         {
           "name":"Get BIG-IP A Software Version",
           "options": {
             "collection":"../collections/BIG_IP/BIGIP_Operational_Workflows.postman_collection.json",
             "remapPreRun": {
               "bigip_a_mgmt": "bigip_mgmt",
               "bigip_a_token": "bigip_token"
             },
             "folder":"4A_Get_BIGIP_Version",
             "remapPostRun": {
               "bigip_version": "bigip_a_version",
               "bigip_build": "bigip_a_build"
             }
           }
         },
         {
           "name":"Get BIG-IP B Software Version",
           "options": {
             "collection":"../collections/BIG_IP/BIGIP_Operational_Workflows.postman_collection.json",
             "remapPreRun": {
               "bigip_b_mgmt": "bigip_mgmt",
               "bigip_b_token": "bigip_token"
             },
             "folder":"4A_Get_BIGIP_Version",
             "remapPostRun": {
               "bigip_version": "bigip_b_version",
               "bigip_build": "bigip_b_build"
             }
           }
         }
       ]
     }
   ]
}

|- Get BIGIP Version
   |- Get BIGIP Version on BIG-IP A
   |  |  Pre-run: Remap bigip_a_mgmt -> bigip_mgmt
   |  |  Pre-run: Remap bigip_a_token -> bigip_token
   |  |      Run: 4A_Get_BIGIP_Version folder
   |  | Post-run: Remap bigip_version -> bigip_a_version
   |  | Post-run: Remap bigip_build -> bigip_a_build
   |
   |- Get BIGIP Version on BIG-IP B
   |  |  Pre-run: Remap bigip_b_mgmt -> bigip_mgmt
      |  Pre-run: Remap bigip_b_token -> bigip_token
      |      Run: 4A_Get_BIGIP_Version folder
      | Post-run: Remap bigip_version -> bigip_b_version
      | Post-run: Remap bigip_build -> bigip_b_build

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

 {
   "name":"Wrapper_Demo_2",
   "description":"Execute a chained workflow that authenticates to two BIG-IPs and retrieves their software version",
   "globalEnvVars":"../framework/f5-postman-workflows.postman_globals.json",
   "globalOptions": {
     "insecure":true,
     "reporters":["cli"]
   },
   "globalVars": {
     "bigip_a_mgmt": "",
     "bigip_b_mgmt": "",
     "bigip_username":"admin",
     "bigip_password":"admin"
   },
   "saveEnvVars":true,
   "outputFile":"Wrapper_Demo_2-run.json",
   "envOutputFile":"Wrapper_Demo_2-env.json",
   "workflow": [
     {
       "name":"Authenticate to BIG-IPs",
       "skip":true,
       "children": [
         {
           "name":"Authenticate to BIG-IP A",
           "options": {
             "collection":"../collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json",
             "remapPreRun": {
               "bigip_a_mgmt": "bigip_mgmt"
             },
             "folder":"1_Authenticate",
             "remapPostRun": {
               "bigip_token": "bigip_a_token"
             }
           }
         },
         {
           "name":"Authenticate to BIG-IP B",
           "options": {
             "collection":"../collections/BIG_IP/BIGIP_API_Authentication.postman_collection.json",
             "remapPreRun": {
               "bigip_b_mgmt": "bigip_mgmt"
             },
             "folder":"1_Authenticate",
             "remapPostRun": {
               "bigip_token": "bigip_b_token"
             }
           }
         }
       ]
     },
     {
       "name":"Get BIG-IP Software Versions",
       "skip":true,
       "children": [
         {
           "name":"Get BIG-IP A Software Version",
           "options": {
             "collection":"../collections/BIG_IP/BIGIP_Operational_Workflows.postman_collection.json",
             "remapPreRun": {
               "bigip_a_mgmt": "bigip_mgmt",
               "bigip_a_token": "bigip_token"
             },
             "folder":"4A_Get_BIGIP_Version",
             "remapPostRun": {
               "bigip_version": "bigip_a_version",
               "bigip_build": "bigip_a_build"
             }
           }
         },
         {
           "name":"Get BIG-IP B Software Version",
           "options": {
             "collection":"../collections/BIG_IP/BIGIP_Operational_Workflows.postman_collection.json",
             "remapPreRun": {
               "bigip_b_mgmt": "bigip_mgmt",
               "bigip_b_token": "bigip_token"
             },
             "folder":"4A_Get_BIGIP_Version",
             "remapPostRun": {
               "bigip_version": "bigip_b_version",
               "bigip_build": "bigip_b_build"
             }
           }
         }
       ]
     }
   ]
 }

Task 3 - Run the Workflow¶

1. Open an SSH session as described in the previous lab

2. Run cd f5-postman-workflows/local

3. Run cp ../workflows/Wrapper_Demo_2.json .

4. Edit the Wrapper_Demo_2.json file and enter you BIG-IP management addresses

   1 2 3 4 5 6 7 8

   { "globalVars": { "bigip_a_mgmt": "10.1.1.4", "bigip_b_mgmt": "10.1.1.5", "bigip_username":"admin", "bigip_password":"admin" } }

5. Run f5-newman-wrapper Wrapper_Demo_2.json

6. Examine the output to see how the workflow was executed.

   Example output:

   [snops@f5-super-netops] [~/f5-postman-workflows/local] $ f5-newman-wrapper Wrapper_Demo_2.json
   [Wrapper_Demo_2-2017-03-30-19-22-52] starting run
   [Wrapper_Demo_2-2017-03-30-19-22-52] [runCollection][Authenticate to BIG-IP A] running...
   newman
   
   BIGIP_API_Authentication
   
   ❏ 1_Authenticate
   ↳ Authenticate and Obtain Token
     POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 570ms]
     ✓  [POST Response Code]=200
     ✓  [Populate Variable] bigip_token=UE7W5CXWM5SJ6SZEV5A7KTAI5Q
   
   ↳ Verify Authentication Works
     GET https://10.1.1.4/mgmt/shared/authz/tokens/UE7W5CXWM5SJ6SZEV5A7KTAI5Q [200 OK, 1.23KB, 9ms]
     ✓  [GET Response Code]=200
     ✓  [Current Value] token=UE7W5CXWM5SJ6SZEV5A7KTAI5Q
     ✓  [Check Value] token == UE7W5CXWM5SJ6SZEV5A7KTAI5Q
   
   ↳ Set Authentication Token Timeout
     PATCH https://10.1.1.4/mgmt/shared/authz/tokens/UE7W5CXWM5SJ6SZEV5A7KTAI5Q [200 OK, 1.23KB, 13ms]
     ✓  [PATCH Response Code]=200
     ✓  [Current Value] timeout=1200
     ✓  [Check Value] timeout == 1200
   
   ┌─────────────────────────┬──────────┬──────────┐
   │                         │ executed │   failed │
   ├─────────────────────────┼──────────┼──────────┤
   │              iterations │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │                requests │        3 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │            test-scripts │        3 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │      prerequest-scripts │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │              assertions │        8 │        0 │
   ├─────────────────────────┴──────────┴──────────┤
   │ total run duration: 740ms                     │
   ├───────────────────────────────────────────────┤
   │ total data received: 1.71KB (approx)          │
   ├───────────────────────────────────────────────┤
   │ average response time: 197ms                  │
   └───────────────────────────────────────────────┘
   [Wrapper_Demo_2-2017-03-30-19-22-52] [runCollection][Authenticate to BIG-IP B] running...
   newman
   
   BIGIP_API_Authentication
   
   ❏ 1_Authenticate
   ↳ Authenticate and Obtain Token
     POST https://10.1.1.5/mgmt/shared/authn/login [200 OK, 1.41KB, 350ms]
     ✓  [POST Response Code]=200
     ✓  [Populate Variable] bigip_token=ONQXOQPNCVOHZELKIFSPHETL3I
   
   ↳ Verify Authentication Works
     GET https://10.1.1.5/mgmt/shared/authz/tokens/ONQXOQPNCVOHZELKIFSPHETL3I [200 OK, 1.23KB, 9ms]
     ✓  [GET Response Code]=200
     ✓  [Current Value] token=ONQXOQPNCVOHZELKIFSPHETL3I
     ✓  [Check Value] token == ONQXOQPNCVOHZELKIFSPHETL3I
   
   ↳ Set Authentication Token Timeout
     PATCH https://10.1.1.5/mgmt/shared/authz/tokens/ONQXOQPNCVOHZELKIFSPHETL3I [200 OK, 1.23KB, 12ms]
     ✓  [PATCH Response Code]=200
     ✓  [Current Value] timeout=1200
     ✓  [Check Value] timeout == 1200
   
   ┌─────────────────────────┬──────────┬──────────┐
   │                         │ executed │   failed │
   ├─────────────────────────┼──────────┼──────────┤
   │              iterations │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │                requests │        3 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │            test-scripts │        3 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │      prerequest-scripts │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │              assertions │        8 │        0 │
   ├─────────────────────────┴──────────┴──────────┤
   │ total run duration: 472ms                     │
   ├───────────────────────────────────────────────┤
   │ total data received: 1.71KB (approx)          │
   ├───────────────────────────────────────────────┤
   │ average response time: 123ms                  │
   └───────────────────────────────────────────────┘
   [Wrapper_Demo_2-2017-03-30-19-22-52] [runCollection][Get BIG-IP A Software Version] running...
   newman
   
   BIGIP_Operational_Workflows
   
   ❏ 4A_Get_BIGIP_Version
   ↳ Get Software Version
     GET https://10.1.1.4/mgmt/tm/sys/software/volume [200 OK, 1.32KB, 207ms]
     ✓  [GET Response Code]=200
     ✓  [Populate Variable] bigip_version=12.1.1
     ✓  [Populate Variable] bigip_build=1.0.196
   
   ┌─────────────────────────┬──────────┬──────────┐
   │                         │ executed │   failed │
   ├─────────────────────────┼──────────┼──────────┤
   │              iterations │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │                requests │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │            test-scripts │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │      prerequest-scripts │        0 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │              assertions │        3 │        0 │
   ├─────────────────────────┴──────────┴──────────┤
   │ total run duration: 250ms                     │
   ├───────────────────────────────────────────────┤
   │ total data received: 611B (approx)            │
   ├───────────────────────────────────────────────┤
   │ average response time: 207ms                  │
   └───────────────────────────────────────────────┘
   [Wrapper_Demo_2-2017-03-30-19-22-52] [runCollection][Get BIG-IP B Software Version] running...
   newman
   
   BIGIP_Operational_Workflows
   
   ❏ 4A_Get_BIGIP_Version
   ↳ Get Software Version
     GET https://10.1.1.5/mgmt/tm/sys/software/volume [200 OK, 1.32KB, 191ms]
     ✓  [GET Response Code]=200
     ✓  [Populate Variable] bigip_version=12.1.1
     ✓  [Populate Variable] bigip_build=1.0.196
   
   ┌─────────────────────────┬──────────┬──────────┐
   │                         │ executed │   failed │
   ├─────────────────────────┼──────────┼──────────┤
   │              iterations │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │                requests │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │            test-scripts │        1 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │      prerequest-scripts │        0 │        0 │
   ├─────────────────────────┼──────────┼──────────┤
   │              assertions │        3 │        0 │
   ├─────────────────────────┴──────────┴──────────┤
   │ total run duration: 230ms                     │
   ├───────────────────────────────────────────────┤
   │ total data received: 611B (approx)            │
   ├───────────────────────────────────────────────┤
   │ average response time: 191ms                  │
   └───────────────────────────────────────────────┘
   [Wrapper_Demo_2-2017-03-30-19-22-52] run completed in 3s, 316.921 ms
   

7. Examine the environment variables that were saved at the end of the run by executing cat Wrapper_Demo_2-env.json. The resulting BIG-IP software versions are now present and have been highlighted below.

   Example output:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

   { "id": "d459e491-4936-4be7-a910-567f711a636a", "values": [ { "type": "any", "value": "10.1.1.4", "key": "bigip_a_mgmt" }, { "type": "any", "value": "10.1.1.5", "key": "bigip_b_mgmt" }, { "type": "any", "value": "10.1.1.5", "key": "bigip_mgmt" }, { "type": "any", "value": "admin", "key": "bigip_username" }, { "type": "any", "value": "admin", "key": "bigip_password" }, { "type": "any", "value": "UE7W5CXWM5SJ6SZEV5A7KTAI5Q", "key": "bigip_a_token" }, { "type": "any", "value": "ONQXOQPNCVOHZELKIFSPHETL3I", "key": "bigip_b_token" }, { "type": "any", "value": "ONQXOQPNCVOHZELKIFSPHETL3I", "key": "bigip_token" }, { "type": "any", "value": "12.1.1", "key": "bigip_a_version" }, { "type": "any", "value": "1.0.196", "key": "bigip_a_build" }, { "type": "any", "value": "1200", "key": "bigip_token_timeout" }, { "type": "any", "value": "12.1.1", "key": "bigip_b_version" }, { "type": "any", "value": "1.0.196", "key": "bigip_b_build" } ] }

Task 1 - Review the super-netops-container files and collections used¶

1. Open Putty and connect to the super-netops-container user credentials are snops and default
2. During the installation of the super-netops-container there were several github repositories cloned, all of which are mapped to the /home/snops/ directory.

Let’s make sure all repositories were mapped correctly.

Execute: cd /home/snops

The Collections we will be using are located here:

|- /f5-automation-labs
   |- /postman_collections
   |  |  f5-programmability-class-2.postman_collection.json

|- /f5-postman-workflows
  |- /collections
  |  |  /BIG_IP
  |  |      BIGIP_Operational_Workflows.postman_collection.json

The f5-newman-wrapper configuration files are located here:

|- /f5-automation-labs
   |- /jenkins
   |  |  /f5-newman-build
   |  |      f5-newman-build-1
   |  |      f5-newman-build-2
   |  |      f5-newman-build-5
   |  |  /f5-newman-operation
   |  |      f5-newman-build-3
   |  |      f5-newman-build-4

Task 1 - Examine f5-newman-build-1¶

1. Open Putty and connect to the super-netops-container user credentials are snops and default

2. Navigate to the location containing the f5-newman-wrapper files cd ~/f5-automation-labs/jenkins/f5-newman-build

3. Let’s examine the contents of the first f5-newman-wrapper file cat f5-newman-build-1

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

   { "name":"f5-newman-build-1", "description":"Execute a chained workflow that authenticates to a BIG-IP and builds configuration", "globalEnvVars":"/home/snops/f5-postman-workflows/framework/f5-postman-workflows.postman_globals.json", "globalOptions": { "insecure":true, "reporters":["cli"] }, "globalVars": { "bigip_mgmt": "10.1.1.4", "bigip_username":"admin", "bigip_password":"admin", "bigip_partition":"Common", "bigip_pool_name":"module_3_pool", "bigip_pool_member":"75.67.228.133:80", "bigip_object_state":"user-up", "bigip_object_session":"user-enabled", "bigip_vs_name":"module_3_vs", "bigip_vs_destination":"10.1.20.129:80", "bigip_node_name":"75.67.228.133", "bigip_http_monitor":"module_3_http_monitor", "bigip_http_profile":"module_3_http", "bigip_tcp_profile":"module_3_tcp_clientside" }, "workflow": [ { "name":"Authenticate to BIG-IP", "options": { "collection":"/home/snops/f5-postman-workflows/collections/BIG_IP/BIGIP_API_Authentication. postman_collection.json", "folder":"1_Authenticate" } }, (REMOVE THIS TEXT AND ADD YOUR CODE BELOW) } ] }

4. The above f5-newman-wrapper file only has the Authenticate to BIG-IP Collection/Folder referenced, we will now add in another collection. You are going to add this code snippet after the last },. This shows the method for chaining together multiple calls from multiple sources.

1 2 3 4 5 6 7

{ "name":"1 - Build a Basic LTM Config", "skip":false, "options": { "collection":"/home/snops/f5-automation-labs/postman_collections/f5-programmability-class-2. postman_collection.json", "folder":"1 - Build a Basic LTM Config" }

Task 2 - Execute the first f5-newman-wrapper file¶

1. Login to your BIG-IP lab machine and verify you do not have any Virtual Servers or Pools

   Note

   If you are using the F5 lab systems there are already shortcuts in your Chrome browser called BIG-IP A GUI, if you receive a certificate warning accept and add exception (the BIG-IP has a self-signed cert which violates Chrome’s security). BIG-IP A Login credentials are admin\admin

2. f5-newman-build-1 now contains the needed calls to build the Framework of an Application Service (Virtual Server, Pool and needed Profiles), it doesn’t however include any pool members.

   Execute: f5-newman-wrapper f5-newman-build-1

   Output should look like:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85

   $ f5-newman-wrapper f5-newman-build-1 [f5-newman-build-1-2017-07-26-08-23-00] starting run [f5-newman-build-1-2017-07-26-08-23-00] [runCollection][Authenticate to BIG-IP] running... newman BIGIP_API_Authentication ❏ 1_Authenticate ↳ Authenticate and Obtain Token POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 505ms] ✓ [POST Response Code]=200 ✓ [Populate Variable] bigip_token=MB4YMPICV3XEZ3B47LJRQKGHTJ ↳ Verify Authentication Works GET https://10.1.1.4/mgmt/shared/authz/tokens/MB4YMPICV3XEZ3B47LJRQKGHTJ [200 OK, 1.23KB, 17ms] ✓ [GET Response Code]=200 ✓ [Current Value] token=MB4YMPICV3XEZ3B47LJRQKGHTJ ✓ [Check Value] token == MB4YMPICV3XEZ3B47LJRQKGHTJ ↳ Set Authentication Token Timeout PATCH https://10.1.1.4/mgmt/shared/authz/tokens/MB4YMPICV3XEZ3B47LJRQKGHTJ [ 200 OK, 1.23KB, 50ms] ✓ [PATCH Response Code]=200 ✓ [Current Value] timeout=1200 ✓ [Check Value] timeout == 1200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 8 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 1197ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.71KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 190ms │ └───────────────────────────────────────────────┘ [f5-newman-build-1-2017-07-26-08-23-00] [runCollection][1 - Build a Basic LTM Config] running... newman f5-programmability-class-2 ❏ 1 - Build a Basic LTM Config ↳ Step 1: Create a HTTP Monitor POST https://10.1.1.4/mgmt/tm/ltm/monitor/http [200 OK, 1.32KB, 625ms] ↳ Step 2: Create a Pool POST https://10.1.1.4/mgmt/tm/ltm/pool [200 OK, 1.56KB, 157ms] ↳ Step 3: Create a HTTP Profile POST https://10.1.1.4/mgmt/tm/ltm/profile/http [200 OK, 1.96KB, 183ms] ↳ Step 4: Create a TCP Profile POST https://10.1.1.4/mgmt/tm/ltm/profile/tcp [200 OK, 2.68KB, 64ms] ↳ Step 5: Create a Virtual Server POST https://10.1.1.4/mgmt/tm/ltm/virtual [200 OK, 1.9KB, 230ms] ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 5 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 0 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 1406ms │ ├───────────────────────────────────────────────┤ │ total data received: 5.79KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 251ms │ └───────────────────────────────────────────────┘ [f5-newman-build-1-2017-07-26-08-23-00] run completed in 6s, 90.207 ms

   Note

   Notice the 200 OK responses, the number of requests ect, we’re building in testing and logging, at this point look back at BIGIP-A for the newly created framework

3. On BIG-IP A, examine Virtual Server module_3_vs:

   

4. On BIG-IP A, examine Pool module_3_pool:

   

Task 3 - Execute the second f5-newman-wrapper file¶

1. f5-newman-build-2 contains calls to add pool members to the Framework of the Application Service created above; this is done independently of the build, to show staging as a possible use case.

   Execute: f5-newman-wrapper f5-newman-build-2

   Output should look like:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

   $ f5-newman-wrapper f5-newman-build-2 [f5-newman-build-2-2017-07-26-08-40-52] starting run [f5-newman-build-2-2017-07-26-08-40-52] [runCollection][Authenticate to BIG-IP] running... newman BIGIP_API_Authentication ❏ 1_Authenticate ↳ Authenticate and Obtain Token POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 272ms] ✓ [POST Response Code]=200 ✓ [Populate Variable] bigip_token=WSNAXWTCWNZGJG7MDBVF6CRXTB ↳ Verify Authentication Works GET https://10.1.1.4/mgmt/shared/authz/tokens/WSNAXWTCWNZGJG7MDBVF6CRXTB [200 OK, 1.23KB, 15ms] ✓ [GET Response Code]=200 ✓ [Current Value] token=WSNAXWTCWNZGJG7MDBVF6CRXTB ✓ [Check Value] token == WSNAXWTCWNZGJG7MDBVF6CRXTB ↳ Set Authentication Token Timeout PATCH https://10.1.1.4/mgmt/shared/authz/tokens/WSNAXWTCWNZGJG7MDBVF6CRXTB [200 OK, 1.23KB, 61ms] ✓ [PATCH Response Code]=200 ✓ [Current Value] timeout=1200 ✓ [Check Value] timeout == 1200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 8 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 1034ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.71KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 116ms │ └───────────────────────────────────────────────┘ [f5-newman-build-2-2017-07-26-08-40-52] [runCollection][2 - Add Members to LTM Config] running... newman f5-programmability-class-2 ❏ 2 - Add Members to LTM Config ↳ Step 1: Add Members to Pool PATCH https://10.1.1.4/mgmt/tm/ltm/pool/module_3_pool [200 OK, 1.52KB, 143ms] ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 0 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 182ms │ ├───────────────────────────────────────────────┤ │ total data received: 818B (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 143ms │ └───────────────────────────────────────────────┘ [f5-newman-build-2-2017-07-26-08-40-52] run completed in 4s, 328.497 ms

2. On BIG-IP A examine Virtual Server module_3_vs, the Virtual Server should be healthy and Green:

   

3. On BIG-IP A examine Pool module_3_pool:

   

Task 1 - Execute f5-newman-build-3¶

1. Open Putty and connect to the super-netops-container user credentials are snops and default

2. Navigate to the location containing the f5-newman-wrapper files cd ~/f5-automation-labs/jenkins/f5-newman-operation

3. On BIGIP-A examine the pool module_3_pool, you should see 2 active (Green) pool members:

   

4. f5-newman-build-3 contains calls to change the node state to user-down for "bigip_pool_member":"75.67.228.133:80", both of these are specified as variables in the f5-newman-wrapper files.

   Execute: f5-newman-wrapper f5-newman-build-3

   Output should look like:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82

   $ f5-newman-wrapper f5-newman-build-3 [f5-newman-build-3-2017-07-26-09-06-53] starting run [f5-newman-build-3-2017-07-26-09-06-53] [runCollection][Authenticate to BIG-IP] running... newman BIGIP_API_Authentication ❏ 1_Authenticate ↳ Authenticate and Obtain Token POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 267ms] ✓ [POST Response Code]=200 ✓ [Populate Variable] bigip_token=JFN6TNIRAWEKNR5QPM26VT4QFE ↳ Verify Authentication Works GET https://10.1.1.4/mgmt/shared/authz/tokens/JFN6TNIRAWEKNR5QPM26VT4QFE [200 OK, 1.23KB, 22ms] ✓ [GET Response Code]=200 ✓ [Current Value] token=JFN6TNIRAWEKNR5QPM26VT4QFE ✓ [Check Value] token == JFN6TNIRAWEKNR5QPM26VT4QFE ↳ Set Authentication Token Timeout PATCH https://10.1.1.4/mgmt/shared/authz/tokens/JFN6TNIRAWEKNR5QPM26VT4QFE [200 OK, 1.23KB, 26ms] ✓ [PATCH Response Code]=200 ✓ [Current Value] timeout=1200 ✓ [Check Value] timeout == 1200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 8 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 1243ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.71KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 105ms │ └───────────────────────────────────────────────┘ [f5-newman-build-3-2017-07-26-09-06-53] [runCollection][3 - Disable Node] running... newman f5-programmability-class-2 ❏ 3 - Disable Node ↳ Step 1: Check Pool Exists GET https://10.1.1.4/mgmt/tm/ltm/pool/~Common~module_3_pool [200 OK, 1.56KB, 39ms] ✓ [GET Response Code]=200 ↳ Step 2: Check Pool Member Exists GET https://10.1.1.4/mgmt/tm/ltm/pool/~Common~module_3_pool/members/~Common~75.67.228.133:80 [200 OK, 1.25KB, 33ms] ✓ [GET Response Code]=200 ↳ Step 3: Change Pool Member State PUT https://10.1.1.4/mgmt/tm/ltm/pool/~Common~module_3_pool/members/~Common~75.67.228.133:80 [200 OK, 1.25KB, 298ms] ✓ [PUT Response Code]=200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 3 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 1092ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.89KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 123ms │ └───────────────────────────────────────────────┘ [f5-newman-build-3-2017-07-26-09-06-53] run completed in 6s, 564.868 ms

   Note

   Notice the 200 OK responses, as it completed successfully

5. Log back into BIG-IP A examine the pool module_3_pool status page:

   

Task 2 - Execute f5-newman-build-4¶

1. Open Putty and connect to the super-netops-container user credentials are snops and default

2. Navigate to the location containing the f5-newman-wrapper files cd ~/f5-automation-labs/jenkins/f5-newman-operation

3. On BIG-IP A examine the pool module_3_pool, you should show only 1 Active and Green:

   

4. f5-newman-build-3 contains calls to user-up variable node "bigip_pool_member":"75.67.228.133:80"

   Execute: f5-newman-wrapper f5-newman-build-4

   Output should look like:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82

   $ f5-newman-wrapper f5-newman-build-4 [f5-newman-build-4-2017-07-26-09-12-47] starting run [f5-newman-build-4-2017-07-26-09-12-47] [runCollection][Authenticate to BIG-IP] running... newman BIGIP_API_Authentication ❏ 1_Authenticate ↳ Authenticate and Obtain Token POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 240ms] ✓ [POST Response Code]=200 ✓ [Populate Variable] bigip_token=LN5IEBCKW5TTNXZLX5VYRUTOW5 ↳ Verify Authentication Works GET https://10.1.1.4/mgmt/shared/authz/tokens/LN5IEBCKW5TTNXZLX5VYRUTOW5 [200 OK, 1.23KB, 15ms] ✓ [GET Response Code]=200 ✓ [Current Value] token=LN5IEBCKW5TTNXZLX5VYRUTOW5 ✓ [Check Value] token == LN5IEBCKW5TTNXZLX5VYRUTOW5 ↳ Set Authentication Token Timeout PATCH https://10.1.1.4/mgmt/shared/authz/tokens/LN5IEBCKW5TTNXZLX5VYRUTOW5 [200 OK, 1.23KB, 27ms] ✓ [PATCH Response Code]=200 ✓ [Current Value] timeout=1200 ✓ [Check Value] timeout == 1200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 8 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 922ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.71KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 94ms │ └───────────────────────────────────────────────┘ [f5-newman-build-4-2017-07-26-09-12-47] [runCollection][4 - Enable Node] running... newman f5-programmability-class-2 ❏ 4 - Enable Node ↳ Step 1: Check Pool Exists GET https://10.1.1.4/mgmt/tm/ltm/pool/~Common~module_3_pool [200 OK, 1.56KB, 31ms] ✓ [GET Response Code]=200 ↳ Step 2: Check Pool Member Exists GET https://10.1.1.4/mgmt/tm/ltm/pool/~Common~module_3_pool/members/~Common~75.67.228.133:80 [200 OK, 1.25KB, 28ms] ✓ [GET Response Code]=200 ↳ Step 3: Change Pool Member State PUT https://10.1.1.4/mgmt/tm/ltm/pool/~Common~module_3_pool/members/~Common~75.67.228.133:80 [200 OK, 1.25KB, 62ms] ✓ [PUT Response Code]=200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 3 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 519ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.89KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 40ms │ └───────────────────────────────────────────────┘ [f5-newman-build-4-2017-07-26-09-12-47] run completed in 4s, 510.429 ms

   Note

   Notice the 200 OK responses, as it completed successfully

5. On BIG-IP A examine Pool module_3_pool:

   

Task 1 - Execute f5-newman-build-5¶

1. Open Putty and connect to the super-netops-container user credentials are snops and default

2. Navigate to the location containing the f5-newman-wrapper files cd ~/f5-automation-labs/jenkins/f5-newman-build

3. On BIG-IP A examine the virtual server module_3_vs, it should be active and Green:

   

4. On BIGIP-A examine the pool module_3_pool, you should show 2 active members Green:

   

5. f5-newman-build-5 contains calls to delete all items we’ve created in the last few modules

   Execute: f5-newman-wrapper f5-newman-build-5

   Output should look like:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85

   $ f5-newman-wrapper f5-newman-build-5 [f5-newman-build-5-2017-07-26-09-28-13] starting run [f5-newman-build-5-2017-07-26-09-28-13] [runCollection][Authenticate to BIG-IP] running... newman BIGIP_API_Authentication ❏ 1_Authenticate ↳ Authenticate and Obtain Token POST https://10.1.1.4/mgmt/shared/authn/login [200 OK, 1.41KB, 194ms] ✓ [POST Response Code]=200 ✓ [Populate Variable] bigip_token=NGEHHD6ZDJFD2MNF2UL3UXTGVH ↳ Verify Authentication Works GET https://10.1.1.4/mgmt/shared/authz/tokens/NGEHHD6ZDJFD2MNF2UL3UXTGVH [200 OK, 1.23KB, 16ms] ✓ [GET Response Code]=200 ✓ [Current Value] token=NGEHHD6ZDJFD2MNF2UL3UXTGVH ✓ [Check Value] token == NGEHHD6ZDJFD2MNF2UL3UXTGVH ↳ Set Authentication Token Timeout PATCH https://10.1.1.4/mgmt/shared/authz/tokens/NGEHHD6ZDJFD2MNF2UL3UXTGVH [200 OK, 1.23KB, 17ms] ✓ [PATCH Response Code]=200 ✓ [Current Value] timeout=1200 ✓ [Check Value] timeout == 1200 ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 3 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 8 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 835ms │ ├───────────────────────────────────────────────┤ │ total data received: 1.71KB (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 75ms │ └───────────────────────────────────────────────┘ [f5-newman-build-5-2017-07-26-09-28-13] [runCollection][5 - Clean Up Service] running... newman f5-programmability-class-2 ❏ 5 - Clean Up Service ↳ Step 1: Delete a Virtual Server DELETE https://10.1.1.4/mgmt/tm/ltm/virtual/module_3_vs [200 OK, 740B, 57ms] ↳ Step 2: Delete a TCP Profile DELETE https://10.1.1.4/mgmt/tm/ltm/profile/tcp/module_3_tcp_clientside [200 OK, 740B, 88ms] ↳ Step 3: Delete a HTTP Profile DELETE https://10.1.1.4/mgmt/tm/ltm/profile/http/module_3_http [200 OK, 740B, 56ms] ↳ Step 4: Delete a Pool DELETE https://10.1.1.4/mgmt/tm/ltm/pool/module_3_pool [200 OK, 740B, 47ms] ↳ Step 5: Delete a HTTP Monitor DELETE https://10.1.1.4/mgmt/tm/ltm/monitor/http/module_3_http_monitor [200 OK, 740B, 59ms] ┌─────────────────────────┬──────────┬──────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────┼──────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ requests │ 5 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ test-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ prerequest-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────┼──────────┤ │ assertions │ 0 │ 0 │ ├─────────────────────────┴──────────┴──────────┤ │ total run duration: 445ms │ ├───────────────────────────────────────────────┤ │ total data received: 0B (approx) │ ├───────────────────────────────────────────────┤ │ average response time: 61ms │ └───────────────────────────────────────────────┘ [f5-newman-build-5-2017-07-26-09-28-13] run completed in 4s, 267.464 ms

   Note

   Notice the 200 OK responses, as it completed successfully

6. On BIG-IP A examine Virtual module_3_vs and Pool module_3_pool are deleted

Task 1 - Locating the Jenkins files and how they are setup¶

1. Open Putty and connect to the super-netops-container, user credentials are snops and default

2. During the installation of the super-netops-container there were several github repositories cloned, all of which are mapped to the /home/snops/ directory.

   Execute: cd ~/f5-automation-labs/jenkins to access our folder containing the Jenkins Pipeline Files

3. The Jenkins files are located alongside the f5-newman-wrapper files we’ve used in the previous labs (setup this way was for ease of learning). You may place tools in different structures in your environment.

   File Locations:

   |- /f5-automation-labs
      |- /jenkins
      |  |  /f5-newman-build
      |  |      Jenkinsfile1-2
      |  |      Jenkinsfile5
      |  |  /f5-newman-operation
      |  |      Jenkinsfile3
      |  |      Jenkinsfile4
   

4. Lets review the first Jenkins file, from the correct structure execute cat Jenkinsfile1-2

   File output:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

   node { stage('Testing') { //Run the tests //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-1" //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-2" } stage('Frameword-Deployment') { //Run SNOPS Container Newman Package Virtual and Pool sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-1" //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'good', message: 'Super-NetOps Engineer is about to deploy an F5 Service Framework, Approval Needed!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } stage('Approval') { //Gate the process and require approval input 'Proceed?' //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'good', message: 'Super-NetOps Engineer just approved a new F5 Service Framework, thats some serious Continuous Delivery!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } stage('Add-Sevice-Node') { //Run SNOPS Container Newman Package add Node to Pool sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-2" //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'good', message: 'Super-NetOps Engineer just added a Node to a Service, Production is Online!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } }

   • This is a Jenkins Pipeline file, which we will be inputing into a Pipeline deployment via our Jenkins Toolkit.
   • The file should be human readable even without Jenkins experience, a stage can be thought of as a step in the Pipeline (or a work-center in manufacturing terms); right after the stage is its name, followed by some commands. Since the super-netops-container is running this Jenkins installation locally, we can use local mappings to file structure.
   • In more common deployments the Jenkins file would be stored in a SCM (like Github) and called during an Event (Build/Pull Request) or a Polling Timer, or even some other kind of scripting launch.
   • Testing in Pipeline before executing code with tools like linter or python scripts can make sure formatting is valid, reducing errors from happening during builds.

Our installation also has some Slack calls. Which we will setup next.

Task 2 - Accessing Jenkins and Installing the Slack-Notifier Plug-in¶

Slack is a ChatOps tool, think of Skype, Messenger or IIRC! Except Slack also has the ability to take in bots. slackbots are used to interact with services, they might query something for you when asked, or give you information when they notice something. In our case our Jenkins Pipeline file will use Slack to notify all of us when an action happens, collaborative teamwork.

1. Access Jenkins via Chrome, if you didn’t set a bookmark to the mapped port you can access the service via http://10.1.1.8:10000, the user credentials are admin\default.

   

2. Once you are logged into Jenkins it should look like below

   

3. Click on Manage Jenkins

   

4. On the Manage Jenkins tab Select Available then filter on slack, once the filter is complete choose Slack Notification Plugin and execute Install without Restart

   

5. Once the Slack Notification Plugin has changed to Success, tick the radio button for Restart Jenkins when installation is complete and no jobs are running

   

6. Slack can take a few minutes to install in the background (give it 30 seconds), once the Restarting Jenkins globe is grey and the status is Running go back to Jenkins Home

   

7. Executing a restart of Jenkins your session will be ended and you will need to log back into the system

   

Task 1 - Building the Framework via Jenkins¶

This step is executing the f5-newman-wrapper files. Instead of having to run the two different builds (Framework and Pool member add) individually, Jenkins has a pause function looking for approval. After approving, this will allow the node to be added, still using 2 f5-newman-wrapper files but in conjunction with a single solution (Jenkins). Jenkins will continue to update the class via Slack as people are progressing. Jenkins will also keep a running console for logging, which we will also review.

1. From the Jenkins Dashboard click on create new jobs

   

2. We are going to create our first Pipeline Job. Name the item module_4_jenkinsfile1-2, choose the Pipeline project style and select OK

   

3. We are going to be using the raw Jenkinsfile1-2 right in the Pipeline Script option at the end of the config page. Scroll to the bottom of the page but please look at the other options to deploy a Pipeline. There are options in here such as Polling an SCM for the same file we are working with. The Polling method enables full Continuous Deployment, as Jenkins will deploy the change on a polled basis and we have an automatic testing phase for syntax in the Pipeline.

   

4. We need to enter the contents of the Jenkinsfile1-2 into the Script section under Pipeline. After the contents are added click the Save Option.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

 node {
    stage('Testing') {
       //Run the tests
       //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-1"
       //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-2"
    }
    stage('Frameword-Deployment') {
        //Run SNOPS Container Newman Package Virtual and Pool
       sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-1"
       //chatops slack message that run has completed
       slackSend(
          channel: '#jenkins_builds',
          color: 'good',
          message: 'Super-NetOps Engineer is about to deploy an F5 Service Framework, Approval Needed!',
          teamDomain: 'f5agilitydevops',
          token: 'vLMQmBq2tiyiCcZoNlbmAi0Z'
          )
    }
    stage('Approval') {
       //Gate the process and require approval
       input 'Proceed?'
       //chatops slack message that run has completed
       slackSend(
           channel: '#jenkins_builds',
           color: 'good',
           message: 'Super-NetOps Engineer just approved a new F5 Service Framework, thats some serious Continuous Delivery!',
           teamDomain: 'f5agilitydevops',
           token: 'vLMQmBq2tiyiCcZoNlbmAi0Z'
           )
    }
    stage('Add-Sevice-Node') {
        //Run SNOPS Container Newman Package add Node to Pool
       sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-2"
       //chatops slack message that run has completed
       slackSend(
          channel: '#jenkins_builds',
          color: 'good',
          message: 'Super-NetOps Engineer just added a Node to a Service, Production is Online!',
          teamDomain: 'f5agilitydevops',
          token: 'vLMQmBq2tiyiCcZoNlbmAi0Z'
          )
    }
 }

|image106|

1. Once the Job is saved, you will be taken to the stage view page, from here we are going to execute our Pipeline build, choose the Build Now option.

   

2. The Build is now running, and the stages are being executed in order. However, on our third stage we have a pause and an approval needed. Also at the same time Slack has notified us that a new service is being deployed and someone needs to approve it.

   

   

   

3. Approve the change in Jenkins to allow the build to finish. Once this is done, the approval and finished Slack notification will be sent.

   

   

4. At the end of the Build event (success or failure) there is a console output from Jenkins. Select the blue globe on the left to see the outputs

   

5. The output file not only contains the Jenkins output from the Build, but also the f5-newman-wrapper toolkit logs for easy troubleshooting

   

6. Check Slack visual for completion of everything!

   

7. Verify on the BIG-IP that the pool module_3_vs has been created and the services are Green

   

Task 2 - Jenkinsfile3 and Jenkinsfile4¶

These two Jenkins files were completed to show the ability of creating smaller deployments. In our case we will use the f5-newman-wrapper toolkit to again change the user selected state of a pool member. The different Pipelines notifications also have different Slack Color depictions, helping to quickly identify issues to team members.

1. Return to the Jenkins Dashboard and select New Item

   

2. Follow steps 2 & 3 of the last module creating 2 new Jenkins jobs, one for each desired user state.

   Pipeline Job Name: module_4_jenkinsfile_3

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

   node { stage('Testing') { //Run the tests //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-operation/f5-newman-build-3" } stage('Disable-Node') { //Run SNOPS Container Newman Package Virtual and Pool sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-operation/f5-newman-build-3" //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'bad', message: 'Super-NetOps Engineer just disabled a Service Node!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } }

3. Verify on the BIG-IP that the pool module_3_pool has a user down node

   Pipeline Job Name: module_4_jenkinsfile_4

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

   node { stage('Testing') { //Run the tests //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-operation/f5-newman-build-4" } stage('Enable-Node') { //Run SNOPS Container Newman Package Virtual and Pool sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-operation/f5-newman-build-4" //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'good', message: 'Super-NetOps Engineer just enabled a Service Node!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } }

4. Verify on the BIG-IP that the pool module_3_pool has a user up node

Task 1 - Teardown the Application via Jenkins¶

1. Return to the Jenkins Dashboard and select New Item

   

2. Follow steps 2 & 3 of the last module creating the final Jenkins job

   Pipeline Job Name: module_4_jenkinsfile_5

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

   node { stage('Testing') { //Run the tests //sh "python –m /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-5" } stage('Removal-Notification') { //Run SNOPS Container Newman Package Delete Service //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'bad', message: 'Super-NetOps Engineer is about to remove an F5 Service!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } stage('Approval') { //Gate the process and require approval input 'Delete?' } stage('Service-Delete') { //Run SNOPS Container Newman Package add Node to Pool sh "f5-newman-wrapper /home/snops/f5-automation-labs/jenkins/f5-newman-build/f5-newman-build-5" //chatops slack message that run has completed slackSend( channel: '#jenkins_builds', color: 'good', message: 'Super-NetOps Engineer removed an F5 Service successfully!', teamDomain: 'f5agilitydevops', token: 'vLMQmBq2tiyiCcZoNlbmAi0Z' ) } }

3. Verify the on the BIG-IP the service has been Deleted