In my last post, I had expressed my gratitude for being part of CoverMyMeds, where we are building an infrastructure that is centered on repeatability and efficiency. My part in that involves researching and implementing an IPAM solution that doesn’t suck. Previously, I covered some of the IPAM challenges. My next task is to go in search of a tool that will address those challenges.
The requirements were made clear after I had trotted out my best flat file solution, which was not ridiculed, but not warmly received. The flat file solution would have worked well for our Puppet configuration needs, but would have required a fair amount of scripting to implement properly. During that meeting, a process took place that makes me happy to be a part of the team at CoverMyMeds, a technically driven discussion of our needs without politics or rancor. The main requirements were broken down into the following list, loosely prioritized from top to bottom:
- Never assign an IP twice – the biggest downfall of spreadsheets
- A working API – to enable the following two requirements
- Integration with our Puppet configuration
- Export data to BIND DNS servers
- A usable GUI
- AD LDAP authentication
- Verify IP as being alive
- Harvest unused IP addresses
- Export IP lists to spreadsheets
Looking at these requirements, we might understandably think of DHCP as the service to provide our IPAM. DHCP was considered early on, but there were a couple of concerns that removed DHCP from our list of potential solutions. First it was pointed out that if ever our DHCP server was unavailable and a system restarted, there was a chance the system could come up with the wrong IP address. Another concern was that the system should cover all assigned IP addresses and be usable by everyone, even those not necessarily comfortable working on the command line.
Two of the more promising proprietary products I researched were Infoblox and SolarWinds. Both of these products are very feature complete, maybe too complete in my view. It’s not possible to just take the IPAM, for example, and plug that into our environment. This type of product usually requires you to use the whole suite of applications. I didn’t really test either of these products for the reason I just indicated. It was enough to read up on the products to see if I could work them into our infrastructure without major work flow disruptions or large rewrites.
I next turned my attention to open source options. Open source solutions are the preferred option for CoverMyMeds because ninety percent of our production software is open source. As a company, we place high value on using open source and contributing back to the community as much as we can. There are many IPAM packages available in the open source ecosystem. Making sure we selected something that met our needs and was in active development were the main requirements.
The first application that I thought would be a good fit was OpenNetAdmin. One of the most attractive features of this particular application was the purported availability of plugins to extend its functionality. This page listed numerous plugins that could be used to enable different functionality for OpenNetAdmin. I felt the GUI might have been a bit difficult to work with, but thought the plugins would make up for shortcomings in the GUI.
I installed OpenNetAdmin on a Vagrant virtual server and began exploring how it might fit into our existing puppet environment. I did find that there was a steep learning curve for the GUI, it was not what I would consider intuitive. The Puppet plugins I was most interested in would not fit very well in our current configuration. My biggest problem with OpenNetAdmin though, was not finding a good way to request an IP address on the command line or make that request using an API. There is a command line interface, but it requires a separate Perl module, dcm.pl, to operate. That meant any system or user wishing to interact with our IPAM outside the GUI would need to install and configure this Perl module. While I may have been able to find a way around this requirement, the requirement along with a challenging GUI took OpenNetAdmin out of the running.
phpIPAM was not my first choice, but was suggested by a couple of team members, so I decided that I should test it. This application is under current active development, has an API, AD authentication, automatic status checks, and a module to request IP addresses. What it didn’t have was a clear path to integration with Puppet, but I imagined the API would make integration with Puppet possible.
As with OpenNetAdmin, I started by setting up a Vagrant instance and installing phpIPAM. The install was simple and I was presented with a polished, easy to navigate GUI. The GUI has sections, which contain subnets and VLANs; this made it easy to categorize our subnets by location. Subnets are defined using CIDR and once created can be scanned for existing hosts and added to existing vlans. phpIPAM provides an API that allows querying the application for data. There are only example scripts provided for the API, but I was at least able to verify that there was working code to build on. There are options to both import and export IPAM data using spreadsheets; a nice time saver. Authentication can be done locally or using LDAP, which was easy to configure. After working with phpIPAM for several hours I was convinced that this was the application that offered the best feature set for our environment. With a couple hours of hacking, I was able to use the API to request the first available IP address in a given subnet.
I put on a short demonstration of phpIPAM for the rest of our team and suggested phpIPAM as our IPAM solution. Since introducing phpIPAM into our workflow, several colleagues have remarked about how happy they are to stop using spreadsheets for IPAM. Join me next time when I’ll describe how I used phpIPAM together with mkvm to automate server provisioning.