Fleetman Microservices in Kubernetes

Richard: Quindi, per questo corso, ti sto dando uno scenario in cui ti è stato assegnato un sistema da un team di sviluppo e hanno già creato una serie di immagini Docker. E il tuo lavoro come ingegnere delle operazioni è di farlo distribuire nel cloud. Ora so che nella vita reale molti di voi che osservano questo funzioneranno come ingegnere degli sviluppatori o forse si sta puntando a diventare un ingegnere degli sviluppatori. In questo modo si sta lavorando sia sullo sviluppo che sulla distribuzione del sistema. Quindi ho preparato per te una serie di immagini pre-costruite, DockerHub. com sotto il repository Richard Chesterwood e il tuo lavoro in questa sezione del corso è riunirli insieme e dovremo decidere se questi sono pod, set di repliche o implementazioni. E devi metterli insieme un po 'come un puzzle. Ora ci sono solo cinque immagini su questo sistema perché ho creato quello che è davvero il sistema di microservizi più basilare possibile. Ma è ancora un sistema con una quantità ragionevole di complessità, non è certamente un'applicazione Hello World. Ma ovviamente non possiamo semplicemente iniziare a distribuire queste immagini senza aver compreso l'architettura del sistema e come è stato distribuito. Quindi su questo video ti darò una panoramica completa di questo sistema di microservizi. Questo è un diagramma di alto livello di come tutte le immagini del Docker nel sistema sono collegate tra loro. Ognuna di queste caselle qui, una, due, tre, quattro, cinque, si riferisce alle immagini Docker che hai appena visto su DockerHub. Questo è un sistema che uso da alcuni anni ogni volta che svolgo corsi di formazione basati su microservizi o tecnologie simili. L'obiettivo è che è abbastanza complicato da illustrare tutti i concetti senza che sia così complicato da risultare travolgente. È davvero un ottimo caso di studio. Sebbene questo sia progettato per essere un semplice sistema abbattuto, c'è ancora una ragionevole quantità di complessità in questo sistema. Non voglio che tu ti senta sopraffatto da questo, anche se non comprendi il funzionamento interno del sistema, sarai ancora in grado di implementarlo. Tuttavia, per questo video ti guiderò attraverso l'architettura del sistema e spiegherò in cosa consistono ciascuno di questi pezzi e in che modo combaciano tutti. Il sistema che stiamo implementando in questo corso è un sistema per un qualche tipo di azienda di trasporti che deve monitorare i suoi veicoli mentre si muovono nel paese. Quindi è qualcosa come i camion delle consegne che si muovono in tutto il paese. Ciascuno dei veicoli è dotato di un Global Positioning System e periodicamente, forse ogni 10 secondi circa, un veicolo riporterà la sua posizione attuale al nostro server centrale. E avremo molti di questi veicoli sul campo che riportano costantemente le loro posizioni. Ora, naturalmente, la difficoltà è che non abbiamo veicoli reali. E questo mi consente di presentarti al primo dei microservizi. Questo qui è il microservice chiamato il simulatore di posizione. E come suggerisce il nome, questo microservizio simulerà quei veicoli che si spostano nel paese. È un microservizio molto semplice. Non hai davvero bisogno di capire alcun codice in questo sistema. Ricorda, il nostro compito è solo quello di distribuire il sistema sul cloud, ma so che molti di voi saranno interessati a esaminare gli interni profondi di questo sistema, e si può trovare tutto il codice per questo sistema sul mio repository GitHub chiamato K8S-fleetman. E il mio nome utente su GitHub è DickChesterwood. Ora, su progetti di sviluppo reali, tendo a mantenere ogni microservice come un repository a sé stante, ma per mantenere le cose semplici e perché GitHub al momento della registrazione non ha un buon modo di raggruppare i repository correlati, ho deciso solo per rendere questo un unico repository con una cartella per ogni microservizio. Ognuno dei servizi inizia con la frase K8s per Kubernetes, ovviamente dash dashet seguito da qualunque sia chiamato il nome del servizio, microservice o sottosistema. Quindi ecco il simulatore di posizione. Capita di essere implementato in Java e sto usando Spring Boot. Come ho detto, non importa se hai familiarità con queste tecnologie. Voglio solo mostrarti davvero da dove provengono i dati. Quindi su questo particolare microservizio, all'avvio legge in una serie di file. E all'interno di questi file ci sono alcuni dati di test per simulare i veicoli. E funziona come un loop infinito in realtà, e in modo casuale ogni pochi secondi legge dal file. Lascia che ti mostri come sono questi file sotto la cartella SRC e poi sotto main. E poi sotto le risorse, e poi sotto le tracce, ecco una serie di file di test che ho generato. Ogni file rappresenta un singolo veicolo. Il nome del veicolo è solo il nome del file e vedremo questi nomi apparire nel front-end. Se volessi aggiungere più veicoli a questo, dovresti semplicemente creare un nuovo file, dovresti semplicemente creare un nuovo file in questa directory. Se vuoi dare un'occhiata a qualcuno di loro, vedrai che qui non c'è molto di una struttura, è solo una lunga serie di latitudini e longitudini, in altre parole posizioni sul pianeta Terra. E ho generato questi file semplicemente prendendo alcune tracce GPS che puoi trovare da varie fonti online. Ogni volta che il simulatore di posizione legge in una di queste latitudini e longitudini, ovviamente deve fare qualcosa con esso. Uno degli obiettivi dei microservizi è che un singolo microservizio dovrebbe fare solo una cosa. Ora, nel caso del simulatore di posizione, allora una cosa ovviamente simulerà le posizioni. Una volta letto in una di queste posizioni da un file, il compito di questo microservizio è finito. Quindi ha bisogno di consegnare quei dati da qualche altra parte. Quindi, dato che il microservizio genera posizioni simulate, invia quelle posizioni a una coda. E una coda è un aspetto molto comune di un'architettura di microservizi. Ci consente di inviare dati attraverso il sistema senza unire il microservizio. Per questo sistema, sto usando una coda chiamata ActiveMq. Non so se ti sia capitato di imbatterti in quella coda, ci sono molte scelte diverse che potremmo fare qui, ho solo una certa familiarità con ActiveMq, è una coda abbastanza semplice con cui lavorare. La coda, proprio come tutto il resto del sistema, è implementata come contenitore Docker. È questo chiamato K8s-fleetman-queue. Oltre a GitHub, troverai anche una cartella per la coda. Questo è di gran lunga il più semplice dei componenti di questo sistema perché è solo un singolo file Docker. Se si guarda nel file Docker, questo contenitore è stato creato da un download standard da Apache. org. Il prossimo microservizio nel sistema è quello chiamato tracker di posizione, e sicuramente per questo sistema questo è il più importante dei microservizi. Il lavoro di questo microservizio consiste nel leggere le posizioni dalla coda e fare vari calcoli su quelle posizioni. Ad esempio, calcolerà la velocità dei veicoli. Anche questo microservizio costituirà un deposito per i veicoli in modo che possiamo fare cose come memorizzare la cronologia di dove sono stati i veicoli. Di questo parleremo un po 'più avanti nel corso quando inizieremo a lavorare con i database. Solo una breve parola sulla mia notazione qui, noterai che ho la freccia puntata verso la coda anche se, come hai appena visto dall'animazione lì, i dati, le posizioni del veicolo vanno in questa direzione. Ora, quando ho usato questo schema sui corsi precedenti, ho avuto molte domande al riguardo. Non sono mai stato del tutto sicuro su quale direzione attorno a questa freccia debba andare veramente, ma tecnicamente in UML, che è la notazione che sto usando qui, la freccia indica una dipendenza. E questo microservizio dipende dalla coda, quindi è quello che sto rappresentando con la freccia qui. Non sto effettivamente rappresentando la direzione del flusso di dati, spero che abbia senso. Quindi questi tre componenti rappresentano davvero l'intero back-end di questo sistema, è un sistema semplice. Naturalmente nella vita reale avremmo molti più microservizi, ma questo è sufficiente per questo sistema. Quindi, ovviamente, avremo un front end per tutto questo e per questo particolare sistema questa sarà un'applicazione JavaScript. Accade per essere implementato usando Angular. Ora l'ultimo componente principale di cui abbiamo bisogno è un cosiddetto gateway API. La ragione per cui questo è necessario è ovviamente che in qualche modo l'applicazione JavaScript qui a sinistra avrà bisogno di comunicare con il sistema di back-end, avrà bisogno di comunicare in qualche modo con questi microservizi. E sarebbe sicuramente una brutta cosa se permettessimo qui al codice JavaScript di chiamare direttamente uno qualsiasi dei microservizi. La ragione è che il sistema di backend cambierà costantemente man mano che il sistema verrà aggiornato e modificato e, in generale, progettato, i microservizi cambieranno. Ricorda, i microservizi sono molto piccoli, quindi è inevitabile che ci siano dei cambiamenti. Molto rapidamente posso immaginare che questo tracker di posizione diventerà sempre più complicato e molto presto vorremmo dividere quel microservice in microservizi separati. E a volte succede il contrario, a volte ti rendi conto che due microservizi sono troppo piccoli e devono essere uniti. Quindi il back-end sarà in costante stato di flusso. Ora, se permettessimo al front-end JavaScript di fare riferimento direttamente a uno di questi microservizi, ovviamente ogni volta che apportassimo una modifica a uno di questi microservizi, dovremmo anche passare attraverso tutto il codice JavaScript e avremmo per apportare tutte le modifiche rilevanti. Quindi quello sarebbe sicuramente un anti-pattern e non permettiamo mai al codice di front end di fare riferimento direttamente ai microservizi. Per questo motivo, introduciamo un componente finale chiamato gateway API. L'idea del gateway API è molto semplice. Questo diventa il singolo punto di accesso all'intera applicazione. D'ora in poi il codice JavaScript avrà solo il permesso di fare riferimento a questo gateway API. Il gateway API è un componente piuttosto semplice. Il suo compito è delegare qualsiasi chiamata ai microservizi appropriati. E in genere il gateway API contiene una sorta di logica che associa le richieste in arrivo ai microservizi sottostanti. Quindi il JavaScript qui potrebbe fare una chiamata di riposo, non deve essere una chiamata di riposo, ma potrebbe essere, per alcuni URL, che viene intercettato dal gateway API e quindi utilizzerà una logica per determinare come deve essere chiamata essere gestito La logica nel gateway API è in genere una sorta di mappatura. Quindi sarebbe qualcosa di simile se la richiesta in arrivo termina con / veicoli, quindi delegare la chiamata a, in questo caso, il tracker di posizione. Questo significa che mentre progettiamo i microservizi, aggiungiamo nuovi microservizi, dividiamo i microservizi e così via, gli ingegneri devono solo apportare le modifiche corrispondenti qui nel gateway API molto semplice. Il front-end è quindi isolato da eventuali modifiche. Ora sto faticando qui perché so che molti di voi avranno già familiarità con i gateway API e che molti di voi saranno nuovi, quindi è difficile ottenere il livello giusto qui, ma se si desiderano ulteriori informazioni su questo, quindi controlla l'URL che sto mostrando qui, che è un'ottima introduzione al modello di gateway API. Quindi, ricorda, non è necessario conoscere i dettagli dell'implementazione profonda di qualsiasi sistema, è solo un lavoro per implementare il sistema. Quindi ora sai qual è lo scopo di ognuna di queste cinque immagini Docker, trasformiamoci in una distribuzione di Kubernetes.