Previously I wrote a post on expanding Service Now's property collection for AWS discovery using a nested property as an example, this required a small amount of scripting but I mentioned that retrieving root-level properties about an instance was a code-less process on the platform. Recently a customer asked me to show them how to collect the Private IP address of an AWS instance so i thought I would take the opportunity to do a Part 2 post to demonstrate just how easy it is to add these root-level properties to your CMDB data collection.
But before I do I wanted to take one step back and share what customers have been working with us on in relation to the public cloud, specifically AWS, and how discovery fits into our overall architecture which we are working with customers to enhance their ability to deliver these services.
There are three specific areas we have defined, building out solutions to very real problems with our customers using a variety of products and ServiceNow platform capabilities.
o Cloud Operating Model - The cloud model is fundamentally changing the typical approach of Change & Release, CMDB, etc., and while different, it is still very much a necessary framework for IT to operate to reduce risk and effectively deliver and manage services, while also bringing the desired increases in velocity and agility. Customers ask me how to take production workloads to cloud with the necessary Change, config, release, incident, with the same level of process maturity as their existing on premise services, the answer is to move the operating model away from the service provider specific level to up a level to an agnostic cross cloud platform to provide a "common operating model" across the hybrid cloud, standardizing process and policy with a consistent model regardless of the underlying infrastructure provider.
o Cost & Usage — A barrier to adoption is the anticipated cost of moving workloads to AWS compared to actual costs. We have a complete view of all cost & usage today for AWS/Azure, and we're working on solutions to show ROI actuals post-migration to the public cloud. Armed with this level of information informed decisions can be made about the most cost efficient placement of workloads, be that to a cloud provider or on premise, which we feel this will help customers make good decisions and allay cost concerns, and ultimately drive faster adoption.
o Security & Governance - Another barrier to adoption is ensuring compliance around required AWS security controls. There are many good opportunities to leverage the platform's products/capabilities with modules like Risk & Compliance, Data Certification, Vulnerability Management, SIR, etc. Using these controls the move to public cloud consumption can reap the benefits of cost efficiency and agility without opening the organization to excessive risk or expensive compliancy issues.
Hope that helps provide an overview of what business problems we are solving for our customers. The key part to solving these business problems, and the core of our platform that all of the other products rely on, is having an accurate and rich CMDB, so with that in mind back to the topic at hand, how easy it is to add these root-level properties to your CMDB discovery to enrich your CMDB data model for AWS.
First we're going to add a field on the EC2 instances table to store the new property we want to discover. Browse to System Definition > Tables, then search for the cmdb_ci_ec2_instance table.
Click into the table to access the schema and click New to add a new column. In our example we're going to be creating a string column to store our instance Private IP address, as per below.
Now that we have somewhere to store our new property, we need to tell discovery how to populate the field. As mentioned previously this is a two step process, first we define a normalised property name which maps to the field on the target table.
Browse to System Definition > Tables again, and search for the normalizedobject_db_mapping table.
Right click on the table and select Show List to view the records in the table.
Click New to create a new record for our new property, give the property a name which will be easy to remember and then select the Table and Field that we want to map the property to. In our example this is the Private IP Address column in the EC2 Instances table that we created in the previous step, once complete, save the record to the table.
The last step is to map the property that AWS is sending to us in the payload. These property names are defined by Amazon, you can view them in the payload or by manually using describe instance, or look them up in the AWS documentation.
Once you know the AWS name of the property you are looking for discovery to collect browse to System Definition > Tables again, and search for the aws_datasource_type_mapping table. This table is used to define the mapping between the AWS property and the Normalized property we created in the previous step.
Right click on the table and select Show List to view the records in the table.
In the list view click New to add a new entry to the table. The Datasource for all AWS discovery is Amazon EC2, the Resource type is Instance, and the source field is the AWS property name - in this case privateIpAddress. Once these are defined, enter the name of the Normalized property we defined in the previous step - in this case I used the same name for the normalized property as the AWS property name for simplicity, so it is again privateIpAddress. Once complete hit save to save the record in the table.
….and you're done! With just 3 steps we've added a new property to our AWS discovery data collection, this same process works for any base-level property that AWS provides, after your next discovery run the new field will be populated with data.
The only thing left to do is add the field to the form for easy viewing, to do that just browse to a record in the EC2 Instances table, right click the header and select Configure > Form Layout.
Select your new property from the Available list and move it across to the Selected list using the arrow buttons, in this case I've added the new Private IP Address field to appear below the Public IP Address field on the form.
And here's the end result. Thanks for reading I hope you found this mini-series useful!
3 Comments
