Blog

Enterprise CMDBs and the Cloud: APIs will Keep Us Together

While the cloud has become a welcome channel for companies refining their server footprint, it’s still rare to find an established business that is running *solely* in the cloud. Rather, many companies leverage the cloud for specific workloads and new cloud-first applications, while keeping other servers and applications in-house. But are you tracking your cloud servers the same way you track on-premises ones? Do you have a single place to see a list of ALL your servers and when they last changed? Configuration management databases (CMDBs) are a popular way to store information about IT assets such as who owns them, where they physically are, and their change history. How can you take advantage of the cloud while retaining a complete, up-to-date CMDB? One option is to programmatically link cloud servers to your CMDB through the use of cloud APIs. In this blog post, we’ll see an example of that process in action.

Step 1: Link Cloud Servers to CMDB Entries

Let us first consider the “IT-as-a-Service” scenario where an internal customer portal serves as the launching pad for new cloud servers. Using the CenturyLink Cloud API, customers can easily provision and manage their cloud servers without ever logging into our Control Portal.

Linking CMDB to CenturyLink Cloud Cloud Servers

Here, the customer’s own portal gives internal employees the opportunity to quickly spin up a cloud server. After adding a record to the CMDB and getting back the CMDB record locator, the CenturyLink Cloud CreateServer API operation is called. CenturyLink Cloud servers can have user-defined metadata attached to them, and in this case, that metadata consists of the CMDB record ID.  The server build request is queued by the CenturyLink Cloud engine and the name of the new server is returned by calls to the GetDeploymentStatus API operation. The name of the CenturyLink Cloud server can optionally be added to the CMDB configuration item in order to create a bi-directional link between the systems. At this point, the internal CMDB has a list of servers built internally or in the CenturyLink Cloud cloud.

Step 2: Synchronize Updates

A wonderful aspect of the cloud is the ease by which someone can create, modify, and destroy servers on demand. This means that you do not want to get stuck manually maintaining records of cloud servers that are constantly in flux. Inevitably, the effort to keep the CMDB up to date will fail and it becomes an unreliable record of IT asset configurations. How can you easily synchronize your CMDB with CenturyLink Cloud? Use the APIs!

Synchronizing Changes from CenturyLink Cloud to Local CMDB

CenturyLink Cloud’s Engineering team just added new API operations that make it simple to retrieve a list of all servers that have changed within a certain period of time. Customers can run a simple application every evening and invoke the GetAllServersByModifiedDate API operation to pull back a list of all CenturyLink Cloud servers that have experienced the following events:

     
  • Created or deleted
  •  
  • Paused/powered on/powered off/reset/rebooted/shut down
  •  
  • CPU count, RAM amount, storage amount changed
  •  
  • Public IP added or released
  •  
  • Snapshot created/restored/deleted
  •  
  • Archived or restored from archive
  •  
  • Custom (metadata) field added, or value changed
  •  
  • Software installed or script executed (via Blueprint)

Most of these changes are extremely relevant to a configuration database and provide critical context about the cloud server’s lifecycle. By automating these changes with the API, you can save significant administration time and effort.

CMDBs are a critical component for many enterprises, and your cloud servers should be a visible part of your IT asset management strategy. CenturyLink Cloud is constantly working to deliver a powerful API that provide the glue to connect your on-premises systems and cloud resources. Existing customers have instant access to our API today and new customers can get started by signing up for an account today!

Building Servers with the CenturyLink Cloud API

Any service provider worth its salt has to have an API. It’s one of the first questions we ask our providers and understandably one we get asked a lot as well. With our latest release we also updated our API, so I figured what better way to show off the API that with a sample of how easy it is to build a server.

First using Visual Studio 2010 we’ll install RestSharp using NuGet (if you don’t have NuGet installed stop reading and do yourself a favor and install it).

Install-Package RestSharp

Then create a rest client pointing at the Tier3 API.

private RestClient Client = new RestClient("https://api.tier3.com/rest");

Now we are ready to call the API. Once you create an API user in your account you can use it to logon and store the authentication in the client cookies.

var request = new RestRequest("/auth/logon"); request.Method = Method.POST; request.RequestFormat = DataFormat.Json; request.AddBody(new { APIKey = "b3b41e0818ad4dfdb9d43c964f680de1", Password = "plAtform6{+*" }); var response = Client.Execute(request); var content = DeserializeContent(response); if (content.StatusCode != 0) throw new ApplicationException(content.Message); if (Client.CookieContainer == null) Client.CookieContainer = new System.Net.CookieContainer(); response.Cookies .Select(c => new Cookie(c.Name, c.Value, c.Path, c.Domain)) .ToList() .ForEach(c => Client.CookieContainer.Add(c));

You’ll notice a few helpers methods I created to deal with deserializing the JSON response into a dynamic object. I’ve included that code at bottom for reference.

Let’s queue up the server for creation

var request = new RestRequest("/server/createserver"); request.Method = Method.POST; request.RequestFormat = DataFormat.Json; request.AddBody(new { Template = "WIN2008R2STD-64", Alias = "DEMO", Description = "API Demo Server", HardwareGroupID = 123, ServerType = 1, // 1-Standard, 2-Enterprise ServiceLeve = 2, // 1-Premium, 2-Standard Cpu = 2, MemoryGB = 4, ExtraDriveGB = 0, PrimaryDNS = "4.2.2.2", SecondaryDNS = "4.2.2.3", Network = "vlan123_172.1.123" }); var response = Execute(request); if (response.StatusCode != 0) throw new ApplicationException(response.Message);

CreateServer returns a RequestID for which we can use to query for the status of the server build. And since all server provisioning is done through Blueprints, we can use the GetDeploymentStatus method on the Blueprint API to check on how things are going.

var request = new RestRequest("/blueprint/getdeploymentstatus"); request.Method = Method.POST; request.RequestFormat = DataFormat.Json; request.AddBody(new { RequestID = 1149 /*content.RequestID*/ }); while (true) { var response = Execute(request); if (response.StatusCode != 0) throw new ApplicationException(response.Message); if (response.PrecentComplete == 100) break; Thread.Sleep(60000); }

And finally we Logout.

var request = new RestRequest("auth/logout"); request.RequestFormat = DataFormat.Json; var response = Execute(request); if (response.StatusCode != 0) throw new ApplicationException("Failed to Logout");

And there you have it! 4 easy steps to provision a server from code. There are a ton of other things that you can do with the full API, but I’ll leave that up to you to discover.

As promised, the helper methods

private dynamic Execute(RestRequest request) { var response = Client.Execute(request); return DeserializeContent(response); } private dynamic DeserializeContent(RestResponse response) { using (var reader = new StringReader(response.Content)) { using (var json = new JsonTextReader(reader)) { return JsonSerializer.Create(new JsonSerializerSettings()).Deserialize(json); } } }

Originally posted on Troy’s blog.