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 into TMOS. This utility is useful for understanding how TMOS objects map to the REST API. The interfaces implement full Create, Read, Update and Delete (CRUD) functionality, however, in 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. You can 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.

   Warning

   Skipping this step will result in errors in subsequent steps

   Warning

   We are using self-signed certificate in this lab. In your environment you must make sure that you use certificate issued by your certificate authority for both production and lab equipments. Not doing so would make it possible for an attacker to do a man-in-the-middle attack and allow him the ability to steal passwords and tokens.

   

2. Navigate to the URL https://10.1.1.10/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 credentials (admin/admin)

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. The is used to copy JSON formatted resource with Ctrl+C. This can be useful when you want to slightly change an existing resource

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

   

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 desktop of your Linux Jumphost. The initial window may take a few moments to appear.

   Note

   The Postman client receives very frequent updates. If you are prompted to update the client please click the Remind me later button to skip updating the version installed in your lab environment

2. By default the Postman clients requires verification of SSL/TLS Certificates to a public Root Certificate Authority. By default BIG-IP, and many other, devices use a Self-Signed Certificate for SSL/TLS connections. To allow connections with Self-Signed Certificates we need to modify the default settings of Postman.

   • Open the Postman Settings windows by click File ‣ Settings:

     

   • Verify your client is configured to allow self-signed certificates by setting SSL certificate verification to OFF

     

   • Click the X in the top right of the Settings window

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

   

4. 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/Class_1.postman_collection.json
   

   

5. You should now see a collection named F5 Programmability: Class 1 in your Postman Collections sidebar. Postman automatically resizes its GUI depending on its window size. It might be necessary to use the short Ctrl + \ (on Windows) or click the show sidebar icon at the bottom left corner of postman if you do not see the sidebar.

   

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. 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/Class_1.postman_environment.json
   

7. Set your environment to F5 Programmability: Class 1 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 client 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 encryption (F5 default) with a certificate signed by an authority 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 Programmability: Class 1 collection on the left side of the screen, expand the Lab 1.2 - API Authentication & 'example' Templates 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 Send button:

   

3. Click the Headers tab and examine the HTTP header. Notice that the number of Headers in the Headers tab changed from 1 to 2. This is because Postman automatically created the HTTP header and updated your request to include it.

   

4. Click the Body tab, if the request succeeded you should be presented with a listing of the /mgmt/tm/ltm Organizing Collection:

   

5. Click the Test Results tab and ensure all the tests for this request have passed:

   

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

   

7. Check the Test Results tab and notice that our Unit Tests for this request are now failing (as expected):

   

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. TBA only sends the credentials once, on the first request. The system then responds with a unique token for that session and the consumer then uses that token for all subsequent requests. BIG-IP 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 (Active Directory, RADIUS, TACACS, 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.

Perform the following steps to complete this task:

1. Click the Step 2: Retrieve Authentication Token item in the Lab 1.2 Folder

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 F5 Programmability: Class 1 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. Because the subsequent requests refer to the {{bigip_a_auth_token}} variable, you will not have to set the token in the header of the following requests.

13. Click the Step 4: Set Authentication Token Timeout item in the Lab 1.2 Postman folder. This request will PATCH your token Resource (notice 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 request. Click the Send button and review the response body to see what the current settings on the device are. Examine the resulting response to understand what settings are currently applied.

3. Click the Step 2: Set System Global-Settings request. This item uses a PATCH request to the global-settings resource to modify the attributes contained within it. We will update the guiSetup and hostname attribute.

   • Click on body. 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 by looking at the response. You can also GET the global-settings by sending the Step 1: Get System Global-Settings request again to verify they have been updated.

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 folder. Click Send and review the current settings
2. Click the Step 4: Set System DNS Settings item in the folder. Click body. Review the JSON body to verify the name server IPs 4.2.2.2 and 8.8.8.8 are listed. Additionally, add a search domain of f5.local. You will modify a JSON array to add a search domain.
3. Click the Send button and verify the requested changes were successfully implemented by looking at the response or by sending the Step 3: Get System DNS Settings request again.
4. Click the Step 5: Get System NTP Settings item in the folder. Click Send and review the current settings
5. Click the Step 6: Set System NTP Settings item in the folder. Click Body. Review the JSON body to verify the NTP servers with hostnames 0.pool.ntp.org and 1.pool.ntp.org are contained in the servers attribute (another JSON array!).
6. Click the Send button and verify the requested changes were successfully implemented by looking at the response or sending the Step 5: Get System NTP Settings again.

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 than other system accounts because it is used by underlying Linux OS.

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

To update all other system accounts we will PATCH the /mgmt/tm/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 folder.

2. We are performing a POST operation to change the root user password and have to specify the oldPassword because the REST implementation on the BIG-IP uses the underlying Linux mechanism. Click Body. 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 to BIG-IP-A. A shortcut to a terminal is included on the desktop of the Linux jumphost. To open an SSH connection to BIG-IP A open a terminal window and execute ssh root@10.1.1.10

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. We are performing a PATCH operation to admin user Resource. Click Body and 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

   OR by logging into TMUI (HTTP GUI) to BIG-IP-A 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 request in the folder. Click Body and examine the JSON request 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 shown in the table above. In order to do so you can replace the following:
   • name: Internal –> External
   • tag: 10 –> 20
   • interfaces[] --> name: 1.1 –> 1.2
5. Click the Step 2: Get VLANs request in the folder. Click the Send button to GET the VLAN collection. Examine the response to make sure both VLANs have been created.

Task 2 - Create Self IPs¶

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

1. Click the Step 3: Create Internal Self IP request in the folder. Examine the JSON body; the values for creating the Self-Internal Self IP have already been populated.

   Note

   The JSON body sets the VLAN to /Common/External on purpose. You will modify this value in the steps below. Please do not change the value.

2. Click the Send button to create the Self IP

3. Click the Step 4: Create External Self IP request in the folder and click Send

4. Click the Step 5: Get Self-Internal Self IP Attributes request in the folder and click the Send button. Examine the VLAN settings of the Resource. As noted above the Self IP has been assigned to the wrong VLAN (intentionally)

   Note

   Postman has the ability to check the responses for specific values to verify if the result of a request is what it is expected to be. The :guilabel:Test Results for this request will show a failure for the [Check Value] vlan == /Common/Internal value. This is intentional and you should continue to the next section.

   

Task 4 - Create Routes¶

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

1. Before creating the route, we double check the content of the routing table. Click the Step 7: Get Routes item in the collection. Click the Send button to GET the routes collection. Examine the response to make sure there is no route.
2. Click the Step 8: Create a Route item in the collection. Examine the JSON body; the values for creating the Default Route have already been populated.
3. Click the Send button to create the Route
4. Click the Step 9: Get Routes item in the collection again. Click the Send button to GET the routes collection. Examine the response to make sure the route has been created.

Task 1 - Open and Run a Collection¶

1. The collection we will run in this task will populate some environment variables with various data about the BIG-IP system. First, let’s examine the Environment Variables that are currently set. Click the icon in the top right of the Postman window. Notice that there are no variables starting with the name lab1.5_:

   

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

3. Click the Step 1: Get BIG-IP Software Version request. Click the Tests tab and examine the Javascript code and comments:

   

   The Javascript code in the Test script will populate an environment variable based on the response from the BIG-IP system.

4. Click the Runner button at the top right of your Postman window:

   

5. Select the F5 Programmability: Class 1 Collection then the Lab 1.5 - Building Imperative Workflows folder. Next, be sure the environment is set to F5 Programmability: Class 1:

   

   Your Runner window should look like:

   

6. Click the Run Lab 1.5 - Buil… button

7. The results window will now populate. You will see each request in the folder is sent and it’s associated test results are displayed on the screen. The last request in the folder includes some Javascript code to dump the results to the screen:

   

8. Next, switch back to the main Postman window. Click the button again and examine the environment variables. Notice that three new variables starting with the name lab1.5_ have been populated:

   

In this lab, we demonstrated running a simple Imperative Workflow using the Postman Collection Runner. In subsequent labs, we will expand on this simple use case to perform more complex functions. As you continue through the labs be sure to take time to explore the details of the requests being sent. The Postman Collection used in this class can also serve as a starting point for building your own collections or modifying existing ones.

As we move through the rest of this module you will see the complexity involved in building Imperative Workflows. While these types of workflows are incredibly powerful, they are also time-consuming to build from scratch. As we move into Module 2 you will see the importance of leveraging Abstraction and Declarative Interfaces to minimize the amount of time spent building Imperative Workflows.

Task 1 - Build a Cluster using Runner¶

In this task we will use the Runner to execute a series of requests contained in the Lab 1.6 - Build a Cluster folder. As mentioned previously this folder contains a large number of REST requests required to build an Active/Standby cluster. Additionally, we will make use of a JavaScript framework called f5-postman-workflows that extends the Postman client to include common test and polling functions.

Perform the following steps to build the cluster:

1. Click the Runner button at the top right of your Postman window:

   

2. Select the F5 Programmability: Class 1 Collection then the Lab 1.6 - Build a Cluster folder. Next, be sure the environment is set to F5 Programmability: Class 1:

   

   Your Runner window should look like:

   

3. Click the Run Lab 1.6 - Buil… button

4. The results window will now populate. You will see each request in the folder is sent and it’s associated test results are displayed on the screen. Building the cluster can take a few minutes. You can follow the progress by scrolling down the results window.

5. Once the Run Summary button appears the folder has finished running. You should have 0 failures and the last item in the request list should be named Cleanup Environment

   

6. At this point you can log into BIG-IP A using Chrome at https://10.1.1.10 and verify the cluster was built by using the menu in the BIG-IP GUI to navigate to Device Management ‣ Overview and verifying the cluster and failover status indicators are all Green

   

Task 1 - Create a Transaction¶

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 (all-or-nothing). 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 committing.

Perform the following steps to complete this task:

1. Expand the Lab 1.7 - Build a Basic LTM Config using 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 endpoint 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. 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:

   

   The transId value has been automatically populated for you in the bigip_transaction_id environment variable:

   

4. 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 POST request method, 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:

   

5. Click the Send button and examine the response

6. Examine and click Send on Steps 3-6 in the folder

7. 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 ordered commands in the transaction.

Task 2 - Modify a Transaction¶

1. Click the Step 8: View Queued Command 4 from Transaction item in the folder. Examine the request method and URI. We will GET command number 4 from the transaction queue.

   

2. Click the Step 9: Change Eval Order 4 -> 1 item in the folder. Examine the request method, 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:

   Note

   Requests in the ordered transaction queue must obey the order of operations present in the underlying BIG-IP system.

   Warning

   When sending the Header X-F5-REST-Coordination-Id, the system assumes you want to ADD an entry in the transaction queue. You MUST remove this header if you want to issue transaction queue changes (like deleting an entry from the queue, changing the order, committing a transaction). If you don’t remove the header, the system will respond with a 400 HTTP error code with the following error text:

   "message": "Transaction XXXXX operation .... is not allowed to be added to transaction."

   

3. Click the Step 10: View the Transaction Queue Changes item in the folder. Verify that request number 4 has moved into position 1 and the order of all other requests has been updated accordingly.

Task 3 - Commit a Transaction¶

1. Click the Step 11: Commit the Transaction item in the folder. Examine the request type, URI and JSON body. We will PATCH our transaction resource and change the value of the state attribute to submit the transaction:

   

2. Click the Send button and examine the response. The state may already be COMPLETED, however, it’s good practice to explicitly check for this.

3. Click the Step 12: View the Transaction Status item in the folder and click the Send button. Verify that the state of the transaction is COMPLETED

4. You can verify the configuration was created on the BIG-IP device via the BIG-IP A GUI at https://10.1.1.10

5. Verify the virtual server works by opening http://10.1.20.120 in the Chrome web browser

iApp Templates & Deployments¶

A BIG-IP device has multiple ways to install an iApp onto its platform, including TMOS Shell (TMSH), the GUI (TMUI), and the REST Interface. All mechanisms are valid and, if needed, can be used in conjunction with each other.

For instance, you can install an iApp template from the GUI and then deploy a new service via iControl REST using tools like cURL, Postman and Ansible.

F5 iApps were introduced in TMOS Version 11, they can interact within, and across different F5 modules providing full Layer 4-7 Application Service capability. The iApp Template is used to drive an iApp Deployment that creates a configuration under an Application Service Object (ASO). The ASO model identifies which objects belong to the iApp service deployment. Upon service deletion, all service related objects are recursively deleted.

Some examples of the modules we can use iApp templates to configure:

• Local Traffic Manager
• Advanced Firewall Manager
• Application Security Manager
• Access Policy Manager

You can find the GUI representation of iApps on the left-hand side of the UI under iApps. iApp deployments are located under Application Services, while iApp templates are located under Templates on the system.

• Application Services (iApp deployments)

  

• Templates (iApp templates)

  

The associated REST API endpoints are:

• iApp Deployments: /mgmt/tm/cloud/services/iapp
• iApp Templates: /mgmt/tm/sys/application/template

iApp Deployments and Source-of-Truth¶

By default, iApp technology implements a strict source-of-truth preservation mechanism called Strict Updates. The App Service iApp allows granular configuration of the underlying TMOS objects without disabling the Strict Updates mechanism, however, not all iApp templates implement this functionality.

In non-automated environments, the impact of this can be justified. However, in automated environments we must always guarantee that the template inputs are the Source-of-Truth for an underlying deployment. As a result, Strict Updates should not be disabled.

For example, creating an iApp deployment, disabling Strict Updates and then modifying the underlying configuration results in a Source-of-Truth violation because redeployment of the iApp would result in the changes made directly to the configuration being overwritten. It is because the direct modification of the configuration moved the Source-of-Truth to the object itself, rather than the iApp deployment input values that automation tools are interacting with.

Task 1 - View Installed iApp Templates¶

Perform the following steps to complete this task:

1. Send the Step 1: Get Installed iApp Templates request to view iApp templates installed on the BIG-IP device:

   

2. Review the JSON response Body. The JSON payload shows a iApp templates that are installed by default on the BIG-IP device:

   

Task 2 - Install the App Services iApp Template¶

Perform the following steps to complete this task:

1. Send the Step 2: Install App Svcs v2.0.004 iApp Template request to install the iApp template:

   

2. Review the Request JSON Body, and the Response JSON Body. In this task we installed the App Services iApp Template and the BIG-IP sent back a response that the iApp was installed with its object name.

   Note

   The JSON body in the Request portion is automatically generated as part of the build process for the App Services iApp and the request in the Postman Collection was copied from a pre-built collection that ships with releases of the App Services iApp template.

   

Task 1 - View Deployed Services¶

Perform the following steps to complete this task:

1. Send the Step 1: Get Deployed iApp Services request to view current iApp deployments on the BIG-IP device:

   

2. Review the JSON Response Body. The BIG-IP device does not have any iApp deployments. As a result the items array is empty ([]):

   

Task 2 - Deploy Basic HTTP Service¶

Perform the following steps to complete this task:

1. Click Step 2: Deploy Service - HTTP. Review the Request JSON Body. The JSON body of the POST contains the input for the iApp template to drive the deployment of the service.

   

2. Click the Send button to Create a Basic HTTP Service:

   

   In this task, we deployed our first service. Review the Response JSON Body to verify if the Service has been deployed.

   

   Note

   We’ve just progressed into a Declarative instantiation, by defining the end state and letting the BIG-IP handle the order of operations and configuration of the specific objects. By doing this, we have drastically reduced the Domain Specific Knowledge requirement to interact with the device. In the next module, we will combine this concept with Abstraction to further simplify the interface.

3. Now that the service has been deployed, let’s review the BIG-IP configuration. You can review via REST by sending the Step 1: Get Deployed iApp Services request again, or you can login to the BIG-IP A GUI and see the service deployment via TMUI:

   • REST: Send Step 1: Get Deployed iApp Services request:

     

   • TMUI GUI: iApps ‣ Application Services ‣ Applications

     

4. From the TMUI GUI, examine the Virtual Server that was created from this deployment by clicking Local Traffic ‣ Virtual Servers ‣ Virtual Server List ‣ Demo_vs. The configuration is simple, but it does contain the key components for an HTTP service (Listener, HTTP Profile, Monitor, Pool, and Pool Members):

   

5. The service is available and active, you can connect to the Virtual Server using Chrome at http://10.1.20.121 and examine its response:

   

   Note

   The colors of the text, images, and borders may vary based on which back-end server was selected during the load balancing process.

Task 3 - Modify our Deployed Service¶

In this task, we will modify the existing service. We will disable all pool members and bring the service down.

Perform the following steps to complete this task:

1. Click on Step 3: Modify Service - HTTP. Review the Request URL and JSON Body. Notice that we specified the Resource URL for our deployment. Modifying or Redeploying a service is handled by sending only the updated JSON to the specific Resource (our service) using a PUT request method. We set the state of the pool members to disabled which forces the service offline.

   

2. Click the Send button to Modify the previously deployed Basic HTTP Service:

   

3. In the BIG-IP GUI click Local Traffic ‣ Network Map to view the new state of the Pool Members (Black indicators reflect the disabled state). The state has been updated to reflect the state we declared in our call. The Virtual Server is no longer passing traffic at http://10.1.20.121 because all the Members in the Pool are disabled:

   

Task 4 - Delete our Deployed Service¶

The lifecycle of a service also includes the service removal. We will now delete an existing service.

Perform the following steps to complete this task:

1. Send the Step 4: Delete Service - HTTP request to Delete the previously deployed Basic HTTP Service:

   

2. Like modification, the deletion of a service is performed on the Resource URL. When we created the service we defined a Declarative state to the iApp template. The template then created the configuration and all the associated objects. With a DELETE request, the BIG-IP will processes the removal of all objects linked to the ASO in the correct order. This is crucial to Application Lifecycle Management as it provides a mechanism to make sure all parts of the service are removed successfully.

   Note

   There is no JSON body to a DELETE call, as the HTTP Method is defining the action.

   Now that the service has been deleted, let’s review the BIG-IP configuration. You can review via REST by sending the Step 1: Get Deployed iApp Services request again, or you can login to the BIG-IP A GUI and see the service deployment via TMUI:

   • REST: Send Step 1: Get Deployed iApp Services request:

     

   • TMUI GUI: iApps ‣ Application Services ‣ Applications

     

Task 5 - Deploy an HTTP Service with Custom created Profile and a referenced iRule¶

Perform the following steps to complete this task:

1. Send the Step 5: Deploy Service - HTTP w/ iRule and Custom Profiles request to deploy an HTTP Service with Custom Profiles and an iRule:

   

2. The App Services iApp can Create or Reference various objects. In this deployment we perform two actions:

   1. Create custom profiles on the BIG-IP device with various options specified. These profiles do not exist on the BIG-IP but are created dynamically during the deployment.

   2. Create an iRule on the BIG-IP device by using a URL Reference. The App Services iApp downloads the iRule resource from the URL and then creates a new iRule object on the system. The iRule object is then automatically linked to the Virtual Server

      Warning

      When using URL references, it is important to properly secure the repository which hosts the resource(s). The example in this lab uses a publicly readable repository, however, most environments should use a private repository with appropriate access control.

3. Review the Request JSON Body to see how the desired outcomes above were declared:

   • Custom Profiles:

     

   • URL Referenced iRule:

     

   • iRule linked to Virtual Server: (Local Traffic ‣ Network Map)

     

4. Open Chrome and connect to the Virtual Server at http://10.1.20.121. The iRule that was attached to the service contains an HTTP_RESPOND event, which responds with a simple Maintenance Page.

   

Task 6 - Deploy an HTTPS Service¶

Perform the following steps to complete this task:

1. Send the Step 6: Deploy Service - HTTPS request to deploy an HTTPS Service using URL Resources for the SSL/TLS Key, Certificate and Certificate Bundle.

   

2. iApps are a Declarative interface, allowing us to modify deployment without the need to delete it (this also means we can re-name objects if we needed too). For this service we will:

   • Use the same custom profiles

   • Remove the iRule

   • Change the Listener port to 443 (HTTPS)

   • Use URL Resources to obtain the SSL/TLS Key, Certificate and Certificate Bundle

     Warning

     When using URL references, it is important to properly secure the repository which hosts the resource(s). The example in this lab uses a publicly readable repository. However, most environments should use a private repository with appropriate access control.

   • Create and apply a Client SSL Profile

3. Review the Request JSON Body to see how the desired outcomes above were declared:

   

4. Review the configured Virtual Servers in the TMUI GUI. The App Services iApp created a new Virtual Server to redirect TCP/80 traffic to TCP/443 and reconfigured the Virtual Server to listen on TCP/443

   

5. The configuration of the Virtual Server now uses an SSL Client profile containing our imported SSL Resources. The deployment is now providing SSL Offload for the backend compute nodes.

   

6. Open Chrome and access the service with http://10.1.20.121. It should redirect you to https://10.1.20.121.

   Note

   We are using self signed certificates in the lab so an SSL warning will be shown.

   Warning

   When you open this page you may continue to keep the Maintence Page from the previous Task. This occurs because of two reasons:

   1. Chrome keeps HTTP connections open in the background to improve network performance
   2. BIG-IP maintains a fully versioned configuration internally. Stateful connections, like HTTP, are then pinned to a specific version of the configuration for the lifetime of the connection.

   As a result, because Chrome has not closed the actual TCP connection, BIG-IP still processes traffic with the configuration that was present when the connection was originally created.

   You can open an Incognito Chrome Window (Ctrl-Shift-N) and try to connect to http://10.1.20.121 again. The connection in the Incognito window should behave as expected because it’s a new connection and therefore uses the most recent configuration.

   

Task 7 - Deploy an HTTPS Service with an Web Application Firewall Policy¶

Another advantage of Service Deployment using iApp Templates is that they can deploy advanced Layer 4-7 services from various F5 modules. In this task we will deploy a service that includes a Web Application Firewall policy with the base HTTPS offload and load balancing features.

Perform the following steps to complete this task:

1. Send the Step 7: Deploy Service - HTTPS w/ WAF Policy request to deploy an HTTPS Service using URL Resources for a Web Application Firewall policy that will be used with the Application Security Manager (ASM) module.

   

2. This final iApp deployment will build upon our service by having the iApp load a WAF policy Resource from our repository. The App Services iApp will then create a Layer 7 Traffic Policy and apply it to the Virtual Server.

   This deployment recognizes the need for Security from the beginning of the application lifecycle. It lays the groundwork for Continuous Improvement by having the policy reside in a repository. It allows us to treat resources as code leading to an Infrastructure as Code (IaC) methodology. As the policy is updated in the repository additional automation and orchestration can be enabled to deploy the policy into the environment. The result is an ability to rapidly build, test and iterate Layer 7 security policies and guarantee deployment into the environment.

3. Review the Request JSON Body to see how the desired outcomes above were declared:

   • Layer 7 Policy Rules:

     

   • Layer 7 Policy Actions:

     

   • ASM Policy URL:

     

4. In the TMUI GUI, we can see the Layer 7 policy applied to the Virtual Server. In the Application Security, we can see the details of the policy which was dynamically fetched, applied, and set to Blocking mode.

   • Layer 7 Policy:

     

   • Layer 7 Policy attached to Virtual Server:

     

   • ASM WAF Policy:

     

iWorkflow Overview¶

Before looking at the details of the onboarding process, lets discuss the new components iWorkflow introduces to our toolchain.

Onboarding Process Overview¶

The process implemented in the Lab 3.1 - iWorkflow Onboarding folder of the Postman collection is diagrammed below.

Task 1 - Onboard iWorkflow using Runner¶

In this task we will use the Runner to execute a series of requests contained in the Lab 3.1 - iWorkflow Onboarding folder.

Perform the following steps to build the cluster:

1. Click the Runner button at the top right of your Postman window:

   

2. Select the F5 Programmability: Class 1 Collection then the Lab 3.1 - iWorkflow Onboarding folder. Next, be sure the environment is set to F5 Programmability: Class 1:

   

3. Click the Run Lab 3.1 - iWor… button

4. The results window will now populate. You will see each request in the folder is sent and it’s associated test results are displayed on the screen. Onboarding iWorkflow can take a few minutes. You can follow the progress by scrolling down the results window.

5. Once the Run Summary button appears the folder has finished running. You should have 0 failures and the last item in the request list should be named Install App Services Template on iWorkflow

   

6. At this point you can log into iWorkflow using Chrome at https://10.1.1.12 and admin/admin credentials. Click Clouds and Services at the top of the window:

   

7. Browse the various panes to see what was created:

   

Task 1 - Create the Service Templates¶

In this task we will use the Runner to quickly create our sample Service Templates. Perform the following steps to complete this task:

1. Click the Runner button at the top right of your Postman window.

2. Select F5 Programmability: Class 1 ‣ Lab 3.2 - Create a Declarative Service Catalog folder.

3. Select the F5 Programmability: Class 1 environment

4. Click the Run Lab 3.2 - Crea… button and wait for the run to complete. Verify no errors were encountered.

5. Open the iWorkflow GUI in Chrome by navigating to https://10.1.1.12

6. Expand the Service Templates panel and verify all the templates have been created:

   

Task 2 - Explore the f5-http-lb-v1.0 Template¶

Now that we’ve created our Templates let’s review one of them in depth.

Perform the following steps to complete this task:

1. Open the f5-http-lb-v1.0 Template by double clicking it:

   

2. Let’s examine the Properties pane.

3. Select All in the Displayed Parameters section:

   

4. This pane shows detailed information about the Template such as:

   • iApp Template Name & Version the Service Template is using
   • The Connectors/Clouds that may use this template
   • A control that toggles which Parameters are displayed in the pane
   • The input Sections and Fields (collapsed in screeshot) for the iApp Template

   

5. In the Sections portion of the pane, find the Virtual Server Listener & Pool Configuration section. Click the triangle to expand the section:

   

6. You can now see all the input fields associated with this section of the iApp template. These fields are defined by the iApp Template itself. In the previous lab, when we installed the App Services iApp Template, iWorkflow created a internal representation of the input fields used in the iApp template. iWorkflow then allows you to create a template that:

   • Define which fields are Tenant Editable, therefore exposed to the Tenant interface
   • Setting a default value for the field
     • If the field is NOT Tenant Editable the default value is sent during a Service Deployment, however, the Tenant cannot see or modify the value
     • If the field is Tenant Editable the default value is populated for the Tenant and the Tenant may edit it during a Service Deployment

   

   In the case of the fields shown in the example:

   • pool__DefaultPoolIndex: A value of 0 will be sent during a deployment
   • pool__MemberDefaultPort: Nothing will be sent
   • pool__addr: Tenant will be allowed to populate the field with a value
   • pool__mask: A value of 255.255.255.255 will be sent
   • pool__port: Tenant will see 80 and can change the field

   By combining different combinations of Default Values and Tenant Editable fields you can create many different types of templates to match your requirements.

   Note

   The App Services iApp Template has been specifically designed to integrate with iWorkflow and Automation use cases. While any iApp template that is properly versioned can be used with iWorkflow, you should consider whether the template was designed for Automation use cases or not. Many iApp templates were designed for a GUI or Wizard based interaction through the BIG-IP TMUI GUI. As a result those templates may not present a good API interface.

7. In addition to simple text fields, iApp templates also support table based input. The App Services iApp uses this capability to allow input of more complex data such as Pools, Pool Members and Layer 7 Routing Policies. iWorkflow allows you to have granular control over how the Tenant can interact with a table. Let’s find the pool__Pools table and click the triangle to expand it:

   Note

   To accomodate screen size this screenshot does not show all the columns in the table.

   

   The highlighted sections in the image above correspond to the capabilities in the list below:

   • [1] Definition of the Min and Max number of rows in a table
     • Example: Define a fixed number or limit for the number of Pools a Tenant can deploy
   • [2] Default Values for each column in a table
     • Example: Define a default Load Balancing Method for deployed Pools
   • [3] Tenant Editable flag for each column in the table
     • Example: Only allow the Tenant to control the Load Balancing Method and Name of a Pool, while defaulting all other values.
   • [4] Default Rows that auto-populate a desired input for the Tenant. Each row can have a No Access, Read-Only or Write ACL applied.
     • Example: Define a Service that allows URL Based Content Routing to only two pools.
       • Define 2 Default Rows in the Pools table
       • Set the Min & Max value to 2

8. Finally, to assist in designing a Tenant interface, iWorkflow allows you to preview what the Tenant UI would look like for a Service Template. To view preview for click the Tenant Preview button:

   

9. The preview window shows how the Tenant UI would present the Service Template. As you can see the interface is vastly simplified and only Tenant Editable fields are shown. Because the true deployment details are filtered from the Tenant, the Service Deployment requires much less Domain Specific Knowledge. Keep in mind that while the Tenant interface may be simple, you can leverage advanced functionality in the Service Template.

   

Task 3 - Explore the Remaining Service Templates¶

Using the pattern in the last task explore the other Service Templates that were created earlier. A description of each Service Template is included in the table below. In all cases the Template has been configured with the appropriate Monitors, Profiles and Options for the use case.

Tenant Overview¶

iWorkflow Tenants allow Consumers to perform Service Lifecycle operations in an isolated environment. All actions performed prior to this lab have been in what’s called the Provider space and, by nature, are masked from Tenants unless specifically exposed. As a result of the Tenant isolation, each Tenant maintains its own set of Users and Roles associated with those users, allowing each Tenant full control of the actions Tenant Users can perform.

During our iWorkflow Onboarding process in Lab 3.1 we created a Tenant named MyTenant and an associated Tenant User with a username of tenant. Additionally we gave MyTenant access to the BIG-IP Connector named BIG-IP A&B Connector:

This gives the tenant user the ability to perform CRUD operations on Service Deployments.

Create¶

Perform the following steps to complete this task:

1. Click the Deploy example-f5-http-lb Service request in the folder.

2. Examine the URI. Notice that the variable iwf_tenant_name is used to specify the Tenant we are performing the operation on. In this case iwf_tenant_name is set to MyTenant in the Postman environment:

   

3. Examine the JSON Request Body; it contains the following data:

   • Deployment name
   • A URI Reference to the Service Template f5-http-lb-v1.0
   • The input vars and tables for the deployment. These fields were marked Tenant Editable in the Service Template
   • A URI Reference to the Connector to use for deployment. This specifies which BIG-IP devices will be used for this deployment

   The data in the list above is higlighted below:

   

4. Click the Send button to Create the Service Deployment

5. Switch to the Chrome iWorkflow Tenant UI window. The example-f5-http-lb Service is now present in the L4-L7 Services pane. Double click the Service and examine its properties. You can compare the values in the UI to the JSON Request Body from the step above.

   

6. Open a Chrome window/tab to the BIG-IP A GUI at https://10.1.1.10 and login with admin/admin credentials. Navigate to iApps ‣ Application Services. Select example-f5-http-lb from the list of deployed services and examine the Components of the deployed service:

   

Update¶

Perform the following steps to complete this task:

1. Click the Modify example-f5-http-lb Service request in the folder.

2. We will send a PUT request to the Resource URI for the existing deployment and add a Pool Member as shown in the JSON Request Body:

   

3. Click the Send button to Update the Service Deployment

4. Update the iWorkflow Tenant UI and notice that the Service has been updated:

   

5. Update the BIG-IP GUI and notice that the Components tree has been updated:

   

Read¶

Perform the following steps to complete this task:

1. Click the Get example-f5-http-lb Service request in the folder.

2. We will send a GET request to the Resource URI for the existing deployment.

3. Click the Send button to Read the Service Deployment

4. Examine the JSON Response Body to see the state of the current Service Deployment:

   

Delete¶

Perform the following steps to complete this task:

1. Click the Delete example-f5-http-lb Service request in the folder.

2. We will send a DELETE request to the Resource URI for the existing deployment.

3. Click the Send button to Delete the Service Deployment

4. Update the iWorkflow Tenant UI and verify that the Service has been deleted:

   

5. In the BIG-IP GUI navigate to iApps ‣ Application Services and verify the service was deleted.

   

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 3.4 - iWorkflow REST Proxy folder in the Postman collection.

2. Click the Step 1: Create pool on BIG-IP A. Examine the request type, URL and JSON body. Essentially we are performing a POST to the ‘/mgmt/tm/ltm/pool’ collection on BIG-IP 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 in the Headers tab.

   

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 --rm hello-world

Example output:

$ 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.

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 and verfiy 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:jenkins

   Example output:

   $ docker pull f5devcentral/f5-super-netops-container:jenkins
   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:jenkins
   

2. Execute docker images

   Example output:

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

Task 2 - Start the container image¶

To start using the container we will execute the command:

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

container: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=master
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.

Its likely that the installation of the f5-super-netops-container will not be on a localhost while running in a large environment, the steps below show how you can leave this instance running as a background process, if needed.

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=master f5devcentral/f5-super-netops-container: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

The container includes the snops user with a password of default. If you are not using the F5 Lab environment 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 of connecting to the container:

$ 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 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=master f5devcentral/f5-super-netops-container: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 outside of the F5 Lab environment via HTTP, open a web browser and enter the URL:

http://(YourDockerSever):8080/start

You should see a page like this:

Task 3 - Connect via Jenkins¶

To connect to the image via Jenkins we 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=master f5devcentral/f5-super-netops-container: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://(YourDockerSever):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, in some cases the Collections dont appear until Postman has been closed an relaunched.

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

To utilize the helper functions the framework includes, 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¶

First, we will import two collections to Postman using the same steps in the previous labs. The two different collections will allow us to perform REST API Authentication to BIG-IP devices and then execute Operational actions on the BIG-IP device. We are stitching together two Imperative process’s.

Execute the following steps to complete this task:

1. Click Import -> Import from Link and import both of 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 opened 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 (A Waterfall). 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 performs unit tests on the response data, and verifies 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. Return to, or 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, similar to how this was shown in the Postman GUI Environment Variables. 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. Return to or open a new session 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. Return to or open a new session 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) } ] }

#. The above f5-newman-wrapper file only has the Authenticate to BIG-IP Collection/Folder referenced, we will need to 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, shown in a previous lab. For editing files VIM/VI is installed on the container, if you do not know how to use VIM/VI please let the instructor know.

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" }

1. Now that you have the full file you can see what it will look like with cat f5-newman-build-1. The environment variables will float into both Collections, and the returned Global Variables will persist during the whole run.

Example of a complete file:

 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

{
       "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"
                       }
               },
               {
                    "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, look back at BIGIP-A for the newly created Application Service 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 Application Service Framework created above; this is done independently of the build, to show Service 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. Return to or open a new session 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. Return to or open a new session 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 all Nodes should be back to the beginning state:

   

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

1. Return to or open a new session 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. Return to or open a new session to the super-netops-container, user credentials are snops and default

2. During the installation of the f5-super-netops-container there were several github repositories cloned, all of which are mapped to the /home/snops/ directory. Lets make sure the Jekins files were mapped correctly.

   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 current folder 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 toolkit, think of Skype, Teams, Messenger, or IIRC! Except Slack also has the ability to take in bots. slackbots are used to interact with services, they might query for something 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.

Note

In the Jenkins Files, the message piece is sent to the Slack channel, if you would like to modify your messages for our lab change the text!

1. Access Jenkins via Chrome, there is already a bookmark Jenkins created on your behalf , 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 will stop your session, you will need to log back into the system

   

Task 1 - Building the Application Service Framework via Jenkins¶

This step is executing the f5-newman-wrapper files. Instead of having to run the two different builds (Application Service Framework and Pool member add) individually we’ll us a pause. Jenkins has a pause functionality which pausing the deployment looking for an approval to continue. After the approving step, 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 does 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 which can deploy a Pipeline. The different options in here are for an SCM (like GitHub), the Polling or Commit methods enable Continuous Deployment, as Jenkins will deploy the change on an event basis. Tie this with automatic testing to make sure you’re not breaking the build!

   

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

 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'
          )
    }
 }