Varnish 4.0 on CentOS 6.5(EC2/HVM) | iret.media
1.EC2を起動する いずれもAMIはマッツォさんのCentOS6.5(HVM)、Tokyoリージョンなので ami-7fa6fe7e CentOS6.5 HVM AMI (SR-IOV対応) – aws memo Varnishのオリジンサーバーの起動 Varnish Cache用のサーバーの起動 2.オリジンサーバーの構築 この2はオリジンの話なので読み飛ばしてもらってもOK 以下を参照 チュートリアル: LAMP ウェブサーバーのインストール – Amazon Elastic Compute Cloud # yum update # yum grouplist # yum groupinstall -y "Web Server" "PHP Support" # yum install -y php-mysql # service httpd start # chkconfig htt
cloudpackブログ - VarnishでHTTPのアクセス(S3)をHTTPSのアクセス(S3)にリダイレクト
以前紹介した下記記事の合わせ技になります。 Varnishでリダイレクト専用Webサーバの構築 Varnish経由でS3のコンテンツをPOSTで取得(Facebookアプリ用) 概要は、このようになります。 設定ファイル(/etc/varnish/default.vcl)は、以下のようになります。 backend default { .host = "localhost"; .port = "80"; } sub vcl_recv { if(req.http.host == "www.suz-lab.com") { if(req.http.X-Forwarded-Proto == "https") { set req.backend = suzlab; set req.http.host = "www.suz-lab.com.s3-website-ap-northeast-1.amazon
cloudpackブログ - 突然Varnishが起動しなくなった場合
以前は動いていたVarnishを久しぶりに再起動したところ、起動しなくなってしまいました。 ログを確認してみたところ、ログには原因らしいエラーが出力されていなかったので、下記のように直接コマンドラインでVarnishを起動してみると、バックエンドホストの名前解決ができなくなっていたのが原因でした。 # varnishd -f /etc/varnish/default.vcl Message from VCC-compiler: Backend host '"xxx.xxx.xxx"' could not be resolved to an IP address: Name or service not known (Sorry if that error message is gibberish.) (input Line 68 Pos 13) .host = "xxx.xxx.xxx";
cloudpackブログ - Varnishでwww.suz-lab.comをsuz-lab.comにリダイレクト
以前、Varnishでリダイレクト専用Webサーバの構築の記事で、suz-lab.comをwww.suz-lab.comにリダイレクトする方法を紹介しましたが、 今回は、その逆のwww.suz-lab.comをsuz-lab.comにリダイレクトする方法を紹介します。 上記の設定は、設定ファイルdefault.vclのvcl_errorで行い、具体的には下記のようになります。 sub vcl_error { if(req.http.host == "www.suz-lab.com") { set obj.http.Location = "http://" regsub(req.http.host, "www.(.*)", "1") req.url; set obj.status = 301; } return(deliver); } 近頃、S3への小細工は、全部Varnishで行っています
cloudpackブログ - 勉強会資料『S3 & ELB & Varnish』を公開しました
本日（11月10日）に開催されるJapan AWS User Group (JAWS-UG) – Kyoto勉強会 第2回で、 CTOの鈴木（@suz_lab）が登壇し、LTを行います。 今回のLTでは、cloudpackが提供する便利なツールcloudpack Toolsで提供している、プロキシサービスとリダイレクトサービスで利用している技術について紹介します。 Amazon S3とロードバランサー（ELB）、キャッシュサーバのVarnishを組み合わせることで、 下記のようなサービスを実現しています。 ○S3 & ELB & Varnishの利用例 S3のHTTPSでの独自ドメイン（S3（独自ドメイン設定）でHTTPSを利用） S3へのPOSTアクセス（FacebookアプリのコンテンツをS3に配置） S3へのレスポンスに独自ヘッダ（S3で携帯サイト(Softbank)の著作権保護）
cloudpackブログ - cloudpackが提供するVarnishを利用したサービス
cloudpackには「リダイレクトサービス」と「プロキシサービス」という 付加サービスがあり内部的にはVarnishを利用しています。 リダイレクトサービスとは、下記のようにwww無しのドメイン名(suz-lab.com)のみで アクセスしてきたHTTPリクエストを、wwwの付いたURLにリダイレクトするサービスです。 リダイレクトサービスは、ELB、S3、CloudFrontを独自ドメインで利用する場合に、DNSに対して CNAMEレコードで設定する必要があるのですが、ドメイン名(例：suz-lab.com)に対しては CNAMEが利用することができないので、その対策としてのサービスです。 (現在、ELBに関してはRoute53で対応することができます。) そして、Varnishでの実現方法は、Varnishでリダイレクト専用Webサーバの構築の記事で紹介した通りになります。 プロキシ
cloudpackブログ - Varnishでキャッシュ期限を指定
vcl_fetchで下記のようにすることで、Varnishでキャッシュ期間を5分に設定することが可能です。 尚、vcl_fetchはオリジンからコンテンツを取得した後に呼ばれる関数です。 sub vcl_fetch { unset beresp.http.expires; set beresp.http.cache-control = "max-age=300"; set beresp.ttl = 300s; } 上記では、まずオリジンからのExpiresヘッダを削除し、Cache-Controlヘッダを300秒(5分)にし、最後に、キャッシュ自体の期限(TTL)も300秒(5分)にしています。 以上で、5分間はクライアントもしくはVarnishのキャッシュが利用されるようになるはずです。 こちらの記事はなかの人（suz-lab）監修のもと掲載しています。 元記事は、こちら
cloudpackブログ - Varnishでキャッシュのヒット状況をヘッダに追加
Varnishでキャッシュのヒット状況をヘッダに追加するには、Adding a header indicating hit/missで紹介されているようにすればできます。 具体的には、下記のようになります。 sub vcl_deliver { if(obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } ヘッダを確認することで、キャッシュ上のコンテンツかどうか判断することが可能です。 こちらの記事はなかの人（suz-lab）監修のもと掲載しています。 元記事は、こちら
cloudpackブログ - MonitでVarnishの監視
VarnishでELBヘルスチェックに対応させるで紹介しているのように、Varnish単体で/healthcheck.txtにアクセスできるのが前提となります。 この状態で、下記のような/etc/monit.d/varnish.confで実現できます。 check process varnish with pidfile /var/run/varnish.pid start program = "/etc/init.d/varnish start" stop program = "/etc/init.d/varnish stop" if failed port 80 protocol http request /healthcheck.txt then restart if 5 restarts within 5 cycles then timeout これにより、あとはMonitを再起動
cloudpackブログ - Varnishでx-jphone-copyrightヘッダにno-transferとno-peripheralを指定
前回、VarnishでS3のコンテンツにx-jphone-copyrightヘッダを付与でno-storeを付与したのですが、今回は、no-transferとno-peripheralの二つを指定してみました。 各役割は基本的に下記のようになります。 no-store: 「コピー」と「メール添付」と「外部転送」の禁止 no-transfer: 「メール添付」の禁止 no-peripheral: 「外部転送」の禁止 Apacheの場合は、httpd.confで下記のように指定すれば大丈夫です。 (二つ目の指定がappendになっているのがポイントです) Header set x-jphone-copyright no-transfer Header append x-jphone-copyright no-peripheral ... しかし、Varnishにはappendのようなものがあり
cloudpackブログ - VarnishでS3のコンテンツにx-jphone-copyrightヘッダを付与
携帯サイトの著作物保護 ～画像転送禁止を厳しく設定する～の記事で紹介されているように、SoftBankの携帯で画像転送の禁止を行うには、画像ファイルのレスポンスヘッダにx-jphone-copyrightを付与する必要があります。 しかし画像をS3に置く場合は、S3はx-jphone-copyrightのようヘッダを付与することができないので、Varnishなどのプロキシーを経由する必要があります。 例として、s3.suz-lab.comでアクセスすることができるS3に対して、softbank.suz-lab.comでアクセスすることができるVarnish経由で上記のS3にアクセスするには、下記のように設定ファイル(/etc/varnish/default.vcl)を記述すれば大丈夫です。 backend default { .host = "localhost"; .port = "80
cloudpackブログ - VarnishでGETメソッド以外をキャッシュしない方法
システム移行の案件等、プロキシー型のCDNを動作確認するためにVarnishでエミュレートすることが度々あります。 今回は、その際に、CDNによりますがGETだけキャッシュして、それ以外は、そのままオリジンサーバに通してしまうものもあり、その辺りをVarnishでどのように実現するかについて紹介します。 方法としては、下記のように設定ファイルを変更することで実現可能です。 vi /etc/varnish/default.vcl sub vcl_recv { if(req.request == "GET") { return (lookup); } return (pass); } lookupはキャッシュからコンテンツを探し、passは、そのままオリジンサーバにパスするという挙動になります。 上記をまとめますと、GETメソッドの場合はキャッシュからコンテンツを探し(lookup)POSTの
cloudpackブログ - Varnish経由でS3のコンテンツをPOSTで取得(Facebookアプリ用)
S3のコンテンツにPOSTでアクセスできないで紹介した通り、FacebookアプリのコンテンツをS3に置こうとすると、FacebookはS3にPOSTでコンテンツを取得しにいくので、うまくいきません。 そこで、一旦FacebookはVarnishにアクセスし、VarnishがPOSTをGETに書き換え、S3からコンテンツを取得できるようにしてみました。 FacebookからS3までのコンテンツ取得経路は下記となり、 Facebook → ELB(www.suz-lab.com) → Varnish → S3(origin.suz-lab.com) 設定ファイル(/etc/varnish/default.vcl)は次の通りになります。 backend default { .host = "localhost"; .port = "80"; } sub vcl_recv { if (req.u
cloudpackブログ - VarnishでELBヘルスチェックに対応させる
バックエンド関係無しに対応させる方法になります。 とはいえ、Varnishで、ELBにてヘルスチェック用に指定したパス(/healthcheck.txt)が、ステータス200で返るようにすれば大丈夫です。 設定ファイル(/etc/varnish/default.vcl)は下記のようになります。 backend default { .host = "www.suz-lab.com"; .port = "80"; } sub vcl_recv { if (req.url == "/healthcheck.txt") { return (error); } return (lookup); } sub vcl_error { set obj.http.Content-Type = "text/plain; charset=utf-8"; if (req.url == "/healthcheck.
cloudpackブログ - Varnishのログを確認
Varnishのログはファイルではなく共有メモリに出力されるので、ログを確認するにはvarnishlogという専用のコマンドを利用します。 実際、ログは下記のように出力されます。 # varnishlog 13 SessionOpen c xxx.xxx.xxx.xxx 14608 :80 13 ReqStart c xxx.xxx.xxx.xxx 14608 472752705 13 RxRequest c GET 13 RxURL c /form.html 13 RxProtocol c HTTP/1.1 13 RxHeader c Host: ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com 13 RxHeader c Connection: keep-alive 13 RxHeader c Cache-Control:
cloudpackブログ - VarnishからオリジンサーバにHostヘッダを変更してアクセス
久しぶりになりますが、Varnishの記事です。 前回はVarnishでリダイレクト専用Webサーバの構築をご紹介しました。 今回は、単純なキャッシュサーバではありますが、オリジンサーバへのアクセス時に、ユーザーがリクエストした場合のHostヘッダではなく、任意のHostヘッダに変更してアクセスする設定になります。 ユーザーのリクエスト時のHostヘッダのままで、オリジンサーバ(origin.suz-lab.com)にアクセスする場合は、単純に/etc/varnish/default.vclを下記のように設定するだけで大丈夫です。 backend default { .host = "origin.suz-lab.com"; .port = "80"; } 但し、バーチャルホストの関係などで、Hostヘッダを変更してアクセスする場合は、下記のように、vcl_recvのreq.http.ho
cloudpackブログ - Varnishでリダイレクト専用Webサーバの構築
S3でWebサイトのホスティングをした時に、独自ドメインを利用しようとすると、DNSのCNAME設定の関係上、www.suz-lab.comなどのDNS名のみの利用しか出来ないため、suz-lab.comが宙ぶらりんになってしまいます。 もし出来るなら、suz-lab.comは、www.suz-lab.comにリダイレクトさせたいと思うので、リダイレクト専用のWebサーバをVarnishを利用して作ってみました。 (後でcloudpackのサービスとして公開する予定です。) 仕様は、任意のDNS名でアクセスすると、そのDNS名の頭にwww.を付けたURLにリダイレクトするものになります。 例えば、 suz-lab.comでアクセス → www.suz-lab.comにリダイレクト iret.co.jpでアクセス → www.iret.co.jpにリダイレクト というようになります。 リダイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
