ホームページ > 記事 > システムチュートリアル > OctoDNS および DNS 分割権限構成の使用方法
堅牢なシステムを構築するには、障害を想定した設計が必要です。 GitHub のサイト信頼性エンジニア (SRE) として、私たちは冗長性を通じて問題を軽減できるよう常に努めています。今日は、DNS 経由でのサーバーの検索をサポートするために行った最近の取り組みについて説明します。 |
上記のクエリは、TLD ネーム サーバーに github.com の NS レコードを要求するものです。ドメイン レジストラーで構成した値が返されます。この場合、それぞれ 4 つのレコードを持つ 2 つの DNS サービス プロバイダーがあります。プロバイダーの 1 つが停止した場合でも、他のプロバイダーが引き続きリクエストを処理できる可能性があります。どこでもレコードを同期し、古いデータや間違った状態を心配することなく、安全にレコードを変更できます。
分割権限を完全に構成する最後の部分は、両方の DNS サービス プロバイダーのすべてのネーム サーバーをトップレベルの NS レコードとしてゾーンのルートに追加することです。
リーリーGitHub には数十の領域と数千のレコードがありますが、これらの領域のほとんどは冗長性が必要になるほど重要ではないため、サブセットのみを扱う必要があります。私たちは、これらのレコードを複数の DNS サービス プロバイダー間で同期し、より一般的には内部および外部のすべての DNS レコードを管理できるソリューションを実現したいと考えています。そこで今日、OctoDNS を発表します。
###構成###OctoDNS を使用すると、DNS ワークフローを再発明できます。リージョンとレコードは、Git リポジトリの構成ファイルに保存されます。 GitHub フローを使用して変更を加え、サイトと同様にブランチを使用してデプロイします。 「空の」デプロイメントを作成して、変更によってどのレコードが変更されるかをプレビューすることもできます。構成ファイルは yaml ディクショナリであり、リージョンごとに 1 つあり、その最上位キーはレコード名で、キー値は ttl、type、およびタイプ固有のデータです。たとえば、ゾーン ファイル github.com.yaml に含まれている場合、次の設定により octodns.github.com の A レコードが作成されます。
リーリー 構成の 2 番目の部分では、レコード データのソースを DNS サービス プロバイダーにマップします。次のコード スニペットは、構成プロバイダーからゾーン github.com をロードし、その結果を dyn および Route53 に同期するように OctoDNS に指示します。 リーリー同期
構成が完了すると、OctoDNS は現在の状態を評価し、ターゲットの状態をソースに一致させるために必要な一連の変更の概要を示す計画を構築できます。以下の例では、octodns.github.com は新しいレコードであるため、必要なアクションは両方にレコードを作成することです。
リーリー デフォルトでは、octodns-sync はシミュレートされた実行モードになっているため、アクションは実行されません。変更を確認して問題がなければ、「--doit」フラグを追加してコマンドを再度実行できます。 OctoDNS は処理フローを継続し、今回は Route53 と Dynect に必要な変更を加えて新しいレコードを作成します。 リーリー現時点では、両方の DNS サービス プロバイダーに同じデータ レコードがあり、正確な結果が得られることがわかっているので、DNS リクエストをそれらの間で簡単に分割できます。上記の OctoDNS コマンドを直接実行すると、内部ワークフローは展開スクリプトと Chatops に依存します。詳細については、README のワークフロー セクションを参照してください。
要約
私たちは、ほとんどの Web サイトが権限を分割することで恩恵を受けることができると考えており、OctoDNS によって最大のハードルが取り除かれることを願っています。権限の分割に興味がない場合でも、コードとしてのインフラストラクチャの利点を DNS にもたらす OctoDNS は一見の価値があります。
GitHub SRE チームが興味深い問題を解決するのを手伝いたいですか?ぜひご参加ください。こちらからお申し込みください。以上がOctoDNS および DNS 分割権限構成の使用方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。