fume
commented
3 weeks ago Dall'interno del container, di default, 127.0.0.1 non fa riferimento al "tuo" localhost (ovvero il Docker host), ma al localhost del container stesso, motivo per cui ottieni l'errore ECONNREFUSED, visto che all'interno del tuo container nessuno è in ascolto su quella porta/ip. L'errore causa poi il crash del container.
Se vuoi che il tuo container sia in grado di comunicare con l'host, hai diverse opzioni ma dipendono dal networking mode di Docker che stai usando.
Se non hai specificato il parametro --network quando hai lanciato il container, allora stai utilizzando quasi sicuramente la modalità "bridge" e il tuo container è stato collegato alla docker network di nome "bridge". In questo caso per parlare con l'host devi usare il gateway IP della docker network "bridge".
C:\> docker network ls
NETWORK ID NAME DRIVER SCOPE
4137fed6027c bridge bridge local
7b01931d1691 host host local
ab8fd4415ad0 none null local
C:\> docker network inspect bridge
....
....
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1" <---- usando questo IP dal container, parlerai con l'host
}
]
}
....Nel mio caso l'IP da utilizzare è 172.17.0.1.
In alternativa puoi lanciare il container con il parametro --network="host" e in questo caso anche dall'interno del container "localhost" o 127.0.0.1 faranno riferimento all'host e non al container stesso. Questo approccio è spesso sconsigliato in quanto il container stesso potrebbe usare "localhost" aspettandosi di parlare con se stesso, ma in questo caso parlerebbe con l'host, portandi quindi ad altri tipi di errori.
In ogni caso, se anche spid-keycloak-provider (non ho visto il repo, non so di cosa si tratta 😄) è stato lanciato tramite docker (senza parametro --network che equivale a --network="bridge"), allora entrambi i container saranno collegati alla network "bridge", motivo per cui potranno parlarsi usando l'ip del container. Gli ip dei container potrai recuperarli con il comando
C:\> docker network inspect bridge
.....
......
"Containers": {
"0c59a21e641ad67c5b14435b6f72d97aa31fae7527a8f6dc381e0d33ae291af2": {
"Name": "container2",
"EndpointID": "7747a9007eace05fef1a876735551fb738e36cc11214cbf56acf1f1dc9575818",
"MacAddress": "02:42:ac:11:00:03",
"IPv4Address": "172.17.0.3/16", <--------- 172.17.0.3 è l'IP del container2
"IPv6Address": ""
},
"56a70c8dee9406365648d09a35df9483c59533a0c72bd447695cb61a17607a80": {
"Name": "container1",
"EndpointID": "788231f2767e37d625b555c5e7a1740fb6f4f4879425ecba002131500b9df8d4",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16", <--------- 172.17.0.2 è l'IP del container1
"IPv6Address": ""
}
}
......Alternativa forse più semplice è usare docker-compose per lanciare entrambi i container. In questo caso i container potranno parlarsi fra di loro semplicemente usando il service name che gli hai assegnato, in quanto verranno collegaati ad una network creata ad-hoc in fase di avvio.
Alternativa simile al docker-compose: creare una user defined bridge network e collegarci esplicitamente i containers. In questo modo i container potranno parlarsi tramite IP e/o tramite nome container (cosa non possibile sulla rete predefinita chiamata "bridge").
C:\Users\fumer> docker network create my-network
C:\Users\fumer> docker run -d --rm --name container1 --network my-network alpine /bin/sh -c "sleep infinity"
C:\Users\fumer> docker run -d --rm --name container2 --network my-network alpine /bin/sh -c "sleep infinity"
C:\Users\fumer> docker exec -it container1 /bin/sh
/ # ping container2
PING container2 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.049 ms
64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.081 ms
64 bytes from 172.18.0.2: seq=2 ttl=64 time=0.059 ms
64 bytes from 172.18.0.2: seq=3 ttl=64 time=0.059 ms
64 bytes from 172.18.0.2: seq=4 ttl=64 time=0.058 ms
--- container2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.049/0.061/0.081 ms
C:\Users\fumer> docker exec -it container2 /bin/sh
/ # ping container1
PING container1 (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.060 ms
64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.060 ms
64 bytes from 172.18.0.3: seq=2 ttl=64 time=0.099 ms
64 bytes from 172.18.0.3: seq=3 ttl=64 time=0.067 ms
64 bytes from 172.18.0.3: seq=4 ttl=64 time=0.057 ms
64 bytes from 172.18.0.3: seq=5 ttl=64 time=0.103 ms
64 bytes from 172.18.0.3: seq=6 ttl=64 time=0.097 ms
64 bytes from 172.18.0.3: seq=7 ttl=64 time=0.059 ms
^C
--- container1 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0.057/0.075/0.103 ms
gabrielesilinic
non mi è pienamente chiaro che stia succedendo, ma sto cercando di testare l'applicazione con italia/spid-keycloak-provider. a causa del fatto che come da pull request #276 non sia possibile usare localhost ho semplicemente cercato di bypassare il problema usando l'IP localhost corrispondente per registrare il mio SP dentro il server. il problema è che appena metto http://127.0.0.1:8080/my-url semplicemente muore, sotto il messaggio d'errore che ho recuperato dal container docker prima che terminasse.
qui sotto per comodità il dockerfile che si occupa di far andare keycloak con tanto di plugin. anche se onestamente dubito che serva perché comunque è possibile che crashi prima che a keycloak importi qualcosa.
nota: l'immagine non si occupa della completa configurazione del endpoint saml --> openid connect SPID, per quello si può dare un occhiata in wiki.