Help Docker compose. Ciekawy problem z siecia

Status
Not open for further replies.

miloszes

Nowy użytkownik
Noobie
Feb 4, 2024
7
1
0
1
43
QNAP
TS-459U
Ethernet
2.5 GbE
Witam wszystkich serdecznie,

Od pewnego czasu staram sie ustawic kilka uslug na swoim QNAPie.
Ze względu na przejrzystość chciałem rozdzielić poszczególne usługi na oddzielne piiki docker compose - tak aby były one podzielone funkcjonalnie.
Aktualnie pracuję nad konfiguracja sieci - chcialbym aby poszczegolne serwisy dostepne byly wylacznie wewnatrz sieci int-net, natomiast dostep do nich byl dostepny poprzez nginx wystawiony na jakims IP(podany adres IP jest adresem przykladowym).
W zwiazku z tym dla serwisu nginx probuje stworzyc dwie sieci:
* int-net (bridge) komunikacja wewnetrzna
* qnet-network (qnet)
1707053939910.png

O ile z wystawieniem nginx'a na "zewnatrz" nie mam najmniejszego problemu, tak podczas konfigurowania dodatkowej sieci int-net docker rzuca mi nastepujacym bledem:

"Error response from daemon: driver failed programming external connectivity on endpoint proxy-proxy-1 (7e7939bf635169840eb5260adc7892c5e3b37a441b9ca63d776ea93587537ed7): listen tcp4 0.0.0.0:443: bind: address already in use"

Próbowałem następujacych opcji:

1. definiowanie sieci int-net w ramach
a. tego samego pliku compose
b. pliku homepage compose z opcja attachable + ngix attachable + external
c. reczne stworzenie sieci za pomoca docker network create network-int oraz docker network create network-int --attachable --subnet=172.25.0.0/16 a nastepnie definiowanie w ngix attachable + external
d. reczne stworzenie sieci jak w podpunkcie powyzej i proba dodania kontenerow do sieci int-net za pomoca polecenia docker docker network connect int-net 9f79eb44b842
e. rozne inne kombinacje tych rozwiazań

Co ciekawe kiedy utowrzylem siec za pomoca portainera i dodalem recznie kontener za pomoca polecenia z punktu d, wszystko dziala prawidlowo. Rowniez ta sama siec uzyta w pliku compose jako attachable i external zachowuje sie prawidlowo - nie dostaje wspomnianych bledow address already in use :/

Porownanie wynikow docker inspect obu sieci nie wykazuje roznic. Jedyna roznica polega na tym, ze jedna siec zostala dodana za pomoca portainer (dzialajace rozwiazania) a druga recznie/compose.yaml(nie dzialajace rozwiazanie).

Ponizej zalaczam compose.yaml file, ktorego uzywam do przeprowadzania testow.

version: "3.8"
services:
proxy:
image: "jc21/nginx-proxy-manager:latest"
restart: unless-stopped
hostname: "proxy.local"
ports:
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
networks:
int-net:
qnet-network:
ipv4_address: 192.168.30.69
volumes:
- /share/containers_mount/proxy/data:/data
- /share/containers_mount/proxy/letsencrypt:/etc/letsencrypt
networks:
qnet-network:
driver_opts:
iface: eth0
driver: qnet
ipam:
driver: qnet
options:
iface: eth0
config:
- subnet: 192.168.30.0/24
gateway: 192.168.30.10
int-net:
external: true
attachable: true
name: int-net

Plik compose deploy'uje za pomoca container station 3. Posiadam najnowsza wersje QTS (5.1.5.2645). Powyzszy plik compose nie udaje mi sie deployowac za pomoca portainer (
failed to deploy a stack: Network proxy22_qnet-network Creating Network proxy22_qnet-network Error failed to create network proxy22_qnet-network: Error response from daemon: cannot find interface option) ze wzgledu na problem tworzenia sieci qnet.


Czy ma ktos moze pomysl dlaczego moje rozwiazanie moze nie dzialać? Wiem, że mogę kontynuować i tworzyć sieci za pomoca portainer, ale nie jest to to co chcialbym osiagnac - chcialcym miec w jednym miejscu zdediniowane procesy i jak najbardziej je moc zautomatyzowac na przyszlosc.


Z góry dziękuję i pozdrawiam,
Miłosz
 
Solution
Siec problematyczna.
JSON:
[
[
    {
        "Name": "int-net",
        "Id": "1541667856ecd79b1ab9fd70e55be2bc180d08a124906dcfb712fa0b201652c2",
        "Created": "2024-02-04T13:55:48.593506201+01:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.30.0.0/16",
                    "Gateway": "172.30.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {...
zadam pytanie z kategorii idiota: czy jaki zmienisz port 443 na 8443 to działa (lewą stronę) ?
 
Tak, po zmianie portu z 443 na 8443 poszło bez problemu.

Nie wiem czy to cos wprowadzi do tematu, ale ponizej mam zrzuc z docker inspect z sieci na ktorej jest problem z 443 (docker inspect 1541667856ec). POniższy listing pochodzi ze zrzutu po zamianie portu kontenera z 443 na 8443.
[
{
"Name": "int-net",
"Id": "1541667856ecd79b1ab9fd70e55be2bc180d08a124906dcfb712fa0b201652c2",
"Created": "2024-02-04T13:55:48.593506201+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.30.0.0/16",
"Gateway": "172.30.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"338ebfad65b0007b424a6708c885e3c8b73f072131480b2d152bc0a0aa2b9169": {
"Name": "proxy-proxy-1",
"EndpointID": "47c6c2c418a60b600b5fa5116619a8d40359276aa9d678a85ceb63c5bf39c3cc",
"MacAddress": "02:42:ac:1e:00:04",
"IPv4Address": "172.30.0.4/16",
"IPv6Address": ""
},
"79c9c29605d32188aee0eab5c5a7195b786da938522bd91afcf44347e9700e2f": {
"Name": "homepage",
"EndpointID": "1e4ebd57451819c8cb4c0fa83289dd08213e9884c76c983be49b7e206bfe87c2",
"MacAddress": "02:42:ac:1e:00:02",
"IPv4Address": "172.30.0.2/16",
"IPv6Address": ""
},
"f33b123bdc98b40f056311043dfaab3a1c16aedd39563b40f6d77daba61b0f19": {
"Name": "pi-hole-1-pihole-1",
"EndpointID": "71e4dda64a76677dca8381bd801ef4432fb8b5711daa2930f90363036ee8c002",
"MacAddress": "02:42:ac:1e:00:03",
"IPv4Address": "172.30.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "int-net",
"com.docker.compose.project": "homepage",
"com.docker.compose.version": "2.14.1"
}
}
]


Natomiast tutaj zrzuc z sieci w której binding po 443 działa bez problemu. W tym zrzucie istnieje różnica w label - rano przed aktualizacj QTS do najnowszej wersji siec z problemami miała również pusty obiekt label. Zerknę na to jeszcze za chwilę, czy dam radę wyczyścić te pola label. Poniższy listing jest ze zbindowanym portem 443.


[
{
"Name": "test-net",
"Id": "d61ebd64678e89c2eb3aa7916b50c70e3c9a6df5732be90cd56b17aaf299bef1",
"Created": "2024-02-04T10:59:34.720582209+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.20.0.0/16",
"Gateway": "172.20.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"79c9c29605d32188aee0eab5c5a7195b786da938522bd91afcf44347e9700e2f": {
"Name": "homepage",
"EndpointID": "1e400bf4cfbe061a6940e5ed0baaa03ddd746b4f7654ff572cef0b7d075315fa",
"MacAddress": "02:42:ac:14:00:02",
"IPv4Address": "172.20.0.2/16",
"IPv6Address": ""
},
"f33b123bdc98b40f056311043dfaab3a1c16aedd39563b40f6d77daba61b0f19": {
"Name": "pi-hole-1-pihole-1",
"EndpointID": "af4e56aded21357b579472b50dd5fa7c91d6cc79ca8f7cae1dabdf9d624736da",
"MacAddress": "02:42:ac:14:00:03",
"IPv4Address": "172.20.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
]

Widzialem wczoraj w necie, ze docker mial problem czasami z tym bindowaniem i zastanawiam sie czy to jakis bug dockera, który jest w obecnie obsługiwanej wersji QNAP (20.10.22-qnap7). Najnowsza wersja docker engine to 25.x.x.

listen tcp4 0.0.0.0:443: bind: address already in use
Może interfejs zarządzania QNAP jest na porcie 443?

Ciężko powiedzieć - ta druga sieć zrealizowana przez portainer śmiga aż miło. W ogóle to IMO bez sensu się zachowuje, bo tutaj mamy bridged network, które w teorii powinno być izolowane jeżeli to dobrze rozumiem, i każdy kontener powinien dostać swoje IP i zbindować swoje porty pod swoje interface'y na przydzielonym IP.
Czy masz może jakiś pomysł czy da się "wylistować" wszystkie adresy IP i ich porty użyte przez dan sieć?
 
Siec problematyczna.
JSON:
[
[
    {
        "Name": "int-net",
        "Id": "1541667856ecd79b1ab9fd70e55be2bc180d08a124906dcfb712fa0b201652c2",
        "Created": "2024-02-04T13:55:48.593506201+01:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.30.0.0/16",
                    "Gateway": "172.30.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "338ebfad65b0007b424a6708c885e3c8b73f072131480b2d152bc0a0aa2b9169": {
                "Name": "proxy-proxy-1",
                "EndpointID": "47c6c2c418a60b600b5fa5116619a8d40359276aa9d678a85ceb63c5bf39c3cc",
                "MacAddress": "02:42:ac:1e:00:04",
                "IPv4Address": "172.30.0.4/16",
                "IPv6Address": ""
            },
            "79c9c29605d32188aee0eab5c5a7195b786da938522bd91afcf44347e9700e2f": {
                "Name": "homepage",
                "EndpointID": "1e4ebd57451819c8cb4c0fa83289dd08213e9884c76c983be49b7e206bfe87c2",
                "MacAddress": "02:42:ac:1e:00:02",
                "IPv4Address": "172.30.0.2/16",
                "IPv6Address": ""
            },
            "f33b123bdc98b40f056311043dfaab3a1c16aedd39563b40f6d77daba61b0f19": {
                "Name": "pi-hole-1-pihole-1",
                "EndpointID": "71e4dda64a76677dca8381bd801ef4432fb8b5711daa2930f90363036ee8c002",
                "MacAddress": "02:42:ac:1e:00:03",
                "IPv4Address": "172.30.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "int-net",
            "com.docker.compose.project": "homepage",
            "com.docker.compose.version": "2.14.1"
        }
    }
]
[/ICODE]

Sieć działajaca prawidłowo.

[CODE=json]
[
{
"Name": "test-net",
"Id": "d61ebd64678e89c2eb3aa7916b50c70e3c9a6df5732be90cd56b17aaf299bef1",
"Created": "2024-02-04T10:59:34.720582209+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.20.0.0/16",
"Gateway": "172.20.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"79c9c29605d32188aee0eab5c5a7195b786da938522bd91afcf44347e9700e2f": {
"Name": "homepage",
"EndpointID": "1e400bf4cfbe061a6940e5ed0baaa03ddd746b4f7654ff572cef0b7d075315fa",
"MacAddress": "02:42:ac:14:00:02",
"IPv4Address": "172.20.0.2/16",
"IPv6Address": ""
},
"f33b123bdc98b40f056311043dfaab3a1c16aedd39563b40f6d77daba61b0f19": {
"Name": "pi-hole-1-pihole-1",
"EndpointID": "af4e56aded21357b579472b50dd5fa7c91d6cc79ca8f7cae1dabdf9d624736da",
"MacAddress": "02:42:ac:14:00:03",
"IPv4Address": "172.20.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
]
Post automatically merged:

Udało mi się znaleźć rozwiazanie.
Najprawodpodobniej w moim przypadku kluczowe bylo stworzenie sieci z dwoma parametrami:

attachable: true
internal:true

poniżej załaczam działajacego u mnie compose.yaml gdyby ktoś natrafił na podobny problem w przyszłości.

YAML:
version: "3.8"
services:
  proxy:
    image: "jc21/nginx-proxy-manager:latest"
    restart: unless-stopped
    hostname: "proxy.local"
    ports:
      - '80:80' # Public HTTP Port
      - '443:443' # Public HTTPS Port
      - '81:81' # Admin Web Port
    networks:
      network-int:
      qnet-network:
        ipv4_address: 192.168.30.69     
    volumes:
      - /share/containers_mount/proxy/data:/data
      - /share/containers_mount/proxy/letsencrypt:/etc/letsencrypt
networks:
  qnet-network:
    driver_opts:
      iface: eth0
    driver: qnet
    ipam:
      driver: qnet
      options:
        iface: eth0
      config:
        - subnet: 192.168.30.0/24
          gateway: 192.168.30.10
  network-int:
    attachable: true
    internal: true
    name: network-int
    ipam:
      config:
        - subnet: 172.10.0.0/16
          gateway: 172.10.0.1

W przypadku ręcznego tworzenia sieci rozwiazanie u mnie działa z następujacymi parametrami:

Bash:
 docker network create network-int --attachable --subnet=172.25.0.0/16 --internal
docker network connect network-int 79c9c29605d3

Najprawodpoodbniej to, że działało za pomoca portainer wynikało z przypadku, że przypadkowo gdy testowałem różne ustawienia wyklikałem sieć attachable internal - a nie było widać tej różnicy w docker inspect i wydawało mi się, że tak samo utworzyłem obydwie sieci.


Dziękuję za poświęcony czas i pomoc przy problemie.
Dobrego wieczoru,
Miłosz
 
Solution
Status
Not open for further replies.

Users search this thread by keywords

  1. container station docker compose
  2. Container
  3. nginx proxy manager