В моем обновлении возникла ошибка
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Пожалуйста, помогите мне это исправить.
Привет!
Я не отвечаю на твой вопрос, просто проявляю любопытство. Почему ты считаешь, что тебе нужна страница технического обслуживания? Казалось бы, настройка довольно утомительна при малой пользе.
Мои экземпляры простаивают всего 5 минут в месяц для обновлений, и это, по сути, всё.
Всякий раз, когда я вносил значительные изменения, например, устанавливал плагины, это иногда занимало до 20 минут.
Это не такая уж большая проблема, если учесть, что такие действия не проводятся каждую неделю или даже каждый месяц. Однако для нового посетителя эта уродливая страница с сообщением о том, что что-то не работает, производит далеко не лучшее первое впечатление. Даже постоянные посетители, которые не знают, что сайт временно недоступен, могут впасть в «панику», подумав, что вся сообщество было закрыто или что-то в этом роде. Возможно, некоторые из них сразу же напишут мне письмо, спрашивая, что происходит.
Я считаю, что это просто приятный жест в отношении посетителей, как новых, так и старых, позволяющий им понять, что происходит.
Если подход, предложенный Клодом, требует всего несколько минут на настройку, но после этого не требует постоянного вмешательства, я считаю, что это время потрачено не зря.
Это займёт секунды, если вы перейдёте на установку с двумя контейнерами.
Вы даже можете запланировать переключение на ночь, если очень хотите, пока вы и/или ваша основная аудитория спят.
Вам не нужна страница технического обслуживания.
Я использую двухконтейнерную сборку за CDN Cloudflare. Двухконтейнерная схема минимизирует время простоя, и оба моих основных рабочих форума отключаются не более чем на 30 секунд во время пересборки. Мне нравится иметь страницу технического обслуживания, потому что стандартная страница «сервер недоступен» выглядит не очень привлекательно и не дает никаких подсказок о том, как долго сайт будет недоступен.
Например, для сайта your-domain.com я просто использую маршрут Cloudflare Workers, настроенный на `yourdomain.com/.
Шаг 1: Создание страницы Workers
Вы можете настроить страницу технического обслуживания на странице настроек Workers & Pages в Cloudflare — нажмите кнопку Создать приложение:
затем используйте шаблон Hello World:
затем дайте ему имя и нажмите Развернуть:
затем перейдите на страницу обзора этой страницы технического обслуживания и нажмите Изменить код:
и вставьте этот код в окно кода worker.js (замените домен и любое сообщение, которое вы хотите, отредактируйте текст, цвет текста, фон и т. д.):
export default {
async fetch(request, env, ctx) {
try {
// Получаем исходный запрос с вашего сервера
const response = await fetch(request);
// Если ВАШ САЙТ переключает контейнеры, он возвращает 502, 521 или 530
if (response.status === 502 || response.status === 521 || response.status === 530) {
return returnCustomErrorPage();
}
// Если все в порядке, возвращаем обычный трафик форума
return response;
} catch (e) {
// Если сервер полностью недоступен
return returnCustomErrorPage();
}
}
};
function returnCustomErrorPage() {
const html = `
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Обновление системы - YOUR-SITE.com</title>
<style>
body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; text-align: center; padding: 50px; color: #333; background-color: #f9f9f9; }
h1 { font-size: 2.5em; margin-bottom: 0.5em; color: #9400D3; }
p { font-size: 1.2em; line-height: 1.5; }
.container { max-width: 600px; margin: 0 auto; background: white; padding: 40px; border-radius: 8px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); }
</style>
</head>
<body>
<div class="container">
<h1>Краткое окно обновления</h1>
<p><strong>YOUR-SITE</strong> проходит краткое 30-секундное обновление системы.</p>
<p>Сделайте глоток вашего напитка — эта страница автоматически обновится, как только мы вернемся в онлайн.</p>
</div>
<script>
// Автоматически проверяет, доступен ли сайт, каждые 10 секунд
setInterval(function() {
window.location.reload();
}, 10000);
</script>
</body>
</html>
`;
return new Response(html, {
status: 503, // 503 лучше всего для SEO, чтобы Google не штрафовал вас за простой
headers: {
"Content-Type": "text/html;charset=UTF-8",
"Retry-After": "30"
}
});
}
Это должно выглядеть примерно так. Нажмите «Развернуть», чтобы сохранить:
Шаг 2: Добавление маршрута
Теперь перейдите на страницу маршрутов Cloudflare Workers и нажмите кнопку Добавить маршрут, чтобы открыть новое модальное окно маршрута, заполните маршрут домена и выберите страницу Workers, которую вы только что создали, затем нажмите «Сохранить»:
Шаг 3: Запуск обновлений или пересборок
Теперь, когда вы подключаетесь к серверу по SSH и запускаете системные обновления или выполняете пересборку, вместо страницы «сайт недоступен» или страницы ошибки будет отображаться эта страница, когда на самом деле происходит простой (я использую 30 секунд, потому что это максимум для моих сайтов)
Я склонен добавлять и удалять маршрут Workers, когда выполняю техническое обслуживание, но некоторые предпочитают просто оставлять его там все время (я оставляю сам код страницы, я просто добавляю и удаляю маршрут).
Думаю, это все.
Необязательно: Запуск обновлений с помощью скрипта и расписания
Я также использую shell-скрипт Unix на своем сервере для запуска обновления, специфичного для двух контейнеров, который я создал следующим образом:
cat << 'EOF' > /root/update-web.sh
#!/bin/bash
cd /var/discourse
echo "➡️ Загрузка последних скриптов Docker Discourse..."
git pull
echo "➡️ Инициализация нового веб-контейнера в фоновом режиме (занимает ~8 минут)..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Инициализация успешна! Переключение контейнеров..."
./launcher destroy web_only && ./launcher start web_only
echo "🚀 Готово! Сайт обновлен с почти нулевым простоем."
else
echo "❌ Инициализация не удалась! Отмена переключения, чтобы оставить текущий сайт в сети."
fi
EOF
chmod +x /root/update-web.sh
затем я запускаю его в корневом приглашении на моем сервере командой ./update-web.sh.
Вы можете автоматизировать его на определенное время, например, на 1 час ночи в воскресенье по вашему местному времени с помощью cron-задачи. Для меня 1:00 ночи по местному времени — это 8:00 утра по UTC, (вы можете определить дату UTC вашего сервера), введя date в командной строке, когда подключены по SSH.
Так что:
выполните эту команду, чтобы открыть планировщик задач вашего сервера:
crontab -e
(если он попросит вас выбрать редактор, нажмите ваш предпочитаемый редактор, 1 для nano, вероятно, самый простой)
я прокручиваю вниз комментариев и вставляю это:
0 8 * * 0 /root/update-web.sh >> /var/log/discourse-update.log 2>&1
(что означает запуск файла /root/update-web.sh в 0 минут, 8 часов (UTC), каждое воскресенье утром)
затем сохраните и выйдите (если вы используете nano):
Ctrl + Oдля сохранения.Enterдля подтверждения.Ctrl + Xдля выхода.
затем я могу запустить cat /var/log/discourse-update.log, когда просыпаюсь по воскресным утрам, чтобы проверить, выполнилась ли задача правильно. Если вы используете планировщик задач cron, вам нужно будет оставить маршрут страницы Workers.
Думаю, это все. Дайте знать, если у вас есть вопросы, ха-ха. Это гораздо проще, чем я сделал это, ха-ха. 
Вау! Я очень ценю это подробное руководство! 
Я только что сохранил твой ответ в заметки, чтобы вернуться к нему, когда скоро снова установлю Discourse. Я обязательно сообщу, как всё прошло, даже если до установки пройдёт некоторое время. Сейчас я заканчиваю работу над кодом, и только потом снова сосредоточусь на Discourse.
И я согласен, что страница «веб-сервер недоступен» выглядит некрасиво, а для неопытных пользователей это сообщение мало что значит. Наличие простой страницы обслуживания с пользовательским сообщением всегда предпочтительнее, даже если для её настройки требуется определённая работа.
Ещё раз, огромное спасибо за то, что нашёл время поделиться этим. Надеюсь, другим людям это тоже пригодится 
и вот в чём загвоздка.
Это не простое изменение, требующее дополнительной инфраструктуры, за которой нужно следить и которую нужно поддерживать, и, на мой взгляд, это совершенно не стоит нескольких секунд простоя.
Я понимаю, что вы имеете в виду, но это лишь один случай. А что, если что-то действительно сломается и мне потребуется больше времени, чем несколько секунд, чтобы это исправить?
Кроме того, откуда вы берете несколько секунд простоя, когда я наблюдал около 20 минут после установки плагинов?
Потому что в настройке с двумя контейнерами (ссылка на которую приведена в обоих наших сообщениях и является обязательной зависимостью) вы запускаете новую сборку с помощью ./launcher bootstrap web_only (в течение этого времени ваш сайт остается на 100% работоспособным), а затем просто уничтожаете и сразу запускаете новый, уже собранный контейнер (что занимает несколько секунд)
О, ясно, это всё ещё относится к настройке с двумя контейнерами. Я думал, ты имел в виду, что полностью создавать настройку с двумя контейнерами не стоит. То, что ты говоришь не стоит усилий — это только дополнительная работа над страницей обслуживания, верно?
Лично я — да.
Если вы хотите подстраховаться для веб-пользователей, которые зайдут на сайт в первые 30–60 секунд после обновления навигации, то страница техобслуживания вполне уместна.
Вам нужно взвесить пользу этого решения с затратами времени на поддержку соответствующей инфраструктуры.
Теперь я понял. Спасибо.
Итак, теперь я спрашиваю: с двумя контейнерами эти 20 минут всё ещё актуальны, единственное отличие в том, что я могу запустить процесс в одном из контейнеров, в том, который не находится в продакшене, а когда он будет готов, выполнить переключение. Так это работает?
Да, сборка контейнера всё ещё занимает некоторое время. К вашему сведению: убедитесь, что вашего сервера достаточно мощный, чтобы этот процесс мог происходить параллельно с обычной работой по обслуживанию вашего сообщества (по сути, самое главное — обеспечить достаточный объём оперативной памяти, поэтому крайне важно убедиться, что у вас достаточно места под своп). Сборка также загрузит как минимум одно ядро процессора, поэтому подумайте о сервере с 1–2 дополнительными ядрами.
и, кажется, менее эффективный сервер…?Я бы рекомендовал как минимум 4 ГБ ОЗУ и 3 ядра («vcpu») для такой конфигурации…
Для справки, так как это было запрошено в другой теме, (редакция: неверный) ответ: Any cheaper alternatives to Hetzner? - #2 by Canapin
Это единственный вариант, который соответствует этим требованиям… какая разница в цене…
Похоже, сейчас мне придется развернуть это в одном контейнере, а когда будут деньги (
), уже обновлю.
Спасибо за информацию, Роберт!
Я не согласен и считаю, что страница обслуживания того стоит. По моему опыту, когда люди видят страницу ошибки Discourse, первое, что они делают — это нажимают «Обновить», после чего видят кратковременную страницу обслуживания, которая затем автоматически перезагружает сайт по завершении переключения контейнеров. Настройка не требует больших усилий, и это нужно сделать только один раз. Во время пересборки с конфигурацией двух контейнеров процесс инициализации происходит в фоновом режиме, и пользователи могут продолжать пользоваться сайтом; именно переключение контейнеров вызывает кратковременный простой (в отличие от стандартной конфигурации с одним контейнером).
Стоимость сервера и его выбор — это совершенно другой вопрос, и ему должно быть посвящено отдельное обсуждение.