Mam katalog apkmirror-scraper-composeo następującej strukturze:

.
├── docker-compose.yml
├── privoxy
│   ├── config
│   └── Dockerfile
├── scraper
│   ├── Dockerfile
│   ├── newnym.py
│   └── requirements.txt
└── tor
    └── Dockerfile

Próbuję uruchomić następujące docker-compose.yml:

version: '3'

services:
  privoxy:
    build: ./privoxy
    ports:
      - "8118:8118"
    links:
      - tor

  tor:
    build:
      context: ./tor
      args:
        password: ""
    ports:
      - "9050:9050"
      - "9051:9051"

  scraper:
    build: ./scraper
    links:
      - tor
      - privoxy

gdzie jest Dockerfilefortor

FROM alpine:latest
EXPOSE 9050 9051
ARG password
RUN apk --update add tor
RUN echo "ControlPort 9051" >> /etc/tor/torrc
RUN echo "HashedControlPassword $(tor --quiet --hash-password $password)" >> /etc/tor/torrc
CMD ["tor"]

że privoxyjest

FROM alpine:latest
EXPOSE 8118
RUN apk --update add privoxy
COPY config /etc/privoxy/config
CMD ["privoxy", "--no-daemon"]

gdzie configskłada się z dwóch linii

listen-address 0.0.0.0:8118
forward-socks5 / tor:9050 .

a Dockerfileza scraperjest

FROM python:2.7-alpine
ADD . /scraper
WORKDIR /scraper
RUN pip install -r requirements.txt
CMD ["python", "newnym.py"]

gdzie requirements.txtzawiera pojedynczą linię requests. Na koniec program newnym.pyzostał zaprojektowany tak, aby po prostu sprawdzić, czy zmiana adresu IP za pomocą Tora działa:

from time import sleep, time

import requests as req
import telnetlib


def get_ip():
    IPECHO_ENDPOINT = 'http://ipecho.net/plain'
    HTTP_PROXY = 'http://privoxy:8118'
    return req.get(IPECHO_ENDPOINT, proxies={'http': HTTP_PROXY}).text


def request_ip_change():
    tn = telnetlib.Telnet('tor', 9051)
    tn.read_until("Escape character is '^]'.", 2)
    tn.write('AUTHENTICATE ""\r\n')
    tn.read_until("250 OK", 2)
    tn.write("signal NEWNYM\r\n")
    tn.read_until("250 OK", 2)
    tn.write("quit\r\n")
    tn.close()


if __name__ == '__main__':
    dts = []
    try:
        while True:
            ip = get_ip()
            t0 = time()
            request_ip_change()
            while True:
                new_ip = get_ip()
                if new_ip == ip:
                    sleep(1)
                else:
                    break
            dt = time() - t0
            dts.append(dt)
            print("{} -> {} in ~{}s".format(ip, new_ip, int(dt)))
    except KeyboardInterrupt:
        print("Stopping...")
        print("Average: {}".format(sum(dts) / len(dts)))

docker-compose buildBuduje pomyślnie, ale gdy próbuję docker-compose up, pojawia się następujący komunikat o błędzie:

Creating network "apkmirrorscrapercompose_default" with the default driver
ERROR: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

Próbowałem znaleźć pomoc dotyczącą tego komunikatu o błędzie, ale nie znalazłem żadnej. Co powoduje ten błąd?

Widziałem, że sugeruje, że docker może mieć maksimum utworzonych sieci. Polecenia docker network prunemożna użyć do usunięcia wszystkich sieci, które nie są używane przez co najmniej jeden kontener.

Mój problem zakończył się, jak skomentował Robert : problem z openvpn service openvpn stop„rozwiązał” problem.

Napotkałem ten problem, ponieważ miałem uruchomiony OpenVPN. Jak tylko zabiłem OpenVPN, docker-compose upodpaliłem od razu, a błąd zniknął.

Uruchomiłem ten problem z działającym OpenVPN i znalazłem rozwiązanie, w którym NIE powinieneś zatrzymywać / uruchamiać serwera OpenVPN.

Pomysł, który powinieneś określić dokładnie podsieć, której chcesz użyć. Na docker-compose.ymlpiśmie:

networks:
  default:
    driver: bridge
    ipam:
      config:
        - subnet: 172.16.57.0/24

Otóż ​​to. Teraz defaultsieć będzie używana i jeśli Twoja sieć VPN nie przypisała Ci czegoś z 172.16.57.*podsieci, wszystko w porządku.

W następstwie Petera HAUGE dydaktycznego komentarz , na prowadzenie docker network lswidziałem (między innymi liniami) dodaje się:

NETWORK ID          NAME                                    DRIVER              SCOPE
dc6a83d13f44        bridge                                  bridge              local
ea98225c7754        docker_gwbridge                         bridge              local
107dcd8aa889        host                                    host                local

Linia z NAMEi DRIVERjako, hostże oba wydają się być tym, do czego odnosi się z „sieciami już utworzonymi na Twoim hoście”. Tak więc, podążając za https://gist.github.com/bastman/5b57ddb3c11942094f8d0a97d461b430 , uruchomiłem polecenie

docker network rm $(docker network ls | grep "bridge" | awk '/ / { print $1 }')

Teraz docker-compose updziała (chociaż newnym.pypowoduje błąd).

Mam ten sam problem. Pobiegłem docker system prune -a --volumes, docker network pruneale żadne mi nie pomogło.

Używam VPN, wyłączyłem VPN i po tym, jak docker zaczął normalnie i był w stanie stworzyć sieć. Następnie możesz ponownie włączyć VPN.

Jak wspomniały inne odpowiedzi, domyślna bridgesieć lokalna Dockera obsługuje tylko 30 różnych sieci (każda z nich jest jednoznacznie identyfikowalna na podstawie nazwy). Jeśli ich nie używasz, docker network prunezałatwią sprawę.

Możesz jednak być zainteresowany utworzeniem ponad 30 kontenerów, z których każdy ma własną sieć. Gdybyś był tym zainteresowany, musiałbyś zdefiniować overlaysieć. Jest to nieco trudniejsze, ale bardzo dobrze udokumentowane tutaj .

EDYCJA (maj 2020 r.): Link stał się niedostępny, przeglądając dokumenty, nie ma dokładnego zamiennika, ale polecam zacząć od tego miejsca .

Miałem identyczny problem z tym samym komunikatem o błędzie, ale rozwiązanie polegające na usunięciu nieużywanych sieci dockerowych nie pomogło. Usunąłem wszystkie niedomyślne sieci Dockera (a także wszystkie obrazy i kontenery), ale to nie pomogło - docker nadal nie był w stanie utworzyć nowej sieci.

Przyczyną problemu były interfejsy sieciowe, które pozostały po instalacji OpenVpn. (Był wcześniej zainstalowany na hoście). Znalazłem je, uruchamiając ifconfigpolecenie:

...
tun0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:10.8.0.2  P-t-P:10.8.0.2  Mask:255.255.255.0
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:75 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:84304 (84.3 KB)  TX bytes:0 (0.0 B)

tun1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:10.8.0.2  P-t-P:10.8.0.2  Mask:255.255.255.0
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:200496 errors:0 dropped:0 overruns:0 frame:0
      TX packets:148828 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:211583838 (211.5 MB)  TX bytes:9568906 (9.5 MB)
...

Odkryłem, że mogę je usunąć za pomocą kilku poleceń:

ip link delete tun0
ip link delete tun1

Po tym problem zniknął.

1. Sprawdź, czy działa jakikolwiek inny kontener. Jeśli tak, zrób: docker-compose down

2. Jeśli VPN jest podłączony, odłącz go i spróbuj ponownie uruchomić kontener Docker:

   docker-compose up -d container_name

Możesz spróbować

$sudo service network-manager restart

Pracował dla mnie.

Napotkałem ten sam problem, powodem jest to, że osiągnąłeś maksimum sieci:

wykonaj: docker network ls wybierz jedną do usunięcia za pomocą:docker network rm networkname_default

TL; DR

Dodaj

version: "3.7"
services:
  web:
    ...
    network_mode: "bridge"

Przeczytaj o network_modew dokumentacji .

Długa wersja

Zastrzeżenie : nie mam zbyt dużej wiedzy na temat sieci Docker, ale to załatwiło sprawę. YMMV.

Kiedy uruchomiłem docker run my-imagesieć, nie sprawiło mi to żadnych problemów, ale kiedy przekonwertowałem to polecenie na docker-compose.ymlplik, otrzymałem ten sam błąd co OP.

Przeczytałem odpowiedź Arenima i kilka innych rzeczy w Internecie, które sugerowały ponowne wykorzystanie istniejącej sieci.

Możesz znaleźć istniejące sieci, takie jak ta:

# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
ca0415dfa442        bridge              bridge              local
78cbbda034dd        host                host                local
709f13f4ce2d        none                null                local

Chciałem ponownie użyć domyślnej bridgesieci, więc dodałem

services:
  web:
    ...

networks:
  default:
    external:
      name: bridge

do korzenia mojego docker-compose.yml(a więc nie wewnątrz jednego z moich services, ale w wcięciu w rdzeniu).

Mam teraz następujący błąd:

BŁĄD: alias o zasięgu sieci Twojego kontenera jest obsługiwany tylko w przypadku kontenerów w sieciach zdefiniowanych przez użytkownika

Doprowadziło to do tego problemu Docker Github , który wyraźnie stwierdził, że powinienem dodać network_modeobiekt do mojego docker-compose:

version: "3.7"
services:
  web:
    ...
    network_mode: "bridge"

Używałem wersji Dockera 18.09.8, docker-composewersji 1.24.1i formatu pliku redagowania 3.7.

Przydarzyło mi się to, ponieważ używałem OpenVPN . Znalazłem sposób, w jaki nie muszę przerywać korzystania z VPN, ręcznie dodawać sieci do pliku docker-compose ani uruchamiać żadnego szalonego skryptu.

Przerzuciłem się na WireGuardzamiast OpenVPN. Mówiąc dokładniej, ponieważ korzystam z rozwiązania nordvpn, zainstalowałem WireGuard i użyłem jego wersji NordLynx.

Zabijanie VPN nie jest potrzebne.

Ten inny komentarz dotyczący korzystania z nowej sieci jest dla mnie dość bliski rozwiązaniu i działał przez jakiś czas, ale znalazłem lepszy sposób dzięki omówieniu w innym pytaniu

Utwórz sieć z:

docker network create your-network --subnet 172.24.24.0/24

Następnie na dole pliku docker-compose.yaml umieść to:

networks:
  default:
    external: 
      name: your-network

Gotowe. Nie ma potrzeby dodawania sieci do wszystkich definicji kontenerów itp., A jeśli chcesz, możesz ponownie użyć sieci z innymi plikami docker-compose.

Jeśli chcesz mieć wiele sieci, możesz kontrolować, ile miejsca IP Docker przekazuje każdej sieci za pomocą default-address-poolsustawienia demona, więc możesz dodać to do /etc/docker/daemon.json:

{
  "bip": "10.254.1.1/24",
  "default-address-pools":[{"base":"10.254.0.0/16","size":28}],
}

Tutaj zarezerwowałem 10.254.1.1/24(254 adresy IP) dla sieci mostkowej.

Dla każdej innej sieci, którą utworzę, docker podzieli 10.254.0.0przestrzeń (65 tys. Hostów), udostępniając jednocześnie 16 hostów ( "size":28odnosi się do maski CIDR dla 16 hostów).

Jeśli utworzę kilka sieci, a następnie uruchomię docker network inspect <name>na nich, może wyświetlić się coś takiego:

        ...
        "Subnet": "10.254.0.32/28",
        "Gateway": "10.254.0.33"
        ...

Te 10.254.0.32/28środki to sieć może używać adresów IP z 16 10.254.0.32- 10.254.0.47.

Napotkałem ten sam problem

Tworzenie sieci „schemaregistry1_default” z domyślnym sterownikiem
BŁĄD: nie można znaleźć dostępnej, nienakładającej się puli adresów IPv4 wśród wartości domyślnych do przypisania do sieci

i nic nie pomogło, dopóki nie wyłączyłem Cisco VPN. po tym docker-compose działało

Naprawiłem ten problem krok po kroku:

1. wyłącz swoją sieć (bezprzewodową lub przewodową ...).

2. zrestartuj system.

3. przed włączeniem sieci na PC wykonaj polecenie docker-compose up, utworzy nową sieć.

4. wtedy możesz włączyć sieć i kontynuować ...