Откат: вернуть известное рабочее состояние

Выпуск r2 подготовлен и выбран через current. После публикации выяснилось, что старая статья отображается без важных изображений. Следует ли срочно исправлять файлы на месте или вернуть r1? В этом уроке рассмотрим откат как осознанный выбор известного результата. Для статического сайта он сравнительно прост, если прежняя версия сохранена и конфигурация осталась совместимой.

Учебное событие не является неисправностью настоящего ProfessorWeb. Мы используем условный старый адрес /my/legacy/first.php и два каталога release-lab. Полезность примера в порядке рассуждения: установить масштаб, выбрать действие и проверить результат. Команда смены ссылки — только часть этой последовательности.

Что даёт основание вернуть выпуск

До публикации мы указали обязательные свойства: старый путь открывается, материал соответствует странице, ресурсы доступны, неизвестный адрес получает 404. Если кандидат нарушает одно из этих свойств, он не соответствует условиям принятия. Однако сначала следует понять источник наблюдения. Одна устаревшая вкладка браузера может показывать прежний кеш, тогда как свежий запрос получает правильные файлы. Возврат по непроверенному впечатлению способен добавить второе изменение, не устранив причину.

Рассмотрим условную запись: после переключения индикатор показывает r2, HTML старой статьи отвечает 200, а требуемое изображение — 404. В сохранённом r1 этот файл присутствует. Причина достаточно конкретна: кандидат потерял ресурс. Если восстановление в исходниках и получение нового артефакта займёт время, возврат к целостному r1 разумно ограничивает ущерб. Не нужно выдавать такую запись за измерение: фактическое время и ответы появятся только на выполненном стенде.

Сначала определить, что именно возвращаем

В базовом варианте Nginx продолжает использовать прежний корень через current, сертификат и DNS не менялись, а оба выпуска статические. Значит, возврат включает выбор прежнего каталога. Если одновременно изменили обработчик .php, одной смены файлов может оказаться мало. Тогда нужно вернуть совместимую конфигурацию и проверить её отдельно. Поэтому карточка выпуска должна содержать не только номер архива, но и перечень инфраструктурных изменений.

Слово «предыдущий» также не всегда означает «рабочий». Если r1 сам имел известный дефект, возвращаться к нему без анализа нельзя. В журнале отмечают последний принятый выпуск и причину его принятия. Прежний путь, автоматически записанный перед переключением, помогает найти кандидата для возврата, но окончательное решение связано с известным состоянием. При нескольких быстрых попытках это различие особенно полезно.

Возврат по тому же механизму

Используем ту же замену ссылки, что и при прямой публикации. Перед действием проверяем каталог, паспорт и доступность файлов. Временное имя должно быть свободно; если оно осталось от прерванного действия, сначала выясняют его происхождение. Нельзя молча удалить любой объект с похожим именем, особенно если сценарий принимает путь извне.

set -e
base=/srv/release-lab
target="$base/releases/r1"
test -L "$base/current"
test -f "$target/release.json"
test -f "$target/public/my/legacy/first.php"
test ! -e "$base/.rollback.next"
test ! -L "$base/.rollback.next"
ln -s "$target" "$base/.rollback.next"
mv -Tf "$base/.rollback.next" "$base/current"
readlink -f "$base/current"

Это одиночный учебный возврат на GNU/Linux. В автоматизированном проекте прямые выпуски и откаты проходят общий механизм исключения конкуренции. Иначе новый конвейер может сразу заменить выбранный r1, и действие окажется коротким промежуточным состоянием. Сериализацию и порядок решений добавим позднее; сейчас важно понять, что откат не обладает отдельной магической атомарностью.

Возвращение ссылки не удаляет r2. Его сохраняют для разбора вместе с паспортом и симптомами. Если сразу стереть неудачный результат, будет сложнее воспроизвести отсутствующий ресурс и определить, где он потерялся. После исправления создают новый выпуск, а не дописывают изображение в старый r2 под прежним номером. Так история продолжает объяснять содержание каждого состояния.

Проверка возврата снаружи

После смены пути проверяют основной домен: индикатор версии, старый материал и конкретный отсутствовавший ресурс. Ожидается r1 и восстановленное содержание, но ответ может пройти через кеш. Если HTML уже обновился, а изображение всё ещё отсутствует, возможна сохранённая отрицательная копия ответа либо другая причина маршрутизации. Смотрят заголовки и слой, который ответил, вместо многократного переключения туда и обратно.

Nginx может возвращать собственную страницу ошибки, поэтому анализ тела помогает отличить ошибку выбора файла от прикладной страницы. Его журналы дают дополнительный контекст, но не заменяют внешний запрос. Описание обработки ошибок Nginx. Для текущей задачи достаточно проверить маршруты, которые обосновали возврат, и основной набор принятия. Повторять весь объём проверки без новой причины необязательно.

Полезно отдельно отметить окончание инцидента. Запись «выполнена команда» не сообщает, что посетители снова получили нужный материал. Запись «внешняя проверка старого адреса и ресурса успешна, выбран r1» описывает восстановленное поведение. На своём стенде читатель добавит время, источник запроса и номер артефакта. Эти данные нужны и для последующего объяснения, и для контроля повторной публикации исправления.

Когда откат файлов недостаточен

У статического дерева нет прикладных записей, меняющихся после публикации. Во второй части курса появятся загруженные файлы и база. Тогда r2 может изменить схему или создать новые данные, а r1 — не понимать их. Смена каталога вернёт код, но не вернёт базу. В таком случае восстановление из копии может удалить новые пользовательские действия, поэтому нельзя автоматически связывать откат с заменой базы старым дампом.

Даже у статики есть внешнее состояние: DNS, сертификат, кеш CDN и настройки хостинга. Возврат каталога не отменяет его изменение. Если проблема связана с истёкшим сертификатом, перестановка статических выпусков не поможет. Нужно выбрать действие на правильном слое. Модель из первого урока помогает сформулировать этот вопрос: испорчен артефакт, неверно настроено окружение или изменилось дополнительное состояние?

После стабилизации

Разбор неудачного кандидата заканчивается исправлением в исходниках и новой проверкой. В нашем случае добавляют потерянный ресурс в полноценное публичное дерево, получают новый идентификатор и проходят staging заново. Не следует считать прежний положительный просмотр распространяющимся на исправленный архив: теперь у него другие байты. При этом причина понятна, поэтому проверка может быть сосредоточена на ресурсах и сохранении маршрутов.

К концу урока мы получили проверяемый возврат известного выпуска и сохранили данные для исправления. Это защищает от ошибки обновления, пока сервер и прежние каталоги доступны. От утраты диска или аккаунта потребуется другое средство — независимая резервная копия и заранее понятный способ её восстановления.