KUSANAGIの僕が実装した機能とその裏側

福田です。この記事は「KUSANAGI Advent Calendar 2016」の13日目の記事です。今日は私が在職時代に作った機能やその際にあった体験談を語りたいと思います。とはいえど、もうやめて海外きてから正味半年近く経つので、記憶が曖昧なところもありますがその点ご容赦くださいませ。そして99%単なる自慢記事です。なるべく問題ないように書いているつもりですがお怒りのメールが来たら速攻消します

Sponsored link

KUSANAGIバナー

そもそもKUSANAGIって何?っていう人はこちらをクリックすると詳細がわかります

リリース前にも携わり、確かな高速化を実現

確かですが2015年5月?に入社した際はまだ7.0か7.1ぐらいだった頃だったと思います。正式リリース前でした。その頃はまだTwentyFourteenの標準デザインを使っていましたし、確か記憶が定かであればまだ沙耶もいませんでした。この時は僕は社長にPreloadというものをKUSANAGIに同梱することを勧め、実際に10Req/s程度を安定的に向上させることができたので実際に実装していただけました。たかが10Req/s、されど10Req/s。

manやSSL・日本語化に関する機能を主に実装

僕は高速化を目指して入社したつもりですが、もうその時点でほとんど手も足も出ないほどにガチガチに高速化されていたので、僕が関わった直接的な高速化は上のPreloadだけです。では留学準備のために退職するまでに何をやっていたのか。機能の追加です。ない頭からひねり出した機能がHSTS関連の機能とmanコマンド対応、Yumレポジトリの作成などですね。

SSLオプションは腐心しました。Let’s Encrypt以外、例えばEV証明書を使う可能性があることに気がつき、証明書インストールオプションを作ったのですが、以前はTarballでまとめていただき、一括インストールをしていたのですが、これはなぜかというと、その当時はロケーションの指定が難しかったからです。現在は誰だかわかりませんが改良していただいたおかげでその手間は不要になりました。また、HTTPSへのリダイレクトオプションなども実装しましたが、これはHSTSと一緒についてくるよね(僕のサーバーの常識)から実装しました。その際、「https [on|off]」としてしまうとHTTPS自体の有効・無効を切り替えるのかと勘違いするリスクがあったため、僕はあえて長ったらしい「https [redirect|noredirect]」というオプションにした経緯があります。
また、HSTS機能も僕が作りました。自分が使うときに単に便利よね&今後のセキュリティはこれがベースだと信じたためです。特筆していえば、HighモードでHSTS Preloadリストへの自動送信機能も作りましたが、この機能は現状おそらく動作しなくなっているはずです。というのも、受付URLが変わったという経緯があります(かつてはURLに自分のドメインを入れればよかったが、今は仕様変更によりそんな簡単ではなくなった)。実際動かしてはいませんがどこかのサイトでは確かエラー吐いていたはずです。忘れた。また、一部Settingオプションの実装なども担当しました。これに関しては特にいうことないので略。

KUSANAGIコマンドのmanはできるだけコマンドライン上で美しいデザインになるようにちょっとだけ工夫しました。また、裏側としていえば初期ではなくある程度コマンドが追加された段階で実装したため、非常に時間がかかり、また疲労係数も大きいことがありました。元々は英語&日本標準時固定で作成していたのですが、辞める直前にgettextを用いた日本語化・pacoを用いたTUIベースの時間帯設定を実装したのも僕ですね。タイムゾーン設定の方は大人からも褒められましたが、あれ、適当にテキストぶっ込むだけでいい感じにしてくれるので褒めるのはpacoの方かと()。

あとなんかありましたけど忘れました。

KUSANAGIの見えない部分も実装

今あるのかどうかははっきりしませんが、KUSANAGIコマンドの裏側も実装しました。例えばドメイン形式の判定関数などですね。今使っているのかどうかはわかりませんがコマンドの一覧を見た感じ使っていなさそうです。将来使えればと思っていたので、つまるところそれまではどこからも呼ばれないゴミ関数を限りある資源に放り込んだということです。他、パッケージビルドシステムやリポジトリの管理、社員専用のコマンドまでも僕が作りました。社員専用のコマンドには、ビルドを一発ででき、またテストもKVMなどを使って全自動で実現させるつもりでしたが思いついたのが遅いことなどからあえなく時間切れ、退職となりました。

ちなみに構想していた仕組みは次の通り。

  1. 同じリポジトリにRPM化される前のデータと社員専用コマンドを置いておく
  2. RPM化される前のデータを編集、コミットする
  3. 社員専用コマンドからリモートのビルドサーバにビルド要求を送信
  4. ビルド完了後、ビルドサーバから自動的にKVMが立ち上がるor社員専用コマンドから検証VMが立ち上がる
  5. テスト完了後、社員専用コマンドからリリース

ボツになった機能

構想はしていたもののボツになった機能もあります。それは強制アップデート・インストール統計です。強制アップデートはユーザーからのPull式=コマンド実行に頼ることなく、こちらから専用のポート待ち受けソフトかWordPressなどに仕込んだある意味バックドアからアップデート要求/RPMなどを送りつけてアップデートをかける仕組みです。ダメな理由は第三者による改ざんのリスクなどではなく、万が一行うと大混乱に陥る可能性があるからだそうです。ま、せいぜい自分の中にとどめておくべきだと僕も思いました。後々。これが実現できていたら、OpenSSLの重大脆弱性などはこちらからアップデートをかけさせるつもりでした。インストール統計は強制アップデートに付随してできるじゃん、っていうことで思いついた結果です。特に意味はない。

まとめ

僕がとんでもないバグを作ってしまい、そのまま18歳未満の労働規制の影響でさっさと帰宅してしまったために他の社員2名ほどをデスマーチにさせてしまったことが2度ぐらいありまして、それに関しては非常に申し訳なく思っていますし、時折魔が差したこともありましたがそれでも優しくしていただいた社員の皆様には感謝感激です。そして一年とちょっとここで仕事していたわけですが、こんな3000文字ぐらいでまとまってしまうようなことしかしてなかったとなると無能社員だった予感がしてなりません。

ちなみに…Prime-Strategyでバイトとして働いていましたが、僕は実を言うと唯一の学生(高校生・大学生)社員でした。甘やかしていただいていたのかもしれませんが、帰国後(&大学入試終了後)はしっかりとした一人前に仕事していきたいな、と、思っています。もちろんデスマの借りは返します。そして僕はあの社風が好きです。

明日は田島さんの「KUSANAGI for Laravel」です。LaravelはPHPフレームワークです。はい、実はWordPress以外も当然ですが動かせます。もちろん爆速です。FuelPHPやCakePHPを動かしている人も知っています。皆さんもお試しいただくとKUSANAGIとの新しい人生(!?)を歩めるかと思います。あとはUbuntuに移植した変人(←僕)とか、Nginxの設定をいじりにいじり倒してもはやKUSANAGIじゃない何かに化けているサーバ(←知り合い)とかもあったりします。

KUSANAGIをいじり倒しましょう!VIVA KUSANAGI!!!
おしまい。

Sponsored link

Sponsored link

2 responses to “KUSANAGIの僕が実装した機能とその裏側”

  1. smiyaza1969 says:

    ドメイン形式の判定関数は今も使ってますねwww.example.com と example.comの場合だけ動作を変えています。

Leave a Reply