魔改造したJupyterでイベント会場のWiFi環境を爆誕させる話

※記事を書いてすぐに、同僚が更に魔改造を進めたため、僕も調子に乗ってその魔改造に追従した結果、この記事の内容がすでに古くなってしまいましたw この記事を書いた時点の一式は https://github.com/mnagaku/wifi/tree/qiita1204 となります。最新版のは、また書きます

# はじめに

Jupyterって、構築・運用ツールですよね！

とゆーわけで、魔改造したJupyterでイベント会場のWiFi環境を爆誕させます。

用意するもの

* dockerが動く古いノートPC（5000円ぐらい）
* Linuxで使えるUSB-NIC（2つで2800円ぐらい）
* Cisco Aironet 1140（ヤフオクで2台で9000円ぐらい）
* PoE対応スイッチ（amazonで4500円ぐらい）
* LANケーブル（少々）
* [mnagaku/wifi](https://github.com/mnagaku/wifi)

2万円ちょいで、カタログスペック上は100台ぐらいぶら下げれるWiFi環境が買い揃えられます。スバラシイ。

# ノートPCの準備

debian9 stretchをインストールします。ブラウザが使いたいので、ウィンドウマネージャも入れておいてください。LXDEとか軽いのが良いでしょう。

ノートPCに最初から付いてるNICに加えてUSB-NIC2つを追加し、NICが3つ付いた状態にします。最初から付いてるNIC経由でインターネットアクセスできる状態とし、追加したUSB-NICにはブリッジ設定を施しておきます。

例えば、最初から付いてるeth0経由でインターネットアクセスし、追加したenx14とenx19にブリッジ設定br14とbr19を付けると、以下な感じになるでしょう。

```:/etc/network/interfacesの例
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

auto enx14
iface enx14 inet manual

auto enx19
iface enx19 inet manual

auto br14
iface br14 inet static
address 192.168.14.1
netmask 255.255.255.0
bridge_ports enx14
bridge_maxwait 0
bridge_fd 0
bridge_stp off

auto br19
iface br19 inet static
address 192.168.19.1
netmask 255.255.255.0
bridge_ports enx19
bridge_maxwait 0
bridge_fd 0
bridge_stp off
```

debianに、dockerとdocker-composeをインストールしたら、[docker-compose.yml](https://github.com/mnagaku/wifi/blob/master/docker-compose.yml)を/rootに落としておいてください。

因みに、br14をwifi用に、br19を有線接続用に使う想定です。といっても、br14に有線接続のクライアントをぶら下げるのも可能ですので、USB-NICは1個の追加でも大丈夫です。実は、有線接続を優先するようにQoSかける構想だったのですが、今回の話には出て来ないので、br19はいらない子な感じです。すいません。

# どっかー！こん、ぽおおおおおおおず！

```bash
# docker-compose up -d
Creating network "root_default" with the default driver
Creating network "root_wifi" with driver "bridge"
Creating network "root_wire" with driver "bridge"
Creating jupyter ...
Creating jupyter ... done
Creating vyos ...
Creating vyos ... done
Creating munin ...
Creating munin ... done
```

jupyterとvyos（ソフトウェアルータ）とmunin（snmpで監視）の3つのコンテナが起動します。

jupyterは起動時にmnagaku/wifiをgit cloneするようになっていて、構築手順をnotebook化した[event-wifi-construct.ipynb](https://github.com/mnagaku/wifi/blob/qiita1204/event-wifi-construct.ipynb)を、jupyter起動後すぐに使えるようになっています。

ノートPC上のブラウザから、jupyterコンテナのIPアドレスの8888ポートにアクセスすると、魔改造したjupyterが見えるでしょう。（トークンは起動時に指定しているのでdocker-compose.ymlを確認してください）

# やっとjupyterが出てきた

[![https://gyazo.com/ee0c262ffa8ae0f67483643056889fb9](https://i.gyazo.com/ee0c262ffa8ae0f67483643056889fb9.png)](https://gyazo.com/ee0c262ffa8ae0f67483643056889fb9)

このjupyterは、筆者らのグループが取り組んでいる、jupyterのnotebookを「実行できる手順書」とする「[Literate Computing for Reproducible Infrastructure](https://literate-computing.github.io/)」とゆー取り組みのための各種プラグインが入ったもので、dockerコンテナとしてパッケージされたものを[niicloudoperation/notebook](https://hub.docker.com/r/niicloudoperation/notebook/)から自由に使って頂けます。

見慣れない体裁だったり、アイコンが並んでたりするのはそのためです。

普通のnotebookと同じように、上から読みながらポチポチ進めて行けば良いのですが、例えば、

[![https://gyazo.com/7b2101a3b5e41f2dbd20cea44e6e531f](https://i.gyazo.com/7b2101a3b5e41f2dbd20cea44e6e531f.png)](https://gyazo.com/7b2101a3b5e41f2dbd20cea44e6e531f)

このnotebookを実行するための前提条件を確認するための実行セルを用意したり（notebookの書き方の工夫）、繰り返し実行してはいけないセルの実行後、フリーズ（雪の結晶のアイコン）をかけたり（プラグインによる拡張）、

[![https://gyazo.com/a62fbc597b3c8282a2f7038276013b11](https://i.gyazo.com/a62fbc597b3c8282a2f7038276013b11.png)](https://gyazo.com/a62fbc597b3c8282a2f7038276013b11)

お手本になる過去の実行結果を記憶させておき、今の実行結果とdiffを取れたり（プラグインによる拡張）、といった、構築・運用の業務にjupyterを使うための工夫が組み込まれています。

[![https://gyazo.com/a859531409b74436fc8013b05ea6e0b0](https://i.gyazo.com/a859531409b74436fc8013b05ea6e0b0.png)](https://gyazo.com/a859531409b74436fc8013b05ea6e0b0)

「Aironetの設定」では、この先の手順を進めるために、実際に無線APを繋いで、通信できる状態になっていなければなりませんが、最初の実行セルで、pingが通らなかったらエラーが出るようになっているので、よく分かんないでポチポチしてても、ちゃんと止まれるようになっています（notebookの書き方の工夫）。

sshのfingerprintを覚えさせる処理に併記されたマークダウンのドキュメント部分には、この手順を作る際に、試したけど動かなかった手順などの情報を書いておくことで、他の人に読んでもらった時に、なぜそうなっていて、どうしてああしなかったのか、が分かるようになっています（notebookの書き方の工夫）。

そんな感じで、このnotebookを流し切れば、15分ほどで、WiFi環境が構築できます。

# 「実行できる手順書」としてのnotebook

確かになんかスゴそうだけど、設定済みのAPじゃダメなの？

筆者もこの夏まではそうしていました。でも、

* 設定済みのAPを現地で少し設定し直したい時、どこをどう弄れば良いか忘れている
* 設定を付けた自分しか機械のことを分かってないので、他のスタッフに頼めない

とゆー問題がありました。実務でも、属人性や忘却（ドキュメント不足）などは、よく問題になります。

そして、この辺の問題は、単純な自動化では解決されません。

![LC4RIvs自動化.png](https://qiita-image-store.s3.amazonaws.com/0/42021/09d19468-5f67-45ff-f148-e783d24658af.png)

notebookを外部のスケジューラから全セル実行かけると、よくある自動化ですが、人間が読みながら実行もできるし、場合によっては、そうするべき場面もあり得ます。

このnotebookをもとにすれば、今後、vyosを完全仮想化に変更したり、別の機種のAPに変更したり、監視系を別のソリューションに変更したりする場合でも、ドキュメント部分を読みながら、書き換えながら、1つのファイルを弄ることで済ませられます。

設定済みのAPのバックアップファイルでは、そうは行きませんよね。

# さいごに

jupyterのnotebookを「実行できる手順書」とする「[Literate Computing for Reproducible Infrastructure](https://literate-computing.github.io/)」についてのコミュニティをはじめました。

https://www.facebook.com/groups/LiterateComputing/

に、参加申請を頂ければ、順次承認させて頂きます。これまで作成された資料の一覧や、今後の発表予定などの情報に加え、チュートリアルや情報交換のイベントもやっていきたいと思いますので、是非ご参加ください。よろしくお願いします。