Bundles, Binary Wrappers and Infrastructure
Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.
The Lab should describe and operate existing tools through reusable C# integration layers. Its own responsibility is instance and lifecycle coordination; each integration supplies the relevant external-tool knowledge.
This chapter identifies the layers and the evidence available for them. A related article is a design source, not proof that its named package has been built and released.
Three integration responsibilities
| Layer | Responsibility | Example |
|---|---|---|
| Bundle | Model and produce a tool's configuration or service contribution | GitLab settings, Compose services, routing configuration |
| Binary wrapper | Invoke a specific executable through typed arguments and results | Git, glab, dotnet, Hugo, Docker, Podman or kubectl |
| Lab adapter | Translate a Diem operation into provider capabilities and observable lifecycle steps | Prepare workspace, build release, apply deployment, verify route |
A Bundle may describe a service without starting it. A wrapper may execute a command without deciding whether it belongs in a deployment plan. The Lab connects those actions to the selected instance and policy.
Wrappers must preserve complete argument tokens, cancellation, exit status and diagnostics. Credentials are supplied through the appropriate input mechanism and redacted from displayed commands. Tool-version compatibility is part of their contract.
Component inventory and evidence boundary
| Component or design | Related source | Treatment in this proposal |
|---|---|---|
GitLab.Bundle |
Typed Docker's shared framework | Intended reusable integration; verify package/code version before adoption |
| GitLab configuration contributors | GitLab configuration series | Background for typed configuration and service composition |
DockerCompose.Bundle and binary wrappers |
Typed Docker | Related design and implementation claims requiring package-level verification |
Traefik.Bundle |
Traefik series | Routing integration source |
| GitLab CI modeling | GitLab CI YAML | Candidate reusable pipeline integration |
| HomeLab plugin contracts | Plugin system | Related design; not proof of a released FrenchExDev.Net.Lab |
| Original Diem | Pinned source (ouvre dans une nouvelle fenêtre) | Historical source evidence |
The first implementation inventory should add repository/package identity, version, available tests, supported platforms and compatibility gaps. This document does not claim that every required wrapper already exists. Missing integrations should follow the established Bundle and binary-wrapper patterns.
Docker and Podman are engine choices
A local container adapter advertises the engine operations it supports. Docker and Podman implementations may differ in sockets, permissions, volume behavior or composition tooling. Capabilities must be checked against the actual provider.
Compose is a deployment description and execution route. Kubernetes is another deployment target. They are not interchangeable switches at the same level as the local engine.
A Kubernetes adapter operates through configured cluster APIs and tools; it does not assume that selecting Docker for local builds determines the cluster's runtime. A Compose adapter identifies the compatible executable/provider it will use.
Plan, apply and observe
The Lab requests a deployment plan for an instance. Contributors provide required services, configuration artifacts and dependencies. Adapters validate capabilities, perform operations and return observed identifiers and readiness results.
The desired hostname and actual route state remain separate. DNS resolution alone is not application readiness. A target can resolve correctly while its application is still building or unhealthy.
Provider actions should be retryable with identifiable outcomes. Repeating a provisioning event should reconcile the intended managed resource rather than create another unrelated service.
The Lab specification defines the lifecycle. Self-description applies the same integration layers to the Lab's own services.
Previous: Bounded Contexts, Shared Kernels and ACLs · Next: Rendering, Generation and Live Development · Series index · Section index