Преминете към основното съдържание

Непрекъснато разгръщане

Продукционната среда се разгръща от работния процес deploy на entrosity-infra (.github/workflows/deploy.yml) след преминаването (cutover) от монолитното хранилище (monorepo) entrosity/RMM на 2026-09-26 (CUTOVER.md в entrosity-infra). Работните процеси deploy, agent-builds, release и platform-cutover на монорепото са изключени. Разгръщанията никога не се изпълняват паралелно и никога не се прекъсват.

Разгръщане се стартира, когато:

  • продуктово хранилище публикува нов образ от main и изпрати repository_dispatch deploy: entrosity-axis.backend и entrosity-hub.backend (задачата image в техния ci.yml публикува ghcr.io/entrosity/{axis,hub}-backend:main и :main-<sha12>, след като проверките на main минат), както и entrosity-axis.frontend, entrosity-hub.frontend и entrosity-docs (след като публикуват статичните си образи :main). entrosity-edge.*, entrosity-sphere.* и entrosity-matrix.* публикуват образите си :main по същия начин, но още не изпращат сигнала: техните образи излизат със следващото разгръщане;
  • push към main на entrosity-infra промени deploy/;
  • бъде стартирано ръчно (Actions → deploy → Run workflow). С stage-only зарежда образите и синхронизира deploy/ на хоста, без да рестартира нищо.

Всяко изпълнение разгръща текущия образ main на всеки компонент, така че редът, в който продуктовите хранилища завършват, няма значение.

На хоста не е нужен регистър на образи: образите се предават поточно през SSH. Продукционните образи са axis-backend, hub-backend, edge-backend, sphere-backend, matrix-backend и entrosity-web (преди преминаването rmm-backend, platform-backend и rmm-web); те се доставят заедно, със същата версия, а upgrade.sh изпълнява миграциите и рестартира Axis и Hub, както и Edge, Sphere и Matrix на хостовете, които ги включват (EDGE_ENABLED, SPHERE_ENABLED, MATRIX_ENABLED; Работа с Entrosity Sphere, Работа с Entrosity Matrix). Обобщението на изпълнението изброява digest на всеки разгърнат образ main.

Всяко изпълнение има нужда от всеки образ

Всяко изпълнение изтегля образа :main на всеки бекенд и изгражда уеб образа от образа :main на всеки фронтенд, независимо дали хостът включва продукта. Липсващ образ проваля цялото разгръщане: публикувайте промяна в entrosity-infra, която добавя продукт (както при Entrosity Sphere и Matrix), само след като образите на бекенда и фронтенда му са публикувани (Въвеждане).

Последната проверка чете PLATFORM_DOMAIN от .env на хоста и изчаква (до пет минути) пътя на API за агентите на устройствата, регистрирани към стария хост ($DEPLOY_URL/api/v1/healthz), API на Axis на хоста на Hub, API на Hub и, където .env на хоста ги включва, тези на Edge (/edge/api/v1/healthz), Sphere (/sphere/api/v1/healthz) и Matrix (/matrix/api/v1/healthz). Ако те не отговорят, работният процес отпечатва състоянието на услугите и последните редове от журналите на backend, platform и web и завършва с грешка.

Настройки на хранилището​

В entrosity-infra:

ТайнаСтойност
ENTROSITY_CI_TOKENЧете частните образи от GHCR (read:packages).
DEPLOY_HOSTАдресът на хоста.
DEPLOY_SSH_KEYЧастен ключ, чиято публична половина е в authorized_keys на root на хоста.
DEPLOY_KNOWN_HOSTSИзходът на ssh-keyscan <host>, който фиксира ключа на хоста.
ПроменливаСтойност
DEPLOY_ENABLEDТрябва да е true; всяка друга стойност пропуска всяко изпълнение освен ръчно stage-only (аварийно спиране).
DEPLOY_URL (по избор)Старият хост на Axis, проверяван накрая заедно с хоста на Hub (по подразбиране https://manage.entrosity.com).

Хостът​

  • Docker с приставката compose и попълнен /opt/entrosity/deploy/.env (Инсталиране). Работният процес никога не променя .env или backups/. Проектът на compose все още се казва rmm, а unit файлът на systemd rmm.service стартира стека от /opt/entrosity.
  • PostgreSQL 18 пази данните си в тома rmm_postgres18-data (монтиран в /var/lib/postgresql). При преминаването продукцията беше прехвърлена от PostgreSQL 16 с pg_dumpall и възстановяване с psql; старият том rmm_postgres-data и стекът на монорепото в /opt/rmm/deploy се пазят за връщане назад, докато не бъдат премахнати.
  • На хост с 2 GB задайте PG_SHARED_BUFFERS, PG_EFFECTIVE_CACHE_SIZE и паметта на бекенда в .env и добавете 2 GB swap.

Връщане към предишна версия​

Изпълнете deploy/scripts/deploy.sh <older version> на хоста (образите на предишните две версии все още са там) или стартирайте отново по-старо изпълнение на работния процес.

Компилации на агента и конектора​

MSI файловете на агента и конектора се изграждат от entrosity-axis-agent и entrosity-axis-connector (dev-release.yml при всеки push към main, release.yml при етикети), които ги прикачват към издания в GitHub и ги публикуват в продукция като издания за самообновяване (RELEASE_PUBLISH_ENABLED=true с тайните RELEASE_PUBLIC_KEY и RMM_RELEASE_TOKEN и в двете хранилища; компилациите не са подписани). Dev компилациите са с версия 0.1.<run>-dev.<sha>. Вижте Издания на агента и CI работни процеси.