Due bug che bloccavano deploy.sh su tenant con provisioning PVC lento:
1. Race DNS: lo step 8 aspettava solo mongodb-tenant-0 prima di rs.initiate.
Se i pod 1/2 erano ancora in provisioning, i loro record DNS nel service
headless non esistevano e rs.initiate falliva il quorum check con
"Could not find address for mongodb-tenant-1...". Ora si attende che tutti
e 3 i pod siano Ready.
2. mongosh "connection <monitor> closed": con --host 127.0.0.1, appena il
replica set è inizializzato mongosh passa in modalità topology e prova a
monitorare il PRIMARY via hostname annunciato, chiudendo la connessione.
Sostituito con URI directConnection=true, compatibile con la localhost
exception per la creazione del primo utente.
Allineati gli hint diagnostici in deploy.sh e l'esempio rs.status() nel README
al nuovo form directConnection.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Toolkit per deployare/aggiornare un tenant LoginMaster su qualsiasi Kubernetes
(EKS/AKS/DOKS/Scaleway/vSphere/...). Contiene:
- deploy.sh: bootstrap di un nuovo tenant (idempotente, re-run protection,
storage class auto-rilevata, prompt separati api/admin tag, generazione
segreti crittografici via openssl rand).
- update.sh: rolling update zero-downtime con tag api/admin separati, rollback
hint via 'kubectl rollout undo', riapplicazione opzionale del ConfigMap.
- templates/: 8 manifest parametrici (envsubst): namespace, cert-manager TLS
Mongo, NetworkPolicy intra-namespace, ConfigMap, MongoDB StatefulSet 3 repliche
con TLS interno + initContainer per keyfile/PEM, tenant-api Deployment 2 repliche
con CA validation, tenant-admin, ingress nginx + Let's Encrypt.
Sicurezza: TLS interno Mongo (cert-manager CA self-signed 10y), keyFile per
auth replica set, password client mai in argv, NetworkPolicy che isola il
tenant, pod Mongo non-root (uid 999) con initContainer come root per i file
runtime in tmpfs.
Luca