Error at master node trying to connect to remote jmter slave node in same network
You need to ensure that at least port 1099 is open, check out How to open ports to a virtual machine with the Azure portal article for more details.
Apart from port 1099 you need to open:
The port you specify as the server.rmi.localport on slaves
The port you specify as the client.rmi.localport on master
More information:
Remote hosts and RMI configuration
JMeter Distributed Testing with Docker
JMeter Remote Testing: Using a different port
Related
I'm running a webpack-dev-server application inside a Docker container (node:4.2.1). If I try to connect to the server port from within the container - it works fine. However, trying to connect it from the host computer results in reset connection (the port is published, of course). How can I fix it?
This issue is not a docker problem.
Add --host=0.0.0.0 to your webpack command.
You need to connect to your page like this:
http://host:port/webpack-dev-server/index.html
Look to the iframe mode
You need to make sure:
you docker container has mapped the EXPOSE'd port to a host port
docker run -p x:y
your VM (if you are using docker machine with a VM) has forwarded that mapped port to the actual host (the host of the VM).
See "How to access tomcat running in docker container from browser?"
Running a NodeJS Docker Container on an EC2 instance, I'm trying to remote debug it, but keep getting "connection refused" from the instance.
What I've tried -
Opening ports in EC2 security groups
Exposing ports in Dockerfile, both the port the app is listening on and the debug port
Forwarding the port within the Docker run command using the -p flag
Making sure the app is accessible directly through the port it's configured to listen to
After trying all of these, the debug port is still inaccessible by the remote debugger or even telnet.
Any ideas what could cause this?
I'm using somata as my microservices platform for the web apps I'm building. I have successfully set up multiple clients on one machine with the somata registry running on the same machine. Now I want to have a client on one machine connect to a registry on another machine. How do I connect a client to a remote registry?
The simplest way is to use the environment variables SOMATA_REGISTRY_HOST (default "127.0.0.1") and SOMATA_REGISTRY_PORT (default 8420) when running your script:
SOMATA_REGISTRY_HOST=55.44.33.21 node test.js
The somata Client constructor also lets you connect to specific registries with the options registry_host and registry_port:
var client = new somata.Client({
registry_host: '55.44.33.21',
registry_port: 5858
})
Note: To allow connections from remote hosts, somata-registry will have to be run with its binding port as "0.0.0.0" instead of the default "127.0.0.1", which can be accomplished with the -h flag or SOMATA_REGISTRY_BIND_HOST environment variable when starting the registry. The -p flag and SOMATA_REGISTRY_BIND_PORT are also available for listening on a custom port.
somata-registry -h 0.0.0.0
or
SOMATA_REGISTRY_BIND_HOST=0.0.0.0 somata-registry
And of course you'll need access to the host and port from the remote machine.
My environment:
Master:
Azure VM running Ubuntu 14.10
Docker (1.9) running Jenkins Image
I have added port 8080 (for UI) and 50000 (for slave) as endpoints on the Azure VM.
Slave:
Windows 10 (running on Mac via BootCamp)
Configured the firewall to allow inbound and outbound traffic on port 50000 (that slave jnlp seems to be using).
I can access my Jenkins Master install over the web. I am trying to configure the slave on my Windows 10 m/c. I have tried all 3 methods to configure the slave.
Each time after several retries, the slave throws the "Connection Refused" error (screenshot attached).
Slave Error Screenshot
Can someone help point me in the right direction? I have little knowledge of Linux systems but proficient with Windows.
I have tried the workaround here but it hasn't worked for me.
There's three things that I think you can check here:
Check that you expose port 50000 on your Jenkins docker container. Check for the Dockerfile, there must be a clause EXPOSE 5000 or something. Or when you run your container run it with something like this: docker run -it -p 50000:50000 which maps local post 50000 to the containers port 50000.
Check that you don't have any security rules on Azure blocking port 50000 to your Azure VM. Don't know about Azure but in AWS you allow port 50000 in your security group(s).
Check your Azure VM's firewall. Is it Windows? Check the firewall and allow port 50000. Is it Linux ? Check iptables and allow port 50000.
Hope it helps.
I have a Spark-master running in a Docker container which in turn is executed on a remote server. Next to the Spark-master there are containers running Spark-slave on the same Docker Host.
Server <---> Docker Host <---> Docker Container
In order to let the slaves find the master, I set a master hostname in Docker SPARKMASTER which the slaves use to connect to the master. So far, so good.
I use the SPARK_MASTER_IP environment variable to let the master bind to that name.
I also exposed the Spark port 7077 to the Docker host and forwarded this port on the physical server host. The port is open and available.
Now on my machine I can connect to the Server using its IP, say 192.168.1.100. When my Spark program connects to the server on port 7077 I get a connection, which is disassociated by the master:
15/10/09 17:13:47 INFO AppClient$ClientEndpoint: Connecting to master spark://192.168.1.100:7077...
15/10/09 17:13:47 WARN ReliableDeliverySupervisor: Association with remote system [akka.tcp://sparkMaster#192.168.1.100:7077] has failed, address is now gated for [5000] ms. Reason: [Disassociated]
I already learned that the reason for this disconnection is that the host IP 192.168.1.100 doesn't match the hostname SPARKMASTER.
I could add a host to my /etc/hosts file which would probably work. But I don't want to do that. Is there a way I can completely disable this check for hostname equality?