Różnica między linkami i zależy od w docker_compose.yml

Zgodnie z dokumentacją pliku Docker Compose :

• depends_on - Wyraźna zależność między usługami.
• links- Łącz do kontenerów w innej usłudze, a także wyrażaj zależność między usługami w taki sam sposób, jak depend_on .

Nie rozumiem celu łączenia z innymi kontenerami, więc różnica między dwiema opcjami wciąż wydaje mi się dość trudna.

Byłoby o wiele łatwiej, gdyby istniał przykład, ale nie mogę go znaleźć.

Zauważyłem, że kiedy połączę pojemnik B z pojemnikiem A, wówczas pojemnik B będzie „możliwy do pingowania” w powłoce pojemnika A.

Wbiegłem ping Bdo kontenera A bashi uzyskałem taki wynik (tylko w celach informacyjnych, obraz z Internetu)

Wpis wymaga aktualizacji po linkswycofaniu opcji.

Zasadniczo linksnie jest już potrzebny, ponieważ jego główny cel - udostępnienie kontenera innym przez dodanie zmiennej środowiskowej - jest domyślnie dołączony do network. Gdy kontenery są umieszczone w tej samej sieci, są one dostępne dla siebie nawzajem, używając nazwy kontenera i innego aliasu jako hosta.

Na docker run, --linkjest również przestarzała i powinna zostać zastąpiona przez sieć niestandardowej.

docker network create mynet
docker run -d --net mynet --name container1 my_image
docker run -it --net mynet --name container1 another_image

depends_onwyraża kolejność początkową (i domyślnie kolejność ciągnięcia obrazu), co było dobrym efektem ubocznym links.

Ta odpowiedź dotyczy wersji 2 dokera i działa również w wersji 3

Nadal możesz uzyskać dostęp do danych, gdy używasz zależy_on.

Jeśli spojrzysz na dokery Docker Compose i Django , nadal możesz uzyskać dostęp do bazy danych w następujący sposób:

version: '2'
services:
  db:
    image: postgres
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    depends_on:
      - db

Jaka jest różnica między linkami i zależy od opcji?

spinki do mankietów:

Podczas tworzenia kontenera dla bazy danych, na przykład:

docker run -d --name=test-mysql --env="MYSQL_ROOT_PASSWORD=mypassword" -P mysql

docker inspect d54cf8a0fb98 |grep HostPort

I możesz znaleźć

"HostPort": "32777"

Oznacza to, że możesz podłączyć bazę danych z lokalnego portu hosta 32777 (3306 w kontenerze), ale ten port będzie się zmieniać za każdym razem, gdy ponownie uruchomisz lub usuniesz kontener. Możesz więc użyć łączy, aby mieć pewność, że zawsze będziesz się łączyć z bazą danych i nie musisz wiedzieć, który to port.

web:
  links:
   - db

zależy od:

Znalazłem fajnego bloga od Giorgio Ferraris Docker-compose.yml: od V1 do V2

Kiedy docker-compose wykonuje pliki V2, automatycznie buduje sieć między wszystkimi kontenerami zdefiniowanymi w pliku, a każdy kontener będzie mógł natychmiast odwoływać się do innych tylko przy użyciu nazw zdefiniowanych w pliku docker-compose.yml.

I

Więc nie potrzebujemy już linków; linki zostały użyte do rozpoczęcia komunikacji sieciowej między naszym kontenerem db a kontenerem serwera WWW, ale jest to już zrobione przez docker-compose

Aktualizacja

zależy od

Wyraźna zależność między usługami, która ma dwa efekty:

• docker-compose upuruchomi usługi w kolejności zależności. W poniższym przykładzie db i redis zostaną uruchomione przed uruchomieniem sieci.
• docker-compose up SERVICEautomatycznie uwzględni zależności SERVICE. W poniższym przykładzie web-docker-compose up również utworzy i uruchomi db i redis.

Prosty przykład:

version: '2'
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

Uwaga: depend_on nie będzie czekał, aż db i redis będą „gotowe” przed uruchomieniem sieci - tylko do momentu ich uruchomienia. Jeśli musisz poczekać na gotowość usługi, zobacz Kontrolowanie kolejności uruchamiania, aby uzyskać więcej informacji na temat tego problemu i strategii jego rozwiązywania.

[Aktualizacja września 2016 r.]: Ta odpowiedź była przeznaczona dla skomponowanego pliku dokera v1 (jak pokazano w przykładowym pliku do komponowania poniżej). W przypadku wersji 2 zobacz inną odpowiedź autorstwa @Windsooon.

[Oryginalna odpowiedź]:

Jest to dość jasne w dokumentacji. depends_ondecyduje o zależności i kolejności tworzenia kontenerów, i to linksnie tylko, ale także

Kontenery dla połączonej usługi będą dostępne pod nazwą hosta identyczną z aliasem lub nazwą usługi, jeśli nie określono aliasu.

Na przykład zakładając następujący docker-compose.ymlplik:

web:
  image: example/my_web_app:latest
  links:
    - db
    - cache

db:
  image: postgres:latest

cache:
  image: redis:latest

Dzięki linkskodowi wewnątrz webbędzie można uzyskać dostęp do bazy danych przy użyciu db:5432, zakładając, że port 5432 jest widoczny na dbobrazie. Gdyby depends_onzostały użyte, nie byłoby to możliwe, ale kolejność uruchamiania kontenerów byłaby prawidłowa.