Կեշի թեգեր + Varnish

Varnish Cache՝ վեբ ծրագրերի արագացուցիչ է, որն առավելապես հայտնի է որպես HTTP կեշավորող հակադարձ պրոքսի սերվեր: Varnish-ը օգտագործվում է հազարավոր Drupal կայքերում՝ էջերի բեռնման արագությունը 10-ից մինչև 1000 անգամ բարձրացնելու համար, և այն կարելի է օգտագործել կեշի թեգերի հետ միասին՝ կեշի չեղարկումը հեշտացնելու համար։

Կեշի թեգերի հիմնական ինտեգրման համար անհրաժեշտ է երեք բան անել՝ համոզվելու համար, որ Varnish-ը լավ աշխատում է Drupal-ի ստեղծած կեշի թեգերի հետ․

• Թարմացրեք Varnish-ի VCL-ն՝ ապահովելու համար BAN հարցումների ճիշտ մշակում։
• Ուղարկեք կեշի թեգերի հեդեր (օրինակ՝ X-Cache-Tags) յուրաքանչյուր հարցման հետ միասին, որը պարունակում է էջի բոլոր կեշի թեգերի բացատրված ցուցակ։
• Ուղարկեք BAN հարցում համապատասխան կեշի թեգերով յուրաքանչյուր անգամ, երբ թարմացվում է բովանդակությունը կամ կոնֆիգուրացիան, և համապատասխան կեշի թեգերով էջերի ժամկետը ավարտվում է։

Varnish VCL-ի թարմացում

Symfony FOSHttpCache փաթեթը պարունակում է գերազանց փաստաթղթավորում VCL փոփոխությունների մասին՝ կեշի թեգերի աջակցության համար, բայց ահա նվազագույն VCL փոփոխությունները՝ սկսելու համար (Varnish 4.x-ի համար)․

vcl_recv-ում.

sub vcl_recv {
    ...
    # BAN հարցումները թույլատրվում են միայն purge ACL-ում ընդգրկված IP-հասցեներից։
    if (req.method == "BAN") {
        # Նույն ACL ստուգումը.
        if (!client.ip ~ purge) {
            return (synth(403, "Not allowed."));
        }

        # BAN-ի տրամաբանությունը՝ օգտագործելով X-Cache-Tags հեդերը։
        if (req.http.X-Cache-Tags) {
            ban("obj.http.X-Cache-Tags ~ " + req.http.X-Cache-Tags);
        }
        else {
            return (synth(403, "X-Cache-Tags header missing."));
        }

        # Ստեղծեք արհեստական էջ, որպեսզի հարցումը չգնա backend.
        return (synth(200, "Ban added."));
    }
}

vcl_backend_response-ում.

sub vcl_backend_response {
    # Կարգավորեք ban-lurker-ի համար հարմար հեդերներ։
    set beresp.http.X-Url = bereq.url;
    set beresp.http.X-Host = bereq.http.host;
    ...
}

vcl_deliver-ում.

sub vcl_deliver {
    # Հեռացրեք ban-lurker-ի հարմար հեդերները հաճախորդին ուղարկելու ժամանակ։
    unset resp.http.X-Url;
    unset resp.http.X-Host;
    # Տարբերեք Drupal-ի կեշի թեգերի դեբագի համար (դեռևս բետա փուլում).
    unset resp.http.X-Cache-Tags;
    unset resp.http.X-Cache-Contexts;
    ...
}

Պարտադիր է Varnish-ը վերագործարկել VCL-ում փոփոխությունները կատարելուց հետո։

Ուղարկեք կեշի թեգերի հեդեր

Դուք կարող եք միացնել հետևյալ մոդուլներից մեկը՝ заставляя Drupal-ը արտահանել HTTP հեդեր, որը պարունակում է կեշի թեգերը.

Նշենք, որ որոշ 8.x-3.0-beta5-ից ավելի վաղ տարբերակներում Purge մոդուլը ավտոմատ կերպով կարգավորում էր Purge-Cache-Tags հեդերը, սակայն այն հանվել է՝ որոշվելով, որ դրա փոխարեն պատասխանատվությունը պետք է դրվի ենթամոդուլների վրա։

BAN հարցման ուղարկում բովանդակության կամ կոնֆիգուրացիայի փոփոխման դեպքում

Generic HTTP Purger մոդուլը թույլ է տալիս մտնել Purge-ի կոնֆիգուրացիայի էջը (admin/config/development/performance/purge) և ավելացնել HTTP Purger:

Մուտքագրեք ձեր Varnish սերվերի տվյալները (հյոստ, պորտ, ուղի և այլն), և «Հեդերների» կոնֆիգուրացիայում մուտքագրեք հետևյալ կարգավորումը՝

• Հեդեր՝ X-Cache-Tags
• Արժեք՝ [invalidation:expression]

Միայն թե այս կոնֆիգուրացիան պահեք և կարգավորեք cron առաջադրանքը՝ Purge հերթը մշակելու համար (drush p-queue-work), Varnish-ը պետք է սկսել արգելափակել էջերը՝ երբ հերթը կատարի BAN հարցումները։

Այս փաստաթղթում նշված մի քանի նկատառումներ հարմարեցվել են հետևյալ աղբյուրներից.

• Օգտագործեք Drupal 8 Cache Tags Varnish-ի և Purge-ի հետ
• Ավելացնել աջակցություն կեշի թեգերի համար Drupal VM Varnish-ի կոնֆիգուրացիայում