暗証番号やPINコードに使えるような、指定された桁数のランダムな整数値を生成したいのである。
英数記号を用いたパスワード文字列の自動生成については知見があるのだが、「数字のみ」という条件が付いた途端に、「あれ？ そういえば、どう生成すればよいのかなあ？」とつまづいてしまったのである。
パスワード文字列の生成ではpwgen(1)を愛用している。他のツールを探すのも面倒なので、pwgen(1)で何とかできないだろうか？
man(1)を見ながら検討した結果、手元のpwgen 2.08ではこんな感じで数字のみのパスワードを生成することに成功した。
# 6桁のPINコードを1つ生成する場合： pwgen -A -r abcdefghijklmnopqrstuvwxyz -s 6 1
オプション-Aを指定して英大文字を除外した上で、オプション-rを使って英小文字を除外している。オプション-yを指定しなければ、記号文字は使われない。消去法で、残された有効文字は数字のみとなる。
他にもっとスマートなツールが存在するはずだが、とりあえず個人的に使う分にはこんなもので十分だろう。
パッと見の印象：テスト駆動開発あたりの文脈から出てきた「単体テスト」についての、「良いテスト」について論じた本。
単体テストにフォーカスしたソフトウェア・テストの本で、しかも「具体的なテストのやり方」ではなく抽象的な視点で論じているものって、（少なくとも和書では）あまり類書を見ないように思う。
本書を購入した理由は、私の中の「単体テスト」と、最近に世間一般で言われている「単体テスト」の差異を知るためである。私自身は、どちらかと言えば組み込みソフトウェア開発の文脈で単体テストに取り組んできた人である。組み込み系の単体テストは、本書の「単体テスト」とはまた異なる趣がある。
知らないうちに、自分と相手とで異なる「単体テスト」を思い浮かべたまま会話していて、話がこじれてしまった――みたいなことを避けたい。そのためにも、今の時代に多くの人が思い浮かべるだろうタイプの「単体テスト」について知っておきたい。
こういう用途には、今の「単体テスト」について一通りまとめられた本書はちょうど良い感じである。
ただし、この本は教科書や学術書ではなく、「著者が自分自身の開発経験を通じて会得した考え方をまとめたもの」という面が大きい。そのため、内容の所々に著者の好みが現れているように感じられる。全てを鵜呑みするのは避けた方がよいだろう。
1週間ほど前の下記blog記事が気になったため、少し調べてみた。似たような事例に引っかかった人はそれなりにいるようだ。
調べてみての感想は：
周知の事実だが今一度繰り返すと、コンテナ自体はプロセスではない。Linux namespacesの機能を駆使して、既定の名前空間とは別の名前空間に諸々のリソースを詰め込んで隔離した代物がコンテナである。
プロセスではないので、Dockerのbridge networkにおいて今回の話題の中心であるポート・マッピングのような機能を実現するにあたり、ユーザーランドでのソフトウェア処理による通信制御――つまりソケット・プログラミングを行っていない。
もしもソケット・プログラミングによるソフトウェア処理で実現していたならば、この件は「Linux上でネットワーク・サーバを直接動かす」のと同じレベルになるので、実運用において問題を引き起こすことはなかっただろう。
でも残念、現実は非情である。コンテナから「ホストの外部ネットワーク」への通信や、ポート・マッピングの機能を実現するために、ホスト側では古の自作Linuxルーターみたいなことをやっているのである。
Dockerのネットワーク機能について語るにあたり、一見して無関係そうな、迂遠なところから話を始めようと思う。BSDソケットとネットワーク・インタフェースの関係である。
TCPやUDPにはポート番号という概念があり*2、クライアント・サーバ・モデルにおけるサーバ側ソフトウェアでは、bind(2)を使用してソケットを「通信を待ち受けるポート番号」に割り当てる――というのがソケット・プログラミングにおける古典的なアプローチである。*3
ポート番号に目が向きがちだが、bind(2)ではソケットにIPアドレスを割り当てることもできる。どういうことだろうか？
例えばコンピュータにLANポートが2つ付属していて、そのうちeth0には192.0.2.1が、eth1には203.0.113.10が割り当てられていたとする。
ここで、TCPポート2195番を使用するネットワーク・サーバを動かしたいのだが、eth0（192.0.2.1:2195）宛ての通信は受信したいけどeth1（203.0.113.10:2195）宛ての通信は無視したい――という場合に、bind(2)にて「192.0.2.1:2195」というIPアドレスとポート番号のペアを割り当てることにより、eth0宛ての通信だけ受信するようになる。
eth0とeth1の両方に届いた通信を受信したいなら、「0.0.0.0」というワイルドカードとして機能するIPアドレス*4を指定すればよい。ワイルドカードアドレスを指定することにより、ローカルループバックを含む「そのコンピュータに割り当てられている全てのIPアドレス」のポート2195番宛ての通信を受信するようになる。
bind(2)によるIPアドレスの割り当ては便利といえば便利なので、大抵のネットワーク・サーバでは「通信を待ち受けるIPアドレス」を設定できるようになっている。
例えば、下記は手元のsshd_configの一部を抜粋したものになるが、「ListenAddress」という項目にてbind(2)するIPアドレスを指定できるようになっている。
# sshd_config より抜粋 #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::
既定値は0.0.0.0であり、コンピュータの全てのIPアドレス宛ての通信に反応するようになっている。
古典的な「管理者がサーバの隅から隅まで把握している」というスタイルのサーバ構築・管理においては、サーバ上で動かす「TCP/IPを喋るサーバ・デーモン」について、各々の設定を見直して、必要最小限の「IPアドレスのbind(2)」を実現するだろう。つまり、軽々しくワイルドカードアドレスを使用したままにはしておかないのが理想的である。
現実は異なる。ネットワーク・サーバの設定を変更して特定のIPアドレスをbind(2)するようなことは、今となってはあまり多くない。設定ファイルの既定値はワイルドカードアドレスであることが多いし、大半のケースでは既定値であるワイルドカードアドレスのまま運用している。
先に抜粋したsshd_configから分かるように、私自身もワイルドカードアドレスのままネットワーク・サーバの類を動かしていることが多い。
実際のところ、現在のサーバ管理においては、多種多様な「TCP/IPを喋るサーバ・デーモン」を動かしている上に、各種コンポーネント類の入れ替わりも早い。なのでいちいち全てのネットワーク・サーバの設定を精査なんてしていられない。ちょっと間に合わない。
では、bind(2)によるIPアドレスの割り当ての代わりに何をしているかといえば、ファイアウォールで宛先アドレス／ポート番号をチェックしてパケットフィルタリングしているのである。
ネットワーク・サーバの設定ファイルは分散している上に内容も千差万別だが、ファイアウォールなら1ヶ所で集中管理できる。その点は便利だよね。
Linux上では、ネットワーク・サーバはプロセスとして動作している。LinuxのNetfilterにおいては、ローカルプロセス宛てのパケットはINPUTチェインでフィルタリングすればよい。
次の図は、NetfilterにおけるL3でのパケット処理の流れを示したものである。
+-----------------------------------------------------------------+
| Network Interfaces |
| (lo/eth/wlan/etc...) |
+-----------------------------------------------------------------+
| |
Incoming packet Outgoing packet
| |
+-------------+ |
| PREROUTING | |
| +---------+ | +-------------+
| | raw | | | POSTROUTING |
| +---------+ | | +---------+ |
| | | | | nat | |
| +---------+ | | +---------+ |
| | mangle | | | | |
| +---------+ | | +---------+ |
| | | | | mangle | |
| +---------+ | | +---------+ |
| | nat | | +-------------+
| +---------+ | |
+-------------+ |
| +---------------------------+ |
| | FORWARD | |
+-------------+ | +--------+ +--------+ | +-------------+
| Routing |--->| | mangle |---->| filter | |--->| Routing |
+-------------+ | +--------+ +--------+ | +-------------+
| +---------------------------+ |
| +-------------+
| | OUTPUT |
| | +---------+ |
| | | filter | |
+-------------+ | +---------+ |
| INPUT | | | |
| +---------+ | | +---------+ |
| | mangle | | | | nat | |
| +---------+ | | +---------+ |
| | | | | |
| +---------+ | | +---------+ |
| | filter | | | | mangle | |
| +---------+ | | +---------+ |
+-------------+ | | |
| | +---------+ |
| | | raw | |
+-----------------------------------------------+ | +---------+ |
| | Local Process | +-------------+
| | | |
| +---------------------+ +-------------------+ | +-------------+
| | recv(2)/recvfrom(2) | | send(2)/sendto(2) |-|-->| Routing |
| +---------------------+ +-------------------+ | +-------------+
| | | |
| Received data Send data |
+-----------------------------------------------+内部でソケット通信しているネットワーク・サーバは、この図におけるローカル・プロセスに該当する。INPUTチェインは、ネットワーク・インタフェースからローカル・プロセスまでの経路上に位置する。なので、INPUTチェインにてパケットフィルタリングを行うことになる。
VPSなどでサーバを構築する場合、iptablesやnftablesのINPUTチェインにフィルタリングルールを設定するだろう。大概の入門文書にてそう案内されているし、実務的にもその通りだ。
ということで、Linuxサーバを触っている人にとって、INPUTチェインは身近なものである。普通にネットワーク・サーバを動かす分には、割とそれだけで十分に間に合うものだ。
残念ながら、Dockerのコンテナそのものはローカル・プロセスではない。ローカル・プロセスではないのだから、コンテナ宛ての通信について「ホスト側のNetfilterのINPUTチェイン」にて制御を試みるのは的外れである。
次の図は、Dockerでネットワーク・ドライバとしてbridge networkを選択した状態で、3つのコンテナを動かした際の、大まかなネットワーク構成を示したものである。
+----------------------------------------------+ | Linux box | | | | +------------------------------------------+ | | | Default network namespace | | | | | | | | +-------+ +-------+ +-------+ +-------+ | | | | | lo | | eth0 | | eth1 | | wlan0 | | | | | +-------+ +-------+ +-------+ +-------+ | | | | | | | | +---------+ | | | | | docker0 | | | | | +----+----+ | | | | | | | | | +--------------+--------------+ | | | | | | | | | | | +---+---+ +---+---+ +---+---+ | | | | | veth0 | | veth1 | | veth2 | | | | | +---+---+ +---+---+ +---+---+ | | | +-----|--------------|--------------|------+ | | | | | | | +-----|------+ +-----|------+ +-----|------+ | | | +---+---+ | | +---+---+ | | +---+---+ | | | | | veth0 | | | | veth0 | | | | veth0 | | | | | +-------+ | | +-------+ | | +-------+ | | | | +-------+ | | +-------+ | | +-------+ | | | | | lo | | | | lo | | | | lo | | | | | +-------+ | | +-------+ | | +-------+ | | | | | | | | | | | | Container1 | | Container2 | | Container3 | | | +------------+ +------------+ +------------+ | +----------------------------------------------+
Dockerのホスト側から見ると、実行中の各コンテナはdocker0という仮想ネットワーク・デバイスの先にぶら下がっている。
この構造は、下記のネットワーク構成と非常によく似ている。
+------------------------------------------+
| Linux_box0 |
| |
| +-------+ +-------+ +-------+ +-------+ |
| | lo | | eth0 | | eth1 | | wlan0 | |
| +-------+ +-------+ +-------+ +-------+ |
| |
| +-------+ |
| | eth2 | |
| +---+---+ |
+--------------------|---------------------+
|
+--------------+--------------+
| | |
+-----|------+ +-----|------+ +-----|------+
| +---+---+ | | +---+---+ | | +---+---+ |
| | eth0 | | | | eth0 | | | | eth0 | |
| +-------+ | | +-------+ | | +-------+ |
| +-------+ | | +-------+ | | +-------+ |
| | lo | | | | lo | | | | lo | |
| +-------+ | | +-------+ | | +-------+ |
| | | | | |
| Linux_box1 | | Linux_box2 | | Linux_box3 |
+------------+ +------------+ +------------+この図は自作Linuxルータの実行環境の一例である。Linux_box0がルータである。eth2はプライベート・ネットワークに繋がっている。プライベート・ネットワーク上には3台のコンピュータ（Linux_box1～Linux_box3）が動作している。Linux_box1～Linux_box3は、ルータであるLinux_box0を経由して外部ネットワークと通信する。
ここで、外部ネットワークと繋がっているネットワーク・インタフェースがeth0だと仮定すると、Linux_box0では、何かしらの方法でeth0～eth2間でパケットを橋渡しする必要がある。
Dockerの場合も似たようなもので、やはり外部ネットワークと繋がっているのがeth0だと仮定すると、ホスト側にて何かしらの方法でeth0～docker0間でパケットを橋渡しする必要がある。
どう橋渡しするか？ IPフォワードを使用してネットワーク・インタフェース間でパケットを転送するのである。この時、NetfilterのPREROUTINGチェインとPOSTROUTINGチェインにて、パケットの宛先IPアドレスの書き換えを行っている（俗に言うNATとかIPマスカレードとかいうアレである）。
先に示したNetfilterのパケット処理の図で言うと、例えばLinux_box1／Container1が外部ネットワークに向けて送信したパケットは、Linux_box0／Dockerホスト側では次のように処理されるだろう。
反対方向の、外部ネットワークからLinux_box1／Container1に向けてのパケットは、次のように処理されるだろう。
どちらのケースも（特に受信方向のパケットについて）INPUTチェインを通過しない。だからINPUTチェインに記述したフィルタリング・ルールは適用されない。
このことは、Dockerのネットワークまわりについて理解していれば、自明のことである。
残念ながら、私を含めて「コンテナはプロセスではない」ということの本当の意味についての理解が浅い人は多い。そのような人が今まで触ってきたネットワーク・サーバと同じような塩梅でコンテナを扱おうとしてしまい、ファイアウォールについてもネットワーク・サーバの時と同じ流儀で適用すれば十分だと判断してしまった時に、INPUTチェインのフィルタリング・ルールが適用されないという事実が牙をむくことになる。
……自作Linuxルータなら、物理的にLANの構成が目に見えて分かる。でもDockerの場合は全てがホスト側のコンピュータの中におさまっていて目に見えない。目に見えないからこそ、混乱を引き起こしやすいのかもしれない。
Dockerは外部ネットワークとコンテナの間をつなぐためにNetfilterのルールを変更する。具体的にはどのような内容なのだろうか？
以下に示す環境（Ubuntu 22.04上のDocker 24.0.3）にてルールを確認してみた。実験用に用意した環境であるため、そもそもパケットフィルタリングのルールは未設定の環境である。
$ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy $ uname -a Linux fabrico 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux $ docker --version Docker version 24.0.3, build 3713ee1 $ docker version Client: Docker Engine - Community Version: 24.0.3 API version: 1.43 Go version: go1.20.5 Git commit: 3713ee1 Built: Wed Jul 5 20:44:55 2023 OS/Arch: linux/amd64 Context: default Server: Docker Engine - Community Engine: Version: 24.0.3 API version: 1.43 (minimum version 1.12) Go version: go1.20.5 Git commit: 1d9c861 Built: Wed Jul 5 20:44:55 2023 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.21 GitCommit: 3dce8eb055cbb6872793272b4f20ed16117344f8 runc: Version: 1.1.7 GitCommit: v1.1.7-0-g860f061 docker-init: Version: 0.19.0 GitCommit: de40ad0
まず、Docker本体が動作している時にnftablesでルールを確認すると、次のようになっている。
# sudo nft -s list ruleset table ip nat { chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER } chain DOCKER { iifname "docker0" counter return } } table ip filter { chain DOCKER { } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 counter return } chain FORWARD { type filter hook forward priority filter; policy drop; counter jump DOCKER-USER counter jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter accept oifname "docker0" counter jump DOCKER iifname "docker0" oifname != "docker0" counter accept iifname "docker0" oifname "docker0" counter accept } chain DOCKER-USER { counter return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter drop counter return } }
この状態では、コンテナがクライアント側として振る舞う通信が許可されている（なのでapt(8)やyum(8)を使用してネットワーク経由でもコンポーネントをアップデートすることが可能である）。
具体的には、POSTROUTINGチェインの下記ルールにより、コンテナから外部ネットワークに向けて送信したパケットの送信元IPアドレスが「ホスト側のIPアドレス」に書き換えられてから外部ネットワークに送出される。
oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade
nftablesのルールでは明示されていないが、外部ネットワークからコンテナ宛てに届いたパケットについても、PREROUTINGチェインあたりのタイミングで送信先IPアドレスが「ホスト側のIPアドレス」から「コンテナのIPアドレス」に書き換えられているはずである*5。
外部ネットワークからコンテナ宛てに届いたパケットに関しては、FORWARDチェインの下記ルールにより「コンテナが送信したパケットに対する応答パケット」のみを受容するように動作している。
oifname "docker0" ct state related,established counter accept
総じて、送信側も受信側も実に「家庭用のブロードバンドルータ」っぽいルールであるな、という感想である。
次にdocker run -p 8080:8080でコンテナを起動した時のルールはどうなっているだろうか？
# docker run -p 8080:8080 test_image # sudo nft -s list ruleset table ip nat { chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade meta l4proto tcp ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 8080 counter masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER } chain DOCKER { iifname "docker0" counter return iifname != "docker0" meta l4proto tcp tcp dport 8080 counter dnat to 172.17.0.2:8080 } } table ip filter { chain DOCKER { iifname != "docker0" oifname "docker0" meta l4proto tcp ip daddr 172.17.0.2 tcp dport 8080 counter accept } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 counter return } chain FORWARD { type filter hook forward priority filter; policy drop; counter jump DOCKER-USER counter jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter accept oifname "docker0" counter jump DOCKER iifname "docker0" oifname != "docker0" counter accept iifname "docker0" oifname "docker0" counter accept } chain DOCKER-USER { counter return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter drop counter return } }
コンテナから外部ネットワークに向けて送信されたパケットの扱いについては、先ほどと同じだ。違いは外部ネットワークからコンテナ宛てに届いたパケットの扱いに見られる。
外部ネットワークからホスト側のポート8080番に届いたパケットは、PREROUTINGチェインからジャンプした先のDOCKERチェインにおいて、下記ルールによって宛先IPアドレス／ポート番号が書き換えられる。
iifname != "docker0" meta l4proto tcp tcp dport 8080 counter dnat to 172.17.0.2:8080
その後、FORWARDチェインからジャンプした先のDOCKERチェインの下記フィルタリング・ルールでパケットが受容される。
iifname != "docker0" oifname "docker0" meta l4proto tcp ip daddr 172.17.0.2 tcp dport 8080 counter accept
この一連の流れには、家庭用ルータのポート開放機能を彷彿させるものがある。
さて、PREROUTINGチェインで実行される下記ルールを再度見てみる。
iifname != "docker0" meta l4proto tcp tcp dport 8080 counter dnat to 172.17.0.2:8080
このルールでは、ホスト側に届いたパケットの宛先IPアドレスをチェックしていない。そのため、ホスト側の「docker0を除く、全ての『IPアドレスが付与された』ネットワーク・インタフェース」のポート8080番に届いたパケットが、DNATで宛先がコンテナのIPアドレスに書き換えられて、以降のチェインに流れて行ってしまうことになる。
それでは、例えばdocker run -p 192.0.2.100:8080:8080のように、IPアドレスを明示してポート・マッピングした場合には、どのようなルールになるだろうか？
# docker run -p 192.0.2.100:8080:8080 test_image # sudo nft -s list ruleset table ip nat { chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade meta l4proto tcp ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 8080 counter masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER } chain DOCKER { iifname "docker0" counter return iifname != "docker0" meta l4proto tcp ip daddr 192.0.2.100 tcp dport 8080 counter dnat to 172.17.0.2:8080 } } table ip filter { chain DOCKER { iifname != "docker0" oifname "docker0" meta l4proto tcp ip daddr 172.17.0.2 tcp dport 8080 counter accept } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 counter return } chain FORWARD { type filter hook forward priority filter; policy drop; counter jump DOCKER-USER counter jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter accept oifname "docker0" counter jump DOCKER iifname "docker0" oifname != "docker0" counter accept iifname "docker0" oifname "docker0" counter accept } chain DOCKER-USER { counter return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter drop counter return } }
PREROUTINGチェインでDNATする部分のルールのみ変化している。
# IPアドレスを明示しなかった場合： iifname != "docker0" meta l4proto tcp tcp dport 8080 counter dnat to 172.17.0.2:8080 # IPアドレスを明示した場合： iifname != "docker0" meta l4proto tcp ip daddr 192.0.2.100 tcp dport 8080 counter dnat to 172.17.0.2:8080
IPアドレスを明示した場合は、DNATする際に宛先IPアドレスをチェックしている。これにより「ホスト側の特定のネットワーク・インタフェースに届いたパケット」のみがDNATされ、以降のチェインに流れていくようになる。
ポート・マッピングする際にIPアドレスを明示することで、ホスト側の特定のネットワーク・インタフェースに届いたパケットだけがDNATされて、コンテナに転送されるのであった。
さて、Dockerの開発者になった気分で思考実験してみよう。「ホスト側の特定のネットワーク・インタフェースを示すIPアドレス」の既定値（デフォルト値）として相応しい値は何だろうか？
Dockerを動かすホストには、ネットワーク・インタフェースは何個存在するだろうか？ それぞれのネットワーク・インタフェースには、どのようなIPアドレスが付与されているだろうか？
答え：ネットワーク・インタフェースが何個あるのか分からないし、付与されているIPアドレスも分からない。
さあ、既定値として相応しいIPアドレスは何だろうか？
――と考えた時に、既存のネットワーク・サーバの待ち受けIPアドレスのように「とりあえず全てのネットワーク・インタフェース宛てのパケットを受容してしまおう」という判断をすることは、まあ、意外とありがちなパターンではないかと思う。
唯一の違いは、普通のネットワーク・サーバならNetfilterのINPUTチェインのフィルタリング・ルールが適用される（だから、その辺のルールさえ適切ならば、ワイルドカードアドレスにbind(2)しても被害はでない）のにたいして、Dockerのポート・マッピングではINPUTチェインのルールが適用されないことである。
ここで、既定値としてローカルループバックを採用することは、Dockerという汎用なソフトウェアとしては「ちょっとやりすぎ」感がある。
例えばRDBMS（MySQLとか）の管理ポートなら「既定値＝ローカルループバック」でも納得できるかもしれない。なぜならRDBMSを全世界に大公開することは非常に稀だからだ。というか普通は、公開ネットワーク上のサーバで動かしているRDBMSの管理ポートに外からアクセスできてしまったら、真っ先にサーバのセキュリティ対策不足を疑うと思う。
一方でWebサーバの公開ポートについて「既定値＝ローカルループバック」だったら「うーん、それってどうなのよ？」みたいなお気持ち表明が出てくるはずである。「既定値はワイルドカードアドレスでいいのでは？」とも突っ込まれるかもしれない。
Dockerは汎用な仕組みである。各コンテナでは、Webサーバ（広く公開されることが多い）が動いていることもあれば、RDBMS（公開範囲はできるだけ狭く）が動いていることもある。
ローカルループバックを既定値とするのは適切だろうか？ むしろDockerユーザからのお気持ち表明が出ないだろうか？
非常に悩ましい。私個人の感想としては、仮に開発者が「しゃーないやんけ」とこぼしていたとしても、まあ、むべなるかな……。
とりあえず以下の4通りが考えられる。オススメは(1)ないし(2)じゃないかしら。
DOCKER-USERという名前のチェインを追加する。ここにユーザ定義のフィルタリング・ルールを追加すればよい。docker runする時に--cap-add=NET_ADMINを付与することで、コンテナの中でiptablesやnftablesを利用できるようになる。コンテナ起動後に追加されるルールのうち、POSTROUTINGに追加される下記内容について：
meta l4proto tcp ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 8080 counter masquerade
どのような意図のルールなのか分からなかったのだが、Stack Overflow情報によれば、POSTROUTINGのデフォルト・ルールがDENY（つまりpolicy drop）である場合でもコンテナが自分自身に接続できるようにするため、というエッジケース対応用のルールであるらしい。
*2:SCTPやDCCPなどの後発のL4プロトコルにもポート番号はある。AppleTalkやIPX/SPXやNBF（NetBEUI）などの古いプロトコルについては知らない。
*3:サーバ側のポート番号が固定されているので、クライアント側は「送信先ポート番号」を決め打ちして通信開始する――というアプローチである。これとは別に、VoIPやWebRTCなどのように、仲介者（SIPサーバやシグナリングサーバ）を通じて（SDPなどで）「通信に使用するポート番号」の情報を相互に交換することにより、ポート番号を動的に決定する（≒決め打ちではない）アプローチもある。
*5:iptablesのマニュアルを確認した感じでは、IPマスカレードを使用する場合にはPOSTROUTINGチェインにだけ設定しておけばよいみたいである。
2023-06-18現在のステータス。昨年（2022-06-19）から1年経て、こうなっている。
なおCSS、HTML、XMLはひとまず除外する。人工言語ではあるけれども「プログラミング言語」という括りに含められるか否かは議論が分かれる気がする。*1
to_s(16)やto_s(2)で基数変換して表示できるところが割と好き。varとval」と「varとlet」の振る舞いの差異につまづいたりしてしまう*11。*1:「HTML5 + CSS」の組み合わせなら、チューリング完全の疑惑があったり、JavaScript使わずにCSSでWebチャットを作った猛者がいたりと、色々と怪しいのだけど。
*2:「独立性の高い単体のツールを実装する」という視点では、現代ではAWKよりも便利な言語が山ほどある。
*3:しかし標準ライブラリの充実度をJavaやC#（.NET Framework含む）と比較したり、型推論まわりをKotlinやSwiftと比較してはいけない。以前よりも随分と便利になったのだけど、だけど、隣の芝生を見てしまうと、うーん……。
*4:SwiftではC++の機能を直接呼び出すことができないので、Objective-Cでラッピングして利用することになる（インタフェースはObjective-Cで、内部実装はObjective-C++）。この時、Objective-Cクラスのインスタンス変数として「C++クラスのインスタンスを保持するスマートポインタ」を持つ構成にしておくと、Objective-Cクラスのインスタンスがdeallocされる時に、スマートポインタ経由でC++クラスのインスタンスもdeleteされる。
*5:少なくともC++の言語／ライブラリ仕様は私の手には余る。自分が把握している範囲の機能でコードを書くのは好きなのだけど。
*6:支障がある部分を触るほど深入りするには、あと20年ぐらい掛かるのではないか？
*9:これでもsedはチューリング完全な言語だと証明されているらしい。
*10:私の認識では、JavaScriptは、第一級関数やクロージャがお仕事用のメジャーな言語に組み込まれて、少なくない人が使う契機となった言語だ。
*11:Kotlinのvalは「再代入不可の変数」だ（定数はconstで定義する）。Kotlinのプリミティブ型以外のデータ型はclass（つまり参照型）なので、valで定義した変数を破壊的操作する行為は割と普通だと思う。一方でSwiftのletは定数であるし、値型が中心の言語仕様である影響かstructやenum（つまり値型として振る舞うデータ型）が多用されるので、letで定義した変数を破壊的操作できるケースとできないケースが生じる。
*12:言語仕様的にはC# 5.0の環境だが、ライブラビまわりはC# 4.0相当だったはず。
*13:Windowsのことを考えなければ、自前でライブラリをビルドしてアプリに組み込むのは結構簡単だった。
*14:――といってもシミュレータだけど。
*15:ClojureやScalaに関しては、同様の機能を私が見逃している可能性も高いのだが。
注文の多いタイトルである。
なぜ、こんなに注文が多いのか？
元々は、astyle(1)（Artistic Style）を弄くっていて：
astyle --style=kr \ --indent=tab=4 \ --indent-namespaces \ --indent-labels \ --indent-preproc-define \ --break-blocks \ --pad-oper \ --pad-header \ --unpad-paren \ --add-brackets \ --align-method-colon \ --unpad-method-prefix \ --pad-method-colon=none \ --max-code-length=120 \ --errors-to-stdout \ ${@+"$@"}
――こんなオプションでいい感じになるのだが、唯一気に入らないのが、2行以上の連続する空白行がそのまま残ってしまうこと。1行にしたいのだ。
astyle(1)には--delete-empty-linesというオプションがあるが、これだと1行だけの空白行も消えてしまう上に、関数内でしか有効にならない。そうじゃなくて、1行だけの空白行はそのまま残しつつ、2行以上の連続する空白行を1行にしてほしい。関数の中と外のどちらでも適用されてほしい。
astyle(1)にかけるソースファイルには、改行がCRLFのものとLFのものが混在している。なので、どの改行コードのファイルでも処理できるようにしたい。出力結果の改行コードは元ファイルに準じてほしい。
astyle(1)は、元のファイルのバックアップを作成しつつ、元のファイルの名前で処理結果を出力する。その出力結果を上書きする感じで、空白行の処理を行いたい。大本のファイルはastyle(1)が残しているので、空白行の処理を行う前のファイルは残さなくてもよい。
ということで、まずはこんな感じのコードを（「これ、遅いだろうな」と思いつつ）書いてみた。
for i; do cat "$i" | (rm -f "$i"; sed '/./,/^$/!d' >"$i") done
しかし残念なことに、手元の環境（Cygwinのsed(1)を使用）では、CRLFが問答無用でLFになってしまった。どうもsed(1)が原因のようだ。
sed(1)を止めてPerlにすることにした。最初に書いたのがコレ。
perl -0777 -pi -e 's/(\r\n|\n|\r){3,}/\1\1/g' ${@+"$@"}
「-0777」で入力ファイルを一気に読み込むことで、正規表現を用いて連続する改行コードにマッチできるようにしている。また、オプションiを拡張子無しで用いて、入力ファイルを出力結果で上書きするようにしている。
これでうまくいくかと思いきや、例えば次のようなファイル（CRLF）にて：
1 aaaaa 2 bbbbb
1行目の末尾から3行目の頭の間の「\r\n\r\n」が「\n\n」になってしまった。つまり、CRLFのファイルを食わせると、CRLFとLFが混在したファイルができあがる可能性がある。
これは正規表現の問題で、本来なら、CRLFのファイルでは「CRLFが3つ以上」に、LFのファイルでは「LFが3つ以上」に……という具合にマッチさせなくてはならないところを、無理やり1つの正規表現にしたために、「\r\n\r\n」が「『CRかLF』が4つ」と解釈されてマッチしてしまう可能性が生じていたのだ。
上記を踏まえて書き直したのがコレ：
perl -0777 -pi -e ' foreach my $nl ("\r\n", "\n", "\r") { s/(?:$nl){3,}/$nl$nl/g; } ' ${@+"$@"}
これで意図したとおりに動作するようになった。
ところで、大抵のファイルでは改行コードが混在している可能性は低い。なので、3種類の改行コード全てについてマッチングと置換をする必要もないだろう。
ということで、ファイル中の最初の改行コードを調べて、その改行コードでのみ置換を行うようにしてみた。
perl -0777 -pi -e ' foreach my $nl ("\r\n", "\n", "\r") { if (/$nl/) { s/(?:$nl){3,}/$nl$nl/g; last; } } ' ${@+"$@"}
これで多少は速くなった……かもしれない。
コンピュータは電子計算機とも訳されるように計算に用いるのが本流である、という信念*1の元に、私はちょっとした計算にもパソコンを用いている。
当然ながら*2計算にはLisp処理系のREPLを使用する。*3
ちょっとした計算にてLisp処理系のREPLを用いるメリットは、例えば何かを単純に足し引きする時に、足し引きする値ごとに演算子を書かなくて済むのである。
私はよく買い物の計画を練るのにREPLを用いる：
; ルーターのお守りを任されたけど使い方が分からん。 ; 入門書でも読もうかな。 (+ 4730 ; 978-4839965402 ) ; => 4730 ; そういえば新人向けのLinux入門書を見繕わないと。 ; この辺りの本とかどうだろう？ (+ 4730 ; 978-4839965402 1980 ; 978-4048913928 2970 ; 978-4797380941 ) ; => 9680 ; ついでに同僚のA氏が絶賛してた本も買おうかな……。 (+ 4730 ; 978-4839965402 1980 ; 978-4048913928 2970 ; 978-4797380941 4488 ; 978-4839981723 ) ; => 14168 ; ちょっと金額を減らしたいなあ。 ; こんな感じでどうだろう？ (+ 4730 ; 978-4839965402 2970 ; 978-4797380941 4488 ; 978-4839981723 ) ; => 12188 ; 端はポイントで支払おう。 (+ 4730 ; 978-4839965402 2970 ; 978-4797380941 4488 ; 978-4839981723 -188 ) ; => 12000
買い物が1ヶ所のネットショップで済むならば、買い物かごの機能で合計金額を確認すれば済むだろう。だけど時には品揃えと単価の都合より複数のネットショップ（そして稀に実店舗も）に分散して購入を検討することもある。そんな時は、REPL上であれこれ項目をこねくり回して合計金額を計算することが多い。*4
中置記法を用いるプログラミング言語に慣れた身からすると、Lisp処理系での足し算は少し興味深い。
私の普段使いの言語では、加算は二項演算だ*5。そのため加算する際には値が2個必要だ。値が1個だけでは駄目だ。そして値が3個以上あってもいけない（演算子を都度追加しなくてはならない）。
# これはOK。 10 + 3 # => 13 # これはNG……というかREPLでは「右辺となる値の入力待ち」になりそう。 10 + # これはNG。シンタックスエラー。 10 + 3 5 # 演算子を都度追加すればOK。 10 + 3 + 5 # => 18 10 + 3 + 5 + 2 # => 20
（後置記法／逆ポーランド記法を用いるプログラミング言語ではどうだろうか？ Forthの解説文を読んだ感じでは、ワード+はスタックに積まれている値を2個使用するようだが……）
一方で、Lisp処理系では値が1個でも3個以上でも加算した結果を得ることができる。だから、REPLを使ってあれこれ考えながらこねくり回す時に、安心して「取り扱う値」にだけ集中していられる。演算子の書き忘れに起因するシンタックスエラーなどを気にしなくてもよい。
; これはOK。 (+ 10 3) ; => 13 ; これもOK。 (+ 10) ; => 10 ; これだってOK。 (+ 10 3 5) ; => 18 (+ 10 3 5 2) ; => 20
それと、中置記法の言語では例えば「10 + -3」のような書き方は合法だが、個人的に見た目に違和感があり、どうしても「10 - 3」と書きたくなる。しかし理由は不明だが、Lisp処理系で「(+ 10 -3)」と書いても違和感がない*6。だから安心して負の値のリテラルを加算するコードを書ける。
注意点としては、多くのLisp処理系には分数型があるので、整数値を除算した時に意図せず分数型の値が得られてしまうことがある。
; 72の法則を試してみよう。 ; 年利4%だとどうだろう？ (/ 72 4) ; => 18 ; 年利5%だと？ (/ 72 5) ; => 72/5 ; おおっと、明示的に小数のリテラルで書かないと駄目だった。 (/ 72.0 5) ; => 14.4
変数については、letなどを用いて局所変数を使う分には、Lisp処理系ではワンライナーでも比較的書きやすい気がする。普段使いの言語でも、ブロックスコープを用いれば似たようなことを実現できるが、それをワンライナーで書くのはちょっとだけ面倒に感じる。この辺は、Lispの「式もデータ構造もリスト」という特徴がコードの見た目に及ぼす影響によるものだろう。
; 今はこんな感じ： (+ 108) ; => 108 ; 直近の想定値を加味すると： (let ((n 21)) (+ 108 n -40 -21.2 -4.8)) ; => 63.0 ; さらに4回分の想定値を加味すると： (let ((n 21)) (+ 108 n -40 -21.2 -4.8 (* n 4) 10 -40 -21.2)) ; => 95.8 ; ……うーん、条件を少し変更してみるか： (let ((n 22)) (+ 108 n -40 -21.2 -4.8)) ; => 64.0 (let ((n 22)) (+ 108 n -40 -21.2 -4.8 (* n 4) 10 -40 -21.2)) ; => 100.8
ところで大域変数*7ではなく局所変数を用いるしょうもない理由の1つとして「letあたりならCommon LispとSchemeのどちらのREPLでも大体同じ感じに書ける」というものがある。例えばここまでに書いたLispのコード片はCLISPとGaucheのどちらでも動作する。*8
ここまで書いてきたように、私は単純な足し引きの計算にLisp処理系のREPLを多用しているのだが、それゆえに、ここまでに書いた内容よりも高度なコードはほぼ確実に書けない自信がある。
今、手癖の範囲で書けるLispのコードは、この程度が限界だ。
; 四捨五入を考慮しないなら、こんな感じ？ (let ((ir (* 0.31 0.66)) (lir 0.05)) (if (>= ir lir) ir lir)) ; => 0.2046
if式は便利だ……KotlinのノリでSwiftでif式を書こうとしてシンタックスエラーしちゃう癖を何とかしたいなあ。CやC++ならちゃんと「if文」モードでコーディングできるんだけど、Swiftだとうまく切り替わらないの、何でだろう？
*1:そんなものはない。
*2:いや全くもって当然ではない。
*3:単純な計算を行うだけなのに、電子計算用のハードウェアでOSを動かして、OS上で数値計算用ではなくリスト処理用の言語処理系を動かして数値計算を行う――という大いなる計算資源の無駄遣いを楽しめるのも大人の醍醐味であろう。
*4:この手の計算に表計算ソフトを用いないのは、ひとえに私がへそ曲がりなだけである。
*5:もしかしたら「中置記法」かつ「加算が二項演算ではない」プログラミング言語も存在するかもしれないが、今のところ私はそのような言語に遭遇したことがない。
*6:個人の感想です。
*8:いい加減、この手の計算に用いるREPLをCommon LispとSchemeのどちらか一方に統一したいところである――とか言いだしてから10年以上経過した気がする。
WindowsとmacOSを本格的に併用していた時期に気づいたのだが、Windowsで「読み取り専用」に設定したファイルは、macOSではロックされたファイルとして認識されるようだ。明示的にロックを解除しない限り、macOSのFinderでは削除できない。
Windowsでは誤ってファイルを編集してしまわないように「読み取り専用」に設定することがある。「読み取り専用」のファイルは普通のファイルとほぼ同様にそのまま削除できる（「読み取り専用」のフラグを解除する必要がない）。なので、運用上は特に問題にならない。
これが例えば「Windowsで『読み取り専用』のファイルをリムーバブルメディアにコピー→macOSに持っていく」なんてことをすると、macOS上でファイルを削除できずに慌てることになる。
ロックの解除はGUIでも可能だが、上記の状況ではロックされたファイルが大量にあったりする訳で、GUIで解除するのは面倒だ。普段からbash(1)で操作することが多いので、ターミナルで何とかしたい。
ロックの解除はchflags(1)で可能だが、コマンド名やオプションを忘れた頃にロックされたファイルに遭遇することが多いので、シェルスクリプト化しておくことにした。
#!/bin/sh # -*- coding: utf-8-unix -*- # vim:fileencoding=utf-8:ff=unix PATH=/bin:/usr/bin exec chflags -R nouchg "$@"
シェルスクリプト化したから、多分しばらくの間ロックされたファイルに遭遇することはないだろう。世の中そういうもの。
chflags(1)はmacOS固有のコマンドかと思ったが、どうもBSD由来のようだ。4.4BSDから追加されたファイルフラグ（パーミッションとは別に、ファイルの追加・変更禁止などを設定するフラグ）を操作するためのコマンドだった。
ということは、Windowsで「読み取り専用」に設定したファイルをFreeBSDやOpenBSDに持っていった時にも同じような問題が起きるのだろうか？
2022年後半はNANDの価格の下落が進み、その影響か有象無象の格安SSDをよく見かけるようになった。
SSDの中身は、乱暴に言ってしまえば「NANDチップを含む電子部品が実装された基板」だ。HDDとは異なり、モーターのような精密な機械部品を含まない。必要な電子部品さえ揃えられるならば、SSDを設計・製造する難易度はあまり高くない。その影響か、現状では有象無象のブランドまでSSDを手がけている。
玉石混交なブランドがSSDを扱っている影響で、市販のSSDの品質も玉石混交気味だ。
SSDを「一定以上の信頼性のある補助記憶装置」として使いたい場合――例えばOSをインストールするシステム・ドライブとして使用したいならば、玉石の中から信頼性が高めなSSDを選ぶ必要がある。
SSDも工業製品なので、最終的には個体による品質の差（そして時には初期不良の問題）に突き当たるのだが、その点を除外するならば、一般的には「NAND型フラッシュメモリの市場シェア上位のメーカーが展開するブランドのSSD」は比較的信頼性が高いといえる。
NANDメーカーの吸収合併など動きでブランド名が変化することがある。ここに、2023年2月時点での「比較的信頼のおけるSSDブランド」についてメモしておく。
以下、アルファベット順：
『プログラミングの壺 I ソフトウェア設計編』に続いて、古典を読んでみようと思い立って購入。
あとで書く。
