Назад | Перейти на главную страницу

Как обновить работающий веб-сервер?

Я занимаюсь настройкой веб-сервера, и мне было интересно, каким будет лучший метод обновления веб-сайта, который он содержит. Я знаю, что у меня должен быть какой-то «тестовый» сервер, работающий параллельно, чтобы изменения можно было опробовать в первую очередь, прежде чем они вступят в силу. Итак, насколько точно тестовый сервер должен имитировать производственную коробку, и есть ли какой-либо известный способ простого развертывания тех же изменений в производственной коробке после того, как они были протестированы?

Я действительно хотел бы иметь надежный метод тестирования и применения изменений к производственному веб-сайту, и любые советы по этому поводу очень ценны.

Платформа:
Работает на сервере linux ubuntu. Запуск mediawiki, wordpress и почтовый сервер. Имею root-доступ к ящику по ssh. У Mediawiki и Wordpress есть серверная часть PHP и MySQL. Почтовый сервер также использует базу данных MySQL.

Мы используем серию виртуальных машин, по крайней мере, по одной для каждого действующего клиентского сервера, которые синхронизируются с действующими машинами (за исключением того, что некоторые данные изменяются, поэтому мы не работаем с личной идентификационной или иной конфиденциальной информацией).

Любая серия изменений, которые должны быть внесены в производственную машину, объединяются в патч, который состоит из любых необходимых файлов / сценариев и сценария (сценарий оболочки, обычно для среды, подобной Unix, пакетный файл или сценарий vbs или сценарий PowerShell под Windows), который применяет эти файлы / сценарии соответствующим образом. Затем мы берем соответствующую виртуальную машину, обновляем ее базы данных из копии производственной среды, если копия виртуальной машины становится слишком устаревшей (не забывая повторно запускать соответствующие сценарии SQL для очистки или рандомизации конфиденциальных данных), и снимок состояния в этом состоянии (снимки поддерживаются виртуальным боксом и большинством продуктов vmware, включая бесплатный «сервер vmware» и, вероятно, большинство других решений для виртуализации тоже). Затем мы применяем патч так же, как и к производственному серверу, запустив основной сценарий управления. Если при применении изменений возникают ошибки, виртуальная машина откатывается к моментальному снимку (что занимает не более нескольких десятков секунд), поэтому исправление можно обновить и повторить попытку. Это повторяется по мере необходимости, пока пластырь не нанесет чистый. Как только это будет сделано, некоторых тестировщиков просят попробовать все это, чтобы убедиться, что новые вещи работают, а другие старые не сломались (сколько времени вы потратите на это, зависит от масштаба и серьезности изменений, а также вашего уровня паранойя). Если обнаружены проблемы, цикл отката, редактирования и повторного применения повторяется, пока все не станет хорошо. Как только все станет хорошо, если позволяет время, на всякий случай запускается последний цикл отката, исправления и тестирования. Как только все это будет сделано, у вас, надеюсь, будет патч, который можно применить к производственной среде, запустив один скрипт с соответствующими параметрами (т.е. соответствующими паролями, поскольку учетные данные для проверки подлинности на тестовых виртуальных машинах должны отличаться от данных на производственных машинах), и вы можете будьте уверены, что он нанесет чистый и даст желаемый эффект без (или как можно меньше) нежелательных.

Всегда делайте свежие резервные копии, прежде чем применять что-либо существенное к производственной системе, независимо от того, сколько времени вы потратили на тестирование обновления, на всякий случай, и всегда планируйте хотя бы небольшое время простоя, в течение которого вы можете не пускать других пользователей и дайте получившейся обновленной системе (-ам) дополнительную проверку на паранойю (и откатите их до последней резервной копии, если что-то пошло не так - если ваша производственная среда виртуализирована, то средство создания снимков может быть здесь также полезно).

Как правило, это может работать в любой среде.

Это действительно зависит от вашего определения «вживую». например вы имеете в виду сервер со 100% работоспособностью, который не может выйти из строя, или просто общий вопрос об обновлении сайта.

Самое простое, что вы можете сделать, это просто включить FTP-доступ к вашему ящику / учетной записи / хранилищу, и если у вас есть только незначительные изменения, которые не нарушают ничего другого, просто перезапишите файл, пока сайт работает, а затем в следующий раз, когда кто-то обновит страницу , он должен загрузить новый файл.

Если, однако, вы вносите большие изменения, которые сломают другие элементы, у вас (IMHO) есть несколько вариантов:

  • Сделайте это, загрузите страницу за страницей и надейтесь, что никто не заметит / вы сделаете это достаточно быстро.
  • Выведите сайт из сети, внесите изменения и снова включите его.
  • Делай то, что делаю - (хотя я не отвечал за обновление ОГРОМНЫХ сайтов),
    1. Измените страницу блокировки IP на http-refresh в течение 5 секунд, ссылаясь на себя.
    2. Поместите подстановочный знак в ограничения IP.
    3. Загрузите изменения.
    4. Удалите блокировку IP.

Я считаю, что он работает эффективно и хорошо - многие пользователи даже не знают о простоях во время обновления. Если у вас есть магазин или аналогичный магазин, вероятно, стоит быть честным и написать на странице с ошибкой: «Мы выполняем обновления сайта, вернемся в Интернет в течение 2 минут» и т. Д.

Кроме того, приведенное выше предполагает, что вы протестировали изменения и все работает нормально - все, что вам нужно сделать, это несколько файловых операций, которые совсем не займут много времени.

Используйте капистрано (capistrano и руководство по PHP)
Среда тестирования должна максимально точно имитировать производственную среду и быть независимой (т.е. без общих данных и т. Д.).