uWSGI on OpenWrt

以下の内容は OpenWrt 19.x の時点でのやや古いものであり当面の間は残しておくが、最近の 23.05 に基いた新しい文書を別途作成したので、通常は新しい方を参照して欲しい。

OpenWrt ルーターに Django を導入したいと思ったので、それにあたってはその下準備として、アプリケーションサーバーを整えておく必要がある。Python 系のアプリケーションサーバーとしては uWSGI が定番のようなので、まずここでは uWSGI 環境の構築について一通り行いたいと思う。

luci-ssl-nginx

OpenWrt では luci-ssl-nginx というパッケージがあり、これを導入するとデフォルトの uHTTPd 環境の LuCI に代えて、NGINX（かつ SSL）環境の LuCI が動くようになる。この環境において、Lua プログラムである LuCI に NGINX が CGI としてリレーするために、uWSGI が使われている。この場合は、uWSGI はあくまでも CGI を扱うためのアプリケーションサーバーの一種として使われているだけで、Python 固有の WSGI サーバーとして使われているわけではないが、それでも NGINX ⇔ uWSGI 間のプロトコルは uwsgi プロトコルが使われている点は特筆すべき点だろう（NGINX は uwsgi プロトコルにネイティブ対応している）。

NGINX が uwsgi プロトコルを使うということは、設定ファイル中で uwsgi_* プレフィックスを使った設定が行え、uwsgi_pass でソケットを通じて uWSGI にリレーできることを意味している。

例えば、OpenWrt の luci-ssl-nginx を入れた状態では uWSGI 関連の設定は次のようになっている。

/etc/nginx/luci_uwsgi.conf（/etc/nginx/nginx.conf からインクルードされている）

location /cgi-bin/luci {
  index  index.html;
  include uwsgi_params;
  uwsgi_param SERVER_ADDR $server_addr;
  uwsgi_modifier1 9;
  uwsgi_pass unix:////var/run/luci-webui.socket;
}
location ~ /cgi-bin/cgi-(backup|download|upload|exec) {
  include uwsgi_params;
  uwsgi_param SERVER_ADDR $server_addr;
  uwsgi_modifier1 9;
  uwsgi_pass unix:////var/run/luci-cgi_io.socket;
}

location /luci-static {
}

location /ubus {
        ubus_interpreter;
        ubus_socket_path /var/run/ubus.sock;
        ubus_parallel_req 2;
}

uWSGI と関係しているのは、/cgi-bin/luci と /cgi-bin/cgi-(backup|download|upload|exec) のブロック。いずれも uwsgi_pass で UNIX ソケットに繋いでいる。uwsgi_modifier1 を 9 にしているということは、これはプロトコル的に CGI モードである（👉 The uwsgi Protocol）。NGINX と uWSGI は本来、uwsgi プロトコルで直結できるのだが、現状の OpenWrt ではこのように汎用的な CGI としての設定にしてあるようである（👉 OpenWrt 公式ガイド）。

LuCI on nginx is currently supported by using uwsgi as plain-cgi interpreter.

以下、uWSGI 側の設定について見てみる。

/etc/uwsgi/emperor.ini

[uwsgi]
strict = true
pidfile = /var/run/uwsgi.pid
emperor = /etc/uwsgi/vassals/*.ini
early-emperor = true
vacuum = true
emperor-on-demand-directory = /var/run/
emperor-required-heartbeat = 99
vassal-set = die-on-idle=true

uWSGI は emperor.ini が子プロセスの起動などを行っているようだが、具体的な個別の設定はこの emperor.ini にインクルードされている vassals/*.ini にある。LuCI の WebUI 用の .ini と、LuCI が呼び出す入出力用の CGI のための .ini の 2 種が定義されている。

/etc/uwsgi/vassals/luci-webui.ini

[uwsgi]
strict = true
if-not-env = UWSGI_EMPEROR_FD
socket = /var/run/luci-webui.socket
chmod-socket = 666
cheap = true
end-if =
plugin = cgi
cgi-mode = true
cgi = /www/
chdir = /usr/lib/lua/luci/
buffer-size = 10000
reload-mercy = 8
max-requests = 2000
limit-as = 200
reload-on-as = 256
reload-on-rss = 192
enable-threads = true
post-buffering = 8192
socket-timeout = 120
thunder-lock = true
plugin = syslog
logger = luci syslog:uwsgi-luci
log-route = luci luci:
disable-logging = true
req-logger = syslog:uwsgi-luci
log-format=%(method) %(uri) => return %(status) (%(rsize) bytes in %(msecs) ms)
threads = 3
processes = 3
cheaper-algo = spare
cheaper = 1
cheaper-initial = 1
cheaper-step = 1
master = true
idle = 360
/etc/uwsgi/vassals/luci-cgi_io.ini

[uwsgi]
strict = true
if-not-env = UWSGI_EMPEROR_FD
socket = /var/run/luci-cgi_io.socket
chmod-socket = 666
cheap = true
end-if =
plugin = cgi
cgi-mode = true
cgi = /www/
chdir = /usr/lib/lua/luci/
buffer-size = 10000
reload-mercy = 8
max-requests = 2000
limit-as = 200
reload-on-as = 256
reload-on-rss = 192
no-orphans = true
post-buffering = 8192
socket-timeout = 120
thunder-lock = true
plugin = syslog
disable-logging = true
req-logger = syslog:uwsgi-luci-cgi_io
log-format=%(method) %(uri) => return %(status) (%(rsize) bytes in %(msecs) ms)
chmod-socket = 666
cgi-safe = /usr/libexec/cgi-io
cgi-dontresolve = true
cgi-close-stdin-on-eof = true
cheap = true
idle = 360

ログファイルの設定など色々と細かい設定が並んでいるが、特記すべきなのは、socket を定義している点と、plugin として cgi を使い、その cgi のルートパスを設定している点だろう。socket は NGINX 側のものと対応しているのがわかるし、NGINX 側でも CGI プロトコルに設定してあるのだから、uWSGI 側でも CGI モードで設定するのは当然である。

Python プログラムを CGI として動かす

バッファーサイズ等の細かい調整は無視して、とりあえず CGI としてなら次のような設定で Python プログラムを動かすことができる。

/etc/uwsgi/vassals/cgi.ini

[uwsgi]
socket = /var/run/wsgi.socket
plugin = cgi
cgi = /mnt/data/www/default

そして NGINX 側でも、この socket に対して CGI プロトコルで接続する設定を適当な場所に追加する。

/etc/nginx/nginx.conf（抜粋）

    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        server_name  localhost;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:DHE+AESGCM:DHE:!RSA!aNULL:!eNULL:!LOW:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!SEED";
        ssl_session_tickets off;

        ssl_certificate /etc/nginx/nginx.cer;
        ssl_certificate_key /etc/nginx/nginx.key;

        location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
            expires 365d;
        }

        include luci_uwsgi.conf;
+
+       location ~* \.py$ {
+            include uwsgi_params;
+            uwsgi_param SERVER_ADDR $server_addr;
+            uwsgi_modifier1 9;
+            uwsgi_pass unix:/var/run/wsgi.socket;
+       }

        root /mnt/data/www/default;
    }

Python プログラムを WSGI として動かす

結構正解に辿り着くまで苦労したのが、Python プログラムを CGI としてではなく、本来の WSGI として動かす設定についてである。

正解に辿り着いてしまえば、それほどのことでもないのだが、ポイントは、NGINX 側ではちゃんとプロトコルを uwsgi にすること（デフォルトなので uwsgi_modifier1 を記述しなければ 0 になるのだが、当初 LuCI 用の .ini の設定をコピーしたため、9 に指定のまま CGI プロトコルになってしまっていたために却ってうまく動かなかった）、wsgi.ini 側で plugin に python を指定することである。そうすれば、wsgi-file で指定した Python プログラムが実行される（下の例では wsgi-file ではなくより複雑な mount 設定を使っている）。

とりあえず、最終的に動くようになった例が以下：


opkg install uwsgi-python3-plugin

まずは uWSGI の Python プラグインをインストールしておく必要がある。

/etc/nginx/nginx.conf（抜粋）

    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        server_name  localhost;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:DHE+AESGCM:DHE:!RSA!aNULL:!eNULL:!LOW:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!SEED";
        ssl_session_tickets off;

        ssl_certificate /etc/nginx/nginx.cer;
        ssl_certificate_key /etc/nginx/nginx.key;

        location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
            expires 365d;
        }

        include luci_uwsgi.conf;
+
+       location ~* \.py$ {
+            include uwsgi_params;
+            uwsgi_param SERVER_ADDR $server_addr;
+            #uwsgi_modifier1 0; # wsgi: 0; psgi: 5; cgi: 9
+            uwsgi_pass unix:/var/run/wsgi.socket;
+       }

        root /mnt/data/www/default;
    }
/etc/uwsgi/vassals/wsgi.ini

[uwsgi]
#protocol = http
plugin = python
socket = /var/run/wsgi.socket
chdir = /mnt/data/www/default
mount = /env.py=env.py
#stats = 192.168.10.1:9191
/mnt/data/www/default/env.py

def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/plain')])
    query_string = env['QUERY_STRING']
    request_method = env['REQUEST_METHOD']
    content_type = env['CONTENT_TYPE']
    content_length = env['CONTENT_LENGTH']
    request_uri = env['REQUEST_URI']
    document_path = env['PATH_INFO']
    document_root = env['DOCUMENT_ROOT']
    server_protocol = env['SERVER_PROTOCOL']
    request_scheme = env['REQUEST_SCHEME']
    https = env['HTTPS']
    remote_addr = env['REMOTE_ADDR']
    remote_port= env['REMOTE_PORT']
    server_addr = env['SERVER_ADDR']
    server_port = env['SERVER_PORT']
    server_name = env['SERVER_NAME']
    content = f'''\
QUERY_STRING:\t{query_string}
REQUEST_METHOD:\t{request_method}
CONTENT_TYPE:\t{content_type}
CONTENT_LENGTH:\t{content_length}

REQUEST_URI:\t{request_uri}
PATH_INFO:\t{document_path}
DOCUMENT_ROOT:\t{document_root}
SERVER_PROTOCOL:\t{server_protocol}
REQUEST_SCHEME:\t{request_scheme}
HTTPS:\t{https}

REMOTE_ADDR:\t{remote_addr}
REMOTE_PORT:\t{remote_port}
SERVER_ADDR:\t{server_addr}
SERVER_PORT:\t{server_port}
SERVER_NAME:\t{server_name}
'''
    return [content.encode()]
https://（IP）/env.py にブラウザでアクセスした結果
QUERY_STRING:   
REQUEST_METHOD: GET
CONTENT_TYPE:   
CONTENT_LENGTH: 

REQUEST_URI:    /env.py
PATH_INFO:  /env.py
DOCUMENT_ROOT:  /mnt/data/www/default
SERVER_PROTOCOL:    HTTP/1.1
REQUEST_SCHEME: https
HTTPS:  on

REMOTE_ADDR:    192.168.10.109
REMOTE_PORT:    53328
SERVER_ADDR:    192.168.10.1
SERVER_PORT:    443
SERVER_NAME:    localhost

最後に

最初のうち、理解しにくくややこしいく感じたのが、サーバー（デーモンプログラム）同士である、uWSGI と NGINX の間は、uwsgi プロトコルで接続されていて、それは socket 設定行によって示されている（Web サーバー側が uwsgi プロトコル非対応の場合は socket 設定ではなく http-socket 設定になるだろうし、Web サーバーを別途置かずに uWSGI に Web サーバーも兼用させる場合は http 設定になる）という話と、Python プログラムと uWSGI の間は WSGI で接続する場合と従来の CGI で接続するという場合があるという話が、ごっちゃになっていた点かもしれない。

uWSGI に http プロトコルをしゃべらせれば、NGINX は不要なのだが、なぜあまりそういう使い方をしないのかという点も、すぐに納得行かず、一日モヤモヤしていた。だが、mount 設定でイチイチ REQUEST_URI と実際のパスの対応付けを予め列挙しておかなければならないのを見てもわかるように、uWSGI は本来、あまり静的コンテンツ処理向きのものではない。なので基本的には静的コンテンツは NGINX で捌きつつ、動的コンテンツのみピンポイントで uWSGI にリレーするという運用方法が標準的に想定されたものなのだろうと思う。

まあともかく、Django を導入するにあたっての下準備としての uWSGI いじりはこのくらいまでやっておけば十分だと思うので、ここまでで一応終わりにすることにする。

コメント

コメントを投稿

このブログの人気の投稿

OpenWrt での Wi-Fi 設定

イメージ
OpenWrt をインストールしたら、まず最初に手を付ける作業が Wi-Fi（Network > Wireless で該当デバイスの設定を Edit）。初期状態では Wi-Fi が無効化されているため、Wi-Fi を有効化しておかないと、有線 LAN で直結していないノート PC（Macbook）から作業できない、というのが個人的には決定的な理由。 設定自体は特に難しくはなく、大まかには 2.4G 帯と 5G 帯それぞれについて、暗号化キーを決め、SSID や周波数チャンネル、出力強度をカスタムしたりする程度。最後に Enable して Save & Apply する流れとなる。 以下では、最初に、作業用の古いノート PC（Linux）から有線 LAN でルーターに接続して設定を行い、5G 帯をアクセスポイント・モードで有効化し、Wi-Fi 経由で MacBook が接続できるようにしてから、（Linux マシンと LAN ケーブルを片付けて）残りの作業を行っている。 5G 帯のアクセスポイント設定 WZR-HP-AG300H の場合では radio1 が 5G 帯（802.11an）となっているので、この Wireless 設定を Edit する。 Device 設定（Advanced Settings） 上半分の Device 設定についてはまず Advanced Settings タブの国設定で「JP - Japan」を選ぶ。 Interface 設定（基本設定） 下半分の Interface 設定については上のスクリーンショットのように Mode を「Access Point」、ESSID を適当に設定する（ここでは「OpenWrt」としている）。 Device 設定（基本設定） 国設定を選んだので、基本設定のタブに戻る（下のスクリーンショット）。 チャンネルは auto にすると、PC（受信端末）側のアクセス可能範囲外のチャンネルが選ばれてしまう場合があるので、確実に接続できるであろうチャンネルを手動で選んでおいた方が無難だろう。出力パワーは最強にしておいた。帯域幅はデフォルトの 20 MHz 幅のまま（40 MHz にすると倍化するが、その分、他の Wi-Fi との干渉もし易くなるため）。 ...
続きを読む

シークエンスパパとも 本物の霊能力

イメージ
Ms Sarah Welch / CC-BY-SA-3.0 シークエンスはやともを知ったきっかけ TV を見ない僕がシークエンスはやとも（YouTuber。吉本興業所属）の存在を知ったのは、今年の春（3 月か 4 月）の頃だったと思うが、YouTube でふと宜保愛子の動画を探していて、彼が宜保愛子を称賛するものを見つけて以来だったと思う。 それ以来いくつかの彼の動画をちょくちょく観るようになって、彼の霊能力が父親（シークエンスパパとも）譲りであり、パパともも息子のはやともに勧められて（癌闘病の傍ら）YouTuber として活躍していたのだが、残念ながら今年 1 月末に逝去していた、ということなどを知るようになった。 シークエンスパパともを知ったきっかけ はやとも流れでパパともの動画を観るきっかけになったのは、画面脇のお勧めに出ていた親子対談の動画を見たのが切っ掛けだった。 そこでのパパともの宮本武蔵に関するコメント（「晩年の宮本武蔵は一生懸命仏像を彫ったりしていたが、（若い頃）子供の道場主を殺したりしていたことによる怨霊は除霊できなかった」）に少しシビれた。息子のはやともが、まだ若いせいもあって、ちょっと話がマクロな（思想論や社会論的な）方向に行くと、厨二病的な傾向があるのには食傷気味な感じがあった。一方で、パパともの宗教・倫理観的な考えの方がその点、人間的な深さを感じるものがあったので、それがパパともに興味を引かれたきっかけだった。 パパともの霊能力に衝撃を受けた理由 そこで、初めて、パパとものチャンネルの動画もいくつか観たりしたのだが、「未解決事件を霊視する」という中々に攻めた企画を初期にやっていて興味深かったのだが、中に、上野の不忍池での事件（僕自身はこの 2006 年の事件については知らなかった）を扱ったものがあった： 「あっ！」と思ったのが、奇しくも前日（2023-06-28）、全く別のチャンネルの別の動画で、霊媒師が同じ事件を霊視するという企画のものを観ていたのだった： 千原せいじの YouTube チャンネルで、彼がコラボをしている飯島唯という通称・ギャル霊媒師の方が霊視をしている。 パパともの動画は 2021-05-12 と 2021-05-15 に公開されたものであるのに対し、ギ...
続きを読む

和歌山（？）の女性宮司の霊能力者を特定した

イメージ
昨夜、ニンゲンTVに登場した和歌山（？）の女性宮司の霊能力者の後編が公開された。滅茶苦茶気になったので、全力で我が特定力（？）を駆使したが、今ようやく特定できた。疲れた…… orz 前編を観た段階で、原田龍二が浮遊霊にいつの間にか憑かれていたことが発覚。『神島編』以来の肩の不調の原因だったようだが、だとしたら降魔師・阿部吉宏の立場は……。 まあ、数日前、僕は阿部さんは意外と「討ち漏らし」はあるんじゃないかという説を「 ニンゲンTVのヤバい心霊映像で気分が悪くなった……（その 2） 」という記事でも述べたりしていたので、霊能力者としては「感知能力が戦闘能力よりも劣る」タイプなのかなとは思っていた。 原田のヨイショと、天野ディレクターの良くも悪くも優秀な演出・編集によって、阿部さんが完全無敵の守護神（いわばオリヴァー・カーン）のように扱われているが、世には霊能者は他にも存在し、その中で阿部さんが完全無欠なのかというとそういうわけでないと思うし、本人も結構、そのあたりは謙虚な発言をしている。だが、ニンゲンTVの番組の演出上、これまで阿部さんを他の霊能者と比較するような場面がなく、ただ、非能力者である他のメンバーから唯一絶対的な能力者存在として扱われてしまっていただけだ。 阿部さん加入前に、ニンゲンTVがコラボをしていた凄腕霊能者の山口彩さんが好例だが、阿部さんが自身で謙虚に述べているように「 上には上がいる 」というのが本当のところだと思う。ただ、そういったプロ中のプロとして活躍中の霊能者の人たちだと、廃村・廃墟といった心霊スポット巡りの撮影に参加してくれるようなフィジカル的にもタフな人材は（阿部さんを除いて他に）見つけることは難しいように思われる。 原田の亡き祖母との再会の仕方に関する回答や、霊的な世界に関する見解など、この宮司は、（一霊四魂や言霊など）神道寄りながら、かなり良い指摘の仕方をする方だったと思う。神道なのに、最後は仏教的な輪廻転生観に基いて語っていたのも印象的だった。
続きを読む