環境
Redhat OpenStack Platform v13(Queens) で検証。
ただし、基本的な動作はQueens以前、Rockyにおいても変わらない。
DNSaaSとは？
DNS as a Serviceの略称。
近年、SaaSやIaaS、PaaSなど色々流行っているが、それと同じようにDNSサービスをクラウドサービスで簡単/自動的に扱えるようにしたもの。
昔ながらにzoneファイルにレコード書いて、BINDに読み込ませたりなどはせず、例えば、ゾーンやレコードの作成/削除の管理をREST APIなどで行えたり、GUIで簡単に操作できたりするようなサービスと考えて良い。
AWSのRoute53がわかりやすいと思う。有名なパブリッククラウドならば同等の機能が実装されている。
Route53のようにレジストラまでの機能はなくとも、例えば、パブリッククラウド上に何らかのインスタンスを作成すると、自動的にレコードが作成されインスタンス名でのアクセスが可能であったりするのも、DNSaaSのおかげ。
OpenStackにおけるDNSaaS
OpenStackにおいてもDNSaaSを実現することが出来る。といっても、Route53のような高機能なものではない。下記のような機能を実現できる。
- インスタンスの作成/削除に応じたレコードの管理
- フローティングIPの割当/解除に応じたレコードの管理
- WebUIからのゾーン/レコードの管理
- ゾーンやレコードの管理機能を持ったREST APIの提供
とはいえ、ユーザーからすれば何もせずともインスタンス名でアクセスできるのは、かなり便利なはず。
OpenStackのようなプライベートクラウドの場合、インスタンスを作成する際に静的にIPアドレスを設定して、さらにそれを意識して運用するパターンはあまりないのではないだろうか。多くの場合DHCPを使っているはず。となれば、大量のインスタンスの様々なIPアドレスを覚えて、アクセスしなくちゃいけないのは、なかなか面倒くさい。
というわけで、多くのユーザー、もちろんOpenStackの管理者側からしても、非常に便利な機能である。
種類
OpenStackにおけるDNSaaSは、大別して2つが存在する。
- Internal DNS Resolution
- External DNS Intergration
名前の如くではあるが、それぞれ名前解決の担当範囲が異なる。
Internal DNS ResolutionはテナントNWを担当し、External DNS Intergrationは外部NWを担当する。
Internal DNS ResolutionはFixed IPを返答し、External DNS IntergrationはフローティングIPを返答する。※正引きなら
Internal DNS Resolution
その名の通りでインターナル、つまりテナント側で自動的にレコードを作って名前解決出来る機能になる。
元々OpenStack環境ではDHCPが動いているが、実態はdnsmasqであり、簡易DNSサーバとしても動いてくれる。
以下のような動作をする。
-
それぞれのテナントNW毎に立ち上がるdnsmasqが機能を司る
- つまりテナントNWが10個あれば、10個分のdnsmasqが勝手に実行されており、それぞれDNSサーバーとして機能している
-
それぞれのdnsmasqが持っているレコードは、自分自身のテナントNW内のインスタンス(ポート)の情報のみ
- 自身のテナントNWに属するインスタンスのレコードしか保持していない
- つまりテナントAのdnsmasqは、テナントA内に属するインスタンスの名前解決は可能だが、テナントBの名前解決は不可
- 仮想ルーターを経由してリーチャビリティがあるテナントNWだとしても、そちらに属するインスタンスの名前解決は不可
- 自分のDNSサーバの向き先である自NWのdnsmasqは別NWのことなんか知ったこっちゃない
- とは言っても名前解決したいはず
- dnsmasqが知らない名前は上位のDNSサーバーにフォワードしてくれるので、フォワード先のほうで解決することが可能＠後述
- 要はフローティングIPを教えてもらう形
- 仮想ルーターを経由してローカルなリーチャビリティがあるのに、一回外に出て通信しなくちゃいけないのは非常に痛い話ではあるが・・
- 自動的に別テナントNWのdnsmasqも考慮してくれるような機能はない(はず)
- ちなみに仮想ルーターでつながっているなら、DNSサーバーとして向こうのNWのdnsmasq(DHCPインターフェース)を指定してしまえば、名前解決自体は出来る
- 別に自分のテナントNWからのみしか受け付けないわけではない
- 当然手動設定が必要
- ただし、これをやると自テナントNW内の名前解決が出来なくなので、正直あまり意味がない
-
テナントNWに属しているインスタンスは勝手にレコードが作られる
- 正確にはインスタンスのインターフェース(ポート)に対してレコードが作られる
- 具体的には、portのdns_nameがレコードに反映される
-
インスタンスにアタッチされているポートのdns_nameを変えると即時に反映される
- 元のやつは当たり前だが消える＠これも即時
-
だがインスタンス名を変えたときはレコードは変わらない
- インスタンス内部でホスト名を直接イジってもそうだし、novaインスタンスそのものの名前を変えてもダメ
- 結局のところアタッチされているポートの名前が変わっていないから
-
インスタンスの初期構築時にアタッチしたテナントNWとは別のテナントNWに後から変えたときでも(インターフェースのデタッチ > アタッチ)、dnsmasq側に反映され、名前解決が可能
-
ドメインはneutron.confの
dns_domainが自動的に使われる- テナントNWの個別設定にもdns_domainというプロパティが存在するが、そこは関係なく、そこに何のドメインを指定しても、ここでは使われない
- あくまでneutron.confのdns_domainドメインが使われる
- ただしフローティングIPは別で、テナントNWのdns_domainが使われる＠後述
-
デフォルト動作で自分が知らない名前については、指定した上位のDNSサーバーにフォワードしてくれる
- /etc/neutron/dhcp_agent.ini:dnsmasq_dns_servers
- 自分が担当しているゾーンで知らない存在だとしてもnullで返したりはしない
-
特に指定がない限り、デフォルト状態でインスタンスのDNSサーバーの指定は、dnsmasqに向いている。
- DHCPでdnsmasqを向くような設定が配られている
External DNS Intergration
Internal DNS ResolutionはOpenStack内部に閉じた名前解決の方法であり、外部側、例えばOpenStackの外側のサーバからOpenStack内部のインスタンスの名前解決は行えない。
これを解決するための機能として、External DNS Intergrationがある。
Intergration、連携という名前の通り、外部のDNSサーバとOpenStackを連携させることで実現させる。
具体的には、DesignateというOSSのDNSaaSを用意し、OpenStackのネットワーク機能を司るNeutronと連携させることで、フローティングIP-インスタンス名の名前解決を実現できる。
OpenStackとDesignateの連携方法は2つ存在する。
-
メッセージサービス連携
- OpenStackが内部処理で色々使っているメッセージサービス(oslo)と連携させる方法
-
neutron-api連携
- neutron.conf自体にdesignateを連携させる設定を書いて、neutron-serverの動きとして何かあったらdesignateに連携しにいくような挙動をとる
- 今はこっちが主流な方式
メッセージサービス連携
- designate-sinkというサービスが立ち上がってることが条件
- OpenStackメッセージサービスのosloと連携し、インスタンスに対するフローティングIPやFixed IPの割当/解除に応じて発火されるイベントを捕まえて、内容に応じてDesignate側で自動的にレコード作成/削除をしてくれる。
- イベントのペイロードとして、ホスト名やIPアドレスが入っているので、それを使ってレコードを作る
- ただし、neutronから流れてくるイベントにはホスト名が入っていない
- フローティングIPやポート、ネットワーク自体にdns_nameやdns_domainを入れておいてもイベントには入っていない
- なので、ホスト名-IPアドレスのレコードが作れない
- これが非常に致命的
- 設定でどうにかなると思って頑張って探したが、今の所見つけられていない
- 一方でプロジェクト名が入っているので、プロジェクト毎にサブドメインを切る、みたいな形りやすい
- フローティングIPやポート、ネットワーク自体にdns_nameやdns_domainを入れておいてもイベントには入っていない
- だが、どうも長時間アイドルが続くとイベントへの反応がおかしいような挙動を見せている
- 本方式でDesignate連携をした後、何も操作せず一晩放置、全く同じことを再度試しても、designate-sinkが無反応、といったことが度々あった
- 現状、何故こうなってしまっているのか調査できていない
- 時間ができたら調査したい
neutron-api連携
-
Neutronに実装されている外部DNS連携機能を使って、Designateと連携する方法
-
インスタンスに対するフローティングIPの割当/解除に応じて、NeutronがDesignateのレコードの作成/削除のAPIを叩きに行く。
-
メッセージサービス連携と異なり、正しくホスト名-IPアドレスのレコードも作ってくれるし、消してもくれる
- ただしインスタンス名を変えても、レコードを再作成したりはしない
- いったんフローティングIPを外して、もう一度割り当てても同じ
- 何故かと言うと、NeutronがDesignateに連携しに行くときの情報として使用しているのは、インスタンスの名前ではなく、インスタンスにアタッチされているポートの名前(dns_name)だから
- インスタンス名を変えても、ポートの名前自体は変わらない
- Internal DNS Resolutionと同じ挙動
- 結局フローティングIP-インスタンス名ではなく、フローティングIP-ポート名のレコードが作成される
- なのでポート名(dns_name)を直接変更した上で、フローティングIPを外す/割り当てるをやればOK
- ただしインスタンス名を変えても、レコードを再作成したりはしない
-
ただしレコードの削除は、明示的にフローティングIPの解除をしないとやってくれない
- インスタンスの削除では連携してくれない = レコードが残り続ける
-
ただし、その後競合するIPアドレスのレコードが追加されるときに一緒に削除もやってくれるで、ゴミが残り続けるということではない
- 逆に言えばフローティングIPが使われず、ずっと浮いたままなら残り続けることになるが* * *
-
また連携をする最低条件として、ネットワークやフローティングIPにdns_domainを付与しておないといけない
- そうしないとdesignate連携が働かないようになっている
- OpenStackのドメイン(neutron.conf:dns_domain)そのものを見ているわけではない
-
逆に言えば、テナントNWのdns_domainに書いてある通りにdesignate側に連携しにいくので、サブドメインったり、全く別のドメインにしてレコードを作る、といったことも可能
-
ネットワークやフローティングIPにdns_domain入れるにはコマンドかAPI叩かないとダメ
- horizonから指定はできない
- これがきつい
- つまりユーザーがHorizonからテナントNWを作ったとして、その配下にインスタンスを作成し、フローティングIPを割り当てても、Designateには連携されない
-
この方式では、designate-sinkは停止状態で問題ない
動作確認
環境
Neutron側の設定
準備
[heat-admin@ctrl001 ~]$ sudo docker ps | grep neutron-server
133dd7d7feed registry.access.redhat.com/rhosp13/openstack-neutron-server:13.0-58 "kolla_start" 4 weeks ago Up 4 weeks (healthy) neutron_api
[heat-admin@ctrl001 ~]$
[heat-admin@ctrl001 ~]$ sudo docker exec -it 133dd7d7feed bash
/etc/neutron/neutron.conf:dns_domainの設定。この設定が、OpenStackの中で統一的に使われるNWレベルでのドメイン設定となる。
()[neutron@ctrl001 /]$ grep -B2 dns_domain /etc/neutron/neutron.conf
# Domain to use for building the hostnames (string value)
# dns_domain = openstacklocal
dns_domain=dev.hogehoge.local
パラメータがわかりきっているなら、crudiniコマンドのほうがカッコいい表示の仕方かもしれない。
()[neutron@ctrl001 /]$ crudini --get /etc/neutron/neutron.conf DEFAULT dns_domain
dev.hogehoge.local
同じくneutron.confで重要なのが、External DNS Intergration実現のための設定。
このあたりの設定および構築まわりの話は別記事にて記述する予定。
()[neutron@ctrl001 /]$ grep -B2 external_dns_driver /etc/neutron/neutron.conf
# Driver for external DNS integration. (string value)
# external_dns_driver = <None>
external_dns_driver = designate
()[neutron@ctrl001 /]$
()[neutron@ctrl001 /]$ grep -A2 "\[designate" /etc/neutron/neutron.conf
[designate]
url = http://172.24.20.82:9001/v2
allow_reverse_dns_lookup = false
crudiniを使うパターン
()[neutron@ctrl001 /]$ crudini --get /etc/neutron/neutron.conf DEFAULT external_dns_driver
designate
()[neutron@ctrl001 /]$
()[neutron@ctrl001 /]$ crudini --get /etc/neutron/neutron.conf designate url
http://172.24.20.82:9001/v2
()[neutron@ctrl001 /]$ crudini --get /etc/neutron/neutron.conf designate allow_reverse_dns_lookup
false
ちなみに、RHOSPだとpuppetを使って自動的に設定を生成するため、コントローラノード内部からすると以下のパスになる。
[heat-admin@ctrl001 ~]$ sudo grep -B 2 dns_domain /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
# Domain to use for building the hostnames (string value)
# dns_domain = openstacklocal
dns_domain=dev.hogehoge.local
[heat-admin@ctrl001 ~]$
[heat-admin@ctrl001 ~]$ sudo crudini --get /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf DEFAULT dns_domain
dev.hogehoge.local
また、もう1つ重要な設定が下記の/etc/neutron/neutron.conf:dnsmasq_dns_serversになる。
これに上位のDNSサーバー、今回で言えばDesignateサーバーを指定することで、dnsmasqが知らない名前orIPアドレスなら、ここにフォワードして名前解決してくれる。
()[neutron@ctrl001 /]$ grep -B 3 dnsmasq_dns_servers= /etc/neutron/dhcp_agent.ini
# Comma-separated list of the DNS servers which will be used as forwarders.
# (list value)
# dnsmasq_dns_servers =
dnsmasq_dns_servers=172.24.20.82
()[neutron@ctrl001 /]$
()[neutron@ctrl001 /]$ crudini --get /etc/neutron/dhcp_agent.ini DEFAULT dnsmasq_dns_servers
172.24.20.82
NW
下記、3つのテナントNWを用意
-
tokyo
- 192.168.0.0/24
-
osaka
- 10.10.10.0/24
-
kyoto
- 10.200.200.0/24
openstack network listコマンドで確認すると以下の通り。
ちなみに、publicは外部へとつながるExternal NWのこと。
(overcloud) [stack@director01 ~]$ openstack network list
+--------------------------------------+--------+--------------------------------------+
| ID | Name | Subnets |
+--------------------------------------+--------+--------------------------------------+
| 2825f51a-ef89-4f0d-a7e3-540e997244ad | tokyo | f6dfe617-81a0-4e17-af79-d93c9ff5fbf8 |
| 3f01c440-4ceb-431c-b978-d01018ffdfe9 | public | 67fd5e39-a2e6-40e8-991d-86bc771ad9ab |
| d89cc885-a922-41e1-b32d-525f8a974983 | kyoto | aa6af2a5-2c13-4c69-8417-0f7939df1a46 |
| fa0af7d7-5d5a-4095-beec-9ba710b4741a | osaka | 64e3211f-eda4-43d0-bcb5-8bda6e819352 |
+--------------------------------------+--------+--------------------------------------+
また、ルーターとして、router-1とrouter-2を作成。
(overcloud) [stack@director01 ~]$ openstack router list
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 5e8718ec-d2e3-472a-b8fe-f5479c407ca8 | router-1 | ACTIVE | UP | False | False | 1d20ed74c81e42f49e01b394492391d7 |
| 6c9c6c16-484c-4952-8dfa-f57f6bb421f1 | router-2 | ACTIVE | UP | False | False | 1d20ed74c81e42f49e01b394492391d7 |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
router-1には、tokyoとosakaを接続。
router-2には、kyotoを接続。
これにより、tokyoとosakaはリーチャビリティがある状態であり、Fixed IPでの双方向通信が可能。
kyotoに関しては、tokyoとosakaとは一切のリーチャビリティがない。
単純にHorizonからテナントNWを作成した段階では、テナントNWに対してdns_domainが付与されていない状態であるため、neutron net-update [nw] --dns_domainコマンドで明示的に指定する。
※RHOSP v13(Queens)では、openstack network setコマンドでdns_domainを付与できない、いずれVerUPで対応すると思う
(overcloud) [stack@director01 ~]$ neutron net-update tokyo --dns_domain dev.hogehoge.local.
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated network: tokyo
(overcloud) [stack@director01 ~]$
(overcloud) [stack@director01 ~]$ neutron net-update osaka --dns_domain dev.hogehoge.local.
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated network: osaka
(overcloud) [stack@director01 ~]$
(overcloud) [stack@director01 ~]$ neutron net-update kyoto --dns_domain dev.hogehoge.local.
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated network: kyoto
tokyoの詳細パラメータ
(overcloud) [stack@director01 ~]$ openstack network show tokyo
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2019-01-18T02:13:10Z |
| description | |
| dns_domain | dev.hogehoge.local. |
| id | 2825f51a-ef89-4f0d-a7e3-540e997244ad |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | None |
| is_vlan_transparent | None |
| mtu | 1450 |
| name | tokyo |
| port_security_enabled | True |
| project_id | 1d20ed74c81e42f49e01b394492391d7 |
| provider:network_type | vxlan |
| provider:physical_network | None |
| provider:segmentation_id | 19 |
| qos_policy_id | None |
| revision_number | 5 |
| router:external | Internal |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | f6dfe617-81a0-4e17-af79-d93c9ff5fbf8 |
| tags | |
| updated_at | 2019-01-18T04:35:51Z |
+---------------------------+--------------------------------------+
osakaの詳細パラメータ
(overcloud) [stack@director01 ~]$ openstack network show osaka
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2019-01-18T02:14:04Z |
| description | |
| dns_domain | dev.hogehoge.local. |
| id | fa0af7d7-5d5a-4095-beec-9ba710b4741a |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | None |
| is_vlan_transparent | None |
| mtu | 1450 |
| name | osaka |
| port_security_enabled | True |
| project_id | 1d20ed74c81e42f49e01b394492391d7 |
| provider:network_type | vxlan |
| provider:physical_network | None |
| provider:segmentation_id | 60 |
| qos_policy_id | None |
| revision_number | 5 |
| router:external | Internal |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | 64e3211f-eda4-43d0-bcb5-8bda6e819352 |
| tags | |
| updated_at | 2019-01-18T04:36:03Z |
+---------------------------+--------------------------------------+
kyotoの詳細パラメータ
(overcloud) [stack@director01 ~]$ openstack network show kyoto
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2019-01-18T05:07:48Z |
| description | |
| dns_domain | dev.hogehoge.local. |
| id | d89cc885-a922-41e1-b32d-525f8a974983 |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | None |
| is_vlan_transparent | None |
| mtu | 1450 |
| name | kyoto |
| port_security_enabled | True |
| project_id | 1d20ed74c81e42f49e01b394492391d7 |
| provider:network_type | vxlan |
| provider:physical_network | None |
| provider:segmentation_id | 58 |
| qos_policy_id | None |
| revision_number | 5 |
| router:external | Internal |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | aa6af2a5-2c13-4c69-8417-0f7939df1a46 |
| tags | |
| updated_at | 2019-01-18T05:09:29Z |
+---------------------------+--------------------------------------+
インスタンス
それぞれのNWに対して、インスタンスを2台ずつ作成し、DHCPにてFixed IPを割り当てる。
また、osaka-pc-2とkyoto-pc-2以外については、フローティングIPも割り当てる。
| Instance Name | NW | Fixed IP | Floating IP |
|---|---|---|---|
| tokyo-pc-1 | tokyo | 192.168.0.5 | 172.24.20.56 |
| tokyo-pc-2 | tokyo | 192.168.0.4 | 172.24.20.58 |
| osaka-pc-1 | osaka | 10.10.10.12 | 172.24.20.87 |
| osaka-pc-2 | osaka | 10.10.10.4 | - |
| kyoto-pc-1 | kyoto | 10.200.200.5 | 172.24.20.92 |
| kyoto-pc-2 | kyoto | 10.200.200.8 | - |
一応、1台だけピックアップして、resolv.confとhostsの情報を載せておく。
search dev.hogehoge.localとなっているため、ドメインを明示的に指定しなくても、勝手にdev.hogehoge.localを付与して通信してくれる。
nameserverとして、.2のIPアドレスが付与されているが、これはデフォルトの挙動。
.2は、テナントNWのDHCPインターフェースであり、これの実態はdnsmasqである。
[centos@tokyo-pc-1 ~]$ cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
; generated by /usr/sbin/dhclient-script
search dev.hogehoge.local
nameserver 192.168.0.2
CLIで確認してみると、確かに.2はDHCPインターフェースであることが確認できる。
※device_ownerがdhcpになっている
(overcloud) [stack@director01 ~]$ openstack port list | grep 192.168.0.2
| 4a5aa72a-46ba-4807-b00b-3258e4453d4c | | fa:16:3e:d0:b3:e4 | ip_address='192.168.0.2', subnet_id='f6dfe617-81a0-4e17-af79-d93c9ff5fbf8' | ACTIVE |
(overcloud) [stack@director01 ~]$
(overcloud) [stack@director01 ~]$ openstack port show 4a5aa72a-46ba-4807-b00b-3258e4453d4c
+-----------------------+------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+------------------------------------------------------------------------------------------------+
| admin_state_up | UP |
| allowed_address_pairs | |
| binding_host_id | None |
| binding_profile | None |
| binding_vif_details | None |
| binding_vif_type | None |
| binding_vnic_type | normal |
| created_at | 2019-01-18T02:13:12Z |
| data_plane_status | None |
| description | |
| device_id | dhcp50e004cc-50e8-5a76-ae09-2af98f9aa4a6-2825f51a-ef89-4f0d-a7e3-540e997244ad |
| device_owner | network:dhcp |
| dns_assignment | fqdn='host-192-168-0-2.dev.hogehoge.local.', hostname='host-192-168-0-2', ip_address='192.168.0.2' |
| dns_name | |
| extra_dhcp_opts | |
| fixed_ips | ip_address='192.168.0.2', subnet_id='f6dfe617-81a0-4e17-af79-d93c9ff5fbf8' |
| id | 4a5aa72a-46ba-4807-b00b-3258e4453d4c |
| ip_address | None |
| mac_address | fa:16:3e:d0:b3:e4 |
| name | |
| network_id | 2825f51a-ef89-4f0d-a7e3-540e997244ad |
| option_name | None |
| option_value | None |
| port_security_enabled | False |
| project_id | 1d20ed74c81e42f49e01b394492391d7 |
| qos_policy_id | None |
| revision_number | 7 |
| security_group_ids | |
| status | ACTIVE |
| subnet_id | None |
| tags | |
| trunk_details | None |
| updated_at | 2019-01-18T02:13:15Z |
+-----------------------+------------------------------------------------------------------------------------------------+
ちなみに、インスタンスに接続されているインタフェース(ポート)を見てみると、comupte:novaになっている。
(overcloud) [stack@director01 ~]$ openstack port show 628ca9eb-cffc-4502-86d2-6c4e58458e93 -c device_owner -c dns_name
+--------------+--------------+
| Field | Value |
+--------------+--------------+
| device_owner | compute:nova |
| dns_name | tokyo-pc-1 |
+--------------+--------------+
hostsの情報。localhost系しか載っていないので、この状態では自身のホスト名で名前解決ができないはず。
[centos@tokyo-pc-1 ~]$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Designateの設定
// ごめんなさい、構築の詳細は別記事で書きます。
[root@designate ~]# rpm -qa | grep designate
openstack-designate-api-6.0.1-1.el7.noarch
openstack-designate-central-6.0.1-1.el7.noarch
openstack-designate-agent-6.0.1-1.el7.noarch
openstack-designate-common-6.0.1-1.el7.noarch
openstack-designate-worker-6.0.1-1.el7.noarch
openstack-designate-zone-manager-6.0.1-1.el7.noarch
python-designate-6.0.1-1.el7.noarch
openstack-designate-pool-manager-6.0.1-1.el7.noarch
openstack-designate-producer-6.0.1-1.el7.noarch
python2-designateclient-2.9.0-1.el7.noarch
openstack-designate-mdns-6.0.1-1.el7.noarch
openstack-designate-sink-6.0.1-1.el7.noarch
openstack-designate-ui-6.0.0-1.el7.noarch
同一テナントNW間での名前解決
自分自身を参照
※ tokyo-pc-1 -> tokyo-pc-1
Aレコードで、192.168.0.5が返ってきており、正常に名前解決(正引き)できている。
[centos@tokyo-pc-1 ~]$ dig tokyo-pc-1.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> tokyo-pc-1.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16274
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tokyo-pc-1.dev.hogehoge.local. IN A
;; ANSWER SECTION:
tokyo-pc-1.dev.hogehoge.local. 0 IN A 192.168.0.5
;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 04:53:39 UTC 2019
;; MSG SIZE rcvd: 70
別のインスタンスの名前解決
※ tokyo-pc-1 -> tokyo-pc-2
Aレコードで、192.168.0.4が返ってきており、正常に名前解決(正引き)できている。
[centos@tokyo-pc-1 ~]$ dig tokyo-pc-2.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> tokyo-pc-2.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50271
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tokyo-pc-2.dev.hogehoge.local. IN A
;; ANSWER SECTION:
tokyo-pc-2.dev.hogehoge.local. 0 IN A 192.168.0.4
;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 04:54:16 UTC 2019
;; MSG SIZE rcvd: 70
ちなみに、ドメインを指定しなくてもOK
※dnsmasqの挙動として、dev.hogehoge.localがルートゾーンとなっている模様
[centos@tokyo-pc-1 ~]$ dig tokyo-pc-2
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> tokyo-pc-2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7698
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tokyo-pc-2. IN A
;; ANSWER SECTION:
tokyo-pc-2. 0 IN A 192.168.0.4
;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 04:54:45 UTC 2019
;; MSG SIZE rcvd: 55
仮想ルーターで接続された別テナントNWへ対する名前解決
※ tokyo-pc-1 -> osaka-pc-1
Aレコードで、172.24.20.87が返ってきており、正常に名前解決(正引き)できている。
192.168.0.2のdnsmasqが、上位のDNSサーバー(Designateサーバ)にフォワードして聞いてくれているため、フローティングIPで名前解決することが可能。
[centos@tokyo-pc-1 ~]$ dig osaka-pc-1.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> osaka-pc-1.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7586
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;osaka-pc-1.dev.hogehoge.local. IN A
;; ANSWER SECTION:
osaka-pc-1.dev.hogehoge.local. 7200 IN A 172.24.20.87
;; AUTHORITY SECTION:
dev.hogehoge.local. 7200 IN NS ns.dev.hogehoge.local.
;; Query time: 2 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 05:27:30 UTC 2019
;; MSG SIZE rcvd: 87
ただし、ドメインは絶対に付与していないとダメ。
Designateサーバー内のBINDでは、明示的にゾーンが区切られているため、ドメインが付与されていないと、BIND側で判断ができない。
[centos@tokyo-pc-1 ~]$ dig osaka-pc-1
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> osaka-pc-1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55373
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;osaka-pc-1. IN A
;; AUTHORITY SECTION:
. 7099 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019011702 1800 900 604800 86400
;; Query time: 4 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 05:28:36 UTC 2019
;; MSG SIZE rcvd: 114
と言っても、適切にDNS関連設定がされていれば(resolv.conf:serach xxxx)、自動的にドメインが付与されて通信されるので、問題ない
[centos@tokyo-pc-1 ~]$ grep search /etc/resolv.conf
search dev.hogehoge.local
[centos@tokyo-pc-1 ~]$ ping -c 1 osaka-pc-1
PING osaka-pc-1.dev.hogehoge.local (172.24.20.87) 56(84) bytes of data.
64 bytes from 172.24.20.87 (172.24.20.87): icmp_seq=1 ttl=63 time=0.865 ms
--- osaka-pc-1.dev.hogehoge.local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.865/0.865/0.865/0.000 ms
フローティグIPが付与されていないと応答されない
※ Designateに連携されるのは、あくまでフローティングIPが割り当てられたインスタンスのみであるため
[centos@tokyo-pc-1 ~]$ dig osaka-pc-2.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> osaka-pc-2.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21818
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;osaka-pc-2.dev.hogehoge.local. IN A
;; AUTHORITY SECTION:
dev.hogehoge.local. 3600 IN SOA ns.dev.hogehoge.local. joe.example.org. 1547788376 3551 600 86400 3600
;; Query time: 2 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 05:29:36 UTC 2019
;; MSG SIZE rcvd: 108
とはいえ仮想ルーターで接続されてはいるため、Fixed IPで接続可能
※名前解決ができないだけ
下記、例の通り、ホスト名でアクセス(フローティングIP経由)し、その後Fixed IPの明示的指定でもアクセスできている。
[centos@tokyo-pc-1 ~]$ dig +noall osaka-pc-1.dev.hogehoge.local +ans
osaka-pc-1.dev.hogehoge.local. 6823 IN A 172.24.20.87
[centos@tokyo-pc-1 ~]$
[centos@tokyo-pc-1 ~]$ ssh centos@osaka-pc-1
centos@osaka-pc-1's password:
Last login: Fri Jan 18 05:33:21 2019 from 172.24.20.56
[centos@osaka-pc-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:a1:6c:87 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.12/24 brd 10.10.10.255 scope global dynamic eth0
valid_lft 74944sec preferred_lft 74944sec
inet6 fe80::f816:3eff:fea1:6c87/64 scope link
valid_lft forever preferred_lft forever
[centos@osaka-pc-1 ~]$
[centos@osaka-pc-1 ~]$ exit
ログアウト
Connection to osaka-pc-1 closed.
[centos@tokyo-pc-1 ~]$ ssh centos@10.10.10.12
centos@10.10.10.12's password:
Last login: Fri Jan 18 05:34:42 2019 from 192.168.0.5
[centos@osaka-pc-1 ~]$
なので、フローティングIPが付与されていないosaka-pc-2に対しても、名前解決ができないだけで、Fixed IP経由ではアクセス可能。
[centos@tokyo-pc-1 ~]$ ssh centos@osaka-pc-2
ssh: Could not resolve hostname osaka-pc-2: Name or service not known
[centos@tokyo-pc-1 ~]$ ping -c 1 10.10.10.4
PING 10.10.10.4 (10.10.10.4) 56(84) bytes of data.
64 bytes from 10.10.10.4: icmp_seq=1 ttl=63 time=0.499 ms
--- 10.10.10.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.499/0.499/0.499/0.000 ms
[centos@tokyo-pc-1 ~]$
[centos@tokyo-pc-1 ~]$ ssh centos@10.10.10.4
centos@10.10.10.4's password:
Last login: Fri Jan 18 05:32:21 2019 from 192.168.0.5
[centos@osaka-pc-2 ~]$
仮想ルーターで接続されていない別テナントNWへ対する名前解決
osakaと異なり、tokyo-kyotoのような仮想ルーター経由でのリーチャビリティが存在しない場合の挙動。
tokyo-pc-1 -> kyoto-pc-1
結局、フローティグIPさえ割り当てられていれば、名前解決は可能。もちろん、通信も。
[centos@tokyo-pc-1 ~]$ dig kyoto-pc-1.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> kyoto-pc-1.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;kyoto-pc-1.dev.hogehoge.local. IN A
;; ANSWER SECTION:
kyoto-pc-1.dev.hogehoge.local. 7200 IN A 172.24.20.92
;; AUTHORITY SECTION:
dev.hogehoge.local. 7200 IN NS ns.dev.hogehoge.local.
;; Query time: 3 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 05:36:29 UTC 2019
;; MSG SIZE rcvd: 87
osakaと同じく、フローティングIPが付与されていなければ、名前解決不可。
名前解決の挙動に関して、仮想ルーターの接続性は関係ない。
[centos@tokyo-pc-1 ~]$ dig kyoto-pc-2.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> kyoto-pc-2.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5443
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;kyoto-pc-2.dev.hogehoge.local. IN A
;; AUTHORITY SECTION:
dev.hogehoge.local. 3600 IN SOA ns.dev.hogehoge.local. joe.example.org. 1547788376 3551 600 86400 3600
;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 05:36:33 UTC 2019
;; MSG SIZE rcvd: 108
仮想ルーターでつながっていない以上、フローティングIP経由でしか通信は出来ない。
当然、Fixed IPでの接続は出来ない。
[centos@tokyo-pc-1 ~]$ dig +noall kyoto-pc-1.dev.hogehoge.local +ans
kyoto-pc-1.dev.hogehoge.local. 7068 IN A 172.24.20.92
[centos@tokyo-pc-1 ~]$
[centos@tokyo-pc-1 ~]$
[centos@tokyo-pc-1 ~]$ ssh centos@kyoto-pc-1
centos@kyoto-pc-1's password:
Last login: Fri Jan 18 05:38:01 2019 from 172.24.20.56
[centos@kyoto-pc-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:c6:70:21 brd ff:ff:ff:ff:ff:ff
inet 10.200.200.5/24 brd 10.200.200.255 scope global dynamic eth0
valid_lft 84734sec preferred_lft 84734sec
inet6 fe80::f816:3eff:fec6:7021/64 scope link
valid_lft forever preferred_lft forever
[centos@kyoto-pc-1 ~]$
[centos@kyoto-pc-1 ~]$ exit
ログアウト
Connection to kyoto-pc-1 closed.
[centos@tokyo-pc-1 ~]$ ssh centos@10.200.200.5
ssh: connect to host 10.200.200.5 port 22: Connection timed out
Internal DNS ResolutionとExternal DNS Intergration発動時のパケットを見てみる。
tokyo-pc-1インスタンス / コントローラノード / Designateサーバー を使い、tokyo-pc-1から名前解決実行時に、dnsmasqが存在するコントローラノードと上位のDNSサーバーであるDesignateサーバー内で、どうパケットが流れているかtcpdumpした結果。
tokyo-pc-1で、Internal DNS Resolutionとして、tokyo-pc-2の名前解決を実行。
また、External DNS Intergrationとして、osaka-pc-1の名前解決を実行。
[centos@tokyo-pc-1 ~]$ dig +noall tokyo-pc-2.dev.hogehoge.local +ans
tokyo-pc-2.dev.hogehoge.local. 0 IN A 192.168.0.4
[centos@tokyo-pc-1 ~]$ dig +noall osaka-pc-1.dev.hogehoge.local +ans
osaka-pc-1.dev.hogehoge.local. 7200 IN A 172.24.20.87
下記が、コントローラノードでのログ。
と、tcpdumpの前に。まず、dnsmasqがどのコンテナで動いているかを確認する。
長くて申し訳ないが、一行目がtokyoのためのdnsmasqであると推測。
NeutronはLinux Kernelのネットワーク関連機能であるネームスペース機能(ip netns)を使って、テナントNWとして空間を独立させて、それぞれのテナントNWを動かしている。
dockerコンテナの実行コマンドとして、ip netns exec qdhcp-2825f51a-ef89-4f0d-a7e3-540e997244ad が実行されていることから、qdhcp-2825f51a-ef89-4f0d-a7e3-540e997244adがtokyoのためのネームスペースであることがわかる。
※本当はもっと別のコマンドで順序立てて確認するのだが、この方法が一番手っ取り早い (と個人的に思っている)
前後して大変わかりにくいかもしれないが、この確認は、tokyo-pc-1からのdig実行より前に事前に実施。
[heat-admin@ctrl001 ~]$ sudo docker ps --no-trunc | grep 192.168.0.
4b79cbc1c66a9a410eafe3e28d9eaf6cd74f24cf29ce311361d94ff1f1be2f0b registry.access.redhat.com/rhosp13/openstack-neutron-dhcp-agent:13.0-60 "ip netns exec qdhcp-2825f51a-ef89-4f0d-a7e3-540e997244ad /usr/sbin/dnsmasq -k --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/2825f51a-ef89-4f0d-a7e3-540e997244ad/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/2825f51a-ef89-4f0d-a7e3-540e997244ad/host --addn-hosts=/var/lib/neutron/dhcp/2825f51a-ef89-4f0d-a7e3-540e997244ad/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/2825f51a-ef89-4f0d-a7e3-540e997244ad/opts --dhcp-leasefile=/var/lib/neutron/dhcp/2825f51a-ef89-4f0d-a7e3-540e997244ad/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=tap4a5aa72a-46 --dhcp-range=set:tag0,192.168.0.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --server=172.24.20.82 --domain=dev.hogehoge.local" 4 minutes ago Up 4 seconds neutron-dnsmasq-qdhcp-2825f51a-ef89-4f0d-a7e3-540e997244ad
663ca24a674bae2656c4b09a9c24e50ea30648ad09244642c42b7571b12c831f registry.access.redhat.com/rhosp13/openstack-neutron-dhcp-agent:13.0-60 "ip netns exec qdhcp-9168b38c-42f4-4bbf-bb13-9cd27795ece9 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/9168b38c-42f4-4bbf-bb13-9cd27795ece9/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/9168b38c-42f4-4bbf-bb13-9cd27795ece9/host --addn-hosts=/var/lib/neutron/dhcp/9168b38c-42f4-4bbf-bb13-9cd27795ece9/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/9168b38c-42f4-4bbf-bb13-9cd27795ece9/opts --dhcp-leasefile=/var/lib/neutron/dhcp/9168b38c-42f4-4bbf-bb13-9cd27795ece9/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=tap518baff0-e0 --dhcp-range=set:tag0,192.168.0.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --server=172.24.20.82 --domain=dev.hogehoge.local" 6 hours ago Up 6 hours neutron-dnsmasq-qdhcp-9168b38c-42f4-4bbf-bb13-9cd27795ece9
ネームスペースがわかったので、そのネームスペース狙い撃ちでtcpdumpを実行させる。
で、その後にtokyo-pc-1から名前解決を実行する。
見ての通り、192.168.0.5、つまりtokyo-pc-1からtokyo-pc-2についての問い合わせが来て、正しく応答している。
およそ10秒経って、osaka-pc-1の名前解決が届いている。これについてはtokyoのdnsmasqが全く知らないので、172.24.20.82の上位のDNSサーバー、Designateサーバーに対してフォワードしている。
結果、正しく正引きできたので、その内容をtokyo-pc-1に対して返答している。
[heat-admin@ctrl001 ~]$ sudo ip netns exec qdhcp-2825f51a-ef89-4f0d-a7e3-540e997244ad tcpdump -i any port 53 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:40:46.263049 IP 192.168.0.5.39358 > 192.168.0.2.domain: 51616+ [1au] A? tokyo-pc-2.dev.hogehoge.local. (54)
16:40:46.263159 IP 192.168.0.2.domain > 192.168.0.5.39358: 51616* 1/0/1 A 192.168.0.4 (70)
16:40:57.482715 IP 192.168.0.5.46075 > 192.168.0.2.domain: 62797+ [1au] A? osaka-pc-1.dev.hogehoge.local. (54)
16:40:57.482991 IP 192.168.0.2.11666 > 172.24.20.82.domain: 40391+ [1au] A? osaka-pc-1.dev.hogehoge.local. (54)
16:40:57.484344 IP 172.24.20.82.domain > 192.168.0.2.11666: 40391* 1/1/1 A 172.24.20.87 (87)
16:40:57.484440 IP 192.168.0.2.domain > 192.168.0.5.46075: 62797* 1/1/1 A 172.24.20.87 (87)
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
同じタイミングで、Designateサーバーのほうでもtcpdumpを実行させておく。
上述したdnsmasq側でのDesignateサーバーへのフォワード通信のみ流れてきている。
[root@designate ~]# tcpdump -i eth0 port 53 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:40:57.488143 IP 172.24.20.55.11666 > 192.168.100.5.domain: 40391+ [1au] A? osaka-pc-1.dev.hogehoge.local. (54)
16:40:57.488313 IP 192.168.100.5.domain > 172.24.20.55.11666: 40391* 1/1/1 A 172.24.20.87 (87)
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
[root@designate ~]#
Designateの挙動
Neutron APIとしてのExternal DNS Intergrationを構成した際の挙動を記載する。
以下のログは、インスタンスにフローティングIPが付与され、NeutronがDesignateにレコードを追加しようと連携した際のログとなる。
デバッグログも表示させてしまっているため、大分見づらくなってしまっているが・・・
/var/log/designate/api.log
/var/log/designate/api.log
2019-01-18 05:12:56.730 825 DEBUG designate.central.rpcapi [req-71b7f98c-a49f-4510-933f-aeea8572fa5a noauth-user noauth-project - - -] Calling designate.central.find_zones() over RPC wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:56.743 825 INFO designate.api.v2.controllers.zones [req-71b7f98c-a49f-4510-933f-aeea8572fa5a noauth-user noauth-project - - -] Retrieved <Zone count:'1' object:'ZoneList'>
2019-01-18 05:12:56.744 825 INFO eventlet.wsgi [req-71b7f98c-a49f-4510-933f-aeea8572fa5a noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:56] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.014472
2019-01-18 05:12:56.748 825 DEBUG designate.central.rpcapi [req-debbcf1b-fd4f-4aec-a240-4031030d8d22 noauth-user noauth-project - - -] Calling designate.central.get_zone() over RPC wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:56.758 825 INFO designate.api.v2.controllers.zones [req-debbcf1b-fd4f-4aec-a240-4031030d8d22 noauth-user noauth-project - - -] Retrieved <Zone id:'a389943d-e343-4736-b171-4cdb24d24860' type:'PRIMARY' name:'dev.hogehoge.local.' pool_id:'794ccc2c-d751-44fe-b57f-8894c9f5c842' serial:'1547788362' action:'NONE' status:'ACTIVE'>
2019-01-18 05:12:56.759 825 INFO eventlet.wsgi [req-debbcf1b-fd4f-4aec-a240-4031030d8d22 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:56] "GET /v2/zones/a389943d-e343-4736-b171-4cdb24d24860 HTTP/1.1" 200 797 0.011927
2019-01-18 05:12:56.763 825 DEBUG designate.objects.adapters.base [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] Creating RecordSet object with values {u'records': [u'172.24.20.92'], u'type': u'A', u'name': u'kyoto-pc-1.dev.hogehoge.local.'} parse /usr/lib/python2.7/site-packages/designate/objects/adapters/base.py:162
2019-01-18 05:12:56.763 825 DEBUG designate.objects.recordset [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] Validating 'RecordSet' object with values: {'records': [{'data': u'172.24.20.92'}], 'type': u'A', 'name': u'kyoto-pc-1.dev.hogehoge.local.'} validate /usr/lib/python2.7/site-packages/designate/objects/recordset.py:166
2019-01-18 05:12:56.766 825 DEBUG designate.objects.base [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] Validating 'RecordSet' object with values: {'records': [{'address': u'172.24.20.92'}], 'type': u'A', 'name': u'kyoto-pc-1.dev.hogehoge.local.'} validate /usr/lib/python2.7/site-packages/designate/objects/base.py:336
2019-01-18 05:12:56.766 825 DEBUG designate.central.rpcapi [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] Calling designate.central.create_recordset() over RPC wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:56.872 825 INFO eventlet.wsgi [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:56] "POST /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets HTTP/1.1" 202 864 0.110299
重要な箇所だけ抜き出す。
まず、Neutron(172.24.20.3)がDesignateのREST APIを叩いて、Designateが持っているゾーン情報を取得する。
nameにドメインが指定されている。これは、テナントNWのdns_nameで指定した値になる。
2019-01-18 05:12:56.744 825 INFO eventlet.wsgi [req-71b7f98c-a49f-4510-933f-aeea8572fa5a noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:56] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.014472```
a389943d-e343-4736-b171-4cdb24d24860というゾーンIDを指定して、詳細情報を取得。
2019-01-18 05:12:56.759 825 INFO eventlet.wsgi [req-debbcf1b-fd4f-4aec-a240-4031030d8d22 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:56] "GET /v2/zones/a389943d-e343-4736-b171-4cdb24d24860 HTTP/1.1" 200 797 0.011927
そのゾーンに対して、レコードの作成を実行する。取得ではなく作成なのでHTTP POSTしている。
2019-01-18 05:12:56.763 825 DEBUG designate.objects.adapters.base [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] Creating RecordSet object with values {u'records': [u'172.24.20.92'], u'type': u'A', u'name': u'kyoto-pc-1.dev.hogehoge.local.'} parse /usr/lib/python2.7/site-packages/designate/objects/adapters/base.py:162
2019-01-18 05:12:56.872 825 INFO eventlet.wsgi [req-5180c105-7eab-410b-905d-e82e743e89d5 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:56] "POST /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets HTTP/1.1" 202 864 0.110299
逆にレコードの削除のパターン。細かくは書かないが、やっていることはレコード作成のときと同じ。
ゾーンの情報を取得して、削除するべきレコードが存在するなら、HTTP DELETEメソットで削除する。
2019-01-18 05:12:26.140 825 DEBUG designate.central.rpcapi [req-e161faba-5ad1-44d3-bc45-168919b9d193 noauth-user noauth-project - - -] Calling designate.central.find_zones() over RPC wra
pped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:26.152 825 INFO designate.api.v2.controllers.zones [req-e161faba-5ad1-44d3-bc45-168919b9d193 noauth-user noauth-project - - -] Retrieved <Zone count:'1' object:'ZoneList
'>
2019-01-18 05:12:26.153 825 INFO eventlet.wsgi [req-e161faba-5ad1-44d3-bc45-168919b9d193 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:26] "GET /v2/zones?name=dev.
hogehoge.local. HTTP/1.1" 200 916 0.014623
2019-01-18 05:12:26.158 825 DEBUG designate.central.rpcapi [req-2d235825-4907-4478-8c84-90f5e4f1ae82 noauth-user noauth-project - - -] Calling designate.central.get_zone() over RPC wrapp
ed /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:26.168 825 DEBUG designate.central.rpcapi [req-2d235825-4907-4478-8c84-90f5e4f1ae82 noauth-user noauth-project - - -] Calling designate.central.find_recordsets() over RP
C wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:26.181 825 INFO eventlet.wsgi [req-2d235825-4907-4478-8c84-90f5e4f1ae82 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:26] "GET /v2/zones/a389943d-
e343-4736-b171-4cdb24d24860/recordsets?name=kyoto-pc-1.dev.hogehoge.local. HTTP/1.1" 200 911 0.024573
2019-01-18 05:12:26.185 825 DEBUG designate.central.rpcapi [req-78d4b764-4709-4750-be23-3b83edfab889 noauth-user noauth-project - - -] Calling designate.central.find_zones() over RPC wra
pped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:26.197 825 INFO designate.api.v2.controllers.zones [req-78d4b764-4709-4750-be23-3b83edfab889 noauth-user noauth-project - - -] Retrieved <Zone count:'1' object:'ZoneList
'>
2019-01-18 05:12:26.198 825 INFO eventlet.wsgi [req-78d4b764-4709-4750-be23-3b83edfab889 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:26] "GET /v2/zones?name=dev.
hogehoge.local. HTTP/1.1" 200 916 0.013429
2019-01-18 05:12:26.202 825 DEBUG designate.central.rpcapi [req-3e67b583-bbee-44ff-a3b8-a0185a3ceadc noauth-user noauth-project - - -] Calling designate.central.get_recordset() over RPC
wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:26.216 825 DEBUG designate.central.rpcapi [req-3e67b583-bbee-44ff-a3b8-a0185a3ceadc noauth-user noauth-project - - -] Calling designate.central.delete_recordset() over R
PC wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 05:12:26.367 825 INFO eventlet.wsgi [req-3e67b583-bbee-44ff-a3b8-a0185a3ceadc noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 05:12:26] "DELETE /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/750bf4be-982d-4f59-ae6d-81b4b2a8b270 HTTP/1.1" 202 761 0.166133
ここで、Neutronが連携してくるときの流れを実際に追うべく、curlでAPIを叩いて、各種情報を取得してみる。
まずはゾーンの情報。今回は1つのゾーンしか用意していないが、複数作っていれば、当然その数だけここに表示される。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 696 100 696 0 0 43213 0 --:--:-- --:--:-- --:--:-- 43500
{
"zones": [
{
"status": "ACTIVE",
"masters": [],
"name": "dev.hogehoge.local.",
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860"
},
"transferred_at": null,
"created_at": "2018-11-14T01:19:53.000000",
"pool_id": "794ccc2c-d751-44fe-b57f-8894c9f5c842",
"updated_at": "2019-01-18T05:13:01.000000",
"version": 167,
"id": "a389943d-e343-4736-b171-4cdb24d24860",
"ttl": 7200,
"action": "NONE",
"attributes": {
"tier": "gold",
"ha": "true"
},
"serial": 1547788376,
"project_id": "noauth-project",
"type": "PRIMARY",
"email": "joe@example.org",
"description": "This is an example zone."
}
],
"links": {
"self": "http://127.0.0.1:9001/v2/zones"
},
"metadata": {
"total_count": 1
}
}
↑で得られたidを使って、ゾーンの詳細情報を取得してみる。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860 | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 598 100 598 0 0 38783 0 --:--:-- --:--:-- --:--:-- 39866
{
"status": "ACTIVE",
"masters": [],
"name": "dev.hogehoge.local.",
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860"
},
"transferred_at": null,
"created_at": "2018-11-14T01:19:53.000000",
"pool_id": "794ccc2c-d751-44fe-b57f-8894c9f5c842",
"updated_at": "2019-01-18T05:13:01.000000",
"version": 167,
"id": "a389943d-e343-4736-b171-4cdb24d24860",
"ttl": 7200,
"action": "NONE",
"attributes": {
"tier": "gold",
"ha": "true"
},
"serial": 1547788376,
"project_id": "noauth-project",
"type": "PRIMARY",
"email": "joe@example.org",
"description": "This is an example zone."
}
次にゾーンに紐づくレコードの一覧を取得する。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11065 100 11065 0 0 221k 0 --:--:-- --:--:-- --:--:-- 225k
{
"recordsets": [
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/46e2937c-14b5-47e0-8b3c-fa61067735b2"
},
"created_at": "2018-11-14T01:19:53.000000",
"updated_at": "2019-01-18T05:12:56.000000",
"records": [
"ns.dev.hogehoge.local. joe.example.org. 1547788376 3551 600 86400 3600"
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 75,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "SOA",
"id": "46e2937c-14b5-47e0-8b3c-fa61067735b2",
"name": "dev.hogehoge.local."
},
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/6aa2ff88-8bd3-49c0-9c85-ae8bf5e554cf"
},
"created_at": "2018-11-14T01:19:53.000000",
"updated_at": null,
"records": [
"ns.dev.hogehoge.local."
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 1,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "NS",
"id": "6aa2ff88-8bd3-49c0-9c85-ae8bf5e554cf",
"name": "dev.hogehoge.local."
},
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/21462d56-1012-4d6d-891d-97c9ad21de43"
},
"created_at": "2019-01-18T04:37:29.000000",
"updated_at": null,
"records": [
"172.24.20.56"
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 1,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "A",
"id": "21462d56-1012-4d6d-891d-97c9ad21de43",
"name": "tokyo-pc-1.dev.hogehoge.local."
},
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/0e94b8c8-05bb-4cc9-bbf1-0a2ffe652bfd"
},
"created_at": "2019-01-18T04:37:50.000000",
"updated_at": null,
"records": [
"172.24.20.58"
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 1,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "A",
"id": "0e94b8c8-05bb-4cc9-bbf1-0a2ffe652bfd",
"name": "tokyo-pc-2.dev.hogehoge.local."
},
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/d55e20c0-d8a1-4314-b1f0-1fc15418026b"
},
"created_at": "2019-01-18T05:12:42.000000",
"updated_at": null,
"records": [
"172.24.20.87"
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 1,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "A",
"id": "d55e20c0-d8a1-4314-b1f0-1fc15418026b",
"name": "osaka-pc-1.dev.hogehoge.local."
},
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/79794c3a-d466-410b-871b-11a773c6f60f"
},
"created_at": "2019-01-18T05:12:56.000000",
"updated_at": null,
"records": [
"172.24.20.92"
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 1,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "A",
"id": "79794c3a-d466-410b-871b-11a773c6f60f",
"name": "kyoto-pc-1.dev.hogehoge.local."
}
],
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets",
"next": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets?marker=79794c3a-d466-410b-871b-11a773c6f60f"
},
"metadata": {
"total_count": 20
}
}
レコード単体を取得したいときは、↑で得られたidを使ってGETする。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/79794c3a-d466-410b-871b-11a773c6f60f | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 529 100 529 0 0 28568 0 --:--:-- --:--:-- --:--:-- 29388
{
"status": "ACTIVE",
"description": null,
"links": {
"self": "http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/79794c3a-d466-410b-871b-11a773c6f60f"
},
"created_at": "2019-01-18T05:12:56.000000",
"updated_at": null,
"records": [
"172.24.20.92"
],
"zone_id": "a389943d-e343-4736-b171-4cdb24d24860",
"version": 1,
"ttl": null,
"action": "NONE",
"zone_name": "dev.hogehoge.local.",
"project_id": "noauth-project",
"type": "A",
"id": "79794c3a-d466-410b-871b-11a773c6f60f",
"name": "kyoto-pc-1.dev.hogehoge.local."
}
次にインスタンス名を変更したときの挙動。
例として、tokyo-pc-2を変更してみる。
まずはtokyo-pc-2にアタッチされているインターフェース(ポート)の確認。
ポートを作成した際、インスタンス名が自動的にdns_nameに付与される。
先述した通り、Internal DNS Resolutionにせよ、External DNS Intergrationにせよ、ポートのdns_nameがレコード作成に使われる。
(overcloud) [stack@director01 ~]$ openstack port list | grep 192.168.0.4
| f672d217-c779-49a0-a9de-cb7f39aaa929 | | fa:16:3e:28:51:36 | ip_address='192.168.0.4', subnet_id='f6dfe617-81a0-4e17-af79-d93c9ff5fbf8' | ACTIVE |
(overcloud) [stack@director01 ~]$ openstack port show f672d217-c779-49a0-a9de-cb7f39aaa929
+-----------------------+------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+------------------------------------------------------------------------------------+
| admin_state_up | UP |
| allowed_address_pairs | |
| binding_host_id | kvm002.example.com |
| binding_profile | |
| binding_vif_details | datapath_type='system', ovs_hybrid_plug='True', port_filter='True' |
| binding_vif_type | ovs |
| binding_vnic_type | normal |
| created_at | 2019-01-18T02:20:51Z |
| data_plane_status | None |
| description | |
| device_id | ac22f9df-c0c7-455d-99e3-35f19956ac14 |
| device_owner | compute:nova |
| dns_assignment | fqdn='tokyo-pc-2.dev.hogehoge.local.', hostname='tokyo-pc-2', ip_address='192.168.0.4' |
| dns_name | tokyo-pc-2 |
| extra_dhcp_opts | |
| fixed_ips | ip_address='192.168.0.4', subnet_id='f6dfe617-81a0-4e17-af79-d93c9ff5fbf8' |
| id | f672d217-c779-49a0-a9de-cb7f39aaa929 |
| ip_address | None |
| mac_address | fa:16:3e:28:51:36 |
| name | |
| network_id | 2825f51a-ef89-4f0d-a7e3-540e997244ad |
| option_name | None |
| option_value | None |
| port_security_enabled | True |
| project_id | 1d20ed74c81e42f49e01b394492391d7 |
| qos_policy_id | None |
| revision_number | 14 |
| security_group_ids | 14394db0-f89a-454b-9189-20bf2975d883 |
| status | ACTIVE |
| subnet_id | None |
| tags | |
| trunk_details | None |
| updated_at | 2019-01-18T02:23:52Z |
+-----------------------+------------------------------------------------------------------------------------+
というわけで、レコードの中身を変えたいなら、ポートのdns_nameを変更する必要がある。
下記のようにopenstack port set --dns-name [dns_name] [port_id]コマンドを使って、dns_nameを明示的に変更する。
(overcloud) [stack@director01 ~]$ openstack port set --dns-name tokyo-banana f672d217-c779-49a0-a9de-cb7f39aaa929
(overcloud) [stack@director01 ~]$ openstack port show f672d217-c779-49a0-a9de-cb7f39aaa929 -c dns_name
+----------+--------------+
| Field | Value |
+----------+--------------+
| dns_name | tokyo-banana |
+----------+--------------+
Internal DNS Resolutionの場合、上記コマンドでdns_nameを変更すると、dnsmasq側でも即座に反映される。すばらしい。
[centos@tokyo-pc-1 ~]$ dig tokyo-banana
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> tokyo-banana
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51950
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tokyo-banana. IN A
;; ANSWER SECTION:
tokyo-banana. 0 IN A 192.168.0.4
;; Query time: 2 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 08:52:02 UTC 2019
;; MSG SIZE rcvd: 57
当然、以前の名前では名前解決が出来なくなっている。
[centos@tokyo-pc-1 ~]$ dig tokyo-pc-2
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> tokyo-pc-2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33117
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tokyo-pc-2. IN A
;; AUTHORITY SECTION:
. 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019011800 1800 900 604800 86400
;; Query time: 46 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 08:52:10 UTC 2019
;; MSG SIZE rcvd: 114
一応、インスタンス名を変えるだけでは、レコードは何も変わらないことをログも沿えて示す。
インスタンス名を変更する。その後、アタッチされているポートのdns_nameを確認してみても、古いインスタンス名のまま。
[stack@director01 ~]$ openstack server set --name osaka-banana osaka-pc-2
[stack@director01 ~]$
[stack@director01 ~]$ openstack server show osaka-banana -c name
+-------+--------------+
| Field | Value |
+-------+--------------+
| name | osaka-banana |
+-------+--------------+
[stack@director01 ~]$ openstack port show b64dc631-e6b9-49ee-a558-fd3868e2c661 -c dns_name -c dns_assignment -c fixed_ips
+----------------+-----------------------------------------------------------------------------------+
| Field | Value |
+----------------+-----------------------------------------------------------------------------------+
| dns_assignment | fqdn='osaka-pc-2.dev.hogehoge.local.', hostname='osaka-pc-2', ip_address='10.10.10.4' |
| dns_name | osaka-pc-2 |
| fixed_ips | ip_address='10.10.10.4', subnet_id='64e3211f-eda4-43d0-bcb5-8bda6e819352' |
+----------------+-----------------------------------------------------------------------------------+
名前解決をしてみても、やはり想定の動作。
[centos@osaka-pc-1 ~]$ dig +noall osaka-banana +ans
[centos@osaka-pc-1 ~]$ dig +noall osaka-pc-2 +ans
osaka-pc-2. 0 IN A 10.10.10.4
問題は、External DNS Intergration側。つまりDesignateの挙動。
こちらは変わらない。Neutron - Designateの連携はフローティングIPの割当/解除のタイミングでしか行われない。
そのため、インスタンスのポートの設定が変わっても、フローティングIPの操作が行われたわけではないから、Designate側には何も連携されない。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq . | grep tokyo-pc-2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11065 100 11065 0 0 221k 0 --:--:-- --:--:-- --:--:-- 225k
"name": "tokyo-pc-2.dev.hogehoge.local."
[root@designate ~]#
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq . | grep tokyo-banana
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11065 100 11065 0 0 217k 0 --:--:-- --:--:-- --:--:-- 220k
つまり、フローティングIPの操作をすれば良い。一旦、フローティングIPを解除する。
(overcloud) [stack@director01 ~]$ openstack server remove floating ip tokyo-pc-2 172.24.20.58
ログを見ると、Designate側に連携されていることが確認できる。
ポートのdns_nameがtokyo-bananaになっているからといって、tokyo-banana - 172.24.20.58のレコードを削除しようとするわけではない。元々のtokyo-pc-2 - 172.24.20.58のレコードを削除しようとしている。
おかげで正しく削除がされていることが確認できる。
[root@designate ~]# tail /var/log/designate/api.log | grep INFO
2019-01-18 08:58:24.463 825 INFO eventlet.wsgi [req-99bfde71-1645-4902-9a95-5b683fa6b26c noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 08:58:24] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.014578
2019-01-18 08:58:24.491 825 INFO eventlet.wsgi [req-37fcac3c-6464-418b-86a0-f44e00d8c731 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 08:58:24] "GET /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets?name=tokyo-pc-2.dev.hogehoge.local. HTTP/1.1" 200 911 0.024320
2019-01-18 08:58:24.506 825 INFO designate.api.v2.controllers.zones [req-cdde13ce-733d-473d-b00e-64f807b73745 noauth-user noauth-project - - -] Retrieved <Zone count:'1' object:'ZoneList'>
2019-01-18 08:58:24.507 825 INFO eventlet.wsgi [req-cdde13ce-733d-473d-b00e-64f807b73745 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 08:58:24] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.013564
2019-01-18 08:58:24.668 825 INFO eventlet.wsgi [req-8e51aad4-530c-4f4d-a499-50aa4b84f579 noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 08:58:24] "DELETE /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/0e94b8c8-05bb-4cc9-bbf1-0a2ffe652bfd HTTP/1.1" 202 761 0.157623
curlでも確認してみる。確かに削除された。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq . | grep tokyo-pc-2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10400 100 10400 0 0 210k 0 --:--:-- --:--:-- --:--:-- 211k
次にフローティングIPを割り当てる。今回は同じフローティングIPを割り当てているが、別のフローティングIPに変えれば、そのIPアドレスでレコードが作成される。
(overcloud) [stack@director01 ~]$ openstack server add floating ip tokyo-pc-2 172.24.20.58
ログ的にも正しく作成されている。
[root@designate ~]# tail -3 /var/log/designate/api.log
2019-01-18 09:03:02.292 825 DEBUG designate.objects.base [req-82c3d8af-51b9-44e2-bce7-04e7d71d313a noauth-user noauth-project - - -] Validating 'RecordSet' object with values: {'records': [{'address': u'172.24.20.58'}], 'type': u'A', 'name': u'tokyo-banana.dev.hogehoge.local.'} validate /usr/lib/python2.7/site-packages/designate/objects/base.py:336
2019-01-18 09:03:02.292 825 DEBUG designate.central.rpcapi [req-82c3d8af-51b9-44e2-bce7-04e7d71d313a noauth-user noauth-project - - -] Calling designate.central.create_recordset() over RPC wrapped /usr/lib/python2.7/site-packages/designate/loggingutils.py:24
2019-01-18 09:03:02.438 825 INFO eventlet.wsgi [req-82c3d8af-51b9-44e2-bce7-04e7d71d313a noauth-user noauth-project - - -] 172.24.20.3 - - [18/Jan/2019 09:03:02] "POST /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets HTTP/1.1" 202 866 0.150823
curlでも確認。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq . | grep tokyo-pc-2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11067 100 11067 0 0 215k 0 --:--:-- --:--:-- --:--:-- 216k
[root@designate ~]#
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq . | grep tokyo-banana
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11067 100 11067 0 0 219k 0 --:--:-- --:--:-- --:--:-- 220k
"name": "tokyo-banana.dev.hogehoge.local."
インスタンスからも名前解決してみる。
tokyo-pc-1から名前解決すると、Internal DNS Resolutionになってしまうので、osaka-pc-1から実行する。
[centos@osaka-pc-1 ~]$ dig tokyo-banana.dev.hogehoge.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> tokyo-banana.dev.hogehoge.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27107
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tokyo-banana.dev.hogehoge.local. IN A
;; ANSWER SECTION:
tokyo-banana.dev.hogehoge.local. 7200 IN A 172.24.20.58
;; AUTHORITY SECTION:
dev.hogehoge.local. 7200 IN NS ns.dev.hogehoge.local.
;; Query time: 3 msec
;; SERVER: 10.10.10.2#53(10.10.10.2)
;; WHEN: 金 1月 18 09:06:16 UTC 2019
;; MSG SIZE rcvd: 89
[centos@osaka-pc-1 ~]$
[centos@osaka-pc-1 ~]$ ssh tokyo-banana
The authenticity of host 'tokyo-banana (172.24.20.58)' can't be established.
ECDSA key fingerprint is SHA256:Z0SM1udlHErrBFdJgaYRKk8zlN4Ru1+GeSCy96bZ0OE.
ECDSA key fingerprint is MD5:82:fb:e4:37:22:ce:8e:80:61:3d:41:4f:08:b7:4c:c9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tokyo-banana,172.24.20.58' (ECDSA) to the list of known hosts.
centos@tokyo-banana's password:
Last login: Fri Jan 18 04:38:41 2019 from 10.50.6.251
[centos@tokyo-pc-2 ~]$
ちなみに、ポートのdns_nameを変更してからフローティングIPを解除しても、元のdns_nameでDELETE連携されることは示したが、インスタンス名においても同様。やはりインスタンス名は何も関係ない。
(overcloud) [stack@director01 ~]$ openstack server set --name osaka-pc-3 osaka-pc-1
(overcloud) [stack@director01 ~]$ openstack server remove floating ip osaka-pc-3 172.24.20.87
(overcloud) [stack@director01 ~]$ openstack server show osaka-pc-3 -c name
+-------+------------+
| Field | Value |
+-------+------------+
| name | osaka-pc-3 |
+-------+------------+
[root@designate ~]# tail /var/log/designate/api.log | grep INFO
2019-01-19 13:20:05.479 825 INFO eventlet.wsgi [req-0fb4c1f7-8f24-4d4b-abcf-2837eacae3c2 noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 13:20:05] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.014478
2019-01-19 13:20:05.506 825 INFO eventlet.wsgi [req-17eec34b-428f-4b96-8cfa-a95b57947f44 noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 13:20:05] "GET /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets?name=osaka-pc-1.dev.hogehoge.local. HTTP/1.1" 200 911 0.023897
2019-01-19 13:20:05.522 825 INFO designate.api.v2.controllers.zones [req-92c54cb3-7109-4cca-aadc-8d1675c6a7e0 noauth-user noauth-project - - -] Retrieved <Zone count:'1' object:'ZoneList'>
2019-01-19 13:20:05.523 825 INFO eventlet.wsgi [req-92c54cb3-7109-4cca-aadc-8d1675c6a7e0 noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 13:20:05] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.014198
2019-01-19 13:20:05.635 825 INFO eventlet.wsgi [req-9b2ccf1c-a197-45ce-aff5-95dfa109030a noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 13:20:05] "DELETE /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/d55e20c0-d8a1-4314-b1f0-1fc15418026b HTTP/1.1" 202 761 0.109459
また、あくまでフローティングIPの割当と解除に対してだけ反応するため、インスタンスの削除では連携されない。
再度、フローティングIPを割り当てる。ログは示さないが、おわかりの通りインスタンス名はosaka-pc-3でも紐づくポートのdns_nameがosaka-pc-1のままなので、Designate側にはosaka-pc-1 - 172.24.20.87のAレコードが作成される。
(overcloud) [stack@director01 ~]$ openstack server add floating ip osaka-pc-3 172.24.20.87
さて、このレコードが削除されるかどうか。
インスタンスを削除する。
(overcloud) [stack@director01 ~]$ openstack server delete osaka-pc-3
/var/log/designate/api.logを見ても、何も届いていない。何も連携されず、何も届いていない以上、ログがないので、ここには載せない。
実レコードとしてどうなのかも一応見ておく。
すると、osaka-pc-1が見つかった。やはり、削除されていない。
[root@designate ~]# curl http://127.0.0.1:9001/v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets | jq . | grep -e "osaka-pc-[1|3]"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10400 100 10400 0 0 214k 0 --:--:-- --:--:-- --:--:-- 211k
"name": "osaka-pc-1.dev.hogehoge.local."
当然、名前解決も可能。
[centos@tokyo-pc-1 ~]$ dig +noall osaka-pc-1.dev.hogehoge.local +ans
osaka-pc-1.dev.hogehoge.local. 7200 IN A 172.24.20.87
ただし、Internal DNS Resolution側は即座に反応して、名前解決不可能になる。
下記のようにdnsmasqを直指定で名前解決した場合、Internal DNS Resolutionとしてレコードが削除されていなければ、osaka-pc-1はFixed IPで解決されるはずだが、実際にはフローティングiPが返答されている。
つまり、dnsmasqがosaka-pc-1のことを知らず、Designateサーバーにフォワードして名前解決したと言える。
[centos@tokyo-pc-1 ~]$ dig @10.10.10.2 +noall osaka-pc-1.dev.hogehoge.local +ans
osaka-pc-1.dev.hogehoge.local. 7200 IN A 172.24.20.87
当然、インスタンスは削除して実態はいないのだから、名前解決はできても疎通はとれない。
[centos@tokyo-pc-1 ~]$ ping -c 1 osaka-pc-1
PING osaka-pc-1.dev.hogehoge.local (172.24.20.87) 56(84) bytes of data.
--- osaka-pc-1.dev.hogehoge.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Internal DNS Resolutionのdnsmasqは何も完全にテナントNW内部に閉じたものではない。
ルーター経由でリーチャビリティさえあれば、明示的な指定で別のテナントNWから参照することも可能。
テナントNW:osakaのDHCPインターフェース(dnsmasq)である10.10.10.2にはルーター経由で接続可能であるため、問題なく名前解決が可能。もちろんosakaのNWに閉じたものだけなので、tokyo-pc-1などの名前解決は出来ない。
kyotoに関しては、そもそもリーチャビリティがないので、名前解決不可能。
[centos@tokyo-pc-1 ~]$ dig +noall tokyo-pc-1 +ans +stats
tokyo-pc-1. 0 IN A 192.168.0.5
;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 09:20:15 UTC 2019
;; MSG SIZE rcvd: 55
[centos@tokyo-pc-1 ~]$ dig @10.10.10.2 +noall tokyo-pc-1 +ans +stats
;; Query time: 218 msec
;; SERVER: 10.10.10.2#53(10.10.10.2)
;; WHEN: 金 1月 18 09:20:26 UTC 2019
;; MSG SIZE rcvd: 114
[centos@tokyo-pc-1 ~]$ dig @10.10.10.2 +noall osaka-pc-1 +ans +stats
osaka-pc-1. 0 IN A 10.10.10.12
;; Query time: 1 msec
;; SERVER: 10.10.10.2#53(10.10.10.2)
;; WHEN: 金 1月 18 09:20:32 UTC 2019
;; MSG SIZE rcvd: 55
[centos@tokyo-pc-1 ~]$ dig @10.200.200.2 +noall kyoto-pc-1 +ans +stats
;; connection timed out; no servers could be reached
ならば、下記のようにresolv.confのnameserverで複数指定すれば、リーチャビリティのあるテナントNW内の名前解決は全部出来るのでは！？と思うが・・・
[centos@tokyo-pc-1 ~]$ cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search dev.hogehoge.local
nameserver 192.168.0.2
nameserver 10.10.10.2
できない。
Linuxのnameserverは、1つ目のnameserverの応答がなかったときに始めて、2つ目以降のnameserverを使用する。
今回でいえば192.168.0.2がそもそも「そんなのシラネーヨ」と返答してきてしまうと、10.10.10.2にわざわざ問い合わせに行ったりはしない。
[centos@tokyo-pc-1 ~]$ dig +noall tokyo-pc-1 +ans +stats
tokyo-pc-1. 0 IN A 192.168.0.5
;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 09:25:04 UTC 2019
;; MSG SIZE rcvd: 55
[centos@tokyo-pc-1 ~]$
[centos@tokyo-pc-1 ~]$ dig +noall osaka-pc-1 +ans +stats
;; Query time: 41 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: 金 1月 18 09:25:11 UTC 2019
;; MSG SIZE rcvd: 11
dns_domainが存在しないときの挙動
今回、テナントNWを用意した段階でdns_domainを付与していたが、敢えて存在しない状態のときの挙動。
敢えて、と言うが、つまりはデフォルトの挙動である。
例により、openstackコマンドではdns_domainは変更できないので、neutron net-updateコマンドを使用し、空文字を指定してdns_domainを未指定状態にする。
(overcloud) [stack@director01 ~]$ openstack network show tokyo -c dns_domain
+------------+-----------------+
| Field | Value |
+------------+-----------------+
| dns_domain | dev.hogehoge.local. |
+------------+-----------------+
(overcloud) [stack@director01 ~]$ neutron net-update tokyo --dns_domain ""
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated network: tokyo
(overcloud) [stack@director01 ~]$ openstack network show tokyo -c dns_domain
+------------+-------+
| Field | Value |
+------------+-------+
| dns_domain | |
+------------+-------+
tokyo-pc-2からフローティングIPを解除する。
(overcloud) [stack@director01 ~]$ openstack server remove floating ip tokyo-pc-2 172.24.20.58
実は・・・DELETEの処理は発動する。
[root@designate ~]# tail /var/log/designate/api.log | grep INFO
2019-01-19 12:54:16.662 825 INFO eventlet.wsgi [req-ebec6e6a-5e9b-4ad4-a6fe-5141331f6682 noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 12:54:16] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.015034
2019-01-19 12:54:16.690 825 INFO eventlet.wsgi [req-0639a91b-0aee-4e27-8e4e-6b87c396b8eb noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 12:54:16] "GET /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets?name=tokyo-banana.dev.hogehoge.local. HTTP/1.1" 200 915 0.024557
2019-01-19 12:54:16.706 825 INFO designate.api.v2.controllers.zones [req-c3602ecc-91ea-495b-89df-083f5b5522cd noauth-user noauth-project - - -] Retrieved <Zone count:'1' object:'ZoneList'>
2019-01-19 12:54:16.707 825 INFO eventlet.wsgi [req-c3602ecc-91ea-495b-89df-083f5b5522cd noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 12:54:16] "GET /v2/zones?name=dev.hogehoge.local. HTTP/1.1" 200 916 0.013915
2019-01-19 12:54:16.866 825 INFO eventlet.wsgi [req-42f6539b-cc7b-4e84-a434-47ef8f2eb5c8 noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 12:54:16] "DELETE /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/c3e8deef-a896-48e9-8faf-17c5075d851f HTTP/1.1" 202 763 0.155815
再度、フローティングIPを割り当てる。
(overcloud) [stack@director01 ~]$ openstack server add floating ip tokyo-pc-2 172.24.20.58
うんともすんとも言わない。
[root@designate ~]# tail -1 /var/log/designate/api.log
2019-01-19 12:54:16.866 825 INFO eventlet.wsgi [req-42f6539b-cc7b-4e84-a434-47ef8f2eb5c8 noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 12:54:16] "DELETE /v2/zones/a389943d-e343-4736-b171-4cdb24d24860/recordsets/c3e8deef-a896-48e9-8faf-17c5075d851f HTTP/1.1" 202 763 0.155815
次に、dns_domainを今まで使っていたものとは変更してみる。
このドメインのゾーンはDesignate側に作成していない。
(overcloud) [stack@director01 ~]$ neutron net-update tokyo --dns_domain example.local.
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated network: tokyo
(overcloud) [stack@director01 ~]$ openstack network show tokyo -c dns_domain
+------------+----------------+
| Field | Value |
+------------+----------------+
| dns_domain | example.local. |
+------------+----------------+
再度、フローティングIPの解除と割当を行う。
(overcloud) [stack@director01 ~]$ openstack server remove floating ip tokyo-pc-2 172.24.20.58
(overcloud) [stack@director01 ~]$ openstack server add floating ip tokyo-pc-2 172.24.20.58
すると、Designate側には以下のようなログが出力される。
tokyoに新しく指定したdns_domainであるexample.localが、存在するかどうかを確認してきている。
2019-01-19 13:05:59.785 825 INFO eventlet.wsgi [req-a3b214fc-4d9c-421e-a49e-764449dce6ca noauth-user noauth-project - - -] 172.24.20.3 - - [19/Jan/2019 13:05:59] "GET /v2/zones?name=example.local. HTTP/1.1" 200 317 0.010904
実際にAPI叩いて確認してみると以下の通り。当然ながらゾーンが存在していない。
ゾーンが存在していれば、ここで何度も書いている通りのログが流れ、レコードが作成される。
このように明示的にdns_domainを指定することで、そのテナントNWがマッピングされるドメイン(ゾーン)を変更することが出来る。
[root@designate ~]# curl -X GET http://127.0.0.1:9001/v2/zones?name=example.local. | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 118 100 118 0 0 9676 0 --:--:-- --:--:-- --:--:-- 9833
{
"zones": [],
"links": {
"self": "http://127.0.0.1:9001/v2/zones?name=example.local."
},
"metadata": {
"total_count": 0
}
}
あとがき
一年以上前に書いた下書きを投稿していなかった・・・長文記事なんだからこそ、さっさと投稿しておけばよかった。もうTrainもリリースされ、Designateもアップデートされているし、ちょっと挙動が変わっているかも？時間あるときにアップストリームのOpenStackを使って調査検証してみたい。あぁ、というかその前に構築系の記事書かないと・・・