I actually created two zones when setting up the DNS for OpenShift. The servers reside in one zone, and the user applications in another. The broker service will be making updates to the application zone. It doesn't seem like a good idea to have the server hostnames in the same zone where a bug or intrusion could alter or delete them. Something like this will do.
infra.example.org- contains the server hostnamesapp.example.org- contains the application records
Picking a Domain Name (and a Registrar)
In most cases your choice is going to be constrained by what domains you own or have access too. You may need (as I did) to purchase a domain from a domain registrar. Or you will have to have your corporate IT department delegate a domain for you (whether they run it or you do).
When you register or delegate a domain your domain registrar will request a list of name servers which will be serving the content of your domain. Route53 won't tell you the nameservers until you tell them what domain they'll be serving for you. That means that creating a domain, if you don't have one, is a 3 step exchange:
- Request domain from a registrar
- Tell Route53 to serve the domain for you
- Tell your registrar which Route53 nameservers will be providing your domain
These steps will happen so rarely that I haven't bothered to script them. I just use the web interface for each step.
NOTE: there are technical differences between a zone and a domain but I'm going to treat them as synonyms for this process. When you're registering, it's called a domain. When you're going to change the contents it's called a zone.
NOTE: there are technical differences between a zone and a domain but I'm going to treat them as synonyms for this process. When you're registering, it's called a domain. When you're going to change the contents it's called a zone.
Each registrar will have a different means for you to set your domain's nameserver records. You'll have to look them up yourself. If you're getting a domain delegated from your corporate IT department you'll have to give them the list of Route53 nameservers so that they can install the "glue records" into their service.
So, pick your Registrar, search for an available domain, request, register, and pay. Then head over to the AWS Route53 console.
Make a note of the "Delegation Set". This is the set of nameservers which you need to provide to your domain registrar. The registrar will provide some place to enter the nameserver list and then they will add the glue records to the top-level domain.
Make a note as well of the "Hosted Zone ID". That's what you will use to select the zone to update when you send requests to AWS Route53.
When the domain registrar completes adding the Route53 nameservers it's time to come back to the thor CLI tools installed in part one.
From this you can craft a command. This example includes the --wait and --verbose options so that you can observe the process. Without the --wait option, the task will complete and return, but there will be a propagation delay before the name will resolve. With the --wait option, the task polls the Route53 service until it reports that the DNS services have synched.
When this command completes the new record should resolve:
Again, with the --verbose and --wait options, the task will not complete until the DNS change has propagated. When it completes, the name will no longer resolve.
So, pick your Registrar, search for an available domain, request, register, and pay. Then head over to the AWS Route53 console.
Adding a zone to Route53
On the web interface, click "Create Hosted Zone" in the top tool bar. You'll see this dialog on the right side.
Fill in the values for your new domain and a comment, if you wish. Then click "Create Hosted Zone" at the bottom of the dialog and Route53 will create your zone and assign a set of nameservers.
Make a note of the "Delegation Set". This is the set of nameservers which you need to provide to your domain registrar. The registrar will provide some place to enter the nameserver list and then they will add the glue records to the top-level domain.
Make a note as well of the "Hosted Zone ID". That's what you will use to select the zone to update when you send requests to AWS Route53.
When the domain registrar completes adding the Route53 nameservers it's time to come back to the thor CLI tools installed in part one.
Viewing the Route53 DNS information
You certainly can view the DNS information on the Route53 console. If you've set up the AWS CLI tools indicated in the previous post you can also view them on the CLI.
NOTE: If you haven't followed the previous post, you should before you continue here.
First list the zones you have registered.
NOTE: If you haven't followed the previous post, you should before you continue here.
First list the zones you have registered.
thor route53:zone:list task: route53:zone:list id: <YOURZONEID> name: app.example.org. records: 3
Now you can list the records in the zone (indicating the zone by name)
thor route53:record:list app.example.org task: route53:record:list app.example.org looking for zone id <YOURZONEID> example.org. NS ns-131.awsdns-16.com. ns-860.awsdns-43.net. ns-2023.awsdns-60.co.uk. ns-1076.awsdns-06.org. app.example.org. SOA ns-131.awsdns-16.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
Adding a DNS Record
The real goal in all of this is that the OpenShift broker must be able to add and remove records for applications. OpenShift uses the aws-sdk rubygem. The Thor tasks also use that gem. You can call them from the command line or use them to compose more complex operations.
OpenShift currently uses CNAME records to publish applications rather than A records. This is largely to allow for rapid re-naming or re-numbering of nodes within AWS. The use of CNAME records (which are aliases to another FQDN or fully qualified domain name means that the node which hosts the applications can be renumbered without the need to update every DNS record for every application. If bulk updates of DNS are not expensive, I believe that OpenShift could use A records, though it could require significant recoding.
To verify your DNS domain has been properly configured, add a CNAME record. Thor provides a standard help option for each query.
thor help route53:record:create
Usage:
thor route53:record:create ZONE NAME TYPE VALUE
Options:
[--ttl=N]
# Default: 300
[--verbose]
[--wait]
create a new resource record
From this you can craft a command. This example includes the --wait and --verbose options so that you can observe the process. Without the --wait option, the task will complete and return, but there will be a propagation delay before the name will resolve. With the --wait option, the task polls the Route53 service until it reports that the DNS services have synched.
thor route53:record create app.example.org test1 CNAME test2.app.example.org --verbose --wait
task: route53:record:create app.example.org test1 CNAME test2.infra.example.org
update record = {:comment=>"add CNAME record test1.app.example.org", :changes=>[{:action=>"CREATE", :resource_record_set=>{:name=>"test1.app.example.org", :type=>"CNAME", :ttl=>300, :resource_records=>[{:value=>"test2.infra.example.org"}]}}]}
response = {:change_info=>{:id=>"/change/C2VQAFRSE6OXMY", :status=>"PENDING", :submitted_at=>2013-05-27 00:24:19 UTC, :comment=>"add CNAME record test1.app.example.org"}}
1) change id: /change/C2VQAFRSE6OXMY, status: UNKNOWN - sleeping 5
2) change id: /change/C2VQAFRSE6OXMY, status: PENDING - sleeping 5
3) change id: /change/C2VQAFRSE6OXMY, status: PENDING - sleeping 5
4) change id: /change/C2VQAFRSE6OXMY, status: PENDING - sleeping 5
5) change id: /change/C2VQAFRSE6OXMY, status: PENDING - sleeping 5
When this command completes the new record should resolve:
host -t cname test1.app.example.org test1.app.example.org is an alias for test2.infra.example.org.Also, now if you list the zone records with
thor route53:record list app.example.org you'll see the new CNAME record.
Deleting a DNS record
Deleting a DNS record is nearly identical to adding one. To insure that you are deleting the correct record the delete task requires the same complete inputs as the create task.
thor route53:record delete app.example.org test1 CNAME test2.infra.example.org --verbose --wait
task: route53:record:delete app.example.org CNAME test1
update record = {:comment=>"delete CNAME record test1.app.example.org", :changes=>[{:action=>"DELETE", :resource_record_set=>{:name=>"test1.app.example.org", :type=>"CNAME", :ttl=>300, :resource_records=>[{:value=>"test2.infra.example.org"}]}}]}
response = {:change_info=>{:id=>"/change/C3ORAEV7FTLPBJ", :status=>"PENDING", :submitted_at=>2013-05-27 00:58:25 UTC, :comment=>"delete CNAME record test1.app.example.org"}}
1) change id: /change/C3ORAEV7FTLPBJ, status: UNKNOWN - sleeping 5
2) change id: /change/C3ORAEV7FTLPBJ, status: PENDING - sleeping 5
3) change id: /change/C3ORAEV7FTLPBJ, status: PENDING - sleeping 5
4) change id: /change/C3ORAEV7FTLPBJ, status: PENDING - sleeping 5
5) change id: /change/C3ORAEV7FTLPBJ, status: PENDING - sleeping 5
Again, with the --verbose and --wait options, the task will not complete until the DNS change has propagated. When it completes, the name will no longer resolve.
host -t cname test1.app.example.org Host test1.app.example.org not found: 3(NXDOMAIN)
Summary
Now that we've registered a domain, and arranged to have it served by Route53, we can add and remove names. When we configure OpenShift, it will be able to publish new application records.
Next Time
We still have to create hosts to run the OpenShift service. On AWS that means creating instances , virtual machines in Amazon's cloud. Amazon applies some fairly restrictive nework level packet filtering. They use a feature called a securitygroup to define the filtering rules. In the next post, I'll discuss how to create and manage new securitygroups, and what groups we'll need to allow OpenShift to operate.
Resources
- AWS Route53 DNS management console - https://console.aws.amazon.com/route53/home
- ICANN list of Accredited Registrars - http://www.icann.org/registrar-reports/accredited-list.html
- DNS Zones - https://en.wikipedia.org/wiki/DNS_zone
No comments:
Post a Comment