Вступление
В традиционной изменяемой серверной инфраструктуре серверы постоянно обновляются и модифицируются на месте. Инженеры и администраторы, работающие с инфраструктурой такого типа, могут подключаться по SSH к своим серверам, обновлять или понижать пакеты вручную, настраивать файлы конфигурации для каждого сервера отдельно и развертывать новый код непосредственно на существующих серверах. Другими словами, эти серверы изменчивы; они могут быть изменены после того, как они созданы. Инфраструктура, состоящая из изменяемых серверов, сама по себе может называться изменчивой, традиционной или (уничижительно) кустарной.
immutable infrastructure - это еще одна парадигма инфраструктуры, в которой серверы никогда не изменяются после их развертывания. Если что-то необходимо обновить, исправить или изменить каким-либо образом, новые серверы, построенные из общего образа с соответствующими изменениями, предоставляются для замены старых. После проверки они вводятся в эксплуатацию, а старые списываются.
Преимущества неизменяемой инфраструктуры включают в себя большую согласованность и надежность вашей инфраструктуры и более простой и предсказуемый процесс развертывания. Он смягчает или полностью предотвращает проблемы, которые часто встречаются в изменчивых инфраструктурах, таких как дрейф конфигурации и серверы типа «снежинка». Однако его эффективное использование часто включает в себя комплексную автоматизацию развертывания, быструю подготовку серверов в среде облачных вычислений и решения для обработки данных с состоянием или эфемерными данными, таких как журналы.
Остальная часть этой статьи будет:
-
Объясните концептуальные и практические различия между изменчивой и неизменной инфраструктурой
-
Опишите преимущества использования неизменяемой инфраструктуры и контекстуализируйте сложности
-
Дайте общий обзор деталей реализации и необходимых компонентов для неизменной инфраструктуры
Различия между изменяемой и неизменной инфраструктурой
Наиболее фундаментальное различие между изменяемой и неизменной инфраструктурой заключается в их центральной политике: компоненты первой предназначены для изменения после развертывания; компоненты последнего предназначены для того, чтобы оставаться неизменными и в конечном итоге заменяться. В этом руководстве эти компоненты рассматриваются как серверы, но существуют и другие способы реализации неизменяемой инфраструктуры, например, с контейнерами, в которой применяются те же концепции высокого уровня.
Чтобы углубиться, существуют как практические, так и концептуальные различия между изменяемой и неизменяемой инфраструктурой на основе сервера.
Концептуально говоря, два вида инфраструктуры сильно различаются в подходах к обработке серверов (например, создано, поддерживается, обновляется, уничтожается). Это обычно иллюстрируется аналогией «домашние животные против крупного рогатого скота».
Практически говоря, изменяемая инфраструктура - это гораздо более старая инфраструктурная парадигма, которая предшествует основным технологиям, таким как виртуализация и облачные вычисления, которые делают неизменными инфраструктуры возможными и практичными. Знание этой истории помогает контекстуализировать концептуальные различия между ними и последствия использования того или другого в современной инфраструктуре.
В следующих двух разделах эти различия будут обсуждаться более подробно.
Практические отличия: облачность
До того, как виртуализация и облачные вычисления стали возможными и широко доступными, серверная инфраструктура была сосредоточена вокруг физических серверов. Создание этих физических серверов было дорогостоящим и требовало много времени; Первоначальная настройка может занять дни или недели из-за того, сколько времени потребовалось для заказа нового оборудования, настройки машины, а затем ее установки вcolo или аналогичном месте.
Изменчивая инфраструктура берет свое начало здесь. Поскольку стоимость замены сервера была очень высокой, было бы наиболее целесообразно продолжать использовать серверы, на которых вы работали, как можно дольше с минимальным временем простоя. Это означало, что было внесено много изменений для обычных развертываний и обновлений, а также для специальных исправлений, настроек и исправлений, когда что-то пошло не так. Следствием частых ручных изменений является то, что серверы трудно копировать, что делает каждый из них уникальным и хрупким компонентом всей инфраструктуры.
Появлениеvirtualization and on-demand/cloud computing стало поворотным моментом в серверной архитектуре. Виртуальные серверы были дешевле, даже в масштабе, и их можно было создавать и уничтожать за считанные минуты, а не дни или недели. Это впервые сделало возможными новые рабочие процессы развертывания и методы управления серверами, такие как использованиеconfiguration management илиcloud APIs для быстрой, программной и автоматической подготовки новых серверов. Скорость и низкая стоимость создания новых виртуальных серверов - вот что делает принцип неизменности практичным.
Традиционные изменяемые инфраструктуры изначально создавались, когда использование физических серверов диктовало возможности их управления, и продолжали развиваться по мере совершенствования технологий. Парадигма изменения серверов после развертывания все еще распространена в современной инфраструктуре. Напротив, неизменяемые инфраструктуры изначально разрабатывались с учетом технологий на основе виртуализации для быстрого предоставления компонентов архитектуры, таких как виртуальные серверы облачных вычислений.
Концептуальные различия: домашние животные против крупного рогатого скота, снежинки против фениксов
Принципиальное концептуальное изменение, которое продвинули облачные вычисления, заключалось в том, что серверы можно считать одноразовыми. Чрезвычайно нецелесообразно рассматривать отказ от физических серверов и их замену, но с виртуальными серверами это не только возможно, но и просто и эффективно.
Серверы в традиционной изменяемой инфраструктуре были незаменимыми, уникальными системами, которые должны были постоянно работать. Таким образом, они были как домашние животные: единственные в своем роде, неповторимые, за которыми ухаживали вручную. Потеря может быть разрушительной. Серверы в неизменяемой инфраструктуре, с другой стороны, являются одноразовыми и их легко копировать или масштабировать с помощью автоматизированных инструментов. Таким образом, они похожи на скот: один из многих в стаде, где ни один человек не является уникальным или незаменимым.
ПроцитируемRandy Bias, который первым применил pets vs. аналогия с облачными вычислениями:
По старинке мы относимся к нашим серверам как к домашним животным, например к почтовому серверу Бобу. Если Боб упадет, все руки на палубе. Генеральный директор не может получить свою электронную почту, и это конец света. По-новому, серверы нумеруются, как скот в стаде. Например, с www001 по www100. Когда один сервер выходит из строя, он вынимается, снимается и заменяется на линии.
Еще один похожий способ проиллюстрировать последствия различий в том, как обрабатываются серверы, - это концепции серверов «снежинка» и серверов Феникс.
Snowflake servers похожи на домашних животных. Это серверы, которые управляются вручную, часто обновляются и настраиваются на месте, что приводит к уникальной среде. Phoenix servers похожи на крупный рогатый скот. Это серверы, которые всегда создаются с нуля, и их легко воссоздать (или «восстать из пепла») с помощью автоматизированных процедур.
Неизменяемые инфраструктуры почти полностью состоят из серверов крупного рогатого скота или феникса, в то время как изменяемые инфраструктуры допускают использование некоторых (или многих) домашних животных или серверов-снежинок. В следующем разделе обсуждаются последствия обоих.
Преимущества неизменной инфраструктуры
Чтобы понять преимущества неизменных инфраструктур, необходимо учитывать недостатки изменяемой инфраструктуры в контексте.
Серверы в изменчивой инфраструктуре могут страдать от дрейфа конфигурации, то есть, когда недокументированные, импровизированные изменения приводят к тому, что конфигурации серверов все больше расходятся друг с другом и с проверенной, утвержденной и первоначально развернутой конфигурацией. Эти все более похожие на снежинки серверы сложно воспроизводить и заменять, что затрудняет масштабирование и восстановление после проблем. Даже репликация проблем для их устранения становится сложной из-за сложности создания промежуточной среды, соответствующей производственной среде.
Важность или необходимость различных конфигураций сервера становится неясной после многих ручных модификаций, поэтому обновление или изменение любой из них может иметь непреднамеренные побочные эффекты. Даже в лучшем случае внесение изменений в существующую систему не гарантированно работает, а это означает, что развертывания, в которых это делается, могут привести к сбою или переводу сервера в неизвестное состояние.
С учетом этого основными преимуществами использования неизменяемой инфраструктуры являются простота развертывания, надежность и согласованность, которые в конечном итоге сводят к минимуму или устраняют многие общие болевые точки и точки отказа.
Известное хорошее состояние сервера и меньше сбоев развертывания
Все развертывания в неизменяемой инфраструктуре выполняются путем предоставления новых серверов на основе проверенного и управляемого версиями образа. В результате эти развертывания не зависят от предыдущего состояния сервера, и, следовательно, не могут из-за этого потерпеть неудачу - или только частично завершиться.
Когда новые серверы подготовлены, их можно протестировать перед вводом в эксплуатацию, сократив фактический процесс развертывания до одного обновления, чтобы сделать новый сервер доступным, например, обновление балансировщика нагрузки. Другими словами, развертывания становятсяatomic: либо они завершаются успешно, либо ничего не меняется.
Это делает развертывание намного более надежным, а также гарантирует, что состояние каждого сервера в инфраструктуре всегда известно. Кроме того, этот процесс позволяет легко реализоватьblue-green deployment илиrolling releases, что означает отсутствие простоев.
Нет конфигурации дрейфа или серверов-снежинок
Все изменения конфигурации в неизменяемой инфраструктуре реализуются путем проверки обновленного образа в системе управления версиями с документацией и использования автоматизированного унифицированного процесса развертывания для развертывания серверов замены с этим образом. Доступ оболочки к серверам иногда полностью ограничен.
Это предотвращает сложные или трудно воспроизводимые настройки, устраняя риск появления серверов-снежинок и дрейфа конфигурации. Это также предотвращает ситуации, когда кому-то нужно изменить плохо понятый производственный сервер, который подвержен высокому риску ошибки и может привести к простою или непреднамеренному поведению.
Согласованные условия постановки и легкое горизонтальное масштабирование
Поскольку все серверы используют один и тот же процесс создания, крайние случаи развертывания отсутствуют. Это предотвращает беспорядочные или несовместимые промежуточные среды, делая тривиальным копирование производственной среды, а также упрощаетhorizontal scaling, беспрепятственно позволяя вам добавлять больше идентичных серверов в вашу инфраструктуру.
Простые процессы отката и восстановления
Использование контроля версий для сохранения истории изображений также помогает в решении производственных проблем. Тот же процесс, который используется для развертывания новых образов, также можно использовать для отката к более старым версиям, добавляя дополнительную устойчивость и сокращая время восстановления при обработке простоев.
Детали реализации неизменной инфраструктуры
Неизменяемая инфраструктура сопряжена с некоторыми требованиями и нюансами в деталях ее реализации, особенно по сравнению с традиционной изменяемой инфраструктурой.
Технически возможно реализовать неизменную инфраструктуру независимо от каких-либо принципов автоматизации, инструментов или разработки программного обеспечения, просто придерживаясь ключевого принципа неизменности. Однако нижеприведенные компоненты (примерно в порядке приоритета) настоятельно рекомендуется для практического применения в масштабе:
-
Servers in a cloud computing environment или другая виртуализированная среда (like containers, хотя это меняет некоторые другие требования ниже). Ключевым моментом здесь является наличие единичных экземпляров с быстрой инициализацией из пользовательских изображений, а также автоматическим управлением для создания и уничтожения с помощью API или подобного.
-
Full automation of your entire deployment pipeline, в идеале включая проверку изображения после создания. Настройка этой автоматизации значительно увеличивает первоначальные затраты на внедрение этой инфраструктуры, но это разовые затраты, которые быстро амортизируются.
-
Aservice-oriented architecture, разделяющая вашу инфраструктуру на модульные, логически дискретные единицы, которые обмениваются данными по сети. Это позволяет вам в полной мере использовать предложения облачных вычислений, которые составляютsimilarly service-oriented (например, IaaS, PaaS).
-
stateless, volatile application layer, который включает ваши неизменяемые серверы. Все, что находится здесь, может быть разрушено и восстановлено быстро в любое время (изменчиво) без потери данных (без сохранения состояния).
-
Apersistent data layer, который включает:
-
Centralized logging с дополнительными сведениями о развертывании сервера, такими как идентификация образа с помощью версии или Git commit SHA. Поскольку серверы являются одноразовыми (и часто утилизируются) в этой инфраструктуре, внешнее хранение журналов и метрик позволяет выполнять отладку, даже когда доступ к оболочке ограничен или после разрушения сервера.
-
External data stores для баз данных и любых других данных с отслеживанием состояния или эфемерных данных, таких какDBaaS/cloud databases иobject or block storage (предоставляемые облаком или самоуправляемые). Вы не можете полагаться на локальное хранилище, когда серверы нестабильны, поэтому вам нужно хранить эти данные в другом месте.
-
-
Dedication from engineering and operations teams, чтобы сотрудничать и придерживаться подхода. Несмотря на всю простоту конечного продукта, в неизменной инфраструктуре много движущихся частей, и никто не будет знать все это. Кроме того, некоторые аспекты работы в этой инфраструктуре могут быть новыми или выходить за пределы комфортных зон людей, например, отладка или выполнение одноразовых задач без доступа к оболочке.
Существует много разных способов реализации каждого из этих компонентов. Выбор одного из них во многом зависит от личных предпочтений и знакомства, а также от того, какую часть своей инфраструктуры вы хотите построить самостоятельно, а не полагаться на платную услугу.
CI/CD tools может быть хорошей отправной точкой для автоматизации конвейера развертывания; Compose - вариант для решения DBaaS; rsyslog иELK - популярные варианты централизованного ведения журнала; Netflix’s Chaos Monkey, который случайным образом убивает серверы в вашей производственной среде, является настоящим испытанием огнем для вашей окончательной настройки.
Заключение
В этой статье описывается, что такое неизменяемая инфраструктура, концептуальные и практические различия между ней и изменяемой инфраструктурой старого стиля, преимущества ее использования и подробности ее реализации.
Знать, стоит ли вам подумать о переходе на неизменную инфраструктуру или нет, может быть сложно, и не существует четко определенного предела или точки перегиба. Один из способов начать - применить некоторые из методов проектирования, рекомендованных в этой статье, например управление конфигурацией, даже если вы все еще работаете в изменчивой среде. Это облегчит переход к неизменности в будущем.
Если у вас есть инфраструктура с большинством вышеперечисленных компонентов, и вы сталкиваетесь с проблемами масштабирования или чувствуете разочарование в связи с непостоянством процесса развертывания, это может быть хорошим временем для начала оценки того, как неизменность может улучшить вашу инфраструктуру.