Поисковая система по каталогам GAIA-X - под капотом
В современном мире, а теперь и в большей степени с недавними карантинными мерами, мы полагаемся на облачные сервисы для работы нашей инфраструктуры и хранения наших данных.
Инициатива GAIA-X возникла из-за необходимости повысить осведомленность о суверенитете данных и создать надежную федеративную облачную экосистему для Европы.
В этой статье мы обсудим, как группа демонстраторов GAIA-X, состоящая из 3DS OUTSCALE, Docaposte, German Edge Cloud, Orange Business Services, OVHcloud, Scaleway и T-System, создала прототип поисковой системы по каталогам.
Одной из целей поисковой системы по каталогу было дать пользователю возможность искать и выбирать услуги, соответствующие их потребностям. Цель состоит в том, чтобы быть инклюзивным и предоставлять информацию пользователям, чтобы они могли сделать прозрачный и осознанный выбор. Информация, описанная для каждой услуги, включает, по крайней мере, все соответствующие «Правила политики», определенные руководством GAIA-X как обязательные, и набор технических описаний. «Правила политики» охватывают множество областей (защита данных, безопасность, обратимость и т. Д.) И разработаны в двух документах: один для правил политики инфраструктуры, а другой — правил политики данных и программного обеспечения.
Конечно, все это должно быть доступно в машиночитаемом формате, чтобы обеспечить автоматический выбор услуг.
Первый шаг — составить список различных сценариев инфраструктуры на основе каждого из наших запросов клиентов и извлечь семантику из требований.
Например, если клиент запрашивает « базу данных, соответствующую стандарту PCI-DSS для платежных услуг, размещенную в Германии в соответствии с Кодексом поведения по защите данных CISPE », интересующими объектами являются « база данных », « PCI-DSS », « Германия ». и « Защита данных CISPE ».
Но как сущности соотносятся друг с другом и как они определяются? И можно ли их классифицировать?
Одним из интуитивно понятных способов представления семантики было использование графиков, подобных приведенным ниже:
Помня об этих различных сценариях, мы нашли шаблоны и решили, что в первом выпуске будет простая онтология графовой базы данных (ниже):
Эта онтология не предназначена для покрытия всех будущих потребностей GAIA-X. У нас есть более сложные онтологии, которые мы рассмотрим в следующих статьях.
Мы также определили таксономию для классификации сервисов и включения атрибутов на узлах.
Следующим шагом было развертывание среды разработки и подготовки. Мы решили не создавать производственную именованную среду, чтобы избежать путаницы и подчеркнуть тот факт, что этот демонстратор является реализацией того, как каталог GAIA-X может работать, а не обязательно, как он будет реализован позже.
Мы использовали Gitlab с управляемой кластерной интеграцией Kubernetes и стандартными настройками конвейера CI / CD для развертывания микросервисов. Для хранения данных мы использовали графовую базу данных Neo4j.
Следующим шагом с онтологией и таксономией было заполнение базы данных.
Чтобы ускорить разработку, мы сосредоточились на сервисе Object Storage для релиза. Каждый из облачных провайдеров, работающих над демонстратором, заполнил базу данных описанием своего сервиса Object Storage.
Наконец, поскольку одним из критериев GAIA-X является удобство использования, мы создали интуитивно понятный способ запроса базы данных с помощью классического пользовательского интерфейса поисковой системы.
Для расширенных запросов мы решили не раскрывать язык запросов Neo4j Cypher, а создать еще более простую грамматику синтаксического анализа, основанную на отношениях между узлами и их атрибутами. Это позволило нам реализовать поле ввода произвольной формы с автозаполнением. Мы использовали движок Parsing Expression Grammar PEG.js, используя следующую грамматику:
Эта грамматика позволяет пользователю выражать более сложные запросы, такие как:
Наконец, исходный код выпущен под лицензией BSD-3, и мы предоставляем спецификации OpenAPI, JSONSchema и JSON-LD для облегчения взаимодействия и повторного использования.
В заключение, мы гордимся тем, что часть этой работы уже отражена в документе по технической архитектуре GAIA-X, и что нам удалось успешно работать вместе над общим видением европейской экосистемы.
Инициатива GAIA-X возникла из-за необходимости повысить осведомленность о суверенитете данных и создать надежную федеративную облачную экосистему для Европы.
В этой статье мы обсудим, как группа демонстраторов GAIA-X, состоящая из 3DS OUTSCALE, Docaposte, German Edge Cloud, Orange Business Services, OVHcloud, Scaleway и T-System, создала прототип поисковой системы по каталогам.
Одной из целей поисковой системы по каталогу было дать пользователю возможность искать и выбирать услуги, соответствующие их потребностям. Цель состоит в том, чтобы быть инклюзивным и предоставлять информацию пользователям, чтобы они могли сделать прозрачный и осознанный выбор. Информация, описанная для каждой услуги, включает, по крайней мере, все соответствующие «Правила политики», определенные руководством GAIA-X как обязательные, и набор технических описаний. «Правила политики» охватывают множество областей (защита данных, безопасность, обратимость и т. Д.) И разработаны в двух документах: один для правил политики инфраструктуры, а другой — правил политики данных и программного обеспечения.
Конечно, все это должно быть доступно в машиночитаемом формате, чтобы обеспечить автоматический выбор услуг.
Первый шаг — составить список различных сценариев инфраструктуры на основе каждого из наших запросов клиентов и извлечь семантику из требований.
Например, если клиент запрашивает « базу данных, соответствующую стандарту PCI-DSS для платежных услуг, размещенную в Германии в соответствии с Кодексом поведения по защите данных CISPE », интересующими объектами являются « база данных », « PCI-DSS », « Германия ». и « Защита данных CISPE ».
Но как сущности соотносятся друг с другом и как они определяются? И можно ли их классифицировать?
Одним из интуитивно понятных способов представления семантики было использование графиков, подобных приведенным ниже:
Помня об этих различных сценариях, мы нашли шаблоны и решили, что в первом выпуске будет простая онтология графовой базы данных (ниже):
Эта онтология не предназначена для покрытия всех будущих потребностей GAIA-X. У нас есть более сложные онтологии, которые мы рассмотрим в следующих статьях.
Мы также определили таксономию для классификации сервисов и включения атрибутов на узлах.
Следующим шагом было развертывание среды разработки и подготовки. Мы решили не создавать производственную именованную среду, чтобы избежать путаницы и подчеркнуть тот факт, что этот демонстратор является реализацией того, как каталог GAIA-X может работать, а не обязательно, как он будет реализован позже.
Мы использовали Gitlab с управляемой кластерной интеграцией Kubernetes и стандартными настройками конвейера CI / CD для развертывания микросервисов. Для хранения данных мы использовали графовую базу данных Neo4j.
Следующим шагом с онтологией и таксономией было заполнение базы данных.
Чтобы ускорить разработку, мы сосредоточились на сервисе Object Storage для релиза. Каждый из облачных провайдеров, работающих над демонстратором, заполнил базу данных описанием своего сервиса Object Storage.
Наконец, поскольку одним из критериев GAIA-X является удобство использования, мы создали интуитивно понятный способ запроса базы данных с помощью классического пользовательского интерфейса поисковой системы.
Для расширенных запросов мы решили не раскрывать язык запросов Neo4j Cypher, а создать еще более простую грамматику синтаксического анализа, основанную на отношениях между узлами и их атрибутами. Это позволило нам реализовать поле ввода произвольной формы с автозаполнением. Мы использовали движок Parsing Expression Grammar PEG.js, используя следующую грамматику:
logical_and ::= expression "AND" logical_and
expression ::= "NOT" expression / primary
primary ::= "(" logical_or ")
| rules
rules ::= node relation node
| node relation "ANY(" node+ ")"
| node relation "ALL(" node+ ")“
| node.property "=" value
| node.property "!=" value
| node.property "IN ANY(“ value+ “)"
Эта грамматика позволяет пользователю выражать более сложные запросы, такие как:
Service IMPLEMENTS ANY('S3', 'SWIFT') AND (Service COMPLIES_WITH 'GDPR' OR Provider LOCATED_IN 'European Economic Area')
Service.type = 'object storage' AND Service LOCATED_IN ALL('France', 'Germany')
Наконец, исходный код выпущен под лицензией BSD-3, и мы предоставляем спецификации OpenAPI, JSONSchema и JSON-LD для облегчения взаимодействия и повторного использования.
В заключение, мы гордимся тем, что часть этой работы уже отражена в документе по технической архитектуре GAIA-X, и что нам удалось успешно работать вместе над общим видением европейской экосистемы.
0 комментариев