PyMongo Cant connect to MongoDB Atlas from Azure Container Instance

MongoDB Atlas
,
1

I have a simple python script that’s running on Azure Container Instance. I am trying to do an insert to MongoDB Atlas on cloud with Pymongo and i keep getting this error:

pymongo.errors.ServerSelectionTimeoutError: test-shard-00-01.tvyda.mongodb.net:27017: timed out,test-shard-00-00.tvyda.mongodb.net:27017: timed out,test-shard-00-02.tvyda.mongodb.net:27017: timed out, Timeout: 5.0s, Topology Description: <TopologyDescription id: 616838412c3f7b25d8dfc654, topology_type: ReplicaSetNoPrimary, servers: [<ServerDescription ('test-shard-00-00.tvyda.mongodb.net', 27017) server_type: Unknown, rtt: None, error=NetworkTimeout('test-shard-00-00.tvyda.mongodb.net:27017: timed out',)>, <ServerDescription ('test-shard-00-01.tvyda.mongodb.net', 27017) server_type: Unknown, rtt: None, error=NetworkTimeout('test-shard-00-01.tvyda.mongodb.net:27017: timed out',)>, <ServerDescription ('test-shard-00-02.tvyda.mongodb.net', 27017) server_type: Unknown, rtt: None, error=NetworkTimeout('test-shard-00-02.tvyda.mongodb.net:27017: timed out',)>]>

This is the code i have:

conn_str = f"mongodb+srv://{self.mongo_user}:{self.mongo_password}@{self.mongo_cluster}/{self.mongo_db}?retryWrites=true&w=majority"
db_name = self.mongo_db
collection_name = self.mongo_collection
client = pymongo.MongoClient(
conn_str, serverSelectionTimeoutMS=5000, tls=True, tlsAllowInvalidCertificates=True)
db = client[db_name]
collection = db[collection_name]

result = collection.insert_one(some_dict)

I have added the IP of the container instance to the Network Access list in MongoDB cloud.

It is working perfectly fine from Docker desktop that i run on my local machine.

I couldnt fine any solution to this. Any help is appreciated. Thanks.

Also posted on Stack Overflow: python - PyMongo Cant connect to MongoDB Atlas from Azure Container Instance - Stack Overflow

1 Like
2

I have this same issue. I was able to confirm that if I whitelist all IPs this works so I don’t think the issue is related to a firewall, but past that, I’m not sure what else to try.

3

Did you get to the bottom of this? Have you by chance reached out to Azure support about whether the public IP of the source context may be dynamic?

4

I didn’t. I swapped to AWS and that is working ok. Not perfect, but good enough that I am going to keep deploying.

1 Like
5

I want to flag this with my colleagues at Azure–can you confirm which Azure service you were using, was it https://azure.microsoft.com/en-us/services/container-instances/#features ? Also, any reason you didn’t use Private Endpoints (powered by Azure Private Link)? I wonder if those aren’t supported

6

Yeah, I was using Azure Container Instances. I don’t really know what Private Endpoints are so it’s definitely possible the problem is just me being new to full stack development and the cloud deployment process in general. (btw, I think there is a deadlink when looking for billing docs for Private endpoints) https://www.mongodb.org/dochub/core/privatelink-billing

image
image798×433 24 KB

My goal with the web application I’m currently working on is to reduce the cost when we aren’t getting traffic as much as possible. We initially had a nice development setup where we used a local mongodb server, docker-compose with our unicorn app and react app. There is also one more external service that we interact with using our backend (fastapi) service. We were able to migrate from our local mongodb server to mongodb Atlas extremely quickly (less than an hour). This was cool, but we then needed to figure out our plan for getting React running somewhere and our fastapi/uvicorn application. Having an IP we could use was important for us because the external API (smartmetertexas) required it as did mongodb (unless we opened our traffic to everybody). For hosting our React app, we found Netlify. We tested out Heroku first for the backend, but that didn’t give us enough access to a static IP, then we tried koyeb.com which was close, but just slightly too early (couldn’t give us static IP at this time). After this, I tested out Azure and AWS. Neither really worked as well as I had hoped, but I was able to get them both configured to the point they worked pretty well. Azure said I had an IP assigned, but when I tried to to whitelist it, it didn’t work. AWS was a little harder to setup, but the IP I had actually worked to whitelist. So my current setup that is working is AWS ECS using EC2 instances (tried Fargate, but would have needed a $40 load balancer to make that work).

Still working on our getting our app up and running but all of the pieces are working now more or less. Probably more than you care about here, but if you need anything else from me, let me know. I have been really happy with the serverless experience that mongodb has offered up to this point.

7

Thanks for flagging the broken docs link, we’ll get that fixed.

And thank you for this golden feedback: hearing about your journey across all these different services to get a React + MongoDB Atlas app up and running is super importnat, and we need to ensure it’s easy to use all of the above since a lot of folks might have less patience and grit than you! (As an aside, it’s cool to hear you tried Koyeb, I am in touch with that team: I will let the team know that the lack of static IP was an issue).

I wonder if the Azure public IP that was assigned was for ingress only into the frontend of the React app and not for egress to services like MongoDB Atlas: but this is pure speculation on my part. I’d love to get to the bottom of this to ensure we give the feedback to Azure but suspect you’ve moved on and don’t want to re-open that can of worms, if so I understand.

Cheers
-Andrew

8

I am definitely willing to discuss it further, but at this point, I probably won’t be shifting our stack away from AWS unless we get some really nice credits from Azure.

Also would have responded sooner, but I hit the max replies of 3 since I’m a new user. In case you get ghosted at three replies by anybody that may be why :slight_smile: I also couldn’t send a PM which was apparently by design.

9

Hi @Kevin_Bird,

Apologies for the posting speed bumps you encountered and thank you for bringing this to our attention!

There are some limits in place to try to mitigate the frequency of spammers who unfortunately create new accounts and immediately try to abuse features like sending direct messages or trying to send many messages in a short period of time. Those limits are relaxed as you spend a bit more time on the site – see trust levels for more info. We continue to monitor and adjust limits based on feedback, but spammers are a relentless source of nuisance posts.

However, the limit you ran into is a false positive which should be fixed now. This was intended to ask a brand new user to pause and wait for a reply when they have too many posts with no replies yet. Since you commented on a topic started by another user and @Andrew_Davidson replied to the topic (instead of one of your posts) this accidentally triggered the “too many posts waiting on replies” limit for your account. There should also have been a system notification you could have replied to (brand new users can’t start DMs, but can reply), but this seems to have been muted. Our community team will check into the platform behaviour and try to avoid future unnecessary speed bumps for others.

FYI, if anyone does run into any forum issues where moderator assistance is required, there are a few contact options listed in the site FAQ (aka README.1st). Contacting via the forum (flagging a post or sending a DM) would be preferable, but there’s also email backup if needed.

Regards,
Stennie