[B! tips][cdn] ko-ya-maのブックマーク

最近知ったCloudflareで実はこんなこともできる集

Argo Tunnel Client(cloudflared)をngrokの代替として使う cloudflaredというArgo Tunnelクライアントを使えば、ngrokのようにローカルサーバを外部に公開することができる。 # localhost:8080 を公開する。実行後に表示されるURLを使ってどこからでもアクセスできる。 cloudflared tunnel --url http://localhost:8080 これだけならばわざわざ乗り換える理由にはならないが、ngrokでは有料でしか使えない機能も無料プランで使える。カスタムドメインの割り当て SSOによる認証 TCPのプロキシセキュアでDDNSのいらないVPNの構築例えば個人で自宅にVPNの環境を作る場合、ルーターのVPN機能を使うか、VPNサーバを立ててDDNSでドメインを自宅のグローバルIPに紐付けるといったや

ko-ya-ma 2021/10/28

リンク

Next.jsのmiddlewareはVercel以外でも問題なく使えるか

Next.jsでv12〜middlewareという機能が使えるようになりました。 middlewareに書いた処理はリクエストが完了する前に実行されます。Cookieの値に応じてルーティングを振り分けたり、Basic認証を導入したり等など、幅広い用途で使えそうです。 VercelとNext.jsの組み合わせが強いのは、VercelにNext.jsをデプロイするとこのmiddleware部分をEdge Functionsで捌いてくれるという点です。つまり、静的なページに対するリクエストに対して、オリジンサーバーに触れことなくmiddlewareを実行できるということです。 Vercel以外のプラットフォームだとどうなのかドキュメントには以下のような記載があります。 This works out of the box using next start, as well as on Edge

ko-ya-ma 2021/10/27

リンク

CloudFront + WordPress 構成の必須設定 | Oji-Cloud

概要はじめに本日は、AWS CloudFront + WordPress 構成を構築する上でハマった落とし穴をいくつかご紹介します。CloudFront + WordPress 構成を採用される方は、参考にして下さい。システム構成 Amazon Lightsailに、WordPress環境を起動しています。WordPressのバージョンは、5.6です。WordPressのフロントにCloudFrontを設置し、CloudFrontでSSLの終端を行っています。なお、今回ご紹介する落とし穴は、通常のWordPress環境およびWordPress Multisite環境の両方で発生することを確認しております。 siteurl がオリジン側のURLを向いてしまう説明 Amazon LightsailにWordPressのインスタンスを起動し、CloudFront のオリジンに設定してデ

ko-ya-ma 2021/06/21

リンク

CloudFrontで「Forward Cookies」を「All」にしている時に注意すべき点 | DevelopersIO

菅野です。先日、CloudFront経由でウェブページにアクセスした時に常に「X-Cache: Miss from cloudfront」となるので調査したところ、CloudFrontの「Behavior」の「Forward Cookies」が「All」になっている事が原因でした。今回はなぜ「All」だとキャッシュが使われなかったのか、CloudFrontにおけるcookieの注意点について書こうと思います。 webページを準備 EC2インスタンスを立ち上げ、apacheとphpをインストールします。 /var/www/html/index.phpを作成し、内容は以下にします。 GoogleAnalyticsもcookieを使うので検証の為に埋めました。 <?php setcookie( "cookie01", "value01" ); // setcookie( "cookie02"

ko-ya-ma 2021/06/09

cookieが原因

リンク

HTTPキャッシュ入門の入門 – cat /dev/random > /dev/null &

ローカル・経路上のキャッシュを併用しようキャッシュは再利用されるほどいいものです。サイトの規模にもよるのですが、ローカルと経路上のキャッシュはそれぞれ性質が異なるため、ブラウザキャッシュだけ適切に設定しておけば経路上では不要というわけではありません。ローカルキャッシュはキャッシュを持つクライアント自身がサイトを再訪する場合は有効ですが、キャッシュを持っていない新規クライアントには無効です。経路上のキャッシュは新規クライアントに対してもキャッシュを返すことができるため、例えばサイトへの流入が突然増えるといった事態でも対処がしやすいです。そのためコンテンツ次第ではありますが、ブラウザキャッシュのように特定のクライアントでしか使えないprivate cacheにするよりも、効率を考えてローカル・経路上のどちらでもキャッシュができ、多数のクライアントで共有できるshared cache

ko-ya-ma 2021/05/06

リンク

オリジンを S3 とした CloudFront に対して、存在しないオブジェクトへアクセスした際の HTTP ステータスコードが 403 Forbidden になったときの対処方法 | DevelopersIO

困っていた内容オリジンを S3 として CloudFront を使用している。存在しないオブジェクトにアクセスすると HTTP ステータスコード 403 Forbidden が返ってきてしまう。これを、HTTP ステータスコード 404 Not Found を返すようにしたい。どう対応すればいいの？オリジンとして設定している S3 のバケットポリシーに、s3:ListBucket アクションを許可する設定を追加します。また、Resource 句にバケットのルートを追加します。設定前 { "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:

ko-ya-ma 2020/05/15

リンク

実践！ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)

CDNが単一障害点にならないようにするためにヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。ただ、どんな事情であれ、障