Esto se debe a hostname sin resolver del host de Docker. En Docker, las instancias mongo1 , mongo2 y mongo3 son accesibles por esos nombres. Sin embargo, estos nombres no son accesibles desde el host de Docker. Esto es evidente por esta línea:
Addr: mongo2:27017, Type: Unknown, State: Connected, Average RTT: 0, Last error: dial tcp: lookup mongo2: no such host
El controlador MongoDB intentará server discovery de un miembro(s) del conjunto de réplica dado(s); encontrará todos los demás nodos dentro del conjunto de réplicas (a través de rs.conf
). El problema aquí es que el conjunto de réplicas se establece con el nombre mongo<N> , el controlador (ejecutado en el host de Docker) no podría resolver estos nombres. Puede confirmar esto intentando hacer ping a mongo1 del host de Docker.
Puede intentar ejecutar la aplicación desde otra instancia de Docker que comparta la misma red de Docker que el conjunto de réplicas. O bien, modifique la red de Docker como tal para permitir nombres de host resolubles.
ACTUALIZAR:
Con respecto a su comentario sobre por qué usar mongo shell, o PyMongo obras.
Esto se debe a la diferencia en el modo de conexión. Al especificar un solo nodo, es decir, mongodb://node1:27017 en shell o PyMongo, no se realizan descubrimientos de servidores. En su lugar, intentará conectarse a ese único nodo (no como parte de un conjunto de réplicas). El problema es que debe conectarse al nodo principal del conjunto de réplicas para escribir (debe saber cuál). Si desea conectarse como un conjunto de réplicas, debe definir el nombre del conjunto de réplicas.
A diferencia del mongo-go-driver , de forma predeterminada, realizaría la detección del servidor e intentaría conectarse como un conjunto de réplicas. Si desea conectarse como un solo nodo, debe especificar connect=direct en la URI de conexión. Consulte también Ejemplo de conexión directa
