Adventures of a Small Time OpenStack Sysadmin relate the experience of converting a small VMware cluster into two small OpenStack clusters, and the adventures and friends I made along the way.
Adventures of a Small Time OpenStack Sysadmin Chapter 044 - Designate DNS Service aka DaaS DNS as a Service.
First, links to some reference docs I used:
Designate Docs Page
https://docs.openstack.org/designate/yoga/
Kolla-Ansible Projects Deployment Configuration Reference, for Designate, points to:
Kolla-Ansible Networking Guide, Designate Chapter:
https://docs.openstack.org/kolla-ansible/yoga/reference/networking/designate-guide.html
Neutron's notes about integrating with Designate
https://docs.openstack.org/neutron/yoga/admin/config-dns-int.html
DNS integration with an external service AKA the "Use Cases" Document
https://docs.openstack.org/neutron/yoga/admin/config-dns-int-ext-serv.html
My DNS design:
My Samba Active Directory domain is cedar.mulhollon.com, and its advised for anything attached to the AD to point to the domain controllers (I have four virtual machines for DC, two on each OS cluster). So all four DCs are authoritative for cedar.mulhollon.com.
I have four resolver virtual machines. The usual arrangement of two VMs on each cluster. I've fooled around with all kinds of round robin and cross cluster backup and in the end the simplest thing to do is like-to-like, so dc22 lists dns22 as its first samba "dns forwarder" and dns21 as its second backup, and so forth, so generally, dc11 will forward to dns11, etc.
Designate, as configured by hand, in Plan 1.0, was authoritative on a set of Bind 9 installations, one on each OpenStack host. Well, its no longer Plan 1.0 era, its Plan 2.0 era. And Kolla-Ansible by default and somewhat to my surprise spins up a "Bind 9 in a container" on the controller aka os6 for Cluster 2. My primary OpenStack Designate domain for cluster2 will be os2.mulhollon.net. So, os6 is authoritative primary for the domain os2.mulhollon.com (and, eventually, os3 would be auth for os1.mulhollon.com). So that plain old network users can resolve in the os2.mulhollon.com domain, each virtual resolver (the paragraph above...) contains:
type forward;
forward only;
forwarders { 10.10.20.56; };
};
Note that 10.10.20.56 is cluster 2's controller
My strategy is to configure both domains on each cluster such that Heat Orchestration templates can run on EITHER cluster with no change, and DNS resolution will work, of course if you install wiki on cluster 2 the dns entry for wiki.os2.mulhollon.com will work but wiki.os1.mulhollon.com will not work. For "domain wide" DNS I'd be using samba-tool and Samba active directory hostname wiki.cedar.mulhollon.com regardless of which cluster its installed upon anyway.
I have not experienced any problems with this design, so far. But, its early days...
I have been doing DNS "stuff" on and off for about a quarter century now. I have to admit, this is the first time I've configured a DNS server off a REST API, or use a Python library to configure it. Pretty Cool!
Installation Notes
Installation was mostly per the Kolla-Ansible PDCR for Designate, aka the "Kolla-Ansible Networking Guide" Designate chapter.
One minor difference is my configuration strategy is pristine /etc/kolla/globals.yml so I enable_designate: "yes" in /etc/kolla/globals.d/designate.yml
I do not alter my dns_interface setting; the default is network_interface which in my neutron config points to my management LAN. I suspect almost all sysadmins run the default config of putting their Designate traffic over their management LAN, but alternatives are possible.
The default designate_backend is "bind9" and that's what I'm using.
I set my designate_ns_record to my controller, where Kolla-Ansible installed a Docker container of Bind 9.
I don't have multiple Designate-workers so I don't need to worry about how to configure redis to coordinate them.
This rather minimal configuration can be seen at the following link:
Designate CLI Client
You have to install the client before creating zones and doing "Designate Stuff" at the CLI, although I mostly use Heat Orchestration Templates it helps during initial setup and during testing and troubleshooting to have a working CLI.
It boils down to running:
pip install python-designateclient -c https://releases.openstack.org/constraints/upper/yoga
See this link:
https://gitlab.com/SpringCitySolutionsLLC/openstack-scripts/-/blob/master/installcli/installcli.sh
I did not do many demo scripts for Designate but this example shows an interesting characteristic of Designate:
And that characteristic would be, that zones are very much a project-based resource, so specify "--all-projects" to see all the zones/domains or rephrased, if your zone seems missing, your best first troubleshooting step is to see if you're even logged into the correct project...
Nova and Neutron Autoconfiguration
Designate needs a designate-sink.conf file in /etc/kolla/config/designate/designate-sink.conf to tell Neutron and Nova what DNS zones to configure automatically. The architecture page explains designate-sink.
https://docs.openstack.org/designate/latest/contributor/architecture.html#designate-sink
The meaning of the zone_id is completely undocumented but looking at the REST API docs I think its the ID string you see if you run an "openstack zone list" and look at the ID column. I'm pretty sure its not the name of the zone because that would be better named "zone_name"
I have this about 50% working. I'm not entirely sure what 50% is working from day to day. At some later date I will return to this. I'm not super motivated about the time savings of automatic configuration when using the web UI and CLI, because I mostly Heat Template Orchestrate everything and its trivial to use Designate in an orchestration template.
Heat Template Operations
Did an openstack zone create for each separate project, note this needs project_IDs not project names. A typical HEAT template resource zone create looks like:
type: OS::Designate::Zone
properties:
name: "iot.os2.cedar.mulhollon.net."
email: "vince@mulhollon.com"
type: PRIMARY
And here is a link to the entire template containing the above resource in context:
https://gitlab.com/SpringCitySolutionsLLC/openstack-scripts/-/blob/master/projects/iot/iot/iot.yml
After a zone is created, time to stuff it with records. Here's a typical HEAT template resource record:
type: OS::Designate::RecordSet
properties:
type: "A"
zone: "iot.os2.cedar.mulhollon.net."
name: "hawkbit"
records:
- get_attr: [ my_floating_ip, floating_ip_address ]
And here's a link to the entire orchestration template:
I'm not sure I actually "need" Designate but its too cool not to play with. So, I play. So far it all works perfectly, easily, and reliably, although I'm still experimenting with the automatic entry creation feature in Neutron and Nova.
Tomorrow, Blazar Reservation Service.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.