Shoot-'Em-Up Costruction Kit

k3OS - La base del Cloud Aperto Premessa Esiste un problema alla base dell'uso di un qualsiasi sistema operativo per far girare Kubernetes su un nodo di un cluster per la containerizzazione: dover manutenere (configurare, patchare, aggiornare e fare il backup) di più entità separate ma dipendenti che sono il Sistema Operativo, Kubernetes e i container. L'idea, che approfondisco in questo post, venuta a quelli di Rancher è di creare una distro con Kubernetes ad-hoc da manutenere con Kubernetes stesso. Perchè Kubernetes ? Perché è diventato uno standard de-facto per quanto riguarda il containers management adottato dai maggiori fornitori di cloud pubblico. Quindi questo significa che adottare Kubernetes significa predisporre una infrastruttura, di cloud ibrido, generalizzata che può appoggiarsi ad uno qualsiasi dei fornitori di cloud pubblico alla bisogna (picchi di carico). Architettura Il cluster L'obiettivo è la cost

Multitenant Definizione Un tenant è un gruppo omogeneo di utenti di una applicazione. In ambito SaaS un tenant è un "abbonato" al servizio che si fornisce o un cliente della applicazione. Con multi-tenant si intende una architettura che consente a più tenant di utilizzare la stessa istanza fisica ma mantenendo una separazione delle istanze logiche della stessa applicazione. Abbiamo la nostra applicazione distribuita in cloud e gli utenti: Ognuno potrà vedere solo i suoi dati. La stessa cosa se gli utenti sono raggruppati in organizzazioni: ognuno potrà vedere solo i dati della propria organizzazione: Architettura Dal punto di vista tecnico deve succedere che la stessa istanza dell'applicazione deve gestire le utenze mantenendo una separazione logica degli utenti e una separazione fisica dei dati per implementare il massimo livello di separazione fra i tenant: un database per tenant.  Quindi anche se i tenant condividono le stesse

Microservizi - Monitoraggio Costruzione di una "Dashboard" di monitoraggio di un sistema software con componenti a microservizi e non. Gestione dei log. Introduzione Sempre nel contesto delle architetture a microservizi, ma anche in un contesto più generale di applicazioni distribuite risulta necessario avere e/o fornire all'utente un pannello di controllo o Dashboard. Può essere orientata a fornire dati di sintesi come "numero di processi completati con successo" e  "numero di processi completati con insuccesso" ma anche a avere informazioni tecniche sul funzionamento delle componenti del sistema. Ultimo, ma non ultimo, avere uno storico di queste informazioni. Essendo, le architetture a microservizi, parcellizzate per natura in tante componenti avere uno strumento che consenta una visione d'insieme è indispensabile anche per capire dove intervenire in caso di anomalie. Dashboard Vogliamo aggregare e rappresentare si

Docker - Lista comandi Utile raccolta di comandi dal sito hackernoon : Sviluppo docker create [image] : Crea un nuovo container a partire da una particolare immagine. docker login : Fa il login nel repository di Docker Hub. docker pull [image] : ottiene una immagine dal Docker Hub repository. docker push [username/image] : Inserisce una immagine nel repository di Docker Hub. docker search [term] : Cerca in Docker Hub repository uno specifico termine. docker tag [source] [target] : Crea un tag, inserito in "target" o un alias che fa riferimento all'immagine inserita come "source". Esecuzione dei Docker Containers docker start [container] : Avvia uno specifico container. docker stop [container] : Ferma uno specifico container. docker exec -ti [container] [command] : Apre una shell all'interno di un particolare container. docker run -ti — image [image] [container] [command] : Crea ed avvia un container allo ste