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