docs: align Corp v1 boundary with owned home-lab containers
Build and publish Corp v1 Board portal / build (pull_request) Successful in 36s
Build and publish Corp v1 Board portal / build (pull_request) Successful in 36s
This commit is contained in:
@@ -1,50 +1,57 @@
|
||||
---
|
||||
id: overview
|
||||
title: "Overview"
|
||||
description: "See the real Corp v1 service architecture: people and Discord, Hermes Agent, Gitea, CI, Pages, Harbor, Argo CD, and Gondor MicroK8s."
|
||||
title: "Container Overview"
|
||||
description: "See the internal containers Lego deploys and maintains for Corp v1, from Hermes and Gitea through Pages, Harbor, Argo CD, identity, ingress, and MicroK8s."
|
||||
---
|
||||
|
||||
import Drawio from '@theme/Drawio';
|
||||
import architectureDiagram from '!!raw-loader!./diagrams/architecture-overview.drawio';
|
||||
|
||||
# Overview
|
||||
# Container Overview
|
||||
|
||||
This is the **deployed service architecture around Corp v1 today**. It is different from the [Operating Model](/architecture-high-level/operating-model/): the operating model explains how work moves; this page shows which services perform and preserve that work.
|
||||
This view treats the **Corp v1 managed home-lab platform** as the software system. A container here is an independently operated service or managed service slice for which Lego owns configuration, versioning, deployment, upgrades, access, backup or recovery, and operational verification.
|
||||
|
||||
<Drawio content={architectureDiagram} title="Corp v1 deployed service architecture" toolbar="zoom layers lightbox" responsive maxHeight={820} />
|
||||
<Drawio content={architectureDiagram} title="Corp v1 internal container architecture" toolbar="zoom layers lightbox" responsive maxHeight={860} />
|
||||
|
||||
## Services in the current setup
|
||||
## Internal containers
|
||||
|
||||
| Service | Current role in Corp v1 |
|
||||
| Container | Corp v1 responsibility |
|
||||
|---|---|
|
||||
| **Discord** | Human interaction surface: one `corp-v1-board` governance channel and seven focused sessions per project. |
|
||||
| **Hermes Agent** | The executing AI agent. It loads channel and engineering skills, uses connected tools, changes repositories, observes CI and runtime state, and reports evidence. It is not placed inside the Kubernetes cluster in this model. |
|
||||
| **Penpot** | Current UI/UX design workspace for journeys, information architecture, prototypes, accessibility review, and implementation handoff. |
|
||||
| **Gitea** | Durable source and collaboration system for the Board portal, project documentation, application source, adopted skills, branches, pull requests, decisions, and GitOps repositories. |
|
||||
| **Gitea Actions** | Self-hosted validation and publication. Exact-head runs are part of delivery evidence. |
|
||||
| **LEGO Cloud Pages** | Publishes the Board and project Docusaurus portals through the `pages` workload. The current `0500-pages` Argo CD application is `Synced / Healthy`. |
|
||||
| **Harbor** | Stores immutable application images. The current `0200-harbor` Argo CD application is `Synced / Healthy`. |
|
||||
| **Argo CD** | Reconciles GitOps desired state into Gondor v1. The current AeroSim application is `Synced / Healthy`; a project is not shown as deployed merely because a repository exists. |
|
||||
| **Gondor v1 MicroK8s** | Three-node Kubernetes runtime: Osgiliath plus two Minas Tirith workers. It currently hosts Pages and approved application workloads. |
|
||||
| **Access edge** | Cloudflare and Osgiliath Nginx route public traffic. Pages uses `pages-oauth2-proxy`, with Keycloak providing the observed sign-in boundary. |
|
||||
| **Hermes Agent** | Agent runtime, connected tools, model-provider integration, focused sessions, skill loading, execution, and evidence verification. |
|
||||
| **Corp v1 Board portal** | Docusaurus source, registries, architecture, decisions, build, publication, navigation, and deployed-content readback. |
|
||||
| **Gitea** | Service operation plus Corp organizations, teams, repositories, branches, pull requests, variables, permissions, skills, documentation, application source, and GitOps state. |
|
||||
| **Gitea Actions runners** | Runner operation, workflow versions, exact-head validation, documentation builds, image publication, and delivery evidence. |
|
||||
| **Penpot** | Service deployment and the project design workspaces, editable design sources, review state, accessibility evidence, and handoff. |
|
||||
| **LEGO Cloud Pages** | Pages workload, route structure, publication behavior, OAuth-protected access, and content readback. |
|
||||
| **Harbor** | Registry service, projects, repositories, robot integration, immutable application images, retention, and availability. |
|
||||
| **Argo CD** | Service lifecycle, AppProjects, Applications, repository access, desired-state reconciliation, health, and sync evidence. |
|
||||
| **Identity and access** | Keycloak, OAuth proxy configuration, protected routes, clients, policies, and sign-in behavior. |
|
||||
| **Ingress edge** | Cloudflare configuration, Osgiliath Nginx, ACME, Kubernetes ingress, routing, certificates, and public endpoints. |
|
||||
| **Gondor v1 MicroK8s** | Three-node runtime, namespaces, workloads, Services, Ingress, storage integration, readiness, image identity, and runtime readback. |
|
||||
| **Project workloads** | Approved application Deployments, Services, routes, configuration, release candidates, rollback state, and observable behavior. |
|
||||
|
||||
## Documentation delivery path
|
||||
## External connections
|
||||
|
||||
1. Hermes or a human contributor changes an editable source in Gitea.
|
||||
2. Gitea Actions validates the exact commit and builds Docusaurus.
|
||||
3. The Pages publication workload serves the built route.
|
||||
4. Protected readers pass through the access boundary.
|
||||
5. Hermes verifies distinctive content through the authorized Pages service path before claiming completion.
|
||||
Only two software systems cross the Corp v1 boundary:
|
||||
|
||||
## Application delivery path
|
||||
- **Discord** supplies the communication service. Corp v1 owns the managed channel configuration represented in its operating model.
|
||||
- **ICA or GPT Codex** supplies LLM inference to Hermes Agent.
|
||||
|
||||
1. Project source and GitOps desired state are reviewed in Gitea.
|
||||
2. Gitea Actions validates the exact commit and publishes an immutable image to Harbor when credentials and policy gates are satisfied.
|
||||
3. Argo CD reconciles approved desired state into the target MicroK8s namespace.
|
||||
4. Runtime pod readiness, image identity, service route, and user-visible behavior are read back.
|
||||
## Documentation path
|
||||
|
||||
Penpot evidence enters this flow through reviewed links and project documentation; it does not replace versioned requirements, ADRs, code, or release evidence.
|
||||
`Hermes → Gitea → Gitea Actions → Board portal build → LEGO Cloud Pages → identity/ingress → deployed readback`
|
||||
|
||||
## Boundaries of truth
|
||||
A documentation delivery claim requires successful exact-commit CI and distinctive content from the deployed Pages service path.
|
||||
|
||||
Discord and agent sessions coordinate work, but they are not the only durable record. Approved decisions, current architecture, source, adopted skills, and delivery evidence are persisted in Gitea-backed documentation. CI success proves validation; deployed readback proves publication or runtime behavior. The two are required together when delivery is claimed.
|
||||
## Application path
|
||||
|
||||
`Hermes → Gitea → Gitea Actions → Harbor → GitOps state → Argo CD → MicroK8s workload → ingress → runtime readback`
|
||||
|
||||
Argo CD also reads desired state from Gitea. A repository or image alone is not a deployed product; the runtime image identity, readiness, route, and user-visible behavior must be verified.
|
||||
|
||||
## Related views
|
||||
|
||||
- [Context](/architecture-high-level/context/) defines the home-lab boundary, human actors, and two external systems.
|
||||
- [Operating Model](/architecture-high-level/operating-model/) explains governance and the delivery lifecycle.
|
||||
- [Overview Skills](/architecture-high-level/overview-skills/) explains the instructions Hermes loads to operate these containers safely.
|
||||
- [Overview Repositories](/architecture-high-level/overview-repositories/) explains the versioned project and skill sources.
|
||||
|
||||
Reference in New Issue
Block a user