Design concept
Enterprises generally have their own internal operations and maintenance (O&M) teams who design and build their Configuration Management Database (CMDB) according to the company's specific O&M scenarios. This is because there are few open-source products that can meet their requirements, and it's difficult to achieve customization through secondary development. Therefore, they choose to develop their CMDB in-house rather than using open-source solutions.
As a result, to implement a configuration and management system for O&M resources that is as universal, flexible, and scalable as possible, the system must meet the following requirements:
- Operations and maintenance (O&M) personnel can build the stored data model and the relationships between models according to the enterprise's O&M scenarios and requirements.
- Provide rich APIs, especially for universal data and relationship retrieval, to facilitate secondary development.
- Users can easily subscribe to the data they are interested in and have rich chart displays.
- Automatic discovery of data and granular permission control.
Based on the above principles, a CMDB has been designed and implemented, and it has been open-sourced. We hope to receive positive feedback from everyone, and the system will continue to be improved continuously.
- Online Demo: https://cmdb.veops.cn
- Username: Demo or admin
- Password: 123456
- Github's open source address is:https://github.com/veops/cmdb
Overall CMDB Architecture

As shown in the diagram, the CMDB is divided into four layers from bottom to top: Storage Layer, Data Layer, API, and UI. The CIType in the diagram can be understood as data models, such as physical machines, virtual machines, applications, network cards, software, etc. CI refers to configuration items, which are instances of CIType. For example, a specific physical machine is one CI. Below is a brief introduction to these four layers. Storage Layer :is primarily used to store CIType and CI, and the relationship between them.
- Mysql: Persistent storage of all data
- Reddis: Data cache, mainly for users, properties, CIType, permissions, etc. Reduce Mysql access pressure and improve API response speed
- Elasticsearch: Primary store CI's instance data to retrieve CI.Elasticsearch: Primary store CI's instance data to retrieve CI.In fact, ESs is an optional option, and the retrieval of CI-data is done by Mysql+Redis, although if the number of CI's cases exceeds a certain order of magnitude, it is recommended to use ES, taking into account the efficiency of the query.
data layer :describes model and instance data and the relationship between them.This layer requires first shipping to complete modelling with specific application scenarios.The model includes properties, attributes with different values and some test rules, such as a sole, mandatory checktest, and avoidance of entry of dirty data at the system level.Summary, Veops CMDB actually contains mainly the following four types of data:This layer requires first shipping to complete modelling with specific application scenarios.The model includes properties, attributes with different values and some test rules, such as a sole, mandatory checktest, and avoidance of entry of dirty data at the system level.Summary, Veops CMDB actually contains mainly the following four types of data:
-
Hardware data:Physical machine, host machine, rack, network equipment, network card, hard disk, memory, etc.
-
Software data:docker, mysql, redis, tomcat, etc.
-
Business Data:Applications, Product Line, Causes, etc.
-
Relation Data :The relationships between the above three types of data.
Of course, each company has different performance scenarios and users can design data models according to their needs.
API Layer : To provide a unified and transparent calling interface for the UI, abstract and encapsulate interfaces for various data modules at the lower layers. It should be made as generic as possible, and the query APIs for CI and CI relations must be universal and flexible, taking into account the various querying needs of users. This system has implemented two corresponding APIs, which basically meet all the requirements of front-end data querying.
UI Layer : In fact, it's a web portal, where users directly access the CMDB portal. The core functionalities mainly include: model configuration, resource view, relationship view, tree view, and permission management. Below, I will elaborate on these 5 core modules.