Introduce a way to instrument what happens within Harmony and around Harmony (e.g. in the CLI or in Composer). The goal is to provide visual feedback to the end users and inform them of the progress of their tasks (e.g. deployment) as clearly as possible. It is important to also let them know of the outcome of their tasks (what was created, where to access stuff, etc.). <img src="https://media.discordapp.net/attachments/1295353830300713062/1400289618636574741/demo.gif?ex=688c18d5&is=688ac755&hm=2c70884aacb08f7bd15cbb65a7562a174846906718aa15294bbb238e64febbce&=" /> ## Changes ### Instrumentation architecture Extensibility and ease of use is key here, while preserving type safety as much as possible. The proposed API is quite simple: ```rs // Emit an event instrumentation::instrument( HarmonyEvent::TopologyPrepared { topology: "k8s-anywhere", outcome: Outcome::success("yay") } ); // Consume events instrumentation::subscribe("Harmony CLI Logger", async |event| { match event { HarmonyEvent::TopologyPrepared { name, outcome } => todo!(), } }); ``` #### Current limitations * this API is not very extensible, but it could be easily changed to allow end users to define custom events in addition to Harmony core events * we use a tokio broadcast channel behind the scene so only in process communication can happen, but it could be easily changed to a more flexible communication mechanism as implementation details are hidden ### `harmony_composer` VS `harmony_cli` As Harmony Composer launches commands from Harmony (CLI), they both live in different processes. And because of this, we cannot easily make all the logging happens in one place (Harmony Composer) and get rid of Harmony CLI. At least not without introducing additional complexity such as communication through a server, unix socket, etc. So for the time being, it was decided to preserve both `harmony_composer` and `harmony_cli` and let them independently log their stuff and handle their own responsibilities: * `harmony_composer`: takes care only of setting up & packaging a project, delegates everything else to `harmony_cli` * `harmony_cli`: takes care of configuring & running Harmony ### Logging & prompts * [indicatif](https://github.com/console-rs/indicatif) is used to create progress bars and track progress within Harmony, Harmony CLI, and Harmony Composer * [inquire](https://github.com/mikaelmello/inquire) is preserved, but was removed from `harmony` (core) as UI concerns shouldn't go that deep * note: for now the only prompt we had was simply deleted, we'll have to find a better way to prompt stuff in the future ## Todos * [ ] Update/Create ADRs * [ ] Continue instrumentation for missing branches * [ ] Allow instrumentation to emit and subscribe to custom events Co-authored-by: Ian Letourneau <letourneau.ian@gmail.com> Reviewed-on: https://git.nationtech.io/NationTech/harmony/pulls/91 Reviewed-by: johnride <jg@nationtech.io> |
||
---|---|---|
.cargo | ||
.gitea/workflows | ||
adr | ||
data/watchguard | ||
docs | ||
examples | ||
harmony | ||
harmony_cli | ||
harmony_composer | ||
harmony_macros | ||
harmony_tui | ||
harmony_types | ||
k3d | ||
opnsense-config | ||
opnsense-config-xml | ||
private_repos/example | ||
.dockerignore | ||
.gitattributes | ||
.gitignore | ||
Cargo.lock | ||
Cargo.toml | ||
check.sh | ||
CONTRIBUTING.md | ||
Dockerfile | ||
LICENSE | ||
README.md |
Harmony : Open-source infrastructure orchestration that treats your platform like first-class code.
By NationTech
Unify
- Project Scaffolding
- Infrastructure Provisioning
- Application Deployment
- Day-2 operations
All in one strongly-typed Rust codebase.
Deploy anywhere
From a developer laptop to a global production cluster, a single source of truth drives the full software lifecycle.
1 · The Harmony Philosophy
Infrastructure is essential, but it shouldn’t be your core business. Harmony is built on three guiding principles that make modern platforms reliable, repeatable, and easy to reason about.
Principle | What it means for you |
---|---|
Infrastructure as Resilient Code | Replace sprawling YAML and bash scripts with type-safe Rust. Test, refactor, and version your platform just like application code. |
Prove It Works — Before You Deploy | Harmony uses the compiler to verify that your application’s needs match the target environment’s capabilities at compile-time, eliminating an entire class of runtime outages. |
One Unified Model | Software and infrastructure are a single system. Harmony models them together, enabling deep automation—from bare-metal servers to Kubernetes workloads—with zero context switching. |
These principles surface as simple, ergonomic Rust APIs that let teams focus on their product while trusting the platform underneath.
2 · Quick Start
The snippet below spins up a complete production-grade LAMP stack with monitoring. Swap it for your own scores to deploy anything from microservices to machine-learning pipelines.
use harmony::{
data::Version,
inventory::Inventory,
maestro::Maestro,
modules::{
lamp::{LAMPConfig, LAMPScore},
monitoring::monitoring_alerting::MonitoringAlertingStackScore,
},
topology::{K8sAnywhereTopology, Url},
};
#[tokio::main]
async fn main() {
// 1. Describe what you want
let lamp_stack = LAMPScore {
name: "harmony-lamp-demo".into(),
domain: Url::Url(url::Url::parse("https://lampdemo.example.com").unwrap()),
php_version: Version::from("8.3.0").unwrap(),
config: LAMPConfig {
project_root: "./php".into(),
database_size: "4Gi".into(),
..Default::default()
},
};
// 2. Pick where it should run
let mut maestro = Maestro::<K8sAnywhereTopology>::initialize(
Inventory::autoload(), // auto-detect hardware / kube-config
K8sAnywhereTopology::from_env(), // local k3d, CI, staging, prod…
)
.await
.unwrap();
// 3. Enhance with extra scores (monitoring, CI/CD, …)
let mut monitoring = MonitoringAlertingStackScore::new();
monitoring.namespace = Some(lamp_stack.config.namespace.clone());
maestro.register_all(vec![Box::new(lamp_stack), Box::new(monitoring)]);
// 4. Launch an interactive CLI / TUI
harmony_cli::init(maestro, None).await.unwrap();
}
Run it:
cargo run
Harmony analyses the code, shows an execution plan in a TUI, and applies it once you confirm. Same code, same binary—every environment.
3 · Core Concepts
Term | One-liner |
---|---|
Score | Declarative description of the desired state (e.g., LAMPScore ). |
Interpret | Imperative logic that realises a Score on a specific environment. |
Topology | An environment (local k3d, AWS, bare-metal) exposing verified Capabilities (Kubernetes, DNS, …). |
Maestro | Orchestrator that compiles Scores + Topology, ensuring all capabilities line up at compile-time. |
Inventory | Optional catalogue of physical assets for bare-metal and edge deployments. |
A visual overview is in the diagram below.
4 · Install
Prerequisites:
- Rust
- Docker (if you deploy locally)
kubectl
/helm
for Kubernetes-based topologies
git clone https://git.nationtech.io/nationtech/harmony
cd harmony
cargo build --release # builds the CLI, TUI and libraries
5 · Learning More
-
Architectural Decision Records – dive into the rationale
-
Extending Harmony – write new Scores / Interprets, add hardware like OPNsense firewalls, or embed Harmony in your own tooling (
/docs
). -
Community – discussions and roadmap live in GitLab issues. PRs, ideas, and feedback are welcome!
6 · License
Harmony is released under the GNU AGPL v3.
We choose a strong copyleft license to ensure the project—and every improvement to it—remains open and benefits the entire community. Fork it, enhance it, even out-innovate us; just keep it open.
See LICENSE for the full text.
Made with ❤️ & 🦀 by the NationTech and the Harmony community