JHipster - Microservizi 2

Microservizi - 2

Introduzione

In questo post descrivo come usare l'architettura a micro-servizi presentata nel post precedente e aggiungo gli elementi per sviluppare in questa architettura.

Sviluppo

L'ipotesi di base è quella di dover sviluppare una applicazione web a microservizi, con una interfaccia utente e una serie di servizi di back-end.

La parte di front-end può essere sviluppata seguendo due strade:

1) sviluppare separatamente le due componenti usando l'apposito comando in fase di lancio del wizard:

$ jhipster --skip-client

oppure:

$ jhipster --skip-server

2) sviluppare una monolitica e poi portare nell'architettura a micro servizi: la parte di "services" e la parte di "webapp"

Componenti

Scenario 1

Importazione del jdl (prima sul gateway e poi sul microservizio)

Il Gateway in questa fase rappresenta la componente sulla quale ci concentreremo. A questo arriveranno le chiamare del browser e dovrà rispondere alle richieste.

1) Generare le entità con il comando :

  $ jhipster import-jdl jhipster-jdl.jh

Da questo accedo a front-end e back-end perché vengono generati tutti e due sul gateway

2) Generare le entità sul micro-servizio con il comando :

  $ jhipster import-jdl jhipster-jdl.jh

In questo caso si può notare che la cartella relativa alla webapp risulta vuota:

Essendo un microse-rvizio la procedura di importazione del jdl non ha creato la parte di front-end, giustamente !!!

Tornando sul gateway, sul quale l'applicazione è già utilizzabile avendo questo generato sia front-end che back-end, bisogna impostare l'url alla quale deve richiedere i servizi del back-end:

/webpack/webpack.common.js

impostare la costante:

SERVER_API_URL: `'http://IP_MICROSERVIZIO:8081/'`

Scenario 2

Importazione del jdl (prima sul micro-servizio e poi sul gateway dal microservizio)

sul gateway bisogna lanciare:
$ jhipster entity [NOMEENTITA]


Esempio concreto: login

1) Importato jdl nel progetto loginMS
2) Creato nuovo progetto gateway
3) Settato su entrambi il registry

Spring Cloud Config Server

Vediamo come sfruttare questa componente dello stack JHipster.
Questa componente punta distribuire ed esternalizzare, in una architettura a microservizi, i parametri di configurazione. E' costituita da un server (integrato nel registry) e di un client (integrato in ogni microservizio).
L'implementazione prevede di default l'uso di git come componente di archiviazione. Quindi da git viene letta la configurazione di default.

Funzionamento

La prima cosa che fanno le applicazioni appena partono è registrarsi al Registry per ricevere la loro configurazione. Questo vale sia per i microservizi che per il gateway. Appena partono, le applicazioni, creano una istanza di una variabile "Environment" (org.springframework.core.env.Environment) che viene alimentata dal metodo della "SpringApplication" "getEnvironment()".
Il tutto viene letto dal repository git:

https://github.com/jhipster/jhipster-registry-sample-config.git

Uso

Ho comincianto creando un progetto su git e importando il codice dal git precendete:

Poi ho aggiunto una variabile:

	my:
	loggin:
	logpath: \app\log\

Ho clonato il progetto relativo al registry dal repository git:

$ git clone https://github.com/jhipster/jhipster-registry.git

Ho modificato la variabile, presente in:

central-config/application.yml


spring.cloud.config.server.composite.uri facendola puntare al mio repo con il file application.yml. Ho lanciato il progetto del Registry e mi risulta la possibilità di ottenere la distribuzione di un json con la configurazione:

http://IP_SERVER:8761/config/jhipster-registry/dev

Ora passiamo alla "dockerizzazione" del Registry così impostato.
Attenzione al comando:


JHipster costruisce applicazioni già pronte ad essere dockerizzate. Scrive un file di configurazione per docker in:

src/main/docker/

Dockerizziamo una applicazione

Avendo scaricato il progetto del registry, avendolo modificato, ora devo renderlo una immagine docker. Il progetto è stato modificato in Eclipse sotto Windows. Il processo qui documentato vale per qualunque progetto maven, per passare dal codice al microservizio dockerizzato in esecuzione.

Per ottenere l'immagine docker a partire dal progetto maven di un microservizio sul server è installato e usato JIB. Quindi basterà:

• trasferire il tar del progetto maven, dalla macchina di sviluppo, nella dir dell'utente: /home/utente/downloads/src
• copiare il pacchetto compresso come sudo nella dir di lavoro: 

$ sudo cp /home/utente/downloads/src/[NOMEDELMICROSERVIZIO.TAR] .

• cancellare l'eventuale directory con i sorgenti di versioni precedenti: 

$ sudo rm -R [NOMEDELMICROSERVIZIO]

• scompattare il progetto del microservizio:

$ sudo tar xvf [NOMEDELMICROSERVIZIO.TAR]

• spostarsi nella directory del progetto:

$ cd NOMEDELMICROSERVIZIO

• buildare l'immagine del docker manualmente:

$ sudo mvn -X -e package -Pdev verify -DskipTests jib:dockerBuild

• in alternativa vediamo come buildare l'immagine del docker da Eclipse:

  

Specificare come Goal: package jib:buildTar

Profiles: dev

Ed eventualmente "Skip Tests" per evitare l'esecuzione degli alfa test e velocizzare la build.

Specificare la JVM desiderata per la compilazione.

• maven risponderà con il nome del microservizio buildato:

[INFO] Built image to Docker daemon as [NOMEDELMICROSERVIZIO]

• individuare il nome del container del microservizio con:

$ sudo docker container ps

•  se è in esecuzione, altrimenti se è fermo:

$ sudo docker container ps -a

• appuntarsi "CONTAINER ID" e "IMAGE"
• fermare la precedente istanza del microservizio:

$ sudo docker container stop [CONTAINER ID]

• rimuovere il vecchio container:

$ sudo docker rm [CONTAINER ID]

• rimuovere la vecchia immagine:

$ sudo docker image rm [IMAGE]

• lanciare il run della nuova immagine che creerà in nuovo container, con il nome da assegnare CONTAINER NAME, e lo eseguirà:

$ sudo docker run --network host --name [CONTAINER NAME] -d [IMAGE]

• per vedere i log del microservizio in esecuzione:

$ sudo docker logs [CONTAINER NAME]

Note

1) Se si vuole evitare la compilazione della parte relativa ai test, aggiungere questa fra le "property" nel pom.xml:

<maven.test.skip>true</maven.test.skip>

2) Quello proposto per l'ambiente di sviluppo che prevede l'uso di un docker, almeno sotto Windows, non è utilizzabile in produzione perché docker genera un ip locale alla macchina. La soluzione in produzione richiede, allo stato attuale, un docker in linux.

3) Ho scaricato e lanciato il docker del jhipster-registry.

Per impostare la rete del docker in modalità bridge per usare l'ip dell'host per implementare il servizio:

$ sudo docker run --network host jhipster/jhipster-registry

Quest'opera è distribuita con Licenza Creative Commons Attribuzione 4.0 Internazionale (CC BY 4.0) - Condividi allo stesso modo