I'm running vagrant/ubuntu 16.04 on mac os high sierra. I have set port forwarding and symlink to awesome.local.com. Basic node.js web app works perfectly and can be viewed on mac chrome browser pointing to awesome.local.com:3000
I want to develop firebase in this environment the same way, and was able to set-up the CLI and logged in fine.
Going through the Firebase Web Codelab: https://codelabs.developers.google.com/codelabs/firebase-web/index.html?index=..%2F..%2Findex#0
When running
$ firebase serve
Looks like everything is running without error (I did debug):
hosting: Local server: http://localhost:5000
When I go to the browser and point to awesome.local.com:5000 I get:
This site can’t be reached
awesome.locl.com refused to connect.
Search Google for awesome.local.com:5000
ERR_CONNECTION_REFUSED
I've tried:
rebuilt dev environment
reinstalling everything
other tutorials
Thanks for any help with this.
If you want to run firebase serve against a different host and port, see the help in the CLI:
$ firebase serve --help
Usage: serve [options]
start a local server for your static assets
Options:
-p, --port <port> the port on which to listen (default: 5000) (default: 5000)
-o, --host <host> the host on which to listen (default: localhost) (default: localhost)
--only <targets> only serve specified targets (valid targets are: functions, hosting)
--except <targets> serve all except specified targets (valid targets are: functions, hosting)
-h, --help output usage information
You can change the host and port it listens to with -p and -o. The default will only bind to localhost, which will not be accessible to anything other than 127.0.0.1.
Related
I'm a newbie to Nginx. I cannot access my Node.js application that I deploy on AWS EC2 using Nginx reverse proxy. If I do curl http://localhost:3000 I can see the application is running successfully on the server(I'm using pm2 for running node server). But when I try to access it in my browser or postman using public DNS I get the error This site can't be reached and the request gets timeout. Here's my Nginx configuration (I have followed a number of tutorials for this)
The configuration file is named nginx.conf and is in /etc/nginx/sites-enabled directory. If I do sudo nginx -t it says syntax is ok and the test is successful. Also I can see the Nginx is running using command sudo systemctl status nginx What could be the possible reason for this behaviour?
I figured it out the problem wasn't with the Nginx configuration actually I needed to allow public access for port 80 on my ec2 instance which is blocked by default. I allowed port 80 and everything is working fine. This blog helped me. Visit it for me details on how to enable port 80 for your ec2 instance.
I have install firebase cli etcetc. I can start the project and develop using firebase serve. I can visit the page of the project through localhost:5000 but if i try from different device in my network (mobile phone) to access network-ip:5000 I get connection refused.
Anyone knows what configuration/command it needs to forward port 5000 ? (different projects like creat-react-app works fine)
firebase serve -o 0.0.0.0
The -o flag sets the host.
For more information, see Server Fault: What's the difference between IP address 0.0.0.0 and 127.0.0.1?
With a local IP 192.168.0.10
I launched firebase serve -o 192.168.0.10 and it works perfectly on port 5000 from other device
In my javascript app :
functions.useFunctionsEmulator('http://192.168.0.10:5000')
If you run firebase serve --help, it will give you the information needed to listen on a different port or IP address:
Usage: serve [options]
start a local server for your static assets
Options:
-p, --port <port> the port on which to listen (default: 5000) (default: 5000)
-o, --host <host> the host on which to listen (default: localhost) (default: localhost)
--only <targets> only serve specified targets (valid targets are: functions, hosting)
--except <targets> serve all except specified targets (valid targets are: functions, hosting)
-h, --help output usage information
You can use -p and -o on the command line to change the host and port where it listens for connections. For your case, you won't be able use localhost for the host because that's only visible to other processes on the same machine.
This worked for me. I found the config.json file for the functions-emulator (It's in user/.config/configstore/#googlecloud/functions-emulator/config.json on mac or windows) and changed "bindHost": "localhost", to "bindHost": "0.0.0.0" and then I could access served functions from other devices on my network via localip:5000 which wasn't working before.
Tivoli commented on Aug 20, 2017 •
Digging around the code I figured this out, it's because the
firebase-tools is only setting the projectId as part of the
functions-emulator config. This fixes it in my Dockerfile
ADD config.json
/root/.config/configstore/#google-cloud/functions-emulator/config.json
and the config.json looks like this
{
"bindHost": "0.0.0.0" }
You can change the 0.0.0.0 to any host you want, but this works for
Docker.
For reference
https://github.com/firebase/firebase-tools/blob/master/lib/serve/functions.js#L71
is the offending block, it needs to set the above parameter to the
same as the --host command line parameter.
If you are running on your own local machine then you need to set it
to the configstore folder for your respective OS on OS X it would be
~/.config/configstore/#google-cloud/functions-emulator/config.json.
Reference for the default config values
https://github.com/GoogleCloudPlatform/cloud-functions-emulator/blob/master/src/defaults.json
I have multiple upstream servers from an nginx load balancer:
upstream app {
# Make each client IP address stick to the same server
# See http://nginx.org/en/docs/http/load_balancing.html
ip_hash;
# Use IP addresses: see recommendation at https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
server 1.1.1.1:6666; # app-server-a
server 2.2.2.2:6666; # app-server-a
}
Right now I ue the servers in an active/passove configuration by taking down each servers (eg systemctl myapp stop) then letting nginx detect the server is down.
However I'd like to be able to change the upstream server dyamically, without having to take either app server or nginx OSS down. I'm aware of the proprietary upstream_conf module for nginx Plus but am using nginx OSS.
How can I dynamically dynamically reconfigure the upstream server on nginx OSS?
You can use:
openresty an OSS nginx bundle with lua scripting ability
nginx with lua scripting (you can configure it by yourself using nginx OSS and luajit) to achieve this.
dynx can achieve exactly what you are looking for, it's still work in progress but the dynamic upstream functionality is there and it's configurable through a rest API.
I'm adding the details on how to deploy and configure dynx:
you need to have a docker swarm up and running (for testing purpose
you can have a 1 swarm machine), follow the docker documentation to do that.
after you need to deploy the stack, for example, with this command (you need to be on the dynx git root):
docker stack deploy -c docker-compose.yml dynx
To check if the application deployed correctly, you can use this command:
docker stack services dynx
To configure an location you can use through the api you can for instance do:
curl -v "http://localhost:8888/configure?location=/httpbin&upstream=http://www.httpbin.org/anything&ttl=10"
To test if it works:
curl -v http://localhost:8666/httpbin
Do not hesitate to contact me or open an issue on github if you are not able to get it to work
I can't get my ASP.NET web application to get served to my browser when the web app is containerized in Docker.
I'm running a Mac, and I've used Visual Studio Code to create an ASP.NET web application. It's a simple, out-of-the-box demo that is based on the yo aspnet "Empty Application." When run "native" (outside of Docker), this application serves a "Hello World!" to http://localhost:5000 just fine. In other words, running dnx web starts the web server (Kestrel) and yeilds:
Hosting environment: Production
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
This is good. Now enter Docker. I seem to have successfully built a Docker image containing the web application, and when I run the container in Docker, I get the same output from Kestrel. Also good, but, I can no longer load the "Hello World!" page in my browser at http://localhost:5000. Instead, I get a ERR_CONNECTION_REFUSED. This is fairly obviously because due to the Docker "indirection," there is nothing serving directly to port 5000 anymore. In other words, I think there's an incorrect forwarding configuration, or, I think am misunderstanding the addressing.
I believe that port forwarding is involved in this process. In my Dockerfile, I am using an EXPOSE 5000 which I thought would allow me to map my local use of port 5000 to the Docker container's port 5000 using a run command like this:
docker run -i -t -p 5000:5000 container_name
But that's not the case with http://localhost:5000 (ERR_CONNECTION_REFUSED). So it occurred to me that Docker is almost certainly not at localhost. I had noticed when Docker loads, it says:
docker is configured to use the default machine with IP 192.168.99.100
So, I thought I'd try http://192.168.99.100:5000, but again (confusingly?) ERR_CONNECTION_REFUSED. Next, I read an interesting article here and I was able to determine from the suggested command
docker inspect container_name | grep IPAddress
That the container is assigned "IPAddress": "172.17.0.2"
So, I thought I'd try http://172.17.0.2:5000. And now we might actually be getting somewhere, because instead of a ERR_CONNECTION_REFUSED, I instead get a spinning hourglass and a resulting timeout. But still no "Hello World!"
What might I be missing?
It turns out that the web application is available at the IP address of the virtual machine 192.168.99.100 as suspected. 172.17.0.2 was clearly some sort of red herring.
The real kicker seems to be that the container's default "internal" IP is 0.0.0.0
Following the excellent advice of this posting, I edited the Dockerfile and specified the following:
ENTRYPOINT ["dnx", "web", "--server.urls", "http://0.0.0.0:5000"]
Because...
This will allow our web application to serve requests that come in from the
port forwarding provided by Docker which defaults to 0.0.0.0
The port mapping is crucial to link the host's port to the container's, but the EXPOSE command is apparently redundant. Now, when I run
docker run -i -t -p 80:5000 container_name
I can simply browse to http://192.168.99.100 (port 80 is implicit)
And viola! There's my "Hello World!"
Apart from using http://0.0.0.0:5000 you can use http://*.5000
ENTRYPOINT ["dnx", "web", "--server.urls", "http://*:5000"]
or you can include this against the runtimes environment
"commands": {
"kestrel": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://*:5004"
},
"web": ......
and the entrypoint in the dockerfile can be
ENTRYPOINT ["dnx","-p","project.json","kestrel"]
How to run meteor on a different port, for example on port 80.
I tried to use meteor --port 80, but I get this error Error: listen EACCES
help me please.
Sounds like it might be access issue on your machine.
Check out this following answer, which might be related to your question. Quoting:
"As as a general rule processes running without root privileges cannot bind to ports below 1024.
So try a higher port, or run with elevated privileges via sudo."
So, you can see that sudo meteor run with your port number will work, but that you can address the root cause, which is fixing the node root privilege.
Node.js EACCES error when listening on most ports
You can't bind to ports < 1024 on Linux/Unix operating systems with a non-privileged account.
You could get around this by running meteor as root, but this is a really bad idea. In development mode, running as root will modify the permissions of the files under your application directory. In production, it's just a giant security hole. Never run a meteor app as root.
Listed below are the best practices depending on your environment.
Development
Run meteor on a high port number. The default is 3000 when you don't give a --port argument. Connect to it via the URL printed in the console - e.g. http://localhost:3000/.
Production
Here you have two choices:
Run meteor on a high port number and connect it to the outside world via a reverse proxy like nginx or HAProxy.
Start the webserver as root but step down the permissions once it's running using something like userdown. This is how mup works which, incidentally, is probably what you should be using to deploy your app.
run it with sudo
sudo meteor --port 80
The meteor run --port 8080 terminal command can be used.