Wynika to z nierozwiązanej hostname z hosta platformy Docker. W Dockerze instancje mongo1 , mongo2 i mongo3 są osiągalne pod tymi nazwami. Jednak te nazwy nie są osiągalne z hosta platformy Docker. Widać to po tym wierszu:
Addr: mongo2:27017, Type: Unknown, State: Connected, Average RTT: 0, Last error: dial tcp: lookup mongo2: no such host
Sterownik MongoDB podejmie próbę server discovery z danego elementu(ów) zestawu replik; znajdzie wszystkie inne węzły w zestawie replik (poprzez rs.conf
). Problem polega na tym, że zestaw replik jest ustawiony na nazwę mongo<N> , sterownik (uruchomiony na hoście platformy Docker) nie będzie w stanie rozpoznać tych nazw. Możesz to potwierdzić, próbując pingować mongo1 z hosta platformy Docker.
Możesz spróbować uruchomić aplikację z innej instancji platformy Docker współdzielącej tę samą sieć platformy Docker co zestaw replik. Lub zmodyfikuj sieć platformy Docker jako taką, aby zezwolić na rozpoznawalne nazwy hostów.
AKTUALIZACJA:
Jeśli chodzi o Twój komentarz, dlaczego używasz mongo powłoka lub PyMongo Pracuje.
Wynika to z różnicy w trybie połączenia. Podczas określania pojedynczego węzła, tj. mongodb://node1:27017 w powłoce lub PyMongo nie dokonuje się wykrywania serwerów. Zamiast tego spróbuje połączyć się z tym pojedynczym węzłem (nie jako część zestawu replik). Połów polega na tym, że musisz połączyć się z podstawowym węzłem zestawu replik, aby pisać (musisz wiedzieć, który z nich). Jeśli chcesz połączyć się jako zestaw replik, musisz zdefiniować nazwę zestawu replik.
W przeciwieństwie do mongo-go-driver , domyślnie przeprowadza wykrywanie serwera i próbuje połączyć się jako zestaw replik. Jeśli chcesz połączyć się jako pojedynczy węzeł, musisz określić connect=direct w identyfikatorze URI połączenia. Zobacz też Przykład Connect Direct
