In the world of microservices endpoints should not (must not) be hardcoded. One of the best ways to do this is to have a DNS and let each microservice register while starting. By doing this whenever microservice A wants to communicate with microservice B it just asks DNS for endpoints where B currently listens.
What I do not understand is: How microservices know where the DNS lives?
Basically DNS is just a 'special' service and I can have one or multiple instances of it right? So I should not hardcode it's endpoint too or should I? And let's say I do - what if DNS instnace is moved to different location? Do I have to manually change it's location in configuration?
Does anyone happen to know how to design this? (or can anyone just point me to any document where this is explained since although there are many information about microservices and dns I can not find this particular information anywhere - maybe it's just too trivial and I am the only one who does not get it)
Manual setup of DNS is possible, as stated by the other answers, but I would recommend to use an infrastructure that supports the service discovery in all respects. For example kubernetes has built in DNS support and makes it very easy to expose a service that can consist of any number of Pods.
An infrastructure technology like kubernetes will also make many other respects of the microservices architectural style easier to implement, including high availability and scalability.
Please see the official docs for some more information.
DHCP solves this problem. When a host boots it sends a broadcast DHCP message. The DHCP server responds with many values, one of which is the location of DNS servers.
In the case of micro services, the host OS (or container host) will be configured for DNS via DHCP. The microservice code uses the OS DNS functions to resolve addresses.
https://en.m.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
You can use your local network to discover services, via Dhcp and whatnot. But that requires that all services are already "registered" within that DNS server.
Microservices can find each other via service discovery, server or client side. If you choose client side service discovery, you can use tools like Consul, which provides a bunch of great features. One of which is a DNS endpoint which allows queries via SRV records with <serviceName>.consul.service domain names.
Consul has it's own DNS endpoint, you can configure your services to use that (usually on port 8600 locally, as Consul agents run locally).
But you can also configure an actual DNS server to forward questions to Consul, so that you can easily mix service discovery drive by Consul with manually setup services within a Bind instance or similar...
Known hostname solution. The fixed part would be the service domain name, for instance xservice.com. You can query this host using standard DNS tools (e.g., dig in your shell, etc).
Finally, in the DNS bound to xservice.com you then add a SRV record with further details.
A SRV record lists all the service details, including:
the symbolic service name;
the canonical hostname of the machine providing the service;
the TCP (or UDP) port on which the service is available.
There are many other info as well. Please see Wikipedia for the complete list.
Please keep in mind this is a somewhat static solution. If you are looking for a more dynamic one, then Oswin answer might be a better fit :-)
Related
Hello I've been searching everywhere and did not found a solution to my problem, which is how can I access my API through the gateway configured endpoint only, currently I can access to my api using localhost:9000, and localhost:8000 which is the Kong gateway port, that I secured and configured, but what's the point of using this gateway if the initial port is still accessible.
Thus I am wondering is there a way to disable the 9000 port and only access to my API with KONG.
Firewalls / security groups (in cloud), private (virtual) networks and multiple network adapters are usually used to differentiate public vs private network access. Cloud vendors (AWS, Azure, etc) and hosting infrastructures usually have such mechanisms built in, e.g. Kubernetes, Cloud Foundry etc.
In a productive environment Kong's external endpoint would run with public network access and all the service endpoints in a private network.
You are currently running everything locally on a single machine/network, so your best option is probably to use a firewall to restrict access by ports.
Additionally, it is possible to configure separate roles for multiple Kong nodes - one (or more) can be "control plane" nodes that only you can access, and that are used to set and review Kong's configuration, access metrics, etc.
One (or more) other Kong nodes can be "data plane" nodes that accept and route API proxy traffic - but that doesn't accept any Kong Admin API commands. See https://konghq.com/blog/separating-data-control-planes/ for more details.
Thanks for the answers they give a different perspectives, but since I have a scalla/play microservice, I added a special Playframework built-in http filter in my application.conf and then allowing only the Kong gateway, now when trying to access my application by localhost:9000 I get denied, and that's absolutely what I was looking for.
hope this answer gonna be helpful for future persons in this same situation.
I have 3 VMs (app, content, DB) that are part of an application deployment. I need to clone multiple copies of this VM set. There is a common web server for all sets that proxies requests to the app server in each set.
Because hostnames are duplicated, I believe I can put each SET of 3 VMs into their own subnet and prevent communication and hostname duplication.
The web server will be outside these subnets (I guess in its own subnet).
If you have multiple hosts with the same hostname in the same VNET, will they have the same internal DNS name? The fact that they are firewalled into separate subnets should prevent cross traffic?
The web server will proxy based on IP address, since hostname will not resolve easily.
An alternative is one web server per VM set, 4 servers per VNET. This will work, but means 25% more VMs to manage.
Anyone suggest the "typical" way a network engineer would architect this? (Yes this could be cross posted to networking group, but it is dependent upon Azure specifics as well as general network architecture).
Many thanks experts.
You cannot have multiple hosts with the same hostname and internal DNS name. These have to be unique. The alternative seems more favorable here.
For our SaaS app, we're allowing customers to point their domain name to our server.
The plan right now is to simply hand out one of our AWS elastic IP addresses for them to point their domain to. The elastic IP address would essentially be pointed to a EC2 instance web-server...and maybe a load balancer in time (if traffic demands it!).
The user would specify what their domain is in our app, and we'd be able to resolve the host name coming in as their app.
My concern is the longevity of this solution. This IP cannot change. And we'll certainly be tied to AWS if we go this route.
(Note: Being a 1-2 person startup, standing up a data-center is more than likely no-go, and we hope to use AWS or Azure).
What solutions would make this IP address -> SaaS Web Server concept last in the long run, with flexibility, and as minor of a tie as possible to a cloud provider?
With running the risk of asking "what is the best way to do this"...what's the best way to do this, keeping in mind longevity and small opt-in to a cloud provider?
You can't point an IP address to a load balancer, so this seems like a very bad idea. You need your own domain/subdomain that clients can point their domains/subdomains to via a CNAME record on their end. Then if the location of your service ever changes you just have to update your domain record and their DNS records will continue to be correct.
We have a client who wants to connect their premises to Azure. Their main hindrance at this point is determining the best way to connect to Azure given their current connectivity configuration. They have two redundant ISP connections going to the head office for internet access. They want to be able to configure a VPN connection to Azure that would operate in a similar way i.e. if ISP A went down it would seamlessly use ISP B and vice versa. The normal multi-site VPN configuration does not fit this since there is one local network behind which means the network behind separate VPNs over each ISP would have overlapping IP address ranges which is not supported. Is such a configuration possible? (See diagram below)
Either that or is there a way to abstract the two ISP connections onto one VPN connection to Azure.
They’re currently considering using a Cisco ASA device to help with this. I’m not familiar with the features of this device so I cannot verify if it will solve their issue. I know there is also a Cisco ASAv appliance in the Azure marketplace don't know if that could also be a part of a possible solution if they went with such a device.
required vpn configuration
The Site-to-Site VPN capability in Azure does not allow for automatic failover between ISPs.
What you could do are the following
- Have automation task created that would re-create the local network and gateway connection upon failover. Manual and would take some RTO to get it up and running
- Use the Cisco CSRs to create a DMVPN mesh. You should be able to achieve the configuration you want using that option. You would use UDRs in Azure to ensure proper routing
I havent done it in Azure, but here is what you do in AWS (And I am sure there would be parallel in Azure)
Configure a "detached VGW" (virtual Private gateway) in aws. Use DMVPN cloud to connect CSRs to multi-site on-prem.
Also, for failover between ISPs you could have a look at DNS load balancing via a parallel to AWS's Route 53 in Azure.
Reference thread :
https://serverfault.com/questions/872700/vpc-transit-difference-between-detached-vgw-and-direct-ipsec-connection-csr100
I have two servers that provide a service to clients.
The client devices access the server through a DNS name. example.com
Now we generally use server1 (primary) but if server one becomes inaccessible, I want the DNS to change its resolving name to server 2 (secondary server)
How can I go about doing this, Is there a service that dyndns provides?
The only way I know to do it is to log into the DNS server and manually change the addresses that the dns resolves 2.
It sounds like you're looking to create an automated failover in the event of an outage. While this is a service that Dyn provides as an added service in the DynECT Managed DNS service (hit up sales#dyn.com for more info on that), you can also use the Dyn Updater API to push an IP update up to your Standard DNS account as well. It would be a matter of using a 3rd party monitoring solution to trigger the update in your code using their API, then using the Dyn Updater API to switch the IP.
http://dyn.com/support/developers/api/
Whether you want to spend the money on upgrading to DynECT Managed DNS or keep using your Standard DNS account, we can help you either way.
Good luck, and if you have any other questions, please do not hesitate to ask.
CL