container docker - voce runtime "nessuna informazione disponibile"

Question

container docker - voce runtime "nessuna informazione disponibile"

Ettore-Morasso opened this issue 2 years ago · 10 comments

Descrizione del Bug
Creando un container dall'immagine del repository github (linkitaly/govway:3.3.7_postgres) o creando un immagine come spiegato al link https://github.com/link-it/govway-docker (es 3.3.6-p1) e avviandola, l'applicativo parte correttamente e sembra funzionare, tuttavia quando dalla console si apre la parte relativa al runtime per ogni voce di informazione viene riportato "nessuna informazione disponibile" e non è presente alcun pulsante per svuotare la cache.
La problematica sembra quella riportata in https://githubhelp.com/link-it/govway/issues/30 ma il workaraound proposto non funziona, anche perchè in quel commento si voleva risolvere un errore a seguito di aggiornamento da una versione ad un'altra.
In questo caso l'installazione è pulita e al primo avvio del container il problema è già presente.
Il problema non si presenta con un installazione classica del prodotto.

Come riprodurlo:
fare pull dell'immagine (3.3.6p1 o 3.3.7), avviare il container, entrare nella console, selezionare la voce runtime

Risultato atteso:
Ottenere le informazioni sul sistema e i pulsanti per svuotare le vaire cache

Ambiente:

OS: [docker host debian 10.8 o ubuntu Ubuntu 20.04.3 LTS]
GovWay: [e.g. 3.3.6p1 o 3.3.7]
AS: [e.g WildFly 18]
Java: [e.g OpenJDK 11]
DBMS: [e.g Postgres 13]

Answer 1 · 2022-09-15T18:03:31.000Z

Dalle nostre verifiche non siamo riusciti a riprodurre il problema. Potresti inviarci un archivio contenente i log generati da govway ?

Dato che govway recuper le informazioni di runtime attraverso una chiamata http in localhost è possibile che si stata fatta quanlche configurazione di rete particolare ?

Answer 2 · 2022-09-16T11:31:30.000Z

Se può essere di aiuto ti allego l'ambiente docker compose utilizzato per verificare la tua segnalazione.

Inoltre nella documentazione di GovWay relativa agli Scenari Applicativi puoi trovare un ambiente docker compose funzionante utilizzato per la dimostrazione degli scenari descritti.
In questo caso avendo una configurazione di rete differente da quella attesa per default dall'immagine (govway in ascolto su localhost:8080) è stato aggiunto nella directory di configurazione di govway il file 'govway.nodirun.properties' valorizzato come segue:

# ===================================================================
# Indirizzamento servizi dei nodi 'run'
# Servizio 'proxy'
GovWay.remoteAccess.url=http://gateway:8082/govway/proxy
# Servizio 'check'
GovWay.remoteAccess.checkStatus.url=http://gateway:8082/govway/check
# ===================================================================

Answer 3 · 2022-09-16T14:41:55.000Z

Grazie dei riferimenti, proverò le vostre configurazioni presto.
Allego invece archivio con il docker-compose.yaml utilizzato, i log govway e la conf wildfly modifica per avere https sulla porta 8445.
Quello che ho notato dal log della console è che quando clicco sulla voce runtime vengono tracciati molti errori (connessione rifiutata) che immagino siano relativi appunto alle chiamate per recupeare le varie info.
Da interfaccia se provo ad esempio a cambiare il livello di log, lo http status code è 500.
Avevo anche provato a configurare wildfly in modo che redirigesse ogni chiamata da http a https e in questo caso se provavo un operazione come quella sopra descritta lo status code era (giustamente) 302 ma l'operazione falliva...nell'allegato non è presente però questa configurazione.
Forse sbaglio qualcosa...qual'è di preciso la chiamata che fa govway per recuperare le info di sitema?
govway-conf-and-logs.zip

Answer 4 · 2022-09-16T15:11:04.000Z

Non noto alcuna anomalia del docker compose che ci hai allegato.
Se nei log hai riscontrato problemi di connessione, l'istanza wildfly che viene attivata all'interno dell'immagine non è in ascolto su localhost:8080.

Ti allego una serie di verifiche che puoi effettuare collegandoti direttamente sull'istanza 'govway' caricata tramite docker, dove trovi le url utilizzata dalla console per contattare il runtime di govway.
Se riscontri che il problema è di raggiungibilità poichè wildfly risulta in ascolto su un hostname o porta differente, puoi creare il file 'govway.nodirun.properties' descritto nel commento precedente per risolvere la problematica.

[poli@xxx ~]# docker exec -ti govway /bin/bash

[wildfly@govway /]$ cat /opt/wildfly-18.0.1.Final/standalone/log/server.log  | grep "listening on"
2022-09-16 15:01:06,258 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTP listener gestione listening on 0.0.0.0:8082
2022-09-16 15:01:06,258 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajplistener listening on 0.0.0.0:8009
2022-09-16 15:01:06,260 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener fruizioni listening on 0.0.0.0:8081
2022-09-16 15:01:06,260 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on 0.0.0.0:8080

[wildfly@govway /]$ curl -v http://localhost:8080/govway/proxy
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /govway/proxy HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Length: 0
< Date: Fri, 16 Sep 2022 15:04:15 GMT
< 
* Connection #0 to host localhost left intact

[wildfly@govway /]$ curl -v http://localhost:8080/govway/check
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /govway/check HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Length: 0
< Date: Fri, 16 Sep 2022 15:04:18 GMT
< 
* Connection #0 to host localhost left intact

Answer 5 · 2022-09-20T14:01:13.000Z

ho controllato il log di wildfly e le porte di interesse sono tutte in ascolto, tuttavia se configuro wildfly per redirigere da http a https entrambi gli endpoint vanno in errore (302).
Mentre non forzando la redirezione e configurando govway.nodirun.properties così:

`#GovWay.remoteAccess.url=https://govway.democontent.it:8445/govway/proxy

Servizio 'check'

GovWay.remoteAccess.checkStatus.url=https://govway.democontent.it:8445/govway/check`

il servizio check risulta sempre raggiungibile (200, pagina vuota), mentre il servizio proxy ritorna sempre 500 "servizio non disponibile":

`curl -v https://govway.democontent.it:8445/govway/proxy

About to connect() to govway.democontent.it port 8445 (#0)
Trying 172.22.0.3...
Connected to govway.democontent.it (172.22.0.3) port 8445 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Server certificate:
```
  subject: CN=*.democontent.it
```
```
  start date: Apr 13 00:00:00 2022 GMT
```

  expire date: Apr 26 23:59:59 2023 GMT

```
  common name: *.democontent.it
```

  issuer: CN=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1,O=DigiCert Inc,C=US

GET /govway/proxy HTTP/1.1
User-Agent: curl/7.29.0
Host: govway.democontent.it:8445
Accept: /

< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Length: 24
< Date: Tue, 20 Sep 2022 12:41:09 GMT
<

Connection #0 to host govway.democontent.it left intact`

Riporto anche alcune errori dal file console_core che mostrano come la chiamata per ottenere le conf/info da runtime fallisca perchè il servizio non viene trovato:

`...
org.openspcoop2.web.ctrlstat.servlet.config.ConfigurazioneHelper.addConfigurazioneSistema(4817): Errore durante la lettura dello stato della cache AccessoRegistroServizi: Stato [[httpCode 500] Servizio non disponibile] sconosciuto

java.lang.Exception: Stato [[httpCode 500] Servizio non disponibile] sconosciuto
...
org.openspcoop2.web.ctrlstat.servlet.config.ConfigurazioneHelper.addConfigurazioneSistema(4817): Errore durante la lettura dello stato della cache ConfigurazionePdD: Stato [[httpCode 500] Servizio non disponibile] sconosciuto

java.lang.Exception: Stato [[httpCode 500] Servizio non disponibile] sconosciuto
...
ERROR <20-09-2022 10:07:05> org.openspcoop2.web.ctrlstat.servlet.config.ConfigurazioneHelper.isErroreHttp(7036): Errore durante la lettura della risorsa [versione della PdD]: [httpCode 500]
Servizio non disponibile

ERROR <20-09-2022 10:07:05> org.openspcoop2.web.ctrlstat.servlet.config.ConfigurazioneHelper.isErroreHttp(7036): Errore durante la lettura della risorsa [versione della base dati]: [httpCod
e 500] Servizio non disponibile
...
ERROR <20-09-2022 10:07:05> org.openspcoop2.web.ctrlstat.servlet.config.ConfigurazioneHelper.addConfigurazioneSistema(5844): Errore durante la lettura delle informazioni SSL (jmxResourcePdD
): null

java.lang.NullPointerException: null
...`

Mi trovo quindi a un punto morto; riporto però che in una precedente installazione di govway (3.3.6p1) su host fisico il problema non si presenta e recupero correttamente tutte informazioni.

Answer 6 · 2022-09-20T16:32:51.000Z

Prova a collegarti all'interno del database e vedere come viene registrato il nodo tramite la seguente query:

`govwaydb=> select * from nodi_runtime ;

------------+--------+------------------------+-------------------------+-------------+----

172.19.0.2 | GovWay | 2022-09-20 16:22:34.12 | 2022-09-20 16:22:37.542 | 0 | 8`

Utilizza poi l'hostname per effettuare i controlli che ti ho indicato precedentemente tramite il comando curl. Molto probabilmente wildfly non è in ascolto sull'indirizzo che viene registrato nella tabella.

Se riesci ad inviarci i log emessi da GovWay riusciamo a darti un aiuto più preciso. L'archivio zip che hai precedentemente caricato è vuoto nella directory 'govway_log' e 'wildfly'. Verifica eventualmente di aver montato correttamente il volume esterno associato ai logs.

Answer 7 · 2022-09-22T13:01:37.000Z

Scusate per i log vuoti...devo aver sbagliato comando con lo zip.
Facendo la query che mi avete suggerito ho visto come il campo non fosse valorizzato, mentre tutti i restanti si. E' bastato aggiungere lo hostname del caso in quel campo e tutte le funzionalità/informazioni del "menu" runtime si sono abilitate/popolate.
Tuttavia non mi è chiaro perchè non venga popolato quel campo al primo avvio del container...c'è qualche variabile d'ambiente da passare?
Inoltre ho visto che se valorizzo manualmente il campo e poi riavvio (docker restart ) il container mi ritrovo una nuova entry nella tabella nodi_runtime sempre con il campo hostname non valorizzate....come se creasse un nuovo nodo...ma così facendo ritorno nella situazione in cui le informazioni non vengono recuperate.
Chiaramente nel docker-compose.yaml passo la seguente variabile d'ambiente per inizializzare il db:
GOVWAY_POP_DB_SKIP=false
e quindi forse la nuova riga nella tabella nodi_runtime dipende da quello, tuttavia cambiare il docker-compose.yaml dopo il primo avvio non è la soluzione migliore.
Come si può procedere?

Answer 8 · 2022-09-23T10:19:18.000Z

Si tratta di un problema che si verifica quando viene impostato un hostname manualmente, come hai fatto tu nel tuo docker-compose.yml
Ho apportato una modifica allo script di avvio del container che dovrebbe risolvere il problema, nel commit link-it/govway-docker@9b94c23.
La modifica è stata integrata nell'immagine appena rilasciata linkitaly/govway:master_postgres. Puoi modificare il tuo docker-compose.yml impostando questa nuova immagine e confermarci che il problema è risolto ?

Answer 9 · 2022-09-23T13:12:41.000Z

Confermo che con l'ultima build che avete rilasciato corregge il problema, il campo hostname di nodi_runtime viene popolato correttamente con lo ip assegnato da docker al container.
Il valore persiste al riavvio del container (docker restart) senza creazione di una nuova riga sulla tabella.
Se il container viene distrutto e ricreato (compose down e up ), avendo salvato i dati del db su un volume montato, correttamente viene aggiornato il campo della tabella con l'eventuale nuovo ip assegnato da docker.
Unica cosa che ho riscontrato è che se setto wildfly in modo che rediriga il traffico http dalla 8080 alla https 8445 allora viene ritornato sempre un errore (http status code 302) quando si vuole contattare gli endpoint chek e proxy.
Capisco che questo potrebbe essere un aspetto secondario e magari non considerato da design in quanto tale redirezione può essere fatta a monte da un proxy davanti al gateway. E' cosi?

Answer 10 · 2022-09-23T14:09:28.000Z

Ti confermo che i servizi non sono stati progettati per seguire il redirect.
A questo punto se non hai rilevato altre anomalie consideriamo il problema risolto.