CS
RAILSHOT.
Zpět do sálu

Railshot

AI deployment & operations platform

Nasadit lokálně vytvořenou webovou aplikaci do připravených cloudových a on-premises prostředí a pak ji provozovat.

Platforma AI pro nasazení a provoz, která převede lokálně vytvořenou webovou aplikaci do připravených cloudových nebo on-premises prostředí a dál ji provozuje.

2026.09.28 — 2026.10.04 · Ukončeno

Týmový projekt · můj podíl: plánování a implementace CI, clustery CSP a rozhraní Ansible, provoz, revize kódu týmu a integrace

SoftBank Hackathon 2026 powered by KOREC & ProgateÚčastník předkola · výběr finalistů bude oznámen 2026.10.26 (stav k 2026.10.07)

  • WebImplementováno · hackathon
  • Server MCPImplementováno · vzdáleně · lokálně

Provozní cluster a clustery zákaznických aplikací jsou oddělené a veřejná cesta je oddělena od řízení nasazení.

V provozním K3s jsou dashboard, API produktu a build controller umístěny na uzlech v roli platform a Joby runnerů na uzlu v roli build, zatímco nasazení obstarává Argo CD. Zákaznické aplikace běží ve vyhrazeném jmenném prostoru samostatného jednouzlového clusteru K3s + Cilium pro každý registrovaný cíl.

Mapa clusterů · nakresleno podle deklarací a kódu ve veřejném commitu 645e28a
Mapa provozního a zákaznických clusterů RailshotProvozní cluster K3s a registrovaný cluster zákaznické aplikace. V provozním clusteru jmenný prostor railshot-system umisťuje dashboard, API produktu, vzdálené MCP (jen když je dodán jeho obraz) a build controller na uzly v roli platform; Joby runnerů ve jmenném prostoru railshot-build přebírají úlohy GitHub Actions na uzlu v roli build označeném taintem. Úloha vydání hostovaná na GitHubu publikuje otestovaný bundle do GHCR. API produktu commituje workload do config Git a synchronizuje Application ve jmenném prostoru argocd a Argo CD aplikuje Deployment, Service NodePort a NetworkPolicy do jmenného prostoru registrovaného v zákaznickém clusteru. Požadavky na aplikaci vstupují přes vstup L7 poskytovatele do NodePort a Service uzlu a pak do podu aplikace. Rozhodnutí o nasazení stojí jen na stavu Argo a kontrole veřejné URL; diagnostika podů, logy a metriky se čtou jako samostatné signály. Instalační a registrační vstupy operátora jsou odděleny od payloadu aplikace tenanta.Uživatel Railshotdashboard · MCPBootstrap operátorainstalace · registrace · SecretGHCRobrazy podle digestuRepozitář config Gitworkload.json · revisionVstup L7 poskytovateleALB · GCP LB · AmphoraUživatel aplikaceveřejné HTTPSPozorovací VMmimo K3s zákazníka · Composerailshot-systemdashboard · nginxvzdálené MCP · jen s obrazembuild 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 podle digestuNodePort Service · LocalNetworkPolicy · uvedené CIDRSA railshot-argocd · tokenkube-systemCilium · Helm · VXLANrailshot-observabilitynode-exporterkube-state-metricsProvozní cluster · K3sAWS · uzly podle rolíuzly v roli platformnodeSelectoruzel v roli buildNoSchedule taintGitHubActions · GHCRCluster zákaznické aplikace · příkladjeden na registrovaný cílJeden uzel K3s · serverCilium · kube-proxy ponechán1workflow_dispatch2doplňování Jobů runneru3převzetí úlohy4otestovaný bundle5 publikace podle digestu · release job · GitHub-hosted → GHCR51workload commit · push2revision3 Application sync · API produktu · cd.js → bridge.py → Argo CD · Application34aplikace do jmenného prostoru5stažení podle digestu1HTTPS 4432NodePort3 k podu · NodePort Service · Local → Deployment · Pod · obraz podle digestu34 vynucení politiky · Cilium · Helm · VXLAN → NetworkPolicy · uvedené CIDR45 dashboard · API · Uživatel Railshot → dashboard · nginx51 revize · health · obrazy · API produktu · cd.js → bridge.py → Argo CD · Application12veřejná kontrola HTTPS3diagnostika podu · ne rozhodnutí4tail logů · 100 řádků na pod5scrape · NodePorty6Blackbox probe1render platformy · Secret2bootstrap registrace3instalace K3s · Cilium4TokenRequest · 6 h

Build → publikace obrazu

API produktu žádá o běh GitHub Actions a runner na uzlu build úlohu převezme a zkontroluje. Do GHCR publikuje úloha vydání hostovaná na GitHubu jen bundle, který prošel stejnými kontrolami.

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

    API produktu žádá o běh GitHub Actions s tenantem, aplikací, zdrojovým commitem a cílem. API nikdy nevolá Job runneru přímo.

  2. build controller · CronJobrailshot-systemdoplňování Jobů runnerurunner Job · hostNetwork · Docker socketrailshot-build

    CronJob build controlleru (každou minutu, na uzlu platform) vytváří Joby runnerů ve jmenném prostoru railshot-build. Jeho Role povoluje jen get, list a create pro Joby a get, update a patch pro jediný Secret registrace runneru; nemůže vytvářet jmenné prostory ani jiné Secrety.

  3. runner Job · hostNetwork · Docker socketrailshot-buildpřevzetí úlohyloop job · self-hosted runnerrailshot-deploy.yml

    Runner na uzlu v roli build (přesný hostname, tolerance NoSchedule) převezme úlohu loop podle štítků self-hosted a spustí ji. Zdrojový kód zákazníka běží ve stávajících omezených kontejnerech Docker pro build a kontroly.

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

    Úloha loop zanechá bundle, který prošel stejnými kontrolami, a úloha vydání převezme jen tento bundle.

  5. release job · GitHub-hostedrailshot-deploy.ymlpublikace podle digestuGHCR

    Úloha vydání hostovaná na GitHubu (ubuntu-24.04) publikuje obraz z otestovaného bundlu do GHCR bez nového buildu. Publikace obrazů nikdy neprobíhá uvnitř clusteru zákaznické aplikace.

Config Git → Argo → jmenný prostor zákazníka

Config Git nese požadované prostředky a GHCR bajty obrazu. Argo CD aplikuje jen do registrovaného jmenného prostoru zákazníka.

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

    cd.js spouští bridge.py, který commituje a pushuje workload.json jen tehdy, když se záznam o publikaci a registrovaný cíl shodují, a pak zpětně přečte vzdálenou revizi. Git nese požadované prostředky; GHCR nese bajty obrazu.

  2. Repozitář config GitrevisionArgo CD · Applicationargocd

    Application čte jen svůj omezený repozitář konfigurace, cestu a revizi.

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

    Pojmenovaná Application se nastaví přes server-side apply a o synchronizaci jedné přesné revize se žádá bez prune. ServiceAccount railshot-product API produktu má jak operátorem nainstalovaný bootstrap registrace (create pro Secrety, AppProjecty a Applications v argocd; get, update a escalate pro pojmenované Role), tak oprávnění get a patch připojovaná přesným názvem pro každý ověřený cíl. Kubernetesové create nelze omezit názvem, proto názvy v rozsahu hlídá i validace vstupů v produktu.

  4. Argo CD · Applicationargocdaplikace do jmenného prostoru<app namespace>

    Argo CD aplikuje do vyhrazeného jmenného prostoru v zákaznickém clusteru s přihlašovacími údaji z registrovaného Secretu clusteru. AppProject povoluje jen druhy v rozsahu jmenného prostoru a žádné prostředky v rozsahu clusteru.

  5. Deployment · Pod · obraz podle digestu<app namespace>stažení podle digestuGHCR

    Publikovaný obraz podle digestu se stahuje s pull Secretem odkazovaným názvem ve stejném jmenném prostoru. Hodnoty Secretů se nikdy nedostanou do artefaktu ani do config Git.

Veřejná cesta požadavků

Požadavky na aplikaci jdou: vstup L7 poskytovatele → NodePort uzlu → Service → pod aplikace. Vynucování politiky Ciliem je samostatná kontrola, nikoli krok, který požadavek nese. Vstup do provozního dashboardu je samostatná cesta.

  1. Uživatel aplikaceHTTPS 443Vstup L7 poskytovatele

    Uživatelé aplikace se dostanou ke vstupu L7 poskytovatele přes registrovaný hostname. Každý poskytovatel implementuje vlastní vstup.

  2. Vstup L7 poskytovateleNodePortNodePort Service · Local<app namespace>

    Vstup předává provoz na soukromou adresu uzlu a NodePort. NodePort je ten přidělený při registraci cíle.

  3. NodePort Service · Local<app namespace>k poduDeployment · Pod · obraz podle digestu<app namespace>

    Service posílá požadavek k podu aplikace (Deployment) na stejném uzlu. S externalTrafficPolicy Local dorazí zdrojová adresa beze změny ke kontrole registrovaných CIDR v NetworkPolicy.

  4. Cilium · Helm · VXLANkube-systemvynucení politikyNetworkPolicy · uvedené CIDR<app namespace>

    Cilium vynucuje NetworkPolicy: příchozí provoz jen z registrovaných CIDR na port aplikace; ve výchozím stavu žádný odchozí provoz kromě schválené adresy databáze. Cloudové firewally a pravidla hostitele stále hrají roli.

  5. Uživatel Railshotdashboard · APIdashboard · nginxrailshot-system

    Uživatelé přicházejí přes provozní vstup do dashboardu nginx a nginx stojí před API produktu. Service dashboardu je typu NodePort jen tehdy, je-li zadán schválený port uzlu; API zůstává ClusterIP.

Ověření · pozorování

Rozhodnutí o nasazení stojí jen na stavu Argo a kontrole veřejné URL. Diagnostika podů, aktuální logy a provozní metriky jsou samostatné signály, které ho nikdy nemění.

  1. API produktu · cd.js → bridge.pyrailshot-systemrevize · health · obrazyArgo CD · Applicationargocd

    Stav deployed vyžaduje revizi synchronizace Application, Synced a Healthy, operaci Succeeded a shodu odkazů na obrazy zaznamenaných ve stavu Application v Argo s obrazy podle digestu z revidovaného Deploymentu. Nejde o bránu přímo na imageID podu a samotný zelený stav Argo tuto shodu nepotvrzuje.

  2. API produktu · cd.js → bridge.pyrailshot-systemveřejná kontrola HTTPSVstup L7 poskytovatele

    Registrovaná veřejná URL se kontroluje bez přesměrování. Succeeded se zaznamená jen s rozhodnutím Argo i touto kontrolou zároveň.

  3. API produktu · cd.js → bridge.pyrailshot-systemdiagnostika podu · ne rozhodnutíDeployment · Pod · obraz podle digestu<app namespace>

    Po rozhodnutí Argo a veřejné kontrole se Deployment, ReplicaSety a pody čtou zvlášť s registrovanými přihlašovacími údaji a imageID a připravenost se připojí jako diagnostika ready, progressing nebo unavailable. Neúspěšná nebo odlišná diagnostika nikdy nemění rozhodnutí deployed ani succeeded.

  4. API produktu · cd.js → bridge.pyrailshot-systemtail logů · 100 řádků na podDeployment · Pod · obraz podle digestu<app namespace>

    Jen pro aktuálně nasazenou operaci, s důvěryhodnou konfigurací a registrovanými přihlašovacími údaji. U každého aktuálního podu (nejvýše tří) musí digest běžícího obrazu odpovídat očekávanému; pak se čte až 100 maskovaných řádků na pod v limitu bajtů. Starší pokus odpoví superseded; bez konfigurace not_configured. Nejde o agregaci logů.

  5. Pozorovací VMscrape · NodePortyrailshot-observability

    Prometheus na pozorovací VM sbírá data z node-exporter a kube-state-metrics přes dva NodePorty omezené firewallem. Chybějící nebo zastaralé hodnoty jsou neznámé, nikoli nulové.

  6. Pozorovací VMBlackbox probeVstup L7 poskytovatele

    probe_success=1 znamená odpověď 2xx v místě této sondy. Nedokazuje přístup každého uživatele ani nasazenou verzi a nikdy nepovýší published na deployed.

Instalace · registrace operátorem

Instalace clusteru, bootstrap registrace a údaje o cílech, Secrety a nastavení obnovy přihlašovacích údajů jsou vstupy operátora, nikdy součást payloadu aplikace tenanta.

  1. Bootstrap operátorarender platformy · Secretrailshot-system

    Operátor vyrenderuje deklaraci platformy pomocí render-platform.py a dodá soukromou provozní konfiguraci a Secrety. Vzdálené MCP je zahrnuto jen tehdy, když je dodán jeho obraz, a osobní brána (WireGuard) jen s --personal.

  2. Bootstrap operátorabootstrap registraceAppProject · cluster Secretargocd

    Operátor nainstaluje do argocd Role bootstrapu registrace a prázdnou Role registrations a připraví údaje o cíli. Poté registrační helpery spouštěné API produktu (environment.py, applications.py) zapíší Secret railshot-<target> s přihlašovacími údaji s vymezeným rozsahem (clusterResources false, uvedené povolené jmenné prostory) a připojí ověřené přesné názvy do Role registrations. Registrace pro jednotlivé aplikace váže jmenný prostor app-<id> na AppProject stejného názvu.

  3. Bootstrap operátorainstalace K3s · CiliumCilium · Helm · VXLANkube-system

    install-k3s.sh nainstaluje jednouzlový server K3s (flannel, network policy, traefik a servicelb vypnuty; kube-proxy ponechán) a Cilium se instaluje jako vydání 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é dvě hodiny žádá o nový šestihodinový token pro SA zákazníka. Role na straně zákazníka povoluje jen token create pro vlastní SA. Šest hodin je TTL jednoho tokenu, nikoli okamžik, kdy končí přístup operátora.

Každé spojení se stejnou váhou. Výběr toku zvýrazní jen jeho cestu s očíslovanými kroky.

  • Plná čára · směr toku požadavků, bundlů, obrazů a deklarací
  • Přerušovaná čára · požadavky na spuštění, aplikace, instalace, přihlašovací údaje
  • Dlouhá čerchovaná · čtení stavu, logů, sond, metrik; odděleně od rozhodnutí
  • Silná černá čára · zvolený tok; čísla udávají pořadí
  • Rámeček · jmenný prostor, název v záhlaví (není to uzel)
  • Vnitřní štítek · komponenta v tomto jmenném prostoru
  • Přerušovaný rámeček · mimo clustery
  • railshot-system · produkt
  • argocd · oprávnění k nasazení
  • railshot-build · oprávnění Dockeru hostitele
  • GitHub · cluster zákazníka

Rozhodnutí o rozmístění z October 2 v docs/architecture (dva uzly rolí) a diagram ve veřejném README jsou historie; tato mapa odpovídá deklaracím a kódu v 645e28a. Šipky ukazují příčinu a směr, nikoli doklad, že každá cesta poskytovatele nyní funguje.

Jmenné prostory a uzly
Jmenný prostor je rozsah pojmenování: není to hardware ani sám o sobě bezpečnostní hranice. Role platform a build jsou rozmístěním při plánování pomocí nodeSelector a taint; tato mapa nestanovuje počet uzlů provozního clusteru. Rozmístění Argo CD na uzlech je rovněž samostatná kontrola.
Oprávnění uzlu build
Joby runnerů běží s hostNetwork, soketem Dockeru hostitele, NET_ADMIN a jako root. Jmenný prostor, taint ani RBAC oprávnění Dockeru hostitele neodstraní, takže nejde o izolaci od správce VM ani o sandbox pro libovolný kód.
Jmenný prostor zákazníka
Každý registrovaný cíl používá nevýchozí jmenný prostor a AppProject (například tenant-demo nebo app-<id> pro každou aplikaci). Vytváří se jen Deployment jedné služby (automount tokenu ServiceAccount vypnut), Service NodePort a NetworkPolicy a volitelně PVC nebo Job migrace; Secrety se jen odkazují názvem (pull Secret a schválená DATABASE_URL), nikdy se nevytvářejí.
Vstup AWS
Route 53 Alias → sdílený ALB HTTPS 443 → soukromá adresa uzlu zákazníka a NodePort. Mnoho aplikací sdílí jeden uzel, každá s vlastním jmenným prostorem, Application a NodePort.
Vstup GCP
Globální EXTERNAL_MANAGED HTTPS LB → zónová GCE_VM_IP_PORT NEG → soukromý NodePort existující VM. Certifikáty pocházejí z Certificate Manager s autorizací DNS. Modul nevlastní VM ani VPC a jedna VM zůstává jediným bodem selhání.
Vstup OpenStack
Listener TLS Amphora 443 s politikami L7 pro Host a cestu → HTTP NodePort. Výchozí adresou je soukromá VIP; Octavia, K3s, databáze a DNS jsou mimo modul. Veřejná dosažitelnost a připravenost Amphory na místě vyžadují samostatné převzetí a žádné nasazení na místě zatím tímto modulem ověřeno nebylo.
Mezi poskytovateli
Tři vstupy jsou samostatné implementace, bez automatického failoveru či replikace mezi poskytovateli. Cluster zákaznické aplikace je příkladem registrovaného cíle, nikoli tvrzením, že totéž nasazení běží současně v každém cloudu.
Volby operátora
Osobní brána (WireGuard) se k platformě připojí jen tehdy, když operátor zapne --personal; pro zákaznické cloudy není povinnou cestou. V podporovaném režimu direct může pozorovací VM sdílet provozní řídicí VM.