service discovery что это
Экосистема Docker: обнаружение сервисов (Service Discovery) и распределённые хранилища конфигураций (Distributed Configuration Stores)
Published on June 29, 2015
Серия туториалов
Этот туториал является 3-ой частью из 5-ти в серии статей Экосистема Docker.
Введение
Контейнеры предоставляют элегантное решение для тех, кто собирается проектировать и разворачивать масштабируемые приложения. В то время, как Docker реализует технологию контейнеризации, многие другие проекты помогают в развитии инструментов, необходимых для непосредственного процесса разработки.
Одной из ключевых технологий, на которую опираются многие инструменты работающие с Docker, является обнаружение сервисов (Service discovery). Обнаружение сервисов позволяет приложению или компоненту получать информацию об их окружении и “соседях”. Как правило, данный функционал реализуется при помощи распределённого хранилища “ключ-значение” (“key-value”), которое также может служить для хранения деталей конфигурации. Настройка инструмента обнаружения сервисов позволяет Вам разделить runtime-конфигурацию и сам контейнер, что позволяет использовать один и тот же образ в нескольких окружениях.
В данном руководстве мы обсудим преимущества обнаружения сервисов в кластеризованном Docker-окружении. Мы сфокусируемся на основных концепциях, но так же приведём и более конкретный примеры, где это будет уместно.
Обнаружение сервисов и глобально доступные хранилища конфигураций (Globally Accessible Configuration Stores)
Главная идея, лежащая в основе обнаружения сервисов, состоит в том, что любой новый экземпляр приложения должен быть в состоянии программно определить детали своего текущего окружения. Это необходимо для того, чтобы новый экземпляр мог подключиться к существующему окружению приложения без ручного вмешательства. Инструменты обнаружения сервисов обычно реализованы в виде глобально доступных реестров, которые хранят информацию об экземплярах приложений и сервисов, запущенных в данный момент. Большую часть времени реестр распределён по доступным в инфраструктуре хостам, чтобы сделать систему устойчивой к ошибкам (fault tolerant) и масштабируемой.
Хотя основная цель инструментов по обнаружения сервисов состоит в предоставлении деталей подключения для связи компонентов вместе, они так же могут использоваться для хранения любого типа конфигурационной информации. Многие приложения используют эту возможность в своих целях, сохраняя свою конфигурационную информацию с помощью инструмента обнаружения сервисов. Если контейнеры сконфигурированы таким образом, что они знают о необходимости проверять эти детали, они могут модифицировать своё поведение на основе найденных данных.
Как работает обнаружение сервисов?
Каждый инструмент обнаружения сервисов предоставляет API, который компоненты могут использовать для записи или получения данных. По этой причине для каждого компонента адрес обнаружения служб (service discovery address) должен быть либо жестко прописан в самом приложении/контейнере, либо предоставляться во время исполнения (runtime). Обычно, обнаружения сервисов реализовано в виде хранилища “ключ-значение”, доступного через стандартные методы http.
Инструмент обнаружения сервисов работает следующим образом: при запуске какого-либо сервиса, этот сервис регистрирует себя с помощью инструмента обнаружении сервисов. Инструмент обнаружения сервисов записывает всю информацию об этом сервисе, которая может понадобиться другим сервисам, работающим с данным, вновь запущенным, сервисом. Например, база данных MySQL может зарегистрировать IP-адрес и порт, на котором запущен демон, и, опционально, имя пользователя и учетные данные для входа.
При запуске потребителя первого сервиса, этот потребитель может запросить в реестре обнаружения сервисов информацию о первом сервисе. После этого потребитель может взаимодействовать с необходимыми компонентами, основываясь на полученной информации. Хорошим примером является балансировщик нагрузки (load balancer). Он может найти все backend-сервера, на которые можно распределять трафик, посылая запрос к службе обнаружения сервисов и изменяя свою конфигурацию соответствующим образом.
Как конфигурационное хранилище связано с обнаружением сервисов?
Ключевое преимущество глобально распределенной системы обнаружения сервисов состоит в том, что она может хранить любой другой тип конфигурационных данных, который может понадобиться Вашим компонентам во время выполнения. Это означает, что Вы можете вынести больше конфигурации из контейнера в среду выполнения более высокого уровня.
Обычно, для наиболее эффективной работы Ваши приложения должны быть спроектированы с разумными значения по умолчанию, которые могут быть переопределены во время выполнения приложений путем запросов к конфигурационному хранилищу. Это позволяет Вам использовать конфигурационное хранилище схожим образом с использованием флагов в командной строке. Различие заключается в том, что используя глобально доступное хранилище, Вы можете задать одинаковые настройки каждому экземпляру компонента без дополнительной работы.
Как конфигурационное хранилище помогает в управлении кластером?
Вот пример информации о хосте, которая может храниться в распределенном хранилище “ключ-значение”:
Эти данные, возможно, не то, о чём Вам надо заботиться при использовании системы обнаружения сервисов в обычных обстоятельствах, но они предоставляют инструментам управления возможность получать и модифицировать информацию о самом кластере.
Что насчёт обнаружения отказов (Failure Detection)?
Обнаружение отказов может быть реализовано несколькими способами. Суть заключается в том, что в случае отказа компонента система обнаружения сервисов должна узнать об этом и отражать факт, что указанный компонент больше не доступен. Данный тип информации жизненно необходим для минимизации отказов приложения или сервиса.
Многие системы обнаружения сервисов позволяют задавать значения с настраиваемым тайм-аутом. Компонент может установить значения с тайм-аутом и регулярно пинговать обнаружение сервисов. Если происходит отказ компонента, и достигается тайм-аут, информация о подключении для этого компонента удаляется из хранилища. Длительность тайм-аута, в основном, зависит от того, как быстро приложение должно реагировать на отказ компонента.
Что насчёт перенастройки сервисов при изменении параметров?
Это может быть реализовано несколькими способами. Поскольку пример с балансировщиком нагрузки является одним из основных сценариев использования данного функционала, существует несколько проектов, фокусирующихся исключительно на перенастройке балансировщика нагрузки при обнаружении изменений конфигурации. Поправка конфигурации HAProxy является типичным примером, ввиду его распространенности в сфере балансировки нагрузки.
Некоторые проекты являются более гибкими в том смысле, что они могут использоваться для вызова изменений в любом типе программного обеспечения. Эти инструменты регулярно опрашивают систему обнаружения сервисов и, при обнаружении изменений, используют системы шаблонов для генерации конфигурационных файлов с учетом последних изменений. После генерации нового конфигурационного файла затронутый сервис перезагружается.
Что насчет безопасности?
Ответ на этот вопрос во многом зависит от того, какие данные Вы помещаете в хранилище, и сколько уровней безопасности Вы считаете необходимыми для защиты своих данных. Почти все системы обнаружения сервисов позволяют шифровать соединения через SSL/TLS. Для некоторых сервисов приватность может быть не очень важна, и помещения системы обнаружения служб в приватную сеть может быть достаточно. Однако, для большинства сервисов, скорее всего, будет лучше предусмотреть дополнительные меры безопасности.
Другой подход заключается в ведении списков контроля доступа для разделения всего набора ключей в хранилище на отдельные зоны. Система обнаружения сервисов при этом может назначать владельцев и предоставлять доступ к разным ключам на основании требований, определённых для каждой конкретной зоны. Это позволяет предоставлять доступ к информации одним пользователя, сохраняя при этом её недоступной для других пользователей. Каждый компонент может быть сконфигурирован таким образом, чтобы иметь доступ только к необходимой ему информации.
Какие инструменты обнаружения сервисов наиболее популярны?
Теперь, когда мы обсудили некоторые общие особенности инструментов обнаружения сервисов и глобально распределенных хранилищ “ключ-значение”, мы можем упомянуть некоторые проекты, связанные с этими концепциями.
Вот список некоторых из наиболее распространённых инструментов обнаружения сервисов:
Некоторые другие проекты, расширяющие базовые возможности инструментов обнаружения сервисов:
Заключение
Обнаружения сервисов и глобальные конфигурационные хранилища позволяют Docker-контейнерам адаптироваться к их текущему окружению и включаться в существующую систему компонентов. Это необходимое условие для предоставления простой автоматической масштабируемости и развёртывания путем предоставления компонентам возможности отслеживать изменения в их окружении и реагировать на них.
В следующем руководстве мы обсудим способы взаимодействия Docker-контейнеров и хостов при помощи настраиваемых сетевых конфигураций.
Service Discovery
А сейчас мы поиграем в ролевую игру. Но не бойтесь, не в ту, что с костюмом медсестры, горничной или чистильщика бассейна. Вы всего-навсего будете играть роль админа в… скажем так, непростой ситуации.
Игра начинается
Итак, представьте: вы рулите большим проектом с огромным парком серверов. Ваш проект — гигантский онлайн-магазин, продающий корм для хомяков с доставкой. А в хозяйстве у вас — 10.000 серверов. Менеджмент вашей компании готовится к взрывному росту бизнеса сразу после начала новой рекламной кампании в следующий понедельник. Поэтому стахановскими темпами менеджеры растят мощность инфраструктуры и в срочном порядке закупают еще 10.000 серваков.
Задача: в течение недели вписать все новые серверы в инфраструктуру, раскатать на них ваш магазин и все дополнительные сервисы. Что будете делать?
Для тех, кто любит побольнее: ручная настройка
Допустим, приложение, обеспечивающее работу вашего магазина, работает на кластере из тысячи серверов (остальные 9.000 рулят базами данных, бэкапами и кэшированием). Серверы спрятаны за двумя балансировщиками нагрузки (два балансера на одном доменном имени — тоже своего рода балансировка, ведь при обращении по доменному адресу юзер может попасть как на первый балансер, так и на второй).
Вы решаете нарастить мощность вашего магазина, добавив еще серверов с приложениями.
Вот так. А что осталось сделать? Осталось сообщить балансировщику нагрузки о том, что у него в кластере приложения в подчинении появилось еще, скажем, 1000 серверов. Для этого нужно пойти в настройки балансировщика и вписать там руками адреса новых машин.
И вот теперь все заработало, как надо.
Конечно, можно разок напрячься и руками вписать 1000 адресов в конфиги балансировщика. А что делать, если балансировщиков 500, а серверов приложений у них в подчинении 100 000? И они еще и меняют адреса, умирают, переезжают?
Для тех, кто любит контролировать: Service Discovery
Проблемы управления инфраструктурой в таких масштабах с успехом решает специальный журнал, в который серверы и компоненты инфраструктуры сообщают о своих адресах и состоянии, как только они появляются в кластере. Любые системы, которым нужно знать обо всех серверах, в курсе, что всё это можно узнать в этом журнале (если, конечно, у них есть на это права). Система, которая ведёт такой журнал, называется Service Discovery (SD). Посмотрим, как это работает.
Итак, вы засунули в ваш кластер приложения 1000 новых серверов приложений. Всем им админы задают адрес системы Service Discovery (например, с помощью системы автоматизации развертывания серверов), у которой надо прописаться, и немедленно шлют туда сообщение типа “Привет, я сервер приложения, я готов к работе, и вот мой адрес”. Service Discovery принимает подобные запросы не только от серверов приложений, но и от любых инфраструктурных компонентов в сети. В итоге получается, что этот сервис-всезнайка может в любой момент точно сказать, какие серваки есть в сети, что они делают и где живут.
Балансировщик нагрузки, вместо обращения к своим собственным файлам конфигов, раз в N секунд обращается в Service Discovery и запрашивает там список живых серверов приложений. После очередного цикла работы балансировщик получит обновленный список серверов приложений и начнет распределять нагрузку по всем новым машинам.
Поздравляю, мы только что перараспределили нагрузку в системе и включили новые серверы в кластер, не потратив на это ни секунды своего человеческого времени.
В Service Discovery можно запихивать любые компоненты инфраструктуры — базы данных, серверы кэширования, микросервисы, резервные машины.
При любых изменениях в системе все заинтересованные части получат обновленные состояния инфраструктуры и изменят свою работу под новые условия. А заинтересованных агентов обычно много — балансировщики желают знать свои кластеры приложений, приложения хотят знать свои СУБД и системы кеширования, системы мониторинга хотят знать сервисы, подлежащие наблюдению… Короче, желающих быть в курсе дел вашей инфраструктуры набирается много. А изменения состояний — это не только появление новых серверов, но и их выход из строя, переезд, перенос между подсетями. Как хорошо, что всё это решает Service Discovery!
Какие бывают Service Discovery?
ZooKeeper
Проект от Apache Foundation, пионер концепции Service Discovery. Написан на Java, крепок и стабилен, но тяжеловат в настройке и уступает по многим параметрам его более современным потомкам. Сегодня хорош, скорее, в качестве музейного экспоната и экскурса в историю динозавров. При разработке новых приложений его лучше не использовать.
Etcd
Простой, как топор, быстрый и очень гибкий продукт. В нем можно регистрировать серверы, хранить конфиги и держать состояния всех компонентов вашей инфраструктуры.
Крайне прост и надежен, но лишён многих полезных фич. Прекрасный выбор для тех, кому важна скорость и гибкость.
Consul
Пожалуй, лидер современного топа Service Discovery. Чуть более тяжелый и медленный, чем Etcd, но взамен предлагающий кучи крутых плюшек. Например, веб-интерфейс для работы со списками сервисов.
Kubernetes
Kubernetes умеет дофига всего, в том числе и Service Discovery. Это не его основное предназначение, он создавался совсем для других целей. Но для ряда проектов (особенно для тех, кто всё упаковывает в контейнеры и строит из них крупные кластеры) средства Service Discovery, предлагаемые Kubernetes по умолчанию, вполне сойдут.
Стоп-слово и конец ролевой игры
Вот и закончилась наша ролевая игра в админа. Мы начали с болезненного опыта, в котором админ терпит унижения и боль, а закончили легким и приятным сценарием, в котором админ познает прелести Service Discovery и учиться доминировать над огромными парками серваков.
Начните внеднять Service Discovery в ваши проекты в тот момент, когда у вас в хозяйстве появляется 20-30 машин, и следуйте этой практике на каждом этапе роста вашей компании. Переезды, выход оборудования из строя и взрывной рост мощности всегда будут проходить гладко и быстро.
Простой service discovery в Prometheus через Consul
Закон Парето (принцип Парето, принцип 80/20) — «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».
Wikipedia
Приветствую тебя, дорогой читатель!
Моя первая статья на Хабр посвящена простому и, надеюсь, полезному решению, сделавшим для меня сбор метрик в Prometheus с разнородных серверов удобным. Я затрону некоторые подробности, в которые многие могли не погружаться, эксплуатируя Prometheus, и поделюсь своим подходом по организации в нём легковесного service discovery.
Для этого понадобится: Prometheus, HashiCorp Consul, systemd, немного кода на Bash и осознание происходящего.
Если интересно узнать, как все это связано и как оно работает, добро пожаловать под кат.
Встречайте: Prometheus
Kubernetes Documentation, Configuration Best Practices, General Configuration Tips.
*Админы почему-то очень любят хранить в конфигах строки по-умолчанию в виде комментариев, создавая из файла конфигурации настоящую свалку. Не нужно этого делать!
Вспомним про HashiCorp Consul
Будучи уже знакомым с Consul, я знал, что сам он не узнает о сервисах даже на тех машинах, на которых запущен его agent. Через его простое HTTP API сервис нужно зарегистрировать в Consul, а еще его можно разрегестрировать. Ведь бывает, что сервис больше никому не нужен: попробовали, и не подошел. В полном объеме я никогда не использовал Consul. Возникали только задачи, с которыми Consul отлично справлялся частью своих функций: KV-хранилище, HashiCorp Vault, кластеризация Traefik. И, например, никогда не нужен был его DNS. Вот и сейчас задача стояла не усложнить себе жизнь, запуская на каждом сервере по дополнительном сервису в виде Consul agent. Достаточно запустить один инстанс Consul, который будет принимать запросы в HTTP API и к нему будет обращаться Prometheus за списком адресов, по которым расположены те или иное сервисы. Идеально, если это все будет по HTTPS, хотя сеть и так закрытая.
На такой волне стало понятно, что уже имеющийся в Kubernetes StatefulSet Consul, обеспечивающий кластерную работу Traefik, можно использовать для service discovery в Prometheus. И даже Ingress в локальную сеть у него уже был, так как было пару моментов использования Consul’s web UI. Бонусом Traefik обеспечивал ему HTTPS-транспорт с сертификатом от Let`s Encrypt через DNS Challenge.
На этом этапе у меня имелся Prometheus, который готов забрать из Consul адреса сервисов и начать собирать с них метрики, и инстанс Consul, в котором можно регистрировать сервисы. Возникает задача автоматизировать децентрализованную регистрацию сервисов во время запуска на любом сервере инфраструктуры. И на помощь приходит простой Bash.
Время для Bash и systemd.service
В своей инфраструктуре я давно использую иммутабельную CoreOS Container Linux. Было даже дело рассказать об этой ОС на DevOpsConf Russia 2018. Я и по сей день использую эту ОС как основную для запуска сервисов в эфемерных Docker контейнерах, оборачивая в systemd.service. Но только теперь это Flatcar Linux, разработчики которой подхватили идею и не дали ей погибнуть, обеспечив полную совместимость с CoreOS Container Linux. А перейти с CoreOS на Flatcar можно простым обновлением системы!
Как раз вот тут появляется некий /opt/bin/consul-service. У него всего пара переменных системного окружения и несколько обязательных аргументов, которые я опишу поподробней.
Если вы до сих пор работаете со своими серверами в локальной сети по IP, то самое время присвоить себе тоже какой-нибудь идентификатор и обязать коллег обращаться к вам только по нему. И больше ни на какие обращения не реагировать. Так будет справедливо и быстро осознается ценность имени.
consul-service написан на чистом Bash в
60 строчек. В зависимостях у него только хорошо известный всем cURL и Bash. Уверен, что админ без опыта разработки бегло разберется в нескольких строчках этого скрипта. Лицензия этого макро-решения MIT, поэтому если появится необходимость доработать его под свои нужды, не стесняйтесь.
Тот самый scrape_configs в prometheus.yml для prometheus/node_exporter, запущенном на всех серверах, лаконичен и не зависит никак от количества серверов.
О том как Ansible, а точнее Python, попадает и работает на серверах Flatcar Linux думаю, можно рассказать в будущих статьях. В планах посвятить целый цикл статей про иммутабельную ОС Flatcar Linux.
В заключение
Наверное, можно считать всю эту конструкцию неким велосипедом. Но в эксплуатации и передачи коллегам такого велосипеда на поддержку стало сразу ясно, что он простой как «рама+колеса+педали+руль», и ездить на нем удобно. И почти в обслуживании не нуждается.
А лучшей похвалой этой статье станет мысль читающего — “Интересное решение! Надо попробовать!”.
Как вам поможет Service Discovery и управление секретами инфраструктуры в 1С и не только
Давайте разберемся, зачем в 1С может потребоваться Service Discovery, для чего вообще нужна эта кухня?
Service Discovery обычно упоминается в контексте микросервисной архитектуры, но в 1С применялась очень редко. Я не помню ни одного более-менее крутого кейса об использовании Service Discovery в рамках 1С. Были интересные идеи, но их мало. Я решил восполнить этот пробел, тем более, что сейчас я именно этим и занимаюсь в рамках развертывания инфраструктуры.
Что такое Service Discovery
Для чего вообще Service Discovery используется в большом ИТ? Представьте себе известный сайт, например, AliExpress. Как все знают, он работает на своих серверах, у них большие дата-центры, они используют Kubernetes, микросервисную архитектуру и так далее. Каждая функция, каждая операция на этом большом монстре – площадке AliExpress – разбита на маленькие кусочки.
Когда наступает Черная пятница, большое количество людей бежит на AliExpress покупать себе что-то хорошее. Из-за увеличения количества сеансов некоторые микрофункции сервиса начинают сильно нагружаться, но благодаря Kubernetes и возможностям горизонтального масштабирования самих инстансов этих функций, способных поглощать нагрузку, становится много. Но проблема не в том, что их стало много, проблема в том, что серверу нужно знать о том, что они появились – должно быть какое-то централизованное место, которое скажет: «Ребята, у меня появился новый сервис, он вон там, к нему нужно обратиться и взять какие-то данные».
Это и есть Service Discovery – такое централизованное место, которое, как гуру, подсказывает, где расположен нужный сервис, как к нему обратиться. Неважно, какой это сервис: главное, что он есть, и что он доступен в текущий момент.
Зачем в 1С может понадобиться Service Discovery и хранение секретов
Сегодня мы по большей части будем говорить про программы от HashiCorp – Consul и Vault. Consul – это Service Discovery, а Vault – сервис для хранения секретов.
Каким образом это можно привести к 1С? Я расскажу несколько кейсов.
Давайте себе представим такую ситуацию: у нас есть некая инфраструктура, которая состоит из нескольких информационных 1С-баз, сайта (например, интернет-магазина) и ряда внешних сервисов типа датчиков производства, снимающих метрики оборудования. У этой инфраструктуры много пользователей, команда разработчиков, возможно, даже подрядчиков.
Такая система порождает большое количество вторичных настроек: параметры подключения к информационным базам, настройки общих каталогов, адреса веб-сервисов, секреты.
В подавляющем большинстве настройки взаимодействия хранятся внутри информационной системы, и это приводит к следующему:
Переезд одного сервиса в другое место требует изменения этих настроек в других местах.
Вторичным моментом этого станет необходимость дублирования настроек и секретов. В частности, нам приходится хранить в 1С пароли пользователей, точки подключения и пути подключения к внешним информационным базам в справочниках, что явно очень небезопасно. Представьте, что мы берем какую-то информационную базу, делаем ее бэкап и отдаем этот бэкап подрядчику: внешнему или внутреннему, неважно. Получается, что через эту базу мы даем подрядчику возможность получить неправомерный доступ к нашим продуктивным информационным системам. Дело в том, что когда мы базу разворачиваем, у нас в БСП есть механизм, который при разворачивании копии базы показывает, что база перемещена, и предлагает отключить регламентное задание. Механизм крутой, но он не гарантирует, что информационная база при включении регламентного задания – либо других ручных действий пользователя – не получит доступ к продуктивным интегрированным системам через тот же самый план обмена, потому что там есть каталог, который мы выгружаем, и база, с которой мы соединяемся. Многие встречали ситуации, когда копия базы ухитрялась делать обмен с продуктивной базой, потому что в том или ином виде подрядчику передаются пароли и секреты подключения к продуктивным информационным базам. Причем, очень часто пароли захардкожены прямо в код. И когда мы отдали эту конфигурацию, наш подрядчик видит, что есть ресурс, к которому можно подключиться, и логин-пароль для этого. Теперь компрометация этого логина-пароля, чтобы они уплыли дальше, уже дело времени. Он уплывет – 100%.
Третий момент – сложность построения тестовых площадок. Допустим, мы отдали клиентам тестовую базу и теперь нам нужно развернуть для нее тестовую инфраструктуру. Нам нужно узнать строки подключения, логины и пароли к интегрированным системам. Естественно, все эти секреты будут отправлены в Skype или в Telegram, т.е. пароли «поплывут». А нам потом нужно будет вручную зайти и поправить эти данные авторизации. Это время и явное снижение безопасности.
Это основные моменты, почему нам нужен Service Discovery и сервис хранения секретов для 1С. Они хранят данные о сервисах, а база 1С – это такой же сервис, ничем не отличающийся от приложений и микросервисов, только большой. Ведь сервис – некое приложение, осуществляющее действия для пользователя. 1С-ка осуществляет действия для пользователя, значит, по факту, это тоже сервис.
Возможности Service Discovery – Consul
Service discovery – некий справочник о метаинформации, «желтые страницы» сервисов. Я вспоминаю свои студенческие годы, и в институте на кафедре ИТ-нам давали книжечки, которые назывались «Желтые страницы интернета». Там были описаны веб-адреса сайтов, которые в то время вообще существовали в сети.
По факту, Service Discovery – это точно такой же ресурс «Желтых страниц». Он тоже говорит нам о том, какие сервисы есть в сети.
Как я и говорил, все это относится к реализации слабых связанностей между компонентами и системами. Мы малыми шагами идем к микросервисному паттерну разработки Service Oriented Architecture (SOA), описывающему архитектуру приложений в виде атомарных компонентов со слабой связанностью, которые общаются между собой по стандартным протоколам (например, через REST).
Логическим продолжением или подмножеством SOA является микросервисная архитектура. Она базируется на увеличении количества сервисов вместо увеличения функциональности конкретного сервиса и глубокой интеграции с continuous-процессами.
Что я этим хочу сказать? При жесткой настройке связей сервисов (из примера, который я рассказывал ранее) мы получаем единый моноблок. Чтобы этого избежать, нам нужно его декомпозировать на отдельные, более мелкие элементы и дать им общаться между собой более свободно.
Понятно, что прикладные решения 1С микросервисами назвать нельзя. Но если посмотреть на инфраструктуру в целом глобально, можно сказать, что конфигурация 1С – сервис, который осуществляет определенные действия для пользователя.
Нам необходимо использовать единую информационную систему, которая должна:
знать о том, что этот абстрактный сервис запустился, причем она должна узнать это сама;
иметь функциональность проверки работоспособности сервиса: существует он сейчас или не существует;
поддерживать хранение дополнительной метаинформации о сервисе в формате key-value;
иметь возможность отдавать несекретные данные всем заинтересованным информационным системам в любой момент времени (естественно, при наличии у сервиса прав на это).
Переходим к Consul – это OpenSource приложение, которое позволяет развернуть инфраструктуру Service Discovery в вашем окружении. Причем Consul – это безотказная, масштабированная, кластеризованная система, которая разворачивается в виде группы серверов, и каждый из этих серверов несет полноценный срез данных по существующим сервисам в инфраструктуре.
Service Discovery можно рассматривать как некий реестр метаинформаций распределенной архитектуры, в котором хранятся данные по компонентам. Это позволяет реализовать взаимодействие компонентов с минимальным ручным вмешательством.
Service Discovery позволяет обнаруживать сервисы и заносить их в базу, называемую каталогом. Все это делается автоматически либо самим приложением, либо скриптами, которые его формируют. Вам не нужно запускать какой-то сервис, а потом самостоятельно его регистрировать. При развертывании приложение регистрируется в каталоге автоматически. Так же и 1С.
Любое приложение, использующее Consul, обращается к нему через localhost. Самому приложению не нужно знать, где находится Service Discovery, оно стучится туда локально. Consul берет на себя взаимодействие внутри кластеров для обмена так называемых сплетен.
Для интеграции с Consul и поиска данных предлагается использовать API, реализованное через интерфейсы HTTP или DNS. Последний вариант дает возможность работать с Consul приложениям, которые вообще ничего о нем не знают и поддерживают всего два вида DNS-запросов: поиск узлов (node lookup) и поиск сервисов (service lookup)..
Хранение секретов – Vault
Следующий нужный нам элемент – Vault, сервис хранения секретов.
Допустим, у нас есть какие-то сервисы, зарегистрированные в Consul. Но как узнать, какие логины и пароли нужны, чтобы к ним достучаться? Для этих целей и нужен Vault.
«Под капотом» для хранения секретов Vault использует тот же самый Consul – данные в зашифрованном виде хранятся в реестре метаинформации key-value в Consul.
Vault – инструмент, который позволяет хранить секреты в формате JSON (это его основное разрешение).
Отличительные черты Vault:
Сервис хранения секретов должен обладать гибкой системой распределения доступа, что Vault и дает. Он дает не только регламентированный доступ, но и четко идентифицирует: кому этот секрет доступен, что он может с ним сделать, и в течение какого времени он сможет с ним поработать. У него есть политика доступа Access Control List (ACL), которая позволяет четко управлять не только самим секретом, но и группой секретов, их видимостью, доступностью, просмотром и чтением.
Правила могут храниться в Git и подключаться при развертывании и обновлении самого Vault. Помимо этого есть аудит доступа: каждый акт доступа записывается самим Vault и хранится – мы знаем, кто и в какой момент запросил этот пароль. Теперь все интегрированные системы идут в Consul, спрашивают, где находится сервис. Затем запрос идет в Vault, где фиксируется, что такой-то компонент запросил секрет к такому-то сервису.
Так же, как и Consul, Vault работает локально – все запросы идут в локальный Vault, а дальнейший обмен между Vault, Consul и другим источником хранения секрета уже не касается работы самого приложения. Плюс этой схемы – снижение периметра атаки. Чем меньше размазанность хранения паролей по системе – тем лучше.
У Vault очень хорошее, гибкое REST API. С помощью токена вы можете запрашивать пароль для конкретного сервиса, причем пароль может быть временным. И даже необязательно это будет логин и пароль: секретные данные в Vault хранятся в виде json.
Следующий момент – локальный запрос пароля, когда ваш компьютер при запуске программы авторизуется в Vault и получает токен внутри переменных среды. Например, вам нужно запускать 1С-ку, которая запускается не с обычного ярлыка, а со скрипта, который перед запуском подключится в Vault и скажет: я такой-то компьютер, дай мне логин и пароль для текущего пользователя, который у тебя хранится. Это некий аналог доменной авторизации, который тоже в некоторых случаях может использоваться. Я не говорю, что этот вариант лучше, но хранение секретов в едином месте, которое дает регламентированный доступ – это круто.
Итак, Vault – хранилище секретов, которые хранятся в виде key-value либо в виде json-файлов (как будет удобнее).
Причем можно создавать собственное хранилище секретов, которое в принципе недоступно даже root-пользователям. Например, у вас есть личные секреты, доступ к которым вы не хотите давать даже администраторам. Вы можете использовать в Vault свой собственный раздел для хранения секретов, к которому даже root-пользователи доступ не получат.
Реализация в инфраструктуре
Теперь расскажу, каким образом это работает все это у нас в инфраструктуре.
Consul и Vault – единая точка интеграции сервисов.
Все конфигурации, которые у нас развертываются, при развертывании автоматически регистрируются в Consul и выдают оттуда определенный перечень информации.
Интернет-магазин и личный кабинет, которые у нас работают, тоже интегрируются вместе с Consul, но через оркестраторы микросервисов.Интернет-магазин и личный кабинет у нас разворачиваются в виде docker-приложений, и при развертывании регистрируются в Consul автоматически и прописывают: где и какие порты используют.
Мы используем Consul как DNS-сервер и осуществляем доступ за счет вот этого.
Также у нас при регистрации в Consul автоматически создается раздел хранения секретов в Vault. Когда мы стучимся в Consul, мы говорим: а где хранятся секреты в Vault? И он четко указывает этот путь. Это напоминает путь хранения на жестком диске в ОС Linux, где нет дисков – допустим, kv/clients/mycompany и т.д..
Помимо этого есть еще различные сервисы. Например:
Traefik – сервис, который управляет инфраструктурой: своего рода обратный реверс-прокси. Он напоминает Nginx, только более крутой. Он может использовать в качестве провайдера не только Docker, но и сам Consul. Именно благодаря ему сервисы при развертывании в Docker автоматически регистрируются в Consul и становятся публичными для общественности, получают DNS-имена.
Jenkins – он интегрируется с Consul и получает параметры подключения к информационным базам для тестовых средств.
GitLab – тоже использует Consul для получения параметров подключения.
И какие-то другие приложения, которые выступают, как внешние источники данных.
Все это завязывается на Consul. А Consul – отказоустойчивая система.
Интеграция 1С и Consul
Как интегрировать 1С и Consul? Нами было разработано расширение, которое не зависит от информационной базы и встраивается в любую конфигурацию. Задача расширения – при запуске проверить уникальность информационной базы и наличие ее регистрации в Consul.
В качестве ключей для регистрации мы используем:
имя сервера 1С и имя базы – если это серверная база;
или путь к информационной базе и имя текущего хоста – если это файловая база.
Когда база запускается – она идет в Consul и уточняет, зарегистрирована ли она в нем. Consul отвечает: «Я не знаю, кто ты». Тогда база начинает регистрироваться, но при этом уточняет: «А нода, машина, на которой я запустилась, зарегистрирована?» – «Нет» – отвечает Consul – «Тогда давай зарегистрируем ноду». После регистрации ноды база регистрируется сама и заносит для этого сервиса определенные значения key-value.
Для применения полученных значений в базе, а также для формирования новых пар key-value мы сейчас реализуем в расширении поддержку пользовательских скриптов. База же не только должна зарегистрироваться в Consul и Vault, но и узнать оттуда, какие сервисы сейчас существуют в окружении базы, и какие она может использовать.
На слайде видно, что база может быть основная, а может быть и не основная – тестовая. Основная – это продуктивная ИБ. Поэтому текущее развертывание должно зайти туда и спросить, какие значения она может использовать: ключи, параметры авторизации и пути к секретам в Vault, где они хранятся для этих сервисов.
Мы реализуем не только поддержку Consul, но и возможность быстрой смены обработчиков взаимодействия Service Discovery. Это позволяет нам манипулировать: кто хочет работать с Consul, а кто-то – с другими инструментами. Например, кто-нибудь напишет Service Discovery на OneScript – наверное, такое себе приключение, но, может, кто-то и захочет.
Consul выглядит вот так. На экране вы видите ноды, которые сейчас доступны.
Нода – это некий компьютер, на котором крутятся сервисы. В качестве операционной системы у этого компьютера может быть Windows, Linux – не важно. В качестве сервисов – необязательно 1С, это могут быть docker-приложения, веб-сервисы, MS SQL, PostgreSQL. Что хотите называть сервисом, то и будет. Нода должна осуществлять доступ к этому сервису, его развертывание и управление этим сервисом.
Как нода может появиться? Я говорил, что Consul может работать локально, а может – через REST API.
Когда Consul работает локально, мы его объединяем в кластер. Настройка кластера осуществляется при запуске Consul через конфигурационный файл либо через параметры запуска. И когда мы запускаем Consul локально, нода появляется. Допустим, здесь на слайде sport1, sport2, sport5 – это ноды, которые подключены в Consul локально.
Но есть ситуации, когда мы запускаем инстанс на тестовой базе разработчика удаленно и не хотим разворачивать Consul у него локально. Тогда мы можем создавать ноды через запросы, используя REST API. Ноды на слайде Office и AttlassianTest.Sport как раз запущены через REST API.
А вот так выглядит пример самого сервиса. ФинБазаОСКК – это наша конфигурация, которая запустилась и зарегистрировалась в Consul.
При этом у каждого сервиса есть инстансы развертывания, это уже третий показатель. Внизу – основная база, а сверху – тестовая среда.
На ноде развернут сервис, а сервисы одинаковые: мы взяли бэкап ФинБазыОСКК и раскатили его в другом месте – Васе или Пете. Сервисы те же самые, а инстансы разные.
Мы этот бэкап подключаем, как отдельный инстанс, их может быть очень много. Они могут жить и могут удаляться.
Единственную сложность вызывает удаление этих сервисов. Но это тема для отдельного разговора.
Зарегистрированный сервис заносит туда определенный набор значений, key-value.
Для файловой базы набор значений будет вот таким:
ONEC_DABE_NAME – имя базы;
ONEC_SERVER_NAME – эта база зарегистрирована на сервере Sport1;
VAULT_SECRITS_CI – путь хранения секретов, как я уже говорил, он указывается в формате unix-пути, разделенный слэшем;
и дальше указывается какой-то набор дополнительной информации, которую вы хотите туда занести, которая специфично относится к текущей конфигурации, текущему сервису, и, которая, в дальнейшем понадобится для интеграции другим приложениям.
Для 1С набор этих параметров будет одним, для Jenkins – другим.
Все эти значения key-value, они могут дополняться – мы в любой момент можем их изменить или дополнить чем-то на одном сервисе или сразу на группе сервисов.
Итак, сервис создался. У нас есть к нему доступ, все замечательно. А еще у нас есть ресурс, который может к нему подключиться. Где этому ресурсу взять параметр авторизации?
Для этого у нас есть параметр – путь хранения секретов, вы видите его на слайде. При этом сами секреты у нас хранятся в Vault.
Vault – это тоже веб-приложение, у него есть интерфейс. Здесь в данном случае мы видим четыре раздела хранения
cubbyhole – ваш персональный раздел, где хранятся секреты, недоступные никому, кроме вас.
DevOps – набор секретов, размещенных для использования сборочных линий.
infrastructure – пароли к различным инфраструктурным сервисам.
kv (key-value) – секреты доступа и параметры авторизации для приложений-клиентов (например, для информационных баз).
Сейчас я в качестве примера расскажу один из кейсов реализации. Это реализация сборочной линии для 1С-приложений и интеграция его с Consul.
У нас есть несколько информационных баз, в которых осуществляется две операции:
gitsync – операция синхронизации хранилища и Git через GitSync;
testAndBuild – тестирование конфигурации, например, синтаксическая проверка, проверка SonarQube, TDD, BDD-тестирование, сборка поставки и так далее.
Каждая из этих операций требует себе набор определенных параметров – путь к базе, секреты пользователей, путь хранения каких-то конфигурационных файлов, секреты доступа к Git и так далее.
Раньше мы их хранили в Jenkins и нам приходилось их дублировать в нескольких местах – в Jenkins хранить, пользователю отдавать и т.д.
В итоге мы пришли к тому, что хранить их нужно в одном месте – в Vault. На слайде показано два раздела, в которых у нас хранятся секреты.
А здесь показано, как выглядит хранение секретов для каждого раздела.
Например, здесь для testAndBuild хранятся не только секреты, но и параметры, которые по факту могли быть и не секретными.
Но на тот момент, когда мы начали развивать инфраструктуру, было проще начать с того, что все данные хранить только в Vault. А позже мы начали разделять: то, что секретное – хранится в Vault, а то, что является публичным – в Consul.
Сделаю ремарку: здесь хранятся не только секреты, но и пути к файлам.
Такие же настройки у нас заданы для GitSync – они выглядят вот таким образом.
Здесь видно переключатель JSON, что значения секретов можно задавать не в виде пар key-value, а сразу в виде JSON.
В Jenkins разработана сборочная линия, которая интегрируется с Consul/Vault и спрашивает: где параметры авторизации сервисов и баз, которые у нас зарегистрированы, для тех двух задач, которые у нас запускаются – GitSync и testAndBuild.
В итоге получается, что база тестируется, мы видим, что прогоны тестов прошли, но в сборочной линии не хранятся параметры, секреты сборки… Все настройки хранятся в Git.
Теперь при запуске новой сборочной линии нам нужно задать параметры авторизации для нее вручную в Vault.
Вот таким образом системы, которые, казалось бы, невозможно связать между собой, связываются, и между ними мир, дружба, жвачка. Невозможное возможно.
Вопросы
Где это реализовано?
Это реализовано у нас в инфраструктуре, внутри компании “Серебряная Пуля”. Мы используем это для наших клиентов, пока нет решения о том, что это будет OpenSource-решением.
Можно ли реализовать связку PostgreSQL+Consul?
Можно реализовать любую связку – ЧтоТо+Consul – появилось, зарегистрировалось и работает.
Есть база Прод1 и база Прод2. Они связаны планами обмена, HTTP-сервисами и т.д. Мы делаем копию обоих баз – получилась база Копия1 и база Копия2. Что нужно сделать, чтобы Consul решил проблему перенастройки связей между Копией1 и Копией2?
Здесь мы хотим как раз подключать микросервисы с помощью таких инструментов, как OpenFaaS либо OpenWhisk. То есть, мы пишем какие-то маленькие приложения на том же OneScript, запаковываем их в Docker, реализуем REST API. И когда новой базе потребуется постучаться в какой-то микросервис, она спросит у Consul – куда обратиться. Она постучится в этот микросервис, а он уже либо возвращает, к кому нужно подключиться, либо формирует новое окружение – создает тестовую сборочную линию, новые тестовые базы и т.д. Сейчас мы переходим на микросервисную архитектуру в OpenFaaS и у нас это частично уже начинает реализовываться, но не полностью.
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск. Больше статей можно прочитать здесь.
Приглашаем всех принять участие в INFOSTART EVENT 2021 (6-8 мая, СПб).