I just setup a MongoDB instance to be running in EC2 using the Bitnami MEAN stack. I am trying to connect to the MongoDB instance in my node application, but I don't know what the URL path would be.
I am familiar with paths that look like this:
mongodb://username:password#candidate.37.mongolayer.com:port/database
But am unclear how I would figure out what the equivalent path is for my EC2 instance. I found that there is a mongodb-27017.sock file in one of the directories, but the below didn't work.
mongodb://{USERNAME}:{PASSWORD}#{EC2LINK}/stack/mongodb/tmp/mongodb-27017.sock/{DATABASENAME}
Is there any way to figure out what the path is?
Make sure mongo service is running: service mongod status
Make sure the port is open in the security group. (mongo defaults to 27017)
Use this connection URL (same as you're used to): mongodb://{USERNAME}:{PASSWORD}#{EC2 INSTANCE IP / HOSTNAME}/{DATABASENAME} . See Examples
Note: changing the port would require specifying it in the connection string.
Thanks for the help Reut, your suggestions helped me to narrow things down. (I wasn't completely off track).
I finally figured out that my issue was I needed to change the bind_ip config variable in my mongodb.conf file. The bind_IP variable was set (by default) to 127.0.0.1. This prevents remote connections from making their way to the db.
I've since changed that to 0.0.0.0 to allow remote connections.
Related
I haven't created an account in fastcomet yet, but I would like to ask the following questions. The site mentions that it supports node.js applications. So that means I can upload an express application right? How about MongoDB and mongoose? I can access MongoDB by typing in the terminal
$ mongod --dbpath=data -bind_ip 127.0.0.1
And the MongoDB URL in my case is
mongodb://localhost:27017/ilovearisti
How different would it be in fastcommet? I guess I'll have to contact them for the port numbers right?
Thanks,
Theo.
FastComet Team here! Indeed, our hosting plans are fully compatible with Node.js apps and you can have your project hosted on an appropriate package.
If you plan using the MongoDB database type in particular, our experience shows it requires a server solution with more resources and a higher level of private access. This way you would be able to accommodate the operation on an environment suitable for coding with Mongoose on top of the MongoDB driver for Node.js.
As for addressing your URL query, the default IP when starting a mongo instance is set to 127.0.0.1, so it is configured as localhost and port 27017. With this in mind, you only need to make changes on the IP configuration via the mongod daemon if you are using a remote database setup with a different IP address.
Having said all of the above, we can confirm that if you have created a database called iloveiristi, the MongoDB URL will be as follows:
mongodb://localhost:27017/iloveiristi
We hope this information proves useful and we wish you good luck with your project.
Best regards!
I'm seeing a problem I can't explain at all:
After upgrading a Meteor app to v 1.9 and therefore Node.js 12 we also have to switch docker containers to Node.js 12 based containers. In our case we use abernix/meteord:node-12-base (git).
After booting up the updated app we get a DB timeout in the docker container of the app:
/bundle/bundle/programs/server/node_modules/fibers/future.js:313
throw(ex);
^
MongoTimeoutError: Server selection timed out after 10000 ms
at Timeout._onTimeout (/bundle/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/sdam/topology.js:773:16)
at listOnTimeout (internal/timers.js:531:17)
at processTimers (internal/timers.js:475:7) {
name: 'MongoTimeoutError',
[Symbol(mongoErrorContextSymbol)]: {}
}
This happens with the following MONGO_URL:
❌ mongodb://root:OurPw#mongo-docker-alias:27017/meteor?authSource=admin
Funnily enough when we expose the port 27017 in the MongoDB container the following MONGO_URL just works:
✔️ mongodb://root:OurPw#docker-host:27017/meteor?authSource=admin
Now I thought we are having a docker problem but if I attach to a bash inside the Node.js 12 meteord container, apt install the MongoDB shell and try to connect with:
✔️ mongo "mongodb://root:OurPw#mongo-docker-alias:27017/meteor?authSource=admin"
that also just works.
And now I'm left without a clue. I tried multiple MongoDB docker images between v4.0 and 4.2.3 as well as Node.js 12.14 and 12.10. And I also tried without MongoDB auth one time just to rule it out as the problem but the outcome is always the same.
Any idea would be very much appreciated since I'd like to avoid having to connect via an exposed port and the docker host's name because that is prone to errors obviously...
Check the /etc/mOngd.conf file for the network binding. You may need to allow it to respond on all network interfaces as the network might be a different ip/subnet when exposed (or not) which might explain why it works in some scenarios
tl;dr:
setting dns_search: '' for the backend in the docker-compose.yml (or via the docker CLI or other means) fixes the problem.
More information:
Docker seems to add any search directive of the host's /etc/resolv.conf to the container's /etc/resolv.conf per default. However resolving something like mongo-docker-alias.actual-intranet-domain.tld is likely to be problematic since the outside network and DNS has no knowledge of this subdomain. Actually we found out that it got still resolved inside the container in our case, it just took a few seconds (vs <1ms normally). And since the backend tries to establish multiple DB connection it always runs into the timeout.
Docker's DNS search option luckily allows to divert from the default behavior including setting a blank value. Knowing the problem another workaround should be to use docker aliases with a dot in it since then the search shouldn't be used, but we haven't tried that.
A few questions remain but they are not so important. Like in our case why did this happen with the Meteor update, maybe the actual reason was that also the docker version on the host changed since we wouldn't be aware of an infrastructure change. And in general why is docker adding these entries to /etc/resolv.conf? It doesn't seem very useful but if it is maybe there is in general a better approach for this?
A very helpful blog post on this matter was also published by davd.io.
I'm trying to set up both Confluence and PostgreSQL in Docker. I've got them both up and running on my fully up to date CentOS 6 machine, with volume-mapping to the host file system so I can back them up easily. I can connect to PostgreSQL using pgAdmin from another machine just fine, and I can get into Confluence from a browser from that same machine. So, basically, both apps seem to be running as expected inside their respective containers and are accessible to the outside world, which of course eliminates a whole bunch of possibilities for my issue.
And that issue is that Confluence can't talk to PostgreSQL during initial setup, which is necessary for it to function. I'm getting connection failed errors (to be specific: "Can't reach database server or port : SQLState - 08001 org.postgresql.util.PSQLException: The connection attempt failed").
PostgreSQL is using the default 5432 port, which of course is exposed, otherwise I wouldn't be able to connect to it via pgAdmin, and of course I know the ID/password I'm trying is correct for the same reason (and besides, if it was an auth problem I wouldn't expect to see this error message). When I try to configure the database connection during Confluence's initial setup, I specify the IP address of the host machine, just like from pgAdmin on the other machine, but that doesn't work. I also tried some things that I basically knew wouldn't work (0.0.0.0, 127.0.0.1 and localhost).
I'm not sure what I need to do to make this work. Is there maybe some special method to specify the IP to a container from the same host machine, some nomenclature I'm not aware of?
At this point, I'm "okay" with Docker in terms of basic operations, but I'm far from an expert, so I'm a bit lost. I'm also not a big-time *nix user generally, though I can usually fumble my way through most things... but any hints would be greatly appreciated because I'm at a loss right now otherwise.
Thanks,
Frank
EDIT 1: As requested by someone below, here's my pg_hba.conf file, minus comments:
local all all trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
host all all all md5
try changing the second line of the pg_hba.conf file to the following:
host all all 0.0.0.0/32 trust
this will cause PostgreSQL to start accepting calls from any source address. Since a docker container is technically not operating on localhost but on its own ip, the current configuration causes PostgreSQL to block any connections to it.
Also check if confluence is searching for the database on localhost. If that is the case change that to the ip of the hostmachine within the docker network.
Success! The solution was to create a custom network and then use the image name in the connection string to PostreSQL container from Confluence container. In other words, I ran this:
docker network create -d bridge docker-net
Then, on both of the docker run commands for the PostgreSQL and Confluence containers, I added:
--network=docker-net
That way, when I ran through the Confluence configuration wizard, when it asked for the hostname for the PostgreSQL server, I used postgres (the name I gave the container) rather than an IP address or actual hostname. Docker makes that work thanks to the custom network. This also leaves the containers available via the IP of the host machine, so for example I can still connect to PostgreSQL via 192.168.123.12:5432, and of course I can launch Confluence in the browser via 192.168.123.12:8080.
FYI, I didn't even have to alter the pg_hba.conf file, I just used the official PostgreSQL image (latest) as it was, which is ideal.
Thanks very much to RSloeserwij for the suggestions... while none of them proved to be the solution I needed, they did put me on the right track in the Docker docs, which, after some reading, led me to understand a few things I didn't before and figure out the config magic I needed.
After I loaded the couch database and confirmed connecting localhost with port 5984. I want to access this web console in other computer. But It doesn't work. I changed every other ports and checked the firewall. But those didn't have any problems. Is there anybody got same experience?
Thanks in advanced.
Another question,
For changing the web port in local.ini and killed the previous loading application, but why does the previous one alive? Is there any command to unload/stop the application? I can't find the command in bin directory.
Change the parameter bind_address in the config from 127.0.0.1 (accessible from localhost only) to 0.0.0.0.
I have a web server that runs MongoDB. It will save some data that I need a second application installed in a different computer to be able to query on. The server with MongoDB is an Ubuntu, it will use Meteor (currently I'm just doing some tests, so I only have the MongoDB installed) and the other application is a NodeJS script with MongooseJS.
What should I do to setup that instance of MongoDB to be reachable from remote applications?
I'm actually finding it quite hard to understand and find information on the web. I tried
var connection = GLOBAL.database.host;
mongodb.connect('mongodb://'+GLOBAL.database.host);
But it's throwing an error Failed to connect to.... :27017
The host is a virtual machine on Koding that I set up to run these tests. How can I make sure Mongo is accessible and how can I ping it to see if the mongo is responding my requests?
By default MongoDB is restricted to allow connections only from 127.0.0.1 .
The configuration file of mongo is placed in /etc/mongod.conf. In that file you can find the following two lines:
# Listen to local interface only. Comment out to listen on all interfaces.
bind_ip = 127.0.0.1
Follow the instructions and go on commenting the bind_ip line (use the # symbol). Restart MongoDB and try again.
Make sure that you can reach your server to port 27017 (is the port that MongoDB uses). You'll have to allow it in your server if you have something like iptables or allow it in any firewall you may have.