«Свои грабли» detected или Hashicorp way, на тропе просветления

Всем привет. Меня зовут Ярослав. Вместе с моим коллегой Володей, мы представляем команду Sunshard. Нашей небольшой командой Hashicorp-энтузиастов мы решаем различные бизнес-задачи для команд разработки.

Как мы сделали ERP-систему модной и современной

Знаете, что делает ERP-систему по-настоящему крутой? Нет, не красивый интерфейс (хотя и это важно), а Docker и Hashicorp-стек! Именно так, мы взяли и докеризировали ERP-систему совместно с разработчиками icode, словно настоящие волшебники IT.

Архитектурно кейс состоит из следующих решений:

• Оркестрация под управлением Hashicorp Nomad;

• Service mesh и service discovery Hashicorp Consul;

• Плейбуки системы управления конфигурациями Ansible;

• Continuousы в GitlabCI;

• Мониторинг и логшиппинг Grafana/Prometheus/Opensearch Stack;

• Безопасный доступ к инфраструктуре средствами Hashicorp Boundary;

NGINX, Consul и искусство управления трафиком

Тут все начинается с NGINX на бастион-хосте, который, как стражник у ворот, направляет запросы куда нужно. Добавьте к этому Consul для обнаружения сервисов и voilà — магия обеспечения устойчивой работы сервисов начинается.

Настройку Consul DNS мы реализовали через dnsmasq, он обеспечил нам устойчивую работу обнаружения сервисов. 

При деплое приложения с помощью ansible мы накатываем и конфигурацию для nginx. Как упоминалось ранее, мы используем upstream, которые в свою очередь работают через Consul DNS. Вот пример конфигурации, в которой мы используем FQDN сервиса, зарегистрированный  в Consul

upstream {{ domain }} {  server haproxy-webapp-{{ domain }}.service.datacenter.consul:{{webapp_port}};

Hashicorp Boundary — ваш личный охранник

Boundary от Hashicorp — это как ваш личный бодигард в мире IT. Boundary обеспечивает безопасный доступ к бекэндам и приложениям в рамках архитектуры. Он позволяет производить контроль и аудит. Boundary обладает гибкими настройками, позволяющими определить точные права доступа для каждого пользователя или группы пользователей. Его состояние мы поддерживаем с помощью Terraform. C помощью Boundary разработчики имеют доступ к Nomad UI, Consul, Grafaba, Opensearch, а также к требуемым эндпойнтам приложения. В Nomad UI разработчик может посмотреть статус deployments, провалиться в контейнер с помощью exec, посмотреть загруженность кластера в Grafana.

Nomad + Consul

Почему не Kubernetes? Ну а почему бы и нет? На самом деле, у нас есть целый список причин, по которым мы выбрали Hashicorp Nomad и Consul. И да, одна из причин — мы просто упоротые фанаты Hashicorp-стека!

Схема взаимодействия клиентских приложений в одном namespace

• Масштабируемость кластера

• Отказоустойчивость

• Легкий порог вхождения для разработчиков

• Быстрое и лёгкое описание файла deployments для приложения

• Быстрая развертывание кластера на чистом стенде

• Быстрое добавление компонентов кластер

• Легкость обновления версий Nomad и Consul

• Легкое поддержание состояния и актуальности конфигурации Nomad + Consul

• Быстрое восстановление кластера в случае падения рафта

Верхнеуровневая абстракция для Nomad – namespace. Именно по этой сущности мы разделяем клиентские проекты, на его основе мы определяем клиентский домен, создаём сопутствующие директории, генерируем конфигурации для каждого клиента.

Consul Connect — это часть Consul, которая предоставляет средства для безопасного и надежного сетевого взаимодействия между сервисами в распределенных системах.

Как это работает на практике:

1. Sidecar proxy: Consul Connect использует паттерн «sidecar proxy», что означает, что для каждого сервиса, который нужно обеспечить безопасным взаимодействием, создается дополнительный компонент — прокси (sidecar). Этот прокси отвечает за установление безопасного туннеля между сервисами.

2. Service registration: Сервисы, которые хотят взаимодействовать с другими сервисами, должны зарегистрироваться в Consul. Они сообщают свои сетевые адреса и другую информацию, необходимую для обнаружения.

3. Sidecar registration: После регистрации основного сервиса также создается и регистрируется sidecar прокси, который будет представлять этот сервис и обеспечивать безопасное взаимодействие.

4. Mutual TLS: Для обеспечения безопасности используется взаимная аутентификация с помощью TLS (Transport Layer Security). Все обмены данными между сервисами происходят через этот защищенный туннель.

Haproxy выступает в роли балансировщика, который определяет бэкенды приложения и балансирует нагрузку. Также он динамично определяет бэкенды за счет динамического поиска сервисов с помощью Consul. 

Магия Volumes в Nomad

Волшебство Nomad в том, что он позволяет работать с разными типами Volumes.

Архитектурные аспекты:

1. Типы Volumes: В кластере Nomad существуют различные типы Volumes для различных потребностей. Например, Local Volumes связаны с хост-машины и остаются на месте даже после удаления задачи, в то время как Shared Volumes могут быть доступны для нескольких задач и иметь более широкую область видимости.

2. Декларативная конфигурация: В Nomad конфигурация Volumes происходит декларативно. Это означает, что разработчики могут указать, какие Volumes должны быть доступны для каждой задачи в файле конфигурации. Кластер Nomad будет автоматически управлять созданием и монтированием Volumes в соответствии с определенными настройками.

3. Использование драйверов для различных хранилищ: Nomad поддерживает различные драйверы для хранения Volumes, что позволяет использовать различные хранилища данных, такие как локальные диски, NFS, Amazon EBS, и другие.

В нашей архитектуре мы использовали S3 хранилища, которые помогли обеспечить нам доступность, отказоустойчивость.

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

Заключение: Почему наша архитектура — это лучшее, что вы могли выбрать

Архитектура, объединяющая балансировщик NGINX, оркестрацию Nomad, Boundary и Consul, предоставляет надежное, масштабируемое и безопасное решение для развертывания приложений. Она обеспечивает высокую доступность, отказоустойчивость и гибкость в управлении доступом и конфигурацией. При выборе данной архитектуры важно учитывать требования вашего проекта и наличие навыков для эффективного конфигурирования и управления компонентами.

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

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

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

4. Простота в эксплуатировании: Nomad и Consul имеют возможность на лету менять конфигурацию кластера без остановки работы сервисов развернутых внутри. Они могут конфигурироваться через Ansible или Terraform. Имеют глубокую интеграцию между разными продуктами Hashicorp.

5. Ролевая политика (ACL листы): Тут все максимально просто. Применяешь различные настройки уровней доступа на разные сущности кластера.

6. Встроенное из коробки key/value хранилище: Vault это хорошая практика secret-менеджмента. Но он требует дополнительной экспертизы и мощностей. Consul и Nomad имеют встроенные хранилища секретов, которые могут использоваться для приложений.