Недавно я экспериментировал с различными инструментами управления облаком, такими как RightScale, Scalr, пользовательскими скриптами для управления множеством серверов, на каждом из которых размещено несколько ролей (приложение, база данных, балансировщик нагрузки, очереди заданий и т. Д.).
Единственное, чего мне не хватает в большинстве решений, так это способа скользящего развертывания, то есть последовательного выполнения развертываний на нескольких серверах с одинаковой ролью. Например, я не хочу создавать все свои веб-серверы одновременно, так как это почти наверняка приведет к простоям или 500 секундам для моих клиентов. Я бы предпочел строить один или два сервера за раз, в то время как другие серверы все еще доступны для обработки запросов.
Другой альтернативой, очевидно, является запуск новых серверов, которые автоматически обновляются при загрузке, но это не так рентабельно и, скорее всего, требует больше времени для завершения сборки (быстрее построить на существующем сервере, чем запускать новый сервер и убейте старые).
Мы все слышали о крупных компаниях, имеющих знаменитую кнопку «нажми, чтобы построить» (такие компании, как Twilio, Etsy и т. Д.), Но похоже, что у всех есть собственные реализации этого. Я не говорю о простом цикле ssh, clusterssh или даже о mcollective - я предпочитаю что-то с приятным простым интерфейсом, которое позволяет мне указать что-то вроде RightScript или Scalr-скрипта для запуска на наборе серверов с конкретную роль, и он строит их последовательно.
Кто-нибудь знает простые способы сделать это, или это кандидат на новый проект с открытым исходным кодом?
Используйте Puppet и MCollective вместе. Puppet может выполнять большую часть вашей работы по сборке. MCollective позволяет выбирать узлы и планировать их.
http://www.devco.net/archives/2010/03/17/scheduling_puppet_with_mcollective.php
Я не знаю ни одной службы, которая поможет в этом типе обновлений. Проблема в том, что приложение нужно разрабатывать с учетом этого. Вы часто видите, что серверы настроены на использование сервера x в качестве сервера базы данных или сервера y в качестве сервера кеширования. Это самая большая проблема, которую я вижу, когда начинаю смотреть на наше устаревшее программное обеспечение и думать о том, как мы можем автоматизировать процессы обновления и т. Д.
У нас была такая же проблема, как и у вас. Решение для нас не было слишком сложным, потому что все наши последние продукты изначально были предназначены для таких обновлений, потому что мы видели, насколько это может быть сложно. При разработке мы старались избегать тесно связанных сервисов. Это позволяет нам запустить целую новую группу серверов в промежуточной зоне. Когда мы закончили тестирование промежуточной области, мы продвигаем промежуточную область в производственную среду, изменяя CNAME на DNS-сервере. Этот процесс происходит без простоев и низкого риска обновления серверов с неправильной конфигурацией и т. Д. Мы достигли этого, используя http в качестве основного протокола связи и локальный DNS-сервер.
Я понимаю, что, вероятно, это непростая задача - перепроектировать все ваше приложение в соответствии с конкретной архитектурой, которая хорошо работает с непрерывными обновлениями, но это то, что мы нашли наиболее простым решением. Знаменитая кнопка «нажми, чтобы построить» не должна быть только для большой рыбы, даже маленький тунец может получить часть этого действия. В зависимости от того, насколько сложным или простым является ваше приложение, будет определяться, насколько сложно или легко создать собственную кнопку «нажми, чтобы построить».
Я развернул вебистрано, но мне так и не удалось заставить наших разработчиков поработать с ним. они всегда находили способ испортить развертывание.