Обзор | On-Premise | 2GIS Documentation
On-Premise

Обзор решения On-Premise

Решение On-Premise от 2GIS - это набор сервисов, который позволяет развернуть продукты 2GIS на ваших площадках.

В сравнении с использованием облачной инфраструктуры 2GIS, это решение даёт следующие преимущества:

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

Сервисы On-Premise созданы для работы в кластере Kubernetes и поставляются в виде Docker-образов. Такой дизайн даёт следующие преимущества:

  • Более быстрый и менее затратный процесс обновления благодаря контейнеризации. Нет необходимости настраивать все зависимости при каждой итерации развёртывания или обновления.
  • Простое горизонтальное масштабирование сервисов, позволяющее:
    • Быть уверенными в доступности сервисов. Любой сервис может продолжать обработку запросов, даже если часть его инстансов стала недоступна в результате сбоя. Это достигается комбинацией репликации сервисов и балансировки нагрузки с помощью Ingress.
    • Увеличить производительность сервисов. Благодаря использованию кеширования в различных архитектурных слоях приложений, достигается значительное снижение времени обработки запросов.

Один или несколько сервисов реализуют функциональность определенных продуктов 2GIS (см. таблицу ниже).

Продукт 2GIS Сервис On-Premise
Карты
MapGL JS API MapGL JS API
Tiles API
Поиск
Places API
Geocoder API
Suggest API
Categories API
Regions API
Catalog API
Search API
Навигация
Directions API
Distance Matrix API
Truck Direction API
Pairs Direction API
Map Matching API
Isochrone API
Public Transport API
TSP API
Navi-Castle
Navi-Front
Navi-Router
Navi-Back
GIS-платформа
GIS-платформа GIS-платформа

Сервисы On-Premise не являются самодостаточными и делят между собой общую инфраструктуру, позволяющую сервисам работать. Подавляющая часть сервисов и инфраструктуры может быть развёрнута в изолированной локальной сети с ограниченным или отсутствующим доступом к интернету (зависит от сервиса, см. раздел Что нужно учесть перед развёртыванием для получения дополнительной информации).

Архитектура и инфраструктура

Общая инфраструктура включает в себя:

  • Хранилища данных для сервисов. Используются следующие сервисы хранения данных:

    • Apache Cassandra
    • Apache Kafka
    • PostgreSQL
    • Redis
    • Kubernetes Persistent Volumes, которые можно запросить через динамический Persistent Volume Claim.

    Разные сервисы On-Premise используют различные комбинации сервисов хранения данных. См. раздел Требования для развёртывания для получения дополнительной информации.

  • Инфраструктура доставки артефактов и обновлений:

    • Приложение 2GIS CLI для получения актуальных артефактов развёртывания (Docker-образы и наборы данных).
    • Хранилище артефактов развёртывания для хранения наборов данных. Подойдет любое S3-совместимое хранилище. Поддержка других типов хранилища находится в стадии разработки.
    • Реестр Docker (registry) для хранения Docker-образов.
    • Задание импорта Kubernetes (Kubernetes Importer job) для загрузки полученных данных в отдельные хранилища данных.
    • Приложение Helm для развёртывания и обновления сервисов.

    См. раздел Процессы обновления и управления данными для получения дополнительной информации.

  • Сервис ключей для управления доступом к API развёрнутых сервисов On-Premise.

    Для работы этого сервиса необходимы хранилища данных Apache Kafka, PostgreSQL и Redis, а также уже развёрнутые серверы LDAP для аутентификации пользователей.

  • Сервер LDAP. Этот сервер необходим для аутентификации пользователей интерфейса администратора сервиса ключей. См. документацию сервиса ключей для получения дополнительной информации.

  • Ingress-контроллер Kubernetes для балансировки входящих запросов к инстансам сервиса On-Premise. Практически любой сервис размещается за балансировщиком нагрузки, чтобы удовлетворять требованиям по отказоустойчивости и масштабированию.

Следующие сервисы в некоторых сценариях использования могут требовать доступ к данным о пробках в реальном времени:

  • Карты: сервис MapGL JS API использует эти данные, чтобы отобразить пробки в виде цветных линий на карте.
  • Навигация: сервис Navi-Back использует эти данные, чтобы строить маршруты с учётом текущих пробок.
  • GIS-платформа: эти данные используются, чтобы отобразить пробки в виде цветных линий на отдельном слое карты.

Архитектура сервисов On-Premise предполагает, что сервисы могут работать без доступа к интернету. Однако, чтобы получить данные о пробках в реальном времени, необходим доступ к публичным серверам 2GIS в интернете.

Чтобы обойти это ограничение, вышеупомянутые сервисы используют выделенный прокси для пробок. Таким образом, ограниченный доступ в интернет можно будет предоставить только сервису прокси, в то время как остальные сервисы, нужные для работы решения On-Premise, по-прежнему будут работать без доступа в интернет.

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

Использование API-ключей

Сервис ключей используется для:

  • Выпуска и отзыва обычных API-ключей, которые используются конечными пользователями. Эти ключи предоставляют доступ к некоторому подмножеству сервисов On-Premise.
  • Сбора метрик и статистики от развёрнутых сервисов On-Premise, чтобы управлять доступом, основываясь на метриках использования конкретных API-ключей. Для этого в сервисах должны быть настроены особые сервисные API-ключи.

См. документацию сервиса ключей для получения дополнительной информации о том, как получить сервисные API-ключи.

Процессы обновления и управления данными

Чтобы поддерживать сервисы On-Premise и наборы данных в актуальном состоянии, используется следующий механизм:

  1. 2GIS CLI загружает артефакты развёртывания с публичных серверов обновлений 2GIS.

  2. 2GIS CLI помещает загруженные Docker-образы в реестр Docker, а загруженные наборы данных в хранилище артефактов развёртывания.

  3. Затем все артефакты мигрируют из публичного контура в приватный контур (локальную сеть), где становятся доступны для Helm и сервисов On-Premise. Организовать процесс миграции можно разными способами, в зависимости от специфики конкретного проекта. См. раздел Что нужно учесть перед развёртыванием для получения дополнительной информации.

  4. Хранилище артефактов развёртывания используют многие сервисы On-Premise как во время первоначального развёртывания сервиса, так и при обновлении уже существующего развёртывания.

    У многих сервисов, полагающихся на это хранилище, есть отдельное задание импорта Kubernetes (Kubernetes Importer job), предназначенное для управления жизненным циклом данных для сервиса:

    1. Задание читает файл с манифестом в хранилище артефактов развёртывания и с его помощью определяет, есть ли новые наборы данных.

      Этот файл выступает в качестве простой базы данных объектов, находящихся в хранилище, и их версий.

    2. Когда задание находит обновлённые данные в хранилище, оно запускает несколько рабочих процессов (workers).

    3. Отдельный рабочий процесс получает из хранилища требуемые артефакты развёртывания и затем импортирует новые данные в хранилище данных сервиса (в виде отдельной копии).

    4. После того, как все рабочие процессы завершили импорт данных, задание выполняет серию проверок (healthchecks), чтобы убедиться в целостности новых данных:

      1. Если все проверки завершаются успешно, задание удаляет текущие данные, в результате чего новые данные замещают текущие.
      2. Если одна или несколько проверок завершаются с ошибкой, задание останавливает процесс обновления и требует вмешательства системного администратора. Текущие данные, если они есть, остаются нетронутыми.
  5. Ниже перечислены основные сценарии обновления.

    Важное примечание:

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

    Возможно:

    1. Обновить сервис с помощью Helm.

      Helm обновляет сервис подобно тому, как задание импорта Kubernetes обновляет данные: рядом с существующими инстансами сервисов будут развёрнуты новые инстансы. При успешном завершении проверок трафик перенаправляется на новые инстансы. В противном случае Helm останавливает процесс обновления и требует вмешательства системного администратора.

    2. Обновить сервис и его данные с помощью Helm (не все сервисы поддерживают этот вариант обновления).

      Сначала Helm запускает задание импорта Kubernetes для обновления данных сервиса, затем выполняет обновление сервиса.

    3. Обновить только данные сервиса (не все сервисы поддерживают этот вариант обновления). Настраивается выполнение по расписанию соответствующего задания импорта Kubernetes: например, на ежедневной основе.

Учитывайте следующее при подготовке к развёртыванию:

  1. Только часть сервисов и инфраструктуры доставки артефактов и обновлений требует развёртывания в публичном контуре с доступом в интернет. Необходимо разработать процедуру миграции данных, чтобы сервисы и инфраструктура, находящиеся в приватном контуре, могли получить доступ к артефактам развёртывания, находящимся в публичном контуре.

    Например, чтобы обеспечить доставку артефактов развёртывания из публичного контура в приватный контур, вы можете развернуть реестр Docker и S3-совместимое хранилище в приватном контуре и затем настроить синхронизацию между ними и соответствующими сущностями, находящимися в публичном контуре.

    Пример организации процесса миграции данных
  2. Helm-чарты, которые используются для развёртывания сервисов On-Premise, разворачивают только сами сервисы. Вся необходимая общая инфраструктура должна быть подготовлена заранее. Только после этого укажите всю необходимую информацию в конфигурационных YAML-файлах и запустите Helm.

  3. Большинство сервисов следует поместить за балансировщик нагрузки. При развёртывании из Helm-чартов создаётся ресурс Ingress для сервисов, которые этого требуют. Вы можете использовать Ingress-контроллер на ваш выбор для реализации балансировщика нагрузки Ingress в вашем кластере Kubernetes (см. раздел Системные требования сервисов для получения дополнительной информации).

  4. Хранилище артефактов развёртывания, которое используется 2GIS CLI, требует регулярного технического обслуживания, в ходе которого удаляются устаревшие артефакты развёртывания. Это помогает предотвратить исчерпание свободного места в хранилище.

    Примечание:

    2GIS CLI не отслеживает и не управляет свободным местом в хранилище артефактов развёртывания и в реестре Docker. Рекомендуется настроить мониторинг для этой части инфраструктуры и выполнять регулярное техническое обслуживание.

  5. Все сервисы On-Premise, за исключением прокси для пробок, не требуют доступа в интернет для своей работы и поэтому могут быть развёрнуты в изолированных сетях приватного контура.

    Если вы планируете использовать прокси, настройте инфраструктуру в приватной сети так, чтобы он имел доступ в интернет.

  6. Не путайте API-ключ для 2GIS CLI с обычными API-ключами, которыми можно управлять с помощью сервиса ключей, или сервисными API-ключами. Сервис ключей позволяет назначать обычные API-ключи конечным пользователям сервисов On-Premise и реализовывать контроль доступа. Также этот сервис использует сервисные API-ключи для взаимодействия с сервисами On-Premise, которые требуют для работы API-ключи от конечных пользователей. 2GIS CLI использует отдельный API-ключ, который позволяет получать артефакты развёртывания, связанные с приобретёнными продуктами 2GIS.

  7. 2GIS поставляет решение On-Premise различных версий. Каждая версия решения представлена в виде набора сервисов, привязанных к этой версии.

    Версию решения On-Premise можно указать при:

    • установке сервиса;
    • обновлении сервиса;
    • получении артефактов развёртывания с помощью утилиты 2GIS CLI.

    Если при выполнении этих операций не указывать номер версии, то будет использована самая новая из доступных версий.

    Список доступных версий приведен в документе Релизы.

Перед развёртыванием любого сервиса On-Premise должна быть подготовлена следующая инфраструктура:

  1. Кластер Kubernetes.
  2. Ingress-контроллер на ваш выбор. Например, NGINX Ingress Controller.
  3. Выделенный сервер для размещения в публичном контуре инфраструктуры доставки артефактов и обновлений.
  4. Хранилище артефактов развёртывания, с инстансами как в публичном, так и в приватном контурах.
  5. Реестр Docker, с инстансами как в публичном, так и в приватном контурах.
  6. Сервер LDAP.
  7. Все сервисы хранения данных.

См. разделы Архитектура решения On-Premise и Что нужно учесть перед развёртыванием для получения дополнительной информации.

Эти требования должны быть выполнены как для testing-, так и для production-окружения:

Программное обеспечение:

  1. Операционная система: Ubuntu 20.04 LTS
  2. Kubernetes: 1.19+
  3. Docker: 19.03.4+
  4. Реестр Docker: 2.7.1

Сервисы хранения данных:

  1. Apache Cassandra: 3.11+
  2. Apache Kafka: 2.7.0+ с Apache ZooKeeper 3.4.13+
  3. PostgreSQL: 11+ с расширениями PostGIS 2.5+, PLV8 3.0.0+, JsQuery
  4. Redis: 6.2+ (стабильный релиз)
  5. S3-совместимое хранилище: например, Ceph S3 v.14.2.22+

Примечание:

Требования к версиям программного обеспечения могут варьироваться в зависимости от сервиса On-Premise. Для получения дополнительной информации обратитесь к документации конкретного сервиса.

Для testing-окружения

Примечание:

Системные требования ниже являются ориентировочными и приведены в ознакомительных целях. Свяжитесь с 2GIS при планировании развёртывания, чтобы получить расчёты, подходящие для ваших окружений и потребностей.

Сервисы CPU, ядер RAM, Гб Мин. число реплик Операционная система Нужен балансировщик нагрузки? Нужен доступ в интернет? Тип хранилища Размер хранилища, Гб
Инфраструктура доставки артефактов и обновлений
2GIS CLI Docker Нет Да S3, Реестр Docker См. ниже
S3-совместимое хранилище Нет Нет Своё хранилище 800 Гб
Реестр Docker Нет Нет Своё хранилище 100 Гб
Прокси для пробок
Обратный прокси NGINX 1 2 2 Docker Да Да
Сервис ключей
Frontend 1 1 2 Docker Да Нет
Backend 1 1 2 Docker Да Нет PostgreSQL, Apache Kafka См. ниже
PostgreSQL 2 4 3 (развёрнут заранее) Да Нет Своё хранилище 200 Гб
Apache Kafka (+ Zookeeper) 4 4 3 (развёрнуты заранее) Да Нет Своё хранилище 500 Гб*
Redis Требования будут указаны позже.
Карты
Tiles API Backend 1 0.5 2 Docker Да Нет Apache Cassandra См. ниже
Задание импорта Kubernetes 1 4 1 Docker Нет Нет
Apache Cassandra 1 16 3 (развёрнуто заранее) Да Нет Своё хранилище 500 Гб
MapGL JS API 1 2 2 Docker Да Нет
Обратный прокси для получения информации о пробках 1 2 2 Docker Да Да
Навигация
Navi-Front Требования будут указаны позже.
Navi-Router Требования будут указаны позже.
Navi-Back Требования будут указаны позже.
Navi-Castle Backend Требования будут указаны позже.
Kubernetes Persistent Volume** (развёрнуто заранее) Своё хранилище 5 Гб на каждую реплику Navi-Castle
GIS-платформа
Portal frontend 2 1 2 Docker Да Нет
ZooKeeper 2 2 2 Docker Да Нет
SPCore backend 8 4 2 Docker Да Нет PostgreSQL, S3-совместимое хранилище См. ниже
PostgreSQL 4 2 3 (развёрнут заранее) Да Нет Своё хранилище 100 Гб
S3-совместимое хранилище (развёрнуто заранее) Да Нет Своё хранилище 4 Тб***

* Обратите внимание, что эти требования к хранилищу могут меняться в зависимости от настроенного временного периода для хранения статистики. Чем больше этот период, тем больший объем хранилища потребуется.

** Это требование к хранилищу является необязательным. Однако, настоятельно рекомендуется настроить функциональность Persistent Volume и Persistent Volume Claim в вашем кластере Kubernetes.

*** Обратите внимание, что эти требования к хранилищу рассчитаны исходя из сценария использования, который предусматривает хранение большого объема тайлированных снимков в высоком разрешении (например, спутниковых снимков). Если вы не планируете хранить данные подобного рода, то требования к объему хранилища могут быть снижены.

Для production-окружения

Примечание:

Системные требования ниже являются ориентировочными и приведены в ознакомительных целях. Свяжитесь с 2GIS при планировании развёртывания, чтобы получить расчёты, подходящие для ваших окружений и потребностей.

Сервисы CPU, ядер RAM, Гб Мин. число реплик Операционная система Нужен балансировщик нагрузки? Нужен доступ в интернет? Тип хранилища Размер хранилища, Гб
Инфраструктура доставки артефактов и обновлений
2GIS CLI Docker Нет Да S3, Реестр Docker См. ниже
S3-совместимое хранилище Нет Нет Своё хранилище 800 Гб
Реестр Docker Нет Нет Своё хранилище 100 Гб
Прокси для пробок
Обратный прокси NGINX 2 2 2 Docker Да Да
Сервис ключей
Frontend 1 1 2 Docker Да Нет
Backend 1 1 2 Docker Да Нет PostgreSQL См. ниже
PostgreSQL 2 4 3 (развёрнут заранее) Да Нет Своё хранилище 200 Гб
Apache Kafka + Zookeeper 8 12 3 (развёрнуты заранее) Да Нет Своё хранилище 500 Гб*
Redis Требования будут указаны позже.
Карты
Tiles API Backend 4 0.5 2 Docker Да Нет Apache Cassandra См. ниже
Задание импорта Kubernetes 4 4 1 Docker Нет Нет
Apache Cassandra 4 16 3 (развёрнута заранее) Да Нет Своё хранилище 500 Гб
MapGL JS API 2 2 2 Docker Да Нет
Обратный прокси для получения информации о пробках 2 2 2 Docker Да Да
Навигация
Navi-Front Требования будут указаны позже.
Navi-Router Требования будут указаны позже.
Navi-Back Требования будут указаны позже.
Navi-Castle Backend Требования будут указаны позже.
Kubernetes Persistent Volume** (развёрнуто заранее) Своё хранилище 5 Гб на каждую реплику Navi-Castle
GIS-платформа
Portal frontend 2 1 2 Docker Да Нет
ZooKeeper 4 8 2 Docker Да Нет
SPCore backend 8 4 2 Docker Да Нет PostgreSQL, S3-совместимое хранилище См. ниже
PostgreSQL 16 32 2 (развёрнут заранее) Да Нет Своё хранилище 100 Гб
S3-совместимое хранилище (развёрнуто заранее) Да Нет Своё хранилище 4 Тб***

* Обратите внимание, что эти требования к хранилищу могут меняться в зависимости от настроенного временного периода для хранения статистики. Чем больше этот период, тем больший объем хранилища потребуется.

** Это требование к хранилищу является необязательным. Однако, настоятельно рекомендуется настроить функциональность Persistent Volume и Persistent Volume Claim в вашем кластере Kubernetes.

*** Обратите внимание, что эти требования к хранилищу рассчитаны исходя из сценария использования, который предусматривает хранение большого объема тайлированных снимков в высоком разрешении (например, спутниковых снимков). Если вы не планируете хранить данные подобного рода, то требования к объему хранилища могут быть снижены.

Перед развёртыванием любого сервиса On-Premise:

  • Проверьте, что ваша инфраструктура удовлетворяет требованиям, перечисленным в разделе Требования для развёртывания.
  • Проверьте работоспособность:
    • Кластера Kubernetes (с установленным Helm).
    • Сервисов хранения данных.
    • Docker CLI и 2GIS CLI.
    • Хранилища артефактов развёртывания и реестра Docker.
  • Проверьте, что необходимая инфраструктура в публичном контуре доступна из приватного контура и наоборот.
  • Проверьте, что у вас есть API-ключ для 2GIS CLI.

Эти шаги являются общими для развёртывания любого сервиса On-Premise:

  1. Пройдите чек-лист.

  2. Получите актуальные артефакты развёртывания с серверов 2GIS:

    1. Создайте конфигурационный YAML-файл и укажите в нём API-ключ и параметры доступа к хранилищам:

      config.yaml

      key: <Access key for downloading the artifacts>
      log-format: <Log format: text or json. Logs are written to stdout.>
      storage:
          type: s3
          host: <Deployment Artifacts Storage host name and port in "hostname:port" format>
          bucket: <Deployment Artifacts Storage bucket name>
          access-key: <Deployment Artifacts Storage access key>
          secret-key: <Deployment Artifacts Storage secret key>
      docker:
          registry:
              username: <Docker Registry username>
              password: <Docker Registry password>
              server-address: <Docker Registry URL (ex. "http://registry.host.address>:port")>
              image-prefix: <Additional prefix if needed (ex. "/2gis-on-premise")>
      
    2. Запустите Docker-контейнер с 2GIS CLI:

      docker run --rm -v $(pwd)/config.yaml:/config.yaml -v /var/run/docker.sock:/var/run/docker.sock 2gis/dgctl:latest pull --config=/config.yaml --apps-to-registry
      

      Дополнительно можно указать следующие аргументы:

      • --version: для загрузки указанной версии сервисов On-Premise вместо самой новой версии (например, --version=1.0.0).
      • --workers: для изменения числа параллельных потоков загрузки (по умолчанию 3, максимум 8).

      Запишите путь к файлу с манифестом, эта информация понадобится позже. Путь будет отображён в стандартном потоке вывода, когда 2GIS CLI завершит работу.

  3. Перенесите артефакты развёртывания из публичного контура в приватный. См. раздел Что нужно учесть перед развёртыванием для получения дополнительной информации.

  4. Добавьте репозиторий с Helm-чартами 2GIS:

    helm repo add 2gis-on-premise https://2gis.github.io/on-premise-helm-charts && \
    helm repo update
    

    Выполните следующую команду, чтобы проверить доступность репозитория:

    helm search repo 2gis-on-premise
    

    Если вывод команды содержит непустой список чартов, то добавление репозитория прошло успешно.

  5. Разверните сервис ключей. Проверьте его доступность с помощью браузера.

  6. Разверните требуемый сервис On-Premise, пользуясь информацией из этого раздела.

    См. документацию конкретного сервиса: