Поиск по сайту:

Что такое неизменяемая инфраструктура?


Введение

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

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

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

Остальная часть этой статьи будет:

  • Объясните концептуальные и практические различия между изменяемой и неизменной инфраструктурой.
  • Описать преимущества использования неизменяемой инфраструктуры и контекстуализировать сложности.
  • Общий обзор деталей реализации и необходимых компонентов для неизменной инфраструктуры.

Различия между изменяемой и неизменной инфраструктурой

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

Чтобы углубиться, существуют как практические, так и концептуальные различия между изменяемой и неизменяемой инфраструктурой на основе сервера.

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

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

В следующих двух разделах мы поговорим об этих различиях более подробно.

Практические отличия: использование облака

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

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

Появление облачных API для быстрой, программной и автоматической подготовки новых серверов. Скорость и низкая стоимость создания новых виртуальных серверов — вот что делает принцип неизменности практичным.

Традиционные изменяемые инфраструктуры изначально разрабатывались, когда использование физических серверов определяло возможности их управления, и продолжали развиваться по мере совершенствования технологий с течением времени. Парадигма изменения серверов после развертывания все еще распространена в современной инфраструктуре. Напротив, неизменяемые инфраструктуры с самого начала разрабатывались для использования технологий на основе виртуализации для быстрого предоставления компонентов архитектуры, таких как виртуальные серверы облачных вычислений.

Концептуальные различия: домашние животные против крупного рогатого скота, снежинки против фениксов

Фундаментальное концептуальное изменение, которое продвинули облачные вычисления, заключалось в том, что серверы можно было считать одноразовыми. Запрещающе нецелесообразно рассматривать вопрос об отказе от физических серверов и их замене, но с виртуальными серверами это не только возможно, но и просто и эффективно.

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

Процитируем Рэнди Биаса, который первым применил аналогию домашних животных и крупного рогатого скота к облачным вычислениям:

По старинке мы относимся к нашим серверам как к домашним животным, например, к почтовому серверу Бобу. Если Боб упадет, все руки на палубе. Генеральный директор не может получить свою электронную почту, и это конец света. По-новому серверы пронумерованы, как скот в стаде. Например, от www001 до www100. Когда один сервер выходит из строя, его вывозят обратно, расстреливают и заменяют на линии.

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

Серверы Phoenix похожи на крупный рогатый скот. Это серверы, которые всегда строятся с нуля, и их легко воссоздать (или «восстановить из пепла») с помощью автоматизированных процедур.

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

Преимущества неизменяемой инфраструктуры

Чтобы понять преимущества неизменяемых инфраструктур, необходимо контекстуализировать недостатки изменяемых инфраструктур.

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

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

Имея это в виду, основными преимуществами использования неизменяемой инфраструктуры являются простота развертывания, надежность и согласованность, которые в конечном итоге минимизируют или устраняют многие распространенные проблемы и точки отказа.

Заведомо хорошее состояние сервера и меньшее количество сбоев при развертывании

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

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

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

Нет дрейфа конфигурации или серверов-снежинок

Все изменения конфигурации в неизменяемой инфраструктуре реализуются путем проверки обновленного образа в системе контроля версий с документацией и использования автоматизированного унифицированного процесса развертывания для развертывания заменяющих серверов с этим образом. Доступ оболочки к серверам иногда полностью ограничен.

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

Согласованные промежуточные среды и простое горизонтальное масштабирование

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

Простые процессы отката и восстановления

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

Детали реализации неизменяемой инфраструктуры

Неизменяемая инфраструктура имеет некоторые требования и нюансы в деталях реализации, особенно по сравнению с традиционными изменяемыми инфраструктурами.

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

  • Серверы в среде облачных вычислений или другой виртуализированной среде (например, контейнеры, хотя это изменяет некоторые другие требования, указанные ниже). Ключевым моментом здесь является наличие изолированных экземпляров с быстрой подготовкой из пользовательских образов, а также автоматизированное управление созданием и уничтожением через API или подобное.
  • Полная автоматизация всего конвейера развертывания, в идеале включая проверку образа после создания. Настройка этой автоматизации значительно увеличивает первоначальные затраты на внедрение этой инфраструктуры, но это единовременные затраты, которые быстро окупаются.
  • Аналогично сервис-ориентированный (например, IaaS, PaaS).
  • Нестабильный прикладной уровень без сохранения состояния, который включает ваши неизменяемые серверы. Здесь все может быть быстро уничтожено и перестроено в любое время (изменчиво) без потери данных (без сохранения состояния).
  • Постоянный уровень данных, который включает в себя:
    • Централизованное ведение журнала с дополнительными сведениями о развертывании сервера, такими как идентификация образа с помощью версии или Git commit SHA. Поскольку в этой инфраструктуре серверы одноразовые (и часто удаляются), внешнее хранение журналов и метрик позволяет выполнять отладку, даже если доступ к оболочке ограничен или после того, как сервер был уничтожен.
    • Внешние хранилища данных для баз данных и любых других данных с отслеживанием состояния или эфемерных данных, таких как объектное или блочное хранилище (либо облачное, либо самоуправляемое). Вы не можете полагаться на локальное хранилище, когда серверы нестабильны, поэтому вам нужно хранить эти данные в другом месте.

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

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

    Chaos Monkey от Netflix, который случайным образом убивает серверы в вашей производственной среде, является настоящим испытанием для вашей окончательной настройки.

    Заключение

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

    Знать, следует ли и когда следует подумать о переходе на неизменяемую инфраструктуру, может быть сложно, и нет четко определенной точки отсечки или переломного момента. Один из способов начать — реализовать некоторые приемы проектирования, рекомендованные в этой статье, такие как управление конфигурацией, даже если вы все еще работаете в среде, в значительной степени изменяемой. Это облегчит переход к неизменности в будущем.

    Если у вас есть инфраструктура с большинством из перечисленных выше компонентов, и вы столкнулись с проблемами масштабирования или чувствуете разочарование из-за неуклюжести процесса развертывания, самое время начать оценивать, как неизменность может улучшить вашу инфраструктуру.

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