Passa ai contenuti principali

JHipster - Microservizi 1



Microservizi - 1



Introduzione


In questo post descrivo come creare una architettura a microservizi con JHipster.

Architettura

Microservizio


Il microservizio che andremo a creare deve avere totale autonomia ed essere auto-consistente. Questo dice la letteratura. In effetti il microservizio deve svolgere un servizio "completo" a livello di modulo di business logic. Ad esempio in un sistema complesso la gestione delle mail integrata. Quindi deve fornire servizi come l'elenco delle mail di uno specifico utente, crearne, cancellarne, inviarne di nuove.
Per fare questo userà il database per accedere alla lista della mail dello specifico utente (che qui ipotizziamo stiano su un db).
Questo quello che deve fare. Quello che NON deve fare è autenticare l'utente che gli invia le richieste. Quindi di questa fase se ne occuperà un altro modulo. L'autenticazione, in questo prototipo, avverrà mediante token JWT. Creaiamo il microservizio.

Creato con il wizard di JHipster selezionando il tipo di applicazione come "microservizio", l'autenticazione come "JWT" e come servizio di discovery "JHipster Registry".

Importato lo schema dati jdl:


$ jhipster import-jdl test.jh

Dopo ho impostato l'ip del docker del registry, per fare in modo che avvenga il discover del servizio, nei seguenti file (il punto di intervento è reso evidente dalla presenza della porta :8761 che è quella di default del registry):

- /src/main/resources/config/application-dev.yml
- /src/main/resources/config/application-prod.yml
- /src/main/resources/config/bootstrap-prod.yml
- /src/main/resources/config/bootstrap.yml

Per configurare il docker dal quale generare il registry:

- /src/main/docker/central-server-config/docker-config/application.yml
- /src/main/docker/central-server-config/localhost-config/application.yml
- /src/main/docker/app.yml

ATTENZIONE: l'esecuzione dell'applicazione che segue è stata lanciata solo dopo aver configurato il registry come al passo successivo, altrimenti non partirà mai.

L'esecuzione dell'applicazione l'ho lanciata con il "Run As/Java Application" di Eclipse:



Registry

Questa componente ha le seguenti mansioni:

- Implementa un Eureka server che fa il discovery per le applicazioni. Così JHipster gestisce il routing e il load balancing per la scalabilità delle applicazioni.
- Fa da Spring Cloud Config Server e fornisce la configurazione a run-time a tutte le applicazioni.
- Fa anche da server per l'amministrazione e il monitoraggio di tutte le applicazioni.

Il servizio di discovering, basato su "Netflix Eureka server", consiste nel censire tutte le applicazioni che fanno parte della soluzione Eureka > Instances :


E' così che nelle architetture a microservizi il gateway sa quali microservizi sono disponibili, e con quali istanze sono in esecuzione, e per le applicazioni monolitiche è così che la cache distribuita di Hazelcast può scalare.

Dal registry è possibile anche gestire la configurazione centralmente dal menu: Configuration > Cloud Config:


E vedere la configurazione di ogni singola applicazione registrata dal menu: Administration > Configuration. Questa la configurazione del mio microservizio:




Le applicazioni quando vengono lanciate la prima cosa che fanno è collegarsi al JHipster Registry per ottenerne la configurazione ed essere "registrate". Questo vale sia per i microservizi che per i gateway (vedi nel paragrafo "Microservizio" dove configurare la chiave con l'ip e la porta del Registry).

Nota: tutte le applicazioni create con il wizard di JHipster avranno il client Eureka (del servizio di discovering) incluso, anche il Registry, solo che questo sarà caratterizzato dalla variabile eureka.client.fetchRegistry=false. Cosa verificabile mediante il servizio del Registry che ci mostra le configurazioni delle componenti (Gateway, microservizi e Registry stesso).

Un'altra funzione utilissima demandata al Registry è quella per la gestione dei parametri criptati. E' necessario aver installato Java Cryptography Extension (JCE). Per fare in modo che, ad esempio, la password per l'accesso al database non venga messa in chiaro nei file .yml basterà configurare una password per la chiave simmetrica in "encrypt.key" nel bootstrap.yml del Registry oppure come variabile di ambiente "ENCRYPT_KEY" come ho fatto io nel file jhipster-registry.yml del docker del Registry. Anche la gui web del Registry fornisce una pagina apposita per usare questa funzione Configuration > Encryption:


Per usarla praticamente nei file .yml di configurazione in maniera criptata:

password= '{cipher}myciphertextafterencryotion'

Il servizio è accessibile mediante:

IPDELREGISTRY:8761/config/encrypt -d mypassword

Servizio da usare ogni volta che si deve mandare un parametro di configurazione sensibile ad un utilizzatore.


Utilizzo


Andando nel menu Administration > API e selezionando la app di interesse dal menu a tendina in alto a destra avremo accesso ai servizi:


E possiamo provare le chiamate REST/API ai servizi:


Installazione



Per la soluzione ho usato l'immagine docker del registry (jhipster-registry),ottenendola mediante docker compose, e usando la configurazione presente nella dir del progetto a microservizi, creato al passo precedente, e lanciando il comando:


$ docker-compose -f src/main/docker/jhipster-registry.yml up

Dopo il lancio va fermato il servizio per gestirlo da Eclipse come specificato in seguito.

Prima di crearla potrebbe essere utile modificare il file /src/main/docker/jhipster-registry.yml che verrà usato per la configurazione. Ad esempio io ho inserito la variabile di ambiente: ENCRYPT_KEY=chiaveCript necessaria al crypt/decrypt descritto prima. 


Ho usato il plugin per Eclipse Docker Tooling che prima ho installato, sotto Windows, DockerToolbox.exe. Con questo lancio e fermo lo specifico container docker.


Il Gateway ed il Microservizio in esecuzione su due istanze viste dal registry:


Verrà creato un container docker con le specifiche del file puntanto dal comando precedente (jhipster-registry.yml) e verrà lanciato. Se si dispone del plugin per Eclipse di docker conviene fermarlo e gestirne lo start/stop dal plugin (consigliato).
Il compose prende un file di ocnfigurazione che è presente in /src/main/docker/central-server-config/ e che è comune a tutte le applicazioni create con JHipster impostate per l'uso di JHipster-Registry.


Gateway

Creata con il wizard dal sito.
Per il lancio del progetto anche qui con "Run As/Java Application" di Eclipse:



Ogni applicazione a microservizi registrata sul Registry è raggiungibile mediante questo, qui la chiamata del microservizio "mailms" passando dal gateway:




Che chiaramente dice che non siamo autorizzati.
Ogni applicazione, microservizi e gateway, devono registrarsi al Registry (vedi nel paragrafo "Microservizio" dove configurare la chiave con l'ip e la porta del Registry).

Sicurezza

Per questo scenario, nella realizzazione del progetto mediante wizard dal sito, ho scelto l'autenticazione "JWT".
JWT (JSON Web Token) è un metodo per rendere sicure le applicazioni in una architettura a microservizi.

JHipster usa la libreria JJWT , fornita da Okta, per implementare JWT.
Questa tecnologia si basa sull'uso di un token che viene generato dal gateway ed inviato ai microservizi sottostanti con i quali si condivide una chiave segreta, in modo che il microservizio possa validare il token e autenticare l'utente che sta usando il token.
I token sono auto-sufficienti perché contengono le informazioni relative sia all'autenticazione che alle autorizzazioni dell'utente. Quindi il microservizio non ha bisogno di accedere a database esterni (fondamentale per garantire la scalabilità).
JWT è un sistema di sicurezza "stateless", cioè senza memoria di stato. Questa è una ottima scelta se si vuole scalare la propria applicazione su più server.
Questa soluzione prevede un token che contiene il nome utente e le sue autorizzazioni. Il token è firmato e non può essere alterato dall'utente.


Impostazioni



JHipster usa una chiave segreta configurata in due proprietà di Spring Boot:

jhipster.security.authentication.jwt.secret

jhipster.security.authentication.jwt.base64-secret

La seconda, come si capisce dal nome, consiste in una chiave codificata in base64 e quindi vine considerata più sicura. Se entrambe sono configurate verrà usata la "secret" meno sicura per retro-compatibilità ma un warning verrà mostrato all'avvio della applicazione.
Entrambe devono essere lunghe almeno 512 bits e vengono inserite nei file "application-*.yml":




Si consiglia di tenere al sicuro quella di produzione e fare in modo che, tale file, venga inviato con una connessione SCP da un sysadmin nella stessa directory del WAR della nostra applicazione.
Si suggerisce anche di cambiare la password di "admin" e di "user" dall'apposito menu "Account>Password" nel momento in cui si va in produzione.





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

Commenti

Post popolari in questo blog

Telecamere Ip con accesso "nascosto"

Telecamere Ip con accesso "nascosto" Storia triste di un auto-hacking obbligato che mi ha fatto scoprire come la nostra privacy è realmente messa a rischi. Storia Ho acquistato dal mercatino/fiera del Radioamatore di Fasano quattro telecamere IP. La scatola riporta "Smart Camera" LF4810. Ne ho montata una e testata in tutte le sue funzionalità per oltre un mese. Chiaramente la manualistica scarsissima, come da tradizione in questi prodotti cinesi di costo molto concorrenziale, consiste in un "pieghevole" di 4 facciate. Chiaramente non erano documentate le impostazioni necessarie per attivare i protocolli ONVIF e RTSP che mi sono indispensabili per l'uso che ne devo fare. Nonostante questa scarsa documentazione dopo l'installazione base fatta con l'apposita app: tutto sembrava corretto. Chiaramente la prima azione che ho compiuto è stata quella di cambiare la password che di default è "123". Subito dopo h

Dynamic DNS con Duckdns.org in HTTPS

Obiettivo Avere un dominio https con certificato valido da usare come endpoint pubblico per Homeassistant e per un WebHook per i bot telegram. Fase 1 Registrazione del dominio in un servizio di dynamic DNS come https://www.duckdns.org/   : Scegliere per quale sistema operativo installare il client che si occuperà dell'aggiornamento dell'ip: Seguire la semplice guida per la configurazione del processo cron: Fase 2 Creazione del certificato e installazione sul server. Di tutto questo si occuperà una applicazione che si chiama certbot. $ sudo add-apt-repository ppa:certbot/certbot $ sudo apt install python-certbot-apache $ sudo certbot --apache -d ol3.duckdns.org -d www.ol3.duckdns.org Fase 3 Esporre il servizio https sulla rete pubblica. Aprire o reindirizzare la porta 443 verso l'host sul quale si è fatta la configurazione di certbot dal proprio router. Il certificato di certbot è valido per novanta giorn

JHipster - Uso base

Cosa è JHipster è un "generatore di applicazioni" che fornisce tutto lo stack necessario ad implementare una applicazione web e/o a microservizi basata su Spring Boot e AngularJs. E' dotato di un marketplace di componenti già pronte: https://www.jhipster.tech/#modules E' dotato di uno strumento web per la modellazione dello schema E-R: https://start.jhipster.tech/jdl-studio/ Prerequisiti - Java 8  - Node.js (usare la versione LTS 64-bit) - NPM viene installato con Node.js ma va aggiornato      $ npm install -g npm - Per usare il JHipster Marketplace, installare Yeoman:       $ npm install -g yo Uso base Gli step, presi dal sito ufficiale sono questi: 1. Installare JHipster:       $ npm install -g generator-jhipster Nota: per installare una versione specifica del generator:   $ npm install -g generator-jhipster@6.0.5 2. Crea una nuova directory ed entra dentro questa:   $ mkdir myApp   $ cd M yApp 3. Eseguire JHipster e