こんにちは。
VOYAGE GROUPのシステム本部でインフラエンジニアとして働いている @s_tajima です。
DNSサーバーとしてRoute53を利用しようとした場合、
登録されたゾーン(HostedZone)やレコードをどのように管理するかというのに
悩んでいる方々も多いと思います。
特にVOYAGE GROUPでは、
現在 約100ゾーン, 約2500レコード
というとても多いレコードを管理しているのでとても重要な問題です。
一般的にすぐに思いつく管理の手段としては,,
などがあると思います。
これらの手段を選択する前に、Route53を管理する上で、
どのような用件が満たされていると良さそうかを考えてみましょう。
と、このあたりでしょうか。
具体的な説明は割愛しますが、
検証の結果先に挙げた3つの手段では
これらの用件を満たすことは不可能/工夫が必要だということがわかりました。
このような背景から上記の用件を実現できるツールとして,
bind2route53(https://github.com/voyagegroup/bind2route53)を作成しました。
このツールがどのような機能をもっているかを簡単に説明すると、
・bind形式のzoneファイルをCloudFormationのTemplateに変換する。(convert_zonefile)
・Route53上に、ゾーンを作成する。(create_hostedzone)
・CloudFormationに、Route53を管理するためのStackを作成する。(create_hostedzone_stack)
・CloudFormationのStackを更新し、Route53のゾーン/レコードの編集をする。(update_hostedzone_stack)
というシンプルなツールとなっています。
このツールがどのように上記の用件を満たしているのかを説明すると、
1. ゾーンの編集(作成, 削除)/基本的なレコードの編集(作成, 削除, 変更)ができる
上記の機能を見ればこの用件を満たしていることはわかると思います。
2. 本番環境の設定変更の前に、適切な検証環境でレコードの変更をテストできる
上記の機能を実施する際, 設定ファイルにIAMの鍵を複数設定し、どの鍵を利用するかを指定します。
検証環境用の鍵と本番環境の鍵を登録することで、事前に検証環境でテストをすることができます。
※尚、検証環境と本番環境は、別のAWSのアカウントを用意することを前提としています。
3. 2で実施した変更と完全に同一な変更を本番環境に適用できる
検証環境に対して実行したコマンドを、
環境の部分だけ本番環境とすることで同じ内容が本番環境に適用されることが保証されます。
4. 適用した変更を(出来る限り短期間で)切り戻せる
bind形式のzoneファイルをバージョン管理(gitやsvn)しておき、
設定に不備があった場合にはzoneファイルを切り戻し(git checkoutやsvn revert)して
再度CloudFormationに適用することで、切り戻しが行えます。
5. 任意の時点での変更内容を後から確認できる
4に記載した通り、zoneファイルをversion管理下に置くことで変更の履歴を閲覧できます。
6. Route53から別のDNSサーバーに移設したいとなった時に、低いコストで対応できる
bind形式のzoneファイルを管理するので、一般的な別のDNS管理サービスへの移設コストは低いと言えます。
(Route53もそうだが、bind形式のzoneファイルをimportする機能を提供するサービスが多い。)
7. Route53独自の機能(ALIASレコード等)を利用できる
例外的に、zoneファイルに独自のシンタックスを記述することで
Route53独自の機能を利用できるような機能を提供しています。
使い方についての詳細は こちら に記載してあるので参考にしてぜひお使いください。
以上、bind2route53の紹介でした。
#====================================
※尚, VOYAGE GROUPでの現在の運用環境では
bind2route53をラップするスクリプト
(convert_zonefile -> update_hostedzone_stackをコマンド1つで行う等)や、
DNSの設定変更をした際に、その変更が正しくできているかを確認するツール
(内部的にはdigを実行して意図した結果が返ってくるかの確認)を
を作成して、合わせて利用しています。
VOYAGE GROUPのシステム本部でインフラエンジニアとして働いている @s_tajima です。
DNSサーバーとしてRoute53を利用しようとした場合、
登録されたゾーン(HostedZone)やレコードをどのように管理するかというのに
悩んでいる方々も多いと思います。
特にVOYAGE GROUPでは、
現在 約100ゾーン, 約2500レコード
というとても多いレコードを管理しているのでとても重要な問題です。
一般的にすぐに思いつく管理の手段としては,,
- Management Consoleを操作してゾーン/レコードを管理する。
- AWSが提供するSDK等を使い、Route53のAPI(ChangeResourceRecordSets等)を叩く。
- 既存のRoute53の管理ツール(RoadWorker等)を使う。
などがあると思います。
これらの手段を選択する前に、Route53を管理する上で、
どのような用件が満たされていると良さそうかを考えてみましょう。
- ゾーンの編集(作成, 削除)/基本的なレコードの編集(作成, 削除, 変更)ができる
- 本番環境の設定変更の前に、適切な検証環境でレコードの変更をテストできる
- 2で実施した変更と完全に同一な変更を本番環境に適用できる
- 適用した変更を(出来る限り短期間で)切り戻せる
- 任意の時点での変更内容を後から確認できる
- Route53から別のDNSサーバーに移設したいとなった時に、低いコストで対応できる
- Route53独自の機能(ALIASレコード等)を利用できる
と、このあたりでしょうか。
具体的な説明は割愛しますが、
検証の結果先に挙げた3つの手段では
これらの用件を満たすことは不可能/工夫が必要だということがわかりました。
このような背景から上記の用件を実現できるツールとして,
bind2route53(https://github.com/voyagegroup/bind2route53)を作成しました。
このツールがどのような機能をもっているかを簡単に説明すると、
・bind形式のzoneファイルをCloudFormationのTemplateに変換する。(convert_zonefile)
・Route53上に、ゾーンを作成する。(create_hostedzone)
・CloudFormationに、Route53を管理するためのStackを作成する。(create_hostedzone_stack)
・CloudFormationのStackを更新し、Route53のゾーン/レコードの編集をする。(update_hostedzone_stack)
というシンプルなツールとなっています。
このツールがどのように上記の用件を満たしているのかを説明すると、
1. ゾーンの編集(作成, 削除)/基本的なレコードの編集(作成, 削除, 変更)ができる
上記の機能を見ればこの用件を満たしていることはわかると思います。
2. 本番環境の設定変更の前に、適切な検証環境でレコードの変更をテストできる
上記の機能を実施する際, 設定ファイルにIAMの鍵を複数設定し、どの鍵を利用するかを指定します。
検証環境用の鍵と本番環境の鍵を登録することで、事前に検証環境でテストをすることができます。
※尚、検証環境と本番環境は、別のAWSのアカウントを用意することを前提としています。
3. 2で実施した変更と完全に同一な変更を本番環境に適用できる
検証環境に対して実行したコマンドを、
環境の部分だけ本番環境とすることで同じ内容が本番環境に適用されることが保証されます。
4. 適用した変更を(出来る限り短期間で)切り戻せる
bind形式のzoneファイルをバージョン管理(gitやsvn)しておき、
設定に不備があった場合にはzoneファイルを切り戻し(git checkoutやsvn revert)して
再度CloudFormationに適用することで、切り戻しが行えます。
5. 任意の時点での変更内容を後から確認できる
4に記載した通り、zoneファイルをversion管理下に置くことで変更の履歴を閲覧できます。
6. Route53から別のDNSサーバーに移設したいとなった時に、低いコストで対応できる
bind形式のzoneファイルを管理するので、一般的な別のDNS管理サービスへの移設コストは低いと言えます。
(Route53もそうだが、bind形式のzoneファイルをimportする機能を提供するサービスが多い。)
7. Route53独自の機能(ALIASレコード等)を利用できる
例外的に、zoneファイルに独自のシンタックスを記述することで
Route53独自の機能を利用できるような機能を提供しています。
使い方についての詳細は こちら に記載してあるので参考にしてぜひお使いください。
以上、bind2route53の紹介でした。
#====================================
※尚, VOYAGE GROUPでの現在の運用環境では
bind2route53をラップするスクリプト
(convert_zonefile -> update_hostedzone_stackをコマンド1つで行う等)や、
DNSの設定変更をした際に、その変更が正しくできているかを確認するツール
(内部的にはdigを実行して意図した結果が返ってくるかの確認)を
を作成して、合わせて利用しています。