RAILSHOT.
Atpakaļ uz zāli

Railshot

AI deployment & operations platform

Lokāli izveidota tīmekļa lietotne — izvietošanai sagatavotās mākoņa un iekšējās infrastruktūras vidēs un darbībai tajās.

AI izvietošanas un darbības platforma, kas lokāli izveidotu tīmekļa lietotni aizved uz sagatavotām mākoņa vai iekšējās infrastruktūras vidēm un uztur to darbībā.

2026. gada 28. septembris – 4. oktobris · Pabeigts

Komandas projekts · mana daļa: CI plānošana un implementācija, CSP klasteri un Ansible saskarne, darbība, komandas koda pārskatīšana un integrācija

SoftBank Hackathon 2026 powered by KOREC & ProgatePriekšsacīkstu dalībnieks · fināla atlase tiks paziņota 2026. gada 26. oktobrī (uz 2026. gada 7. oktobri)

  • TīmeklisImplementēts · hakatons
  • MCP serverisImplementēts · attālais · lokālais

Darbības un klientu lietotņu klasteri ir nošķirti, un publiskais ceļš tiek turēts atsevišķi no izvietošanas vadības.

Darbības K3s informācijas panelis, produkta API un build controller ir izvietoti platform lomas mezglos, bet runner Job — build lomas mezglā, un izvietošanu veic Argo CD. Klientu lietotnes darbojas noteiktā nosaukumvietā atsevišķā viena mezgla K3s + Cilium klasterī katram reģistrētajam mērķim.

Klastera karte · zīmēta pēc publiskā komita 645e28a deklarācijām un koda
Railshot darbības un klientu klasteru karteDarbības K3s klasteris un reģistrēts klienta lietotnes klasteris. Darbības klasterī nosaukumvieta railshot-system izvieto informācijas paneli, produkta API, attālo MCP (tikai ja tā attēls ir dots) un build controller platform lomas mezglos; nosaukumvietas railshot-build runner Job pieņem GitHub Actions darbus build lomas mezglā ar taint. GitHub mitināts release job publicē testēto komplektu GHCR. Produkta API komitē darba slodzi config Git un sinhronizē Application nosaukumvietā argocd, un Argo CD piemēro Deployment, NodePort Service un NetworkPolicy klienta klasterī reģistrētajā nosaukumvietā. Lietotnes pieprasījumi ienāk no nodrošinātāja L7 ieejas punkta uz mezgla NodePort un Service, pēc tam lietotnes Pod. Izvietošanas verdikts balstās tikai uz Argo stāvokli un publiskā URL pārbaudi; Pod diagnostika, žurnāli un metrikas tiek lasīti kā atsevišķi signāli. Operatora instalēšanas un reģistrācijas ievades tiek turētas atsevišķi no klienta lietotnes derīgās slodzes.Railshot lietotājsinformācijas panelis · MCPOperatora bootstrapinstalēšana · reģistrācija · SecretGHCRattēli pēc jaucējvērtībasconfig Git repozitorijsworkload.json · revisionNodrošinātāja L7 ieejas punktsALB · GCP LB · AmphoraLietotnes lietotājspublisks HTTPSNovērotāja VMārpus klienta K3s · Composerailshot-systemdashboard · nginxattālais MCP · tikai ar attēlubuild controller · CronJobprodukta API · cd.js → bridge.pyargocdArgo CD · ApplicationAppProject · cluster Secretatjaunošanas CronJob · ik pēc 2 hrailshot-buildrunner Job · hostNetwork · Docker socketrailshot-deploy.ymlloop job · self-hosted runnerrelease job · GitHub-hosted<app namespace>Deployment · Pod · attēls pēc jaucējvērtībasNodePort Service · LocalNetworkPolicy · uzskaitītie CIDRrailshot-argocd SA · žetonskube-systemCilium · Helm · VXLANrailshot-observabilitynode-exporterkube-state-metricsDarbības klasteris · K3sAWS · lomu mezgliplatform lomas mezglinodeSelectorbuild lomas mezglsNoSchedule taintGitHubActions · GHCRKlienta lietotnes klasteris · piemērsviens katram reģistrētajam mērķimViens K3s mezgls · serverCilium · kube-proxy saglabāts1workflow_dispatch2runner Job papildināšana3darba saņemšana4testēts komplekts5 publicēšana pēc jaucējvērtības · release job · GitHub-hosted → GHCR51workload commit · push2revision3 Application sync · produkta API · cd.js → bridge.py → Argo CD · Application34piemērošana nosaukumvietā5lejupielāde pēc jaucējvērtības1HTTPS 4432NodePort3 uz Pod · NodePort Service · Local → Deployment · Pod · attēls pēc jaucējvērtības34 politikas piemērošana · Cilium · Helm · VXLAN → NetworkPolicy · uzskaitītie CIDR45 informācijas panelis · API · Railshot lietotājs → dashboard · nginx51 revīzija · health · attēli · produkta API · cd.js → bridge.py → Argo CD · Application12publiskā HTTPS pārbaude3Pod diagnostika · nav verdikts4žurnāla tail · 100 rindas uz Pod5scrape · NodePort6Blackbox probe1platformas renderēšana · Secret2reģistrācijas bootstrap3K3s · Cilium instalēšana4TokenRequest · 6 h

Būvēšana → attēla publicēšana

Produkta API pieprasa GitHub Actions palaidienu, un build mezgla runner pieņem un pārbauda darbu. Tikai komplekts, kas izturējis tās pašas pārbaudes, tiek publicēts GHCR ar GitHub mitinātu release job.

  1. produkta API · cd.js → bridge.pyrailshot-systemizpilde · piemērošana: workflow_dispatchloop job · self-hosted runnerrailshot-deploy.yml

    Produkta API pieprasa GitHub Actions palaidienu ar tenant, app, pirmkoda komitu un mērķi. API nekad tieši neizsauc runner Job.

  2. build controller · CronJobrailshot-systemizpilde · piemērošana: runner Job papildināšanarunner Job · hostNetwork · Docker socketrailshot-build

    Build controller CronJob (katru minūti, platform mezglā) izveido runner Job nosaukumvietā railshot-build. Tā Role atļauj tikai Job get, list un create un get, update un patch vienam runner reģistrācijas Secret; tas nevar izveidot nosaukumvietas vai citus Secret.

  3. runner Job · hostNetwork · Docker socketrailshot-buildizpilde · piemērošana: darba saņemšanaloop job · self-hosted runnerrailshot-deploy.yml

    Runner build lomas mezglā (precīzs hostname, NoSchedule toleration) pieņem loop job pēc self-hosted etiķetēm un izpilda to. Klienta pirmkods darbojas esošajos ierobežotajos Docker būvēšanas un pārbaudes konteineros.

  4. runner Job · hostNetwork · Docker socketrailshot-builddati: testēts komplektsrelease job · GitHub-hostedrailshot-deploy.yml

    Loop job atstāj komplektu, kas izturējis tās pašas pārbaudes, un release job pieņem tikai šo komplektu.

  5. release job · GitHub-hostedrailshot-deploy.ymldati: publicēšana pēc jaucējvērtībasGHCR

    GitHub mitināts release job (ubuntu-24.04) publicē testētā komplekta attēlu GHCR, nebūvējot to no jauna. Attēlu publicēšana nekad nenotiek klienta lietotnes klasterī.

Config Git → Argo → klienta nosaukumvieta

Config Git nes vēlamos resursus, bet GHCR — attēla baitus. Argo CD piemēro tikai reģistrētajā klienta nosaukumvietā.

  1. produkta API · cd.js → bridge.pyrailshot-systemdati: workload commit · pushconfig Git repozitorijs

    cd.js palaiž bridge.py, kas komitē un veic push workload.json tikai tad, ja publikācijas ieraksts un reģistrētais mērķis sakrīt, pēc tam nolasa attālo revīziju atpakaļ. Git nes vēlamos resursus; GHCR nes attēla baitus.

  2. config Git repozitorijsdati: revisionArgo CD · Applicationargocd

    Application nolasa tikai savu ierobežoto config repozitoriju, ceļu un revīziju.

  3. produkta API · cd.js → bridge.pyrailshot-systemizpilde · piemērošana: Application syncArgo CD · Applicationargocd

    Nosauktais Application tiek iestatīts ar server-side apply, un tiek pieprasīta vienas precīzas revīzijas sinhronizācija bez prune. Produkta API ServiceAccount railshot-product ir gan operatora instalētais reģistrācijas bootstrap (create Secret, AppProject un Application nosaukumvietā argocd; get, update un escalate nosauktām Role), gan get un patch tiesības, kas katram validētajam mērķim tiek pievienotas ar precīzu nosaukumu. Kubernetes create nevar ierobežot pēc nosaukuma, tāpēc nosaukumus tvērumā notur arī produkta ievades validācija.

  4. Argo CD · Applicationargocdizpilde · piemērošana: piemērošana nosaukumvietā<app namespace>

    Argo CD piemēro klienta klastera noteiktajā nosaukumvietā ar reģistrētā klastera Secret akreditācijas datiem. AppProject atļauj tikai nosaukumvietas līmeņa veidus un nekādus klastera līmeņa resursus.

  5. Deployment · Pod · attēls pēc jaucējvērtības<app namespace>dati: lejupielāde pēc jaucējvērtībasGHCR

    Publicētais attēls pēc jaucējvērtības tiek lejupielādēts ar pull Secret, uz kuru atsaucas pēc nosaukuma tajā pašā nosaukumvietā. Secret vērtības nekad nenonāk artefaktā vai config Git.

Publiskais pieprasījumu ceļš

Lietotnes pieprasījumi iet pa ceļu nodrošinātāja L7 ieejas punkts → mezgla NodePort → Service → lietotnes Pod. Cilium politikas piemērošana ir atsevišķa kontrole, nevis solis, kas nes pieprasījumu. Ceļš uz darbības informācijas paneli ir atsevišķs.

  1. Lietotnes lietotājsdati: HTTPS 443Nodrošinātāja L7 ieejas punkts

    Lietotnes lietotāji sasniedz nodrošinātāja L7 ieejas punktu pēc reģistrētā resursdatora nosaukuma. Katrs nodrošinātājs implementē savu ieejas punktu.

  2. Nodrošinātāja L7 ieejas punktsdati: NodePortNodePort Service · Local<app namespace>

    Ieejas punkts pārsūta uz mezgla privāto adresi un NodePort. NodePort ir tas, kas piešķirts mērķa reģistrācijā.

  3. NodePort Service · Local<app namespace>dati: uz PodDeployment · Pod · attēls pēc jaucējvērtības<app namespace>

    Service nosūta pieprasījumu uz tā paša mezgla lietotnes Pod (Deployment). Ar externalTrafficPolicy Local avota adrese nemainīta sasniedz NetworkPolicy reģistrēto CIDR pārbaudi.

  4. Cilium · Helm · VXLANkube-systemizpilde · piemērošana: politikas piemērošanaNetworkPolicy · uzskaitītie CIDR<app namespace>

    Cilium piemēro NetworkPolicy: ienākošā datplūsma tikai no reģistrētajiem CIDR uz lietotnes portu; izejošās datplūsmas pēc noklusējuma nav, izņemot apstiprinātu datubāzes adresi. Mākoņa ugunsmūri un resursdatora noteikumi joprojām ir svarīgi.

  5. Railshot lietotājsdati: informācijas panelis · APIdashboard · nginxrailshot-system

    Lietotāji caur darbības ieejas punktu nonāk nginx informācijas panelī, un nginx atrodas produkta API priekšā. Informācijas paneļa Service ir NodePort tikai tad, ja dots apstiprināts mezgla ports; API paliek ClusterIP.

Verifikācija · novērošana

Izvietošanas verdikts balstās tikai uz Argo stāvokli un publiskā URL pārbaudi. Pod diagnostika, pašreizējie žurnāli un darbības metrikas ir atsevišķi signāli, kas to nekad nemaina.

  1. produkta API · cd.js → bridge.pyrailshot-systemnovērošana: revīzija · health · attēliArgo CD · Applicationargocd

    Deployed prasa Application sinhronizācijas revīziju, Synced un Healthy, operāciju Succeeded un lai Argo Application stāvoklī reģistrētās attēlu atsauces būtu vienādas ar pārskatītā Deployment attēliem pēc jaucējvērtības. Tie nav tieši Pod imageID vārti, un zaļš Argo stāvoklis viens pats šo atbilstību neapliecina.

  2. produkta API · cd.js → bridge.pyrailshot-systemnovērošana: publiskā HTTPS pārbaudeNodrošinātāja L7 ieejas punkts

    Reģistrētais publiskais URL tiek pārbaudīts bez pāradresācijām. Succeeded tiek reģistrēts tikai tad, ja ir gan Argo verdikts, gan šī pārbaude.

  3. produkta API · cd.js → bridge.pyrailshot-systemnovērošana: Pod diagnostika · nav verdiktsDeployment · Pod · attēls pēc jaucējvērtības<app namespace>

    Pēc Argo verdikta un publiskās pārbaudes Deployment, ReplicaSet un Pod tiek atsevišķi nolasīti ar reģistrētajiem akreditācijas datiem, un imageID un gatavība tiek pievienoti kā ready, progressing vai unavailable diagnostika. Neizdevusies vai atšķirīga diagnostika nekad nemaina verdiktu deployed vai succeeded.

  4. produkta API · cd.js → bridge.pyrailshot-systemnovērošana: žurnāla tail · 100 rindas uz PodDeployment · Pod · attēls pēc jaucējvērtības<app namespace>

    Tikai pašlaik izvietotajai operācijai, ar uzticamo konfigurāciju un reģistrētajiem akreditācijas datiem. Katram pašreizējam Pod (ne vairāk kā trim) darbojošā attēla jaucējvērtībai jābūt vienādai ar sagaidīto; pēc tam baitu limita robežās tiek nolasītas līdz 100 aizklātām rindām uz Pod. Vecākam mēģinājumam atbilde ir superseded; bez konfigurācijas — not_configured. Tā nav žurnālu apkopošana.

  5. Novērotāja VMnovērošana: scrape · NodePortrailshot-observability

    Prometheus novērotāja VM vāc node-exporter un kube-state-metrics caur diviem ar ugunsmūri ierobežotiem NodePort. Trūkstošas vai novecojušas vērtības ir nezināmas, nevis nulle.

  6. Novērotāja VMnovērošana: Blackbox probeNodrošinātāja L7 ieejas punkts

    probe_success=1 nozīmē 2xx atbildi šajā zondes vietā. Tas nepierāda ne katra lietotāja piekļuvi, ne izvietoto versiju, un tas nekad nepaaugstina published līdz deployed.

Operatora instalēšana · reģistrācija

Klastera instalēšana, reģistrācijas bootstrap un mērķa ievades, Secret un akreditācijas datu atjaunošanas iestatījumi ir operatora ievades, nekad ne klienta lietotnes derīgās slodzes daļa.

  1. Operatora bootstrapizpilde · piemērošana: platformas renderēšana · Secretrailshot-system

    Operators renderē platformas deklarāciju ar render-platform.py un nodrošina privāto darbības konfigurāciju un Secret. Attālais MCP tiek iekļauts tikai tad, ja dots tā attēls, un personīgā vārteja (WireGuard) — tikai ar --personal.

  2. Operatora bootstrapizpilde · piemērošana: reģistrācijas bootstrapAppProject · cluster Secretargocd

    Operators nosaukumvietā argocd instalē reģistrācijas bootstrap Role un tukšu reģistrāciju Role un sagatavo mērķa ievades. Pēc tam produkta API palaistie reģistrācijas palīgrīki (environment.py, applications.py) ieraksta Secret railshot-<target> ar ierobežotiem akreditācijas datiem (clusterResources false, atļautās nosaukumvietas uzskaitītas) un pievieno validētos precīzos nosaukumus reģistrāciju Role. Katras lietotnes reģistrācija piesaista nosaukumvietu app-<id> tāda paša nosaukuma AppProject.

  3. Operatora bootstrapizpilde · piemērošana: K3s · Cilium instalēšanaCilium · Helm · VXLANkube-system

    install-k3s.sh instalē viena mezgla K3s serveri (flannel, network policy, traefik un servicelb izslēgti; kube-proxy saglabāts), un Cilium tiek instalēts kā Helm laidiens (kubeProxyReplacement false, VXLAN, Hubble izslēgts).

  4. atjaunošanas CronJob · ik pēc 2 hargocdizpilde · piemērošana: TokenRequest · 6 hrailshot-argocd SA · žetons<app namespace>

    CronJob railshot-credentials ik pēc divām stundām pieprasa jaunu sešu stundu žetonu klienta SA. Klienta puses Role atļauj tikai token create savam SA. Sešas stundas ir viena žetona TTL, nevis brīdis, kad beidzas operatora piekļuve.

Visi savienojumi ar vienādu svaru. Izvēlieties plūsmu, lai izceltu tikai tās ceļu ar numurētiem soļiem.

  • Nepārtraukta · pieprasījumu, komplektu, attēlu un deklarāciju plūsmas virziens
  • Raustīta · palaišanas pieprasījumi, piemērošana, instalēšana, akreditācijas dati
  • Gara svītra-punkts · stāvokļa, žurnālu, zonžu un metriku nolasīšana; nošķirta no verdikta
  • Bieza melna līnija · izvēlētā plūsma; skaitļi norāda secību
  • Rāmis · nosaukumvieta, nosaukums galvenē (nav mezgls)
  • Iekšējā plāksnīte · komponents šajā nosaukumvietā
  • Raustīts rāmis · ārpus klasteriem
  • railshot-system · produkts
  • argocd · izvietošanas pilnvaras
  • railshot-build · resursdatora Docker pilnvaras
  • GitHub · klienta klasteris

docs/architecture 2. oktobra izvietojuma lēmums (divi lomu mezgli) un publiskā README diagramma ir vēsture; šī karte seko komita 645e28a deklarācijām un kodam. Bultas rāda cēloni un virzienu, nevis pierādījumu, ka katrs nodrošinātāja ceļš pašlaik darbojas.

Nosaukumvietas un mezgli
Nosaukumvieta ir nosaukumu tvērums: ne aparatūra, ne pati par sevi drošības robeža. Platform un build lomas ir plānošanas izvietojums ar nodeSelector un taint; šī karte nefiksē darbības klastera mezglu skaitu. Arī Argo CD mezglu izvietojums ir atsevišķa pārbaude.
Build mezgla pilnvaras
Runner Job darbojas ar hostNetwork, resursdatora Docker ligzdu, NET_ADMIN un root. Nosaukumvieta, taint vai RBAC nenoņem resursdatora Docker pilnvaras, tāpēc tā nav ne VM administratora izolācija, ne smilškaste patvaļīgam kodam.
Klienta nosaukumvieta
Katrs reģistrētais mērķis izmanto nenoklusējuma nosaukumvietu un AppProject (piemēram, tenant-demo vai katrai lietotnei app-<id>). Tiek izveidots tikai viena pakalpojuma Deployment (ServiceAccount žetona automātiskā piesaiste izslēgta), NodePort Service un NetworkPolicy, kā arī neobligāts PVC vai migrācijas Job; uz Secret tikai atsaucas pēc nosaukuma (pull Secret un apstiprināts DATABASE_URL), tie nekad netiek izveidoti.
AWS ieejas punkts
Route 53 Alias → koplietots ALB HTTPS 443 → klienta mezgla privātā adrese un NodePort. Daudzas lietotnes atkārtoti izmanto vienu mezglu, katra ar savu nosaukumvietu, Application un NodePort.
GCP ieejas punkts
Globāls EXTERNAL_MANAGED HTTPS LB → zonāls GCE_VM_IP_PORT NEG → esošās VM privātais NodePort. Sertifikāti nāk no Certificate Manager ar DNS autorizāciju. Modulim nepieder ne VM, ne VPC, un viena VM paliek vienīgais atteices punkts.
OpenStack ieejas punkts
Amphora TLS klausītājs 443 ar Host un ceļa L7 politikām → HTTP NodePort. Noklusējuma adrese ir privāts VIP; Octavia, K3s, datubāze un DNS ir ārpus moduļa. Publiska sasniedzamība un Amphora gatavība uz vietas prasa atsevišķu pieņemšanu, un piemērošana uz vietas ar šo moduli vēl nav verificēta.
Starp nodrošinātājiem
Trīs ieejas punkti ir atsevišķas implementācijas, bez automātiskas pārslēgšanās vai replikācijas starp nodrošinātājiem. Klienta lietotnes klasteris ir reģistrēta mērķa piemērs, nevis apgalvojums, ka tā pati izvietošana vienlaikus darbojas visos mākoņos.
Operatora iespējas
Personīgā vārteja (WireGuard) pievienojas platformai tikai tad, ja operators iespējo --personal; tā nav obligāts ceļš klientu mākoņiem. Atbalstītajā direct režīmā novērotāja VM var koplietot darbības vadības VM.