Введение
Конечная точка проверки доступности поддержки работала, пока новый релиз не начал возвращать ошибку 503. В этой лабораторной работе вы опубликуете обе версии временного Worker, определите активную версию и восстановите заведомо рабочий релиз. Вы сравните фактическое поведение HTTP с метаданными развёртывания Cloudflare, а не будете полагаться только на сообщение об успешной загрузке.
Вы уже должны понимать, как разрабатывать локально с Wrangler, авторизовывать аккаунт и выполнять развёртывание. Начните работу в этой чистой виртуальной машине со своей учебной учётной записью; предыдущая виртуальная машина или Worker не используются повторно. В процессе настройки устанавливаются Node.js 22.22.0 и локальный для проекта Wrangler 4.131.1, а также предоставляются два небольших синтетических обработчика. Домен, сервис хранения данных и секрет не требуются. Все действия по развёртыванию и очистке вы выполняете самостоятельно.
Версия — это неизменяемый снимок кода и конфигурации. Развёртывание определяет, какая версия получает трафик. Откат создаёт новое развёртывание существующей версии; он не изменяет локальный исходный код и не восстанавливает данные в связанных ресурсах. См. официальный обзор версий.
Подготовка заведомо рабочего релиза
На этом шаге подготовьте заведомо рабочую точку входа и проверьте её поведение локально. Предоставленные файлы позволяют сосредоточиться на операциях с релизами. Рабочий обработчик возвращает available=true; неисправный сохраняет работоспособность, но возвращает 503 для бизнес-маршрута.
cd /home/labex/project/release-recovery
cat versions/good.js
diff -u versions/good.js versions/faulty.js
Команда diff завершится с кодом 1, потому что файлы различаются; это ожидаемый результат. Изменяются только доступность и соответствующий статус HTTP. Копирование рабочего файла выбирает исходный файл, указанный в конфигурации.
cp versions/good.js src/index.js
Сгенерируйте уникальное имя с помощью стандартного API crypto в Node. В приведённой ниже команде разделитель EOF не заключён в кавычки, поэтому переменная оболочки подставляется в JSON. Файл не содержит комментариев, поэтому его также можно анализировать стандартными средствами работы с JSON.
WORKER_NAME="labex-release-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
cat > wrangler.jsonc <<EOF
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"workers_dev": true,
"preview_urls": false,
"version_metadata": {"binding": "RELEASE"}
}
EOF
Привязка метаданных версии предоставляет идентификатор и тег версии во время выполнения. Локальная разработка использует локальные метаданные; только метаданные развёрнутого Worker идентифицируют версию в облаке. Описание этой привязки доступно здесь.
Запустите локальный сервер в фоновом режиме с помощью & и перенаправьте его вывод в dev.log. Прежде чем отправлять запросы, дождитесь сообщения Ready.
npx wrangler dev --ip 0.0.0.0 --port 8080 > dev.log 2>&1 &
cat dev.log
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8080/api/availability
Оба маршрута должны вернуть 200; значение availability должно быть true. Локальные значения версии и тега могут быть заполнителями, используемыми в режиме разработки. Перед остановкой процесса разработки на следующем шаге выполните проверку.
Развёртывание и сохранение рабочей версии
На этом шаге разверните заведомо рабочий исходный код в своей учебной учётной записи и сохраните фактическую версию. Остановите локальный процесс, при необходимости подставив его текущий номер.
jobs
kill %1
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Откройте в браузере выведенную ссылку для устройства, введите код и авторизуйте нужную учебную учётную запись. Вводите учётные данные только в процессе входа. Просмотрите стандартный вывод со сведениями об аккаунте и подтвердите имя, даже если в списке указан только один аккаунт.
npx wrangler whoami --json
Замените YOUR_ACCOUNT_ID ниже фактическим идентификатором этого аккаунта. Эта стандартная команда Node изменяет явную конфигурацию проекта; аккаунт не выбирается с помощью временной переменной окружения.
node -e 'const fs=require("node:fs");const p="wrangler.jsonc";const c=JSON.parse(fs.readFileSync(p));c.account_id="YOUR_ACCOUNT_ID";fs.writeFileSync(p,JSON.stringify(c,null,2)+"\n");'
cat wrangler.jsonc
Тег — это понятная человеку метка, а UUID версии — точный идентификатор. При развёртывании загружается версия, и на неё направляется трафик. Сообщение описывает назначение версии.
npx wrangler deploy --tag good --message "Known-good availability"
Скопируйте выведенные URL workers.dev и Current Version ID в следующие команды. Это примеры-заполнители, а не фиксированные общие ресурсы. Если для этого аккаунта ещё не настроен поддомен workers.dev, выполните начальную настройку из раздела «Deploy Your First Cloudflare Worker», затем повторите развёртывание.
APP_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
printf '%s\n' "YOUR_GOOD_VERSION_ID" > good-version.txt
curl -i "$APP_URL/api/availability"
npx wrangler deployments status
npx wrangler versions list
Ожидайте статус 200, значение available=true, тег good и сохранённый UUID версии в ответе. Активное развёртывание должно направлять на эту версию 100% трафика. Откройте именно этот Worker в Dashboard и просмотрите раздел Deployments, чтобы сопоставить версию из CLI и активное развёртывание с отображаемым ресурсом. Если сразу после развёртывания ответ всё ещё показывает предыдущее состояние, подождите пять секунд и повторяйте чтение не более одной минуты; не изменяйте код, чтобы скрыть задержку распространения. Выполните проверку после того, как результаты наблюдений совпадут.
Наблюдение за неисправным релизом
На этом шаге воспроизведите контролируемую регрессию релиза в этом временном Worker. Работающая конечная точка liveness не гарантирует, что бизнес-маршрут исправен. Замените точку входа неисправным файлом и опубликуйте версию с отдельным тегом.
cp versions/faulty.js src/index.js
npx wrangler deploy --tag faulty --message "Demonstrate availability regression"
Сохраните новый Current Version ID этого развёртывания, а не идентификатор рабочей версии. Проверьте оба маршрута и текущее развёртывание.
printf '%s\n' "YOUR_FAULTY_VERSION_ID" > faulty-version.txt
curl -i "$APP_URL/health"
curl -i "$APP_URL/api/availability"
npx wrangler deployments status
npx wrangler versions list
Проверка работоспособности по-прежнему возвращает 200. Доступность теперь возвращает 503, available=false и тег faulty. UUID во время выполнения должен совпадать с новым активным UUID версии, на которую направлено 100% трафика. Ошибка 503 — это предусмотренный дефект данного шага, а не причина пропускать проверку. Если распространение изменений ещё не завершилось, выполните такую же ограниченную по времени повторную проверку ответа. Для независимой проверки необходимо, чтобы неисправность была наблюдаема до восстановления.
В разделе Compute → Workers & Pages откройте именно свой Worker и выберите Deployments. Сравните идентификатор в разделе Active deployment со строкой с тегом faulty в Version History. На снимке экрана используются сокращённые демонстрационные UUID; в командах применяйте сохранённые полные UUID. Рабочая версия остаётся в истории, даже пока активна неисправная версия. Используйте приведённую выше команду wrangler deployments status, чтобы подтвердить настроенное распределение 100% трафика; нулевые показатели активности на этом спокойном снимке экрана не доказывают работоспособность бизнес-маршрута.
Откат и синхронизация локального исходного кода
На этом шаге восстановите точную заведомо рабочую версию. Прочитайте сохранённые идентификаторы и проверьте выбранную рабочую версию перед изменением направления трафика. Подстановка команды оболочки считывает UUID из файла; новая версия при этом не загружается.
cat good-version.txt faulty-version.txt
npx wrangler versions view "$(cat good-version.txt)"
Подтвердите рабочий тег, нужные Worker и аккаунт, а также UUID. Откат направит 100% трафика этого временного Worker на эту версию. Сообщение фиксирует причину восстановления. Выполняйте команду только после проверки цели.
npx wrangler rollback "$(cat good-version.txt)" --message "Restore known-good availability"
Когда Wrangler запросит необязательное сообщение, нажмите Enter, чтобы принять Restore known-good availability. Прочитайте отображаемые рабочий UUID и цель с 100% трафика; в соответствующем запросе подтверждения нажмите одну клавишу y. Прежде чем продолжить, дождитесь сообщения об успешном откате.
npx wrangler deployments status
curl -i "$APP_URL/api/availability"
Новое развёртывание должно использовать исходный UUID рабочей версии; его идентификатор развёртывания не обязан совпадать с исходным. Доступность снова возвращает 200 и true. Обновите вкладку Deployments в Dashboard и сравните активный UUID. При необходимости выполните такую же ограниченную одной минутой повторную проверку ответа.
В этом примере Active deployment снова имеет сокращённый идентификатор 7afe5d31 — тот же, что был у исходной версии good. Маркер активности в Version History переместился на эту строку, а неисправная версия по-прежнему отображается. Сопоставьте эти связи со своими идентификаторами; не копируйте значения из примера. Эта страница показывает выбранную версию, а ответ availability подтверждает восстановление поведения.
Откат не изменяет локальный исходный код. Восстановите рабочий файл локально, чтобы последующее обычное развёртывание случайно не вернуло известную неисправность. Режим dry-run собирает пакет из локального исходного кода, но не загружает его.
cp versions/good.js src/index.js
npx wrangler deploy --dry-run
Выполните проверку: она сравнивает реальный UUID и тег во время выполнения с текущим развёртыванием, которому назначено 100% трафика, и проверяет, что предыдущее неисправное развёртывание остаётся в истории. Локально созданного файла с признаком успеха недостаточно.
Откат не отменяет записи в базу данных, очередь или внешний API, а изменения связанных ресурсов могут сделать старые версии несовместимыми. В этой лабораторной работе таких ресурсов нет. В реальном инциденте оцените эти границы перед восстановлением. В документации по откату описаны ограничения и период хранения версий.
Удаление тестового Worker для релиза
На этом шаге удалите временный Worker, пока авторизация ещё действует. Перед удалением подтвердите его точное имя и аккаунт.
cat wrangler.jsonc
npx wrangler delete
В запросе с совпадающим именем нажмите одну клавишу y. Закреплённая версия Wrangler может сообщить об ошибке аутентификации при очистке устаревшего KV после удаления Worker. Не предоставляйте более широкие разрешения и не считайте любую ошибку доказательством удаления. Обновите Dashboard и выполните проверку: успешная аутентифицированная инвентаризация должна показать, что этого Worker нет. Не затрагивайте учебную учётную запись, поддомен и несвязанные ресурсы.
Отключение виртуальной машины
На этом шаге отключите виртуальную машину после успешного удаления. Один только выход из аккаунта не удалит развёрнутый Worker.
npx wrangler logout
npx wrangler whoami --json
Ожидайте loggedIn=false; структурированная команда может завершиться с ненулевым кодом, поскольку теперь вы не авторизованы. Выполните финальную проверку. Вход в браузере и учебная учётная запись останутся доступными для будущих независимых лабораторных работ.
Итоги
Вы сравнили версии Worker с активными развёртываниями, наблюдали регрессию бизнес-маршрута при исправной проверке liveness и восстановили выбранную рабочую версию. Метаданные во время выполнения связали фактические ответы с развёртыванием, которому назначено 100% трафика. Вы также восстановили локальный исходный код, проверили очистку в облаке и отключили виртуальную машину.
