CMDB-as-Code (GitOps)

The CMDB-as-Code feature allows your development and infrastructure teams to manage Configuration Items (CIs) and Relationships directly from their Git repositories using standard YAML files.

Instead of relying on manual data entry or complex external ETL scripts, Likpi acts as a native GitOps controller. It listens for webhooks directly from your Git provider (GitHub, GitLab, Bitbucket) and automatically updates the CMDB.

How the GitOps Engine Works (Architecture)

Likpi’s CMDB-as-Code relies on a robust, asynchronous, and conflict-free pipeline. When a developer pushes a commit to a monitored branch, the following sequence occurs automatically:

  1. Security & Entitlement Check: Likpi first verifies the enterprise license entitlement. It then cryptographically validates the incoming webhook payload using an HMAC SHA-256 signature against your configured Webhook Secret to ensure the payload was not spoofed.
  2. SSRF Watchdog (Universal API Fetch): The backend asynchronously reaches out to the Git provider’s API to fetch the raw YAML file. Likpi enforces a strict Server-Side Request Forgery (SSRF) Watchdog, guaranteeing that the API URL uses HTTPS and blocking any malicious attempts to route webhooks to internal IP addresses (e.g., localhost or internal subnets).
  3. The Schema Gatekeeper: Before any data is staged, the YAML manifest is parsed and validated against Likpi’s live JSON Schema (schema.json). If the developer missed mandatory identification keys (e.g., unique_identifier) or provided an invalid Category/Type/Item/Model taxonomy combination, the Gatekeeper rejects the commit instantly, flagging a VIOLATION in the GitOps Audit Dashboard.
  4. Blast Radius & Orphan Analysis: Likpi analyzes the topological relationships within the proposed manifest in-memory. If a CI loses all its dependencies, the engine flags an “Impact Warning / Orphaned CI” alert, visible to administrators in the audit logs.
  5. Virtual Staging & Automation Engines: Compliant data is never written directly to Production. Instead, it is bulk-upserted into an isolated Virtual Staging Dataset (e.g., GIT_CORE_INFRA). If the administrator enabled Auto-Identify and Auto-Merge, the system immediately queues asynchronous background jobs to the Activity Engine, which automatically deduplicates and merges the new data into the Production dataset using Attribute-Level Precedence rules.

The Declarative Manifest (likpi.yaml)

To feed data into the CMDB, developers simply maintain a YAML file (by default named likpi.yaml) at the root of their repository. This file uses a standard, Kubernetes-style declarative format.

The Declarative State & Automated Deletions (Absence = Deletion)

Because likpi.yaml acts as a strict declarative source of truth, Likpi operates on an absolute state model. This means you do not need to write explicit “delete” commands. Absence equals deletion.

  • Deleting a Relationship: If a developer removes a dependency line (e.g., an application no longer depends on a specific database) from the relations array, Likpi calculates the diff during the webhook sync and automatically severs that relationship edge in the Staging Dataset.
  • Deleting a CI: If a CI block is completely removed from the YAML file, Likpi recognizes it is no longer part of the desired state. The system automatically flags that CI for deletion (or marks it as an “Orphan/Zombie”) within the Staging Dataset. During the next Reconciliation cycle, the CI will be retired in Production safely.

Strict Schema Compliance (schema.json)

To guarantee the integrity and quality of the CMDB data, every likpi.yaml file must strictly comply with the platform’s root schema.json. Likpi will categorically reject any manifest that fails validation.

At a minimum, every CI document must contain the following top-level root keys:

  • apiVersion: Must always be likpi/v1.
  • kind: Must be a valid, registered CMDB Class (e.g., COMPUTERSYSTEM, APPLICATION, DATABASE).
  • metadata: Must contain the name identifier.
  • spec: Must contain the class (matching the kind) and the attributes payload.

Structure of a CI

Every Configuration Item (CI) is defined following the strict rules mentioned above. Below is a compliant example:

apiVersion: likpi/v1
kind: COMPUTERSYSTEM
metadata:
  name: "srv-billing-prod-01"
spec:
  class: "COMPUTERSYSTEM"
  attributes:
    category: "Hardware"
    type: "Processing Unit"
    item: "Virtual Machine"
    model: "AWS EC2 t3.large"
    environment: "Production"
    service_owner: "finance-ops-team"
    unique_identifier: "i-0abcd1234efgh5678"
    ci_details: "Primary backend node for the billing API."

Defining Relationships

To map topological dependencies, add a relations array inside the spec block. Likpi automatically extracts the source CI context and generates the correct edges in the graph database.

apiVersion: likpi/v1
kind: APPLICATION
metadata:
  name: "app-billing-backend"
spec:
  class: "APPLICATION"
  attributes:
    category: "Software"
    type: "Application Service"
    item: "Microservice"
    model: "Spring Boot"
    unique_identifier: "app-billing-prod-eu-west-1"
  relations:
    - target: "srv-billing-prod-01"
      target_class: "COMPUTERSYSTEM"
      relation_class: "RUNS_ON"
      impact: "Yes"
    - target: "db-finance-cluster"
      target_class: "DATABASE"
      relation_class: "DEPENDS_ON"
      impact: "Yes"

Best Practices for GitOps Scale

When rolling out CMDB-as-Code across a large enterprise, follow these administrative guidelines:

  • File Sizing & Partitioning: Keep individual likpi.yaml files under 2,000 CIs to ensure ultra-fast JSON Schema validation and staging merges. If a repository manages massive infrastructure, split the configuration logically (e.g., by region or environment) and configure multiple Likpi integrations mapped to specific file paths.
  • Automation via IaC: While developers can write these YAML files manually, the most mature strategy is to have your Infrastructure-as-Code tools (Terraform, Ansible, Crossplane) automatically generate the likpi.yaml artifact during their pipeline execution.
  • Trunk-Based Development & Branch Targeting: Likpi integrations should be configured to listen strictly to your primary production branches (e.g., main or master) to reflect true production state. Commits pushed to feature branches are safely ignored.
  • Shift-Left Validation: Strongly encourage development teams to implement pre-merge validation pipelines (like GitHub Actions or GitLab CI) that fetch Likpi’s live /api/v1/schema/json-schema endpoint to validate their YAML before merging pull requests. This prevents the Likpi Gatekeeper from rejecting their webhooks post-merge due to schema non-compliance.