I have a microservices architecture with 6 containers. One of them is the back (a server in python with asyncio) that is running in the address 0.0.0.0:1234 -> the host is '0.0.0.0' to be public.
And I have another microservice in Node JS, it is a socket connector, it has to connect with the back in python that is running in 0.0.0.0:1234, but I can't connect.
Error:
errno: -111,
code: 'ECONNREFUSED',
Why I can't connect the two containers between each other if it supposed to have a network in common?
I connect the others microservices between each other with the public domain that provides railway, but in this case I need the host and the port to connect it through sockets.
const connectToPythonServer = () => {
client.connect({
port: 1234,
host: '0.0.0.0'
}, () => {
// client.connect(1234, '0.0.0.0', () => {
console.log('Connected al back de python, es decir al sv asincronico');
client.write('Hello, server! Love, Client.');
});
}
This is how connect my Node JS connector to the back. It is working locally, but when I took this to railway, it doesn't work. It doesn't connect. **
Related
The compilation is complete in all logs but am retrieving this error message:
"http://127.0.0.1:8080/", host: "172.31.30.177"
2022/12/01 21:42:06 [error] 32487#32487: *55 connect() failed (111: Connection refused) while connecting to upstream, client: 172.31.42.14, server: , request: "GET /.env HTTP/1.1", upstream: "http://127.0.0.1:8080/.env", host: "54.242.94.106"
Along with in my environment I am getting this response as well:
Environment health has transitioned from Degraded to Severe. 100.0 % of the requests are failing with HTTP 5xx. ELB processes are not healthy on all instances. Initialization completed 86 seconds ago and took 2 minutes. ELB health is failing or not available for all instances. Impaired services on all instances.
I am trying to host the server on aws and this is my server:
const express = require('express')
const server = express()
const PORT = process.env.PORT
const cors = require('cors')
const pizzaRouter = require('./api/pizza/pizza-router')
const toppingsRouter = require('./api/toppings/toppings-router')
server.use(express.json())
server.use(cors())
server.use('/api/pizza',pizzaRouter)
server.use('/api/toppings',toppingsRouter)
server.get('/', (req,res) => res.json({message:'This better work'}))
server.listen( PORT, () => {
console.log(`Server listening on PORT ${PORT} `)
})
// I did not assign the PORT env to any number as it has not worked for any i have assigned so far(443, 5000)
I want to deploy an IDAS (FIWARE Backend Device Manager) i.e. IOTA instance that will communicate and send data to an already existing Orion Context Broker instance running in a different virtual machine from the one hosting IDAS. Is that possible? Or is it necessary for the two services to be in the same virtual machine?
I am using an IoTAgent-JSON (I think it's 1.6.2 version) for MQTT transport.
This is the config.js file (I have already replaced the contextBroker host with the host of my Orion Context Broker, as you can see, it was "localhost" before):
var config = {};
config.mqtt = {
host: 'localhost',
port: 1883,
thinkingThingsPlugin: true
};
config.iota = {
logLevel: 'DEBUG',
timestamp: true,
contextBroker: {
host: '147.27.60.182',
port: '1026'
},
server: {
port: 4041
},
deviceRegistry: {
type: 'mongodb'
},
mongodb: {
host: 'localhost',
port: '27017',
db: 'iotagentjson'
},
types: {},
service: 'howtoService',
subservice: '/howto',
IoTA endpoints:
http://147.27.60.202:5351/iot/services
(Fiware-Service: openiot, Fiware-ServicePath: /, X-Auth-Token: [TOKEN])
http://147.27.60.202:4041/iot/devices/
(Fiware-Service: tourguide, Fiware-ServicePath: /)
My Orion Context Broker (where I want to send data) endpoint:
http://147.27.60.182:1026/v2
P.S.: I have tried to change the mongodb host, too.
Image: how the service runs
Yes, you can have Orion and one or more IOTAs running in different virtual machine. The only requirement is mutual interconnection, I mean IOTA needs access to the Orion endpoint and Orion needs access to IOTA endpoint.
Check contextBroker.url (alternatively contextBroker.host and contextBroker.port) and providerUrl IOTA configuration parameters in IOTA documentation.
I am trying to configure persistent sessions through a remote server with redis.
under sails.config.session I am configuring the following code to connect to my Server
module.exports.session = {
adapter: '#sailshq/connect-redis',
url:"redis://:pass#157.xxx.xxx.xxx:6379/0",
prefix: 'sess:',
secret: "secretSailsSessionDataHere",
cookie: {
maxAge: 1 * 60 * 60 * 1000
},
}
When I lift Sails with:
sails lift --redis or sails lift
The connection defaults to my localhost redis server. If I shutdown my local server it says connection refused from 127.0.0.1 when my server address is xxx.xxx.xxx It also spits out the following error
Redis connection manager failed unexpectedly. Details: Error: Error emitted from Redis client.
Error details:ReplyError: ERR invalid DB index
Any suggestions on how I can configure module.exports.sessions to use the remote server?
I'm new at consul and I try to setup a server-client environment. I have started my server with the following command and configuration:
consul.exe agent -ui -config-dir=P:\Consule\config
The config file looks the following ("P:\Consule\config\server.json")
{
"bootstrap": false,
"server": true,
"datacenter": "MyServices",
"data_dir": "P:\\Consule\\data",
"log_level": "INFO"
}
Output when I start consul from commandline with above command:
==> Starting Consul agent...
==> Consul agent running!
Version: 'v0.8.3'
Node ID: '1a244456-e725-44be-0549-33603ea7087d'
Node name: 'MYCOMPUTERNAMEA'
Datacenter: 'myservices'
Server: true (bootstrap: false)
Client Addr: 127.0.0.1 (HTTP: 8500, HTTPS: -1, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Gossip encrypt: false, RPC-TLS: false, TLS-Incoming: false
Atlas: <disabled>
Now, at another computer in my domain I try to run an consul client with follwoing commandline and config-file:
consul.exe agent -config-dir C:\Consul -bind=127.0.0.1
Config file ("C:\Consul\client.json")
{
"server": false,
"datacenter": "MyServices",
"data_dir": "C:\\TEMP",
"log_level": "INFO",
"start_join": ["MYCOMPUTERNAMEA"]
}
But I always get follwing output/error message:
==> Starting Consul agent...
==> Joining cluster...
==> 1 error(s) occurred:
* Failed to join <IP_OF_MYCOMPUTERNAMEA>: dial tcp <IP_OF_MYCOMPUTERNAMEA>:8301: connectex: No connection could be made because the target machine actively refused it.
Does anyone know what I'm doing wrong?
Thanks and best regards
I suppose, the reason is that your server is available only for 127.0.0.1 ip-address, which is localhost ip and available only from the same server. This can be seen here:
Client Addr: 127.0.0.1 (HTTP: 8500, HTTPS: -1, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
You have to configure your server, to make it listening all network interfaces or some specific interface, which have to be available from other server.
Try to run it with the client and advertise options set to 0.0.0.0 (or some specific ip). Read about it here and here.
And you might have to delete -bind=127.0.0.1 from the client configuration, since it might be available from the server too.
I have a simple socket.io chat application which I've uploaded to one of the new Heroku 'cedar' stacks.
Now I almost have everything working but I've hit one stumbling block. On my localhost, I open a connection to the socket server from the client with:
// lots of HTML omitted
socket = new io.Socket('localhost', {port: 8888});
But on Heroku, I obviously must substitute something else in for these values.
I can get the port from the process object on the server like so:
port = process.env.PORT || 8888
and pass that to the view.
But what do I substitute for 'localhost'?
The correct way according the article on heroku is:
io.configure(function () {
io.set("transports", ["xhr-polling"]);
io.set("polling duration", 10);
});
socket = new io.Socket();
This ensures that io.Socket won't try to use WebSockets.
I was able to get Socket.IO v0.8 to work on Heroku Cedar by doing the following:
Within the Express app (in CoffeeScript in my case):
app = express.createServer();
socket = require("socket.io")
...
io = socket.listen(app);
io.configure () ->
io.set("transports", ["xhr-polling"])
io.set("polling duration", 10)
io.sockets.on('connection', (socket) ->
socket.on('myaction', (data) ->
...
socket.emit('result', {myData: data})
### The port setting is needed by Heroku or your app won't start
port = process.env.PORT || 3000;
app.listen(port);
And within the front-facing Javascript of your application:
var socket = io.connect(window.location.hostname);
function sendSocketRequest() {
socket.emit('myaction', $("#some_field").val());
}
socket.on('result', function(data) {
console.log(data);
}
Helpful links:
Heroku Node help
Heroku Socket.IO help
This has now changed as of Oct 2013, heroku have added websocket support:
https://devcenter.heroku.com/articles/node-websockets
Use:
heroku labs:enable websockets
To enable websockets and dont forget to remove:
io.configure(function () {
io.set("transports", ["xhr-polling"]);
io.set("polling duration", 10);
});
After trying every combination under the sun I finally just left it blank. Lo and behold that works perfectly. You don't even need the port.
socket = new io.Socket();
I was also having this problem on heroku. I was able to make it work using the hostname "myapp.herokuapp.com" (or simply window.location.hostname, to work both local and in production) and setting the port to 80. I'm using SocketIO 0.6.0.
Wouldn't you just put your actual hostname?
2011-06-25T21:41:31+00:00 heroku[router]: Error H13 (Connection closed without response) -> GET appxxxx.herokuapp.com/socket.io/1/websocket/4fd434d5caad5028b1af690599f4ca8e dyno=web.1 queue= wait= service= status=503 bytes=
Does this maybe mean the heroku router infront of the app is not configured to handle web socket traffic?
[update]
It would appear as of 6/22/2011 the answer is yes... heroku does not support socket.io see this post: http://blog.heroku.com/archives/2011/6/22/the_new_heroku_2_node_js_new_http_routing_capabilities/