Git

おうち Lab と GitDNSOps

本記事は、VMware DevOps Meetup #10 でお話した内容に修正加筆をしたものです。

我が家の「おうち Lab」は、他の方の「逸般の誤家庭」に比べるとかなりおとなしめです。

ちょっと変わったところというと、インターネット回線が2本引いてあることくらいでしょうか。なぜ2本引いているのかは、我が家のネットワークの歴史的背景によるものなので、まずちょっとだけその話を。

私が住んでいるのは築20年ほど経ったマンションです。マンション購入時に光回線を引くことを条件にしたのですが、当時はまだ光によるインターネットサービスは一般的ではなかったので、PRI 回線を引き込んでほぼ休止扱いにしてありました。その後、マンションにインターネットサービスが2つ提供されることになり、一つはケーブル TV 系の VDSL サービスで、もう一つは UCOM(現アルテリア・ネットワークス)によるもので、宅内までイーサを引き込むものでした。当然、私は後者を選択。帯域的なメリットもありましたが、それよりも当時 UCOM のインターネットサービスは /29 のグローバルアドレスをくれるという太っ腹ネットワークだった、いうのが UCOM を選択した大きな理由でした。この UCOM のネットワークは非常に品質の高いネットワークサービスを提供してくれていてとても満足しています(詳しくは「自宅のインターネット回線品質をVeloCloudで測ってみた」を参照)

ただ、UCOM のネットワーク帯域は 100Mbps で今となっては少々寂しいですし、IPv6 のサービスも提供されていません。また、いっとき私は SD-WAN のスタートアップ (Viptela) に勤めていたので、SD-WAN のテストをするために複数回線が欲しかった、ということもあり、複数ネットワークを引き込むことにしました。前に引いてあった光回線を活用して FLETS 光を利用し、更に NURO を加え3回線にした後、現在は FLETS を解約し、UCOM と NURO の2本構成に縮退しています。

その他は至って普通の Lab 環境です。Intel NUC や自作サーバで vSphere を利用して仮想環境を用意していろいろなものを検証しています。外向きに出しているサービスは個人用 blog サーバと、DNS くらいです。自分が保有しているいくつかのドメイン用の権威 primary サーバとして coreDNS、secondary サーバとして NSD を GCP 上で動かしています。以前 secondary DNS は実家の Raspberry Pi 上で動かしていたのですが、今年実家に誰もいなくなりネットワークも廃止したため、引っ越しを迫られ、引越し先をいろいろと検討しました。もちろん自宅環境に移すこともできたのですが(幸いグローバルアドレスもありますし)、同じ failure domain に primary と secondary を置くのは避けたかったので、別の方法を模索しました。いくつかのドメインは「お名前.com」で取得したもので、お名前.com はそこで取ったドメインに関しては無料で secondary DNS のサービスをしているので、これが使えたらベストだったのですが、あいにく私がメインで使っているドメイン “shin.do” はお名前.comで取ったものではなかったので、この方法は見送りとなりました。色々検討した結果、最終的には GCP 上のフリーインスタンス (e2-micoro) を使って secondary DNS (NSD) を動かすことにしました。無料のはずなのですが、毎月110円ほど費用が発生しているのが謎ですが、今のところ深く気にしないことにしています(笑)また、Lab ネットワークのための DNS cache サーバ兼簡易権威 DNS サーバとして unbound を使っています。

前置きが長くなりましたが、今回はこの外向きの coreDNS で GitOps をしてみる、というのをやってみました。GitOps とはなんぞや、という話は ここここ などを参照ください。要は Git リポジトリ内容を唯一の真 (Single Source of Truth) として扱って宣言的にオペレーションを廻してやろう、という考え方/方法、です。Git を使うので、バージョン・コントロールしやすく、アクセス・コントロールや監査が容易、というメリットなどを享受することができます。

ただ、私の管理している DNS サーバは基本「ワンオペ」なので、アクセス・コントールや監査のしやすさはあまり関係ありません。気軽にロールバックできたりするのは少しだけありがたいですが、そこまで大きな魅力でもありません。それでも DNS に GitOps を適用しようと思うのは、半分ノリと、DNS の変更を git push だけ済ませられるというちょっとした心地よさからでしょうか。。GitOps を DNS に適用するので、これを私は “GitDNSOps” と呼んでいます。はい、勝手に私がそう呼んでいるだけで、一般的に受け入れられている言葉ではないです。でも、流行ったら少し嬉しいので、GitDNSOps、GitDNSOps、GitDNSOps、と3回叫んでおくことにします。今回、Kubernetes 環境は microk8s を使って構築し、LoadBalancer には MetalLB を使いました。この選択に特段深い意味はないので、どっかのタイミングで Tanzu Community Edition に置き換えてもいいかな、と思っています。また、GitOps には ArgoCD を使いましたが、flux などを使っても全然構いません。

coreDNS の設定は Kubernetes の ConfigMap で食わせています。特に変わった設定はありませんが、Corefile で ”reload 10s” と指定している部分だけ説明だけ説明をしておこうと思います。この設定をすると coreDNS は指定された時間(この例だと10秒)で再度設定を読み直してくれます。この設定をしないと、git push して ConfigMap が書き換わっても、coreDNS はそれに気づいてくれないので、DNSのリソースレコードが更新されません。というわけで、若干エレガントさに欠けますが、reload 設定をして設定を読み直すようにしています。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
data:
  Corefile: |
    shin.do:5353 {
        file /etc/coredns/shin.do.zone
        reload 10s
    }
  shin.do.zone: |
    $TTL  3600
    @ IN  SOA ns1.shin.do.  root.shin.do. (
            2021081404 3600 900 3600000 3600 )  
         IN  NS  ns1.shin.do.
         IN  NS  ns2.shin.do.
         IN  MX  10 ASPMX.L.GOOGLE.COM.
    ns1  IN  A 221.245.168.210
    ns2  IN  A 35.247.124.32
    blog IN  A 221.245.168.211

それではみなさん、GitDNSOps で気持ち良い DNS 生活を!

(Photo by Roman Synkevych on Unsplash )

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください