Code Map

CCM is a declarative configuration management engine written in Go. A manifest or a command names resources and the desired state for each; the engine drives every resource to that state and reports what changed. This code map is a deep-dive into how the Go code is built, for contributors and for anyone who wants to understand the machine behind the manifests.

The mental model

CCM has one core and many faces. The core is a small loop: a Manager holds the run’s facts, data, and session; a Resource decides whether the system already matches the desired state; a Provider makes the platform-specific change when it does not. Every entry point drives that same loop. The CLI applies one resource. The apply engine walks a manifest of many. The background agent applies manifests on a timer. A piped wire API applies a resource sent as JSON. The logic underneath is identical, so behavior does not drift between how a resource is invoked.

Providers are selected at run time. A resource type declares a capability interface, and each provider registers a factory that reports whether it can manage the resource on this host. The registry picks the best match from the gathered facts, so the same manifest runs apt on Debian and dnf on RHEL with no change to the resource.

Explore

• Architecture

  Package layering and the three seams that keep the engine composable: the model contracts, the provider registry, and the manager.

• The Resource-Provider Model

  How a concrete resource type is built, and how one resource is driven to its desired state: decide, act, and verify.

• The Apply Engine

  How a manifest of many resources is parsed, resolved against data, and executed in order, with require as a gate and events as the shared state.

• The Agent

  The background loop that applies manifests on a timer, watches remote sources, refreshes facts and data, and remediates failing health checks.

• Data, Facts, and Templates

  How facts are gathered, how Hiera layers a hierarchy into resolved data, and how templates render that data into resource fields.

• Registration and Discovery

  How stable resources announce themselves into a JetStream store keyed by subject, and how other nodes look them up or watch them live.

• Observability

  How each apply becomes a recorded event, a Prometheus counter, and a session summary, and how health checks feed remediation.

• Reference and Map

  The CLI command surface, a source map of every package, the key types and where they are explained, and a glossary. {class=“children children-type-tree children-sort-”}