Всем привет! С вами вновь на связи Евгений Листраткин, ведущий инженер команды администрирования клиентских сервисов в Selectel. Наша работа — DevOps as a Service. Трудимся и в дата‑центрах других компаний, и вообще на любых площадках.
В повседневной работе DevOps‑инженера, поддерживающего несколько проектов одновременно, часто встречаются одни и те же сервисы, которые повторяются практически каждый раз. В ряде случаев они могут даже не отличаться по своим основным настройкам — и базовых хватает, чтобы закрыть все потребности команды.
Стандарт индустрии для работы со множеством однотипных серверов — системы управления конфигурациями на базе Ansible, Puppet, Chef и их менее крупных аналогов. По заранее написанному плейбуку, манифесту или рецепту они на конечных узлах раскатывают ПО в нужной конфигурации.
Однако такой подход не всегда прост и оправдан. Сервис может поставляться как продукт on-premise и состоять из одного единственного бинарника, приходящего из GitHub Releases. Или наоборот — быть огромным файлом Docker Compose, содержащим множество микросервисов. И том, и в другом случае описание инфраструктуры через системы конфигурирования оказывается избыточным, бесполезным или излишне сложным.
Содержание
→ Командное взаимодействие
→ Хранение и сборка кода
→ Хранение образов для контейнеризации
→ Управление контейнерными приложениями
→ Размещение кода
→ Средства управления хостингом сайтов
→ Брокеры сообщений
→ Средства мониторинга и логирования
→ Хранение файлов и документов, а также совместная работа с ними
→ Информационная безопасность
→ Заключение
Хорошей альтернативой становятся готовые образы с уже предустановленными сервисами — для легкой и быстрой развертки на виртуальных машинах.
Будем исходить из предположения, что для изоляции ресурсов, безопасности и большей надежности, команда или компания придерживается принципа «один сервис — один сервер», а не держит «коммуналку» из десятка конфликтующих приложений.
Примером может послужить образ с нашей операционной системой SelectOS, с минимальным набором требований и инструментов — для старта и повседневной работы.
Мы нередко собираем подобные образы, постоянно применяем в своей работе и делимся ими. Все желающие могут так же легко и быстро запускать сервисы в своих проектах. Примечательно, что даже не потребуется штатный DevOps-инженер. Все среды практически настроены и разворачиваются за пару кликов прямо в панели управления.
Важно учесть
В модели поставки продуктов PaaS (Platform as a Service) ресурсами самого облака, их доступностью и поддержкой занимается облачный провайдер — и гарантию несет он же. Совсем другое дело, когда образ и содержащиеся в нем сервисы клиент разворачивает самостоятельно — ответственность несет только он, поскольку сам устанавливает и администрирует все ПО.
Любой из образов с предустановленными сервисами доступен при создании виртуальной машины. Достаточно перейти на вкладку Приложения и выбрать нужный из списка.
У нас в свободном доступе есть множество образов для самых разных задач. Сейчас пробежимся буквально по всем, разберемся с их назначением и начальными настройками. С гордостью замечу: получилась хорошая экосистема, готовая закрыть потребности небольшого проекта.
Командное взаимодействие
Представим базовую ситуацию — начинается работа над новым стартапом. Итак, команда собрана, идеи ждут воплощения. В первую очередь требуется некое цифровое пространство для общения. Нужна удобная, закрытая, безопасная площадка с тематическими чатами, историей переписки и видеоконференциями — как с внутренними, так и с внешними клиентами. Использование привычных мессенджеров сопряжено с различными сложностями и ограничениями, а платные решения могут дополнительно нагружать уязвимый бюджет стартапа. На помощь приходит open source.
Mattermost — платформа для обмена мгновенными сообщениями, конкурирующая со Slack, Rocket.Chat и другими корпоративными мессенджерами. Размещение on-prem на собственных серверах дает полный контроль над безопасностью переписок и передаваемых файлов. Кроме того, в комбинации с возможностями облака по резервному копированию виртуальных машин уходит опасность потери доступа к иностранным ресурсам и беспричинной блокировки аккаунтов, зачастую с потерей всей накопленной информации.
Jitsi Meet — платформа для проведения видеоконференций, которая поддерживает интеграцию с Mattermost. Такая связка еще удобнее в командной работе. Кстати, мы не просто предлагаем пользоваться «какой‑то платформой», а сами активно на ней работаем. Все коллеги в Selectel проводят встречи именно в Jitsi Meet, а их общее ежедневное количество уходит далеко за тысячу.
Matrix — открытый децентрализованный протокол для развертывания защищенной экосистемы корпоративного общения. Ключевое отличие — архитектура «мостов». Удается объединить всех в одном интерфейсе: из Matrix можно напрямую писать в Telegram, WhatsApp или Slack. При этом не приходится беспокоится о тайне переписки информации при общении со внешними подрядчиками — сохраняется полный контроль над конфиденциальностью данных и сквозным шифрованием (E2EE).
Облачные базы данных
Создайте готовую базу данных в облаке за 5 минут. Поддерживаем PostgreSQL, MySQL, Redis и не только.
Хранение и сборка кода
Итак, команда в сборе, площадка для общения настроена. Глаза горят, руки делают. Теперь предстоит решить новую задачу: весь написанный код нужно где‑то хранить, а в идеале — еще и собирать, и доставлять.
Не будем говорить про какие-то «стильно–модно–молодежные» подходы по сборке, доставке кода, отказоустойчивости и прочие прелести DevOps‑ и SRE‑практик. Приветствуется как банальный
git pull, так и более сложные вариации — например, S3 в режиме веб‑сервера.
Как средство размещения и версионирования кода, известный и популярный 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 выглядит следующим образом:
resource "openstack_compute_instance_v2" "instance_1" { name = "basic" image_id = "<image-id>" flavor_id = "1311" key_pair = "<key-pair-name>" user_data = <<EOF #cloud-config write_files: - path: "/opt/main.yml" permissions: "0644" content: | nextcloud_admin_name: "<administrator_name>" nextcloud_admin_pwd: "<administrator_password>" nextcloud_admin_email: "<root@example.com>" nextcloud_domain: "<example.com>" EOF network { name = "<network-name>" } }
Результатом данного подхода станет возможность быстро разворачивать виртуальные машины с готовыми для работы в проекте сервисами. Хорошим примером такого симбиоза будет организация множественных схожих dev‑окружений для разработчиков и тестировщиков.
Заключение
Мы в команде видим растущий интерес к образам с готовыми сервисами, поэтому продолжим их развитие. Наша библиотека популярных сборок и дальше будет пополняться. К примеру, еще два новых образа уже на финишной прямой и скоро попадут в коллекцию сервисов в разных категориях.
Fastpanel, инструмент управления хостингами сайтов — чуть более простой и визуально легкий по сравнению с ISPmanager.
DefectDojo дополняет сервисы безопасности. Он отвечает за выявление различных уязвимостей и формирование отчетов по различным продуктам в едином окне. Команды разработки успешно интегрируют его в пайплайны сборки своих приложений.
Все новые образы станут доступны для развертывания уже в ближайшее время.
В своей работе мы придерживаемся принципа использования уже готовых и проверенных инструментов — это намного лучше, нежели каждый раз пытаться «переизобрести велосипед», а потом еще сделать так, чтобы разработка не подверглась bus-фактору.
Готовые образы с предустановленными сервисами существенно экономят время и силы на развертывании и дальнейшей поддержке, а зачастую позволяют вообще не привлекать полноценного DevOps-инженера — например, при подготовке тестовых сред.
Кроме того, готовые образы никак не отменяют полный контроль над приложениями и данными. Можно самостоятельно управлять процессом сохранности через штатные и доступные инструменты облака.