Вопрос: Как обновить веб-сервер в реальном времени?


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

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

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


5
2017-07-12 22:28


Источник


еще не могу комментировать SF. Можете ли вы предоставить более подробную информацию о продукте? Какая платформа? Windows, * Nix, OSX, Cloud Что такое платформа кода? .NET, python, php и т. Д. Есть много вариантов, когда дело доходит до развертывания. Хотя это лучшие практики, многие решения связаны с рассматриваемым продуктом. Чем больше деталей вы можете предоставить, тем более точными могут предложить люди. - Taylor
Вы должны «отредактировать» свой вопрос и перенести текст из своих комментариев в суть вопроса. Там будет читаться больше людей. - Stefan Lasiewski
сделано и спасибо - radman
Что именно вы хотите обновить? Только mediawiki и wordpress? Или только ОС? Или все вместе? - Raffael Luthiger


Ответы:


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

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

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

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


5
2017-07-12 23:47



+1 Это меня насторожило, почему этот ответ был подавлен. Интересно, что кому-то это не понравилось. - John Gardeniers
Единственное, что приходит на ум, состоит в том, что, возможно, кто-то думал, что я слишком долго наматывался, и предлагаю чрезмерный процесс для шкалы опроса. Было бы неплохо, если бы люди отказались от комментариев, чтобы сказать, почему они сбрасывают вниз, а затем, если у вас есть что-то действительно неправильное, вы бы знали ... - David Spillett


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


1
2017-07-12 23:34



+1 capistrano выглядит полезным - radman


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

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

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

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

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

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


1
2017-07-13 00:08