Евгений Листраткин

Всем привет! С вами вновь на связи Евгений Листраткин, ведущий инженер команды администрирования клиентских сервисов в Selectel. Наша работа — DevOps as a Service. Трудимся и в дата‑центрах других компаний, и вообще на любых площадках. В работе любого DevOps-инженера есть неизбежная рутина — из раза в раз разворачивать одни и те же типовые сервисы, которым часто с головой хватает базовых настроек. Ansible или Puppet — типичное решение. Но неужели писать плейбуки ради одного бинарника или готового файла Docker Compose?! Давайте разберем быструю альтернативу — развертывание инфраструктуры из готовых образов с предустановленным ПО. Материал будет полезен DevOps-инженерам, сисадминам и тимлидам — избавит от рутины, сэкономит время команды, научит раскатывать типовые среды без написания лишнего кода. Стандарт индустрии для работы со множеством однотипных серверов — системы управления конфигурациями на базе Ansible, Puppet, Chef и их менее крупных аналогов. По заранее написанному плейбуку, манифесту или рецепту они на конечных узлах раскатывают ПО в нужной конфигурации. Однако такой подход не всегда прост и оправдан. Сервис может поставляться как продукт on-premise и состоять из одного единственного бинарника, приходящего из GitHub Releases. Или наоборот — быть огромным файлом Docker Compose, содержащим множество микросервисов. И том, и в другом случае описание инфраструктуры через системы конфигурирования оказывается избыточным, бесполезным или излишне сложным. Хорошей альтернативой становятся готовые образы с уже предустановленными сервисами — для легкой и быстрой развертки на виртуальных машинах. Примером может послужить образ с нашей операционной системой SelectOS, с минимальным набором требований и инструментов — для старта и повседневной работы. Источник. Мы нередко собираем подобные образы, постоянно применяем в своей работе и делимся ими. Все желающие могут так же легко и быстро запускать сервисы в своих проектах. Примечательно, что даже не потребуется штатный DevOps-инженер. Все среды практически настроены и разворачиваются за пару кликов прямо в панели управления. Любой из образов с предустановленными сервисами доступен при создании виртуальной машины. Достаточно перейти на вкладку Приложения и выбрать нужный из списка. Панель управления. У нас в свободном доступе есть множество образов для самых разных задач. Сейчас пробежимся буквально по всем, разберемся с их назначением и начальными настройками. С гордостью замечу: получилась хорошая экосистема, готовая закрыть потребности небольшого проекта. Командное взаимодействие Представим базовую ситуацию — начинается работа над новым стартапом. Итак, команда собрана, идеи ждут воплощения. В первую очередь требуется некое цифровое пространство для общения. Нужна удобная, закрытая, безопасная площадка с тематическими чатами, историей переписки и видеоконференциями — как с внутренними, так и с внешними клиентами. Использование привычных мессенджеров сопряжено с различными сложностями и ограничениями, а платные решения могут дополнительно нагружать уязвимый бюджет стартапа. На помощь приходит open source. Mattermost — платформа для обмена мгновенными сообщениями, конкурирующая со Slack, Rocket.Chat и другими корпоративными мессенджерами. Размещение on-prem на собственных серверах дает полный контроль над безопасностью переписок и передаваемых файлов. Кроме того, в комбинации с возможностями облака по резервному копированию виртуальных машин уходит опасность потери доступа к иностранным ресурсам и беспричинной блокировки аккаунтов, зачастую с потерей всей накопленной информации. Jitsi Meet — платформа для проведения видеоконференций, которая поддерживает интеграцию с Mattermost. Такая связка еще удобнее в командной работе. Кстати, мы не просто предлагаем пользоваться «какой‑то платформой», а сами активно на ней работаем. Все коллеги в Selectel проводят встречи именно в Jitsi Meet, а их общее ежедневное количество уходит далеко за тысячу. Matrix — открытый децентрализованный протокол для развертывания защищенной экосистемы корпоративного общения. Ключевое отличие — архитектура «мостов». Удается объединить всех в одном интерфейсе: из Matrix можно напрямую писать в Telegram, WhatsApp или Slack. При этом не приходится беспокоится о тайне переписки при общении со внешними подрядчиками — сохраняется полный контроль над конфиденциальностью данных и сквозным шифрованием (E2EE). Хранение и сборка кода Итак, команда в сборе, площадка для общения настроена. Глаза горят, руки делают. Теперь предстоит решить новую задачу: весь написанный код нужно где‑то хранить, а в идеале — еще и собирать, и доставлять. Как средство размещения и версионирования кода, известный и популярный GitHub также начинает испытывать проблемы с доступностью и стабильностью. Все чаще появляются статьи про эксплуатацию дыр в безопасности приватных репозиториев и случаи случайного слива в них своих приватных данных. GitLab — востребованная альтернатива GitHub. Мы подготовили готовый образ, который, конечно, подойдет и для размещения on-prem. Получается полностью рабочая система, которую несложно настроить в соответствии с особенностями конкретных требований ИБ: ограничении внешнего доступа, подключении двухфакторной аутентификации, интеграции сервисов SSO и других. С размещением, версионированием и совместной работой разобрались. Перейдем к не менее важному этапу работы — сборке и автоматизации поставки кода. Да, вариант с простым клонированием репозитория и управления им через команды Git остается актуальным. Однако встречаются и проекты, чья архитектура требует иного подхода. Для них мы подготовили образы на базе традиционных инструментов автоматизации — пайплайнов CI/CD. Чтобы задействовать встроенные возможности GitLab CI/CD, потребуется запустить GitLab Runner. Немаленькая часть IT-сообщества предпочитает альтернативный вариант — Jenkins. Платформа GitLab поддерживает интеграцию с конкурирующей системой, позволяя полностью делегировать ей процессы непрерывной интеграции и доставки. Хранение образов для контейнеризации Хорошо, наш стартап продвигается. Команды взаимодействуют, код пишется, отправляется в репозиторий. При необходимости он проходит проверки безопасности и, возможно, уже разворачивается на конечных машинах для полноценной работы в production-окружении. Однако современный IT‑мир уже сложно представить без контейнеризации — упаковки ПО в изолированную среду, которую достаточно легко масштабировать и переносить между хостами. Возможности сборки таких контейнеров в инструментах CI/CD есть, но остается открытым вопрос хранения собранных образов, из которых в последующем и будут запускаться контейнеры. Известный Docker Hub уже не первый год «затягивает гайки» с доступом. И хотя есть различные российские зеркала, сохраняется риск проснуться утром и вновь узнать, что образ не смог стянуться в окружение, а то и вовсе удален вместе с аккаунтом. В такой ситуации собственный приватный registry — отличный вариант для хранения образов. Мы предлагаем Harbor — простой наглядный инструмент, готовый и настроенный. Здесь можно резонно подметить: уже есть развернутый GitLab, у него «под капотом» встроенный Container Registry, который нетрудно «включить». Да, это так, он простой и легкий, к тому же интегрированный в GitLab CI/CD. Причина в том, что его UI/UX по наглядности, функциональности и стабильности все еще проигрывает отдельным решениям. Не забываем и про поговорку о хранении всех яиц в одной корзине. Разделение инструментов добавляет отказоустойчивости, снижает ее стоимость, и дает больше вариантов для выбора. Управление контейнерными приложениями Код упакован, собран и доставлен. Необходимо позаботиться о его развертывании в окружении и возможности удобного администрирования инфраструктуры. Один из простых, но востребованных подходов, который встречается даже в production‑средах, — применение Docker Compose. Становится возможно управлять целой группой контейнеров через единое декларативное описание. Не секрет, что подобные инсталляции порой включают десятки разворачиваемых сервисов в рамках одного файла Docker Compose. В результате конфигурационный файл разрастается, и очень значительно. Кому‑то покажется удобным управлять запуском, а затем поддерживать контейнеры с помощью различных GUI‑оболочек. В образе Container Ready используется преднастроенный Docker с плагином Compose и Portainer, который как раз и предоставляет функциональную оболочку управления. Размещение кода Если архитектура проекта не подразумевает контейнеризацию приложений, а требует прямого размещения файлов на сервере — например, с развертыванием кода через простые команды Git, — то нужны готовые среды выполнения. Классические представители этой категории — серверы для работы с PHP или JavaScript. Для подобных задач в коллекции готовых образов предусмотрена традиционная связка LAMP. Обычно эта аббревиатура расшифровывается как Linux, Apache, MySQL и PHP. Однако в данном случае классический MySQL заменен на его форк — MariaDB, а в дополнение к Apache добавлен еще и Nginx. Для размещения кода JavaScript-приложений логично использовать отдельный образ с Node.js. В нем реализована возможность выбора версии среды выполнения, а также предусмотрена небольшая автоматизация — развертывание кода на сервере сразу при его старте. Управление хостингом сайтов Если для работы нужна не просто среда для размещения кода, а полноценная панель управления проектами, — некий аналог классического виртуального хостинга, — отличным выбором станет образ с ISPmanager. Графический интерфейс хорошо продуман, удобно работать с сайтами, почтовыми доменами, базами данных, SSL-сертификатами — всем, что требуется для администрирования. Брокеры сообщений В этом разделе представлен не совсем классический образ приложения, а скорее готовая система автоматизации. Она позволяет быстро и без вмешательства оператора развернуть в рамках проекта Apache Kafka — многонодовый кластер потоковой обработки сообщений. Инфраструктура — несколько отдельных виртуальных машин, объединенных в общую приватную сеть. Образ родился благодаря запросам наших клиентов, которым требовалось разворачивать именно многонодовую инсталляцию. Дело в том, что полноценный PaaS‑сервис Managed Kafka в то время поддерживал только конфигурацию из одного узла. Мониторинг и логирование Итак. В нашем проекте выстроен полноценный цикл создания и доставки приложения, подготовлены места для размещения. Теперь за всей этой инфраструктурой необходимо приглядывать: проверять доступность, контролировать потребление ресурсов, отслеживать просадки производительности, централизованно собирать логи. Для агрегации логов приложений и системных журналов в IT-сообществе наиболее популярен стек на базе Elasticsearch, Kibana и Beats/Logstash, поэтому мы подготовили образ с EFK (Elasticsearch, Filebeat, Kibana). Инструментов в сфере мониторинга существует огромное количество. Однако среди всего многообразия выделяются два лидера рынка — Zabbix и VictoriaMetrics. У каждого из них свое большое коммьюнити, поклонники, а сильные и слабые стороны давно известны. Традиционно считается, что Zabbix лучше подходит для мониторинга выделенных и виртуальных серверов, да и вообще любого оборудования. С отслеживанием работы веб-приложений и кластеров Kubernetes лучше справляется экосистема VictoriaMetrics. При этом оба продукта хорошо развиваются и успешно исправляют свои исторические «недостатки». Каждый из двух образов поставляется уже преднастроенным, а в документации есть инструкция по подключению новых узлов. В случае с VictoriaMetrics дополнительно предусмотрен набор готовых дашбордов для отслеживания основных системных метрик. Хранение файлов и документов, а также совместная работа с ними В любой проектной команде, особенно на уровне менеджмента, одними созвонами и чатами совместная работа не ограничивается. Спецификации, расчеты, различная документация нуждаются в облачных офисных инструментах, а вместе с ними — в местах постоянного хранения. Сложности с доступом к подобным иностранным сервисам все чаще подталкивают пользователей искать разумные, доступные и безопасные альтернативы — данные с которых не пропадут в одно «прекрасное» утро понедельника. Собственное хранилище на базе Nextcloud и Onlyoffice позволяет организовать совместную работу с традиционными офисными документами. Самое существенное преимущество — полный контроль над инфраструктурой и должный уровень приватности. Информационная безопасность По мере взросления проекта и его расширения всегда возникает не всеми любимая, но очень актуальная и необходимая тема — информационная безопасность. Как убедиться, что нет уязвимостей? Какие меры предпринять, чтобы злоумышленники никогда не оказались на серверах? Как удобно обеспечить в инфраструктуре три великие «А» — Авторизацию, Аутентификацию и Аудит? Как в режиме реального времени противостоять внешним угрозам как для оборудования, так и для ПО? Даже на старте проекта, уже стоит задумываться о внедрении единой точки входа (SSO) всей команды. По мере же его роста централизованный подход к авторизации и аутентификации становится просто жизненной необходимостью. Вместо десятков паролей от разных панелей и сервисов для каждого сотрудника — единая точка входа. Такой централизованный доступ может быть организован с помощью готового образа с Keycloak. Если же требуется вести полноценный анализ всего контура, выявлять угрозы и уязвимости, выстроить систему реагирования, то стоит обратить внимание на Wazuh — платформу с открытым исходным кодом, которая с помощью своих агентов собирает данные логов, сравнивает с преднастроенными правилами, подготавливает сводные отчеты и даже автоматически реагирует на инциденты. Как и другие образы, инструменты информационной безопасности так же отлично интегрируются в существующие контуры автоматизации при использовании Terraform и подхода IaC (Infrastructure as Code). За основу можно взять готовые примеры из репозитория на GitHub. В разделе examples/cloud как раз описано создание облачных ВМ, а за имя образа отвечает переменная server_image_name в файле vars.tf. Фактически этот конфигурационный файл почти не отличается от манифестов для провижининга любых виртуальных машин на базе образов классических операционных систем. Если подобные наработки уже используются в проекте, то достаточно лишь определять имя или ID нужного образа — в зависимости от логики шаблонов и входных параметров. Основные отличия от создания классических виртуальных машин на базовых ОС сводятся к двум моментам. Необходимо корректно выставлять минимальные ресурсы, требуемые к образу — их можно посмотреть на сводной странице. В противном случае предустановленное ПО или сервис в загруженном образе может работать нестабильно или не запуститься вовсе. Для каждого приложения требуется передать свой уникальный набор входных данных через user_data, чтобы виртуальная машина доконфигурировалась сразу после запуска. Существующие модули и конфигурации легко дополнить буквально одной строкой, взяв за основу пример из документации по работе с провайдером OpenStack. Требуемые параметры указаны в инструкциях к конкретным приложениям. Например, для образа Nextcloud передача параметров user_data в манифест Terraform выглядит следующим образом: Результатом данного подхода станет возможность быстро разворачивать виртуальные машины с готовыми для работы в проекте сервисами. Хорошим примером такого симбиоза будет организация множественных схожих dev‑окружений для разработчиков и тестировщиков. Источник. Заключение Мы в команде видим растущий интерес к образам с готовыми сервисами, поэтому продолжим их развитие. Наша библиотека популярных сборок и дальше будет пополняться. К примеру, еще два новых образа уже на финишной прямой и скоро попадут в коллекцию сервисов в разных категориях. Fastpanel, инструмент управления хостингами сайтов — чуть более простой и визуально легкий по сравнению с ISPmanager. DefectDojo дополняет сервисы безопасности. Он отвечает за выявление различных уязвимостей и формирование отчетов по различным продуктам в едином окне. Команды разработки успешно интегрируют его в пайплайны сборки своих приложений. Все новые образы станут доступны для развертывания уже в ближайшее время. В своей работе мы придерживаемся принципа использования уже готовых и проверенных инструментов — это намного лучше, нежели каждый раз пытаться «переизобрести велосипед», а потом еще сделать так, чтобы разработка не подверглась bus-фактору. Готовые образы с предустановленными сервисами существенно экономят время и силы на развертывании и дальнейшей поддержке, а зачастую позволяют вообще не привлекать полноценного DevOps-инженера — например, при подготовке тестовых сред. Кроме того, готовые образы никак не отменяют полный контроль над приложениями и данными. Можно самостоятельно управлять процессом сохранности через штатные и доступные инструменты облака.