Post-provisioning operations within the Cloud Provisioning and Governance module got much simpler in the Paris release of ServiceNow due to the introduction of being able to specify subflows built in flow designer / IntegrationHub as an option for executing the post-provision task(s). In this article I will show you how to create a post-provisioning operation that will install the Agent Client Collector (ACC) to monitor a newly provisioned Linux server. This article will not discuss the pre-requisite setup needed for ACC.
To begin, you will need to know the username and password of the virtual machine being provisioned and then create a credential and credential alias for the combination. This is necessary as it will be specified in the SSH action we will define for the subflow that will install the agent.
Credential Alias to Use in Subflow Action
SSH Credential Where You Specify the Alias
Now that we have a credential ready for use in IntegrationHub, we can start building the subflow to use as a post-provisioning step.
High-Level Overview of Subflow
The inputs are important as is the final step (action 5), but we will dive into these later.
Above you see the Action "Install ACC agent on Linux". This is a custom action I created and you can see the definition below. It uses a simple SSH step and the processes the output for success or failure.
Custom Action for Installing Monitoring Agent
Once the subflow is ready (useful "Test" button on the action itself... just provide a Linux host to install on), you can get into your cloud catalog item and start adding it as a post-provisioning step.
Cloud Catalog Item with Post Provisioning Operation
The post provisioning operation (just 1 in this case) needs some variables that will be passed to our subflow defined above. The screenshot below shows the details of our post provision operation.
Passing Variables to the Subflow for Post-Provisioning
The "flowcorrelationid" must be passed to ALL subflows used for post-provisioning. This will allow the result of the subflow to be passed back to the catalog item so that the user will know the result of the execution. The other variable I use for my subflow is the stack record that results from the catalog request. This allows the subflow to use any information about the stack (we need the IP address of all virtual machines in our case). This can be done by passing the value "$(context.order.stack)".
Now that we have the post-provisioning step defined, we can request the catalog item and see that the step is executed at the end of the provisioning process.
Message Showing Post Provision Executed
At this point, we have a new virtual machine up and running with monitoring in place without having to perform the process of installing and configuring the monitoring agent manually.
To recap, this process needed the following components to work:
- A pre-known credential in the form of a credential record and alias used in the action. This could (more likely should) be built into the template used to create the cloud catalog item.
- A new IntegrationHub action to do the actual install of the agent.
- A new IntegrationHub subflow to be called in the post-provision operation.
- A cloud catalog item with a post-provision step defined and appropriate variables passed for use in the subflow.
Some considerations are around the Ihub action that does the install. First, in my example it uses a hard-coded MID server IP/port. A more ideal scenario would do some lookup on running MID servers that are configured to handle ACC agents (those with a running ACC websocket).
This type of process could be resused for installing backup agents or anything else needed in for all server or resource requests. Hope to hear what you've built with the process.
Hi Nick,
It's really great idea.
But we are not able to find the Credential Alias field in "discovery_credentials.list" table of our instances.
Is there any alternative fields for this?? or any alternative methods may help us..
Thank you
Shruti Hegde
