まとめの後に追記を追加。 OpenResty は Nginx をダイナミック・リバースプロキシーサーバに仕立て上げたり、テンプレートエンジンを仕込んでバックエンドの JSON API サーバにリクエストしたレスポンスデータを元にレンダリングして返したり、と色々便利に使えるお気楽ウェブアプリ環境なのだけれど、画像処理系のCPUに負荷のかかりそうなものでもお気軽にいけるのかなとふと疑問に思ったの実験してみる。 OpenResty や LuaRocks のインストールは homebrew でさっくり入るし、windows はパソコン初心者並の知識しかないのではしょる事にして、とりあえずテーマを決める。 「nginx 画像処理」でググってみると「簡単!リアルタイム画像変換をNginxだけで行う方法 | cloudrop」ってのが一番上にあったり「S3をバックエンドにngx_small_lightで
Kong を使った Microservices Architecture API Gateway Pattern の実現方法Dockermicroservices この記事は、Kong - API Gateway Pattern速習会@Wantedlyの資料として作られたものです。 サービスが大きくなるとやりたくなってくること より高速な実装に置き換えたい APIを複数のサービスに分けて開発したい マイクロサービス化 何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界 「明確な」境界が必要 名前空間やスコープなど、プログラミング言語でも使用してい
Plug について説明します。 Plug とは Elixir の HTTP サーバの実装の1つです。 内部では Erlang の信頼できる HTTP サーバ Cowboy を利用してますが、アダプターを切り替えることで他のライブラリにもできます。1 2017年12月19日現在、Cowboy 2 に対応した 1.5.0-rc.0 が出ています。 が、rc.0 なので、ちゃんとした 1.5.0 がリリースされるまでは 1.4.3 を使っておくのが無難でしょう。 Phoenix との違い Phoenix は Plug を利用して作っています。 Phoenix に渡ってくる conn は Plug.Conn なので、Phoenix を弄るには Plug の知識が必要になってきます。 また、Phoenix はプラグのインターフェースである init/1 と call/2 をうまく扱えるようにしている
-module(httpd_tcp_listener). -export([start_link/0]). start_link() -> Pid = spawn_link(fun init/0), {ok, Pid}. init() -> Port = 8888, Backlog = 10244, Options = [binary, inet6, % support both ipv4 and ipv6 {active, false}, {reuseaddr, true}, {backlog, Backlog} ], {ok, Listen} = gen_tcp:listen(Port, Options), accept(Listen). accept(Listen) -> case gen_tcp:accept(Listen) of {ok, Socket} -> {ok, Pid}
https-portal があまり知られてないようなので紹介記事だけ書いとく。 https://github.com/SteveLTN/https-portal あなたがすでにhttpで動作するサービスのdockerコンテナを持ってるなら、こいつを docker-compose に加えるだけで https 対応は完了。 え? 加えるだけで完了。 まじです。 https-portal は何をするものか 基本的には https のリクエストを受け取り、他のコンテナの http へ転送するリバースプロキシとして動作する nginx である。 ところで https を提供するには証明書の取得、設定などが必要だが、こいつはそれを全自動でやってくれる。 え? 証明書の取得、設定を全自動でやってくれる。 まじです。 期間延長も自動でやってくれるらしい。 まあとにかく便利なので、 Let's encryp
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy(同一生成元ポリシー)によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので(自分的)これが決定版! という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio
はじめに 数年にわたり、PadrinoやGrapeといったWebアプリケーションフレームワークのルーティングを改善してきた自分が、今年の11月頃から、従来とは異なるアプローチでHTTPルーティングの高速化について検証したので、その結果について解説する。 なおこの記事では、その過程でC++で基数木を実装し、それを用いることにより、Rubyで高速なHTTPルーティングを実現した事例について、順を追って解説する。 tl;dr C++で基数木(Radix Tree)を表現するr2reeというライブラリを書いた。 r2reeのRuby向けバインディングであるr2ree-rubyを書いた。 r2ree-rubyを用いてRuby上でHTTPルーティングを行う pendragon-radixを書いた。 多分、Rack準拠のルーティングライブラリでは最速。 結果、Sinatraなどで用いられる正規表現+線形
私同様、慣れていない方が何らかの参考にしていただくとか、利用していただければ幸いです。 ちなみにTinyHTTPServer.swiftを見てもらうと分かりますが、HTTPとしてはかなりナメた実装なので、あくまでも参考として下さい(苦笑) 評価方法 動かして戴ける方のために、簡単に動かし方を説明します。まずはgitから落とすかzipを解凍します。 URL https://github.com/gdaigo82/iosSampleServer 次に適当なJPEG画像をsample.jpgとして用意し、それをgdSampleServer/gdSampleServerフォルダに入れます。 その後、xcodeでビルドし、実機もしくはiOSシミュレータで起動してください。例によってですがプロ生ちゃんが出てきます。 #ちなみに実機ですと、本当は3G回線のIPも出ます(つまり2行表示されます)。上の図で
はじめに 先日スタック・オーバーフローでこんな質問に回答しました。 webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません 質問者の方はwebサーバー、アプリケーションサーバー、Rack、Unicorn、Pumaと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探していたところ、以下の記事を見つけました。 A web server vs. an app server - Justin Weiss スタック・オーバーフローでは記事の一部を抜粋して「ざっくり翻訳」したのですが、それだけで終わらせるのはもったいない気がしたので、Qiitaには全文を翻訳して載せておこうと思います。 これを読むと、あなたもwebサーバーとアプリケーションサーバーの違い
nginx + Rails + unicorn の環境で、レスポンスタイムが最大 120 秒の外部 API を実行した際、 Rails ( nginx ) からはタイムアウト ( 60秒 ) が返ってきているにもかかわらず、 実行された外部 API 側では処理されてしまうという現象が発生したので、タイムアウト値を設定した。 unicorn 側は、外部 API の 120 秒から余裕を持って 150 と設定 worker_processes 4 timeout 150 root = File.expand_path(File.dirname(__FILE__) + '/../') listen '/tmp/hoge.sock' pid '/tmp/hoge.pid' stderr_path "#{root}/log/unicorn_error.log" stdout_path "#{root
HAProxy1とは何か? から始まり、基本的な使い方までを調べました。 HAProxyとは 多機能なプロキシサーバです。ソフトウェアロードバランサの一種でもあります。古くから開発が続けられ、非常に高速かつ堅牢で信頼性が高いことを売りにしているようです。 HAProxyが何であって何でないかは、 ドキュメントに箇条書きで記載 されています。 ざっくりまとめると、こんな感じのことが書かれています。 TCP接続のプロキシとして動作させ、アクセス経路を設定することができる HTTPリバースプロキシとしての機能を持ち、ルールに従ってリクエストを別のサーバに渡すことができる このとき、URLやヘッダの書き換えも行える SSLやHTTP圧縮を肩代わりできる TCP/HTTPの正規化器(normalizer)となる 不正なトラフィックからの防護を提供する 負荷分散機能を提供する ロギング機能を持つので、
Nginx でリバースプロキシをする場合に、どうやってセキュアなリクエストであることをアプリケーションに伝えるか?のメモ。 Nginx - Rails の場合 NginxでリバースプロキシするときにもSSLはNginxで処理させる場合が多く、プロキシされるアプリケーションサーバにはSSLが解かれた状態でリクエストが届く。 そのため次のヘッダをNginxでつけるように設定する必要がある。 server { listen 80; server_name hoge.com; location / { proxy_set_header X-Real-IP $remote_addr; index index.html index.htm; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $pro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く