Ruby for SOLIDserver DDI

Automation is important in modern infrastructures and application deployment requires specific infrastructure services to be running properly. Having a central repository of information that can be easily used by any external automation system and with any programming language is a must have for all system and networking teams. We have covered how to use Python with the SOLIDserver in a previous blog, here we start using the Ruby language for DDI, with the help of OpenAPI initiative.

Why use Ruby?

The first motivations of the Ruby language were productivity, joy of programming and happiness, it has been created as primarily focusing on the developer and not the computer that will run it. Even if nowadays Ruby is losing traction from a developer standpoint (16th most popular just after Matlab and Perl), it continues to be used as an engine for products that may require to be interconnected with a DDI solution for automation purposes. Ruby is also used for network and system administration in addition to the web site part which is predominant with the Ruby on Rails framework. For example it is possible to extend the feature set of the Chef automation solution with additional code in Ruby – Chef is in the category of configuration management solutions alongside Puppet and Ansible.

Benefit from SOLIDserver API

On the SOLIDserver DDI, all actions that can be performed are available through the API library. Therefore it is accessible via any external automation or orchestration solution, including those developed using the Ruby language. Even if REST APIs are relatively simple to implement by a developer, this can be cumbersome and it is always easier to use an already packaged library. SOLIDserver release 7.2 proposes a new set of APIs with a new specific endpoint and compliant with OpenAPI specifications. With the definition of the API set in the OpenAPI format it is possible to generate a client source package with tools like Swagger generator. Such a package will be easier to use for a developer since it includes all the structure definitions that can be manipulated and all the API calls are converted into functions or classes. Furthermore, it is possible to generate a client package for multiple development languages, all major flavors are already available in most generators.

Hands-on: Ruby and SOLIDserver DDI

Using Ruby language with SOLIDserver can leverage such an approach with the generated library. For the following examples, we used the Swagger openapi-generator to build the client part and since the community has well designed the tool, it also generates the documentation for all the calls with an example which is really simple as a starting point. We won’t cover all the APIs here, but just a simple use case that is mandatory for most automation projects including an IPAM: how to get a free IP address to instantiate a new VM.

Talk with the SOLIDserver

The easiest way to start with Ruby and SOLIDserver is to include the API module just generated, we add here also the ipaddress module to be able to manipulate some addresses for the following use cases:

require 'efficientip-sds'
require 'ipaddress'	# gem install ipaddress

Then, we can instantiate a connection to the SOLIDserver using the appropriate credentials:

SDS.configure do |config|
  config.host = 'sds-pprod.internal'

  # Configure HTTP basic authorization: BasicAuth
  config.username = 'apirw'
  config.password = 'apirw-pwd'

  # no ssl certificate validation - for demo only
  config.verify_ssl = false
end

And finally instantiate an API module, here for example the one to manipulate the IPAM:

$api_ipam = SDS::IpamApi.new

It really is easy.

Find a suitable free IP address in a network

Adding functions for a specific usage becomes very straightforward, for example this one is able to propose a free IP address in a subnet for future use, such as applying it to a new server instantiated by an orchestrator. The template used is extracted directly from the generated documentation for Ruby. Here we introduce a list command with a “where” clause to limit the amount of objects that will be returned. The limitation is applied to the space and the subnet in which we would like an IP address, but also only to the free IP addresses that are neither at the start nor at the end of the network space.

The listing function can return more than one free IP address, in this case we randomly choose one in the returned range. This approach allows a better spread of the used address and creates a little bit of entropy in our subnet. This also allows concurrent calls to this function that are not idempotent with some probability that the return value will be different, in case we would like to reserve the proposed address in a forthcoming step.

def get_free_ip_in_subnet(space, subnet)
  opts = {
	where: "space_name='%s'" % [space] +
       	" and network_name='%s'" % [subnet] +
       	" and address_type='free'" +
       	" and free_start_address_addr!=network_start_address_addr" +
       	" and free_start_address_addr!=network_end_address_addr",
	limit: 1
  }

  # List the IPv4 free addresses
  result = $api_ipam.ipam_address_list(opts)
  result.data.each do |ip|
	puts "free address: %s" % [ip.address_hostaddr]
	puts " scope size: %s" % [ip.free_scope_size]
	puts " between %s - %s" % [ip.free_start_address_addr, ip.free_end_address_addr]

	firsthostip = IPAddress::IPv4.new ip.address_hostaddr
	newhostip = IPAddress.parse(rand(ip.free_scope_size.to_i) + firsthostip.to_u32)
	puts " proposed ip: %s" % [newhostip.address]
	return newhostip.address
  end

rescue SDS::ApiError => e
  puts "Exception in get_free_ip_in_subnet when calling IpamApi->ipam_address_list: #{e}"
end

Reserve a free IP address for immediate use

The last example consists of searching for a free IP address and reserving it in the IPAM for immediate use. This use case is very useful in automated infrastructures where the IP address is provided in complement to a blueprint for a VM. It can also be used behind a higher level API service proposed by IT to internal clients, through an ITSM system for example. Here it shows how the Ruby generator has created an intermediate definition for the IP address (ipam_ip_address) as defined in the OpenAPI description of the API.

def reserve_free_ip_in_subnet(space, subnet, name)
  freeip = get_free_ip_in_subnet(space, subnet)

   opts = {
 	ipam_ip_address: SDS::IpamIpAddress.new(address_hostaddr: freeip,
                                          	address_name: name,
                                          	space_name: space)
   }

  #add ip address
  result = $api_ipam.ipam_address_add(opts)
  if result.success
	return result.data[0]
  end
rescue SDS::ApiError => e
  puts "Exception when calling IpamApi->ipam_address_add: #{e}"
end

To use it:

ipnew = reserve_free_ip_in_subnet('Local', 'subnet-test', 'new-ip-12')

DDI central repository and automation for architecture deployment and management

Using an open API and standard tooling helps all developers to perform simple actions on a DDI solution, which can therefore act as a central repository and central point of reference for any IP related information. With SOLIDserver, this model can be extended to VLans, applications and to devices with their respective management modules.

Automation is becoming more and more vital for all I&O teams in all industries. Not only for startups, who need this way of managing their infrastructure, nor just for cloud-oriented hosting requiring automation, it should be a standard pattern for any deployment and application architecture. And even if the Ruby language is less used than 15 years ago, the philosophy with automation remains and is possible with many other languages, old or new.

Development of automated provisioning systems is dependent on how the manual processes are running in each organization. Having an easy way to add a new system through its APIs is mandatory, and since DDI systems are at the center of the IP information it’s important to include these early in the automation process. SOLIDserver is open to the IT world, it has been designed like that from the very beginning with a service-centric approach, internal event flows and APIs.