Тригери деплою

Прогрівайте автоматично після кожного релізу — з Vercel, Netlify, Shopify або будь-якого CI-конвеєра.

9 хв читання

Розгортання — це єдиний найнадійніший спосіб охолодити весь сайт одночасно. Випуск робить кеші недійсними, і кожен відвідувач протягом наступних хвилин сплачує вартість відновлення одночасно — саме тоді, коли ви, найімовірніше, спостерігаєте за проблемами.

Тигери розгортання роблять утеплення частиною доставки. Коли ваше розгортання вдається, ваша платформа викликає Cache Rocket, і розігрів починається без того, щоб ніхто відкрив інформаційну панель.

URL-адреси та приклади вебхуку можна знайти в розділі Обліковий запис → Розгорнути інтеграцію.

Як це працює

Ви надаєте своїй платформі хостингу або CI URL-адресу для виклику після успішного розгортання. Запит містить ваші ключі API як заголовки, а також невелике тіло JSON, яке повідомляє, що потрібно нагріти.

Загальна форма

bash

curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/vercel \
  -H "Content-Type: application/json" \
  -H "X-Public-Key: YOUR_PUBLIC_KEY" \
  -H "X-Secret-Key: YOUR_SECRET_KEY" \
  -d '{"hostname":"www.example.com"}'

Платформа	Шлях вебхуку
Vercel	`/web/v1/public/webhooks/vercel`
Netlify	`/web/v1/public/webhooks/netlify`
Shopify	`/web/v1/public/webhooks/shopify`

Note

Точна базова URL-адреса для вашого облікового запису відображається на сторінці «Розгортання інтеграції» разом із готовим до копіювання прикладом curl для кожної платформи.

Вибір корисного навантаження

Тіло JSON вирішує, що нагрівати. Три варіанти, від найширшого до найбільш хірургічного:

Тіло	Ефект	Використовуйте коли
`{"hostname":"www.example.com"}`	Починається кожен warmer, що відповідає цьому hostname	Звичайний повний випуск. Звичайний вибір.
`{"crawlerId":"…"}`	Починає один конкретний warmer	У вас є кілька warmers на сайт, і лише один стосується цього розгортання.
`{"urls":["https://…"]}`	Пріоритетно підігріває саме ці URL-адреси	Часткова публікація або кілька сторінок, які ви знаєте, змінені.

Пріоритетні теплі певні URL-адреси після часткової публікації

bash

curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/netlify \
  -H "Content-Type: application/json" \
  -H "X-Public-Key: YOUR_PUBLIC_KEY" \
  -H "X-Secret-Key: YOUR_SECRET_KEY" \
  -d '{"urls":["https://www.example.com/","https://www.example.com/pricing"]}'

Vercel

Додайте URL-адресу Cache Rocket як хук розгортання або інтеграційний вебхук у налаштуваннях вашого проекту, що запускатиметься під час успішних робочих розгортань. Автентифікуйте за допомогою заголовків X-Public-Key та X-Secret-Key.

Tip

Пожежа лише на виробництві. Розгортання попереднього перегляду мають власні URL-адреси, не знаходяться на вашому підтвердженому hostname, і їх розігрів витрачає ваш бюджет.

Netlify

Використовуйте вебхук сповіщення про подію вдале розгортання, вказуючи на шлях Netlify з тими самими заголовками ключів API.

Shopify

Публікацію теми або веб-перехоплення програми вказуйте на шляху Shopify, тому зміни вітрини магазину оновлюються, щойно вони опубліковані.

Будь-який конвеєр CI

У запиті немає нічого специфічного для платформи — це HTTP POST. Додайте його як останній крок будь-якого конвеєра.

Дії GitHub

yaml

- name: Warm Cache Rocket after deploy
  run: |
    curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/vercel \
      -H "Content-Type: application/json" \
      -H "X-Public-Key: ${{ secrets.CACHEROCKET_PUBLIC_KEY }}" \
      -H "X-Secret-Key: ${{ secrets.CACHEROCKET_SECRET_KEY }}" \
      -d '{"hostname":"www.example.com"}'

Ніколи не закодуйте секретний ключ у файлі конвеєра

Використовуйте зашифроване сховище секретів вашого постачальника CI, як зазначено вище. Визначення конвеєра живуть у вашому сховищі, а зафіксований секрет є секретом, що витік.

Альтернатива: triggerWarm

Існує також простіша кінцева точка, яка приймає ключі в тілі, а не в заголовках, що підходить для середовищ, де налаштування власних заголовків є незручним:

bash

curl -X POST https://cacherocket.com/api/wordpress/triggerWarm \
  -H 'Content-Type: application/json' \
  -d '{"publicKey":"YOUR_KEY","secretKey":"YOUR_SECRET","hostname":"example.com"}'

Супутня кінцева точка warmUrls пріоритетно підігріває явний список URL-адрес.

Правильне оформлення замовлення

Послідовність має більше значення, ніж люди очікують:

1
Розгортання завершено, нова версія доступна
Потепління випуску, який не завершив розгортання, просто кешує старий.
2
Очистіть CDN, якщо розгортання змінило кешований вихід
Інакше підігрів перечитує те, що вже кешовано, і нічого не покращується.
3
Потім запустити прогрівання
Тепер гарячий запуск отримує справді новий вміст і заповнює ним кеш.

Занадто раннє утеплення — класична помилка

Якщо тригер спрацьовує до того, як розгортання буде повністю активним або до того, як CDN буде очищено, ви ретельно розігрієте попередню версію. Підключайтеся до *успішної* події, а не до *розпочатої*.

Загальні проблеми

Вебхук повертає 401.: Ключі неправильні, прострочені або замінені новою парою. Перевірте, чи назви обох заголовків мають точно X-Public-Key і X-Secret-Key, і знайдіть усічені значення у вашому секретному сховищі.
Це повертає успіх, але нічого не гріє.: hostname в організмі, ймовірно, не відповідає жодному активному warmer. Переконайтеся, що hostname, включаючи www, і що відповідний warmer активний.
Потепління тривало, але відвідувачі все ще потрапляли на холодні сторінки.: Майже завжди замовлення — або він запускався до того, як розгортання було активним, або CDN було очищено після нагрівання, а не раніше. Додайте крок очищення перед тригером.
Розгортання попереднього перегляду споживають мій бюджет URL-адреси.: Обмежити вебхук лише робочими розгортаннями.
Це те саме, що очищення CDN?: Ні. Тригери розгортання починають розігрів; вони нічого не скасовують. [Інтеграція CDN] (/documentation/cdn-integrations) очищає, а потім перегріває. Багато команд використовують обидва.