I'm new in Ionic Framework, so I need your help. When I'm running ionic serve on localhost everything is great. But now I'm trying to work with Cloud9, it prints:
The port 8100 was taken on the host 172.17.12.3 - using port 8101 instead
The port 35729 was taken on the host 172.17.12.3 - using port 35730 instead
Running live reload server: http://172.17.12.3:35730
Watching : [ 'www/**/*', '!www/lib/**/*' ]
Running dev server: http://172.17.12.3:8101
But this adresses don't work at all. And i get an error from Cloud9:
Error: you may be using the wrong PORT & IP for your server app. Try passing $PORT and $IP to properly launch your application.
So how can I set $PORT and $IP in Ionic?
Since Cloud9 forwards port 8080 (which is the value of $PORT), you need to tell ionic to use that instead. With the recent change of allowing multiple ports, port 8081 and 8082 are also allowed, so you need to tell ionic to use 8081 (or 8082) as the livereload ports. The command that should work is:
ionic serve -p 8080 -l 8081
I also think that adding -a would help since with that option it appears to bind to IP 0.0.0.0 which you should be binding to in the first place. For more information about Ionic cli options, please check out the Ionic CLI github page
simple solution is to close the terminal in which you are running the serve request and open new terminal then give ionic serve request it will take the 8100 port (which you gave in your code)
Related
Hi I'm am creating 3 webApi's a GateWay and I'm using docker in visualStudio0217 (.netCore).
The projects compile fine and I see the images were created.
But whe I try to go to the Url's http://LocalHost:9002 or http://LocalHost:9000 these dont work
I have this docker compose:
Do I need to do something else?
instead of http://LocalHost:9002 use http://localhost:57978
instead of http://LocalHost:9000 use http://localhost:46429
Explanation
0.0.0.0:57978->8041/tcp means that host port 57978 is mapped to container port 8041
0.0.0.0:46429->8043/tcp means that host port 46429 is mapped to container port 8043
You can use this command to inspect your connections
docker inspect container_name
Maybe you can try to add the "ports" in your docker-compose for each service.
Example:
ports:
- "9002:80"
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
Kubernetes newbie (or rather basic networking) question:
Installed single node minikube (0.23 release) on a ubuntu box running in my lan (on IP address 192.168.0.20) with virtualbox.
minikube start command completes successfully as well
minikube start
Starting local Kubernetes v1.8.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
minikube dashboard also comes up successfully. (running on 192.168.99.100:30000)
what i want to do is access minikube dashboard from my macbook (running on 192.168.0.11) in the same LAN.
Also I want to access the same minikube dashboard from the internet.
For LAN Access:
Now from what i understand i am using virtualbox (the default vm option), i can change the networking type (to NAT with port forwarding) using vboxnet command
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,,22"
as listed here
In my case it will be something like this
VBoxManage modifyvm "VM name" --natpf1 "guesthttp,http,,30000,,8080"
Am i thinking along the right lines here?
Also for remotely accessing the same minikube dashboard address, i can setup a no-ip.com like service. They asked to install their utility on linux box and also setup port forwarding in the router settings which will port forward from host port to guest port. Is that about right? Am i missing something here?
I was able to get running with something as simple as:
kubectl proxy --address='0.0.0.0' --disable-filter=true
#Jeff provided the perfect answer, put more hints for newbies.
Start a proxy using #Jeff's script, as default it will open a proxy on '0.0.0.0:8001'.
kubectl proxy --address='0.0.0.0' --disable-filter=true
Visit the dashboard via the link below:
curl http://your_api_server_ip:8001/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/
More details please refer to the officially doc.
I reached this url with search keywords: minikube dashboard remote.
In my case, minikube (and its dashboard) were running remotely and I wanted to access it securely from my laptop.
[my laptop] --ssh--> [remote server with minikube]
Following gmiretti's answer, my solution was local forwarding ssh tunnel:
On minikube remote server, ran these:
minikube dashboard
kubectl proxy
And on my laptop, ran these (keep localhost as is):
ssh -L 12345:localhost:8001 myLogin#myRemoteServer
The dashboard was then available at this url on my laptop:
http://localhost:12345/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
The ssh way
Assuming that you have ssh on your ubuntu box.
First run kubectl proxy & to expose the dashboard on http://localhost:8001
Then expose the dashboard using ssh's port forwarding, executing:
ssh -R 30000:127.0.0.1:8001 $USER#192.168.0.20
Now you should access the dashboard from your macbook in your LAN pointing the browser to http://192.168.0.20:30000
To expose it from outside, just expose the port 30000 using no-ip.com, maybe change it to some standard port, like 80.
Note that isn't the simplest solution but in some places would work without having superuser rights ;) You can automate the login after restarts of the ubuntu box using a init script and setting public key for connection.
I had the same problem recently and solved it as follows:
Get your minikube VM onto the LAN by adding another network adapter in bridge network mode. For me, this was done through modifying the minikube VM in the VirtualBox UI and required VM stop/start. Not sure how this would work if you're using hyperkit. Don't muck with the default network adapters configured by minikube: minikube depends on these. https://github.com/kubernetes/minikube/issues/1471
If you haven't already, install kubectl on your mac: https://kubernetes.io/docs/tasks/tools/install-kubectl/
Add a cluster and associated config to the ~/.kube/config as below, modifying the server IP address to match your newly exposed VM IP. Names can also be modified if desired. Note that the insecure-skip-tls-verify: true is needed because the https certificate generated by minikube is only valid for the internal IP addresses of the VM.
clusters:
- cluster:
insecure-skip-tls-verify: true
server: https://192.168.0.101:8443
name: mykubevm
contexts:
- context:
cluster: mykubevm
user: kubeuser
name: mykubevm
users:
- name: kubeuser
user:
client-certificate: /Users/myname/.minikube/client.crt
client-key: /Users/myname/.minikube/client.key
Copy the ~/.minikube/client.* files referenced in the config from your linux minikube host. These are the security key files required for access.
Set your kubectl context: kubectl config set-context mykubevm. At this point, your minikube cluster should be accessible (try kubectl cluster-info).
Run kubectl proxy http://localhost:8000 to create a local proxy for access to the dashboard. Navigate to that address in your browser.
It's also possible to ssh to the minikube VM. Copy the ssh key pair from ~/.minikube/machines/minikube/id_rsa* to your .ssh directory (renaming to avoid blowing away other keys, e.g. mykubevm & mykubevm.pub). Then ssh -i ~/.ssh/mykubevm docker#<kubevm-IP>
Thanks for your valuable answers, If you have to use the kubectl proxy command unable to view permanently, using the below "Service" object in YAML file able to view remotely until you stopped it. Create a new yaml file minikube-dashboard.yaml and write the code manually, I don't recommend copy and paste it.
apiVersion : v1
kind: Service
metadata:
labels:
app: kubernetes-dashboard
name: kubernetes-dashboard-test
namespace: kube-system
spec:
ports:
- port: 80
protocol: TCP
targetPort: 9090
nodePort: 30000
selector:
app: kubernetes-dashboard
type: NodePort
Execute the command,
$ sudo kubectl apply -f minikube-dashboard.yaml
Finally, open the URL:
http://your-public-ip-address:30000/#!/persistentvolume?namespace=default
Slight variation on the approach above.
I have an http web service with NodePort 30003. I make it available on port 80 externally by running:
sudo ssh -v -i ~/.ssh/id_rsa -N -L 0.0.0.0:80:localhost:30003 ${USER}#$(hostname)
Jeff Prouty added useful answer:
I was able to get running with something as simple as:
kubectl proxy --address='0.0.0.0' --disable-filter=true
But for me it didn't worked initially.
I run this command on the CentOS 7 machine with running kubectl (local IP: 192.168.0.20).
When I tried to access dashboard from another computer (which was in LAN obviously):
http://192.168.0.20:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/
then only timeout was in my web browser.
The solution for my case is that in CentOS 7 (and probably other distros) you need to open port 8001 in your OS firewall.
So in my case I need to run in CentOS 7 terminal:
sudo firewall-cmd --zone=public --add-port=8001/tcp --permanent
sudo firewall-cmd --reload
And after that. It works! :)
Of course you need to be aware that this is not safe solution, because anybody have access to your dashbord now. But I think that for local lab testing it will be sufficient.
In other linux distros, command for opening ports in firewall can be different. Please use google for that.
Wanted to link this answer by iamnat.
https://stackoverflow.com/a/40773822
Use minikube ip to get your minikube ip on the host machine
Create the NodePort service
You should be able to access the configured NodePort id via < minikubeip >:< nodeport >
This should work on the LAN as well as long as firewalls are open, if I'm not mistaken.
Just for my learning purposes I solved this issue using nginx proxy_pass. For example if the dashboard has been bound to a port, lets say 43587. So my local url to that dashboard was
http://127.0.0.1:43587/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
Then I installed nginx and went to the out of the box config
sudo nano /etc/nginx/sites-available/default
and edited the location directive to look like this:
location / {
proxy_set_header Host "localhost";
proxy_pass http://127.0.0.1:43587;
}
then I did
sudo service nginx restart
then the dashboard was available from outside at:
http://my_server_ip/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/#/cronjob?namespace=default
I am trying to setup xdebug integration on my docker-based setup.
I am using Docker for Mac 1.12.0-rc2-beta17 with the "native" docker machine
I have a container, with xdebug installed, exposing port 9000 and mapping it to the port 9000:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6950c2a2b05d app "/usr/bin/supervisord" 9 minutes ago Up 9 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:2222->22/tcp app_1
When I'm trying to use PhpStorm to listen to the port 9000 for debug connections, I'm getting an error "Cannot listen: port 9000 is busy".
I must precise that I'm a newbie in networks..
It dependent how you want to connect via Xdebug
xdebug.remote_connect_back=1 said that PHP will wait until a HTTP request with GET parameter XDEBUG_SESSION_START=<IDE_key>. Then will PHP within the server try to connect back via port 9000 where your PHPStorm is listing. Classic don't call us, we will call you situation.
Now your situation with docker say simple, your container is responsible for port 9000. So PHP will get a loopback and PHPStorm isn't able to use port 9000 because its already used by your docker container.
So skip the assignment of port 9000 to docker, that will fix this situation.
You must bind 9000 port with --expose option.
This is the reference
if you are using docker compose sample docker-compose.yml file is here:
version: '2'
services:
your_app:
ports:
- "80:80"
expose:
- "9000"
image: "your-image:tag"
Firstly check your container logs to debug:
docker logs 6950c2a2b05d
or
docker logs app_1
Add -f flags for tail-like behavior:
docker logs -f app_1
Two things I discovered:
There is no need to expose the port 9000 on a container with xdebug (that seems rather counter-intuitive for me, as I do not exactly understand how my IDE connects to xdebug then).
I was able to use xdebug using the workaround described in https://forums.docker.com/t/ip-address-for-xdebug/10460/4.
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"]