Skip to content

Wetopi Platform Bootstrap Plan

Plan de arranque de la nueva plataforma RKE2 y organización GitHub

Fecha: 28 de agosto de 2026
Estado: Plan de bootstrap consolidado
Organización GitHub: wetopi-platform
Ámbito: Creación de repositorios, bootstrap de infraestructura, RKE2, servicios base y posterior incorporación de agentes y workloads.

Índice

  1. Resumen ejecutivo
  2. Objetivo del bootstrap
  3. Decisiones ya tomadas
  4. Organización GitHub
  5. Repositorios iniciales
  6. Git como source of truth
  7. OpenTofu vs Terraform
  8. Modelo de infraestructura inicial
  9. VM externa de operaciones: wetopi-ops01
  10. Control plane RKE2
  11. Platform workers
  12. Distribución sobre Proxmox
  13. Networking de las VMs
  14. Red Ceph existente
  15. RKE2 y etcd
  16. Bootstrap desde fuera del cluster
  17. Rol inicial de Codex
  18. Cuándo desplegar Hermes
  19. Orden de despliegue de servicios base
  20. Cilium y Hubble
  21. Ceph CSI
  22. GitOps
  23. OpenBao
  24. Documentation Plane
  25. Memory Plane
  26. Work Coordination Plane
  27. AI Hub
  28. Agentes Hermes y ADK
  29. Edge nodes
  30. Hosting workers
  31. Migración progresiva desde Swarm
  32. Permisos y credenciales
  33. Primeros encargos para Codex
  34. Fases del bootstrap
  35. Checklist de arranque
  36. Resultado esperado

1. Resumen ejecutivo

La nueva plataforma de Wetopi se construirá desde cero, en paralelo a la infraestructura actual basada en Docker Swarm.

No se realizará una migración in-place.

La nueva base será:

Proxmox
  ↓
VMs Ubuntu
  ↓
RKE2
  ↓
Cilium / Hubble
  ↓
Ceph CSI
  ↓
GitOps
  ↓
OpenBao
  ↓
Docs / Memory / Work Ledger
  ↓
Hermes + ADK
  ↓
Edge
  ↓
Hosting workloads

El bootstrap inicial se hará desde fuera de Kubernetes.

Durante esta primera etapa:

  • Codex trabajará desde el laptop del operador;
  • GitHub será el source of truth;
  • existirá una VM externa wetopi-ops01;
  • se crearán 3 control planes RKE2;
  • se crearán 3 platform workers;
  • no se desplegarán aún workloads de customers;
  • no se tocará la red Ceph existente 192.168.96.0/20;
  • cada VM tendrá una única interfaz LAN;
  • Hermes se desplegará después, ya dentro del cluster definitivo.

La organización GitHub será:

wetopi-platform

y los repositorios iniciales serán:

wetopi-platform/infrastructure
wetopi-platform/agent-services
wetopi-platform/ai-hub
wetopi-platform/agents
wetopi-platform/docs

2. Objetivo del bootstrap

El objetivo de esta fase no es migrar inmediatamente los ~700 contenedores actuales.

El objetivo es construir una foundation nueva, reproducible y segura sobre la que posteriormente se pueda migrar Wetopi.

El milestone inicial será:

disponer de un cluster RKE2 HA vacío, estable, observable, con storage, secrets, GitOps y servicios agénticos comunes funcionando antes de mover tráfico de clientes.

3. Decisiones ya tomadas

Plataforma Kubernetes

RKE2

CNI

Cilium

Observabilidad de red

Hubble

Storage

Ceph existente mediante CSI

Secrets

OpenBao

Documentación

Markdown + Git + MkDocs Material

Infraestructura declarativa

OpenTofu + Ansible

Bootstrap

Codex desde laptop + wetopi-ops01

Agentes

Hermes + ADK

Los agentes se desplegarán posteriormente dentro del cluster definitivo.

4. Organización GitHub

Se adopta como organización:

github.com/wetopi-platform

Se descartan nombres temporales como wetopi3, wetopi-v3 o wetopi-new porque describen una migración, no una plataforma duradera.

wetopi-platform se considera adecuado como namespace técnico de largo plazo.

5. Repositorios iniciales

Se crearán inicialmente cinco repositorios.

5.1 infrastructure

Responsabilidad:

  • Proxmox;
  • OpenTofu;
  • Ansible;
  • RKE2;
  • networking base;
  • Cilium;
  • Hubble;
  • Ceph CSI;
  • OpenBao deployment;
  • GitOps;
  • observabilidad base;
  • edge;
  • NATGW;
  • bootstrap;
  • disaster recovery.

Estructura propuesta:

infrastructure/
├── tofu/
│   └── proxmox/
│       ├── modules/
│       └── environments/
│           └── prod/
├── ansible/
│   ├── inventories/
│   ├── roles/
│   │   ├── common/
│   │   ├── rke2-server/
│   │   ├── rke2-agent/
│   │   ├── edge/
│   │   └── natgw/
│   └── playbooks/
├── kubernetes/
│   ├── bootstrap/
│   ├── cilium/
│   ├── hubble/
│   ├── ceph-csi/
│   ├── openbao/
│   ├── gitops/
│   ├── namespaces/
│   └── observability/
├── scripts/
└── docs/
    ├── bootstrap.md
    ├── networking.md
    └── disaster-recovery.md

5.2 agent-services

Servicios compartidos de la capa agéntica:

memory-service/
work-ledger-adapter/
hermes-memory-provider/
identity/
approval/

Inicialmente se priorizarán memory-service, hermes-memory-provider y work-ledger-adapter.

5.3 ai-hub

Repositorio común de:

  • skills;
  • tools;
  • components;
  • contracts;
  • schemas;
  • SDKs;
  • evals;
  • tests.

Regla:

una tool utilizada por más de un agente debe vivir en ai-hub.

5.4 agents

Monorepo inicial de la flota:

agents/
├── hermes/
│   ├── sre/
│   ├── developer/
│   └── marketing/
├── adk/
│   ├── platform/
│   ├── wordpress/
│   └── support/
├── base/
├── deployments/
└── tests/

5.5 docs

Source of truth documental:

docs/
├── mkdocs.yml
└── docs/
    ├── architecture/
    ├── infrastructure/
    ├── kubernetes/
    ├── networking/
    ├── wordpress/
    ├── agents/
    ├── procedures/
    ├── runbooks/
    ├── security/
    └── adr/

6. Git como source of truth

Desde el primer día:

Git
  ↓
review
  ↓
automation
  ↓
infrastructure

La shell history no será source of truth.

Todo cambio relevante debe terminar en Git.

7. OpenTofu vs Terraform

Se selecciona inicialmente OpenTofu por:

  • licencia open source;
  • gobernanza Linux Foundation;
  • evitar dependencia BSL;
  • compatibilidad con el ecosistema Terraform;
  • idoneidad para un proyecto interno de largo plazo.

Terraform seguiría siendo técnicamente válido.

8. Modelo de infraestructura inicial

Se crearán inicialmente:

1 x ops VM
3 x RKE2 control plane
3 x platform workers

Total:

7 VMs

No se crearán todavía hosting workers masivos ni edge productivos.

9. VM externa de operaciones: wetopi-ops01

Se creará wetopi-ops01 fuera del cluster Kubernetes.

Objetivo:

bootstrap host, bastion administrativo y punto de recuperación cuando Kubernetes no esté disponible.

Sizing orientativo:

4 vCPU
8 GB RAM
40-80 GB disk
Ubuntu 24.04
1 NIC LAN

Herramientas:

git
ssh
ansible
opentofu
kubectl
helm
jq
yq
rke2 tooling

No alojará workloads productivos.

Debe permitir operar si fallan Cilium, GitOps, OpenBao o parte del cluster.

10. Control plane RKE2

Se desplegarán:

rke-cp01
rke-cp02
rke-cp03

Cada uno en un host Proxmox físico diferente siempre que sea posible.

Sizing orientativo:

8 vCPU
16 GB RAM
50-100 GB disk
Ubuntu 24.04
1 NIC LAN

11. Platform workers

Se desplegarán:

rke-platform01
rke-platform02
rke-platform03

Sizing orientativo:

8-16 vCPU
16-32 GB RAM
Ubuntu 24.04
1 NIC LAN

Label:

wetopi.io/role=platform

12. Distribución sobre Proxmox

Ejemplo:

pve01 -> rke-cp01 + rke-platform01
pve02 -> rke-cp02 + rke-platform02
pve03 -> rke-cp03 + rke-platform03

La distribución real debe respetar failure domains y recursos disponibles.

13. Networking de las VMs

Cada VM tendrá una única interfaz LAN.

VM
 └── eth0
      └── Wetopi LAN / vRack

Los rangos Kubernetes serán independientes:

VM LAN != Pod CIDR != Service CIDR != Ceph network

Los rangos concretos deben definirse tras inventariar las redes actuales.

14. Red Ceph existente

Existe una red Ceph:

192.168.96.0/20

que forma parte de la infraestructura hiperconvergida Proxmox + Ceph.

Decisión:

NO tocar, renumerar ni rediseñar esta red durante el bootstrap RKE2.

RKE2 consumirá Ceph mediante CSI adaptándose a la infraestructura existente.

15. RKE2 y etcd

Se utilizará embedded etcd sobre los tres server nodes.

cp01 etcd
cp02 etcd
cp03 etcd

Quorum: 2 de 3.

Se priorizará almacenamiento de baja latencia para etcd. Debe evaluarse local NVMe si la alternativa Ceph introduce latencia innecesaria.

Los snapshots de etcd deberán almacenarse fuera de los propios nodos y el procedimiento de restore deberá probarse.

16. Bootstrap desde fuera del cluster

Modelo:

Laptop
  │
Codex
  │
GitHub
  │
ops01
  │
OpenTofu + Ansible
  │
Proxmox / RKE2

Kubernetes no dependerá de agentes internos para poder crearse o repararse.

17. Rol inicial de Codex

Durante el bootstrap Codex actúa como bootstrap engineer.

Trabajará contra:

  • GitHub;
  • repos;
  • ops01;
  • Proxmox con credenciales limitadas;
  • posteriormente Kubernetes.

Todo cambio relevante debe quedar versionado.

18. Cuándo desplegar Hermes

No se desplegarán varios Hermes temporales antes del cluster.

Los Hermes definitivos se desplegarán dentro de RKE2 cuando existan al menos:

RKE2 estable
Cilium
Hubble
Ceph CSI
GitOps
OpenBao
Documentation
Memory Plane
Work Ledger

Después:

Hermes SRE
Hermes Developer
Hermes Marketing

19. Orden de despliegue de servicios base

RKE2
 ↓
Cilium
 ↓
Hubble
 ↓
Ceph CSI
 ↓
GitOps
 ↓
OpenBao
 ↓
Documentation
 ↓
Memory Plane
 ↓
Work Ledger
 ↓
AI Hub integration
 ↓
Hermes
 ↓
ADK Fleet

20. Cilium y Hubble

Cilium será el CNI base.

Inicialmente:

  • networking;
  • NetworkPolicy;
  • Hubble;
  • observabilidad.

No se activarán desde el día uno BGP WAN, egress complejo o service mesh.

21. Ceph CSI

Pruebas mínimas antes de customer workloads:

crear PVC
montar PVC
borrar Pod
recrear Pod
validar persistencia
snapshot si aplica

22. GitOps

El cluster evolucionará hacia:

Git -> reconciler -> Kubernetes

La herramienta concreta puede decidirse durante el bootstrap.

23. OpenBao

OpenBao será el secrets manager central.

Configurar:

  • HA;
  • persistence;
  • Kubernetes Auth;
  • audit;
  • policies;
  • backups.

24. Documentation Plane

Repo:

wetopi-platform/docs

Render:

MkDocs Material

Markdown será el source of truth.

25. Memory Plane

La memoria institucional propia de Wetopi se productivizará como servicio central para Hermes, ADK y futuros agentes.

Debe soportar:

  • factual memory;
  • scopes;
  • provenance;
  • confidence;
  • temporalidad;
  • contradictions;
  • candidate facts.

26. Work Coordination Plane

Se desplegará un backend Kanban/ticketing desacoplado mediante contrato Wetopi.

Responsabilidades:

  • tareas;
  • ownership;
  • resource scopes;
  • leases;
  • intent;
  • journal;
  • coordinación entre humanos y agentes.

27. AI Hub

Repo:

wetopi-platform/ai-hub

Para tools, skills, contracts, components, SDKs, schemas y evals.

28. Agentes Hermes y ADK

Una vez montada la base, Hermes y ADK participarán en:

  • inventario;
  • migración;
  • testing;
  • observabilidad;
  • documentación;
  • automatización;
  • desarrollo;
  • operación.

29. Edge nodes

No forman parte del bootstrap inicial.

Después se añadirán:

rke-edge01
rke-edge02
rke-edge03
...

integrados con IPVS, VRRP, DSR y Gateway API.

30. Hosting workers

Después del edge se crearán pocos workers de hosting:

rke-host01
rke-host02
rke-host03

Primero se migrarán aproximadamente 10 sites y se validará la plataforma antes de escalar.

31. Migración progresiva desde Swarm

Swarm seguirá produciendo durante el bootstrap.

No habrá big-bang.

La capacidad se trasladará progresivamente hasta retirar Swarm.

32. Permisos y credenciales

Codex puede tener permisos amplios de GitHub sobre la organización, pero:

GitHub permissions != production credentials

No entregar inicialmente:

  • OVH master credentials;
  • Proxmox root;
  • Ceph admin global;
  • OpenBao root permanente.

Crear una identidad específica de automatización para Proxmox con mínimos permisos necesarios.

33. Primeros encargos para Codex

Encargo 1 — Repos

Preparar los cinco repos con README, branch protection, CODEOWNERS y CI mínima.

Encargo 2 — Inventario Proxmox

Inventariar:

  • nodos;
  • CPU;
  • RAM;
  • storage;
  • bridges;
  • VLANs;
  • redes;
  • failure domains.

No inventar direccionamiento.

Encargo 3 — Ubuntu template

Crear template Ubuntu 24.04 reproducible con cloud-init.

Encargo 4 — ops01

Crear wetopi-ops01 mediante OpenTofu y provisionarla con Ansible.

Encargo 5 — Control plane

Crear rke-cp01, rke-cp02, rke-cp03.

Encargo 6 — Platform workers

Crear rke-platform01, rke-platform02, rke-platform03.

Encargo 7 — RKE2 HA

Instalar RKE2 con embedded etcd y endpoint API estable.

Encargo 8 — Failure testing

Validar:

reboot cp
loss of one cp
worker reboot
drain
uncordon
etcd snapshot
restore procedure

antes de seguir.

34. Fases del bootstrap

Fase 0 — GitHub

Crear organización y repos.

Fase 1 — Inventario

Proxmox + networking + storage.

Fase 2 — IaC

OpenTofu + Ansible.

Fase 3 — Ops host

wetopi-ops01.

Fase 4 — RKE2 HA

3 control planes + 3 platform workers.

Fase 5 — Networking

Cilium + Hubble.

Fase 6 — Storage

Ceph CSI.

Fase 7 — GitOps

Reconciliación desde Git.

Fase 8 — Secrets

OpenBao.

Fase 9 — Docs / Memory / Work Ledger

Servicios agénticos compartidos.

Fase 10 — Hermes + ADK

Despliegue definitivo.

Fase 11 — Edge

Primer tráfico HTTP en RKE2.

Fase 12 — Hosting

Primeros WordPress.

Fase 13 — Migración masiva

Swarm -> RKE2.

35. Checklist de arranque

GitHub

  • [ ] organización wetopi-platform
  • [ ] repo infrastructure
  • [ ] repo agent-services
  • [ ] repo ai-hub
  • [ ] repo agents
  • [ ] repo docs
  • [ ] Codex autorizado
  • [ ] branch protection
  • [ ] CODEOWNERS

Proxmox

  • [ ] inventario
  • [ ] bridges
  • [ ] IP ranges
  • [ ] failure domains
  • [ ] Ubuntu template
  • [ ] automation account

Bootstrap

  • [ ] wetopi-ops01
  • [ ] rke-cp01
  • [ ] rke-cp02
  • [ ] rke-cp03
  • [ ] rke-platform01
  • [ ] rke-platform02
  • [ ] rke-platform03

Networking

  • [ ] una NIC LAN por VM
  • [ ] evitar overlaps
  • [ ] no modificar 192.168.96.0/20
  • [ ] definir Pod CIDR
  • [ ] definir Service CIDR

RKE2

  • [ ] HA
  • [ ] embedded etcd
  • [ ] API stable endpoint
  • [ ] snapshots
  • [ ] restore tested

Platform

  • [ ] Cilium
  • [ ] Hubble
  • [ ] Ceph CSI
  • [ ] GitOps
  • [ ] OpenBao
  • [ ] MkDocs
  • [ ] Memory Plane
  • [ ] Work Ledger

Agents

  • [ ] Hermes SRE
  • [ ] Hermes Developer
  • [ ] Hermes Marketing
  • [ ] ADK Fleet

Migration

  • [ ] Edge nodes
  • [ ] Gateway API
  • [ ] first hosting workers
  • [ ] first 10 sites
  • [ ] production validation
  • [ ] progressive migration
  • [ ] Swarm retirement

36. Resultado esperado

Al finalizar el bootstrap inicial:

                    GitHub
             wetopi-platform
                    │
             infrastructure
                    │
                 Codex
                    │
               wetopi-ops01
                    │
             OpenTofu/Ansible
                    │
                    ▼
             ┌───────────────┐
             │   RKE2 HA     │
             └───────────────┘
                    │
       ┌────────────┼────────────┐
       │            │            │
   3 Control     Cilium      3 Platform
    Planes        Hubble       Workers
       │            │            │
       └────────────┼────────────┘
                    │
                 Ceph CSI
                    │
                  GitOps
                    │
                 OpenBao
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      Docs       Memory      Work Ledger
        │           │           │
        └───────────┼───────────┘
                    │
             Hermes + ADK

Todavía sin necesidad de haber movido un solo cliente.

Después:

Edge
 ↓
first hosting workers
 ↓
first websites
 ↓
progressive migration
 ↓
Swarm retirement

Conclusión

La estrategia de arranque queda fijada así:

  1. Git primero.
  2. IaC desde el primer día.
  3. Bootstrap desde fuera de Kubernetes.
  4. RKE2 greenfield.
  5. Tres control planes.
  6. Tres platform workers.
  7. Una sola NIC LAN por VM.
  8. No tocar Ceph 192.168.96.0/20.
  9. Cilium/Hubble.
  10. Ceph CSI.
  11. GitOps.
  12. OpenBao.
  13. Docs, Memory y Work Ledger.
  14. Hermes y ADK ya dentro del cluster definitivo.
  15. Edge después.
  16. Hosting después.
  17. Migración progresiva desde Swarm.

La prioridad es crear una foundation que pueda romperse, reconstruirse y probarse sin afectar a producción, y solo después empezar a trasladar tráfico y workloads reales.