añadido apolo
This commit is contained in:
173
apolo/readme.md
Normal file
173
apolo/readme.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# Apolo SSL – Manifiestos de Kubernetes
|
||||
|
||||
Manifiestos de **Apolo** para Kubernetes con Kustomize. Incluye backend (PHP + Postgres + RabbitMQ), servicios web, WebSocket, CoreDNS interno para la VPN, chat (ejabberd), Nakama, y el stack de **streaming** (MediaMTX, Kurento Media Server y su API, Streamer). Certificados vía **cert-manager** y exposición con **ingress-nginx** y **MetalLB**.
|
||||
|
||||
> Despliegue único:
|
||||
>
|
||||
> ```bash
|
||||
> kubectl apply -k .
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## Requisitos
|
||||
|
||||
* **Kubernetes** 1.24+ (probado con containerd).
|
||||
* **MetalLB** configurado y con rango para IPs del LB (ej. `192.168.200.0/24`).
|
||||
* **ingress-nginx** desplegado. En este entorno se usan dos Services:
|
||||
|
||||
* `ingress-nginx/ingress-nginx-controller` → IP pública (ej. `192.168.0.100`)
|
||||
* `ingress-nginx/ingress-nginx-controller-200` → **IP VPN** `192.168.200.10` (tráfico interno)
|
||||
* **cert-manager** con un `ClusterIssuer` llamado `letsencrypt-prod`.
|
||||
* **StorageClass** disponible (`ceph-rbd`) para los PVC de Postgres, RabbitMQ y ejabberd.
|
||||
* (Para acceso por VPN) **WireGuard** + NAT desde la subred de la VPN hacia la red del clúster / redes internas.
|
||||
* Acceso al **Harbor** privado (se crea un Secret `harbor-cred`).
|
||||
|
||||
---
|
||||
|
||||
## Estructura
|
||||
|
||||
```
|
||||
certs/ # Certificados de cert-manager (Certificate)
|
||||
configmaps/ # ConfigMaps de cada servicio (web, portal, CoreDNS, etc.)
|
||||
deployments/ # Deployments de cada componente
|
||||
ingress/ # Ingress (TLS, whitelists VPN, etc.)
|
||||
pvc/ # PersistentVolumeClaims (Postgres, Rabbit, ejabberd)
|
||||
secrets/ # Secrets de aplicación (no commitear credenciales privadas)
|
||||
services/ # Services (ClusterIP / LoadBalancer) y alias de docker-compose
|
||||
namespace.yaml # Namespace apolo
|
||||
kustomization.yaml
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## DNS interno para la VPN
|
||||
|
||||
Se expone un **CoreDNS** propio con IP LB `192.168.200.11` que resuelve:
|
||||
|
||||
* `chat.apolo.c2et.net`
|
||||
* `muc.chat.apolo.c2et.net`
|
||||
* `portal.apolo.c2et.net`
|
||||
* `colossus.apolo.c2et.net`
|
||||
* `streaming.apolo.c2et.net`
|
||||
* `meeting.apolo.c2et.net`
|
||||
* `backend.apolo.c2et.net`
|
||||
|
||||
|
||||
> Para clientes VPN, configurar **DNS** a `192.168.200.11`.
|
||||
|
||||
---
|
||||
|
||||
## Certificados TLS
|
||||
|
||||
* `certs/` contiene `Certificate` para dominios como `chat.*` y `meeting.*`.
|
||||
* El resto de hosts se gestionan vía Ingress con `tls.secretName` emitido por `letsencrypt-prod`.
|
||||
|
||||
---
|
||||
|
||||
## Whitelists y acceso
|
||||
|
||||
Los Ingress sensibles incluyen:
|
||||
|
||||
```
|
||||
nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.200.0/24,10.244.0.0/16,192.168.4.0/24"
|
||||
```
|
||||
|
||||
* **192.168.200.0/24**: clientes por **VPN**
|
||||
* **10.244.0.0/16**: tráfico **intra-clúster**
|
||||
* **192.168.4.0/24**: nodos/infra local (ajústalo si aplica)
|
||||
|
||||
---
|
||||
|
||||
## Despliegue
|
||||
|
||||
```bash
|
||||
# Namespace y todo el stack
|
||||
kubectl apply -k .
|
||||
|
||||
# Ver pods
|
||||
kubectl -n apolo get pods -w
|
||||
```
|
||||
|
||||
### IPs de Services (ejemplo)
|
||||
|
||||
* Ingress interno (nginx): `192.168.200.10`
|
||||
* CoreDNS interno: `192.168.200.11`
|
||||
* MediaMTX (streaming): `192.168.200.12`
|
||||
* Ejabberd (chat): `192.168.200.12`
|
||||
* Kurento API: `192.168.200.14`
|
||||
|
||||
---
|
||||
|
||||
## Operación
|
||||
|
||||
* **Escalar**:
|
||||
|
||||
```bash
|
||||
kubectl -n apolo scale deploy/apolo-web --replicas=2
|
||||
```
|
||||
|
||||
* **Actualizar imagen**:
|
||||
|
||||
* Cambia el tag en el `Deployment` y aplica `kubectl apply -k .`
|
||||
|
||||
* **Logs**:
|
||||
|
||||
```bash
|
||||
kubectl -n apolo logs deploy/apolo-web -f
|
||||
```
|
||||
|
||||
* **Ingress / TLS**:
|
||||
|
||||
```bash
|
||||
kubectl -n apolo describe ingress apolo-backend
|
||||
kubectl -n apolo get certificate
|
||||
kubectl -n apolo describe certificate <name>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Notas y “gotchas”
|
||||
|
||||
* **PV de Postgres**: el contenedor requiere subdirectorio `PGDATA`. Ya se maneja con `initContainer` para evitar el `lost+found` al montar el PVC.
|
||||
* **Health checks web**: los `readiness/liveness` usan `/`. Algunos contenedores devuelven 404 en raíz; está ajustado para que no reinicien en bucle.
|
||||
* **ejabberd**:
|
||||
|
||||
* Permisos de volúmenes: se monta con `fsGroup` adecuado; si ves `permission denied`, revisa `runAsUser/runAsGroup/fsGroup` y el dueño de los paths del contenedor.
|
||||
* TLS: el `initContainer` concatena `tls.key + tls.crt → chat.pem` (formato que espera ejabberd).
|
||||
* **.com vs .net**:
|
||||
|
||||
* El **Portal** puede hablar con `backend.apolo.c2et.com`; la VPN/CoreDNS “traduce” a la IP interna (192.168.200.10) sin tocar certificados.
|
||||
* Si más adelante migras todo a `.com`, cambia `hosts` de los Ingress y `Certificate`.
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting rápido
|
||||
|
||||
* Ver por qué el Ingress devuelve 403/401/404:
|
||||
|
||||
```bash
|
||||
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller -f
|
||||
kubectl -n apolo describe ingress apolo-backend
|
||||
```
|
||||
* Revisar eventos de un pod:
|
||||
|
||||
```bash
|
||||
kubectl -n apolo describe pod <pod>
|
||||
```
|
||||
* Comprobar variables de entorno en PHP (conectividad DB/Rabbit):
|
||||
|
||||
```bash
|
||||
kubectl -n apolo exec deploy/apolo-php -- printenv | egrep 'DATABASE_URL|MESSENGER_TRANSPORT_DSN'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Despliegue
|
||||
|
||||
```bash
|
||||
kubectl apply -k .
|
||||
kubectl -n apolo get pods -w
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user