空飛ぶコンソメスープを飲み比べる。
— 殊海夕音 (@yune_kotomi) May 7, 2019
ANAとJALのスープの粉が両方手に入ったので、飲み比べてみたんですよ。
機内で飲む分には、間が開いてるのもあって*1特に違いは気づかなかったんだけど、並べてみるとかなり味が違う。
ANAの方が甘みがあって、JALの方が辛めでスパイシーな感じ。好みを言うとANAの方かなと思いつつも、単にそれは馴染みがあるからってだけな気もする。JALのやつの方はクルトンが入っていて、食事に添えるには良いかも*2。
尚、メーカーが別なんだし味が違うのは当然ではある。
機内ドリンクサービスのスープ、ANAのはネスレでJALのは明治という知識を得た。
— 殊海夕音 (@yune_kotomi) June 6, 2018
ちなみにAIRDOのは(株)グリーンズ北見である。
販路もパッケージングも違って、ANAのやつは20袋入りで空港売店だけで売ってる。対してJALのは4袋入りのがその辺のスーパーで売られている。
監視をStackdriveで行う。
ログ管理やアラートメール送信って邪魔くさくないですか？ElasticSearchやKibanaなんかで作る今時のログサーバがあると便利だろうけど、小規模サービスにはオーバースペックだし、メールを使わないサービスなのにわざわざメールサーバ用意してアラートメール送信できるようにするのも本末転倒な気がする。単純な送信ロジックだと、似たようなアラートが大量に出るとメールボムになるから、案外気を使うところも多い。
そこでカケラの樹では、Stackdriverを使ってみることに。
導入方法
Railsアプリケーションの場合、最低限Gemfileでstackdriver gemを追加するだけで動作する。設定項目は次のドキュメントを参考に。
googleapis.github.io
カケラの樹での変更は以下のコミットのとおり。
gitlab.com
config.google_cloud.logging.log_nameに日本語を入れるとログ収集が行われなくなったので、アルファベットにしておいたほうが良さそう。
できること
他にも色々機能があるが、とりあえず簡単に使えるものをいくつか。
ログ閲覧・検索
GCPのコンソールからLoggingを開くと、ログがブラウザから閲覧できる。検索も可能。
アラート通知
アラートが発生すると通知される。デフォルトではGCPのモバイルアプリへのプッシュ通知が送信される。メールを受信したい場合、コンソール右上の設定を開き、Stackdriver Error Reportingのメールアドレスの項目にチェックを入れる。
類似した例外が複数発生した場合、勝手にまとめてくれる。
デバッグ
画面上から指定した位置での呼び出し履歴を調べたり、変数の値のウォッチが出来る。本番環境で実行中のインスタンスを観察できるのでこれは便利。
ウォッチ式等の副作用でアプリケーションの動作が変わるのを防ぐ仕組みが入っていてかなり厳しいので、誤検知の場合は式全体をGoogle::Cloud::Debugger.allow_mutating_methods!で囲んでやるとよい。
GCEでライブパッチは使えなさそう。
手元の端末でcanonical-livepatchが動いてるのを見て、そういえば3台までいけるんだからサーバでも使おうか、と思った。
$ uname -a Linux yumenosora 4.15.0-1024-gcp #25~16.04.2-Ubuntu SMP Tue Oct 30 14:14:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ sudo snap install canonical-livepatch canonical-livepatch 8.0.6 from 'canonical' installed $ sudo canonical-livepatch enable [トークン] 2018/11/19 14:20:31 cannot use livepatch: your kernel "4.15.0-1024-gcp" is not eligible for livepatch updates
にゃうーん。Compute Engine上では専用のカーネルが使われるけど、ソレにライブパッチは使えない、みたい。残念。
さよならはてなダイアリー。
はてダからの移行作業を行いました。混んでて中断されてるって話を聞いてたから今までやらなかったんだけど、そろそろほとぼりも冷めたんかな。さほど記事数が無いからっていうのもあると思うけど、30分程度でインポート完了。
一時期に比べて書く量はすごい減ったけど、これからはこっちでいろいろと書いていきます。
DNS over HTTPSで名前解決を保護する。
角川の金盾の件も頭の片隅には置きつつ、それ以前に、名前解決が平文で行われるのはセキュアではないよね、と思ったので、最近話題のDNS over HTTPSを使って名前解決が出来るようにしてみる。
環境はUbuntu 18.04 LTS。
まずはdnscrpyt-proxyをインストールする。
sudo add-apt-repository ppa:shevchuk/dnscrypt-proxy sudo apt install dnscrypt-proxy
で、設定ファイルを変更。
/etc/dnscrypt-proxy/dnscrypt-proxy.toml
--- dnscrypt-proxy.toml.orig 2018-10-16 21:15:17.821726742 +0900 +++ dnscrypt-proxy.toml 2018-10-16 21:23:20.394256628 +0900 @@ -27,13 +27,13 @@ ## The proxy will automatically pick the fastest, working servers from the list. ## Remove the leading # first to enable this; lines starting with # are ignored. -# server_names = ['scaleway-fr', 'google', 'yandex', 'cloudflare'] +server_names = ['google', 'cloudflare'] ## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6. ## Note: When using systemd socket activation, choose an empty set (i.e. [] ). -listen_addresses = [] +listen_addresses = ['127.0.0.1:53']
server_namesはお好みで。GoogleのとCloudflareのがあればいいだろうって判断したけど、検閲絡みのハナシを考えるとscaleway-fr(フランス?)とかyandex(ロシア)のも入れておいたほうがいいのかな。とはいえ起動時のRTT判定で十中八九Cloudflareが選択されるので変化はないかも。
このままでは起動しなかったので、systemdのUnitファイルにちょっと書き足す。
/lib/systemd/system/dnscrypt-proxy.service
--- dnscrypt-proxy.service.orig 2018-10-16 21:16:23.818348613 +0900 +++ dnscrypt-proxy.service 2018-10-16 23:09:48.422039898 +0900 @@ -20,6 +20,7 @@ CacheDirectory=dnscrypt-proxy LogsDirectory=dnscrypt-proxy RuntimeDirectory=dnscrypt-proxy +AmbientCapabilities=CAP_NET_BIND_SERVICE [Install] Also=dnscrypt-proxy.socket
この変更入れないと、DynamicUser=yesだから一般ユーザとして起動するのに、53番をlistenしようとしてコケるんだよね。
で、systemd-resolvedを殺す。
sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved
最後に、名前解決をlocalhostでやるようにする。
$ cat /etc/resolv.conf nameserver 127.0.0.1:53
再起動して完了。システムごとでもいいし、サービス再起動でも動くはず。
sudo systemctl restart dnscrypt-proxy sudo systemctl restart NetworkManager