My Setup
I have some services that register with Eureka. This registration info is used by Zuul to route requests to my services. Most of these services run on a port like 9999 or 8080. Each service is on it's own EC2 instance, and I have Nginx routing requests from port 80 to the server's port, so that I can keep my Security Group rules simple.
My Problem
When my service registers with Eureka, it gets registered with ${server.port}, which ends up being 8080 or 9999, etc. When Zuul attempts to route to {ec2host}:8080, it gets blocked by my Security Group rules. Based on the documentation, it looks like I should be able to specify a host and port with eureka.instance.hostname and eureka.instance.nonSecurePort. Whether I use those properties or not, my service registers with it's specific port.
Is there a way to get the Eureka client to register my service with port 80, instead of the server's port?
Related
I have an application running on my own server with kubernetes. This application is supposed to work as a gateway and has a LoadBalancer service, which is exposing it to "the world". Now I'd like to connect this application with other applications running within the very same kubernetes cluster, so they can exchange HTTP requests with each other.
So let's say that my Gateway app is running on the port 9000, the app which I'd like to call runs on 9001. When I make curl my_cluster_ip:9001 it gives me a response. Nevertheless I never know, what the Cluster IP will be, so I can't implement this to my gateway app.
Use case is typing to the web browser url_of_my_server:9000 -> this will call the gateway -> it sends HTTP Request to the other app running in the cluster on the port 9001 -> response back to the gateway -> response back to the user.
Where the magic has to happen and how to easily make these two apps to talk with each other, while only one will be exposed to "the world" and the other one will be accessible only from within the cluster?
You can expose your app on port 9001 as a service (lets say myservice).
When you do that myservice.<namespace>.svc.cluster.local will resolve to IP addres of your app. More Info on DNS here : https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
And then you can access your app within Kubernetes cluster as:
http://myservice.<namespace>.svc.cluster.local:9001
You have a couple of options for internal service discovery:
You can use the cluster-internal DNS service to find the other application, as detailed in the answer by bits.
if both the proxy and the app runs in the same namespace, there are environment variables that expose the IP and ports. This may mean you have to restart the proxy if you remove/readd the other application, as the ports may change.
you can run both apps as two different containers in the same pod; this will ensure they get scheduled on the same host, which allows you to communicate on the same host.
Also note that support for your HTTP proxy setup already exist in Kubernetes; take a look at Ingress and Ingress Controllers.
I have my free-tier EC2 containing my Scala application. The app is running on port 8080 but I have declared redirection from port 80 to port 8080. Security group of EC2 includes inbound rules of port 8080 and 80 to all IPs. Nonetheless, I couldn't access the service with browser.
Outputs from netstat and iptables
Security group
Browser returns ec2-35-157-211-142.eu-central-1.compute.amazonaws.com refused to connect.
I'd really appreciate if someone could help me.
Thanks.
Ensure that your EC2 instances are located in public subnets. If that's fine, then ensure that they have public IPs assigned, otherwise they won't be accesible from the internet.
If they have public IP, then you should check that the security group has outbound rule allowing those ports for all IPs (or at least the ones you want to allow to connect). If you have inbound rule but no outbound rule your instance won't be able to serve traffic, so please define the outbound rule the same way that the inbound rule.
If that's properly set, then ensure that the network ACL allows inbound/outbound rules for the same ports (and of course: it does not deny them).
I hope this helps :).
If you're able to connect locally but not remotely, chances are that you aren't binding your server to the external interface. To bind to all interfaces, just make host = "0.0.0.0" similar to the following:
For Spray:
IO(Http) ! Http.Bind(service, "0.0.0.0", port = 8080)
For Akka HTTP:
Http().bindAndHandle(route, "0.0.0.0", 8080)
testing Marathon application/group deployment I have observed that if I try to deploy an application specifying a service port that has already been assigned to another app Marathon v2/apps endpoint rejects the request, as expected:
{"message”:"Requested service port 8306 conflicts with a service port in app /dbaas01/mysql"}
Yet, it seems that the service port uniqueness is not checked when submitting the deployment of an application group. I was able to deploy twice the same application group (changing the root group name) and using the same service ports for the applications.
Of course, this creates an issue with the haproxy-marathon-bridge: the load balancer configuration is modified so that the same port points to different services:
listen dbaas01_mysql-8306
bind 0.0.0.0:8306
mode tcp
option tcplog
balance leastconn
server dbaas01_mysql-1 172.30.15.84:31841 check
listen dbaas02_mysql-8306
bind 0.0.0.0:8306
mode tcp
option tcplog
balance leastconn
server dbaas02_mysql-1 172.30.15.85:31075 check
Is this the expected behavior? Why the check on the service port uniqueness is not performed on the application deployed using the /v2/groups endpoint?
Thank you in advance for feedbacks.
Best regards,
Marica
We are working on a service using Twitter's Finatra. The main web services are exposed in port 8080 (using override def defaultFinatraHttpPort = ":8080"). Finatra exposes Finagle's Http Admin interface automatically on port 9000. Is it possible to instruct it to expose the /admin/* endpoints on the main application port (i.e. 8080)?
I've tried overwriting the 'adminPort' var, however Finatra will try to create another Http listener on that port, which will fail because there is one already created. What I'm trying to do is to link the admin controllers to the main Http listener, so that everything is accessible from one single http port.
I plan to set the Secure Gateway Client at DMZ at on-premise environment, so I need to open Outbound ports for SG Client to connect to SG on Bluemix. The following question is similar to my question, but the answer doesn't show the needed ports.
For the Bluemix Secure Gateway service, how does the data center's network need to be configured?
For the Bluemix Secure Gateway service, how does the data center's network need to be configured?
The following Bluemix Doc shows Outbound 443 is needed.
https://www.ng.bluemix.net/docs/troubleshoot/SecureGateway/ts_index-gentopic1.html#ts_sg_006
What are the best practices for running the Secure Gateway client?
Before you install the Docker client into your environment, ensure that both the internet and your on-premises assets are accessible and all host names are resolvable by a DNS. The client uses outbound port 443 to connect to the IBM Bluemix environment, normally this port is open since its secure. Ensure you check or modify additional firewall and IP Table rules that might apply.
But, the tcpdump, which I got when I executed "docker run -it ibmcom/secure-gateway-client XXXX", showed that SG Client used Outbound 443 and 9000. Is it collect that all ports SG Client uses are Outbound 443 and 9000 ?
Correct, if you are closing down both outbound and inbound ports using your firewall, then for outbound allow ports 443/9000. So your initial assertion is correct.