В моем обновлении возникла ошибка
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 — нажмите кнопку Create application:
Затем используйте шаблон Hello World:
Затем дайте ему имя и нажмите Deploy:
Затем перейдите на страницу обзора для этой страницы технического обслуживания и нажмите Edit code:
И вставьте этот код в окно кода 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="en">
<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"
}
});
}
Это должно выглядеть примерно так. Нажмите Deploy, чтобы сохранить:
Шаг 2: Добавление маршрута
Теперь перейдите на страницу маршрутов Cloudflare Workers и нажмите кнопку Add route, чтобы открыть модальное окно нового маршрута, введите маршрут домена и выберите страницу Workers, которую вы только что создали, затем нажмите Save:
Шаг 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
Затем я запускаю его в командной строке root на моем сервере командой ./update-web.sh.
примечание: не выполняйте шаги ниже, если у вас нет платной учетной записи Cloudflare.
Вы можете автоматизировать это на определенное время, например, на 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, первое, что они делают — это нажимают «Обновить», после чего видят кратковременную страницу обслуживания, которая затем автоматически перезагружает сайт по завершении переключения контейнеров. Настройка не требует больших усилий, и это нужно сделать только один раз. Во время пересборки с конфигурацией двух контейнеров процесс инициализации происходит в фоновом режиме, и пользователи могут продолжать пользоваться сайтом; именно переключение контейнеров вызывает кратковременный простой (в отличие от стандартной конфигурации с одним контейнером).
Стоимость сервера и его выбор — это совершенно другой вопрос, и ему должно быть посвящено отдельное обсуждение.
Похоже, я сейчас нахожусь в нерешительности. Я понимаю, что вы имеете в виду, а также @merefield. Это приятная деталь, и если её нужно настраивать только один раз, то, полагаю, это не такая уж большая проблема?
В то же время, если в худшем случае это действительно займёт до 60 секунд, не каждый посетитель зайдёт на сайт ровно в нулевую секунду и будет ждать полминуты. Кто-то увидит «некрасивую» страницу 5 секунд, кто-то 20, а кто-то 60. Некоторые вообще её не увидят (мне кажется?), например, если они просто читают ответ или пишут его: переключение может произойти до того, как они нажмут ОТПРАВИТЬ, или до того, как закончат чтение темы и нажмут ОТВЕТИТЬ (или перейдут на другую страницу).
Моя проблема с маршрутизацией через nginx была связана скорее с 20-минутным простоем в конфигурации с одним контейнером. С возможностью использовать два контейнера и сокращением времени с 20 минут до максимум 60 секунд, я задумываюсь, актуальна ли эта проблема вообще? Особенно если я смогу добавить объявление вверху страницы, предупреждающее, что сайт будет недоступен всего несколько секунд в часы низкой нагрузки — тогда это не станет большой проблемой?
Мне нужно сесть и подумать. Настройка с двумя контейнерами определённо будет реализована, если я найду выгодное предложение по серверу.
Можешь объяснить это так, чтобы понял даже такой новичок, как я? Я пока не очень разбираюсь в воркерах…
Зачем ты добавляешь и удаляешь маршрут страницы воркеров, если его постоянное наличие не вызывает проблем? То есть, если я добавлю страницу технических работ, могу ли я действительно настроить её один раз, и с этого момента всегда подключаться к серверу по SSH через Терминал и выполнять все действия там, как это делаю с обычным контейнером, вообще не заходя в Cloudflare?
@merefield упоминал, что это (страница технических работ, воркеры и т. д.) тоже требует обслуживания, поэтому я задумался: это действительно что-то, что настраивается один раз и забывается, или нужно иногда выполнять какие-то действия?