BG
RAILSHOT.
Обратно в залата

Railshot

AI deployment & operations platform

Внедряване на локално създадено уеб приложение в подготвени облачни и локални среди и последваща експлоатация.

AI платформа за внедряване и експлоатация, която отвежда локално създадено уеб приложение в подготвени облачни или локални (on-premises) среди и го поддържа в работа.

28 септември 2026 г. – 4 октомври 2026 г. · Завършен

Екипен проект · моята част: планиране и реализация на CI, CSP клъстери и интерфейс с Ansible, експлоатация, преглед на кода и интеграция в екипа

SoftBank Hackathon 2026 powered by KOREC & ProgateУчастник в предварителния кръг · обявяването на финалистите се очаква на 26 октомври 2026 г. (към 7 октомври 2026 г.)

  • УебРеализирано · хакатон
  • MCP сървърРеализирано · отдалечен · локален

Уеб интерфейсът и собственият агент на потребителя искат внедряване чрез един и същ продуктов API.

Продуктът от приета заявка за внедряване, през проверките в CI и публикуването на образа, до конфигурацията в Git и разгръщането с Argo CD в регистрирана цел и публичната HTTPS проверка. Успех се записва само при приложена ревизия и публична проверка; резултат, който не може да бъде узнат, остава unknown.

Проект, подаден от уеб интерфейса или от собствен AI агент, свързан чрез MCP, преминава през подготовката на файловете за внедряване, поправката на грешки, публикуването на образа, разгръщането в средата и проверката на публичния URL адрес; след внедряването същият екран показва историята и логовете и управлява обновяванията, спирането, възобновяването и изтриването. Екипен проект.

Период за разработка в състезанието: 28 септември 2026 г. – 4 октомври 2026 г.

Уеб интерфейсът и MCP сървърът, създадени по време на хакатона. Отдалеченият MCP влиза с OAuth, за да подава; локалните папки се подават чрез локалния MCP.

Архитектура на продукта · по пътищата в кода при публичния къмит 645e28a
Архитектура на продукта RailshotКомпоненти и връзки на продукта Railshot. Уеб интерфейсът, отдалеченият OAuth MCP и локален MCP на компютъра на потребителя искат внедряване чрез един и същ продуктов API, който регистрира изходен къмит и изпълнение на CI. CI решава по фиксирани проверки и публикува проверените образи в GHCR. CD адаптерът прилага чрез config Git и Argo CD само когато регистрираната цел съвпада със записа за публикуване, след което проверява регистрирания публичен HTTPS адрес и записва резултата. Метриките са наблюдение, отделно от вердикта.Потребител в браузърпапка · ZIP · GitHub URLMCP клиентChatGPT · Codex · Clauderailshot-local MCPкомпютърът на потребителя · stdioGHCRобрази по digestAI SDK providerCodex · Claude SDKХранилище config Gitрегистриран workload.jsonПубличен HTTPS URLрегистриран health пътPrometheusоперативна контролна VM · четенеapps/dashboardуеб интерфейс · история · Insightsagent/remote-mcp.jsOAuth MCP · deploy_repositoryapps/apiвалидиране · цел · приемане 202опашка за внедряване · по 3 едновременнообвързване с изпълнение на CI · наблюдениеcd.js · deployPublishedmetrics observerapi/product-store.jsсъстояние на операцията · обвързване с изпълнениеgitops/bridge.pyдоверена конфигурация · регистрирана целcommit · push · отдалечено прочитанесинхронизиране с Argo · наблюдениепублична HTTPS пробаArgo CDApplication · проверка на AppProjectapps/<tenant>/<app>изходен къмит · trailersrailshot-deploy.ymlцикъл · базови проверки L0–L3поправка чрез SDK · само поправими грешкисъщите проверки → тестван пакетверсия · публикуване в GHCR · обвързванеK3s клъстер за приложенияworkload · ServiceПлатформа Railshotоперативен клъстер · AWSGitHubнепублично хранилище apps · ActionsРегистрирана целпубличен път за всеки доставчик1 папка · ZIP · GitHub URL · Потребител в браузър → уеб интерфейс · история · Insights12същият продуктов API · /api/v13 OAuth · deploy_repository · MCP клиент → OAuth MCP · deploy_repository34същият продуктов API5 качване на ZIP · deploy_local_project · railshot-local MCP → валидиране · цел · приемане 20256 записано queued · 202 · валидиране · цел · приемане 202 → състояние на операцията · обвързване с изпълнение67 ред в опашката · състояние на операцията · обвързване с изпълнение → опашка за внедряване · по 3 едновременно78състояние на внедряването · история1source commit2workflow_dispatch3подаден къмит4заявка за поправка · условна5публикуване на проверените образи6изпълнение · четене на публикуването7 failed · publication_unverified · обвързване с изпълнение на CI · наблюдение → състояние на операцията · обвързване с изпълнение71images.json · spec · verdict · manifest2прилагане · регистрирана цел3workload commit · push4revision5 синхронизиране · наблюдение · синхронизиране с Argo · наблюдение → Application · проверка на AppProject56прилагане7изтегляне на образа · digest8HTTPS health9 публичен път · Публичен HTTPS URL → workload · Service910 succeeded · revision · URL · cd.js · deployPublished → състояние на операцията · обвързване с изпълнение1011 unknown · нужно е съгласуване · cd.js · deployPublished → състояние на операцията · обвързване с изпълнение111PromQL заявка2scrape · probe3състояние на внедряването · история4HTTPS health

Подаване → приемане

Уеб интерфейсът, отдалеченият MCP и локалният MCP извикват един и същ продуктов API, който записва проверената заявка като queued и отговаря с 202.

  1. Потребител в браузърпапка · ZIP · GitHub URLуеб интерфейс · история · Insightsapps/dashboard

    Източникът и регистрирана среда се избират в уеб интерфейса.

  2. уеб интерфейс · история · Insightsapps/dashboardсъщият продуктов API · /api/v1валидиране · цел · приемане 202apps/api

    Уеб интерфейсът извиква продуктовия API от същия произход.

  3. MCP клиентOAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js

    Отдалеченият MCP се свързва чрез OAuth и приема като вход публично хранилище в GitHub.

  4. OAuth MCP · deploy_repositoryagent/remote-mcp.jsсъщият продуктов APIвалидиране · цел · приемане 202apps/api

    Отдалеченият MCP сървър извиква същия API за внедряване чрез вътрешния си API клиент.

  5. railshot-local MCPкачване на ZIP · deploy_local_projectвалидиране · цел · приемане 202apps/api

    Stdio MCP на компютъра на потребителя архивира папка в ZIP и я качва. Сесията му не се споделя с отдалечената OAuth сесия.

  6. валидиране · цел · приемане 202apps/apiзаписано queued · 202състояние на операцията · обвързване с изпълнениеapi/product-store.js

    Проверяват се входът, регистрираната цел, капацитетът и ключът за идемпотентност; операцията се записва като queued и се отговаря с 202. 202 означава прието, а не внедрено.

  7. състояние на операцията · обвързване с изпълнениеapi/product-store.jsред в опашкатаопашка за внедряване · по 3 едновременноapps/api

    Взема се по реда на приемане, в рамките на лимита за едновременни внедрявания (по подразбиране 3).

  8. състояние на операцията · обвързване с изпълнениеapi/product-store.jsсъстояние на внедряването · историяуеб интерфейс · история · Insightsapps/dashboard

    Уеб интерфейсът и MCP инструментите четат едни и същи записи за операциите. Последният опит и текущото проверено внедряване се показват отделно, а завършена AI задача не е успешно внедряване.

Проверки в CI → публикуване на образа

Фиксираният код на платформата проверява подадения къмит, предава на AI само поправимите грешки и публикува само образите, преминали отново същите проверки.

  1. опашка за внедряване · по 3 едновременноapps/apisource commitизходен къмит · trailersapps/<tenant>/<app>

    Подаденият изходен код става къмит в непубличното хранилище apps (с trailers Railshot-Request и Railshot-Target), а клонът се обновява без force.

  2. опашка за внедряване · по 3 едновременноapps/apiworkflow_dispatchцикъл · базови проверки L0–L3railshot-deploy.yml

    Иска изпълнение с tenant, app, source_commit и target_id. Ако отговорът се загуби, заявката не се изпраща отново; вместо това се търсят изпълненията за същия къмит.

  3. изходен къмит · trailersapps/<tenant>/<app>подаден къмитцикъл · базови проверки L0–L3railshot-deploy.yml

    Прави се checkout само на подадения къмит и на фиксирания код на платформата (PLATFORM_REF).

  4. поправка чрез SDK · само поправими грешкиrailshot-deploy.ymlзаявка за поправка · условнаAI SDK provider

    Извиква се само за поправими класове грешки и спира, когато същата грешка се повтори или се достигне лимитът на опитите. Успехът или неуспехът се решават от проверките, а не от LLM.

  5. версия · публикуване в GHCR · обвързванеrailshot-deploy.ymlпубликуване на проверените образиGHCR

    След проверка на пакета, преминал проверките, същите образи се публикуват в GHCR. Нищо не се изгражда отново.

  6. обвързване с изпълнение на CI · наблюдениеapps/apiизпълнение · четене на публикуванетоrailshot-deploy.yml

    Публикуването се зачита само когато run id, source commit, целта и приложението съвпадат с приетия запис.

  7. обвързване с изпълнение на CI · наблюдениеapps/apifailed · publication_unverifiedсъстояние на операцията · обвързване с изпълнениеapi/product-store.js

    Грешка в CI или непотвърдено публикуване се записват с диагностика и не се предават на CD.

Прилагане → публична проверка

Прилага чрез config Git и Argo CD само когато публикуването съвпада с регистрираната цел, и записва успех само след като регистрираният публичен HTTPS адрес бъде потвърден.

  1. версия · публикуване в GHCR · обвързванеrailshot-deploy.ymlimages.json · spec · verdict · manifestcd.js · deployPublishedapps/api

    CD чете файловете от записа за публикуване чрез доверен зареждач. Самият CI не създава ресурс в клъстера, URL адрес или успешно внедряване.

  2. cd.js · deployPublishedapps/apiприлагане · регистрирана целдоверена конфигурация · регистрирана целgitops/bridge.py

    Изпълнява gitops/bridge.py с доверената конфигурация само когато регистрираните приложение и tenant съвпадат със записа за публикуване.

  3. commit · push · отдалечено прочитанеgitops/bridge.pyworkload commit · pushХранилище config Git

    Прави къмит само на workload.json в регистрирания път на отделен клон, първо записва намерението за push, след това прави push и прочита обратно отдалечената ревизия. Несигурен push не се повтаря.

  4. Хранилище config GitrevisionApplication · проверка на AppProjectArgo CD

    Ревизията на хранилището с конфигурация, към която сочи Application в Argo CD.

  5. синхронизиране с Argo · наблюдениеgitops/bridge.pyсинхронизиране · наблюдениеApplication · проверка на AppProjectArgo CD

    Иска синхронизиране след проверка на AppProject; при наблюдение само чете, без синхронизиране.

  6. Application · проверка на AppProjectArgo CDприлаганеworkload · ServiceK3s клъстер за приложения

    Прилага работното натоварване към регистрирания целеви клъстер.

  7. workload · ServiceK3s клъстер за приложенияизтегляне на образа · digestGHCR

    Изтегля публикувания digest. Непубличен GHCR изисква отделни идентификационни данни за изтегляне.

  8. публична HTTPS пробаgitops/bridge.pyHTTPS healthПубличен HTTPS URL

    Проверява само регистрирания от оператора HTTPS health адрес, без пренасочвания, за отговор 200 (и очаквания JSON, ако е зададен).

  9. Публичен HTTPS URLпубличен пътworkload · ServiceK3s клъстер за приложения

    Публичният път (LB, NodePort, сертификат) се различава според доставчика и регистрираната цел.

  10. cd.js · deployPublishedapps/apisucceeded · revision · URLсъстояние на операцията · обвързване с изпълнениеapi/product-store.js

    Записва се като succeeded само при cd.deployed, ревизия, успешна публична HTTPS проверка, времето ѝ и валиден URL.

  11. cd.js · deployPublishedapps/apiunknown · нужно е съгласуванесъстояние на операцията · обвързване с изпълнениеapi/product-store.js

    Резултат, който не може да бъде узнат, остава unknown; същото прилагане нито се изпраща отново, нито се връща назад.

Наблюдение · не вердикт

Метриките и пробите не решават дали внедряването е успешно. Липсващите, остарелите и неуспешните стойности се показват такива, каквито са.

  1. metrics observerapps/apiPromQL заявкаPrometheus

    Чете сериите up, probe_success и Pod. Липсващи, остарели или неуспешни стойности се показват в това състояние и никога не се превръщат в 0.

  2. Prometheusscrape · probeworkload · ServiceK3s клъстер за приложения

    Scrape от exporter и HTTP проба. Тези метрики не се използват за решение за успешно внедряване.

  3. състояние на операцията · обвързване с изпълнениеapi/product-store.jsсъстояние на внедряването · историяуеб интерфейс · история · Insightsapps/dashboard

    Уеб интерфейсът и MCP инструментите четат едни и същи записи за операциите. Последният опит и текущото проверено внедряване се показват отделно, а завършена AI задача не е успешно внедряване.

  4. публична HTTPS пробаgitops/bridge.pyHTTPS healthПубличен HTTPS URL

    Проверява само регистрирания от оператора HTTPS health адрес, без пренасочвания, за отговор 200 (и очаквания JSON, ако е зададен).

Всички връзки с еднаква дебелина. Изберете поток, за да се откроят само неговият път и номерираните стъпки.

  • Плътна · посоката, в която текат изходният код, образите и заявките
  • Прекъсната · заявка за изпълнение, прилагане или синхронизиране
  • Дълга щрих-пунктирна · четене на състояние, проби и метрики, отделно от вердикта
  • Къса прекъсната · записана грешка или неизвестен изход
  • Дебела черна линия · избраният поток; числата показват реда
  • Кутия · граница със собственик, с пътя до изходния код в заглавието
  • Вътрешен етикет · компонент в тази граница
  • Прекъсната кутия · извън платформата
  • Оранжев контур · където решава модел
  • Продуктов API
  • Записи за внедряванията
  • Граница на изпълнението на CD
  • Вход · CI · цел

Картината от 2 октомври (bc61a5a) в docs/architecture/README.md е история на реализацията; тази архитектура следва кода при 645e28a. Доставчиците и мрежовите пътища се различават според регистрираната цел, а това не означава, че всеки доставчик е винаги включен.