PythonのClickのサブコマンドをsymlinkで表現する作例

PythonClick

command [--debug] foo [--force] [--yes]

なのを実装したとして、これと同じのを command-foo というsymbolic linkを作って

command-foo [--debug] [--force] [--yes]

でも実行できるようにしたい作例。

command-foo --force --debug と実行するとエラーになるのがイマイチ。。。
他にいい方法があったら教えてください!!

REST API フレームワーク Connexion のススメとその作例

Python の Connexion というフレームワークとそのサンプルアプリケーションを書いたのでその紹介です。


Connexion は「API (spec) First」を謳うフレームワークです。

API First」とは、 ご存じ The Twelve-Factor App の追補として 2016 年に Pivotal 社が提唱したガイドライン Beyond the Twelve-Factor App の中のひとつです。

簡単にいうと、コードを書き始める前にまずAPIの仕様を定める。たとえば昨今のマルチデバイス対応のような複数チームで開発を進めるような現場で、お互いこのAPI仕様を拠り所とすることで、他方の開発プロセスに干渉することなく、円滑に開発を進めることができる、というものです。 (たぶん)

Connexion はこの API First を実践するのを助けてくれるプロダクトで、OpenAPI (過去に Swagger spec と呼ばれていたものです)で記述した仕様を軸として次のことが実現できます。

  • API 利用者向けのドキュメントを生成できる
  • 仕様に記述した入力パラメータの validation ルール(必須パラメータのあり/なしとか、正規表現で記述した値の形式チェックとか)を自動で実施してくれるので、適用コードを一切書く必要がない

現職で API サーバーを 3 つ実装して、今は Connexion で 4 つめを実装しているのですが、ドキュメントと実装の乖離は頭の痛い問題でした。具体的にいうと、値の形式チェックのルールをちょっと変えたんだけどドキュメントに反映しわすれていたとか、初期に書いたドキュメントの一部が実装から漏れていたとか、みなさんも容易に想像できるんじゃないでしょうか。

また、エンドポイントの情報(HTTPのメソッドとパス)をドキュメントと controller を呼ぶ router の両方に書かないといけないのが常々無駄だと思っていたのですが、Connexion が仕様を読んで所定の controller のメソッドを呼んでくれるので router を記述する必要がなくなったのもよい点の1つです。

Connexion を使うことでこういった問題から解放されたので本当に助かっています。

ほかにも API の動作をちょっと試したりデモするのに便利な Web UI のダッシュボードがついていたり、OAuth 2 のトークンベースの認証に対応していたりといろいろと特徴があるので詳しくは Connexion のサイトをみてみてください。


そんなこんなでここしばらく Connexion の試し書きをしていました。

などのサンプル実装を大いに参考にさせてもらったのですが、もうちょっと実践的な作例を書いてみました。

  • データストアは RDBMS で、 SQLAlchemy ORM の declarative mapping を使用
  • Connexion (の内部の Flask )との連携は Flask-Alchemy を使用
  • ORM のシリアライズ(dict化)には sqlathanor を使用
  • サンプルとして 2 つのテーブル(リソース)を定義して、one-to-many のリレーション
  • 検索条件の処理は、所定の SQL っぽい記法(JSON)でリクエストをすると、いい感じに SQLAlchemy の query オブジェクトを返してくれる簡易 query builder を書いた
  • pytest と WebTest を使ってテストも用意した

まだまだ Python は B- ぐらいウデマエの上に SQLAlchemy なども使ったことがなかったので、「こう書いたほうがいいでし!」とかあったらぜひ プルリ お待ちしています!

たくさんのホストにpingするのに便利なツールpingerを書きました

たくさんのホストにpingするのに便利なツールpingerをgoで書きました。

こちらから Linux, macOS, Windows 用のバイナリがダウンロードできるので是非お試しください。(手元に環境がないのでWindowsでは動作確認していません)

メンテナンス時、特にネットワーク関連のメンテには、多数のホストへの到達性をモニタリングしがら作業したいことがあると思いますが、(自分が知ってる限りの)既存のツールでは一覧性がよいものがなかったのがこのpingerを書いた動機です。

pingerを実行すると、このように上部には指定したホストの状況を2カラムで表示し、下部に失敗したホストの履歴を表示するので、現在の状況(上部)と過去の状況(下部)を同時に把握できるのが便利ポイントです。




ping対象のホストはpingerの引数にホスト名かIPアドレスで指定してください。思うがままにたくさん指定してください。

pingerの実行にはroot権限が必要なので、いずれかの方法で実行してください。

  • sudo pingerで実行する
  • rootで実行する
  • root で chown root pinger; chmod 4755 pinger しておいてから実行する
  • Linuxの場合、root で setcap cap_net_raw=ep pinger しておいてから実行する (azs! id:mapk0y

ESCかC-cをタイプすると終了します。

終了すると画面がクリアされてしまいます。pingに失敗した履歴を保存しておきたい場合は、標準エラー出力をファイルにリダイレクトしてください。

$ sudo pinger example.com example.net 192.0.2.1 192.0.2.2 192.0.2.3 2> pinger.log

ホスト名(IPアドレス)の横に2つの数値が表示されますが、左のはRTT、右の括弧内のは最大10個の直近の結果の平均RTTで、どちらも単位は ms です。


それではよいpingライフを!

hardware clockがずれる件と 11 minute mode

localtimeにしていたhardware clockをなんとなくUTCにしてみたら10分ぐらいで元に戻っちゃうというお話です。環境は Ubuntu 16.04 です。

結局、reboot しないとダメだったんですが、いい方法あったら教えてください><



hardware clockがlocaltimeになっているかUTCになっているかは、timedatectl の "RTC time" や "RTC in local TZ" のところを見るか、

### UTCの場合
$ sudo timedatectl
      Local time: Wed 2016-12-14 19:19:46 JST
  Universal time: Wed 2016-12-14 10:19:46 UTC
        RTC time: Wed 2016-12-14 10:19:46 # ココ
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no # ココ
      DST active: n/a

### localtimeの場合
$ sudo timedatectl
      Local time: Wed 2016-12-14 19:34:20 JST
  Universal time: Wed 2016-12-14 10:34:20 UTC
        RTC time: Wed 2016-12-14 19:34:20 # ココ
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: yes # ココ
      DST active: n/a

Warning: The RTC is configured to maintain time in the local time zone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

hwclock --show --debug でも確認できます。

### UTCの場合
$ sudo hwclock --show --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1478666918 seconds after 1969
Last calibration done at 1478666918 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time. # ココ
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/12/14 10:36:58
Hw clock time : 2016/12/14 10:36:58 = 1481711818 seconds since 1969
Wed Dec 14 19:36:58 2016  -0.074581 seconds

### localtimeの場合
$ sudo hwclock --show --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1481708948 seconds after 1969
Last calibration done at 1481708948 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time. # ココ
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/12/14 19:37:03
Hw clock time : 2016/12/14 19:37:03 = 1481711823 seconds since 1969
Wed Dec 14 19:37:03 2016  -0.031894 seconds


hwclock --systohc --utc や timtdatectl set-local-rtc 0 で hardware clock を localtime から UTC に変更できるのですが、10分ぐらいするとなぜか元に戻っちゃいました。

これは hwclock(8) に依れば "11 minute mode" という、system clockがずれていないと信頼できるような環境で有益な、11分ごとにhardware clockをsystem clockの時刻に合わせるモードが原因でした。

"11 minute mode" が有効になっているかどうかは、ntptime の実行結果の status 行を見れば確認できます。ここにUNSYNCがなければ有効、あれば無効です。

### "11 minute mode" が有効になっている(=UNSYNCがない)
$ ntptime | grep status
  status 0x2001 (PLL,NANO),

### "11 minute mode" が無効になっている(=UNSYNCがある)
$ ntptime | grep status
  status 0x41 (PLL,UNSYNC),

もしくは adjtimex --print の実行結果の status の数値の 64 ビット目が0(STA_UNSYNC)ならば "11 minute mode" が有効になっていることを示します。


hwclock(8) にも書いてありますが、手元の環境でも ntpd を起動すると "11 minute mode" が有効になりました。(落とすと無効になる)


というわけで、ntpd を起動すると "11 minute mode" が有効になり kernel(?) が認識しているタイムゾーンと異なるのか、10分ぐらいすると hardware clock の時刻がずれてしまいました。

いろいろ

  • /etc/adjtime を消して hwclock --systohc --utc
  • timtdatectl set-local-rtc 0

やってみたんですが、解消できず、結局は ntpd を落として hardware clock を UTC にして reboot したら直りました。(起動後に ntpd を起動してももうずれない)

MySQL 5.7のmysqld --initializeと鶏卵問題

MySQLのデータディレクトリの初期化にはこれまで mysql_install_db が使われてきましたが、MySQL 5.7からは mysqld --initialize を使うことが推奨されています。

mysqld --initialize は datadir 配下にファイルやサブディレクトリがあるとエラー終了します。

# mysqld --initialize --user=mysql
2016-10-04T11:39:01.313174Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2016-10-04T11:39:01.313222Z 0 [ERROR] Aborting

なので datadir をスッカラカンにして再度実行してみます。my.cnf はこんな内容で、datadir の下に tmpdir、InnoDBのデータとログのディレクトリがある構成です。

datadir  = /data/mysql
tmpdir   = /data/mysql/tmp
innodb_data_home_dir            = ibdata
innodb_log_group_home_dir       = iblog
# rm -fr /data/mysql/*
# mysqld --initialize --user=mysql
# echo $?
1
# cat /data/mysql/mysqld.err
mysqld: Can't create/write to file '/data/mysql/tmp/ibSY07SU' (Errcode: 2 - No such file or directory)
2016-10-04T11:41:18.876953Z 0 [ERROR] InnoDB: Unable to create temporary file; errno: 2
2016-10-04T11:41:18.876965Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2016-10-04T11:41:18.876971Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2016-10-04T11:41:18.876975Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2016-10-04T11:41:18.876980Z 0 [ERROR] Failed to initialize plugins.
2016-10-04T11:41:18.876983Z 0 [ERROR] Aborting

/data/mysql/tmp が存在しないので /data/mysql/tmp/ibSY07SU が作れずエラー終了しています。

InnoDBのデータ、ログディレクトリについても同様で、自動ではサブディレクトリを作ってくれません。

[ERROR] InnoDB: Operating system error number 2 in a file operation.
[ERROR] InnoDB: The error means the system cannot find the path specified.
[ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.
[ERROR] InnoDB: File ibdata/ibdata1: 'create' returned OS error 71. Cannot continue operation
[ERROR] InnoDB: Cannot continue operation.
[ERROR] InnoDB: Operating system error number 2 in a file operation.
[ERROR] InnoDB: The error means the system cannot find the path specified.
[ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.
[ERROR] InnoDB: File iblog/ib_logfile101: 'create' returned OS error 71.
[ERROR] InnoDB: Cannot create iblog/ib_logfile101
[ERROR] InnoDB: InnoDB Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again.
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Failed to initialize plugins.
[ERROR] Aborting


というわけで、初期化にはサブディレクトリが必要なわけですが、サブディレクトリがあると mysqld --initialize はエラー終了します。

_人人人人人人人人人人人人人人人人人人_
> どうすりゃいいねん!!!!!!! <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄



途方に暮れそうになりましたが、ドキュメントにちゃんと書いてありました。

As of MySQL 5.7.11, an existing data directory is permitted to be nonempty if every entry either has a name that begins with a period (.) or is named using an --ignore-db-dir option.

https://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html

というわけで、予め必要なサブディレクトリを作っておいて、必要なだけ --ignore-db-dir で繰り返しそれを指定すればOKです。

# rm -fr /data/mysql/*
# install -d -o mysql -g mysql -m 750 /data/mysql/{tmp,ibdata,iblog}
# mysqld --initialize  --user=mysql --ignore-db-dir=tmp --ignore-db-dir=ibdata --ignore-db-dir=iblog
# echo $?
0

LXD 2.0でlive migrationしてみる

基本的には

に書いてある通りなんで、これの補足という形になります。


まず、live migrationを行う(ホストh1にあるコンテナc1をホストh2にlive migrationする場合)のにこのようなコマンドを実行すると

hirose31@h1$ lxc move c1 h2:

「error: Error transferring container data: websocket: bad handshake」というエラーで失敗し、以下のようにlocalの場合でもremote名を添えて実行すれば成功しました。

hirose31@h1$ lxc move h1:c1 h2:

従って、予め自ホストの分もremoteの登録が必要でした。

hirose31@h1$ lxc remote add h1 192.168.33.21
hirose31@h1$ lxc remote add h2 192.168.33.22

hirose31@h2$ lxc remote add h1 192.168.33.21
hirose31@h2$ lxc remote add h2 192.168.33.22

次にハマったのは、lxc moveするとこのようなエラーで失敗した点です。

hirose31@h1$ lxc move h1:c1 h2:
error: Error transferring container data: checkpoint failed:
(00.093894) Error (sockets.c:129): Diag module missing (-2)
(00.173958) Error (sockets.c:339): Sockets (family 16, proto 0) are not collected
(00.173977) Error (cr-dump.c:1303): Dump files (pid: 8476) failed with -1
(00.178203) Error (cr-dump.c:1600): Dumping FAILED.

エラーメッセージを見て、てっきりエラーの原因を表示するためのGo(LXDのlxcコマンドはGoで書かれています)のソケット関連のdiagnostic(診断)ライブラリが足りてないのかな?と思い、いろいろ調べたのですが、結局原因はGoは関係なく、netlink_diag.koというkernel moduleがなかったためでした。思い込みはよくないですね!

Ubuntu 16.04ではnetlink_diag.koは別パッケージに収録されているのでそれをインストールします。

sudo apt-get install linux-image-extra-$(uname -r)

これでlive migrationが成功しました!

ちなみにですけど、netlink_diag.koがないとstateful stop/start やstateful snapshotsも失敗します。


他に気をつける点は、ググるとひっかかる古い情報ではprofileを変更してたりしますが、デフォルトのdefault profileだけで動きました。むしろ、下手にいじると動かない場合がありました。

LXDの感想

システムコンテナとしてDockerを使い、CentOS 6とUbuntu 14.04を動かそうとしたときはいろいろハマった(gettyがCPU食いつぶすとかudevadm settleでbootが止まるとかとか)んですが、LXDでは images.linuxcontainers.org のイメージを使った限りではすんなりCentOS 6やUbuntu 16.04が動かせていまのところはだいぶ好印象です。

LXDはOpenStackとの連携もできるようですし、より軽量なKVMの代替としてよい選択肢になるんじゃないかと思います。

追記 2017-02-10

live migration元と先とでlxdのバージョンが違うと(例えば2.0.5と2.0.8)このようなエラーで失敗する。

move: error: Bad key: volatile.idmap.base

バージョンを揃えれば成功する。apt-get install lxd でコンテナは稼働したままバージョンを上げられた。