I deploy with project on meteor version 2.7.1 with mongo 4.0.5 and docker image: ‘zodern/meteor:root’,
But it is Connection refused
Please Any help
Hi,
That may help
Greetings,
1 Like
As @erixtekila posted the guide helps. However you will have to use mongodump to backup your data. Note that older indexes might be incompatible with those in 5.0.
I also found that importing using mongorestore required a the renaming of namespaces, see this GitHub issue:
opened 09:55PM - 11 Feb 22 UTC
<!-- Love meteor-up? Please consider supporting our collective:
👉 https://open… collective.com/meteor-up/donate -->
Mup version (`mup --version`): 1.5.5
Mup config
```js
{
"servers": {
"one": {
"host": "1.2.3.4",
"username": "root",
"password": "password"
}
},
"proxy": {
"domains": "host.com,subdomain.host.com",
"ssl": {
"letsEncryptEmail": "email@domain.com",
"forceSSL": true
}
},
"mongo": {
"version": "3.4.1",
"servers": {
"one": {}
},
"dbName": "project_name"
},
"app": {
"name": "my-app",
"path": "../project_name",
"volumes": {
"/images": "/images"
},
"servers": {
"one": {}
},
"buildOptions": {
"serverOnly": true,
"buildLocation": "/tmp/mup-meteor-46532786-03a5-4a6f-b9ab-8aac9105b59a",
"cleanBuildLocation": true
},
"env": {
"ROOT_URL": "https://host.com",
"MONGO_URL": "mongodb://mongodb:27017/my-app",
"VIRTUAL_HOST": "host.com,subdomain.host.com",
"HTTPS_METHOD": "redirect",
"LETSENCRYPT_HOST": "host.com,subdomain.host.com",
"LETSENCRYPT_EMAIL": "email@domain.com",
"VIRTUAL_PORT": 3000,
"HTTP_FORWARDED_COUNT": 1
},
"docker": {
"image": "zodern/meteor:latest",
"stopAppDuringPrepareBundle": true,
"imagePort": 3000,
"args": [
"--link=mongodb:mongodb"
]
},
"enableUploadProgressBar": true,
"type": "meteor"
}
}
```
Output of command
```bash
Started TaskList: Start Meteor
[159.203.61.14] - Start Meteor
[159.203.61.14] - Start Meteor: SUCCESS
[159.203.61.14] - Verifying Deployment
[159.203.61.14] x Verifying Deployment: FAILED
------------------------------------STDERR------------------------------------
(7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
curl: (7) Failed to connect to 172.17.0.2 port 3000: Connection refused
=> Logs:
=> Setting node version
NODE_VERSION=14.18.3
v14.18.3 is already installed.
Now using node v14.18.3 (npm v6.14.15)
default -> 14.18.3 (-> v14.18.3 *)
=> Starting meteor app on port 3000
/built_app/programs/server/node_modules/fibers/future.js:313
throw(ex);
^
MongoServerSelectionError: Server at mongodb:27017 reports maximum wire version 5, but this version of the Node.js Driver requires at least 6 (MongoDB 3.6)
at Timeout._onTimeout (/built_app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/sdam/topology.js:312:38)
at listOnTimeout (internal/timers.js:557:17)
at processTimers (internal/timers.js:500:7) {
reason: TopologyDescription {
type: 'Unknown',
servers: Map(1) {
'mongodb:27017' => ServerDescription {
_hostAddress: HostAddress { isIPv6: false, host: 'mongodb', port: 27017 },
address: 'mongodb:27017',
type: 'Unknown',
hosts: [],
passives: [],
arbiters: [],
tags: {},
minWireVersion: 0,
maxWireVersion: 0,
roundTripTime: -1,
lastUpdateTime: 51406758209,
lastWriteDate: 0,
error: MongoCompatibilityError: Server at mongodb:27017 reports maximum wire version 5, but this version of the Node.js Driver requires at least 6 (MongoDB 3.6)
at checkSupportedServer (/built_app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connect.js:62:12)
at /built_app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connect.js:106:40
at MessageStream.messageHandler (/built_app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connection.js:474:9)
at MessageStream.emit (events.js:400:28)
at processIncomingData (/built_app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/message_stream.js:108:16)
at MessageStream._write (/built_app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/message_stream.js:28:9)
at writeOrBuffer (internal/streams/writable.js:358:12)
at MessageStream.Writable.write (internal/streams/writable.js:303:10)
at Socket.ondata (internal/streams/readable.js:731:22)
at Socket.emit (events.js:400:28)
at addChunk (internal/streams/readable.js:293:12)
at readableAddChunk (internal/streams/readable.js:267:9)
at Socket.Readable.push (internal/streams/readable.js:206:10)
at TCP.onStreamRead (internal/stream_base_commons.js:188:23)
}
},
stale: false,
compatible: true,
heartbeatFrequencyMS: 10000,
localThresholdMS: 15,
logicalSessionTimeoutMinutes: undefined
}
}
=> Setting node version
NODE_VERSION=14.18.3
v14.18.3 is already installed.
Now using node v14.18.3 (npm v6.14.15)
default -> 14.18.3 (-> v14.18.3 *)
=> Starting meteor app on port 3000
=> Redeploying previous version of the app
```
james
April 26, 2022, 7:41pm
4
This is an enormous problem I have seen lately regarding the connection to mongodb, especially after upgrading the DB to Mongo 5 as recommended. You still should use the latest version of MongoDB, but I think you will have the same error. Anyways by trial and error I solved this by appending &directConnection=true to the end of the MONGO_URL and MONGO_OPLOG_URL
I use meteor up and my mup.js like code above
module.exports = {
servers: {
one: {
// TODO: set host address, username, and authentication method
host: '192.168.0.220', // Leangsrun: BMC
username: 'root',
// pem: '~/.ssh/id_rsa',
password: 'root',
// or neither for authenticate from ssh-agent
},
},
app: {
// TODO: change app name and path
// Leangsrun
name: 'new_pos', // Cement PPT,
path: '../',
volumes: {
'/data/file_uploads': '/data/file_uploads',
},
servers: {
one: {},
},
env: {
// TODO: Change to your app's url
// If you are using ssl, it needs to start with https://
// Leang Srun
// Ls Cement
ROOT_URL: 'http://192.168.0.220:4000',
MONGO_URL: 'mongodb://mongodb/new_pos',
MONGO_OPLOG_URL: 'mongodb://mongodb/local',
PORT: 4000,
},
docker: {
// change to 'abernix/meteord:base' if your app is using Meteor 1.4 - 1.5
// image: 'abernix/meteord:node-8.15.1-base', // Mr chheng usd node
image: 'zodern/meteor:root',
},
// The maximum number of seconds it will wait
// for your app to successfully start (optional, default is 60)
deployCheckWaitTime: 120,
// Show progress bar while uploading bundle to server
// You might need to disable it on CI servers
enableUploadProgressBar: true,
},
mongo: {
version: '4.0.5',
servers: {
one: {},
},
},
}
In Meteor 2.7.2 (once it comes out) you can add a setting to re-build indexes if there is issue with their settings. Though use this carefully as it might for a little bit impact performance as the indexes re-build.
See more here:
meteor:release-2.7.2
← meteor:feature/index-recreation
opened 10:33PM - 30 Mar 22 UTC
Somehow my index options have changed on a whole lot of indexes, which caused Me… teor to fail to start. Since I have promised to look into this in the past, but never got the urgency or time, this finally was an opportunity to address the following issues (at least partially):
#11666 #11750
So if there is an issue in creating a new index, now Meteor checks if it is an issue with changed options of the said index. If it is, it will re-create the index. If not, I have improved the error to provide the collection and name of the index where there is a failure, so it is easier to locate the problem.
I'm open to discussing adding a settigns key to disable this re-creation and instead thow an error. Either way I will have to do that another day, due to time constraints.