Skip to content

SFS-019 Stand-Independent Images

Описываемое здесь касается в фронт-приложений SafeBlock на 17.12.2025

Тут и далее сбова сборка (как результат), образ, пакет имееют одно и тоже значение.

Слово сборка употребляется в двух значениях: как процесс сборки и как результат сборки (образ, пакет).

Мотивация

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

Это приводит к следующим:

  • Блокирует возможность перейти на деплой через тегированные сборки
  • Отсутствует возможность автоматизированного отката на ПРЕДЫДУЩУЮ версию конкретного приложения, всего стенда, всей инфраструктуры.
  • Отсутствует возможность передеплоить текущую версию приложения в новой конфигурации/настройками.
  • Отсутствует возможность передеплоить тот-же код с иной конфигурацией так как в репозитории хранится и изменения пайплайнов и сам код.
  • Процесс сборки и деплоя представляют собой один процесс, что лишает возможности делать их отдельно. Для того чтобы выкатить приложение нужной версии его нужно собирать, что требует наличие стенда для сборки, а также не гарантирует тот-же результат.
  • Нарушает 12factor в разделах https://12factor.net/config и https://12factor.net/build-release-run (что приводит в том числе к описываеым тут проблемам)

Как происходит сборка и развертывание сейчас

Screenshot 2024-12-17 at 08 43 48

Что предлагается сделать

  1. Разделить процесс сборки и деплоя.
  2. Собирать приложения в унифицированные версионированные пакеты (тегированные сборки). Другими словами пакеты у которых стоит номер версии и который можно выкатить на любой стенд БЕЗ изменений.
  3. При деплое выкатывать пакет из реестра пакетов.
  4. При деплое на production выкалывать ту версию пакета которая прошла тестирования на предварительных стендах.

Целевой процесс сборки

Screenshot 2024-12-17 at 09 05 26

Целевой процесс деплоя

Screenshot 2024-12-17 at 09 05 41

Что такое "Тегированные сборки"

Тегированная сборка это собранный пакет/образ приложения который хранится в реестре (registry) имеет версию пакета, которая указана в названии пакета или прикреплена к нему тегом, а также версию приложения которая возвращается приложением по запросу или отображается в UI.

Тегированная сборка в данной редакции это унифицированный версионированный пакет приложения который можно выкатить на любой стенд.

  1. Тегированные сборки дают возможность повысить процесс тестировани. Позволяют уверенным что на production находится именно та версия приложения которая прошла тестирование.
  2. Иметь возможность передеплоить приложение с новой конфигурацией БЕЗ пересборки (и соответсвенно перетестирования)
  3. Позволяют однодначно идентифицировать версию приложения находящуюся на стендах. Сейчас это 5 стендов и 4 приложения = 20 версий.
  4. Позволяет централизованно управлять всеми стендами. Что, в свою очередь, позволяет контроллировать состояние инфраструктуры в целом, иметь бэкап черезе который можно привести всю инфру в целевое состояние 2-3 командами.

Список стендо-зависимых переменных

VITE_APP_ENV: production

VITE_CF_ACCESS_CLIENT_ID:, VITE_CF_ACCESS_CLIENT_SECRET:

VITE_WC_PROJECT_ID:, APP_CONFIG_WC_PROJECT_ID:

VITE_BOT_SHARE_LINK: 

VITE_BACKEND_URL:, APP_CONFIG_BACKEND_URL:, VITE_TOKEN_MONIT_BACKEND_URL, VITE_TOKEN_MONIT_WS_ENDPOINT:

APP_CONFIG_ENCODED_NODES_LIST:, VITE_NODE_URL_ETH:, VITE_NODE_URL_BSC:, VITE_NODE_URL_OPTIMISM: , VITE_NODE_URL_AVAX: , VITE_NODE_URL_ARBITRUM: , VITE_NODE_URL_POLYGON: 

Варианты решений

  1. Встраивать в образ ВСЕ возможные значения переменных и выбирать нужное в зависимости от запущенного стенда, который определяется по домену.
  2. Подтягивать необоходимые значения через fetch() по указанному url-у из запускаемого JS-приложения.
  3. Устанавливать необходимые значения через JS-файл с параллельной подключаемый в index.html. <script type="module" src="/config.js"></script>. Другими словами конфиги устанавливаются через es6 модуль.
  4. Иметь сборку со значениями-заглушками которые подменяются не стендо-зависимые:
  5. (а) в процесс деплоя
  6. (б) через ngx_http_sub_module и подообные решения.
  7. Встраивать значения через meta-заголовки в index.html.
  8. (а) В момент деплоя через подстановки.
  9. (б) Отдельным процессом подкладывать на стенды его за ранее.
  10. Использовать привязку к домену для определния url-ов. Применимо только для api, ws, nodes
  11. Другие?

Взвешивание вариантов

Screenshot 2024-12-17 at 13 16 46

Ссылки