こんにちは、滝澤です。 昨年（2019年）11月に開催された日本DNSオペレーターズグループのDNSOPS.JP BoFで発表した話を改めて本ブログで紹介します。
3行で説明すると次のような内容になります。
- DNSゾーン管理ツール OctoDNS と
- SCM（ソースコード管理）ツール GitLab のCI/CD機能を使って、
- 複数DNSプロバイダー構成を運用する事例を紹介します。
前後編に分けて紹介します。
- 前編: OctoDNSの紹介
- 後編: GitLab CI/CDの利用
本記事は後編の「GitLab CI/CDの利用」になります。
GitLab CI/CDの利用
「前編: OctoDNSの紹介」において、OctoDNSの紹介を行いました。 弊社ハートビーツが実際に採用した構成は次の通りです。
- ソースプロバイダー
- ZoneFileSource（ゾーンファイル）
- ターゲットプロバイダー
- Route53Provider（Amazon Route53）
- AzureProvider（Azure DNS）
さらに、GitLab CI/CDを利用した事例を紹介していきます。
経緯
OctoDNSとGitLab CI/CDを利用した複数DNSプロバイダー構成を運用するに至った経緯を簡単に紹介します。
既存のシステムは自社運用のBIND 9のDNS権威サーバーでした。弊社のエンジニアがこのサーバーにsshでログインし、ゾーンファイルを更新するといった運用を行っていました。
主に次の2つの要因により、複数のDNSプロバイダー構成での運用に切り替えることを検討しました。
- DDoS攻撃（分散型サービス妨害攻撃）のリスクを低減したい。これは、2016年10月のDNSプロバイダーのDynのDNS権威サーバーへの大規模DDoSをきっかけにリスクを認識。
- ラックを借りているデータセンターが閉鎖することになった。
前者の対応として、2017年春に複数DNSプロバイダー対応したオープンソースソフトウェアの管理ツール（OctoDNSも含む）があることを認識し、調査を実施しました。しかし、このときには利用したいDNSプロバイダーやリソースレコードの要件には合わなかったため、検討を中断しました。
この2年後（2019年）、後者の状況が発生し、調査・検討を再開し、要件が合わなかった課題が解消されていたため、OctoDNSを利用した構成にすることになりました。
GitLabとは
GitLabとは、GitLab社が開発しているSCM（ソースコード管理）ツールです。 CI/CD (Continuous Integration/Continuous Delivery)機能もあります。
GitLab CI/CDの採用
自社運用のDNS権威サーバーからOctoDNSを利用した複数DNSプロバイダー構成に移行するにあたって、ゾーン同期コマンドのoctodns-syncをどこで実行するかということが課題になりました。
弊社ではソースコード管理にGitLabを利用しているので、ゾーンファイルのバージョン管理も含めて、次のような構成にしました。
- GitLab CI/CDにより、
- OctoDNSをインストールしたDockerコンテナを起動して、
- octodns-syncを実行する。
テスト
何も確認せずにDNSプロバイダーのゾーンに反映するのは安全ではありません。 そのため、stagingブランチを用意しました。
次のような流れになります。
- 【作業者】GitLabのリポジトリからgit clone/git pullを行う。
- 【作業者】stagingブランチに切り替え、ゾーンファイルを編集する。
- 【作業者】stagingブランチにgit commit/git pushする。
- 【GitLab CI/CD】次の内容のテストを行う。
- ゾーンファイルの構文チェック（named-checkzone）
- octodns-syncのDRY RUNでの実施
- 【GitLab CI/CD】テストの出力とパイプラインの結果をSlackに通知する。
- 【作業者】テストの出力とパイプラインの結果をSlack上で確認する。
Slackの通知の例は次のようになります。2つの通知があります。
- 1つ目の通知: octodns-syncの実行結果を整形したもの。これは、作成したスクリプトによる通知。
- 2つ目の通知: CI/CDのPiplelineの結果。GitLabのSlack連携によるもの。
テストで失敗した場合には次のような内容がSlackに通知されます。 この場合は、作業者はゾーンファイルを修正して、再びgit commit/git pushすることになります。
マージリクエストの作成とマージ
先のテストで問題が無ければ、次のような流れになります。
- 【作業者】stagingブランチからmasterブランチへのマージリクエストを作成する。
- 【確認者】マージリクエストの内容を確認してマージする。
- 【GitLab CI/CD】octodns-syncを
--doitオプションを付けて実行し、DNSプロバイダーのゾーンに反映する。 - 【GitLab CI/CD】パイプラインの結果をSlackに通知する。
- 【作業者】パイプラインの結果をSlack上で確認する。
Slackの通知の例は次のようになります。3つの通知があり、すべてGitLabのSlack連携によるものです。
- 1つ目の通知: マージリクエストの作成実施
- 2つ目の通知: マージリクエストのマージ実施
- 3つ目の通知: CI/CDのパイプラインの結果
以上で更新作業が完了になります。
反映の確認
当初の検討案の一つとして、Infratesterのようなテスト自動化ツールを使って、masterブランチへのマージの際のCI/CDにおいて反映内容を確認するという案も出ましたが、採用するには至りませんでした。 ゾーンファイルに数百個のリソースレコードの記述があるため、テストケースの記述がかなり煩雑になる懸念があったのも理由の一つです。
前編で紹介した octodns-compare や octodns-report を使って、検証するというアイデアもあるのですが、現状では見送っています。 octodns-syncで登録しているため、これらのコマンドはゾーンファイルの解析処理が同一であるので、そのロジックに不具合があった場合は確かさが保証できず、その結果をそのまま信用するのはリスクがあると考えています。参考情報として実施するのはありだとは思いますが、テストの実施時間が長くなるのが気になって、先に述べたように採用を見送っています。
結局、digコマンドで変更内容が反映しているかを確認する手順となっています。
GitLab CI/CDを利用することの所感
SCM（ソースコード管理）ツールとCI/CDを介在させることにより、必然と更新作業のワークフローが整備されるという利点もあります。 SCMツールのプロジェクトと権限機能を活用すれば、ゾーン毎に更新権限を分けることもできますし、作業者と確認者を分離することもできます。 ここら辺は組織に合うようにうまくカスタマイズしていけばよいと思います。
まとめ
以上のお話をまとめると次のようになります。
- DNSゾーン管理ツール OctoDNS と
- SCM（ソースコード管理）ツール GitLab のCI/CD機能を使って、
- 複数DNSプロバイダー構成を運用する事例を紹介しました
