You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In alcuni contesti come lo sviluppo locale o il deploy dell'applicazione in ambienti cloud può essere conveniente poter gestire il TLS sul server in ascolto dell'applicazione. In cloud avere un server TLS con certificati self-signed può dar problemi agli health checker e quindi può essere utile far partire l'applicazione in http per poi poter esporre tramite gateway che servono il TLS firmato correttamente.
Attualmente è possibile farlo agendo sul file config/server.json ma per evitare fork e puntare direttamente al repository upstream nelle pipeline è comodo poterlo fare tramite variabile d'ambiente. Segue PR.
The text was updated successfully, but these errors were encountered:
ho notato lo stesso problema, in particolare quando si usano docker compose con microservizi in un network protetto e certificati self-signed o signed da una CA locale al cloud
credo che tutti possano farlo di conseguenza.
è consigliabile una PR in questo progetto per aggiungere una indicazione nella documentazione o la env var di default per gli scopi demo del progetto @damikael
In alcuni contesti come lo sviluppo locale o il deploy dell'applicazione in ambienti cloud può essere conveniente poter gestire il TLS sul server in ascolto dell'applicazione. In cloud avere un server TLS con certificati self-signed può dar problemi agli health checker e quindi può essere utile far partire l'applicazione in http per poi poter esporre tramite gateway che servono il TLS firmato correttamente.
Attualmente è possibile farlo agendo sul file
config/server.json
ma per evitare fork e puntare direttamente al repository upstream nelle pipeline è comodo poterlo fare tramite variabile d'ambiente. Segue PR.The text was updated successfully, but these errors were encountered: