妻が「アイスランド☆ＴＲＩＰ」という本を出版しました。出版されたのはちょっと前なのですが、最近Kindle化されたので紹介です。
この本は著者が自分の新婚旅行で行ったアイスランドの旅行記をコミックエッセイとして書いた本です。つまりこの本を読むと僕の新婚旅行の様子がわかります！もちろんそれだけではなくて、アイスランドのいろんな情報が詰め込まれているので、次の海外旅行どこに行こうかなと思っている人におすすめです。
ちなみに僕はアイスランドへの旅行は、自分が行った海外の中でも1、2を争うくらい楽しかった旅行でした。その様子は以下のブログにも書いてますが、本当におすすめです。
blog.shibayu36.org
blog.shibayu36.org
そんなわけで、アイスランドについて興味が湧いた人は是非本を買っていただければなと思います。よろしくお願いします。
妻はそれ以外にも以下の本を出しているので、興味があったらどうぞ！
[asin:B00K7TB4PO:detail]Goで書いたツールのバイナリ配布ってどうやれば良いのかなーと思っていたら、goreleaser というツールを見つけたので使ってみた。非常に便利だったのでメモしておく。
簡単に言うと、Goのバイナリのクロスコンパイルと、Github Releasesへのデプロイをやってくれる君。詳しくは https://goreleaser.com/ と https://github.com/goreleaser/goreleaser を参照。
https://github.com/goreleaser/goreleaser/releases からバイナリを取ってくるでも良いけど、僕はgo getでインストールした。
$ go get github.com/goreleaser/goreleaser
まずはリリースの設定を行う。レポジトリのルートに.goreleaser.ymlというのを置いて設定していく。僕はこんな感じで設定した。
https://github.com/shibayu36/shibayu36/blob/v0.0.5/.goreleaser.yml
builds: - binary: shibayu36 goos: - windows - darwin - linux goarch: - amd64 - 386 archive: format: zip name_template: "{{ .ProjectName }}_{{ .Os }}_{{ .Arch }}" files: - README.md release: github: owner: shibayu36 name: shibayu36
一つ一つ説明していくと
これで設定は終わり。
リリースするときは、GithubでPersonal access tokenをrepo権限で発行して、以下のようなコマンドを打つだけ。
$ git tag v0.0.5 $ GITHUB_TOKEN=... goreleaser --rm-dist • running goreleaser dev • loading config file file=.goreleaser.yml • SETTING DEFAULTS • GETTING AND VALIDATING GIT STATE • releasing v0.0.5, commit a02b3bd5240af3b7898bbfe2adcb1aad4ae39dbf • LOADING ENVIRONMENT VARIABLES • CHECKING ./DIST • --rm-dist is set, removing ./dist • BUILDING BINARIES • building binary=dist/shibayu36_windows_386/shibayu36.exe • building binary=dist/shibayu36_darwin_386/shibayu36 • building binary=dist/shibayu36_darwin_amd64/shibayu36 • building binary=dist/shibayu36_windows_amd64/shibayu36.exe • building binary=dist/shibayu36_linux_amd64/shibayu36 • building binary=dist/shibayu36_linux_386/shibayu36 • CREATING ARCHIVES • creating archive=dist/shibayu36_linux_386.zip • creating archive=dist/shibayu36_windows_amd64.zip • creating archive=dist/shibayu36_darwin_amd64.zip • creating archive=dist/shibayu36_darwin_386.zip • creating archive=dist/shibayu36_windows_386.zip • creating archive=dist/shibayu36_linux_amd64.zip • new release artifact artifact=shibayu36_windows_386.zip • new release artifact artifact=shibayu36_linux_386.zip • new release artifact artifact=shibayu36_windows_amd64.zip • new release artifact artifact=shibayu36_linux_amd64.zip • new release artifact artifact=shibayu36_darwin_386.zip • new release artifact artifact=shibayu36_darwin_amd64.zip • CREATING LINUX PACKAGES WITH FPM • skipped reason=no output formats configured • CREATING LINUX PACKAGES WITH SNAPCRAFT • skipped reason=no summary nor description were provided • CALCULATING CHECKSUMS • checksumming file=shibayu36_windows_amd64.zip • checksumming file=shibayu36_windows_386.zip • checksumming file=shibayu36_linux_386.zip • checksumming file=shibayu36_linux_amd64.zip • checksumming file=shibayu36_darwin_386.zip • checksumming file=shibayu36_darwin_amd64.zip • new release artifact artifact=shibayu36_0.0.5_checksums.txt • CREATING DOCKER IMAGES • skipped reason=docker section is not configured • RELEASING TO GITHUB • creating or updating release repo=shibayu36/shibayu36 tag=v0.0.5 • release updated url=https://github.com/shibayu36/shibayu36/releases/tag/v0.0.5 • uploading to release file=dist/shibayu36_linux_amd64.zip name=shibayu36_linux_amd64.zip • uploading to release file=dist/shibayu36_windows_386.zip name=shibayu36_windows_386.zip • uploading to release file=dist/shibayu36_windows_amd64.zip name=shibayu36_windows_amd64.zip • uploading to release file=dist/shibayu36_linux_386.zip name=shibayu36_linux_386.zip • uploading to release file=dist/shibayu36_darwin_386.zip name=shibayu36_darwin_386.zip • uploading to release file=dist/shibayu36_darwin_amd64.zip name=shibayu36_darwin_amd64.zip • uploading to release file=dist/shibayu36_0.0.5_checksums.txt name=shibayu36_0.0.5_checksums.txt • CREATING HOMEBREW FORMULA • skipped reason=brew section is not configured • SUCCESS!
これで、https://github.com/shibayu36/shibayu36/releases/tag/v0.0.5 にリリースがなされた。便利！
タグを打ってpushした時に自動でTravisCIでビルドしたいなら、.travis.ymlを以下のように設定する。
https://github.com/shibayu36/shibayu36/blob/v0.0.5/.travis.yml
language: go go: - 1.9 script: - make test after_success: - test -n "$TRAVIS_TAG" && curl -sL https://git.io/goreleaser | bash
またTravisCIの設定で、GITHUB_TOKENを設定するのを忘れずに。
あとは以下のようにコマンドを打つと、TravisCIが勝手にビルドしてリリースまでしてくれる。
$ git tag v0.0.5 $ git push $ git push --tags
便利！
今回はGoのバイナリをgoreleaserを使って配布する方法について調べたのでまとめてみた。Goで作ったツールをクロスコンパイルしてGithub Releasesで配布したいなら、goreleaserは非常に手軽にできて良いと感じた。
他にもいろいろと柔軟な設定もっといろんな設定をしたいときは、https://goreleaser.com/ や、https://github.com/goreleaser/goreleaser/blob/master/.goreleaser.yml を見ると良いだろう。
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。
Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。
まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。
この二つの役割のサーバが連動して、ドメインの名前解決は行われている。
DNSの教科書によると、DNS問い合わせは以下のような流れで進むと書いてある。スタブリゾルバというのは、名前解決のための単なるクライアントライブラリととりあえず思っておけば良い。ルートDNSサーバ、TLD DNSサーバ、組織のDNSサーバが上記した権威サーバである。
https://www.nic.ad.jp/ja/newsletter/No51/0800.htmlから図を引用すると以下のような感じ。
つまり、名前解決をしようとすると、一番上位の権威サーバへ問い合わせて、それは自分のゾーン管理下にないからこっちに聞いてねとたらい回しにされて、さらに次に聞きに行って、それはこっちに聞いてねとたらい回しにされて、という風にたらい回しの仕組みによって名前解決をしているということが分かる。
たらい回しにされながら再帰的に聞いていく役割はフルリゾルバが担い、次にどこに行くかの情報や実際に最後の結果を返すのは権威サーバが担うことになる。
ここまで理解してから、digでいろいろ試してみた。
まずはこのブログのblog.shibayu36.orgに対してdigを打ってみる。フルリゾルバにはGoogle Public DNSの8.8.8.8を指定してみる。
$ dig @8.8.8.8 blog.shibayu36.org ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 blog.shibayu36.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43553 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;blog.shibayu36.org. IN A ;; ANSWER SECTION: blog.shibayu36.org. 3599 IN CNAME hatenablog.com. hatenablog.com. 59 IN A 13.112.5.107
blog.shibayu36.orgはCNAMEで別名としてhatenablog.comを返しているので、ANSWER SECTIONには最終的にhatenablog.comのIPアドレスが返って来ている。
では、これがどのような問い合わせになっているのか、+traceオプションを付けてdigを打ってみる。
$ dig @8.8.8.8 blog.shibayu36.org +trace ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 blog.shibayu36.org +trace ; (1 server found) ;; global options: +cmd . 224784 IN NS a.root-servers.net. . 224784 IN NS i.root-servers.net. . 224784 IN NS d.root-servers.net. . 224784 IN NS l.root-servers.net. . 224784 IN NS f.root-servers.net. . 224784 IN NS c.root-servers.net. . 224784 IN NS k.root-servers.net. . 224784 IN NS j.root-servers.net. . 224784 IN NS m.root-servers.net. . 224784 IN NS g.root-servers.net. . 224784 IN NS e.root-servers.net. . 224784 IN NS h.root-servers.net. . 224784 IN NS b.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 359 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. ;; Received 438 bytes from 192.203.230.10#53(192.203.230.10) in 160 ms shibayu36.org. 86400 IN NS ns-351.awsdns-43.com. shibayu36.org. 86400 IN NS ns-591.awsdns-09.net. shibayu36.org. 86400 IN NS ns-1273.awsdns-31.org. shibayu36.org. 86400 IN NS ns-1628.awsdns-11.co.uk. ;; Received 189 bytes from 199.249.120.1#53(199.249.120.1) in 590 ms blog.shibayu36.org. 3600 IN CNAME hatenablog.com. shibayu36.org. 172800 IN NS ns-1273.awsdns-31.org. shibayu36.org. 172800 IN NS ns-1628.awsdns-11.co.uk. shibayu36.org. 172800 IN NS ns-351.awsdns-43.com. shibayu36.org. 172800 IN NS ns-591.awsdns-09.net. ;; Received 198 bytes from 205.251.196.249#53(205.251.196.249) in 26 ms
+traceオプションを付けるとblog.shibayu36.orgを名前解決するために再帰的な呼び出しをしている様子が見て取れて面白い(+traceを付けるとdigが再帰問い合わせしているけど、本当は8.8.8.8が再帰問い合わせすることに注意)。これを見ると
という風に探索していることが分かる。実際のフルリゾルバはさらにCNAMEにhatenablog.comが入っていることを見つけたらもう一度hatenablog.comを名前解決をして、Aレコードを見つけることになる。これはdig hatenablog.com +traceを実行すれば様子が分かるだろう。
では続いて存在しないドメインの名前解決をしたときの応答を見てみる。
例えば、wrong.shibayu36.orgというドメインは存在しない。これに対してdigを打つと
$ dig wrong.shibayu36.org ; <<>> DiG 9.8.3-P1 <<>> wrong.shibayu36.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59271 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrong.shibayu36.org. IN A ;; AUTHORITY SECTION: shibayu36.org. 300 IN SOA ns-1628.awsdns-11.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
のように、NXDOMAINという「ドメインが存在しない」という状態をSOAレコードとして返す。この応答のTTLは300になっているので、5分間はこの結果がキャッシュされることも分かる。
これを+trace付きで見ると
$ dig @8.8.8.8 wrong.shibayu36.org +trace ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 wrong.shibayu36.org +trace ; (1 server found) ;; global options: +cmd . 12337 IN NS e.root-servers.net. . 12337 IN NS l.root-servers.net. . 12337 IN NS m.root-servers.net. . 12337 IN NS d.root-servers.net. . 12337 IN NS a.root-servers.net. . 12337 IN NS b.root-servers.net. . 12337 IN NS k.root-servers.net. . 12337 IN NS j.root-servers.net. . 12337 IN NS i.root-servers.net. . 12337 IN NS h.root-servers.net. . 12337 IN NS c.root-servers.net. . 12337 IN NS f.root-servers.net. . 12337 IN NS g.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 70 ms org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS d0.org.afilias-nst.org. ;; Received 439 bytes from 192.228.79.201#53(192.228.79.201) in 142 ms shibayu36.org. 86400 IN NS ns-351.awsdns-43.com. shibayu36.org. 86400 IN NS ns-591.awsdns-09.net. shibayu36.org. 86400 IN NS ns-1273.awsdns-31.org. shibayu36.org. 86400 IN NS ns-1628.awsdns-11.co.uk. ;; Received 190 bytes from 199.249.120.1#53(199.249.120.1) in 384 ms shibayu36.org. 900 IN SOA ns-1628.awsdns-11.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Received 124 bytes from 205.251.193.95#53(205.251.193.95) in 99 ms
となり、Route53のサーバがNXDOMAINという結果を返していることが分かる。これはshibayu36.orgまでは存在して、wrong.shibayu36.orgが存在しないので、shibayu36.orgを管理しているRoute53がNXDOMAINを返しているようだ。
では続いて、blog.shibayu36hogehogehoge.orgというドメインを名前解決してみると
$ dig @8.8.8.8 blog.shibayu36hogehogehoge.org +trace ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 blog.shibayu36hogehogehoge.org +trace ; (1 server found) ;; global options: +cmd . 193946 IN NS b.root-servers.net. . 193946 IN NS l.root-servers.net. . 193946 IN NS m.root-servers.net. . 193946 IN NS j.root-servers.net. . 193946 IN NS h.root-servers.net. . 193946 IN NS k.root-servers.net. . 193946 IN NS d.root-servers.net. . 193946 IN NS g.root-servers.net. . 193946 IN NS c.root-servers.net. . 193946 IN NS f.root-servers.net. . 193946 IN NS e.root-servers.net. . 193946 IN NS a.root-servers.net. . 193946 IN NS i.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 109 ms org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. ;; Received 450 bytes from 192.228.79.201#53(192.228.79.201) in 197 ms org. 900 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2012680558 1800 900 604800 86400 ;; Received 111 bytes from 199.19.57.1#53(199.19.57.1) in 202 ms
となり、orgドメインを管理している権威サーバがNXDOMAINを返していることが分かる。これはorgドメインはあるけど、shibayu36hogehogehoge.orgはないので、orgドメインを管理している権威サーバがNXDOMAINを返すわけである。
このように、ドメインが存在しないときは、そのゾーンを管理している権威サーバがNXDOMAINを返すということが分かった。
以上を勉強してから、結局ioドメイン障害では何が起こっていたのかを自分なりに整理してみる。
起こっていたことは去年に起こった障害とほぼ近く、状況については .io ドメインがおかしくなったので dig で調べてみた（2016/10/28） - Qiita を見ると大体把握できる。また今回の状況は .IO TLD DNS issues and a day without Cloudflare に載っていたのだけど
The .IO TLD uses 7 different nameservers for its top level domain; a0.nic.io, ns-a3.io, c0.nic.io, ns-a2.io, b0.nic.io, ns-a1.io and ns-a4.io. 2 of those nameservers, ns-a2.io and ns-a4.io, started misbehaving and instead of returning with a correct set of nameservers for the domain you were requesting, started to reply with an NXDOMAIN result. Essentially declaring that the domain you were requesting, didn’t exist.
と書いていて、7つあるioドメインの権威サーバの内、2台(ns-a2.ioとns-a4.io)が、本当は存在するドメインに対してもNXDOMAINを返してしまっていたということだった。例えばblog.shibayu36.ioというドメインが存在するとした時、
となるべきだったのに
ということが起こっていたという感じ。
さらに困ったことに、この結果をSOAレコードでTTL 900で返すため、フルリゾルバは900秒間この結果をキャッシュしてしまい、一度ns-a2.ioもしくはns-a4.ioに当たって、変な結果を貰ってしまったら、900秒間は名前解決に失敗し続けるという状況になっていた。
また、Google Public DNSは8.8.8.8の裏側に何台もフルリゾルバを配置している。このため、同じ8.8.8.8で名前解決をしようとすると
という風になり、確率的に名前解決に失敗しているように見える、という状況となっていた。
権威サーバが壊れるととにかく怖い！
