Я согласен с рекомендацией Райана использовать сине-зеленый подход, хотя этот термин может быть незнаком тем, кто плохо знаком с развертыванием облачных серверов. Мартин Фаулер резюмирует проблему, которую он решает в BlueGreenDeployment:
Одной из проблем, связанных с автоматизацией развертывания, является сам переход, когда программное обеспечение переносится с финальной стадии тестирования на реальное производство. Обычно это нужно делать быстро, чтобы свести к минимуму время простоя. Сине-зеленый подход к развертыванию делает это, гарантируя, что у вас есть две производственные среды, максимально идентичные. В любое время один из них, например, синий, активен. Когда вы готовите новую версию своего программного обеспечения, вы выполняете последний этап тестирования в зеленой среде. После того, как программное обеспечение заработало в зеленой среде, вы переключаете маршрутизатор, чтобы все входящие запросы шли в зеленую среду — синяя сейчас простаивает.
Решение этой проблемы является одним из основных преимуществ PaaS.
Тем не менее, для исторического контекста стоит отметить, что эта сине-зеленая стратегия не нова для облачных вычислений. Позвольте мне подробно остановиться на одном из «старых» способов решения этой проблемы:
Предположим, у меня есть веб-сайт, размещенный на выделенном сервере myexample.com. IP-адрес моего общедоступного сервера («синий») будет представлен в записи DNS «@» или в виде псевдонима CNAME; другой сервер («зеленый») будет размещать более новую версию приложения. Чтобы публично протестировать новое приложение, не влияя на действующую производственную среду, я просто обновляю /etc/hosts, чтобы сопоставить доменное имя верхнего уровня с IP-адресом зеленого сервера. Например:
129.42.208.183 www.myexample.com myexample.com
Как только я удалю локальные записи DNS и закрою все браузеры, все запросы будут направлены в зеленую предварительную среду. Убедившись, что все работает должным образом, я обновляю запись DNS для живой среды (в данном случае myexample.com). Предполагая, что DNS имеет достаточно короткое значение TTL, например 300 секунд, я обновляю значение записи A, если на Значение записи IP или CNAME, если используется псевдоним, и изменение будет распространено на DNS-серверы в течение нескольких минут. Чтобы подтвердить распространение новых значений DNS, я комментирую вышеупомянутое изменение /etc/hosts, очищаю локальные записи DNS, а затем запускаю traceroute. Предполагая, что он правильно разрешается локально, я выполняю последнюю двойную проверку, все ли в порядке в остальном мире с помощью бесплатной онлайн-проверки DNS (например, whatsmydns.net).
Вышеприведенное предполагает обновление общедоступного сервера содержимого (например, сервер Apache, подключающийся к базе данных или серверу приложений); переход от предварительной версии к рабочей более сложен, если обновление применяется к центральной базе данных или аналогичному серверу транзакционных данных. Если это не слишком мешает посетителям сайта, я отключаю вход в систему и прекращаю все активные сеансы, фактически делая сайт доступным только для чтения. Затем я приступаю к обновлению внутреннего сервера почти так же, как описано ранее, т. е. переключаю предварительную зеленую переднюю часть для ссылки на репликацию в предварительной зеленой внутренней части, тестирую, затем, когда все проверено, переключаю зеленую переднюю часть на синий и снова включите вход. Вуаля.
Хорошей новостью является то, что с Bluemix применяется та же стратегия, что и выше, но она упрощена, поскольку нет необходимости возиться с записями DNS или отдельными серверами.
Вместо этого вы создаете два приложения: одно активное («синее»), а другое — предварительное («зеленое»). Вместо того, чтобы изменять записи DNS вашего сайта и ждать, пока обновление распространится по всему миру, вы можете обновить свое тестовое приложение (cf push Green добавляет новый код в ваше тестовое приложение), протестировать его с собственным URL-адресом (Green.ng.mybluemix.net), и как только вы убедитесь, что оно готово к работе, добавьте приложение в таблицу маршрутизации (cf map-route Green ng.mybluemix.net -n Blue), после чего оба приложения, «синее» и «зеленое», будут получать входящие запросы. Затем вы можете перевести предыдущую версию приложения в автономный режим, отключив ее (cf unmap-route Blue ng.mybluemix.net -n Blue).
Посетители сайта не будут сталкиваться с перебоями в обслуживании, и в отличие от «старого» способа, который я описал ранее, группе развертывания (а) не придется грызть ногти, ожидая распространения записей DNS по всему миру, прежде чем узнать, не работает ли что-то и (b) может немедленно вернуться к предыдущей известной рабочей рабочей версии, если после развертывания будет обнаружена серьезная проблема.
person
Dan Kehn
schedule
13.04.2015
