SK
RAILSHOT.
Späť do sály

Railshot

AI deployment & operations platform

Nasadiť lokálne vytvorenú webovú aplikáciu do pripravených cloudových a on-premises prostredí a potom ju prevádzkovať.

Platforma AI na nasadenie a prevádzku, ktorá prevedie lokálne vytvorenú webovú aplikáciu do pripravených cloudových alebo on-premises prostredí a ďalej ju prevádzkuje.

2026.09.28 — 2026.10.04 · Ukončené

Tímový projekt · môj podiel: plánovanie a implementácia CI, klastre CSP a rozhranie Ansible, prevádzka, revízia kódu tímu a integrácia

SoftBank Hackathon 2026 powered by KOREC & ProgateÚčastník predkola · výber finalistov bude oznámený 2026.10.26 (stav k 2026.10.07)

  • WebImplementované · hackathon
  • Server MCPImplementované · vzdialene · lokálne

Prevádzkový klaster a klastre zákazníckych aplikácií sú oddelené a verejná cesta je oddelená od riadenia nasadenia.

V prevádzkovom K3s sú dashboard, API produktu a build controller umiestnené na uzloch v role platform a Joby runnerov na uzle v role build, zatiaľ čo nasadenie zabezpečuje Argo CD. Zákaznícke aplikácie bežia vo vyhradenom mennom priestore samostatného jednouzlového klastra K3s + Cilium pre každý registrovaný cieľ.

Mapa klastrov · nakreslené podľa deklarácií a kódu vo verejnom commite 645e28a
Mapa prevádzkového a zákazníckych klastrov RailshotPrevádzkový klaster K3s a registrovaný klaster zákazníckej aplikácie. V prevádzkovom klastri menný priestor railshot-system umiestňuje dashboard, API produktu, vzdialené MCP (len keď je dodaný jeho obraz) a build controller na uzly v role platform; Joby runnerov v mennom priestore railshot-build preberajú úlohy GitHub Actions na uzle v role build označenom taintom. Úloha vydania hostovaná na GitHube publikuje otestovaný bundle do GHCR. API produktu commituje workload do config Git a synchronizuje Application v mennom priestore argocd a Argo CD aplikuje Deployment, Service NodePort a NetworkPolicy do menného priestoru registrovaného v zákazníckom klastri. Požiadavky na aplikáciu vstupujú cez vstup L7 poskytovateľa do NodePort a Service uzla a potom do podu aplikácie. Rozhodnutie o nasadení stojí len na stave Argo a kontrole verejnej URL; diagnostika podov, logy a metriky sa čítajú ako samostatné signály. Inštalačné a registračné vstupy operátora sú oddelené od payloadu aplikácie tenanta.Používateľ Railshotdashboard · MCPBootstrap operátorainštalácia · registrácia · SecretGHCRobrazy podľa digestuRepozitár config Gitworkload.json · revisionVstup L7 poskytovateľaALB · GCP LB · AmphoraPoužívateľ aplikácieverejné HTTPSPozorovacia VMmimo K3s zákazníka · Composerailshot-systemdashboard · nginxvzdialené MCP · len s obrazombuild controller · CronJobAPI produktu · cd.js → bridge.pyargocdArgo CD · ApplicationAppProject · cluster SecretCronJob obnovy · každé 2 hrailshot-buildrunner Job · hostNetwork · Docker socketrailshot-deploy.ymlloop job · self-hosted runnerrelease job · GitHub-hosted<app namespace>Deployment · Pod · obraz podľa digestuNodePort Service · LocalNetworkPolicy · uvedené CIDRSA railshot-argocd · tokenkube-systemCilium · Helm · VXLANrailshot-observabilitynode-exporterkube-state-metricsPrevádzkový klaster · K3sAWS · uzly podľa rolíuzly v role platformnodeSelectoruzol v role buildNoSchedule taintGitHubActions · GHCRKlaster zákazníckej aplikácie · príkladjeden na registrovaný cieľJeden uzol K3s · serverCilium · kube-proxy ponechaný1workflow_dispatch2dopĺňanie Jobov runnera3prevzatie úlohy4otestovaný bundle5 publikovanie podľa digestu · release job · GitHub-hosted → GHCR51workload commit · push2revision3 Application sync · API produktu · cd.js → bridge.py → Argo CD · Application34aplikácia do menného priestoru5stiahnutie podľa digestu1HTTPS 4432NodePort3 k podu · NodePort Service · Local → Deployment · Pod · obraz podľa digestu34 vynútenie politiky · Cilium · Helm · VXLAN → NetworkPolicy · uvedené CIDR45 dashboard · API · Používateľ Railshot → dashboard · nginx51 revízia · health · obrazy · API produktu · cd.js → bridge.py → Argo CD · Application12verejná kontrola HTTPS3diagnostika podu · nie rozhodnutie4tail logov · 100 riadkov na pod5scrape · NodePorty6Blackbox probe1render platformy · Secret2bootstrap registrácie3inštalácia K3s · Cilium4TokenRequest · 6 h

Build → publikovanie obrazu

API produktu žiada o beh GitHub Actions a runner na uzle build úlohu prevezme a skontroluje. Do GHCR publikuje úloha vydania hostovaná na GitHube len bundle, ktorý prešiel rovnakými kontrolami.

  1. API produktu · cd.js → bridge.pyrailshot-systemworkflow_dispatchloop job · self-hosted runnerrailshot-deploy.yml

    API produktu žiada o beh GitHub Actions s tenantom, aplikáciou, zdrojovým commitom a cieľom. API nikdy nevolá Job runnera priamo.

  2. build controller · CronJobrailshot-systemdopĺňanie Jobov runnerarunner Job · hostNetwork · Docker socketrailshot-build

    CronJob build controllera (každú minútu, na uzle platform) vytvára Joby runnerov v mennom priestore railshot-build. Jeho Role povoľuje len get, list a create pre Joby a get, update a patch pre jediný Secret registrácie runnera; nemôže vytvárať menné priestory ani iné Secrety.

  3. runner Job · hostNetwork · Docker socketrailshot-buildprevzatie úlohyloop job · self-hosted runnerrailshot-deploy.yml

    Runner na uzle v role build (presný hostname, tolerancia NoSchedule) prevezme úlohu loop podľa štítkov self-hosted a spustí ju. Zdrojový kód zákazníka beží v existujúcich obmedzených kontajneroch Docker na build a kontroly.

  4. runner Job · hostNetwork · Docker socketrailshot-buildotestovaný bundlerelease job · GitHub-hostedrailshot-deploy.yml

    Úloha loop zanechá bundle, ktorý prešiel rovnakými kontrolami, a úloha vydania prevezme len tento bundle.

  5. release job · GitHub-hostedrailshot-deploy.ymlpublikovanie podľa digestuGHCR

    Úloha vydania hostovaná na GitHube (ubuntu-24.04) publikuje obraz z otestovaného bundlu do GHCR bez nového buildu. Publikovanie obrazov nikdy neprebieha vnútri klastra zákazníckej aplikácie.

Config Git → Argo → menný priestor zákazníka

Config Git nesie požadované prostriedky a GHCR bajty obrazu. Argo CD aplikuje len do registrovaného menného priestoru zákazníka.

  1. API produktu · cd.js → bridge.pyrailshot-systemworkload commit · pushRepozitár config Git

    cd.js spúšťa bridge.py, ktorý commituje a pushuje workload.json len vtedy, keď sa záznam o publikovaní a registrovaný cieľ zhodujú, a potom spätne prečíta vzdialenú revíziu. Git nesie požadované prostriedky; GHCR nesie bajty obrazu.

  2. Repozitár config GitrevisionArgo CD · Applicationargocd

    Application číta len svoj obmedzený repozitár konfigurácie, cestu a revíziu.

  3. API produktu · cd.js → bridge.pyrailshot-systemApplication syncArgo CD · Applicationargocd

    Pomenovaná Application sa nastaví cez server-side apply a o synchronizáciu jednej presnej revízie sa žiada bez prune. ServiceAccount railshot-product API produktu má jednak operátorom nainštalovaný bootstrap registrácie (create pre Secrety, AppProjecty a Applications v argocd; get, update a escalate pre pomenované Role), jednak oprávnenia get a patch pripájané presným názvom pre každý overený cieľ. Kubernetesové create sa nedá obmedziť názvom, preto názvy v rozsahu stráži aj validácia vstupov v produkte.

  4. Argo CD · Applicationargocdaplikácia do menného priestoru<app namespace>

    Argo CD aplikuje do vyhradeného menného priestoru v zákazníckom klastri s prihlasovacími údajmi z registrovaného Secretu klastra. AppProject povoľuje len druhy v rozsahu menného priestoru a žiadne prostriedky v rozsahu klastra.

  5. Deployment · Pod · obraz podľa digestu<app namespace>stiahnutie podľa digestuGHCR

    Publikovaný obraz podľa digestu sa sťahuje s pull Secretom odkazovaným názvom v tom istom mennom priestore. Hodnoty Secretov sa nikdy nedostanú do artefaktu ani do config Git.

Verejná cesta požiadaviek

Požiadavky na aplikáciu idú: vstup L7 poskytovateľa → NodePort uzla → Service → pod aplikácie. Vynucovanie politiky Ciliom je samostatná kontrola, nie krok, ktorý požiadavku nesie. Vstup do prevádzkového dashboardu je samostatná cesta.

  1. Používateľ aplikácieHTTPS 443Vstup L7 poskytovateľa

    Používatelia aplikácie sa dostanú k vstupu L7 poskytovateľa cez registrovaný hostname. Každý poskytovateľ implementuje vlastný vstup.

  2. Vstup L7 poskytovateľaNodePortNodePort Service · Local<app namespace>

    Vstup odovzdáva prevádzku na súkromnú adresu uzla a NodePort. NodePort je ten pridelený pri registrácii cieľa.

  3. NodePort Service · Local<app namespace>k poduDeployment · Pod · obraz podľa digestu<app namespace>

    Service posiela požiadavku k podu aplikácie (Deployment) na tom istom uzle. S externalTrafficPolicy Local dorazí zdrojová adresa bez zmeny ku kontrole registrovaných CIDR v NetworkPolicy.

  4. Cilium · Helm · VXLANkube-systemvynútenie politikyNetworkPolicy · uvedené CIDR<app namespace>

    Cilium vynucuje NetworkPolicy: prichádzajúca prevádzka len z registrovaných CIDR na port aplikácie; predvolene žiadna odchádzajúca prevádzka okrem schválenej adresy databázy. Cloudové firewally a pravidlá hostiteľa stále zohrávajú úlohu.

  5. Používateľ Railshotdashboard · APIdashboard · nginxrailshot-system

    Používatelia prichádzajú cez prevádzkový vstup do dashboardu nginx a nginx stojí pred API produktu. Service dashboardu je typu NodePort len vtedy, ak je zadaný schválený port uzla; API zostáva ClusterIP.

Overenie · pozorovanie

Rozhodnutie o nasadení stojí len na stave Argo a kontrole verejnej URL. Diagnostika podov, aktuálne logy a prevádzkové metriky sú samostatné signály, ktoré ho nikdy nemenia.

  1. API produktu · cd.js → bridge.pyrailshot-systemrevízia · health · obrazyArgo CD · Applicationargocd

    Stav deployed vyžaduje revíziu synchronizácie Application, Synced a Healthy, operáciu Succeeded a zhodu odkazov na obrazy zaznamenaných v stave Application v Argo s obrazmi podľa digestu z revidovaného Deploymentu. Nejde o bránu priamo na imageID podu a samotný zelený stav Argo túto zhodu nepotvrdzuje.

  2. API produktu · cd.js → bridge.pyrailshot-systemverejná kontrola HTTPSVstup L7 poskytovateľa

    Registrovaná verejná URL sa kontroluje bez presmerovaní. Succeeded sa zaznamená len s rozhodnutím Argo aj touto kontrolou zároveň.

  3. API produktu · cd.js → bridge.pyrailshot-systemdiagnostika podu · nie rozhodnutieDeployment · Pod · obraz podľa digestu<app namespace>

    Po rozhodnutí Argo a verejnej kontrole sa Deployment, ReplicaSety a pody čítajú osobitne s registrovanými prihlasovacími údajmi a imageID a pripravenosť sa pripoja ako diagnostika ready, progressing alebo unavailable. Neúspešná alebo odlišná diagnostika nikdy nemení rozhodnutie deployed ani succeeded.

  4. API produktu · cd.js → bridge.pyrailshot-systemtail logov · 100 riadkov na podDeployment · Pod · obraz podľa digestu<app namespace>

    Len pre aktuálne nasadenú operáciu, s dôveryhodnou konfiguráciou a registrovanými prihlasovacími údajmi. Pri každom aktuálnom pode (najviac troch) musí digest bežiaceho obrazu zodpovedať očakávanému; potom sa číta až 100 maskovaných riadkov na pod v limite bajtov. Starší pokus odpovie superseded; bez konfigurácie not_configured. Nejde o agregáciu logov.

  5. Pozorovacia VMscrape · NodePortyrailshot-observability

    Prometheus na pozorovacej VM zbiera dáta z node-exporter a kube-state-metrics cez dva NodePorty obmedzené firewallom. Chýbajúce alebo zastarané hodnoty sú neznáme, nie nulové.

  6. Pozorovacia VMBlackbox probeVstup L7 poskytovateľa

    probe_success=1 znamená odpoveď 2xx v mieste tejto sondy. Nedokazuje prístup každého používateľa ani nasadenú verziu a nikdy nepovýši published na deployed.

Inštalácia · registrácia operátorom

Inštalácia klastra, bootstrap registrácie a údaje o cieľoch, Secrety a nastavenie obnovy prihlasovacích údajov sú vstupy operátora, nikdy súčasť payloadu aplikácie tenanta.

  1. Bootstrap operátorarender platformy · Secretrailshot-system

    Operátor vyrenderuje deklaráciu platformy pomocou render-platform.py a dodá súkromnú prevádzkovú konfiguráciu a Secrety. Vzdialené MCP je zahrnuté len vtedy, keď je dodaný jeho obraz, a osobná brána (WireGuard) len s --personal.

  2. Bootstrap operátorabootstrap registrácieAppProject · cluster Secretargocd

    Operátor nainštaluje do argocd Role bootstrapu registrácie a prázdnu Role registrations a pripraví údaje o cieli. Potom registračné helpery spúšťané API produktu (environment.py, applications.py) zapíšu Secret railshot-<target> s prihlasovacími údajmi s vymedzeným rozsahom (clusterResources false, uvedené povolené menné priestory) a pripoja overené presné názvy do Role registrations. Registrácia pre jednotlivé aplikácie viaže menný priestor app-<id> na AppProject rovnakého názvu.

  3. Bootstrap operátorainštalácia K3s · CiliumCilium · Helm · VXLANkube-system

    install-k3s.sh nainštaluje jednouzlový server K3s (flannel, network policy, traefik a servicelb vypnuté; kube-proxy ponechaný) a Cilium sa inštaluje ako vydanie Helm (kubeProxyReplacement false, VXLAN, Hubble vypnutý).

  4. CronJob obnovy · každé 2 hargocdTokenRequest · 6 hSA railshot-argocd · token<app namespace>

    CronJob railshot-credentials každé dve hodiny žiada o nový šesťhodinový token pre SA zákazníka. Role na strane zákazníka povoľuje len token create pre vlastné SA. Šesť hodín je TTL jedného tokenu, nie okamih, keď končí prístup operátora.

Každé spojenie s rovnakou váhou. Výber toku zvýrazní len jeho cestu s očíslovanými krokmi.

  • Plná čiara · smer toku požiadaviek, bundlov, obrazov a deklarácií
  • Prerušovaná čiara · požiadavky na spustenie, aplikácia, inštalácia, prihlasovacie údaje
  • Dlhá bodkočiarkovaná · čítanie stavu, logov, sond, metrík; oddelene od rozhodnutia
  • Hrubá čierna čiara · zvolený tok; čísla udávajú poradie
  • Rámček · menný priestor, názov v hlavičke (nie je to uzol)
  • Vnútorný štítok · komponent v tomto mennom priestore
  • Prerušovaný rámček · mimo klastrov
  • railshot-system · produkt
  • argocd · oprávnenie na nasadenie
  • railshot-build · oprávnenie Dockera hostiteľa
  • GitHub · klaster zákazníka

Rozhodnutie o rozmiestnení z October 2 v docs/architecture (dva uzly rolí) a diagram vo verejnom README sú história; táto mapa zodpovedá deklaráciám a kódu v 645e28a. Šípky ukazujú príčinu a smer, nie doklad, že každá cesta poskytovateľa teraz funguje.

Menné priestory a uzly
Menný priestor je rozsah pomenovania: nie je to hardvér ani sám osebe bezpečnostná hranica. Roly platform a build sú rozmiestnením pri plánovaní pomocou nodeSelector a taint; táto mapa nestanovuje počet uzlov prevádzkového klastra. Rozmiestnenie Argo CD na uzloch je takisto samostatná kontrola.
Oprávnenie uzla build
Joby runnerov bežia s hostNetwork, soketom Dockera hostiteľa, NET_ADMIN a ako root. Menný priestor, taint ani RBAC oprávnenie Dockera hostiteľa neodstránia, takže nejde o izoláciu od správcu VM ani o sandbox pre ľubovoľný kód.
Menný priestor zákazníka
Každý registrovaný cieľ používa nepredvolený menný priestor a AppProject (napríklad tenant-demo alebo app-<id> pre každú aplikáciu). Vytvára sa len Deployment jednej služby (automount tokenu ServiceAccount vypnutý), Service NodePort a NetworkPolicy a voliteľne PVC alebo Job migrácie; Secrety sa len odkazujú názvom (pull Secret a schválená DATABASE_URL), nikdy sa nevytvárajú.
Vstup AWS
Route 53 Alias → zdieľaný ALB HTTPS 443 → súkromná adresa uzla zákazníka a NodePort. Mnoho aplikácií zdieľa jeden uzol, každá s vlastným menným priestorom, Application a NodePort.
Vstup GCP
Globálny EXTERNAL_MANAGED HTTPS LB → zónová GCE_VM_IP_PORT NEG → súkromný NodePort existujúcej VM. Certifikáty pochádzajú z Certificate Manager s autorizáciou DNS. Modul nevlastní VM ani VPC a jedna VM zostáva jediným bodom zlyhania.
Vstup OpenStack
Listener TLS Amphora 443 s politikami L7 pre Host a cestu → HTTP NodePort. Predvolenou adresou je súkromná VIP; Octavia, K3s, databáza a DNS sú mimo modulu. Verejná dosiahnuteľnosť a pripravenosť Amphory na mieste vyžadujú samostatné prevzatie a žiadne nasadenie na mieste sa týmto modulom zatiaľ neoverilo.
Medzi poskytovateľmi
Tri vstupy sú samostatné implementácie, bez automatického failoveru či replikácie medzi poskytovateľmi. Klaster zákazníckej aplikácie je príkladom registrovaného cieľa, nie tvrdením, že to isté nasadenie beží súčasne v každom cloude.
Voľby operátora
Osobná brána (WireGuard) sa k platforme pripojí len vtedy, keď operátor zapne --personal; pre zákaznícke cloudy nie je povinnou cestou. V podporovanom režime direct môže pozorovacia VM zdieľať prevádzkovú riadiacu VM.