Designing an Effective CMDB: Insights from a 2017 GDevOps Talk

What is a CMDB

A Configuration Management Database (CMDB) is an asset repository used by operations teams to store server inventories, hardware specifications, and configuration changes. It serves as the data backbone for monitoring, automation, and cost‑management systems.

Typical CMDB Implementations

File‑based asset list (e.g., a plain‑text inventory used by Nagios scripts to generate monitoring configurations).

Ansible’s built‑in CMDB module, which derives host information from the hosts inventory file and enriches it with hardware and OS details.

Ad‑hoc spreadsheets (Excel) that manually record server attributes.

These approaches often exist in isolation, resulting in multiple parallel CMDBs that must be updated separately, increasing maintenance overhead and risk of inconsistency.

Design Considerations

Before building a CMDB, answer two questions:

What information should be stored and how should it be classified?

What value does that data provide to downstream systems (monitoring, automation, budgeting)?

Information can be divided into:

Fixed information : hardware specs, rack location, network topology. This data can be populated automatically but may require naming conventions (e.g., room‑rack‑switch) for items that scripts cannot discover.

Variable information : contact persons, resource status (online/offline), environment tags (prod, test), project ownership. These fields are essential for monitoring alerts and automated provisioning.

Data accuracy must be ensured by:

Continuous synchronization between online sources (CMDB) and offline inventories (asset scans, manual audits).

Minimizing manual edits through automation and API‑driven updates.

Integration with Automation Tools

After a resource is provisioned, a post‑install script calls the CMDB API to register the new IP and basic attributes. Automation platforms (e.g., SaltStack) then pull project‑level metadata from the CMDB and store it in grains, enabling deployment playbooks to make context‑aware decisions.

Conversely, automation can push newly discovered fixed attributes (e.g., actual CPU count) back to the CMDB via the same API, keeping the asset record up‑to‑date.

To avoid fragmented CMDBs, key data can be synchronized into a distributed configuration service such as ZooKeeper or etcd. Other systems read from this single source, achieving “one change, all systems updated”.

Future Extensions

Beyond server assets, a centralized directory (e.g., OpenLDAP) can store user accounts, email addresses, code‑repository credentials, and server logins. Consolidating identity data enables one‑point updates when personnel change. Because this introduces security risks, multi‑factor authentication (MFA) should be added to protect credential access.

Value Delivered by a CMDB

Cost reduction : Fixed attributes (CPU, memory) allow monthly hardware cost estimation and budgeting. Automated price‑lookup scripts can augment this with market rates.

Efficiency improvement : A single source of truth eliminates redundant updates, reduces manual errors, and improves system stability.

Support for NOOPS : By linking resource request, approval, automated provisioning, and monitoring, the CMDB enables a self‑service, low‑ops workflow where developers can obtain resources via a ticketing system, trigger automated deployment, and verify outcomes through monitoring dashboards.