Building a Flexible, Scalable CMDB for Ops: Architecture, API, and UI Insights

CMDB (Configuration Management Database) focuses on storing operational resource data, distinct from application configuration management. Enterprises typically build their own CMDB to meet specific operational scenarios, as open‑source solutions rarely satisfy all custom requirements.

To create a generic, flexible, and extensible operational resource management system, the system must satisfy:

Allow ops staff to define data models and relationships according to business needs.

Provide rich, generic APIs for data and relationship retrieval, facilitating secondary development.

Enable users to subscribe to data of interest easily.

Based on these principles, an open‑source CMDB has been designed and released for community feedback, with ongoing UI improvements.

Online Demo: http://121.42.12.46:8000 Username: demo Password: 123456 https://github.com/pycook/cmdb

Overall Architecture

CMDB is divided into four layers from bottom to top: Storage, Data, API, and UI. CIType represents a data model (e.g., physical machine, virtual machine, application, NIC, software). A CI is an instance of a CIType, such as a specific physical server.

Storage Layer : Stores CIType, CI, and their relationships.

MySQL – persistent storage for all data.

Redis – cache for users, attributes, CIType, permissions, reducing MySQL load and speeding up API responses.

Elasticsearch – optional storage for CI instances to enable efficient search; default search uses MySQL + Redis, but Elasticsearch is recommended for large datasets.

Data Layer : Describes model and instance data and their relationships. Ops staff build models per scenario, defining attributes with validation rules (e.g., uniqueness, required). The CMDB mainly handles four data categories:

Hardware data – physical machines, hosts, racks, network devices, NICs, disks, memory, etc.

Software data – Docker, MySQL, Redis, Tomcat, etc.

Business data – applications, product lines, business units, etc.

Relationship data – links among the above three types.

Each company can design its own data model to suit its operational needs.

API Layer : Provides a unified, transparent interface for the UI, abstracting lower‑level data modules. The API aims for generic, flexible CI and CI‑relation queries, supporting various user query requirements. Two main APIs cover most front‑end data retrieval needs.

UI Layer : A web portal offering core modules: model configuration, resource view, relationship view, tree view, and permission management.

Model Configuration

Large enterprises can define data models early, but most organizations need dynamic modeling as they grow. Administrators must be able to add, delete, or modify CIType, define attributes (reusing existing ones), and set validation rules. Supported attribute value types are:

Integer

Float

Date types: date, datetime, time

Text

JSON

Relationships between CITypes can also be built, e.g., Business Unit → Product Line → Application, with deployments on physical machines or Docker.

Resource View

Resource view is the CI data retrieval interface. To stay generic and flexible, the CI search API supports filtering by CI attributes with complex expressions (AND, OR, NOT, IN, RANGE, COMPARISON). The expression syntax is illustrated below.

Users can subscribe to resource views of interest (e.g., physical machines, applications). Subscribed views display data filtered by attributes and support batch edit, download, delete, lifecycle tracking, and related CI inspection.

Tree View

Tree view presents resource data in a hierarchical directory style. Users can define multi‑level views (e.g., IDC → Environment → Status) for a CIType such as physical machines, enabling role‑based statistical displays without involving CI relationships.

Relationship View

Relationship view displays CI relationships in a tree format. The CI relationship query API mirrors the CI search API but adds two parameters:

root_id

(the starting CI) and

level

(depth of traversal), allowing queries from any CI to its related nodes.

Example API documentation: https://github.com/pycook/cmdb/blob/master/docs/cmdb_query_api.md

Admins define relationship views (e.g., Business Unit → Product Line → Application) and grant role‑based access. The view can display all resources under an application, whether on physical machines or Docker.

Permission Management

The system offers role‑based access control with inheritance, allowing fine‑grained permissions per CIType and relationship view, covering create, read, update, and delete operations.