За последнее время появилось несколько практических подходов к управлению динамическими виртуальными машинами в облачной среде:
- Push (централизованное распространение/обновление)
Подготовка и обновление новых виртуальных машин осуществляется посредством централизованного механизма. Инструменты управления инфраструктурой используют различные схемы для защиты учетных данных, используемых для автоматизации, от хакеров. - Pull (индивидуальная настройка/обновление)
Каждый шаблон виртуальной машины включает инструменты управления конфигурацией и сценарий инициализации, который выполняется при запуске VM. Скрипт подключается к серверам, которые управляют облачной средой, для регистрации VM. Работающие экземпляры VM должны самостоятельно выполнять проверку доступных обновлений для поддержания актуальности. - Immutable (неизменяемость экземпляров)
Процесс подготовки гарантирует, что новые экземпляры виртуальных машин будут полностью сконфигурированы и подготовлены до их активации в сети. После запуска экземпляр никогда не изменяется. Когда требуются обновления или исправления, новые экземпляры настраиваются из источников и/или шаблонов по мере необходимости, а старые экземпляры уничтожаются. Инструмент управления облачной инфраструктурой делает этот процесс невидимым для приложений, которые, как представляется, «всегда включены» с внешней точки зрения.
Приведённое описание является очень высокоуровневым. Есть множество деталей, которые могут варьироваться от одной установки к другой. В общем случае стратегии “push”, “pull” и неизменяемых экземпляров представляют собой спектр от менее надежного и сложного для масштабирования до более безопасного и легкого для масштабирования.
Применение неизменяемых экземпляров упрощает обслуживание за счёт устранения необходимости в синхронизации конфигурации экземпляров. Облачные среды предназначены для уничтожения и создания виртуальных машин “на лету” и незаметно для приложений. Окружающая среда управляет переключением клиентского трафика между экземплярами таким образом, чтобы все транзакции были завершены до уничтожения экземпляра, которым они были запущены. Окружающая среда также формирует журнал событий таким образом, чтобы обеспечить возможность отслеживания проблем, связанных с приложением, независимо от создания и уничтожения экземпляров виртуальных машины.
Первоначально эти функции были предназначены для поддержки идеи эластичного облака .Это означает, что количество серверов в данной категории, поддерживающих данное приложение, может динамически увеличиваться или уменьшаться в зависимости от нагрузки. Чтобы это происходило беспрепятственно и незаметно для приложений, среда должна иметь возможность запускать и отключать экземпляры виртуальной машины во время работы приложения, не теряя никаких данных журнала или обновлений для файлов приложений и баз данных и не оказывая влияния на конечных пользователей.
Благодаря этой функциональности, можно просто заменять экземпляры виртуальных машин, а не сохранять их в течение длительного времени, что вызывает необходимость устанавливать на них обновления. Данный подход способствовал появлению привело к так называемой стратегии феникс-серверов . Названные в честь мифической птицы, которая возрождается из пепла, феникс-серверы рутинно уничтожаются и перестраиваются по расписанию, даже когда нет обновлений.
Неизменяемый экземпляр не может быть изменен, поэтому серверы, управляемые таким образом, не подвержены проблеме расхождения конфигураций.
Вредоносные программы могут быть внедрены в запущенные экземпляры, но они просуществуют только до того, как феникс “сожжёт” себя и снова возникнет, при этом будет создан на основе защищённого от вирусов шаблоне, находящимся под управлением контроля версий. Таким образом, неизменяемые феникс-серверы phoenix обеспечивают высокий уровень защиты. Однако опасайтесь получить ложное чувство безопасности, поскольку профессиональные кибер-преступники всё своё время тратят на поиск способа проникнуть в ваши системы, в то время как у вас есть много других вещей, которые нужно делать в течение дня, Вы никогда не сможете полностью сорвать их планы, но вы можете предпринять шаги, чтобы максимально усложнить им задачу.
Несмотря на то, что неизменяемые серверы и феникс-серверы помогают решить проблему безопасности, они пока не получили широкого применения. Вместо этого большинство системных администраторов следуют устаревшему подходу: они стараются сохранить каждый экземпляр живым как можно дольше. Ранее это было разумной стратегией из-за стоимости простоя и задержки при перезапуске сбойных систем. В современной облачной среде та же стратегия не приносит ценности. Напротив, она способствует увеличению риска, стоимости и сложности.
По материалам статьи.
Это вы про контейниризацию, докер и kubernetes? Т.е. это теперь феникс-серверами зовется? С трудом догадался… Эффективно в развертывание и поддержке когда речь идет хотябы о десятках (если не сотнях) серверов…