Bene, è il momento di concludere questa serie di articoli in cui ho deciso di raccontare, scendendo un po’ più nel dettaglio, di come ho fatto il deploy di un’applicazione Laravel su un cluster Kubernetes.
Dove eravamo rimasti? Facciamo un piccolo recap, prima di procedere:
- Nella prima parte di questa serie mi sono dedicato a quelle che sono state le mie necessità prima di arrivare a considerare una soluzione Kubernetes managed per la mia app. Non sono partito da Kubernetes da subito, non ne avevo bisogno e col senno di poi è stata la scelta giusta;
- Nella seconda parte, invece, ho iniziato a mettere le mani in pasta. Ho spiegato come ho creato i vari componenti di cui avevo bisogno, dal cluster ai database, per poi passare dalla creazione dell’immagine da usare ed, infine, arrivare alla creazione delle varie risorse sul cluster;
Oggi ci occuperemo di quello che rimane. Vedremo, infatti:
- come gestire la questione dei worker delle nostre code: l’applicazione che ho realizzato, infatti, fa un uso intensivo delle code. Su questo ho anche una chicca da condividervi, quindi continuate a leggere…
- come gestire il discorso dei cronjob: altra parte fondamentale della mia app, smanettando e sperimentando ho scoperto un altro paio di cose interessanti che vi faranno risparmiare qualche mezz’ora di grattacapi;
- lo spiegare a Kubernetes come e quando lanciare le migration, al termine di un deploy, nel modo “giusto”, o comunque più coerente;
