買ってよかったもの(2021年後半7~12月)

はじめに

2021年7~12月で買ってよかったものを紹介します。

紹介

購入して毎日使っているものや生活を変えてくれたものをよかったと判断して紹介します。

ソニー ワイヤレスノイズキャンセリングイヤホン WF-1000XM4

電車で移動する時やたまに出社した時にオンラインMTG用として使っています。 良いところは、マイクのノイズの除去です。 出社先の環境に騒音があっても除去してくれます。 オンラインMTGをする際に、周りの騒音をあまり気にしなくて済むようになりました。

ソニー ワイヤレスネックバンドスピーカーSRS-NB10

www.sony.jp

リモートワークで自宅で仕事をする際のオンラインMTG用として使っています。 ネックバンドなので、耳が圧迫されず長時間のMTGでも耳が痛くならないのが良いです。 長時間ずっとオンラインMTGをつけっぱなしにすることが多い障害対応などにはピッタリですね。

Kindle Paperwhite シグニチャー エディション

数年前のモデルを持っていたのですが、故障してからiPadでずっと本を読んでいました。 今回新モデルが出るということで購入してみたのですが、画面が大きくなり防水であるのが素晴らしいです。 防水なのでお風呂に入りながら読書をしています。 iPadで読書していた時は、読書が習慣にはならなかったのですが(iPadは色々なことができるので、読書していても気がつくとTwitterをしている)、このKindleを使うようになってからは読書が習慣となりました。

ZOJIRUSHI 象印 スチーム式加湿器 (木造6畳/プレハブ10畳) EE-RR35

しっかり加湿をしてくれます。お手入れも簡単です。 ただし、ちょっと音は加熱式なので大きめです(といっても、つけながら私は寝ることはできています)。

HARIO (ハリオ) V60 01 透過 コーヒードリッパー クリア コーヒードリップ 1~2杯用 VD-01T

HARIO(ハリオ) コーヒーミル 透明ブラック 手挽き セラミック スリム MSS-1TB

山善 電気ケトル 電気ポット 0.8L (消費電力 1200W / 温度設定機能/保温機能/空焚き防止機能) ブラックブロンズ EGL-C1280(BB)

コーヒを豆から手引きで挽いて飲むようになりました。 挽きたては、本当に美味しいです。 美味しいコーヒがあることで、仕事の時間もいつもよりちょっと楽しい時間になるので、コーヒは素晴らしいです。

Nintendo Switch有機ELモデル)任天堂

www.nintendo.co.jp

想像よりも、画面サイズが大きくなったことと有機ELであるのがよかったです。 携帯モードでゲームをすることがかなり多くなりました。 気軽にゲームをやりたくさせてくれます。 隙間時間でやるようになり、脳トレとかの長時間やらないようなゲームもやる機会が増えました。 今まで購入直後だけやってあまり進めることができていなかったのでよかったです。

障害対応演習のためにDatadogへの通信を遮断してDatadogダウン状態を模倣する

環境

  • CentOS 7.3.1611
  • Datadog Agent v6.15.0

背景

障害対応演習のために外部サービスのダウン状態を模倣したかった。 今回は、Datadog がダウンしたことを再現したかった。

方法

iptables のルールを追加して、Datadogへの疎通ができない状態にする。これによりメトリクスが送付されなくなる。--gid-owner オプションを用いる。 今回は、Datadog Agent の通信について遮断したいので、--gid-owner を Datadog Agent のグループにした。他のサービスで行うにはそのサービスのグループを指定するとよいだろう。

$ iptables -A OUTPUT -p tcp -m owner --gid-owner ${ Datadog Agentのグループ } -j DROP
$ iptables -A OUTPUT -p udp -m owner --gid-owner ${ Datadog Agentのグループ } -j DROP

設定の削除は、以下で行う。

$ iptables -nl --line-numbers
$ iptables -D OUTPUT ${ 上記で追加したルール番号 }

TerraformでRSTORE Spaceを扱う

背景

TerraformでS3互換のオブジェクトストレージRSTORE Spaceを扱いたい。

方法

S3互換なのでaws プロバイダーが使えるが、いくつかオプションをデフォルト値から変える必要がある。

resource

resource として扱う場合は、skip_credentials_validation, skip_region_validation, skip_requesting_account_idtrueにする(AWSの場合はバリデーションした方が好ましいが、RSTOR Spaceの場合はAWSではないので失敗するから、バリデーションはスキップする)。

例:バケットtest-buckettest.txtを配置する

provider "aws" {
  region                      = "ここにRegion"
  skip_credentials_validation = true
  skip_region_validation      = true
  skip_requesting_account_id  = true
  endpoints {
    s3 = "ここにEndpoint"
  }
}

resource "aws_s3_bucket_object" "test_copy_object" {
  bucket = "test-bucket"
  key    = "test.txt"
  source = "test.txt"
}

backend

backendとして扱う場合は、skip_region_validation, skip_credentials_validationtrueにする。

例:

terraform {
  backend "s3" {
    bucket                      = "bucket-name"
    key                         = "terraform.tfstate"
    endpoint                    = "ここにEndpoint"
    region                      = "ここにRegion"
    skip_region_validation      = true
    skip_credentials_validation = true
  }
}

AWS RDSのSLAの英語版ドキュメントの場所

背景

aws.amazon.comAWS RDSのSLAに関するドキュメントあるが、現時点(2021/10/16)では、「Español」と「Français 」しかない。 Englishのドキュメントを見たい。

解決策

aws.amazon.com において、右上の「日本語」を「English」に変えると英語版のSLAのドキュメントを見ることができる。

障害対応演習のために再起動からVMが復帰しない状況を意図的に作る

環境

背景

vSphere HAによってvSphereホスト障害時VMは再起動が走るが、その際に稀にVMが復帰に失敗することがあった。 この障害に対する障害対応演習を行うために、VMを再起動した際に起動に失敗する状態を再現したかった。

方法

意図的にVM起動直後に fork-bomb を実行するように仕掛けて、起動時にプロセス生成が困難な状況にする1。 毎回の起動直後にfork-bombを実行するようにすると、復旧できなくなるので、仕掛けた後に一回だけfork-bombが起動するようにし、 再び再起動を強制的に行えば復旧できるようにする。 これを次のようにして実現する:

fork-bomb実行前にファイルの存在性をチェックし、ファイルが存在する場合に限りfork-bombを実行する。 実行した場合は、対象のファイルを削除する。

  1. 以下のfork-bombを実行するシェルスクリプトを /var/tmp/reserved-fork-bomb.sh に配置する。 (このシェルスクリプトはfork-bombである。実行すると、大量のプロセスが生成されて制御不能になる恐れがある。壊れてもいいような試験用VMで行うこと。)
    #!/bin/bash
    # reserved_file_path にファイルが存在する場合のみ
    # fork-bombを実行します。
    # reserved_file_path に存在するファイルはfork-bomb実行前に削除されます。
    set -eux
    
    reserved_file_path=$1
    
    if [ ! -e ${reserved_file_path} ]; then
      echo "do nothing."
      exit 0
    fi
    
    rm ${reserved_file_path}
    sync
    
    fork_bomb() {
     fork_bomb | fork_bomb &
    }
    
    fork_bomb
    
  2. 以下のカスタムUnitファイルを /etc/systemd/system/reserved-fork-bomb.service に配置する。 network.targetのまえに起動するようにしているが、環境によっては適切でないかもしれないので、適宜修正する。
    [Unit]
    Description=reserved fork bomb.
    Before=network.target
    
    [Service]
    Type=forking
    ExecStart=/var/tmp/reserved-fork-bomb.sh /var/tmp/reserve-fork-bomb
    
    [Install]
    WantedBy=default.target
  3. シェルスクリプトに実行権限を与える。
    $ chmod u+x /var/tmp/reserved-fork-bomb.sh
    
  4. Unitファイルを追加したのでリロードを行う。
    $ systemctl daemon-reload
    
  5. reserved-fork-bomb サービスを enabled にして、起動時に実行するようにする。
    $ systemctl enable reserved-fork-bomb
    
  6. /var/tmp/reserve-fork-bomb ファイルを作成する。このファイルが存在するときに限り、fork-bombが実行される。
    $ touch /var/tmp/reserve-fork-bomb
  7. 再起動を実行する。これによってVMが再起動され、復帰しない状態となる。
    $ reboot
    

  1. PIDのLimitが設定されている場合は、制限されるので困難な状況にはならない場合がある。

redis-cli config rewriteでpermissionエラーが発生した際も終了ステータスは0で終了する

環境

  • redis 6.0.10
  • redis-cli 6.0.10

問題

redis-cli config rewrite を実行したところ、redis.confが配置されているディレクトリにredisを実行しているユーザの書き込み権限がないために、(error) ERR Rewriting config file: Permission deniedというエラーが発生した。 この場合のコマンドの実行の終了ステータスは0となっていて、そのため、以下のようなAnsibleのタスクは成功してしまった。

- name: Rewrite config file
  command: "redis-cli -a `password` config rewrite"
  changed_when: yes

エラーの趣旨が出力されていても終了ステータスが0になる。これに関連したIssueとしては以下が存在する。 github.com 終了ステータスが0である背景について、以下のコメントがされている。 github.com

redis serverでエラーが発生してもredis cliがエラーというわけではない、 サーバ側のエラーでありCLIのエラーではないため、exit statusは0ということのようだ。

また、例えば、以下のようにredis clusterで他のノードにデータがある場合のエラーについても、終了ステータスは0である。

$ redis-cli  -a 'password' get aaa
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
(error) MOVED 10439 XX.XX.XX.XX:6379
$ echo $?
0

redis-cli を実行する際、人が実行するときは出力される文章でエラーに気が付けるが、Ansibleやshellなどコードとして機械的に実行する際はエラーを表現する出力があっても終了ステータスは0となることがあるようなので扱いに注意が必要である。

解決方法

今回に限っては、ERR が出力に含まれていたらタスクを失敗させるようにすることで検出できる。 ただ、このケース以外でタスクとしては失敗してほしいがERRがつかない場合がないとは言えないので、その場合はこの方法だと検知できない。

- name: Rewrite config file
  command: "redis-cli -a `password` config rewrite"
  register: result
  failed_when: result.rc != 0 or "ERR" in result.stdout

検知したいエラーに対して失敗するように条件を追加するとか、 エラーが発生すること前提で正しく処理ができたかを別の方法で確認するアサーションを追加するなどで対応することが考えられる。 今回の場合だと、対象のredis.confに対して確かに期待する設定が記述されているかをgrepするとか。

追記(2021/09/21)

Redis 6.2で以下のPRが入り、redis-cli-e オプションを指定することでサーバエラー時に終了ステータスをエラーコードで返すようにできるようなったようだ。

github.com

Datadog MySQL サービスチェック mysql.can_connect に関するモニターではno_data_timeframeを1minにすると24hとして扱われる

環境

  • Datadog Agent v6.15.0
  • CentOS 7.3.1611

問題

DatadogのMySQLインテグレーションのサービスチェック mysql.can_connect に関するservice checkモニターを作成し、 ホストダウン時も通知がされて欲しかったため、notify_no_dataを有効かつno_data_timeframeを1minに設定した。

ホストが稼働している場合にmysqldがダウンしたときは即時に通知がされたが、ホストダウンの場合の通知は24h経過した後にあった。 ホストダウンした場合にもno_dataとして通知が即時にされるのを期待していたが、そうはならなかった。

解決策

公式ドキュメント docs.datadoghq.com によると、サービスチェックにおいてno_data_timeframeは2min以上を指定することが推奨されている。 今回の場合だと、1minにしてしまったので24hとして扱われてしまったようである。 2minに設定したところ期待通りにホストダウン時に即時に通知がされるようになった。 設定自体は1minにできてしまい気がつきにくいので、注意が必要である。