コンテンツにスキップ

Varnish#

Drupalをバニッシュリバースプロキシと一緒に使用することをお勧めします。Lagoonは既にバニッシュが設定されているvarnish-drupal Dockerイメージを提供しています。Drupal Varnish config付きです。

このバニッシュ設定は以下のことを行います:

  • Drupalのセッションクッキーを理解し、認証されたリクエストのバニッシュキャッシュを自動的に無効にします。
  • アセット(画像、CSS、JSなど)を1ヶ月間自動的にキャッシュし、このヘッダーもブラウザに送信します。これにより、ブラウザもアセットをキャッシュします。これは認証されたリクエストと認証されていないリクエストの両方で発生します。
  • Drupal 8のパージモジュールで使用されるBANおよびURIBANをサポートしています。
  • URLパラメータからutm_とgclidを削除し、Google Analyticsのリンクが複数のキャッシュオブジェクトを生成するのを防ぎます。
  • その他の多くの良い点 - drupal.vclをチェックしてみてください。

Drupal 8との使用#

要約: 我々の例のレポジトリでdrupal8-advancedの例をチェックしてみてください、それは必要なモジュールと必要なものを含んでいます。 Drupalの設定。

注意:これらの例の多くは、同じdrupal-example-simpleリポジトリ内の異なるブランチ/ハッシュに存在します。例のリストから正確なブランチを取得してください！

PurgeとVarnish Purgeモジュールのインストール#

Drupal 8のキャッシュタグとVarnishを完全に使用するためには、PurgeとVarnish Purgeモジュールをインストールする必要があります。これらは多くのサブモジュールと共に提供されています。最低限以下のものをインストールすることをお勧めします:

  • purge
  • purge_drush
  • purge_tokens
  • purge_ui
  • purge_processor_cron
  • purge_processor_lateruntime
  • purge_queuer_coretags
  • varnish_purger
  • varnish_purge_tags

一度にすべてを取得します:

PurgeとVarnish Purgeのインストール
composer require drupal/purge drupal/varnish_purge

drush en purge purge_drush purge_tokens purge_ui purge_processor_cron purge_processor_lateruntime purge_queuer_coretags varnish_purger varnish_purge_tags

Varnish Purgeの設定#

  1. Configuration > Development > Performance > Purgeにアクセスします。
  2. Add purgerでパージャーを追加します。
  3. Varnish Bundled Purgerを選択します(Varnish Purgerではなく、#Behind the Scenesを参照してください)。 セクション、詳細情報については。).
  4. 追加したばかりのパージャーの隣にあるドロップダウンをクリックし、Configureをクリックします。
  5. 良い名前をつけてください、Lagoon Varnish が良いでしょう。

  6. 以下のように設定します:

    Varnish Purgeの設定
     TYPE: タグ

 REQUEST:
 ホスト名: varnish
 (またはdocker-compose.ymlでVarnishが呼ばれている名前)
 ポート: 8080
 パス: /
 リクエスト方法: BAN
 スキーム: http

 HEADERS:
 ヘッダー: Cache-Tags
 値: [invalidations:separated_pipe]

  7. 設定を保存。

以上で終わりです！これをローカルでテストしたい場合は、次のセクションを読んでください。

Varnish用のDrupalの設定#

その他にもいくつかの設定が可能です:

  1. drush pmu page_cacheを使用してInternal Page Cache Drupalモジュールをアンインストールします。これによりVarnishキャッシュのみがクリアされ、内部キャッシュはクリアされず、変更がユーザーに非常に遅く表示されるなど、奇妙な二重キャッシュ状況が発生することがあります。また、大きなサイトではキャッシュストレージを大量に使用します。
  2. production.settings.php内の$config['system.performance']['cache']['page']['max_age']を2628000に変更します。これにより、Varnishはサイトを最大1ヶ月間キャッシュするように指示されますが、これは多くのように聞こえますが、Drupal 8 キャッシュタグシステムは基本的に何かが変更されるたびにVarnishキャッシュがパージされるようにするので、とても素晴らしいです。

Varnishをローカルでテストする#

LagoonのローカルでのDrupalセットアップでは、開発が困難になる可能性があるため、VarnishとDrupalのキャッシュは無効になっています。これは次のように行われます:

  • docker-compose.ymlの環境変数VARNISH_BYPASS=trueは、Varnishに基本的に自己無効化を指示します。
  • Drupalは、development.settings.phpのDrupal設定$config['system.performance']['cache']['page']['max_age'] = 0を設定することで、キャッシュヘッダーを送信しないように設定されています。

ローカルでVarnishをテストするには、docker-compose.ymlで以下の変更を行います:

  • VarnishサービスセクションでVARNISH_BYPASSをfalseに設定します。
  • x-environmentセクションでLAGOON_ENVIRONMENT_TYPEをproductionに設定します。
  • docker-compose up -dを実行します。これにより、新しい環境変数ですべてのサービスが再起動します。

これで、Varnishをテストできるようになるはずです！

次に、IDが1でURLがdrupal-example.docker.amazee.io/node/1となるノードがあると仮定した短い例を示します。

  1. curl -I drupal-example.docker.amazee.io/node/1を実行し、見てみてください。 これらのヘッダーについて:
    • X-LAGOON には varnish が含まれ、要求が実際にVarnishを経由したことを示します。
    • Age: は、Varnishがこのサイトを初めて見ることはおそらくないため、最初のリクエストがVarnishのキャッシュを温めるでしょう。
    • X-Varnish-Cache は MISS となり、Varnishがこのリクエストの以前にキャッシュされたバージョンを見つけられなかったことを示します。
  2. curl -I drupal-example.docker.amazee.io/node/1 を再度実行し、ヘッダーは次のようになります:
    • Age: は、リクエストがキャッシュされてから何秒経ったかを示します。例えば、コマンドを実行する速度によりますが、1-30の間でしょう。
    • X-Varnish-Cache は HIT となり、Varnishがリクエストのキャッシュされたバージョンを正常に見つけ、それを返したことを示します。
  3. Drupalの node/1 の内容を変更します。
  4. curl -I drupal-example.docker.amazee.io/node/1 を実行し、ヘッダーは最初のリクエストと同じになるべきです:
    • Age:0
    • X-Varnish-Cache: MISS

Varnish on Drupal の裏側#

他のDrupalホストから来ているか、以前にDrupal 8 & Varnishのチュートリアルを経験している場合、あなたは気付いたかもしれません。 Lagoon Drupal Varnishチュートリアルにいくつかの変更があります。それらについて説明しましょう:

Varnish Purgerの代わりにVarnish Bundled Purgerの使用#

Varnish Purgerは、無効化する必要がある各キャッシュタグに対してBANリクエストを送信します。Drupalには多数のキャッシュタグが存在し、これによりVarnishに送信されるリクエスト数がかなり多くなる可能性があります。それに対して、Varnish Bundled Purgerは、複数の無効化に対して一つのBANリクエストを送信します。これはパイプ(|)できれいに分離されており、Varnishのバンの正規表現システムに完璧にマッチします。これにより、Varnishへのリクエスト数が減少し、Varnish内のバンリストテーブルも小さくなります。

Purge Late runtime processorの使用#

Drupal 7のVarnishモジュールとは異なり、Drupal 8のPurgeモジュールはキャッシュのパージに若干異なるアプローチを持っています: パージするキャッシュをキューに追加し、それを異なるプロセッサで処理します。PurgeはCron processorの使用を提案していますが、これはVarnishキャッシュがcron実行時にのみパージされることを意味します。これは、cronがおそらく毎分実行するように設定されていないため、Varnishが古いデータをキャッシュする可能性があり、編集者やクライアントが混乱する結果となる可能性があります。

その代わりに、PurgeLate runtime processorは、各Drupalリクエストの最後にキューを処理します。これにより、キャッシュタグがパージキューに追加されると(例えば、エディタがDrupalノードを編集した場合など)、そのノードのキャッシュタグが直接パージされるという利点があります。Varnish Bundled Purger`と一緒に使用することで、Drupalリクエストの最後にVarnishへの追加のリクエストは1つだけで、リクエストの処理時間にはほとんど影響しません。

Varnish Ban Lurkerの完全なサポート#

私たちのVarnish設定は、Ban Lurkerの完全なサポートを提供しています。Ban Lurkerは、キャッシュをきれいに保ち、Varnishをスムーズに動作させるのに役立ちます。基本的には、Varnishの禁止リストを走査し、それらをVarnishキャッシュ内のキャッシュされたリクエストと比較する小さなツールです。Varnishの禁止は、キャッシュ内のオブジェクトをパージするために使用されます。Ban Lurkerが"禁止"されるべきアイテムを見つけると、それらをキャッシュから削除し、禁止自体も削除します。これにより、通常は禁止されずにキャッシュスペースを占め続ける、アクセスが少なくTTLが非常に長いオブジェクトが削除され、更新できるようになります。これにより、禁止リストが小さくなり、それによって、Varnの処理時間も少なくなります。 それぞれのリクエストでのVarnishの動作については、公式VarnishのBan Lurkerについての投稿や、その他の参考になる読み物をご覧ください。

トラブルシューティング#

Varnishがキャッシュしていない？ それとも何か他の問題がありますか？ 以下にデバッグの方法をいくつか紹介します:

  • drush p-debug-enを実行して、purgeモジュールのデバッグログを有効にします。これにより、Drupalのログのadmin/reports/dblogでデバッグを表示できます。
  • Drupalが適切なキャッシュヘッダーを送信していることを確認してください。これを最もよくテストするためには、LagoonがVarnishキャッシュをバイパスするために生成したURLを使用します(私たちのDrupalの例では、これはhttp://nginx-drupal-example.docker.amazee.ioです)。Cache-Control: max-age=900, publicヘッダーをチェックし、900が$config['system.performance']['cache']['page']['max_age']で設定したものであることを確認します。
  • 環境変数VARNISH_BYPASSがtrueに設定されていないことを確認してください(docker-compose.ymlを参照し、docker-compose up -d varnishを実行して環境変数が正しく設定されていることを確認します)。
  • もし全部 失敗すると、テーブルをひっくり返す前に (╯°□°)╯︵ ┻━┻、Lagoonチームに話してみてください、私たちは喜んでお手伝いします。