00:00
はい、ということなんですけど、今回は nginx ビルドについてちょっと話をするって聞いてきたんですけど、
そもそも nginx ビルドって何なんですかね、ちょっと僕知らなくてですね。 はいはいはい。
そもそも nginx って使ったことあります? もちろん、使ったことあります。使ってます。
多分ウェブ系の人だったら nginx は大体何かしらで触ると思うんですけど、その nginx をコンパイルするのに
結構便利なツールですね。Goで作られています。 なるほど、その nginx をコンパイルするって、何でそもそもコンパイルする必要性あるんですかね。
なんか nginx インストールする時って、例えば apt インストールだったりとか、まあそういうパッケージマネージャー的なのでインストールするのが普通なのかなと思うんですけど、
ビルドする必要性って何なんですかね。 そうですね、まあ確かに最近は apt インストールとかで入るnginx で大抵の人は
こどたれるとは思うんですけど、例えばその nginx ってそのモジュールって概念があって、
そのモジュールで何かいろいろ機能追加できたりするんですよ。 あのもともとあのスタティックモジュールとダイナミックモジュールっていうのが今2つあって
apt インストールとかで入るやつはあのダイナミックモジュールの方がだいたい使われてるんですけど、そのダイナミックモジュールって後から入った仕組みなんですよ。
で、もともとスタティックモジュールの方が一般的で、今でもスタティックモジュールしか対応してないモジュールって結構あるんですよ。
なのでそういうモジュールを使いたい場合は、自分でコンパイルしてスタティックモジュールを一緒にコンパイルするって形で使うのが
以前は一般的だったんですね。それプラス最近だとその特定のオープンSSLのバージョンじゃないと使えない機能とかも結構出てきているので
なんかそういうのをこの機能を使いたいとかピンポイントでこの機能を使いたいみたいなのがあったら自分でエンジンXコンパイルした方が機能としては使いやすいと思いますね。
なるほど。じゃあサーバーにインストールされているオープンSSLのバージョンと違うバージョンを使いたい場合はエンジンXビルドを使って、何らかの形でエンジンXをビルドする必要性があるっていう話なんですかね。
そうですね。これもなんかいろいろやり方ってあって、そのオープンSSLをそのアプトインストールとかで入れたオープンSSLを使ってエンジンXをコンパイルするってこともできるんですよ。
だけど、それだとそのOSと同じバージョンのオープンSSLしか使えないので、エンジンXに対してその専用のオープンSSLを静的にビルドして、そのOSのパッケージとは違うオープンSSLで使うっていうこともできるし、
そこはどういう運用したいかにもよるんだけど、エンジンXビルドは一応どっちでもできるって感じですね。
03:00
なるほど。じゃあ、他にエンジンX以外のミドルウェアだったりとかいろんなツールを使ってて、ここのツールはオープンSSLこのバージョンがいいけど、エンジンXはこのバージョンがいいみたいなのが自由度高く設定できるみたいなのが強みというかエンジンXをビルドする必要性みたいなところがあるんですかね。
そうですね。
ちなみにさっき言ってたそのスタティックなモジュールですかね。使うにはそもそもエンジンXをビルドしないといけないんですかね。他の方法があるんですか。
いや、スタティックモジュールの場合はコンパイルするしか方法はないですね。
なるほど。じゃあ本当にビルド時に含めるしかないんですね、モジュールは。
そうですね。
そういったのがエンジンXビルドで簡単にビルドできるようになるっていうようなツールなんですかね、すごいざっくり言うと。
そうですね。エンジンXってエンジンXをダウンロードしてコンパイルするだけかっていうと、実はそうでもなくて、さっき言ってるオープンSSLと、あとGzip圧縮するためのZlibっていうライブラリーと、
あとエンジンXって設定に正規表現書けるんですけど、その正規表現書くためにPCREっていうのを使っていて、その3つ、PCREとZlibとオープンSSLの3つがないといけないんですよ、基本的に。
使う機能にもよるんですけど、基本的にこの3つのソフトウェアがエンジンXのコンパイル時に必要で、それをわざわざダウンロードしてくるか、もしくはそれこそOSのアプトインストールとかで入れるかのどっちかなんですよね。
この3つは超有名なソフトウェアなので、全部アプトで入れることもできるんですけど、自分で全部入りの静的に全部コンパイルしたいってなると、全部一個一個ソースコードダウンロードしてこないといけないんですよね。
それが結構めんどくさいじゃないですか、一個一個ポチポチダウンロードしてくるの。
めんどくさいですね、地味に。
そう地味にめんどくさくて、エンジンXビルドは全部自動で、全自動でダウンロードしてきてくれるっていうのが便利ですね。
そのときに、ダウンロードするときに細かくバージョンの指定もできるっていうような感じなんですか?
そうです。バージョンもオプションで指定できるし、極力最新版に、そもそも僕が今メンテナンスを、もともと作った人は違う人なんですけど、
今最近は、ここ数年は僕がメンテナンスをしていて、極力、特にZlibとかPCREは最新版じゃないとめんどくさいので、極力最新版になるようにしています。
なるほど。じゃあいい感じにしてくれるし、カスタマイズもできるよっていうような感じなんですね。
そうですね。
ちなみにエンジンXビルドができる前というかある前って、どんな感じでやってたんですかね?みんな本当に各々シェルスクリプト頑張って書いてビルドしてみたいな感じになってたんですかね?エンジンXのビルドって。
どうなんですかね?みんな多分手で一個一個ダウンロードしたか、シェルスクリプトかなんかで一個一個やってきたか、
もしくは手でダウンロードしてきたソースコードを置いておいて、それをシェルスクリプトで実行しているだけだったかもしれないし、それは会社によっていろいろあると思いますね。
06:10
そういったのを手動で頑張っていただったりとか会社単位でやってたのが一個にギュッとまとめて、しかもGoだからインストールするのも簡単でバイナリー一個本体置いて実行すればいいみたいな感じがエンジンXビルドでなったっていう感じですね、環境として。
そうですね、エンジンXビルドはGoなので本当に持ってくるだけで使えますね。ただ一応Gitとかその後Makeとかその諸々エンジンXビルドするのに必要なソフトウェアはいくつかインストールされている必要はありますね。
なるほど、必要な依存のソフトウェアは必須ではあるけども。
必要だけ依存もって感じですね。
なるほど、基本的には簡単にインストールできるよっていう感じですね。
ちなみに片杉さんはどんな感じで使ってますエンジンXビルド具体例ちょっと教えてもらいたいなと思うんですけど。
今は会社では使ってないですと。今趣味で使ってるんですけど、自分今朝倉のVPSでエンジンX運用していて、このエンジンXで結構いろんなことやってるんですよね。
例えばHTTP3を有効にしたりとか、あと最近本当最近ですけどECHっていう新しいやつを有効にしてみたりとか、そういう結構特殊なことをエンジンXでいろいろやってるんですよ。
そういう機能ってエンジンXの最新機能でかつ特定のOpenSSLじゃないと使えなかったりとかするので、それをエンジンXビルドで指定してコンパイルしたのを動かしてるっていう感じですね。
なるほど。じゃああれですかね。やっぱりそういう最新機能を使ったりとか、細かくバージョン指定して最新の機能を使う、ないしはいろんなものを試したいみたいな開発者が使うようなイメージが結構大きそうですかね。エンジンXビルドに関しては。
そうですね。やっぱり特殊な運用したいとか、そういうケースが多いかなとは思いつつ、たださっき言ったOpenSSLとかPCIe Zlibとかを全部静的にコンパイルできると基本的にGoのバイナリーみたいなバイナリーが作れるんですよね。要はどこに持ってってもLinuxだったらだいたいどこでも動くよねっていう形にできるんですよ。
さっき言ったそのOpenSSLとかをApp to Installとかで入れちゃうと、そのApp toInstallされたやつじゃないと基本的には動かないエンジンXができちゃうんですけど、そのエンジンXビルドで全部ソースコードダウンロードしてコンパイルすれば結構割とどこでも動くようなバイナリーっていうのが手に入るんですよね。
なのでちょっと特殊な設定をしたエンジンXをいろんなサーバーに配りたいみたいな用途だとエンジンXビルドでどこかでコンパイルしてそれを配るみたいなやり方もできるし、エンジンX使って実際に運用してるってなると強い見方かなと思いますね。
09:14
なるほど、その一個にパッケージングとしてまとめてしまって、ワンバイナリーでいろんなところに置けるっていうのはかなり聞いてる限りでは魅力的なメリットかなと思いますね。
ただあれですかね、一般的にエンジンXを普通の使い方をする場合はApp to Installしてっていう風な使い方をする方が普通は多いかなっていう感じですかね。
あれなんですよね、最近ってやっぱりALBとかCDNとかそういったものを使うケースが多いと思うんですよ。なのでエンジンXで直接TLSを解きますとかユーザーフェンシングのサービスを自前でエンジンXで動かしますっていう会社さんってだいぶ減っちゃったと思うんですよね。
確かにそうですね。
そうなると開発者の人たちがエンジンX欲しいときって本当にHTTPでプロクシー離せばいいよぐらいの感じだと思うんですよね、ほとんどのケースで。そうなるとApp to Installとかで入れたやつで基本機能が足りないってことはないので、基本それでほとんどの人は満足するんじゃないかなとは思ってますね。
確かに自分のエンジンXの使い方的にも、例えば開発環境だけで機能するリバースプロクシーとかそういうので使ってるんですよね。ローカルで動くような形で。なのでそれであれば普通に標準のエンジンXで事足りるかなっていうので使ってるんですけど、そういうのが多層という感じですね、一般的には。
そうですね。それで事足りるなら全然エンジンXビルドは必要ないんですけど、やっぱりユーザーフェンシングのTLSも全部さばきますってなってくると、ちょっとこの機能使いたいなとかいろいろ出てくるかなと思いますね。
逆にあれですかね、CDNとかをやってるようなサービス会社ですかね、そういうエンジンXをゴリゴリに使うような会社の内部ではもしかしたらかなり使われてる可能性はありますよね。
かもしれないんですけど正直誰が使ってるのかよくわからずに自分もメンテナンスしてるっていうのはありますね。
なるほど。ありがとうございます。ちなみにさっき途中でちょっと前に出たECHですかね、ECHってちょっと聞き慣れない単語というかワードなんですけど、ECHって何なんですかね。
エンクリプテッドクライアントハローの略で、TLSでHTTPSって暗号化されてるじゃないですか、そのTLSの通信を開始するときにクライアントハローっていうのをブラウザーから送られてくるんですよ。
で、このクライアントハローの中身を暗号化しちゃおうっていうやつで、これ何でかっていうと一番大きいのがドメイン名でHTTPSって暗号化されてるって言いつつ、その通信してるドメイン名って暗号化されてないんですよね。
12:08
これはSNIって呼ばれてるところにドメイン名が載ってるので、ここって暗号化されてないんですよ。なのでドメイン名わかっちゃうよねっていうところで、ドメイン名も暗号化したいっていうので、クライアントハロー全体を暗号化すればドメイン名も隠れるっていうので、クライアントハロー全体を暗号化してるっていうのがエンクリプテッドクライアントハローですね。
なるほど、どこのサイトにアクセスしているのかさえ隠してしまおうという話ですね。
じゃあ本当に個人情報というか、例えばNORAのWi-Fiとかにつないでる時にもちゃんとエンクリプテッドクライアントハローが実装されていれば、どのサイトにアクセスしてるかっていうのはそのWi-Fiの管理者でもわからないっていう感じなんですかね。
そういうこともできますね。エンクリプテッドクライアントハローを使えば。
すごい、なんか早く標準になってほしいなと思うんですけど、これはまだ標準になってないんですよね。
いや、PCHはつい最近標準に一応なりましたね。
そうなんですね。標準になって、で、なんか大体のウェブサーバーとかではまだでも実装されて、サポートされてるものではないですよね。
そうですね。サポートはそんなに、クラウドフレアは使えるんですけど、クラウドフレアの事業者で使えるところは自分はちょっと知らないですね。
片杖さんこのECHを試してみたって感じなんですかね。自分のSAKURAのVPSで。
そうです。自分のSAKURAのVPSで、今ECH動いてますね。
じゃあこれその時にエンジンXビルド使って、エンジンXの方でECHって話すようにしたっていう感じなんですね。
なんか特にハマるポイントとかなかったんですか、ちなみにECH使うために。
そうですね。今は大丈夫なんですけど、自分が最初にECH使った時はそのOpenSSLの、OpenSSLだとまだ使えなくて、OpenSSLのFuture ECHブランチっていう開発中のブランチじゃないとECH使えなかったんですよね、当時。
なのでエンジンXビルドの機能をちょっと足して、OpenSSLのGitのタグとかも指定できるようにしたので、
このOpenSSLのタグをダウンロードしてきて、それでコンパイルするみたいなことをできるようにして使えるようになりました。
じゃあバージョンの指定だけじゃなくてGitのタグまで読み込んで、それでダウンロードしてビルドするみたいな機能をエンジンXビルドに足したっていうことですね。
そうですね。エンジンXビルドに足して使えるようになりましたね。つい先日、OpenSSL4系がリリースされたんで、その4にはそのFuture ECHの機能入っているので、
4だったら使えるんですけど、4が出る前だと開発中のブランチ使うしかなかったですね。
15:03
じゃあそこで必要になったからちょっとカスタマーしたっていう形なのですね。
その変更、エンジンXビルドにECHの対応のためにタグのダウンロード機能を追加した時点でもうすでにメンテナーだったんですかね。
結構前からメンテナーで何年、いつからかもう覚えてないんですけど、もう数年前からずっとメンテナーやっていて、ここ数年はもう自分以外のコミットはほぼないかな。
そうなんですね。そのメンテナーになったきっかけみたいなのあったりするんですか。
なんかそもそもメンテナンスが一時期滞っていて、自分が個人でサイコンVPSで使っていたので、ちょっと困るなっていうのと、
あと個人的にエンジンXのバージョンアップとか、あとエンジンXに付随する、さっき言ったPCREとかZlibとか古いバージョンを使いたくないので、
その辺のバージョンアップの情報とか個人的に追ってたんですよね。個人的にそれ追うぐらいだったら、このエンジンXビルドのメンテナンスして追えばいいじゃんってなって、
じゃあもう全部自分でまとめてやっちゃいますよって話をオリジナル作者の人に伝えてメンテナンスを引き取ったって感じですね。
なかなかお得意あるなという感じがするんですけど、そのバージョンのアップデートを追従していかないといけないっていうのが基本的なメンテナンス内容なんですかね。
そうですね。基本的にはエンジンXの新しいバージョンが出たら、デフォルトが最新になるようにするとか、そういうのが一番重要という状況ですね。
なんかどっかのファイル書き換えてバージョンアップデートするみたいな感じなんですかね。
コースコード上に定数で定義されているので、あそこをもともと手で書き換えられてたんですけど、僕がメンテナンスで引き取ったタイミングで、
もう全自動でリノベートっていうサービスを使って全自動で書き換えられるようになったので、今はリノベートが全自動で送ってきますね、プレリクエスト。
結構素晴らしいですね。リノベートを使えばライブラリの更新に合わせて自動でプレリクエスト作ってもらえるみたいな感じなんですかね。
そうですね。多分多くの人はリノベートを使ったことある人でも、例えばGoだったらGo.MODとか、ノードJSだったらパッケージJSONとか、あのあたりは自動でやってくれるんですよ、リノベートだと。
じゃあ先にリノベートってざっくり言うとどんなものなのか説明してもらってもいいですかね。
GitHubの公式にあるDefendPodってやつがあるんですけど、それのもうちょっといろんな機能がある版って感じなんですけど、
パッケージJSONとかGo.MODとかComputerJSONとかGemファイルとか、各言語にいろいろあるじゃないですか、そういうパッケージ管理系が。
18:01
そのツールっていうかファイルとかですよね。
ファイルがあって、そこにバージョンとか書かれてるじゃないですか。そのバージョンを自動で検知して、新しいバージョンが出てたらバージョン更新した上でプレリクエスト送ってくるっていうのがリノベート。
それは結構ほぼデフォルトで今言ったけどやってくれるので、多くの人はほぼデフォルトの設定でそういう設定を使っているんじゃないかなと思うんですけど、
リノベートって実は結構いろんな機能があって、結構細かい設定がいろいろできるんですよ、実は。
なるほど。今聞いた限りだと、パッケージ.JSONとかそういうバージョンがこうやって書かれているよみたいなフォーマットがあるわけじゃないですか、そういうツールごとに。
それであればバージョンがここに書かれているから、ここを見て更新があれば更新のプレリクエストを作るみたいなのが一般的なのかなと思うんですけど、今聞いたエンジンXビルドの話だとどこかに定数が書いてあるって言ってたんで、バージョンが書かれているところが一般的ではないところなのかなと思ったんですけど、それもリノベートでできるってことなんですかね。
そうですね。まさにそういう問題があるんですけど、その辺も正規表現とかでリノベート結構いろいろかけちゃうので、そういうのでうまくこのファイルのここを更新してください。
あとかつ、GitHubのURLとかでそのタグを見に行けたりとかもするので、このここに新しいバージョン出てきたらこれ更新してくださいみたいな設定もかけるんですよね。
そういうの結構いろいろ面倒くさかったんですけど、例えばPCREとかだと他のOSとバージョンのタグ付けがちょっと違ったりとかしたんで、そういうのは一個一個対応する必要あったんですけど、でも一個一個設定かけば全部できるんですよね。
なのでその設定一個一個書いて、このレポのこれが更新されたらここ書き換えてくださいみたいなのを一個一個書いたんですね。
じゃあかなりカスタマイズ性があるものなんですね、リノベートは。
リノベートはすごいカスタマイズ性高いですね。
その分おそらくゴリゴリに書かないといけないっていうのはあると思うんですけど。
そうですね。結構めんどくさいですね。
標準ではないからこそだと思うんですけど。
そうですね、リノベート、ドキュメントは結構ちゃんとしているのかな。
なんかドキュメントがちょっと正直多すぎて、もう全然何の機能あるかよくわかんないんですけど。
多すぎるってことですね。
そう、機能が多すぎて、ドキュメントがめちゃくちゃ多いんで、そこはすごい大変ですけど。
なんか今だったら、もしかしたらクロードコードとかでリノベートのそういう細かい設定とかもしかしたらバーってかけたりするんですかね。
21:01
昔は全く書けなかったですね、リノベートの。
リノベートのドキュメント多分読み込んでなくて、昔のAIは全く書けなかったんですけど、
最近はちょっと以前ちょっと書かせたら、最近はちょっと書けるようになってましたね、以前よりだいぶ。
すごい。
多分リノベートを学習したんじゃないかなと思いますね。
本当にちょっと前まで全く書けなかったんで、最近は以前より書けるようになってます。
いいですね、じゃあより書きやすくなってきたという感じですね。
なんとなくそういう自由度が高いというか、コードに埋め込まれているようなバージョンのアップデートって、
今だったらLLM、クロードコードのギターアクションズだったりとか使ってご利用しちゃうかなと思うんですが、
リノベート使えば割と静的な形で確実にアップデートがしてくれるっていうのがリノベート使っている利点でもあるって感じですか。
そうですね、なんかご利用しでそういうスクリプト書いてもしょうがないかなと思っているので、
リノベートでやったほうがどうなんですかね、人にも寄りそうですが。
リノベートいいと思いますよ、僕は結構有名。
推し。リノベート自体はOSSなんですかね。
OSSもありますね。普通にCLIでも使えますね、リノベートは。
なるほど。定期実行はギターアクションズとかでやってるって感じですかね。
そっちでもできるんですけど、自分はリノベートのSaaSがあるので、
そっち使ってますね。
ギターアクションズで自分で実行してもできるはずですけど、
プレリクエスト作ろうとすると多分オースアップだっけな、
アプリケーション作らないといけないとか色々めんどくさいことがあるはずですね。
確かにGitHubそこら辺めんどくさいですね。
SaaSだと登録するだけで全部やってくれるので便利ですね。
いいですね。じゃあSaaS版を使って現在はメンテナンスしていて、
そのプレリクエスト作られたらちょっと確認してポチポチしていくみたいなのが定期的にあるって感じなんですね。
そうですね。
ちなみにNginx Build、メンテナーやってから結構経てるのかなと思うんですけど、
今後どうしていくみたいなのあったりするんですか、Nginx Buildをもうちょっとこうしていきたいみたいなのって。
自分は特にそういうのないんですけど、Nginxでやりたいこと色々できるようにはしたいなと思っていて、
さっきのECHの件でOpenSSLのタグ指定できるようにするとか、
そういう今のNginx使いこなすのに必要な機能っていうのは随時足していきたいと思ってますし、
あとちょっと前に騒ぎになったんですけど、NginxのポークのFreeNginxっていうのが出てきたんですよ。
24:01
今もあるんですけど、フリーNginxが出てきたらコミュニティがどう動くかわからないので、
今Nginx BuildはフリーNginxも使えるようになってるんですよね。
こういうNginx、フリーNginx両方対応するとか、そういうコミュニティの動きに合わせていって対応はしていきたいなと思ってますね。
じゃあ柔軟にメンテナンスしていけたらなという感じなんですね。
フリーNginxも対応してるっていうのも結構すごいなと思うんですけど、
変わりってあったりするんですかね、Nginx本家とフリーNginx。
フォークしたから大元は変わらないかなと思うんですけど、細かい点で変わってくるかなとは思ってるんですけど。
そうですね、ソースコードは大元は同じだし、お互いそんなものすごいリファクタリングとかもフォークした後特にしてない認識なので、
ソースコード大きく差はないですと。
ただ細かい機能差っていうのはだいぶ出てきているし、あと多分フリーNginxの影響なんですけど、
以前NginxってGitHubはMirrorでGitHubじゃなかったんですよね、もともと開発の主体が。
そうなんですね、別のリポジトで出てたんですね。
そうですね、完全に独自のやつでやってたんですけど、今はGitHubに開発完全に移ってるんですよね。
そのGitHubに開発移ったタイミングで結構開発速度が上がっていて、結構新機能追加されてるんですよ、ここ数年で。
フリーNginxが出てきた時期って結構Nginxの機能追加が滞ってた時期なんですけど、
最近はだいぶNginxにも新機能追加されてきてるので、結構Nginxだと使えるけどフリーNginxだと使えない機能っていうのが結構出始めてるっていうのはありますね。
もちろん逆のパターンもあるんですけど、逆のパターンは正直派手な機能は僕の認識だとあんまりないって感じですね。
じゃあどっちかっていうとそういう派手な機能はNginx本家の方がどんどん取り入れているっていうのが今の状況?
そうですね、僕の認識だと。
逆にフリーNginxの方は何ですかね、その体制みたいなところが重視されてるんですかね。
エンジニアが主導するNginxだよみたいなところがフリーNginxなのかなって個人的には思ってるんですけど。
もともとNginxのコアコミッターの人がそのNginxの方針に反発してフォークしたものがフリーNginxで、開発体制とかもほぼ全部一緒なんですけど、
ただ開発者が基本的にその人一人しかいないっていうのがフリーNginxなんですよね。
そうなんですね、一人なんですね。
一人一人一人がずっとやってる感じですね、フリーNginxは。
そういう感じなんですね。
だからこそ速度みたいな面ではフリーNginxの方がちょっと部が悪いというか。
27:03
開発速度という点ではやっぱりGitHubにNginxが移ったってフリーNginxがGitHubじゃないんですよ開発が。
そうなんですね。
なので開発速度はもう今Nginxの方が速くなりましたね。
逆にフリーNginxからNginx本体に取り込まれた機能とかってあったりするんですかね、片杉さんが見てる範囲で。
それがつい最近あって、フリーNginxのコミットをNginxにもコミット入れようっていう議論が起こって、実際にいくつか入りましたね。
すごい。
今後そういうのも積極的に入れていきましょうって話がNginxの中で通ったので、
これはNginxとフリーNginxはライセンスが一緒なんですよね。
結構界隈だとライセンスに反発してOSSが報告するケースって最近いくつかのソフトウェアであったと思うんですけど、
NginxとフリーNginxはライセンスで分かれたわけじゃないので、ライセンス一緒なんですよ。
なので結構フリーNginxのコミットをNginxに持ってくるってことは現状できる。
しかもソフトウェアのベースもお互いそんなに大胆なファクタリングとかしてないので、
コミットそのまま持ってこれる状況にもあるので、
結構今いくつかフリーNginxからコミット持ってきたやつがリリースされてますね。
すごい話ですね。
もともとライセンス機能でのフォークじゃなくて、開発体制みたいなところのフォークだったからこそできているところですね。
そうですね。なかなか個人としてもいい話だなと思っている。
フリーNginx側はどう思っているかちょっとわからない。
確かにそうですね。立ち位置としてフリーNginxが今後どうなっていくのかというところは個人的に興味あるなとは思いましたね。今の話聞いてて。
そうですね。どうなるかちょっと僕もわからないんですけど、一応Nginxビルドの方は対応しばらくはしていこうかな。
完全に止まったりしたら考えるんですけど、基本的にはしていこうかなとは思ってますね。
ただそのフリーNginx辛いのが開発者視点だと辛いのがドッカイメージとかないんですよフリーNginxって。
なるほど。
だからフリーNginx使いたい場合はそれこそNginxビルドってビルドする以外の方法がほぼないんですよね、現状だと。
パッケージマネージャーとかアプトとかでインストールはできないんですか。
できないですね。
RPMパッケージとかもNginxだと独自のRPMパッケージとかDevパッケージ配ってるんですけど、フリーNginxはそういうのもなくて本当にソースコードしかないので、
自分でコンパイルするしかなくて、自分でコンパイルするんだったら多分Nginxビルド使うのが一番楽なんで。
ってなるとフリーNginx使う方法はそれこそNginxビルド使う以外あんまりないっていうのが現状だったりしますね。
なるほど。じゃあ名前がもしかしたらフリーNginxビルドになるかもしれないですね。
30:06
それはどうなのかな。
そうはならないって感じですね。
そうは現状ならないですね。
フリーNginxが今後どうなるか楽しみでもあるんですけどね。
立ち位置的にNginx本家の方に入れられない実験的なものを入れていくみたいな感じになっていったら、
より面白いことになるのかなとはなんとなくは思うんですけどね。
どうなっていくかって感じですね。
作者の人はそういうことをやりたいわけじゃなさそうだし、入れてる機能もそんな実験的な機能は入れてきてない印象ですね。
なるほど。じゃあそうはならなそうですね。
そうはならなそうですね。
ありがとうございます。
ここまで聞いて結構Nginxビルドの有用性というかこういう場面で使うんだなみたいなのが結構はっきりしてきたなと思っていて、
やっぱりあれですね、一般的なエンジニア、サーバーを扱っているようなエンジニアが使うというよりかは、
もうちょっとコアなNginxをより使い倒すだったりとかこういう実験的なものをちょっと個人的に試してみたいみたいないう時に使うのがNginxビルド一番のユースケースとしてありそうですね。
そうですね。あとクラウドサービス自前で作ってるとかそういうのは使うかもしれないですね。
確かにNginxを使い倒している会社ですね。
そうですね。
ありがとうございます。ちなみにNginxビルドでもいいんですけど、Nginxでもいいんですけど、最後に言いたいこととかあったりしますか?達也さん的に。
そうですね。Nginxビルドでいろいろできるんですよね。今回OpenSSLの話しかしなかったんですけど、実はLibreSSLっていうOpenSSLのフォークもあって、Nginxビルドはそれにも対応してたりするんですよね。
なので本当にOpenSSLもそうだし、いろいろ取り替えられるというか、あんまり普通じゃない構成っていうのも結構できたりするので、そういうの興味ある人は結構面白いかなと思ってますね。
僕もちょっと前までLibreSSLでずっと運用してたので、そういう本当にいろんなことできるので、Nginxビルド便利だと思うので、Nginxビルドする人には使ってほしいかなと思ってます。
ありがとうございます。いい感じの時間になりましたので、今回はここまでにしたいなと思います。
ヤオヨロズのOSSでは毎回一つのOSSを取り上げて、それについて片杉さんとヘンテコで技術的なところも深掘りしながら話をしていく番組になっています。
今後もその名の通りヤオヨロズのOSSを取り上げていきたいなと思ってますので、ぜひお聞きのプラットフォームでフォローと高評価のほうをお願いします。
またですね、このOSSについても取り上げてほしいなどありましたらコメントやXなどで教えていただけると嬉しいです。
33:02
番組についての感想もお待ちしております。
Xなどでつぶやく際はハッシュタグヤオヨロズのOSSをつけてくれると非常にありがたいです。
それでは今回もありがとうございました。
ありがとうございました。
