Некоторые считают, что до контейнеров автоматизация инфраструктуры была чем-то вроде латания дыр. В любом случае сегодня ИТ-специалисты могут добиваться этой цели более эффективно, утверждают опрошенные порталом Enterprisers Project эксперты.

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

«Можно утверждать, что до контейнеров стандартизация инфраструктуры и ее автоматизация были чем-то вроде временного латания дыр, — объясняет технологический евангелист Red Hat Гордон Хафф. — Конечно, у нас были стандартные операционные среды (SOE) и средства управления конфигурацией, которые автоматизировали выделение ресурсов этим SOE и их постоянный мониторинг. Но для выполнения конкретных задач по-прежнему требовалось много серверов-„снежинок“, и развернутые образы могли со временем дрейфовать, даже если ПО управления конфигурацией пыталось обеспечить их соответствие требованиям».

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

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

1. Контейнеры и оркестровка

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

Неизменяемая инфраструктура

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

Архитектура микросервисов

Другой ключевой концепцией здесь является микросервисная архитектура, которая по существу означает разделение приложения на более мелкие дискретные компоненты, которые работают вместе как части более крупной системы. Помимо прочих преимуществ, микросервисы позволяют ИТ-группам самостоятельно управлять этими более мелкими сервисами, вместо того чтобы возвращаться (и повторно развертывать) все приложение каждый раз, когда необходимо изменение. Микросервисы очень хорошо сочетаются с контейнерами, так что каждый сервис может быть упакован независимо. Следует отметить, что не все существующие приложения хорошо подходят для архитектуры микросервисов, и это нормально.

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

«Путь к полностью неизменяемой инфраструктуре может занять время, особенно для [большинства] организаций, у которых есть приложения доконтейнерой эпохи, — говорит Майкл Фишер, руководитель группы продуктов OpsRamp. — Однако это не означает, что планирование и разработка архитектуры должны быть остановлены до тех пор, пока все приложение не будет сконфигурировано для работы на автономных микрофронт- и бэкэндах. ИТ-группы должны итерационно приоритизировать и контейнеризировать сервисы до тех пор, пока не будет выполнен перевод всего приложения».

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

Фишер рассматривает этот процесс равно как творческий, так и технический: «Чтобы понять, что контейнеризировать, нужно оглянуться назад и понять основные сервисы и строительные блоки вашего приложения».

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

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

2. Непрерывная интеграция и доставка (CI/CD), построение конвейеров и создание артефактов

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

С неизменяемой инфраструктурой вы должны перестать мыслить в рамках традиционных терминов, таких как серверы как таковые, даже несмотря на то, что они по-прежнему технически актуальны. Скорее, вам надо начать мыслить в терминах построения конвейеров и создания артефактов. Последнее — это то, что вы автоматически развертываете, удаляете и/или заменяете неизменяемой инфраструктурой.

CI/CD стало критически важной практикой с соответствующим набором инструментов; надежность конвейера CI/CD зависит от того, как он выстроен.

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

По сути, конвейер CI/CD — это то, как контейнерные приложения проходят путь от кода к хранилищу или производственной эксплуатации с минимальным человеческим участием.

Джесси Стокалл, главный архитектор Snow Software, объясняя некоторые важные подходы к управлению контейнерными приложениями и неизменяемой инфраструктурой, рассказывает о том, как контейнеры и оркестровка предотвращают дрейф или необходимость развертывания «снежинок», которые вполне вероятны в SOE.

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

Другие ключевые элементы конвейера CI/CD включают тестирование и валидацию/проверку на соответствие требованиям. И безопасность является неотъемлемой частью каждого из этих этапов (вместо проверки в последнюю минуту).

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

3. Нативные облачные инструменты

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

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

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

«Это изменение ландшафта привело к переосмыслению автоматизации инфраструктуры, — говорит Хафф. — Kubernetes стал стандартом для оркестровки контейнеров. Это, в свою очередь, привело к появлению разнообразных средств автоматизации, специально разработанных для контейнерного мира».

Слово «экосистема», как правило, широко трактуется в технологическом мире. Но оно соответствует своему определению, когда речь идет об автоматизации инфраструктуры в эпоху облачных вычислений, от разработки до обеспечения безопасности и развертывания. Одни проекты или платформы питают другие, особенно если они основаны на Open Source. Это приводит к эффекту снежного кома для автоматизации инфраструктуры.

«Проекты в пространстве CI/CD переосмысливают построение и развертывание конвейеров в контексте моделей и процессов развития Kubernetes, — говорит Хафф. — Сюда входят Tekton Pipelines, а также новые проекты, специально ориентированные на автоматизацию развертывания, такие как Argo CD и Keptn. Мы также видим много новых инструментов безопасности, таких как Aqua и Snyk, которые оптимизированы для этого относительно нового типа инфраструктуры».