Microservizi in Quarkus: configurazione di base

In accordo con la specifica JAX-RS realizzare un microservizio che esponga degli endpoint Rest prevede l'estensione della classe jax.ws.rs.core.Application per realizzare la configurazione RESTFul del Web service.

Un solo punto di configurazione: application.properties

In Quarkus abbiamo un solo file, application.properties, nel quale risiedono le configurazioni applicative e i profili di un tipico ambiente per sviluppo, collaudo e produzione.

Le prime proprietà da analizzare riguardano l'accesso all'applicazione. Abbiamo visto in precedenza che la chiamata di un microservizio avviene attraverso un path di default che precede i path definiti dalle annotazioni presenti nella definizione del servizio Rest.

La personalizzazione di questo path è possibile grazie alla property quarkus.resteasy.path. Per fare in modo che il servizio risponda sul path my-currency-conversion inseriamo ad esempio in application.properties la configurazione:

quarkus.resteasy.path=/my-currency-conversion

Il microservizio risponderà ora sull'URL principale

http://localhost:8080/my-currency-conversion/

al quale aggiungeremo i path dell'endpoint Rest.

Anche la gestione del nome dell'applicazione è un'operazione rilevante e possiamo scegliere quale darle utilizzando la property quarkus.application.nome. Il suo settaggio influenzerà il nome del file jar del microservizio prodotto dalla compilazione Maven.

Quarkus utilizza Netty e, come per ogni application server Java, il deploy dell'applicazione avviene di default sulla porta 8080. Possiamo però impostare un'altra porta d'ascolto specificando le property quarkus.http.port per HTTP e quarkus.http.ssl-port per HTTPS.

Concludiamo la descrizione delle property di base con l'impostazione dell'indirizzo host d'ascolto del microservizio. La property che permette di impostarlo è quarkus.http.host, particolarmente importante per ambienti a container.

Di default Quarkus ascolta sull'indirizzo 0.0.0.0 che equivale ad avere il microservizio in ascolto su tutte le interfacce di rete.

Configurazione TLS

Un altro aspetto di configurazione riguarda la gestione dei certificati e per una guida su come creare certificati self-signed da utilizzare
per le applicazioni di prova è possibile consultare questa pagina.

Elenchiamo di seguito una lista delle property necessarie per la configurazione TLS di un microservizio:

Property	Descrizione
quarkus.http.ssl.certificate.file=[path]	Path del file PEM che rappresenta il certificato o la catena di certificati del server.
quarkus.http.ssl.certificate.key-file=[path]	Path del file PEM che rappresenta il certificato con la chiave privata del server.
quarkus.http.ssl.certificate.key-store-file=[keystore]	Key store opzionale che mantiene le informazioni del certificato del server invece di specificarle in file separati.
quarkus.http.ssl.certificate.key-store-file-type=[JKS|PEM]	Parametro opzionale con cui specificare il tipo di key store. Se non specificato viene dedotto automaticamente dal nome del file.
quarkus.http.ssl.certificate.key-store-password=[password]	Parametro con cui specificare la password del file di key store.
quarkus.http.ssl.certificate.trust-store-file=[file]	Parametro opzionale con cui specificare un certificato di trust store.
quarkus.http.ssl.certificate.trust-store-password=[password]	Parametro per specificare la password del file di trust store.

Profili applicativi

Quando definiamo i parametri di configurazione di un'applicazione in contesti professionali abbiamo la necessità di avere per una determinata property valori differenti per ambienti differenti. In questo contesto si inseriscono i profili Quarkus.

Grazie all'uso di un prefisso da applicare ad una property possiamo etichettarla come appartenente ad un profilo specifico. Ad esempio la property:

%dev.quarkus.application.name=my-service-dev

apparterrà al profilo dev e sarà presa in considerazione solo quando il ìservizio verrà eseguito in development mode (quarkus:dev). Quarkus fornisce 3 profili di default:

• dev: per quando siamo in sviluppo ed eseguiamo il comando quarkus:dev;
• test: per quando lanciamo casi di test;
• prod: per quando eseguiamo il jar del microservizio da riga di comando (es. java -jar quarkus-service.jar).

E' poi possibile definire profili personalizzati con l'impostazione della variabile d'ambiente QUARKUS_PROFILE sul valore dell'alias di profilo da utilizzare. Ad esempio supponiamo di aver definito un profilo aws per eseguire il microservizio su Amazon AWS. In ambiente Linux, dopo aver eseguito export QUARKUS_PROFILE=aws, il seguente comando da console:

java -jar my-quarkus-service.jar

avvierà l'esecuzione del microservizio considerando le property con prefisso aws all'interno di application.properties. E' infine interessante notare come sia semplice accedere da codice alle property definite:

@Inject
	@ConfigProperty(name="quarkus.application.name", defaultValue="my-service")
	private String applicationName;