Всем привет. Меня зовут Ярослав. Вместе с моим коллегой Володей, мы представляем команду 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. Именно по этой сущности мы разделяем клиентские проекты, на его основе мы определяем клиентский домен, создаём сопутствующие директории, генерируем конфигурации для каждого клиента.

Схема взаимодействия клиентских приложений в одном namespace
Схема взаимодействия клиентских приложений в одном 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 имеют встроенные хранилища секретов, которые могут использоваться для приложений.

Комментарии (12)


  1. LeshiyUrban
    30.12.2023 09:58

    А можно пожалуйста по детальнее про встроенные секреты в nomad и consul?


    1. hybahha Автор
      30.12.2023 09:58

      На это будет отдельный пост!


  1. mcleod095
    30.12.2023 09:58

    Написано очень поверхностно, никакой конкретики.
    Насколько помню namespace в номаде никак не ограничивает связь приложений в разных контурах, это чисто ограничение на видимость для операторов и тп. В consul поддержку namespace завезли только в платной версии вроде как.
    как подружить boundary с consul service discovery я вообще не нашел, что бы можно было как в consul connect быстро выбирать какие сервисы и хосты публиковать и кому.
    Как используется и для чего haproxy тоже непонятно, и что такое binta?


    1. hybahha Автор
      30.12.2023 09:58

      Это все же обзорный пост без конкретных инженерных решений.
      Отвечаю на ваши вопросы:
      1) Namespace - у клиента на основе него разграничиваются окружения для клиентов.
      2) В boundary давно обещают завести сервис дискавери. У. нас сейчас через баундари обеспечивается доступ как описано выше. К основным ресурсам за баундари. И через терраформ прокатывается доступы к ui приложней который он резолвит через consul connect.
      3) Haproxy используется в роли балансировщика для приложения в ситуациях когда приложение скейлится.


    1. hybahha Автор
      30.12.2023 09:58

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


      1. mcleod095
        30.12.2023 09:58

        Я вот в номаде не нашел такого ограничения, может не там искал.
        Да и в консуле ограничить общение приложений нельзя, ну если конешно не про consul connect и его Intentions.
        Сами используем nomad+consul+vault. Смотрим на boundary. Нравится тем что связка очень простая и настраивается довольно быстро.


  1. Hamletghost
    30.12.2023 09:58
    +3

    Я тоже фанат hashicorp (возможно даже их агент влияния) но новый проект на nomad в 2023 это необдуманное решение. Kubernetes объективно победил. Взять хотябы публичные облака. Я что-то не слышал про managed nomad в них, а вот kubernetes есть везде.

    Тудаже и consul connect - тоже не самый мейнстрим мягко говоря.

    просто представьте что с этим после вас будут делать хм… не фанаты hashicorp


    1. hybahha Автор
      30.12.2023 09:58

      Все же для использования кубером требуется опыт. И он нужен не малый. Это тоже объективный факт.
      Что мешает развернуть точно также номад в облаке?) У нас реализации в aws, yandex cloud. И в случае необзодимости наращивать ресурсы\добавлять ноды. Весь этот процесс не составляет труда и занимаетот силы 5-10 минут. Также как и даунскейлинг ресурсов \ клиент нод.
      А чем вам не нравится consul connect?
      На самом деле мне, честно говоря, проще представить как будет клиент работать с номадом чем с кубером. Тем более мы оставляем после себя подробный мануал по его эксплуатации. И как по мне документация у хашиков шикарно выполнена, на все случаи жизни.
      И основываясь на фидбеках клиентов им заходит номад лучше чем кубер) Как в части обслуживания так и в части эксплуатации.

      И хочу отдельно подсветить что номад прекрасен тем, что его инсталяция в облаке или селф-серверах мало чем отличается


    1. devhashiops
      30.12.2023 09:58
      +1

      Кубернетис победил кого? Простите?! Среди тех, кто использует Nomad, до сих пор немало громких имён. То, что кубернетис пытаются запихать в каждую дырку - это да, полностью согласен.
      Касательно публичных облаков, ну какбэ, Nomad не впарить всем подряд, это вытекающее из моего крайнего утверждения. Кубернетис хорошо продаётся, поэтому его везде запихали)
      Объективно, заказчику фиолетово, nomad или k8s или swarm, прости господи. Оно должно работать, не падать, выполнять свои бизнес задачи.
      И статья в общем-то не о том, как победить кубер, а о том, что можно не только него, можно делать хорошо на том стеке, что нравится. А если вы тоже любите, как и мы, хашикорп стек, то присоединяйтесь к нашему проекту Prism. Здесь мы в слоумо режиме пилим свой шаблонизатор для Nomad, потому что Levant нам не нравится) И мы уже его используем в наших проектах.
      Приходите, пробуйте, тестируйте, оставляйте обратную связь. Будем рады новым людям, неравнодушным к нашим Hashicorp-инициативам.


      1. AlexKMK
        30.12.2023 09:58

        Заказчику ещё важно, чтоб если вдруг на девопса упадет автобус или кирпич, он быстро нашел нового со знанием своего стека. И желательно не за тонны нефти.


        1. devhashiops
          30.12.2023 09:58

          Покажите мне заказчика, который не хотел бы "не за тонны нефти". Напротив, как по мне, инженеры, способные в кубер, обойдутся дороже.


  1. budnikovsergey
    30.12.2023 09:58

    У меня был опыт поддержки решения на hashicorp-стеке и я считаю, что будет большим преувеличением сказать, что этот стек в продуктиве не требует нескольких опытных и заменяемых инженеров. И он точно не обладает таким плавным переходом от простых до очень сложных возможностей, какие доступны для kubernetes. Да что там, один только Argo-stack и 100500 готовых helm chart чего стоят.