Nest Wifiをmy new gear…したのが5/2で、10日後の5/12にRT-AX3000をmy new gear…した。間取りの都合上、Nest Wifi1台では家全体をカバーすることができなかったというのが一番大きな理由なんだけど、元々解決したかった問題なども記録しておく。

ネット環境

我が家の環境としては、J:COMのネットパックの1Gコースを契約している。ネットパックというプランだけど、ケーブルテレビの契約は無しで、回線とプロバイダのみの契約。ただ、このプランはインターネットには載っていなくて、よくわからんという感じ。機器込で月額5000円未満くらい。

J:COMの回線は、インターネットではすこぶる評判が悪い。しかし、自分の環境ではそれほど困ったことはなく、メールで問い合わせたらすぐに返事は来るし、故障や障害の対応についても不満はなく、そこそこ満足している。

ちなみに、我が家でJ:COMのネット回線を使っている一番の理由は、J:COMの回線がテレビのケーブルを使っているため、ルーターをテレビの近くに置けて便利というところ。光ケーブルの出てくるところが、間取り的にあまりよいところではないし、テレビの近くならゲーム機を有線でつなぎやすい。

肝心の速度については、日中は下りが400Mbpsで上りが80Mbpsくらい。レイテンシは20msecくらい出るので若干遅い方だと思う。夜のピークでもそれほど変わらず、家族がストリーミングしたりしてると下りが100Mbpsで上りが30Mbpsくらいまで落ちることがある。ただ、これくらい出れば日常生活やdocker pullで困ることはない。

そうだ、ルーターを変えよう

今までは、J:COMの終端装置的なものがルーター機能もついているものだったのでそれをそのまま使っていた。しかし、今年の1月から在宅勤務が本格的に始まり、ビデオチャットなど動画をストリーミングする機会が増えると、途中で切れてしまったり明らかに品質が落ちるのが気になるようになった。この現象は、MeetでもZoomでも、奥さんのニコ生でも起きていたので、自宅の環境の問題だなと思い、まずはすぐに変えられそうなルーターを変えることにした。

そこで、たまたま奥さんのPixel 4を買ったときのクーポンの使いみちがなかったことから、とりあえずNest Wifiを買ってみるかと買ってみたのだった。

Nest Wifi、通信は安定するけど壁を挟むとすぐ2.4GHzになる問題

Nest Wifiが届いたので使ってみると、まず初期設定やスマホアプリの素晴らしさに感動し、さらにストリーミングで切れることはなくなって一時は優勝かと思ったけど、壁や扉を挟むとすぐに2.4GHzに切り替わってしまうという問題発生した。また、電波の届き具合も最初にあったルーターよりも弱く感じたので初期不良なども疑ったのだけど、Google Wifiをマンションで使った感想とオススメしない理由 - Koichiro, Sumi - Medium を見たら自分と同じ状況だったので、こういうものかと納得した。

こんにちは「RT-AX3000」

で、今使っているのがASUS RT-AX3000というやつ。これは、自分の用途と家の間取り的には不満がないという状況。良いところと良くないところを上げるとするとこんな感じ。見た目以外は満足している。

• 良い点
  • 最初の不満であったストリーミングで切れなくなった
  • Nest Wifiの不満であった寝室や風呂場でも十分な速度がでるようになった
  • Wifi 6とWPA 3に対応してる
• 良くない点
  • アンテナがのびてるデザインが好みじゃない

Wifi 6対応とかはあまり興味がなかったのだけど、ようやくエントリーモデルがで始めたところらしいので、価格.comなどで比較してこれにした。選んだポイントとしては、発売年月が新しいことと、WPA3対応くらい。あとはもちろん値段。

おわりに

というわけで、ここ最近のmy new gear…である無線ルーターについてまとめた。Nest Wifiでメッシュを組む手もあったのだけど、都会のマンションで壁を超えるためだけにメッシュ組むのかと思うとつらい気持ちになったので、思い切って買い替えたのであった。

毎月第2金曜はペパボテックフライデー。今回は最近取り組んでいるカラーミーショップWPプラグインについて、開発環境周りの話をした。動画はこちら。

カラーミーショップWordPressプラグイン開発における最近の改善 - ペパボテックフライデー2020-05-08 - YouTube

ここ数日お仕事が立て込んでいたので、ゆっくり発表する余裕がないかもしれないと思い、事前に動画を撮っておいた。なんとか顔を出すくらいはできそうだったのでmeetを繋いだのだけど、「自分のPCから自分のYouTube動画を画面共有する」という今まで体験したこと無い発表体験ができたのでよかった。

撮影の環境などについては、こなれて来たらまとめようと思う。

ロリポップ！マネージドクラウド(以下マネクラ)へのRails(Ruby)アプリケーションのデプロイは、Herokuと同じようにgit pushをすることでbundle installやDBのマイグレーションなどが自動で行われるようになっている。このウェブ日記もRailsで作っていて、そのデプロイをGitHub Actionsで自動化したのでそのやり方や試行錯誤の過程を記録しておく。

2020-05-02時点で利用している完全なYAML

「結論ははじめに」ということで、以下ようなYAMLと2つのsecrets(SSH_PRIVATE_KEYとLOLIPOP_REPOSITORY_URL)を用意すれば、masterへのpushをトリガーにしてマネクラにRailsアプリケーションがデプロイされる。

name: deploy

on: 
  push:
    branches:
      - master

jobs:
  deploy_to_lolipop_mc:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        fetch-depth: 0

    - uses: webfactory/ssh-agent@v0.2.0
      with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
    
    - name: add known_hosts
      run: cat .github/workflows/known_hosts >> ~/.ssh/known_hosts
    
    - name: git remote add
      run: git remote add lolipop ${{ secrets.LOLIPOP_REPOSITORY_URL}}

    - name: git remote update
      run: git remote update

    - name: deploy
      run: git push lolipop HEAD:master

各stepを簡単に解説する。

• checkout@v2にfetch-depth: 0を設定する。デフォルトでは1となっていてgitの履歴をとってこない設定になっているため、マネクラ側にpushする際にnon-fast-forwardと判定されてしまう。デフォルトのままにしてgit push -fとする手もあると思う。
• webfactory/ssh-agentを使ってsshの秘密鍵を使えるようにする。(後述)
• webfactory/ssh-agentはknown_hostsの管理はやってくれないので、リポジトリ上にknown_hostsをコミットしておいてそれを書き込む。(後述)
• マネクラのgitリポジトリをremoteに追加する。
• git pushのためには一度fetchしてくる必要があるのでremote updateする。
• マネクラのgitリポジトリにpushする。

今回は、テストの実行などはステップに含めていない。デプロイだけであればこれくらいのステップ簡単にできる。

webfactory/ssh-agent でsshの秘密鍵をメモリ上で管理する

SSHの鍵認証しか許していないサーバにGitHub Actionsの中からアクセスするためには、GitHub Actionsが動作している環境に秘密鍵を置く必要がある。 GitHub Marketplace · Actions to improve your workflowをsshで検索するといくつかsshができるようにするActionsがあることがわかるが今回はwebfactory/ssh-agentを利用した。

sshとその秘密鍵を利用可能にするActionsは大別すると以下の2種類がある。

• ssh-agentを実行する(webfactory/ssh-agent)
• ~/.ssh に秘密鍵を書き込む

GitHub Actionsの実行モデルはよく理解できていないが、実行環境のローカルファイルシステム上に秘密鍵を書き込むよりはメモリ内に留められる方法のほうがよかろうと思い、このActionsを使うことにした。なお、公式のactions/checkoutでも秘密鍵を扱う仕組みはあって、ファイル名をランダムにして書き込むということをしている。

https://github.com/actions/checkout/blob/94c2de77cccf605d74201a8aec6dd8fc0717ad66/src/git-auth-helper.ts#L186-L197

Secretsに登録する秘密鍵とURLを準備する

デプロイに使う秘密鍵は、GitHub Actions専用のものを用意したほうが安全だろう。マネクラではキーペアを簡単に作成・登録できる仕組みがあるので、この機能を使ってデプロイ用のキーペアを作っておく。Ed25519の鍵ができるので強度も安心。

ここで作成してダウンロードされた秘密鍵の中身をそのまま、GitHub側に SSH_PRIVATE_KEYというsecretsに登録すればOK。

また、LOLIPOP_REPOSITORY_URLという名前で、マネクラのコンパネに書かれているリポジトリ「ssh://xxxxxx@yyyy.lolipop.jp:port/」を追加しておく。

Actionsの実行に必要な秘匿情報の追加はこれでおわり。

known_hostsをリポジトリに入れる

sshで初めて接続しようとしたときにプロンプトが出てくるアレのこと。何らかの方法でマネクラサーバのホストキーをknown_hostsにいれないとgit pushができないのだ。webfactory/ssh-agentのREADMEでは、actionsの中でssh-keyscanを使って書き込むか、この内容は秘匿情報ではないのでリポジトリにコミットするとよいと書かれている。このファイルの目的は、READMEにもあるとおり接続先のサーバが正しいものか、MITM攻撃にあっていないか、を検証するためのものなので、Actionsの中で毎回取得するよりは同じものを使ったほうが良いだろうと思い、コミットすることにした。

マネクラのコンパネからリモートリポジトリの情報を元に、以下のコマンドで実行することでホストキーを取得することができる。しかし、マネクラ側のSSHコンテナが起動していないと鍵がうまく取れないことがあるので、事前に別のターミナルなどでSSHをつないでおいたほうがいい。

ssh-keyscan -p <your port> -H <your ssh host>

上のコマンドを実行したときに、stderrに以下のような文字列が出てきたら、一度SSHしてから試してみるとうまくいく。

xxxx.mc.lolipop.jp: Connection closed by remote host

この問題のせいで、Actionsの中でssh-keyscanするのはひと手間掛かりそう。

おわりに

GitHub Actionsを使ったマネクラへのデプロイは、sshの秘密鍵をどう管理したらいいかわからずに二の足を踏んでいたのだけど、改めて学習し直して自分なりに安全な方法を考えてみた。マネクラでもこれで継続的なデプロイをGitHubだけで完結させることができるので、かなり便利ではないかと思う。

この方法でも危険な部分などあったら、是非コメントやツイッターなどで教えてください。

おまけ

テックブログでのロリポ関連の記事を読んだことで、この記事を書くモチベーションがあがりました。@antipopと@linyowsに感謝！

• GitHub Actionsで「ロリポップ！」「ヘテムル」をもっと便利に使おう - ペパボテックブログ
• PRPLパターンで「ロリポップ！」「ヘテムル」のWordPressを爆速にしよう - ペパボテックブログ

久しぶりにsnapで入れたmicrok8sを動かそうとしたら全然動かなくて、調べていくとAppArmorが動かなくなっていることに気付いた。

AppArmorの起動ログには、以下のようにcapabilityがおかしいというエラーがたくさんでていたのだけど、さすがに sys_admin がないというのはおかしい。

AppArmor parser error for /etc/apparmor.d/sbin.klogd in /etc/apparmor.d/sbin.klogd at line 17: Invalid capability sys_admin.

インターネットの海をさまようと、AppArmorのissue Make.rules fails to generate cap_names.h and af_names.h (#74) · Issues · AppArmor / apparmor · GitLab と、Gentoo側のissue 714158 – sys-apps/apparmor-2.13.4 -> ? fails at runtime if built with sys-devel/make-4.3をみつけて、なるほどとなった。

Gentoo側のissueの通り、make 4.3をmaskして4.2に落として、再度コンパイルしたら動くようになったのでよかったですね。

数日前のGURUの記事に対してursmがmentionをくれたので早速移行した。

時代は eselect-repository

— Keita Urashima (@ursm) April 5, 2020

移行といっても、実際はemerge eselect-repositoryをするだけでよいので楽ちん。layman -lとeselect repository list -iを見比べて、有効になっているoverlayが同じだったらOK。

[11:20:33] in ~ via 💎 v2.7.1
❯ layman -l

 * dotnet                    [Git       ] (https://github.com/gentoo/dotnet.git                                              )
 * go-overlay                [Git       ] (https://github.com/Dr-Terrible/go-overlay.git                                     )
 * guru                      [Git       ] (https://anongit.gentoo.org/git/repo/proj/guru.git                                 )
 * jorgicio                  [Git       ] (https://github.com/jorgicio/jorgicio-gentoo.git                                   )
 * snapd                     [Git       ] (https://github.com/zigford/snapd.git                                              )


[11:23:36] in ~ via 💎 v2.7.1
❯ sudo eselect repository list -i
Available repositories:
  [99]  dotnet # (https://github.com/gentoo/dotnet)
  [148] gentoo * (https://gentoo.org/)
  [163] go-overlay # (https://github.com/Dr-Terrible/go-overlay)
  [168] guru # (https://wiki.gentoo.org/wiki/Project:GURU)
  [197] jorgicio # (https://github.com/jorgicio/jorgicio-gentoo)
  [276] pepabo @
  [349] snapd # (https://github.com/zigford/snapd)

eselect-repositoryの方は、privateなリポジトリもでて便利。よかったよかった。

see also: eselect/repository - Gentoo Wiki

Rustで書かれたモダンpsことdalance/procsのebuildファイルをGURUにコミットした。

Rustのツールをebuildにするのはcardoe/cargo-ebuildというコマンドを使うと一撃でできるのだけど、出来上がったebuildファイルにコメントがあるとおり、このツールではライセンスのリストがうまく出せないことがある。

cargo-ebuildが出力するebuildファイルのLICENSEの部分は、リンクする全てのライブラリのライセンスを集めてきて出してくれるのだけど、

• 2つのライセンスが設定されている場合は両方でてくるが、実際にはどちらか一方となっているものも多い
• portageのLICENSE名と必ずしも一致していない

という問題がある。

最終的にどういうライセンスにすればよいかは、onur/cargo-licenseというものを使えと書いてあって、これがメチャクチャ便利…すごい。これの出力をみながら、最小限のANDをとっていくとよさそう。

portageのライセンス名とのマッチングは License groups - Gentoo Wiki このあたりを見ながらマッチングしていけば良さそう。procsのebuildを作るにあたり困ったのは、BSD-3-Clauseというライセンスで、これはportage的にはBSDというライセンスだったので直したりした。

日課のうどんワールドとdepcleanの後、ChWick/gnomesome が動かなくなっているのに気付いて、GNOME Tweaksを見てみるとClutterがないよーというエラーが出ていた。

eix -e clutterを見てもたしかに入ってないし、/var/log/emerge.logを見るとdepcleanでも消えてることに気付いた。

とりあえず復旧させたいのだけど、Clutterを直接入れるのも違うよなーと思って、一番それっぽいgnome-shell-extensionsを入れてお茶を濁す子にした。

depcleanするときはよく画面を見ましょう。

june29の Social Distancing と 2020 年 - #june29jp を楽しく読ませてもらった記憶も薄れないうちに、緊急事態宣言のニュースが飛び込んできた。

この発表内容およびスピーチについて、自分の立場と今の家庭環境においては、よいスピーチだと感じたし、内容についても引き続き頑張っていこうと思えるものだった。

さて、GMOインターネットグループの在宅勤務が始まったのは2020-01-27なので今月末で3ヶ月だ。この期間、インターネットを介さずに会話をした人は、家族、お隣さん、マンションの清掃の方、お店のレジの人、配達業者の方、これくらいだ。知人と呼べる人とはすべてインターネットでのみ繋がっている。自分と社会の接点はインターネットになったように思えた。

今の自分は、「インターネットでも繋がっている」と「インターネットで繋がっている」の違いに戸惑っているのかもしれない。インターネット大好きだと思っていた自分が、「繋がり」の手段がインターネットに限定されたことによってストレスを感じているのかもしれない。

昨日、新型コロナウィルスと私と - 良いあそなすちゃんを読み、似たような思いをもっている人がn人いることを知って、心が少しだけ穏やかになった気がした。数ヶ月前なら許容できた言葉や、素直に受け止めることができたであろう言葉に、今は強く心を動かされてしまっている自分を許すことができるようになった気がした。

「今はしょうがないよ」。そう思いながら、青い鳥のアイコンを長押しして、左上に出てきた☓ボタンを押した。

NewRelicには、NRQL(New Relic Query Language)というクエリ言語を使って、NewRelicに溜まっている様々なデータを検索したりする仕組みがある。

NRQLについては、社内でもたまに勉強会が行われていて(New Relic勉強会をペパボ社内で開催しました - ペパボテックブログ)、うまく活用しているサービスも多い。

これとAlertsを組み合わせると、特定のエラーの発生や、エラーの傾向の変化でアラートを発生させることができるようになる。

NRQLとデータ構造

NRQLで扱うことのできるデータは NRQL入門 | New Relicのドキュメント あたりにまとまっており、アプリケーションのエラー情報は TransactionError に入っている。

さて、次はこのデータ構造がどうなっているかを調べる必要があるのだけど、それは New Relic data dictionary | New Relic Documentation を見るとわかる。もしくは、Insightsという機能で

SELECT * FROM TransactionError

といったクエリを流してみると、具体的にどういう情報が入っているかわかると思う。error.classやerror.messageにどういった文字列が入るかは言語に依るところがあるので、実際のデータをみるのはどちらにしても必要だろう。

ドキュメントにはなさそうだけど面白いカラムとしてaggregateFacetというものがある。NewRelicやこの手のエラートラッキングシステムでは、類似のエラーをまとめる機能がだいたいついているが、このキーとなるのがaggregateFacetというカラムのようだ。今回は使わなかったが、このカラムのユニークカウントの傾向で、新しいエラーが起きているかを検知できそう。

NRQLでAlertsを設定する

TransactionErrorの内容はわかったので、これをアラートに適用していく。今回は「PHPを使ったアプリケーションで、WARNINGもNewRelicに通知しているが、E_ERRORが一定数を超えたときにアラートにしたい」ということをやった。

「Alerts poricies」がなければ新しく作り、あるものに追加するのであればそれを選び、「add a Condition」を選ぶと「Categories」の中に「NRQL」があるので選ぶ。

今回設定したクエリは以下の通り。PHPアプリケーションの場合は、error.classにはE_ERRORやE_WARNINGといった文字列が入っていることがわかったので、これをつかってWARNINGを除いた単位時間あたりの数をアラートのしきい値にすることにした。

select count(*)
from TransactionError
where appName = 'your-app-name' and error.class not in ('E_USER_WARNING', 'E_WARNING')

アラートのしきい値の設定方法は以下の３つがあり、今回は「Static」を選んだが、他２つも便利そうなのでいつか使ってみようと思う。

• 固定値の「Static」
• 傾向を見る「Baseline」
• ２つの値の関係をみる「Outliner」

実際に設定したのは画面はこんな感じ。時間や縦軸はぼかしてある。

おわりに

NewRelic(NRQL)を使って、特定のエラーの発生を通知する仕組みについて紹介した。エラーのトリアージが必要な場合もあると思っていて「新しい機能をリリースしたのでその機能に関係するエラーについてのみ知りたい」「特定の画面は特に重要度が高いので、通知のポリシーを分けたい」といったような使い方にも応用できると思う。

タイトルには「エンジニアのための」とあるが、3章の事例がエンジニアにとって身近な話題というだけで、一般的なリスクマネジメントの歴史から言葉の定義、関連する標準規格まで幅広くおさえられる書籍だと感じた。

特に、リスクコントロールの4つのパターン、「保有」「低減」「回避」「移転」という考え方を知ることができたのは、明日から役立つ内容でよかった。

仕事でもリスクの評価と対応について検討する機会があるが、リスクの評価については書籍のとおり「発生可能性」と「影響度」でマッピングしているものの、その後の対応をどうするかというのは迷うことがあった。この本のおかげで、より自信をもって論理的に判断できるようになったと思う。「リスクを保有する」と判断することもコントロールしていることなのだ。

また、3章のコラム的なところで、「防止的コントロール」と「発見的コントロール」という概念を知ることができたのも収穫だった。リスクに対処しようとすると、発生要因を潰す防止的コントロールを選択しがちだ。しかし、リスクの評価結果によっては、リスクが顕在化してからのダメージを軽減するための「発見的コントロール」でも十分のケースもあり、多くの場合は発見的コントロールのほうがコストが低いのだ。

このあたりも、なんとなくそういう選択をしていることはあったように思うが、これからはより意識的に選択することができるように思う。

本書を読んだことで、リスクマネジメントについての語彙や考え方を身につけることができ、今までやってきたことの意味を再確認できた。

エンジニアはもちろん、情報技術に関わる人で、リスクマネジメントを学ぶ際に最初に読む一冊としてとても良い内容ではないかと思った。索引や参考文献が数多く載っているので、より深く学びたいときのポインタも十分にあるのもおすすめポイントだ。

より細かい読書メモはscrapboxの エンジニアのためのリスクマネジメント入門 - kenchan にあるので、興味のある方はぜひ。