关注微信公众号
第一手干货与资讯
加入官方微信群
获取免费技术支持
Hello, I’m Alena Prokharchyk, one of the developers here at Rancher. In my previous blog posts, I’ve covered various aspects of Service Discovery, a feature we use to discover and interconnect services of user applications deployed in Rancher. This discovery is done by services registering themselves dynamically to Rancher’s internal DNS so that other services in the system can discover them by fully qualified domain name (FQDN). Service Discovery can also be registered to Rancher’s Load Balancer (LB) service which allows it to balance traffic between all of a services’ containers. Even though this covers many use cases, one major piece was lacking - making applications discoverable to outside world applications (or users) that don’t have access to Rancher’s internal DNS. I’m excited to let you know we’ve implemented a new solution that integrates our DNS service with Amazon Route53, which is now available as of Rancher 0.44. In this post I’ll describe its setup and implementation details.
A very common use case for our new Amazon Route 53 integration is to have a service running in Rancher behind multiple LB instances, for example: In our example, the LB service has 2 instances of our Rancher LB deployed. Each LB container publishes its public port to the host. If the hosts are publicly accessible, it means that the LB containers can be accessed from the internet via <host_ip_address>:<exposed_port>. But it is not very common to give your users a direct IP to access your application and this IP can change as the LB service’s containers get redeployed on other hosts. The most common workaround is to register Rancher Host IPs in the public DNS system of your choice--Amazon Route53, CloudFlare, etc. The problem with this approach is that whenever the LB service scales up or scales down, DNS has to be updated manually with the new information. In Rancher v0.44.0 you can offload public DNS programming to a dedicated external DNS service. Today we support only integration with Route53, but given a pluggable code structure of an external DNS component, it would be easy to integrate with other DNS providers in the future.
Before creating a public DNS service in Rancher, you have to set Route53 under your Amazon account with a Hosted Zone. Hosted Zone is a collection of resource record sets hosted by Amazon Route 53. Like a traditional DNS zone file, a Hosted Zone represents a collection of resource record sets that are managed together under a single domain name. You can read more about it here: Creating a Public Hosted Zone on Amazon Route53. That’s all you have to do on Route53 side. For our example, I’ve configured a Hosted Zone named \“rancher-test.com\“:
Route53 service can be deployed from Rancher Catalog. To open Catalog view, click on the \“Catalog\” icon: In the opened view, pick \“Route53 DNS\“: and click \“Launch\“. In the opened dialog, fill in all of the required fields, then click \“Create\“: The above creates a stack with Route53 service. The service has scale=1 meaning that there will be only one container deployed and that container will handle Route53 updates for the entire environment. After the service is created, activate it. Once the DNS container is up and running, you can check out its logs: Logs show that DNS records for LB service we created earlier got propagated to Route53. On the Route53 side, you should see a new record set created for the LB service: The record name is constructed as <serviceName>.<stackName>.<environmentName>.<hostedZoneName>. Its value contains IP addresses of the hosts where LB service got deployed. Now if you execute \“dig\” command against lb.alena.default.rancher-test.com, you would see this DNS name resolved to 2 IPs: On any changes to the LB service affecting its deployment, Route53 records will get the update automatically. Let’s scale down LB service and see what happens by monitoring Route53 container logs: Immediately after scale down action, the Route53 container sent an update for the existing record to external DNS. As you can see, it contains only one IP address now. To double check that it took affect, run \“dig\” command again: Similarly when new service having ports published to the host gets deployed, Route53 DNS service will update external DNS on the fly. And once the service gets removed, its Record Set on the AWS Route53 side will also be removed.
There is a service deployed inside Route53 DNS container that does all the magic. It gets Rancher updates by listening to rancher-metadata service events, and syncs up with AWS Route53. It also catches the changes done on the Route53 side. Let’s say someone by mistake removed a record programmed by Rancher. Rancher Route53 DNS service will correct this situation. It’s important to mention that every Rancher Route53 DNS service instance controls Record Sets ending with <environmentName>.<hostedZoneName>, so if you have multiple Rancher deployments using the same AWS account, it is important that <environmentName>.<hostedZoneName> is unique per each Rancher deployment.
If you’re interested in finding out more about Rancher, please download the software from github, join the Betato get additional support, and visit our forums to view topics and ask questions. This month we’ve got a great meetup scheduled to demonstrate how to use Docker compose blueprints to manage application upgrades. Please register for your seat to see the latest and greatest features in Rancher. Alena Prokharchyk If you have any questions or feedback, please contact me on twitter: @lemonjet https://github.com/alena1108