HTTP/2 の導入に関して

Question

HTTP/2 対応サーバを以前立ち上げていたのですが、ブラウザ側の対応が HTTP/2 TLS+ALPN(間違えてました＾＾；修正前：over TLS) の方向で推移したため、一旦諦めた過去があります。

諦めた当時、HTTP/2 TLS+ALPN(修正前：over TLS) に対応していくにはコンパイルが必須の状態で、コンパイルは経験したことがなかったため、断念しました。

現在の状況も変わっていないと思いますが、再チャレンジしてみたいと考えています。

・導入するにはまだWebサーバのコンパイルが必須でしょうか？
（yumで導入は出来ないですよね？）
・一般的にどのようにアップデートしていくのでしょうか？

導入しようとしている環境は、EC2上に AmazonLinux + nginx を考えています。

コンパイルにすごく時間がかかるといった記事と、運用時のアップデート方法に不安があるため、すでに経験されている方がいればと思い質問してます。

よろしくお願いいたします。

Answer 1

nginxであれば、nginxのリポジトリに、HTTP/2対応の1.10系列、1.11系列がありますので、自力でのコンパイルは不要です。

ただし、Amazon Linuxもそうですが、OpenSSLが1.0.1の環境だと、NPNによるHTTP/2しか動きません。SafariやFirefoxなら特に問題ないのですが、Google ChromeはNPNによるHTTP/2を早々に切り捨てている（ALPNのみ対応）ため、簡単には対応できません。

Comments

[退会済みユーザー]

ありがとうございます。
nginx リポジトリのモノを過去に使用していました。

その際、ある日を堺に Chrome で HTTP/2 が使えなくなった経緯がありました。
（過去のドタバタ：https://teratail.com/questions/39382）

質問の重要な部分を間違えてしまいましたが、ブラウザが ALPN のみ対応に舵を取る可能性があると判断して、導入を諦めたのですが、改めてチャレンジしてみようと考えています。

頂いたアドバイスから、やはり自力コンパイルが必須なのだと思いますが、実際運用するとなるとどのような手順が必要となるのでしょうか？
コンパイルと OpenSSL 1.0.2 の導入（こっちも面倒くさそう。。。）は試行錯誤すればいいかとも思っていますが、運用に入ってからの update 方法がわかっていないため、不安に思っています。

アドバイスいただければ幸いです。

[maisumakun]

nginxとOpenSSLを固めてDockerなどの仮想環境に入れれば、環境構築に失敗しても、その外に影響を及ぼすことはありませんし、アップデートのときにも「事前に環境を作る」→「テストする」→「コンテナ入れ替え」で片付きます。OS付属のOpenSSLを入れ替えるのはかなりアクロバティックになるので、おすすめできません。

[退会済みユーザー]

使用しているインフラがEC2なので、IPアドレス付け替えちゃえばいいかなぁとこのアドバイス見て思いました。
そうなると結構ハードルが下がった気がします。ありがとうございます。

> OS付属のOpenSSLを入れ替えるのはかなりアクロバティックになるので、おすすめできません。

こちらはどういった意味でしょうか？OpenSSL 1.0.2 を普通に導入しようとすると入れ替わっちゃうから気をつけなさいよ！という理解で正しいですか？

[maisumakun]

OpenSSLに依存するコンポーネントが多数ある上に、OpenSSLはセキュリティ上の理由もあって旧バージョンとインターフェースが変化することもあるので、OS付属のをアップデートしてしまうとうまく動かないプログラムが出るなど、トラブルになりがちです。OS標準のとは別な場所にOpenSSL 1.0.2を入れて、nginxはそちらとリンクする形でビルド、というような方がいいです。

[退会済みユーザー]

理解しました。ありがとうございます。

Answer 2

新しめの仕様を使いたければ、ソースからコンパイルするのが当然です。またTLSのようにセキュリティに気をつかうものでは、セキュリティホールへの対応などでパッケージ化を待っていられないこともあるので、ソースからコンパイルすることは多いです (個人の経験として)。

コンパイルは簡単です。ソースアーカイブを入手して、展開し、同梱されているドキュメントを読めばやり方が書いてあります。書いてあることをひとつひとつこなしていけば、必ずできます。

コンパイルにすごく時間がかかるって、どのくらいかかりますか (3日くらいですか?)。その間ほかの仕事ができないわけでもないでしょう。それに、OSのインストールなどはこれまで何回も (何10回も、何100回も) やってきたはずです。時間がかかるからやめとこう、とはならなかったでしょう。

いったん手順を確立すれば、あとは同じことの繰り返しです。それに最初に書いたように、ソフトウェアのポテンシャルを引き出すためにはコンパイルが必要です。

迷っているくらいなら、やってみればいいじゃないですか。やってみろー。こっちへ来～い。お前も仲間になれ～～。

(追記)

コンパイルとインストール (アップデート) は別の操作です (典型的な例では、前者は「make」、後者は「make install」と別のコマンドを打ちます)。後者を実行してはじめて、実行ファイル等が指定の場所にコピー (アップデート時は上書き) されます。

本番機上でコンパイルも行う場合は、平常稼働中にコンパイルをすませておけばいいです。メンテナンス時間帯にサービス停止 → インストール (アップデート) → 動作確認 → サービス再開という流れになるでしょう。

アップデート失敗時の切り戻しについては、事前にアップデート対象の実行ファイル等をバックアップしておいて書き戻すことが考えられます。またほかの方法として、バージョン毎に別のディレクトリ (例: /usr/local/nginx-1.11.9) にインストールし、実際に使うバージョンにシンボリックリンク (例: /usr/local/nginx) を張って、実行ファイルを指定するときはシンボリックリンクのパスを使う、といった工夫も考えられます。こうすれば、切り戻しはリンク先を旧のディレクトリに戻してサービス再起動するだけでできます。

Comments

[退会済みユーザー]

どちらかというとメンテナンス面に不安を覚えています。

導入は試験環境整えて、試行錯誤すれば良いかなぁと思ってますが、運用をどのように行えばよいか経験がないので、アプデートに自信がないというか＾＾；

よく分かっていないのですが、バイナリファイルを一つ入れ替えるとかで対応できるのでしょうか？コンパイルの環境を一つ持って、そこでバイナリを作り、本番環境のそれと差し替えるといった作業ならなんとかなる気もしてるんですけど、本番環境でコンパイルもしないといけないとなると、コンパイルに時間がかかるのはちょっと運用していけないと思ってます。
夜中にコンパイル開始して、コンパイル完了を監視して、正常確認をするとか、寝落ちの可能性100%ですｗ

コンパイル自体はちょっと興味があるので、結論がどうあれ、しばらくしたら手を出してみようと思ってますが、運用面でアドバイスが有れば先に教えていただきたいです。

[ikedas]

3日もかからないです(^^)。いまのハードウェアでOpenSSLやnginxだけなら、makeは時間がかかっても分単位でしょう。

メンテについて追記しておきました。

[退会済みユーザー]

「make」と「make install」の混同が不安の元だったみたいです。理解できました。
運用も回せる気がしてきたので、やってみます。
ありがとうございました。