F5、NGINXの開発チームをロシア国外へ移転させたことを報告。開発を立て直しリリースサイクルも元通りに NGINX（エンジンエックス）はオープンソースで開発されているWebサーバとしてもっとも人気のあるソフトウェアの1つです。その開発者であるIgor Sysoev（イーゴリ・シソエフ）氏がロシアの首都モスクワに住んでいたことなどにより、NGINXの開発はロシアの首都モスクワを中心に行われていました。 そのロシアは現在、ウクライナへの武力侵攻に反対する西側諸国による厳しい経済制裁下にあり、多くのIT企業もロシアにおける活動を停止しています。 2019年にNGINX社を買収し現在NGINXの開発元となっているF5も、ロシアにおける営業活動とNGINXオープンソースプロジェクトへの貢献を停止したことを、3月15日付けのブログ「Standing Firm in Support of the Pe
(Also published on my blog at robinwinslow.uk) Update: The default used in the official nginx docker image was changed from SIGTERM to SIGQUIT in November 2020, so this should no longer be an issue for Docker or Kubernetes users. nginx is a very popular web server. It may have just become the most popular web server – Netcraft’s October survey found nginx had 33% market share. This may be thanks t
世界中のウェブサービスで利用される無料かつオープンソースのWebサーバー「nginx」を開発するNGINXがロシア警察からの強制捜査を受けた ことがわかりました。この背景には、「ロシア企業がnginxの所有権を主張している」という問題があるとのこと。従業員による情報から、警察によって従業員が拘束され、機器が押収されたことも明らかになっています。 Rambler заявила о правах на Nginx – Бизнес – Коммерсантъ https://www.kommersant.ru/doc/4190259 Telegram: Contact @thebell_io https://t.me/thebell_io/4311 Russian police raid NGINX Moscow office | ZDNet https://www.zdnet.com/ar
2020/060/01 追記 nginx公式版が提供されました。こちらを御覧ください asnokaze.hatenablog.com NginxをHTTP/3対応させるパッチがCloudflareから提供されました (CloudflareのHTTP/3ライブラリ Quicheを利用しています。現状ではHTTP/3ドラフト23版の対応になります) github.com 基本的に、書いてるとおりにやればビルドできるのですが、無事HTTP/3しゃべるところまで確認できました ビルド rustインストールしておく $ curl https://sh.rustup.rs -sSf | sh $ source $HOME/.cargo/env書いてあるとおり $ curl -O https://nginx.org/download/nginx-1.16.1.tar.gz $ tar xzvf ngin
Announcing gRPC Support in NGINX ということで、nginx 1.13.9 で gRPC サポートが入り、HTTP と同じように gRPC ストリームを扱えるようになるようです。めでたい！ grpc_pass ディレクティブが新規に実装され、grpc:// と grpcs:// なバックエンドに対してリバースプロキシを行えるようになるようです。これを使って、 TLS 終端を nginx にやってもらったり 複数のバックエンドを置いて柔軟にロードバランスしてもらったり 同一のエンドポイントに複数 gRPC service を設定して、nginx にルーティングしてもらったり などの設定をすることが可能になるようです。 まだ正式にリリースされているわけではないので、今回は HEAD を持ってきて、リリースに載っている例を試してみます。 下準備 今回は適当に EC2
ただ、レスポンスを動的に組み立てるだけの話です。 botではない、単発のSlackのスラッシュコマンド(Slash Commands) 一応簡単に説明しておきます。スラッシュコマンドとは、/foo [text]のように、Slackのチャンネルで頭にスラッシュをつけて入力することでなにかしら処理をしてもらうためのシンタックスです。 Slash Commands | Slack さてこれ、一見Slack Applicationか、botフレームワークの知識が入りそうですが、プリセットのAppSlash Commandsを使えば次のようなゆるゆる仕様で取り扱うことができます。 plain/textでレスポンスが来たら、Bodyをそのままチャンネルに投稿する。 application/jsonでレスポンスをしたら、Bodyをパースして規定の形式でチャンネルに投稿する。 HTTP 200 以外のレス
CentOS6.7上にnginxでSSL設定する際にHTTP/2も設定してみましたが、Google ChromeではHTTP/2が有効にならずとても大変だったので今回の手順を記録します。 追記 2016/09/05 nginx stable(1.10以下)でHTTP/2を利用する場合、iOS SafariでPostする場合にエラーが発生する場合があります。後述参照。 追記 2016/09/30 mainlineバージョンをSRPMからビルドできました。(コメントありがとうございます。) 追記 2017/12/02 nginx側の記事でNPN/ALPN対応表（引用）更新しました。 追記 2017/12/02 各種ブラウザのNPN非対応を追記しました。 Google ChromeでHTTP/2が有効にならない理由 Google Chrome51(2016/4)で SPDY/3.1,NPNが削除
ホスティング事業部の CTL(Chief Technical Lead)の@pyamaです。本記事では先日盛大にリリースいたしましたロリポップの無料独自SSL機能の裏側について関わったメンバーのリレー形式で紹介したいと思います。 Let's Encrypt提供の背景 ロリポップ！のディレクターをしています@fuchinoです。ロリポップ！のリブランディングプロジェクトやプロモーション、プロダクト周り、イベントなどを担当する、ディレクターという名の何でも屋です。 Let's Encrypt提供の背景について、少し書かせていただきます。 2014年ごろから、急激に独自SSLの需要が増加しました。Googleが常時SSL化への取り組みを強化し、推奨したことが大きな理由です。2016年、Let's Encryptが正式に提供開始されてからは、その流れは一気に加速します。 ロリポップ！では、もともと
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
フリーマーケットサービスのメルカリで個人情報が流出する事故が起こった。iOS/Androidアプリ版ではなくWebアプリ版で起こった。あるユーザーが自分の情報を表示しようとすると、他のユーザーの情報が表示されてしまうというものだ。 第三者の情報を閲覧できる状態になっていた可能性があるユーザーは5万4180人。このうち、住所・氏名・メールアドレスが見える状態になっていたユーザーは2万9396人だという。 第三者の情報を閲覧できる状態になっていた可能性があるユーザーでも、特定の条件を満たさなければ、実際には住所・氏名・メールアドレスが見える状態にはならなかったという。メルカリは、そうした条件には二つのケースがあるとしている。 第1のケースは、障害が発生した2017年6月22日の9時41分から15時5分の間にWeb版メルカリにログインしてアクセスし、そのときに閲覧したページがキャッシュサーバーに
StreamモジュールとMailモジュールについては、nginxバイナリに静的にビルドされて組み込まれています。 なお、nginxバイナリと動的モジュールの両方とも、後述するconfigure時のオプション「--with-compat」付きでビルドされています。 nginxバイナリとモジュールのsignatureが異なると動作しない 動的モジュールが実装された当初から「nginxバイナリとモジュールのsignatureが異なると動作しない」という制約があります。 このことについては昨年の記事「nginx-1.9.11で動的モジュールをサポート」において次のように説明しました。 nginxバイナリと異なる環境でビルドされた動的モジュールを組み合わせて動かすことはできません。 これにより困ることの例としては、公式サイトやディストリビューションからnginxのRPMパッケージをインストールした環
worker_processes ワーカーのプロセス数。ドキュメントを意訳するとこんな感じ。 worker_processes の最適値な、いろんな要素が複雑に絡み合っていて複雑なんや。CPU のコア数とか、負荷のかかり方とか、とにかく複雑なんや。困ったら CPU のコア数とかにしとけばええんちゃうか？あとな、auto にしとくとよしなに設定してやるやで。 よしなに…？ よしなにの中身を知りたかったのでググる "よしなに設定する" としか書いてない ソースをよんだ（怒） https://github.com/nginx/nginx worker_processes で grep それっぽいのでてきた。 src/core/nginx.c if (ngx_strcmp(value[1].data, "auto") == 0) { ccf->worker_processes = ngx_ncpu
nginxの記事を書くのは久しぶりの滝澤です。 nginxにApache HTTP Serverの動的共有モジュール（Dynamic Shared Object）（DSO）のような機能が欲しいと思っていた人も多いでしょう。筆者もそうです。秘伝のタレのようなビルド用のスクリプト（実際はRPMパッケージのSPECファイル）を保守し続けるのは辛いなと思っていました。 そのような方々に朗報です。2016年2月9日にリリースされたnginx-1.9.11において動的モジュール（Dynamic Modules）がサポートされました。 しかし、Apache HTTP ServerのDSOと比べると、現時点ではまだ制約があります。 本記事ではnginx-1.9.11における動的モジュールの説明と制約について説明します。 注: 2017年2月22日にフォローアップ記事「nginxの動的モジュールの最新状況（
nginxのステータスコード444 nginx独自のステータスコード444は、レスポンスヘッダを返さずにコネクションを切断できる。レスポンスヘッダを返さないので、ステータスコード444をクライアントが受け取ることはない。 http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return The non-standard code 444 closes a connection without sending a response header. DoS攻撃など、特定条件のアクセスをBANするときに、なるべく計算機リソース消費を抑えたいときに使えるはず。 403を返すときなどと比べて、レスポンス送信のためのCPUコストを節約 403を返すときなどと比べて、レスポンスヘッダ分のネットワーク帯域を節約 HTTP Keepalive
Nginxは5月24日、オープンソースのWebサーバー「Nginx」の最新開発版「Nginx 1.11」をリリースした。 NginxはHTTP・リバースプロキシサーバー、メールプロキシサーバー、汎用のTCP/UDPプロキシサーバーなど多彩な機能を持つWebサーバー。WindowsおよびMac OS X、Linux、FreeBSDなどの各種UNIX系OSなどで利用できる。ライセンスは2条項BSDライセンス。 Nginx 1.11は積極的に開発が進められる「メインライン版」との位置付けで、新機能を含むマイナーリリースが4～6週間周期でリリースされる。Nginxの安定版は4月末に公開された1.10となる。 proxy_bind、fastcgi_bind、memcached_bind、scgi_bind、uwsgi_bindの各オプションで 「transparent」パラメーターが利用できるように
先日発売された nginx 実践入門を読みながら、おー、なるほど、と思ったところをメモもしていたので、それを読書メモとして晒す。ちなみに当方、nginx 初心者。（見よう見まねで conf を書いたことがある、くらい。） なるほどポイント nginx 起動時に sudo が必要な理由 設定ファイルの include の注意点 バーチャルサーバで使用するホスト名について worker_processes ディレクティブには auto が指定できる sendfile ディレクティブの効果 location ディレクティブについて HTTP/2 や SPDY の nginx での設定について リクエストボディに関する設定 client_max_body_size client_body_buffer_size client_body_temp_path Unicorn と nginx との組み合
インフラチームの@cubicdaiyaです。今回はnginxのビルドプロセスを自動化するツールであるnginx-buildについて紹介します。 メルカリとnginx メルカリでは多数のnginxを活用し、高速なレスポンスやサービスの安定稼働を実現するのに重要な役割を果たしています。実際の活用事例には、 リバースプロキシ、L7ロードバランサ TLSターミネーション、SPDYゲートウェイ 静的コンテンツの配信、キャッシュ ngx_dynamic_upstreamを用いたゼロダウンタイムデプロイメント ngx_lua(OpenResty)を用いたサービスコンポーネントの開発 などが挙げられます。そしてメルカリではこれら多数の用途のnginxをnginx-buildでソースコードからビルドしています。(OpenResty以外は合わせてrpm化も行っています) 既存のビルド済みパッケージの利用とソー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
