全力で怠けたい

怠けるために全力を尽くしたいブログ。

西暦と和暦を変換する wareki コマンドが Docker コンテナになりました。

はじめに

wareki コマンドDocker コンテナ になりました。

もともと実行ファイル1つだけの構成でしたが、環境を汚したくないときの選択肢の1つとして Docker コンテナにしてみました。 もちろん、今までのように Releases ページからダウンロードしたり go get とか HomeBrew でインストールして使うこともできます。

インストール方法

普通に docker pull でインストールします。 ただ、このあと docker conainer run するときにイメージがローカルにないときは Docker が自動的にイメージを pull してくれるのでやらなくてもいいです。

$ docker pull ebc2in2crc/wareki

使い方

普通に docker container run します。 コマンドの実行が終わったらコンテナを削除するために --rm オプションを付けるとよいと思います。

$ date "+%Y/%m/%d"
2019/05/01

$ docker container run --rm ebc2in2crc/wareki
R1

$ docker container run --rm ebc2in2crc/wareki --kanji
令和1

参考にしたサイト

apk ファイルと ipa ファイルのバージョンを雑に確認するシェルスクリプトを書いた。

apk ファイルと ipa ファイルのバージョンを雑に確認するスクリプトを書いたときのメモ。

やりたいこと

apk ファイルで知りたいのは android:versionNameandroid:versionCode の2つ。 このあたりの情報は aapt コマンドを使って apk ファイルから取得できるので、必要な情報だけを取得と出力するように。

ipa ファイルで知りたいのは CFBundleShortVersionStringCFBundleVersion の2つ。 このあたりの情報は plutil コマンドを使って ipa ファイルから取得できるので、必要な情報だけを取得と出力するように。

書いたスクリプト

こんなシェルスクリプトを書いて packver.sh /path/to/hoge.apk みたいな感じで使っている。

#!/bin/bash

if [ "$1" = "" ]; then
    echo "usage: $(basename $0) package-path"
    exit 1
fi

PACKAGE=$1

if [ "$(echo ${PACKAGE} | grep '.*apk$')" != "" ]; then
    VERSION_NAME=$(aapt l -a ${PACKAGE} | grep android:versionName | sed -E -e 's/^.*Raw: "//' -e 's/".*$//')
    echo "Version: ${VERSION_NAME}"

    VERSION_CODE=$(aapt l -a ${PACKAGE} | grep android:versionCode | sed -E -e 's/^.*)//')
    echo "Version Code: $(printf '%d' ${VERSION_CODE})"
    exit 0
fi

if [ "$(echo ${PACKAGE} | grep '.*ipa')" != "" ]; then
    PLIST=$(unzip -p ${PACKAGE} Payload/*.app/Info.plist | plutil -convert json -o - -- -)
    SHORT_VERSION=$(echo ${PLIST} | jq -r .CFBundleShortVersionString)
    echo "CFBundleShortVersionString: ${SHORT_VERSION}"

    BUNDLE_VERSION=$(echo ${PLIST} | jq -r .CFBundleVersion | sed -E -e 's/^.*\.//')
    echo "CFBundleVersion: ${BUNDLE_VERSION}"
    exit 0
fi

echo "Invalid package: ${PACKAGE}"
exit 1

依存しているツール

シェルスクリプトの中で aapt とか plutil とか使っているので以下のコマンドは事前にインストールしておく。 Android とか iOS 向けの開発をしているなら普通に入っていそうだが。

apk ファイルと ipa ファイルのバージョンを雑に確認するスクリプトを書いたときことは以上。

pixela-client-go が v1.2.0 にバージョンアップしました。

pixela-client-go が v1.2.0 にバージョンアップしました。

github.com

v1.2.0 アップデート内容

Channel API に対応

Pixela v1.13.0 で追加された Channel API に対応しました。 Channel API の説明と使い方に関しては 公式ブログリリースノート にとても詳しく書かれているのでぜひ参照してみてください。

一応、Slack に通知するチャンネルを作成するコードの例は以下のようになります。

client := pixela.NewClient("notify-test", "thisissecret")

detail := &pixela.SlackDetail{
    URL:         "https://hooks.slack.com/services/xxxx",
    UserName:    "slack-user-name",
    ChannelName: "slack-channel-name",
}
result, err := client.Channel().CreateSlackChannel("my-channel", "My slack channel", detail)
if err != nil {
    log.Fatal(err)
}
if result.IsSuccess == false {
    log.Fatal(result.Message)
}

Notification API に対応

Pixela v1.13.0 で追加された Notification API に対応しました。 Channel API の説明と使い方に関しては 公式ブログリリースノート にとても詳しく書かれているのでぜひ参照してみてください。

一応、通知ルールを作成するコードの例は以下のようになります。

client := pixela.NewClient("notify-test", "thisissecret")

result, err := client.Notification("test-graph").Create(
    "my-notify-rule",
    "my notification rule",
    pixela.TargetQuantity,
    pixela.ConditionGreaterThan,
    "3",
    "my-channel",
)
if err != nil {
    log.Fatal(err)
}
if result.IsSuccess == false {
    log.Fatal(result.Message)
}

現場からは以上です。

pixe.la

パーティションがある EBS のボリュームサイズの拡張方法。

EC2 を運用中にパーティションがある EBS ボリュームのサイズが足りなくなったのでボリュームサイズを拡張したときのメモ。

EBS ボリュームサイズの拡張前

まずは状態を確認していく。

lsblk コマンドで状態を確認するとルートボリュームは /dev/xvda があり、/dev/xvda ルートボリュームは /dev/xvda1 パーティションがあることが分かる。また、/dev/xvda ルートボリュームのサイズは 8GB で /dev/xvda1 パーティションのサイズは 8GB であることも分かる。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /

df コマンドでファイルシステムの状態を確認すると /dev/xvda1 パーティションは割り当てている 8GB のうち 7.8GB とほぼすべてを使い切っている状態で、このままだと何をするにも支障があるので EBS のボリュームサイズを拡張していく。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       8.0G  7.8G  200M   98% /
# 省略

EBS ボリュームサイズの拡張方法

パーティションがある EBS ボリュームサイズを拡張するときは、EBS ボリュームサイズ自体の拡張のほかにパーティションの拡張とファイルシステムの拡張が必要になるので、それぞれやっていく。

EBS ボリュームサイズの拡張

まず一番最初に EBS のボリュームサイズを拡張していく。

AWS の EC2 コンソールのサイドバーで ボリューム を押してボリューム一覧を表示して、ボリューム一覧の対象のボリュームを選択して アクション > ボリュームの変更ボリュームの変更 画面を表示する。

ボリュームの変更 画面は変更後のサイズ (ここでは 50GB) を入力して 変更 ボタンを押す。

拡張するサイズによっては拡張が完了するまで時間がかかることがあるので EBS ボリュームの 状態in-use になるまで待つ。

f:id:ebc_2in2crc:20191013160208p:plain

EBS ボリュームの 状態in-use であることを確認したら作業を続けていく。

lsblk コマンドで状態を確認すると /dev/xvda ルートボリュームは新しいサイズ (50 GB) が反映されているが /dev/xvda1 パーティションは元のサイズ (8 GB) のままであることが分かる。 そのため、ファイルシステムを拡張する前にパーティションを拡張していく。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  50G  0 disk
└─xvda1 202:1    0   8G  0 part /

パーティションの拡張

/dev/xvda1 パーティションを拡張するために growpart コマンドを使う。

$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=104853471,end=104857567

lsblk コマンドで状態を確認すると /dev/xvda1 パーティションが 50GB に拡張されていることが分かる。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  50G  0 disk
└─xvda1 202:1    0  50G  0 part /

/dev/xvda1 パーティションのサイズは拡張されたが、df コマンドでファイルシステムの状態を確認するとファイルシステムは 8GB のままなので、続いてファイルシステムを拡張していく。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       8.0G  7.8G  200M   98% /
# 省略

ファイルシステムの拡張

ここまででボリュームサイズの拡張とパーティションサイズの拡張をしてきたので最後にファイルシステムを拡張していく。

ext2ext3ext4 ファイルシステムは resize2fs コマンドを使って拡張していき、XFS ファイルシステムは xfs_growfs コマンドを使って拡張していく。

使っているファイルシステムdf -T コマンドで確認できる。 ここでは タイプ のところが xfs と出力されているので XFS ファイルシステムを使っていることが分かる。

$ df -T
ファイルシス   タイプ   1K-ブロック    使用  使用可 使用% マウント位置
/dev/xvda1     xfs          8376300 1435180 6941120   18% /
# 省略

ファイルシステムが XFS ファイルシステムなので xfs_growfs コマンドを使って拡張していく。

xfs_growfs コマンドがないときは yum install xfsprogs コマンドで XFS ファイルシステム管理ユーティリティをインストールしてから xfs_growfs コマンドを実行する。

$ sudo xfs_growfs /
meta-data=/dev/xvda1             isize=512    agcount=4, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=2096635, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2096635 to 13106683

xfs_growfs コマンドの実行後に df コマンドでファイルシステムの状態を確認するとファイルシステムが 50GB に拡張されていることが分かる。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1        50G  7.8G   42G   16% /
# 省略

パーティションがある EBS のボリュームサイズの拡張方法は以上。

参考ページ

docs.aws.amazon.com

CSV や TSV を SQL ライクに select できる q コマンドが便利すぎた。

CSV や TSV などの表形式のデータを SQL ライクに select できる q コマンド が便利すぎたのでメモしておく。

q コマンドとは

とりあえず公式ドキュメント。

harelba.github.io

公式ドキュメントには以下のように書いてある。

q は SQL ライクな命令を表形式のテキストデータに対して実行することができます。SQL の強力な表現を Linuxコマンドラインで実行できるようにし、より簡単にテキストデータを扱えるようにするために作られました。

ようするに CSV とか TSV みたいなテキストデータを SQL ぽく select できるコマンドなのだが、非常に簡単に使えてしかも驚くほど強力。

インストール

Macbrew を使うと簡単にインストールできる。

$ brew install q

Mac 以外のインストール方法は ここ

使い方

公式ドキュメント が充実しすぎているのでざっと公式ドキュメントに目を通すだけで十分なのだがよく使うオプションなどを備忘録までにメモしておく。

サンプルで使う CSV ファイルはこんな感じ。

$ cat prefectures.csv
都道府県,読み,地方,人口
愛知県,あいちけん,中部,7484094
青森県,あおもりけん,東北,1308649
秋田県,あきたけん,東北,1022839
石川県,いしかわけん,中部,1154343
茨城県,いばらきけん,関東,2917857
岩手県,いわてけん,東北,1279814
愛媛県,えひめけん,四国,1385840
大分県,おおいたけん,九州,1166729
大阪府,おおさかふ,近畿,8838908
岡山県,おかやまけん,中国,1922181

基本的な使い方

入力データはファイル名を from に指定する。

$ q -d, -H 'select * from prefectures.csv'
愛知県,あいちけん,中部,7484094
青森県,あおもりけん,東北,1308649
秋田県,あきたけん,東北,1022839
石川県,いしかわけん,中部,1154343
茨城県,いばらきけん,関東,2917857
岩手県,いわてけん,東北,1279814
愛媛県,えひめけん,四国,1385840
大分県,おおいたけん,九州,1166729
大阪府,おおさかふ,近畿,8838908
岡山県,おかやまけん,中国,1922181

標準入力を入力データにするときは -from に指定する。

$ cat prefectures.csv | q -d, -H 'select * from -'
愛知県,あいちけん,中部,7484094
青森県,あおもりけん,東北,1308649
秋田県,あきたけん,東北,1022839
石川県,いしかわけん,中部,1154343
茨城県,いばらきけん,関東,2917857
岩手県,いわてけん,東北,1279814
愛媛県,えひめけん,四国,1385840
大分県,おおいたけん,九州,1166729
大阪府,おおさかふ,近畿,8838908
岡山県,おかやまけん,中国,1922181

データの区切り文字を指定するときは -d オプションを指定する。 サンプルの prefectures.csvCSV フォーマットなので `-d,' を指定しているが入力データのフォーマットに合わせてタブでもなんでも指定できる。

入力データの1行目がヘッダー行のときは -H オプションを指定する。 -H オプションを指定するとヘッダー行から自動的にカラム名を検出してくれてクエリのなかで使うことができる。

$ q -d, -H 'select 都道府県 from prefectures.csv'
愛知県
青森県
秋田県
石川県
茨城県
岩手県
愛媛県
大分県
大阪府
岡山県

入力データにヘッダー行がなく1行目からデータ行のときは c1, c2, ... というカラム名になる。

$ cat prefectures.csv | sed 1d | q -d, 'select c1 from -'
愛知県
青森県
秋田県
石川県
茨城県
岩手県
愛媛県
大分県
大阪府
岡山県

クエリ

標準的な SQL はだいたい使える。

SQL の文法は SQLite と同じ。

where

$ q -d, -H 'select * from prefectures.csv where 地方="東北"'
青森県,あおもりけん,東北,1308649
秋田県,あきたけん,東北,1022839
岩手県,いわてけん,東北,1279814

order by

$ q -d, -H 'select * from prefectures.csv order by 人口 desc'
大阪府,おおさかふ,近畿,8838908
愛知県,あいちけん,中部,7484094
茨城県,いばらきけん,関東,2917857
岡山県,おかやまけん,中国,1922181
愛媛県,えひめけん,四国,1385840
青森県,あおもりけん,東北,1308649
岩手県,いわてけん,東北,1279814
大分県,おおいたけん,九州,1166729
石川県,いしかわけん,中部,1154343
秋田県,あきたけん,東北,1022839

limit

$ q -d, -H 'select * from prefectures.csv order by 人口 desc limit 3'
大阪府,おおさかふ,近畿,8838908
愛知県,あいちけん,中部,7484094
茨城県,いばらきけん,関東,2917857

group by

$ q -d, -H 'select 地方, count(1) from prefectures.csv group by 地方'
中国,1
中部,2
九州,1
四国,1
東北,3
近畿,1
関東,1

having

$ q -d, -H 'select 地方, count(1) as cnt from prefectures.csv group by 地方 having cnt >= 2'
中部,2
東北,3

関数

関数も普通に使える。

sum

$ q -H -d, 'SELECT sum(人口) from prefectures.csv'
28481254

substr

$ q -H -d, 'SELECT substr(都道府県, 1, 1) from prefectures.csv'
愛
青
秋
石
茨
岩
愛
大
大
岡

その他のよく使うオプション

入力エンコーディングの指定

入力エンコーディングを指定するときは -e オプションを使う。

たとえば入力エンコーディングEUC-JP のときはエラーになってしまうが、

$ iconv -f UTF-8 -t EUC-JP prefectures.csv | q -d, -H 'select * from -'
Could not parse the input. Please make sure to set the proper -w input-wrapping parameter for your input, and that you use the proper input encoding (-e). Error: 'utf8' codec can't decode byte 0xc5 in position 0: invalid continuation byte

-e EUC-JP オプションを指定すると意図したとおりに動く。

$ iconv -f UTF-8 -t EUC-JP prefectures.csv | q -d, -H -e EUC-JP 'select * from -'
愛知県,あいちけん,中部,7484094
青森県,あおもりけん,東北,1308649
秋田県,あきたけん,東北,1022839
石川県,いしかわけん,中部,1154343
茨城県,いばらきけん,関東,2917857
岩手県,いわてけん,東北,1279814
愛媛県,えひめけん,四国,1385840
大分県,おおいたけん,九州,1166729
大阪府,おおさかふ,近畿,8838908
岡山県,おかやまけん,中国,1922181

出力エンコーディングの指定

出力エンコーディングを指定するときは -E オプションを使う。

$ q -H -d, 'select * from prefectures.csv' | nkf -g
UTF-8

$ q -H -d, -E EUC-JP 'SELECT * from prefectures.csv' | nkf -g
EUC-JP

ヘッダー行を出力

デフォルトはヘッダー行は出力されないが -O オプションを指定するとヘッダー行が出力される。

$ q -H -d, -O 'SELECT * from prefectures.csv'
都道府県,読み,地方,人口
愛知県,あいちけん,中部,7484094
青森県,あおもりけん,東北,1308649
秋田県,あきたけん,東北,1022839
石川県,いしかわけん,中部,1154343
茨城県,いばらきけん,関東,2917857
岩手県,いわてけん,東北,1279814
愛媛県,えひめけん,四国,1385840
大分県,おおいたけん,九州,1166729
大阪府,おおさかふ,近畿,8838908
岡山県,おかやまけん,中国,1922181

Vim のキーボードマクロの記録と実行。

Vim のキーボードマクロが便利なのだがあまり使わないのでいざ使うときに「あれ、どうやってたっけ?」となるので Vim のキーボードマクロの基本的な記録、実行と閲覧方法をメモしておく。

キーボードマクロとは

テキストエディターの多くは入力した文字を保存しておいて保存しておいた文字を後から実行する機能があり、一般的にキーボードマクロとかキーボードレコーダーとか呼ばれることが多い。 この機能は Vim にも備わっていて、うまく使うと単調な繰り返し作業などを非常に効率よく処理することができる。

ちなみに Vim の同機能は記録と実行を合わせて complex repeats というようだ。詳しくは help q を参照。

キーボードマクロの記録

ノーマルモードq とタイプして続いてキーボードマクロの記録先のレジスターをタイプする。 キーボードマクロの記録先のレジスターは [0-9a-zA-Z"] から選べるので、たとえばキーボードマクロをレジスタa に記録するなら qa とタイプする。

キーボードマクロの記録が開始するとステータス行に recording @a のように表示されるので、実際の操作をしていく。

記録したい操作が終わったらノーマルモードに戻ってもう一度 q をタイプする。 するとステータス行の recording @a が消えてキーボードマクロの記録が終了したことが分かる。

キーボードマクロの実行

ノーマルモード@ とタイプして続けて実行したいキーボードマクロの記録先のレジスターをタイプする。 たとえばレジスタa に記録しておいたキーボードマクロを実行するときは @a とタイプする。 @ は他のコマンドと同じように実行回数を指定できるので、たとえば 10@a のようにタイプするとレジスタa に記録しておいたキーボードマクロを10回実行することができる。

キーボードマクロの閲覧

ノーマルモードreg とタイプするとレジスターに記録されているキーボードマクロが閲覧できる。

キーボードマクロの例

4の倍数のときだけアホになるキーボードマクロ。 数値が1行ごとに書かれているので qa でキーボードマクロの記録を開始して 4j0cwstupid!<esc> をタイプして q で記録を終了して、 10@a で記録しておいたキーボードマクロを実行している。

それぞれのコマンドは以下を参照。

  • 4j: カーソルを4行下に移動
  • 0: カーソルを行頭に移動
  • cw: 単語を削除してインサートモードを開始
  • stupid!: インサートモードで単純にタイプ
  • <esc>: ESC キーをタイプの意味。インサートモードを終了してノーマルモードへ戻る。

f:id:ebc_2in2crc:20190915221043g:plain

AWS で障害が発生したときにチェックしているページをまとめてみた。

はじめに

先週は AWS の東京リージョンで大規模な障害が発生した。

piyolog.hatenadiary.jp

AWS に関わるようになって初めて体験した AWS の大規模な障害だったのだが、オンプレミスのシステムが障害を起こしたときと同じように AWS というかクラウドで障害が発生したときも情報収集が非常に重要になる。

たとえば、障害が発生した AZ のリソースを止めて別の AZ にリソースを立ててトラフィックを新しく立てたリソースに回して業務継続する……などの対応は障害の原因と影響範囲が分からないとできないし、クラウド上で動いているシステムがお客様のもので自分たちがその運用会社であるなら、状況をお客様へ報告をするためにも障害の原因と影響範囲は分かっていなければならない。

AWS で障害が発生したときにチェックしているページ

前フリが長くなったが先週 AWS の障害が発生したときにチェックしていたページをまとめておく。

AWS Personal Health Dashboard

AWS Personal Health Dashboard は情報が見やすいし探しやすいのがよい。

ただ、先週 AWS の東京リージョンで発生した障害では AWS コンソールを表示できなくなることがしばしばあったので、AWS Personal Health Dashboard 以外のページもチェックしておくほうがよさそうだった。

AWS Service Health Dashboard

AWS Service Health DashboardAWS の全サービスのステータスを見ることができる。

自分が関係しそうなリージョンは東京リージョンくらいなので Asia Pacific のタブだけを見ていたが、Asia Pacific という名前のとおり東京リージョン以外にも香港リージョンとかソウルリージョンなどのサービスステータスが一緒に掲載されている。東京リージョンにしか関心がない自分にはやや冗長さは感じたがページの性格上仕方なさそう。

Twitter

AWS 公式以外からの情報収集手段としては Twitter. It's what's happening. をチェックしていた。

先週の東京リージョンの障害は AWS 公式の発表は「単一の AZ で発生」ということだったが「単一の AZ ってどこなの?」というのが分からなかったのだが、Twitter で「AZ ID が apne1-az4 の AZ で障害が発生してる (らしい)」という情報を得られたので「あ、自分のところも影響ありそう」ということが分かったのは大きかった。

あと、インフラ業務を担当している人との謎の連帯感を感じられるので Twitter はチェックしておいたほうがいいと思う。

AWS Service Health Dashboard] の RSS フィードを Slack に追加

AWS Service Health DashboardRSS フィードを Slack に追加すると AWS のステータスが更新されたときに Slack のチャンネルに post してくれるようになる。

AWS Service Health Dashboard をチェックするのは pull 型の情報収集手段だがこの方法は push 型の情報収集手段になる。 障害発生中といえどダッシュボードに張り付くわけにもいかないことが多いと思うので push 型の情報収集手段はかなり便利。

さいごに

障害は起きないに越したことはないがそんなことはありえないし、最低限これくらいはチェックしておいたほうがよさそうなページをまとめてみた。