Raspberry Pi で 最新の Nginx (1.13) を使う

Raspberry Pi の Raspbian (debian系) で apt-get すると、Nginx は結構古いやつが入る。 やっぱり新しいのが使いたいと思って試したことをまとめる。

今回は結構 experimental なネタなので、at your own risk でお願いします。
初心者向けではないです。

あと、タイトルは Raspberry Pi だけど、一般の Debian / Ubuntu でも使えるネタだと思います。 (未検証ですが)

作業時間は、3B で 2時間くらいか。 片手間で十分だけど、時間を確保してください。 3B以外の機種では。。。結構な忍耐が必要そうです。。。クロスビルドを検討しましょう。

HTTP/2 も使いたいので、TLSのための openssl の新しいバージョンを使う。
システムワイドの openssl をアップデートするのはリスクがあるので、
nginxに内包して、ここだけで使用するように、ビルドする。

今回は、debian の deb のソースリポジトリから取得したソースをビルドするけど、一旦古いやつをaptで入れて `nginx -V` で表示されたオプションを、configure に指定するという方法でも割といける。

準備
なんにもビルドしたことがない環境の人は。。。


sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install git

など。。。

後々、必要に応じて、ビルドに必要なライブラリをインストールする必要があるかもしれない。
ビルド中に `error: libなんとか` や `warning: libなんとか` と出たら、
`sudo apt-get install libなんとか`
とか
`sudo apt-get install libなんとか-dev`
とやってみる(いい加減..)。

ソースの取得


pwd
/home/pi

mkdir nginx-latest
cd nginx-latest
git clone https://anonscm.debian.org/cgit/pkg-nginx/nginx.git

ちなみに、このリポジトリのパスは `apt-get source nginx` したら、
こっちから取りな。と出てきたパス。 `apt-get source nginx` だと、
1.10 あたりが落ちてくる。

ビルドにオリジナルのソースが必要で、かつ、別名で参照されているので


wget https://nginx.org/download/nginx-1.13.3.tar.gz
ln -s nginx-1.13.3.tar.gz nginx_1.13.3.orig.tar.gz

(ハイフンがアンダースコアになっているので注意)

openssl のソースを取得、展開


wget https://www.openssl.org/source/openssl-1.1.0f.tar.gz
tar xzvf openssl-1.1.0f.tar.gz

ビルドオプションの調整


cd nginx
vi debian/rules

configure の オプションを指定する箇所
`common_configure_flags := \ `(の後の72行目くらい)
があるので、そこに


--with-thread \
--with-openssl=/home/pi/nginx-latest/openssl-1.1.0f \
--with-openssl-opt=-fPIC

を追加。 もともとある `–with-thread` の後にバックスラッシュ付加。
お好みで makeに -j3 オプションを追加。

ビルドコマンド


dpkg-buildpackage -us -uc

エラーが出たら、パスを確認したり、最初のライブラリインストールを試す。
`dpkg-buildpackage`を使うと、また最初の clean, configure からになってしまうので、
参照URLにある、ビルドコマンドを活用すると多少時間短縮できる。
無理そうだったら、スパッと諦めて、また、体力のある時にリトライするのもいい。

ビルドが終わったら、


cd debian/nginx-full/usr/sbin
./nginx -v
./nginx -V

でビルドできたか確認する。


nginx version: nginx/1.13.3
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled

(ドットスラッシュ無しの現行nginxとの比較もしてみよう)

設定ファイルなどのバックアップを取って、


cd ~/nginx-latest

sudo dpkg -i libnginx*.deb
sudo dpkg -i nginx-common_1.13.3-1_all.deb
sudo dpkg -i nginx-doc_1.13.3-1_all.deb
sudo dpkg -i nginx-full_1.13.3-1_all.deb

これで完了。

HTTP/2 を試したいときは、SSL(TLS) が必須なので、HTTPS の設定をしよう。
多分、HTTPS の設定をすれば、勝手になる。
Chromeの機能拡張 HTTP/2 and SPDY indicator というのを使うと、HTTP/2 使用時に青い稲妻が出て面白い。

参考URL
https://www.debian.org/doc/manuals/maint-guide/build.ja.html

Surface Book の GPU で Deep Learning

表題の通り、Surface Book (i5モデル) の GPU で Deep Learning を試してみた話。

(2017/08/02 さらに追記)
(2017/07/25 末尾に追記。有効なケースについて)

最近、ふと deep learning について勉強したくなって、ちょっとしたサンプルプログラムを動かしたりしている。 まだ理論をきちんと理解していないので、サンプルを書き換えるのも、ままならない状態だが、何かの役に立てば面白いかなと思っている。

演算には結構時間がかかるが、GPU を使えば高速化できるらしい。
そういえば、Surface にも GPU 入っているのを思い出したので、試してみることにした。

Surface Book の i5/8GB/256GB のモデルには、dGPU という NVIDIA製の無銘GPUが搭載されている。 一応、CUDA も動くみたい。

  • Windows 10
  • Cuda 8.0
  • CuDNN 5.1
  • Tensorflow GPU 1.2.1

どれも普通にインストールしただけ。CuDNNはシステム環境設定のPATHをbinに通しておく。 TensorFlow も公式の手順で pip install しただけ。 インストールして、以下サイトのサンプルを動かしてみると。。。

RNNで来月の航空会社の乗客数を予測する:TFLearnでLSTMからGRUまで実装しよう

なんと、GPU より CPU のほうが早かった。。。
(ひどいオチだ。。。)

なんかね、3000 x 2000 pixel の表示を高速化するために搭載されてはいるが、そういうことには使わないでくださいって感じ。。。

一応認識されたし、動きはしたけど、演算は無理でした。残念。。。

ちなみに、deep learning の参考書はこれ。いい本だと思う。

Surface でこれなので、お得意の Raspberry Pi では。。。インストールする気も起きないです(笑)

(2017/07/25 追記)
サンプルプログラムによっては、速くなるものもあることが分かった。
スピードは倍くらいになる。 GPUのメモリが1GBしかないので、メモリに関する部分でパフォーマンスに差が出るようだ。

とりあえず、GPU版を入れておいて、Windows の場合、システム環境変数で切り替えるのがよさそう。
CUDA_VISIBLE_DEVICES=-1 で無効、CUDA_VISIBLE_DEVICES=0 で有効。

(2017/08/02 追記)
GPUのメモリが少ないので、バッチサイズは小さめにする必要があるが、うまく調整すれば、3~4倍程度のパフォーマンスが出ることを確認。
調整には、nvidia-smi や NvGpuUtilization ツールを使うとやりやすい。

WordPress の Twenty Elevenテーマ に はてなブックマーク のボタンを追加する

前前回のツイッター編と手順はほぼ一緒。

まずは、はてなブックマークのアプリのページに行って、リンクを作ります。
http://b.hatena.ne.jp/guide/bbutton

保存するURL の項目には、なにか分かりやすいダミー文字列を入れておく。
コードをコピーして。 WordPress の [外観] – [テーマの編集] の

content.php ファイルから


</div><!-- .entry-content -->

という、タグを見つけて、その直前にリンクの文字列を入れる。

先ほどの URLを共有のダミー文字列を含む href の部分を


href="http://b.hatena.ne.jp/entry/<?php str_replace('http://', '', str_replace('https://','s/',the_permalink())); ?>"

に置き換えて保存。

今度は、content-single.php ファイルで、再び、先ほどと同じ div の閉じタグを検索し、その直前にリンクの文字列を入れる。
今度は、href の部分を


href="http://b.hatena.ne.jp/entry/"

にして、保存する。

手順は以上です。

Raspberry PiでCI(継続的インテグレーション)

。。。こんなタイトルで書いたけど、実質、ちょっとしたビルドタスクを動かすくらいの話。

仕事として、プログラムを組んでいるわけではないし、ビルド、テスト、デプロイにツールを使うほどの状況ではないのだが、環境構築遊びとして、ビルドツール / CI ツールを検討。

試したたのは、Jenkins と Strider と Rundeck  。。。と Git の hook。

動かしてみると、JenkinsStriderRundeck も Raspberry Pi には重すぎた。。。(結論早いw)
一応、Raspberry Pi 3B だったら、多少の我慢で動くけど、アクションを起こしたときにしか動かないツールに、普段から400~600MBものメモリを使う気にもならず、結局、あきらめた。

Strider が、若干軽いが、ほんの少しの違い。

で、結局、Git の hook を使うことにした。 同期処理になってしまうけど、gogs の常駐以外にメモリも使わないし、元々 gogs が動いていたのだから、追加コストなしで動作というのは大きい。

hookの注意点としては、

  • gogs / Git のユーザで動くので、それでできるように仕掛けておく必要がある。 事前に `sudo su – git` して、一連の操作を手動で実行できるか試すといい。
  • スクリプト中で、Git を使う場合、例えばワーキングディレクトリ内にいったん、clone もしくは pull したりするときは git に --git-dir=.git のように Git ディレクトリの明示指定が必要。
  • 普段ログインするユーザではないので、PATH とか ~/.ssh/id_rsa とかがいつもと違うので注意。

ということくらいか。 スクリプト中でエラーになると、クライアント側の push の際に画面にエラーが出るので、よく見ること。

もし、非同期でやりたかったら、gogs で Webhook を飛ばして、github-webhook-handler を使って、node.js で書いたコードで受けるのが Raspberry Pi らしいかな。ビルドに失敗したら、パトランプ点灯とか(笑)

cron で数分おきに監視する手もあるけど。 しょぼいが。。。

マルチユーザーで重なった時に、キューイングする事とかは、全く考えてません。悪しからず。

ワーキングディレクトリをタイムスタンプ名で作って clone してビルドで結構いけそうだけど、そこまでしたくないねえ。

チャイナパワー

しばらくソフトウェアの仕事から離れていて、ここ数ヶ月の間に、再履修みたいな感じで、オープンソース界隈を眺めていた。 自分の興味の対象とかもあって、偏りはあるけれども、おおむね感じたこととしては。。。

最重要なソフトウェアの、重要なポジションに日本人はいる。頑張ってる。
でも、荒削りでも、新しく、元気なソフトウェアプロジェクトのコミッターには、中国の人のパワーを感じる。

ということ。

国内で人気サイトを運営しているところのエンジニアさんの blog なんかを見ると、頑張っている人も沢山いるのも分かるけど。

もっと、日本人も積極的に出て行かないと、終わるよ。。。
というか、終わりの始まりを見ているのかも。

自分が現役でソフトの業界にいたときは、日本ローカルの SI 活動は、責任のなすりつけあいのために、信頼性はあるけど、たいした機能も無い、化石みたいなソフトウェアをありがたがって使っている傾向があったけど、今でもそうなんでしょうかねえ。