Джентльменский набор образов — пособие для администраторов

Всем привет! С вами вновь на связи Евгений Листраткин, ведущий инженер команды администрирования клиентских сервисов в Selectel ^[1]. Наша работа — DevOps as a Service. Трудимся и в дата‑центрах других компаний, и вообще на любых площадках.

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

Стандарт индустрии для работы со множеством однотипных серверов — системы управления конфигурациями на базе Ansible, Puppet, Chef и их менее крупных аналогов. По заранее написанному плейбуку, манифесту или рецепту они на конечных узлах раскатывают ПО в нужной конфигурации.

Однако такой подход не всегда прост и оправдан.  Сервис может поставляться как продукт on-premise и состоять из одного единственного бинарника, приходящего из GitHub Releases. Или наоборот — быть огромным файлом Docker Compose, содержащим множество микросервисов. И том, и в другом случае описание инфраструктуры через системы конфигурирования оказывается избыточным, бесполезным или излишне сложным.

Содержание
→ Командное взаимодействие ^[2]
→ Хранение и сборка кода ^[3]
→ Хранение образов для контейнеризации ^[4]
→ Управление контейнерными приложениями ^[5]
→ Размещение кода ^[6]
→ Средства управления хостингом сайтов ^[7]
→ Брокеры сообщений ^[8]
→ Средства мониторинга и логирования ^[9]
→ Хранение файлов и документов, а также совместная работа с ними ^[10]
→ Информационная безопасность ^[11]
→ Заключение ^[12]

Хорошей альтернативой становятся готовые образы с уже предустановленными сервисами — для легкой и быстрой развертки на виртуальных машинах.

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

Примером может послужить образ с нашей операционной системой SelectOS ^[13], с минимальным набором требований и инструментов — для старта и повседневной работы.

Мы нередко собираем подобные образы, постоянно применяем в своей работе и делимся ими ^[14]. Все желающие могут так же легко и быстро запускать сервисы в своих проектах. Примечательно, что даже не потребуется штатный DevOps-инженер. Все среды практически настроены и разворачиваются за пару кликов прямо в панели управления ^[15].

Важно учесть
В модели поставки продуктов PaaS (Platform as a Service) ресурсами самого облака, их доступностью и поддержкой занимается облачный провайдер — и гарантию несет он же. Совсем другое дело, когда образ и содержащиеся в нем сервисы клиент разворачивает самостоятельно — ответственность несет только он, поскольку сам устанавливает и администрирует все ПО.

Любой из образов с предустановленными сервисами доступен при создании виртуальной машины. Достаточно перейти на вкладку Приложения и выбрать нужный из списка.

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

Командное взаимодействие

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

Mattermost ^[16] — платформа для обмена мгновенными сообщениями, конкурирующая со Slack, Rocket.Chat ^[17] и другими корпоративными мессенджерами. Размещение on-prem на собственных серверах дает полный контроль над безопасностью переписок и передаваемых файлов. Кроме того, в комбинации с возможностями облака по резервному копированию виртуальных машин уходит опасность потери доступа к иностранным ресурсам и беспричинной блокировки аккаунтов, зачастую с потерей всей накопленной информации.

Jitsi Meet ^[18] — платформа для проведения видеоконференций, которая поддерживает интеграцию с Mattermost. Такая связка еще удобнее в командной работе. Кстати, мы не просто предлагаем пользоваться «какой‑то платформой», а сами активно на ней работаем. Все коллеги в Selectel проводят встречи именно в Jitsi Meet, а их общее ежедневное количество уходит далеко за тысячу.

Matrix ^[19] — открытый децентрализованный протокол для развертывания защищенной экосистемы корпоративного общения. Ключевое отличие — архитектура «мостов». Удается объединить всех в одном интерфейсе: из Matrix можно напрямую писать в Telegram, WhatsApp или Slack. При этом не приходится беспокоится о тайне переписки информации при общении со внешними подрядчиками — сохраняется полный контроль над конфиденциальностью данных и сквозным шифрованием (E2EE).

Хранение и сборка кода

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

Не будем говорить про какие-то «стильно–модно–молодежные» подходы по сборке, доставке кода, отказоустойчивости и прочие прелести DevOps‑ и SRE‑практик. Приветствуется как банальный git pull, так и более сложные вариации — например, S3 в режиме веб‑сервера ^[21].

Как средство размещения и версионирования кода, известный и популярный GitHub также начинает испытывать проблемы с доступностью и стабильностью. Все чаще появляются статьи про эксплуатацию дыр ^[22] в безопасности приватных репозиториев и случаи случайного слива в них своих приватных данных.

GitLab ^[23] — востребованная альтернатива GitHub. Мы подготовили готовый образ, который, конечно, подойдет и для размещения on-prem. Получается полностью рабочая система, которую несложно настроить в соответствии с особенностями конкретных требований ИБ: ограничении внешнего доступа, подключении двухфакторной аутентификации, интеграции сервисов SSO и других.

С размещением, версионированием и совместной работой разобрались. Перейдем к не менее важному этапу работы — сборке и автоматизации поставки кода.

Да, вариант с простым клонированием репозитория и управления им через команды Git остается актуальным. Однако встречаются и проекты, чья архитектура требует иного подхода. Для них мы подготовили образы на базе традиционных инструментов автоматизации — пайплайнов CI/CD.

Чтобы задействовать встроенные возможности GitLab CI/CD, потребуется запустить GitLab Runner ^[24]. Немаленькая часть IT-сообщества предпочитает альтернативный вариант — Jenkins ^[25]. Платформа GitLab поддерживает интеграцию с конкурирующей системой, позволяя полностью делегировать ей процессы непрерывной интеграции и доставки.

Хранение образов для контейнеризации

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

Однако современный IT‑мир уже сложно представить без контейнеризации — упаковки ПО в изолированную среду, которую достаточно легко масштабировать и переносить между хостами. Возможности сборки таких контейнеров в инструментах CI/CD есть, но остается открытым вопрос хранения собранных образов, из которых в последующем и будут запускаться контейнеры.

Известный Docker Hub уже не первый год «затягивает гайки» с доступом. И хотя есть различные российские зеркала, сохраняется риск проснуться утром и вновь узнать, что образ не смог стянуться в окружение, а то и вовсе удален вместе с аккаунтом. В такой ситуации собственный приватный registry — отличный вариант для хранения образов.

Мы предлагаем Harbor ^[26] — простой наглядный инструмент, готовый и настроенный. 

Здесь можно резонно подметить: уже есть развернутый GitLab, у него «под капотом» встроенный Container Registry, который нетрудно «включить». Да, это так, он простой и легкий, к тому же интегрированный в GitLab CI/CD. Причина в том, что его UI/UX по наглядности, функциональности и стабильности все еще проигрывает отдельным решениям.

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

Управление контейнерными приложениями

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

Один из простых, но востребованных подходов, который встречается даже в production‑средах, — применение  Docker Compose. Становится возможно управлять целой группой контейнеров через единое декларативное описание. Не секрет, что подобные инсталляции порой включают десятки разворачиваемых сервисов в рамках одного файла Docker Compose. В результате конфигурационный файл разрастается, и очень значительно.

Кому‑то покажется удобным управлять запуском, а затем поддерживать контейнеры с помощью различных GUI‑оболочек. В образе Container Ready ^[27] используется преднастроенный Docker с плагином Compose и Portainer, который как раз и предоставляет функциональную оболочку управления.

Размещение кода

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

Для подобных задач в коллекции готовых образов предусмотрена традиционная связка LAMP ^[28]. Обычно эта аббревиатура расшифровывается как Linux, Apache, MySQL и PHP. Однако в данном случае классический MySQL заменен на его форк — MariaDB, а в дополнение к Apache добавлен еще и Nginx.

Для размещения кода JavaScript-приложений логично использовать отдельный образ с Node.js ^[29]. В нем реализована возможность выбора версии среды выполнения, а также предусмотрена небольшая автоматизация — развертывание кода на сервере сразу при его старте.

Средства управления хостингом сайтов

Если для работы нужна не просто среда для размещения кода, а полноценная панель управления проектами, — некий аналог классического виртуального хостинга ^[30], — отличным выбором станет образ с ISPmanager ^[31]. Графический интерфейс хорошо продуман, удобно работать с сайтами, почтовыми доменами, базами данных, SSL-сертификатами — всем, что требуется для администрирования.

Брокеры сообщений

В этом разделе представлен не совсем классический образ приложения, а скорее готовая система автоматизации. Она позволяет быстро и без вмешательства оператора развернуть в рамках проекта Apache Kafka ^[32] — многонодовый кластер потоковой обработки сообщений. Инфраструктура — несколько отдельных виртуальных машин, объединенных в общую приватную сеть.

Образ родился благодаря запросам наших клиентов, которым требовалось разворачивать именно многонодовую инсталляцию. Дело в том, что полноценный PaaS‑сервис Managed Kafka ^[33] в то время поддерживал только конфигурацию из одного узла.

Средства мониторинга и логирования

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

Для агрегации логов приложений и системных журналов в IT-сообществе наиболее популярен стек на базе Elasticsearch, Kibana и Beats/Logstash, поэтому мы подготовили образ с EFK ^[34] (Elasticsearch, Filebeat, Kibana).

Инструментов в сфере мониторинга существует огромное количество. Однако среди всего многообразия выделяются два лидера рынка — Zabbix и VictoriaMetrics. У каждого из них свое большое коммьюнити, поклонники, а сильные и слабые стороны давно известны.

Традиционно считается, что Zabbix лучше подходит для мониторинга выделенных и виртуальных серверов, да и вообще любого оборудования. С отслеживанием работы веб-приложений и кластеров Kubernetes лучше справляется экосистема VictoriaMetrics. При этом оба продукта хорошо развиваются и успешно исправляют свои исторические «недостатки».

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

Хранение файлов и документов, а также совместная работа с ними

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

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

Собственное хранилище на базе Nextcloud и Onlyoffice ^[35] позволяет организовать совместную работу с традиционными офисными документами. Самое существенное преимущество — полный контроль над инфраструктурой и должный уровень приватности.

Информационная безопасность

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

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

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

Вместо десятков паролей от разных панелей и сервисов для каждого сотрудника — единая точка входа. Такой централизованный доступ может быть организован с помощью готового образа с Keycloak ^[36].

Если же требуется вести полноценный анализ всего контура, выявлять угрозы и уязвимости, выстроить систему реагирования, то стоит обратить внимание на Wazuh ^[37] — платформу с открытым исходным кодом, которая с помощью своих агентов собирает данные логов, сравнивает с преднастроенными правилами, подготавливает сводные отчеты и даже автоматически реагирует на инциденты.

Как и другие образы, инструменты информационной безопасности так же отлично интегрируются в существующие контуры автоматизации при использовании Terraform и подхода IaC (Infrastructure as Code). За основу можно взять готовые примеры из репозитория на GitHub ^[38].

В разделе examples/cloud как раз описано создание облачных ВМ, а за имя образа отвечает переменная server_image_name в файле vars.tf. Фактически этот конфигурационный файл почти не отличается от манифестов для провижининга любых виртуальных машин на базе образов классических операционных систем.

Если подобные наработки уже используются в проекте, то достаточно лишь определять имя или ID нужного образа — в зависимости от логики шаблонов и входных параметров.

Основные отличия от создания классических виртуальных машин на базовых ОС сводятся к двум моментам.

Необходимо корректно выставлять минимальные ресурсы, требуемые к образу — их можно посмотреть на сводной странице ^[14]. В противном случае предустановленное ПО или сервис в загруженном образе может работать нестабильно или не запуститься вовсе.

Для каждого приложения требуется передать свой уникальный набор входных данных через user_data, чтобы виртуальная машина доконфигурировалась сразу после запуска. Существующие модули  и конфигурации легко дополнить буквально одной строкой, взяв за основу пример из документации ^[39] по работе с провайдером 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-фактору ^[40].

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

Кроме того, готовые образы никак не отменяют полный контроль над приложениями и данными. Можно самостоятельно управлять процессом сохранности через штатные и доступные инструменты облака ^[41].