2019-11-28 DNSOPS.JP BoF

OctoDNSとGitLab CI/CDを利⽤した
複数DNSプロバイダー構成の運⽤株式会社ハートビーツ

滝澤隆史

1

私は誰
• 滝澤 隆史（たきざわ たかし）
• Twitter: @ttkzw• DNSで遊んでいる⼈– DNS RFC系統図– https://emaillab.jp/dns/dns-rfc/• 所属: 株式会社ハートビーツ– 事業内容• MSP（監視・運⽤代⾏）、受託開発（PHP + React ( TypeScript )）– 滝澤は社内システム基盤の⾯倒を⾒ている• DNS権威サーバー– ここのお話をします2

本⽇のお話を３⾏で説明すると• DNSゾーン管理ツール OctoDNS と• SCM（ソースコード管理）ツール GitLab のCI/CD機能を使って、• 複数DNSプロバイダー構成を運⽤する事例を紹介します。

Azure DNS

Amazon Route 53

Docker Container

CI/CDgit commit / git push
Zone
file

git clone / pull

Zone
file3

背景（きっかけ）4課題認識• 2016年10⽉のDynのDNS権威サーバーへの⼤規模DDoS• ⾃前運⽤の弊社のDNS権威サーバー– DDoSが発⽣したらこの1000分の1程度でも回線飽和で使い物にならなくなるという課題認識– 弊社はお客様へ監視サービスを提供しており、アラートメールの送信ができなくなったり、監視システムへアクセスできなくなったりするのは事業上の⼤問題– この時点ではこの課題を社内のGitLabのIssueに起票しただけ5

オープンソースのツールの認識• 2017年春に複数DNSプロバイダー対応したOSSの管理ツールがあることを認識し、調査を実施– Stack Exchange社開発のDNSControl (2017-03-14 First public release)– GitHub社開発のOctoDNS (2017-03-14 First public release)• この時点では、利⽤したいDNSプロバイダーやリソースレコードの要件には合わなかったため、検討を中断した。
– 利⽤を検討していたDNSプロバイダーがNSレコードの追加に対応していなかったということもあった。これは後ほど解消した。
• この後、「課題は認識しているが、緊急性が⾼いわけではないため、優先度が⾼くならない」という典型的な状況になり、2年ほど放置されてしまった。
6

データセンター閉鎖• ラックを借りているデータセンターが閉鎖することになった。
• DNS権威サーバーをどこかに移転しなければならない• 「課題は認識しているが、緊急性が⾼いわけではないため、優先度が⾼くならない」– 別な意味で緊急性が⾼くなってしまった。

7

プロジェクト開始• ということで調査を再開• 以前の調査では要件が合わなかったDNSプロバイダーとリソースレコードの件が解消されていた。
• 結果として、OctoDNSを使うことにした。
– OctoDNSの⽅が設定ファイルがシンプルという理由

8OctoDNS

9

OctoDNSとは• GitHub社が開発・保守しているオープンソースソフトウェア• DNS as code - Tools for managing DNS across multiple providers• https://github.com/github/octodns

10OctoDNSとは• CLIツール– octodns-sync• ソースプロバイダーのゾーン情報をターゲットプロバイダーにAPIで同期する$ octodns-sync --config-file=./config/production.yaml --doit...

SourceProviderTargetProviderTargetProvider11OctoDNSの設定ファイル（公式サイトのREADME.mdより）config/production.yaml

プロバイダー定義（認証情報含む）--providers:config:class: octodns.provider.yaml.YamlProvider
directory: ./config
default_ttl: 3600
enforce_order: Truedyn:class: octodns.provider.dyn.DynProvider
customer: 1234
username: 'username'password: env/DYN_PASSWORD
route53:
class: octodns.provider.route53.Route53Provider
access_key_id: env/AWS_ACCESS_KEY_ID
secret_access_key: env/AWS_SECRET_ACCESS_KEY

ゾーン毎のプロバイダーの指定

zones:
example.com.:sources:- config
targets:- dyn- route53

config/example.com.yaml--'':
ttl: 60
type: Avalues:- 1.2.3.4- 1.2.3.5

ソース
プロバイダーのゾーンファイル（YAML形式）

12

OctoDNSの実⾏例（公式サイト README.md より）• デフォルトはDRY RUNとして動作する。

$ octodns-sync --config-file=./config/production.yaml...
********************************************************************************* example.com.
********************************************************************************* route53 (Route53Provider)*
Create <ARecord A 60, example.com., [u'1.2.3.4', '1.2.3.5']>*
Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0* dyn (DynProvider)*
Create <ARecord A 60, example.com., [u'1.2.3.4', '1.2.3.5']>*Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0*******************************************************************************...

•

実際に反映するためには --doit オプションを付ける。
$ octodns-sync --config-file=./config/production.yaml --doit...
13

OctoDNSが対応しているプロバイダー
••
••
•
•
•
•
•
•
••

AzureProvider
AkamaiCloudflareProvider
ConstellixProvider
DigitalOceanProvider
DnsMadeEasyProvider
DnsimpleProvider
DynProvider
EtcHostsProviderGoogleCloudProvider
MythicBeastsProvider
Ns1Provider

••
•
••••

•

OVH
PowerDNSProvider
RackspaceProvider
Route53
SelectelTransip
ソースプロバイダー– AxfrSource– ZoneFileSource– TinyDnsFileSource
コンフィグ– YamlProvider

14採⽤した構成• ソースプロバイダー– ZoneFileSource（ゾーンファイル）– 既存のゾーンファイルをそのまま利⽤でき、CLIベースの作業⼿順のまま利⽤できるため。
• ターゲットプロバイダー– Route53Provider（Amazon Route53）– AzureProvider（Azure DNS）
ZoneFile
SourceRoute53
ProviderAzureProvider
15

GitLab CI/CD

16

octodns-syncをどこで実⾏するか• 既存のシステム– DNS権威サーバーのホストにSSHログインして、Subversion管理下のゾーンファイルを直接編集していた。
• BIND 9が動いている• NSDに移⾏する計画はあったんですけどね17

octodns-syncをどこで実⾏するか• 新しいシステム– DNS権威サーバーのホストがない︕– ソースコード管理にGitLabを利⽤しているので、GitLab CI/CDを利⽤して、Dockerコンテナ内でoctodns-syncを実⾏するようにした。

18

GitLabとは• GitLab社が開発しているSCM（ソースコード管理）ツール– CI/CD (Continuous Integration/Continuous Delivery)機能もある• https://about.gitlab.com/

19

基本構成
• GitLab CI/CDにより、• OctoDNSをインストールしたDockerコンテナを起動して、• octodns-syncを実⾏するようにする。

Azure DNS

Amazon Route 53

Docker Container

CI/CD

git commit / git pushZone
file

git clone / pullZone
file20

テスト• 何も確認せずにDNSプロバイダーのゾーンに反映するのは危険• stagingブランチを⽤意して、テストを⾏う– ゾーンファイルの構⽂チェック（named-checkzone）– octodns-syncのDRY RUNでの実施
Azure DNS

Amazon Route 53

Zone
file

git commit / git push
git clone / pull

認CI/CD(staging)

確

Docker Containerの結

知果

果の通結差分の確認のみで同期しない(staging)Zone
file21

Merge Requestの作成とマージ• 作業者はstagingブランチからmasterブランチへのMerge Requestを作成する。
• 確認者はMerge Requestの内容を確認してマージする。
• GitLab CI/CDによりoctodns-syncを--doitオプションを付けて実⾏し、DNSプロバイダーのゾーンに反映する。
Azure DNS

Amazon Route 53反映

実運⽤上ではセルフマージにしている
Docker Container
Merge Requestのマージ
確認者

CI/CD(staging) (master)

Zone
fileZone
file

Merge Requestの作成
作業者
22

実⾏例の紹介23

実⾏例の紹介• 失敗する実⾏例– 構⽂ミス• 成功する実⾏例24

失敗する実⾏例• stagingブランチからgit pullして、ゾーンファイルを編集し、差分を確認し、gitcommit & git pushする。

差分の確認（構⽂ミス）

実際の⼿順はvimで⾏うけど、VSCodeでgit pushまでやってみた例

25

GitLab CI/CDのジョブの確認画⾯（失敗する実⾏例）
ステータス

ジョブの出⼒26

Slackへのジョブ失敗の通知
Slackへの通知
GitLabの画⾯を開かなくてもすむようにジョブの出⼒内容を通知

GitLabのSlack Integrationによる通知

27

成功する実⾏例• stagingブランチからgit pullして、ゾーンファイルを編集し、差分を確認し、gitcommit & git pushする。

差分の確認
（正しい）

28

GitLab CI/CDのジョブの確認画⾯（成功する実⾏例）

ジョブの成功29

Slackへのジョブ成功の通知
Slackへの通知
GitLabの画⾯を開かなくてもすむようにジョブの出⼒内容を通知

GitLabのSlack Integration
による通知

30

GitLab CI/CD: Merge Requestの作成

31

GitLab CI/CD: Merge Requestの確認とマージ

32

GitLab CI/CD: Merge Requestの確認とマージ

変更内容を最終確認し、問題なければMergeボタンをクリックする。

33

GitLab CI/CDのジョブの確認画⾯（同期の実施）

ジョブの成功34

Slackへのmasterブランチのジョブの実⾏結果の通知
GitLabのSlack Integration
による通知

35

実⾏例は以上︕• 実際はdigで確認もするけど、例としては省略。

36

振り返り: stagingブランチ
Azure DNS

Amazon Route 53

CI/CD(staging)

Zone
file

git commit / git push
git clone / pull認

Docker Container

確結知の果の通果
結差分の確認のみで同期しない(staging)

Zone
file

37

振り返り: masterブランチ
Azure DNS

Amazon Route 53
反映

実運⽤上ではセルフマージにしている
Docker Container
Merge Requestのマージ
確認者

CI/CD(staging) (master)

Zone
fileZone
file

Merge Requestの作成
作業者

38

まとめ• DNSゾーン管理ツール OctoDNS と• SCM（ソースコード管理）ツール GitLab のCI/CD機能を使って、• 複数DNSプロバイダー構成を運⽤する事例を紹介しました

Azure DNSAmazon Route 53

Docker Container

CI/CD

git commit / git push
Zone
file

git clone / pullZone
file39おまけ: OctoDNSの知⾒40

OctoDNSの知⾒• OctoDNS v0.9.8時点での情報• リソースレコード(RR)– SOAレコードとNSレコードは同期されない。
– プロバイダーにより対応しているRRタイプは異なる。
• 安全機能 (octodns.provider.plan.Planクラスのraise_if_unsafe()で定義)– 10個以上のRRが存在するときに• 全体の30%以上のRRが更新される場合は中断する• 全体の30%以上のRRが削除される場合は中断する– --force オプションを付けるとこの安全機能を無視する

41

OctoDNSの知⾒• プロバイダー毎の設定⽅法– 各プロバイダーのPythonモジュールのDocstringとして記述されている。
>>> import octodns.provider.route53>>> help(octodns.provider.route53.Route53Provider)
Help on class Route53Provider in module octodns.provider.route53:
class Route53Provider(octodns.provider.base.BaseProvider)| Route53Provider(id, access_key_id=None, secret_access_key=None, max_changes=1000,client_max_attempts=None, session_token=None, *args, **kwargs)|| AWS Route53 Provider|| route53:|
class: octodns.provider.route53.Route53Provider|# The AWS access key id|
access_key_id:|# The AWS secret access key|
secret_access_key:|# The AWS session token (optional)|# Only needed if using temporary security credentials|
session_token:
42OctoDNSの知⾒• ZoneFileSource– SOAレコードは必須（同期されないけど）– ファイル名は絶対ドメイン名にする。
• ./zonefiles/example.test.
class ZoneFileSource(AxfrBaseSource):'''
Bind compatible zone file source
zonefile:
class: octodns.source.axfr.ZoneFileSource# The directory holding the zone files# Filenames should match zone name (eg. example.com.)
directory: ./zonefiles

43