I have kolla-ansible openstack ussuri cluster . It used to works well. Accidently, the metadata service cannot be accessed by instance. The keypair in openstack not imported to the instance. I checked the instance log. I found this warning:
[WARNING]: No active metadata service found
I checked the neutron_metadata_agent is running.
I tried curl http://169.254.169.254/openstack from running instance that has been created before this issue
ubuntu#test-vm:~$ curl http://169.254.169.254/openstack
curl: (7) Failed to connect to 169.254.169.254 port 80: Connection refused
here is the ip route inside the instance
ubuntu#test-vm:~$ ip ro
default via 172.30.0.1 dev ens3 proto dhcp src 172.30.255.102 metric 100
169.254.169.254 via 172.30.255.3 dev ens3 proto dhcp src 172.30.255.102 metric 100
172.30.0.0/16 dev ens3 proto kernel scope link src 172.30.255.102
Could somebody help me out? thanks for your help.
The actual metadata service is hosted by the Nova API. It listens on port 8775/TCP either directly or there is a separate vhost configuration if Apache is used as e.g. TLS proxy. The Neutron metadata agent just acts as kind of forwarder between the instance and the actual metadata service.
This graphic depicts the communication flow (for Train though, but probably still the same for Ussuri).
I suggest to check whether Nova API is still listening to port 8775/TCP and if so, try to debug the communication flow in the graphic. Also check the security group of your instance. Maybe your default security group is broken.
Related
Here is what i have:
GCP instance without external IP (on VPC, and NAT), and it accepts HTTP HTTPS requests
firewall allows ingress TCP for 0.0.0.0 and also for IAP's IP 35.235.240.0/20 on all ports for all instances
I ssh to the instance via IAP and run the application in the terminal on port 5000 and 0.0.0.0 host and leave the terminal hanging, but when I connect in parallel through cloud shell and ssh to this instance through IAP, and then click on web preview on port 5000, I get "Couldn't connect to a server on port 5000".
I have said that it could be a firewall rule blocking IAP, so that's why I gave access to all ports for IAP (for testing)
P.S: the process has been done on a VM with external IP and it got validated ( but without the need to connect to cloud shell to do web preview, I checked the UI with IP:port in the browser )
What did I miss?
You may be following the guide on Building Internet Connectivity for private VMs and this part on Configuring IAP tunnels for interacting with instances and the use of TCP Forwarding in IAP. By Tunneling other TCP connections:
"The local port tunnels data traffic from the local machine to the remote machine in an HTTPS stream. IAP then receives the data, applies access controls, and forwards the unwrapped data to the remote port."
You can create an encrypted tunnel to a port of the VM instance by:
gcloud compute start-iap-tunnel INSTANCE_NAME INSTANCE_PORT \
--local-host-port=localhost:LOCAL_PORT \
--zone=ZONE
I guess you want to use INSTACE_PORT and LOCAL_PORT the same, 5000.
Be aware of it's known limitations.
I cannot connect to external mongodb server from my docker swarm cluster.
As I understand this is because of cluster uses overlay network driver. Am I right?
If not, how does docker overlay driver works and how can I connect to external mongodb server from cluster?
Q. How does the docker overlay driver work?
I would recommend this good reference for understanding docker swarm network overlay, and more globally, Docker's architecture.
This states that:
Docker uses embedded DNS to provide service discovery for containers running on a single Docker Engine and tasks running in a Docker Swarm. Docker Engine has an internal DNS server that provides name resolution to all of the containers on the host in user-defined bridge, overlay, and MACVLAN networks.
Each Docker container ( or task in Swarm mode) has a DNS resolver that forwards DNS queries to Docker Engine, which acts as a DNS server.
So, in multi-host docker swarm mode, with this example setup :
In this example there is a service of two containers called myservice. A second service (client) exists on the same network. The client executes two curl operations for docker.com and myservice.
These are the resulting actions:
DNS queries are initiated by client for docker.com and myservice.
The container's built-in resolver intercepts the DNS queries on 127.0.0.11:53 and sends them to Docker Engine's DNS server.
myservice resolves to the Virtual IP (VIP) of that service which is internally load balanced to the individual task IP addresses. Container names resolve as well, albeit directly to their IP addresses.
docker.com does not exist as a service name in the mynet network and so the request is forwarded to the configured default DNS server.
Back to your question:
How can I connect to an external mongodb server form cluster?
For your external mongodb (let's say you have a DNS for that mongodb.mydomain.com), you are in the same situation as the client in above architecture, wanting to connect to docker.com, except that you certainly don't wan't to expose that mongodb.mydomain.com to the entire web, so you may have declared it in your internal cluster DNS server.
Then, how to tell docker engine to use this internal DNS server to resolve mongodb.mydomain.com?
You have to indicate in your docker service task that you want to use an internal DNS server, like so:
docker service create \
--name myservice \
--network my-overlay-network \
--dns=10.0.0.2 \
myservice:latest
The important thing here is --dns=10.0.0.2. This will tell the Docker engine to use the DNS server at 10.0.0.2:53 as default if it can not resolve the DNS name in the VIP.
Finally, when you say :
I cannot connect to external mongodb server from my docker swarm cluster. As I understand this is because of cluster uses overlay network driver. Am I right?
I would say no, as there is a built in method in docker engine to forward unknown DNS name coming from overlay network to the DNS server you want.
Hope this helps!
I am getting this error when I am running any "consul members" on consul server and clients. The port is in LISTENING state and I made sure there is no firewall blocking. I get this error when in run the same in the consul client:
Error retrieving members: Get http://127.0.0.1:8500/v1/agent/members:
dial tcp 127.0.0.1:8500: connectex: No connection could be made
because the target machine actively refused it.
When I make the above request with the private IP, I get the required output. Can I change the configuration anywhere so that it listens on the private IP for requests?
It seems that your consul members lacks the option -http-addr=....
Example
consul members -http-addr=10.10.10.10:8500
while assuming you use the standard port 8500 of the consul agent and that you started consul via:
consul agent -client=10.10.10.10 #...
Where to find the documentation?
In the Consul Documentation under Running an Agent: "Client Addr":
If you change this address or port, you'll have to specify a -http-addr whenever you run commands such as consul members to indicate how to reach the agent.
Or offline via consul members -help:
http-addr=<address>
Theaddressand port of the Consul HTTP agent. The value can be
an IP address or DNS address, but it must also include the port.
This can also be specified via the CONSUL_HTTP_ADDR environment
variable. The default value is http://127.0.0.1:8500. The scheme
can also be set to HTTPS by setting the environment variable
CONSUL_HTTP_SSL=true.
We are currently using Openstack newtown. We can access the API using client on public endpoint from any computer, but the vm don't have access to it, they can ping the IP and dns name but can't curl or access using openstack-client. How can we allow connection from VM to API ?
Assuming your public API endpoint is externally accessible, the network on which your virtual machine resides will need external access. This can be achieved in a few different ways, depending on your current configuration. You can create a Neutron provider network/subnet which will provide access to a physical network and gateway to the outside world. You can then boot your instance directly on the provider network. More information on Neutron provider networks can be found at docs.openstack.org.
The problem is that floating IP don't give the route of my external network.
I add route using neutron and now all is working perfectly. for info the command is:
neutron router-update demo-routeur --routes type=dict list=true destination=192.168.0.27/27,nexthop=10.0.0.1
I'm running a Node app on a HTTP instance with Debian-8 and only can reach my app via port 8080 which my node server is running on. If I remove the port and try to access through port 80, then I get a refused to connect error.
I've allowed tcp:80 to all targets in Networking -> Firewall Rules and also verified that my iptables are open in Debian. Any ideas?
Resolved - My port forwarding was not set property in Debian.