Why do I get an "message len 1347703880 is invalid. Min 16 Max: 48000000" error when trying to connect to an OKD pod running a simple mongo container? - mongodb

I have created a Mongo container using only the base mongo:3.6.4 official docker image and deployed it to my OpenShift OKD cluster, but cannot connect to this MongoDB instance using a Mongo client from outside the cluster.
I can access the pod at http://mongodb.my.domain and successfully get the "It looks like you are trying to access MongoDB over HTTP on the native driver port." message.
When using the terminal on the pod I can successfully log-in using:
mongo "mongodb://mongoadmin:pass#localhost" --authenticationDatabase admin
But when trying to connect from outside OKD the connection fails.
My client needs to pass through a proxy before it can access the OKD pods and I do have a .der certificate file but am unsure if this is related to the issue.
Some commands I have tried:
mongo "mongodb://mongoadmin:pass#mongodb.my.domain:80" --authenticationDatabase admin
mongo --ssl "mongodb://mongoadmin:pass#mongodb.my.domain:80" --authenticationDatabase admin
I expected to be able to connect successfully but instead get this error message:
MongoDB shell version v3.4.20
connecting to: mongodb://mongoadmin:pass#mongodb.my.domain:80
2019-05-15T11:32:25.514+0100 I NETWORK [thread1] recv(): message len 1347703880 is invalid. Min 16 Max: 48000000
2019-05-15T11:32:25.514+0100 E QUERY [thread1] Error: network error while attempting to run command 'isMaster' on host 'mongodb.my.domain:80' :
connect#src/mongo/shell/mongo.js:240:13
#(connect):1:6
exception: connect failed
I am unsure if it an issue with how I am using my MongoDB client or potentially some proxy settings on my OKD cluster. Any help would be appreciated.

The problem here is that external OpenShift routes aren't great at handling database connections. When you attempt to connect to the Mongo pod via the route, the route will accept the connection and transmit your connection to the Mongo service. I believe this transmission wraps the connection in in a HTTP wrapper, which Mongo doesn't like to handle. The OKD documentation highlights that path based route traffic should be HTTP based, which will cause the connection to fail.
You can see evidence of this when trying to connect to a MongoDB database and it returns "It looks like you are trying to access MongoDB over HTTP on the native driver port." to the browser. The user relief.malone explains this and has proposed a couple of solutions / workarounds in their answer to this question.
To add to relief.malone's answer, I would suggest that you port forward from the MongoDB pod to your local machine for development/debugging. In production, you could deploy an application to OKD that references the MongoDB service via it's internal DNS name, which will look something like this: mongodb.project_namespace.svc:27017. This way you will avoid the route interfering with the connection.
The Openshift OKD documentation on port-forwarding isn't that informative, but, since oc runs the kubectl command under the hood, you can read this Kubernetes guide to get some more information

Related

Connect PostgreSQL to rabbitMQ

I'm trying to get RabbitMQ to monitor a postgresql database to create a message queue when database rows are updated. The eventual plan is to feed this message queue into an AWS EKS (Elastic Kubernetes Service) cluster as a job.
I've read many many approaches to this but they are still confusing as a newcomer to RabbitMQ and many seemed to be written more than 5 years ago so I'm not sure if they'll still work with current versions of postgres and rabbitmq.
I've followed this guide about installing the area51/notify-rabbit docker container which can connect the two via a node app, but when I ran the docker container it immediately stopped and didn't seem to do anything.
There is also this guide, which uses a go app to connect the two, but I'd rather not use Go ouside of a docker container.
Additionally, there is also this method, to install the pg_amqp extension from a repository which hasn't been updated in years, which allows for a direct connection from PostgreSQL to RabbitMQ. However, when I followed this and attempted to install pg_amqp on my Postgres db (postgresql 12), I was unable to connect using psql to the database, getting the classic error:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
My current set-up, is I have a rabbitMQ server installed in a docker container in an AWS EC2 instance which I can access via the internet. I ran the following to install and run it:
docker pull rabbitmq:3-management
docker run --rm -p 15672:15672 -p 5672:5672 rabbitmq:3-management
The postgresql database is running on a separate EC2 instance and both instances have the required ports open for accessing data from each server.
I have also looked into using Amazon SQS as well for this, but it didn't seem to have any info on linking Postgresql up to it. I haven't really seen any guides or Stack Overflow questions on this since 2017/18 so I'm wondering if this is still the best way to create a message broker for a kubernetes system? Any help/pointers on this much appreciated.
In the end, I decided the best thing to do was create some simple Python scripts to do the LISTEN/NOTIFY steps and route traffic from PostgreSQL to RabbitMQ based off the following code https://gist.github.com/kissgyorgy/beccba1291de962702ea9c237a900c79
I set it up inside Docker containers and set them to run in my Kubernetes cluster so they are within the automatic restarts if they fail.

Mongo Shell/Compass won't connect to mongodb container

I'm using Docker (running on WSL) and I have a MongoDB container running. Using mongo shell on my host I can connect to the instance, but I can't authenticate. I also get an authentication error when I try to go through MongoDB Compass, below is the error I keep getting. I've installed saslprep globally via npm on my host machine, but that didn't fix the problem either. Any help would be greatly appreciated!
> db.auth('admin-root', 'test')
Warning: no saslprep library specified. Passwords will not be sanitized
MongoError: Authentication failed.

Why am I getting "unsupported network unix" with Cloud SQL Proxy, when I'm specifying TCP?

I'm having issues when trying to connect to my Cloud SQL instance. I created a SQL Server instance, downloaded the cloud sql proxy, and everything seems to start to connect, but I keep getting the following error:
errors parsing config:
invalid "instance-connection-name": unsupported network: unix
I'm specifying the tcp port to use, but it still complains about UNIX. Here is the command I'm using when trying to connect (I replaced the actual instance connection name for privacy/security):
./cloud_sql_proxy.exe -instances=[instance-connection-name]=tcp:3306
Any help would be appreciated.
Thanks!
I tried this and it works
Rename cloud_sql_proxy_xxx to cloud_sql_proxy
Open cmd in your cloud_sql_proxy's location
Run the following command: cloud_sql_proxy -instances=[project:region:instance-name]=tcp:1433 without [ ]
From Connecting to a Cloud SQL for SQL Server using a Cloud SQL Proxy:
Depending on your language and environment, you can start the proxy using either TCP sockets or Unix sockets.
TCP sockets:
Copy your instance connection name from the Instance details page
For example: myproject:us-central1:myinstance.
If you are using a service account to authenticate the proxy, note the location on your client machine of the private key file that was created when you created the service account.
Start the proxy.
Some possible proxy invocation strings:
a) Using Cloud SDK authentication:
./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:1433
The specified port must not already be in use, for example, by a local database server.
b) Using a service account and explicit instance specification (recommended for production environments):
./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:1433 \
-credential_file=<PATH_TO_KEY_FILE> &

Tyk dashboard app - Couldn't establish a connection with Mongo: no reachable servers

I am trying to set up a Tyk dashboard Docker container for an API gateway. There is a configuration file that is used by Tyk to, among other things, connect to a Redis, and Mongo using JSON. I set up a MongoDB cluster using MongoDB Atlas. I took the connection string, and put it into the Tyk config JSON for the "mongo_url" key.
mongodb://<username>:<password>#cluster0-shard-00-00-to2hv.mongodb.net:27017,cluster0-shard-00-01-to2hv.mongodb.net:27017,cluster0-shard-00-02-to2hv.mongodb.net:27017/admin
I can successfully connect to my NoSQL cluster using the MongoDB Compass app, but when I try to run the Tyk Dashboard container, I get an error
time="Nov 7 20:12:09" level=info msg="connecting to MongoDB:
[cluster0-shard-00-00-to2hv.mongodb.net:27017
cluster0-shard-00-01-to2hv.mongodb.net:27017
cluster0-shard-00-02-to2hv.mongodb.net:27017]"
time="Nov 7 20:12:21"
level=fatal msg="Couldn't establish a connection with Mongo: no
reachable servers"
Has anyone ever run into this issue before?
I believe for Atlas you need an ssl connection, have you set "mongo-use_ssl":true in the tyk_analytics.conf?

Error when using mongoose.connect on AWS EC2 server

I've installed Node, express, and mongodb all successfully. I can run mongo in my terminal and it starts correctly. I can also see data i've manually stored.
Locally, I was using mongoose.connect('mongodb://localhost:27017/test'); and I had no issues. On my EC2 I used mongoose.connect('mongodb://ipaddress:27017/test'); but it's failing.
Error: failed to connect to [ipaddress:27017].
ipaddress is an actual ip address not a string or variable.
mongo
show dbs <-- this shows my databases so I know it's running!
I've looked online for a few hours and have come up short! I'm sure it's a simple setting i've missed.
On my EC2 i'm allowing all connections on all port ranges.
What am I missing?
Thanks!
Since the mongod instance is running on the same server, you need to set the IP Address to 0.0.0.0
I'm not sure why this needs to be done, but I got (some) understanding by reading the explanations listed on this post.