RAILSHOT.
Takaisin saliin

Railshot

AI deployment & operations platform

Paikallisesti rakennettu verkkosovellus käyttöön valmisteltuihin pilvi- ja on-premises-ympäristöihin ja ylläpitoon.

AI-pohjainen käyttöönotto- ja ylläpitoalusta, joka vie paikallisesti rakennetun verkkosovelluksen valmisteltuihin pilvi- tai on-premises-ympäristöihin ja pitää sen käynnissä.

28.9.2026–4.10.2026 · Päättynyt

Tiimiprojekti · oma osuuteni: CI:n suunnittelu ja toteutus, CSP-klusterit ja Ansible-rajapinta, ylläpito, tiimin koodikatselmointi ja integrointi

SoftBank Hackathon 2026 powered by KOREC & ProgateAlkukierroksen osallistuja · finaaliin valitut julkistetaan 26.10.2026 (tilanne 7.10.2026)

  • VerkkoToteutettu · hackathon-versio
  • MCP-palvelinToteutettu · etä · paikallinen

Ylläpito- ja asiakassovellusklusterit ovat erillään, ja julkinen polku pidetään erillään käyttöönoton ohjauksesta.

Ylläpidon K3s:ssä kojelauta, tuote-API ja koontiohjain sijoitetaan platform-roolin solmuille ja runner-Jobit build-roolin solmulle, ja Argo CD hoitaa käyttöönoton. Asiakassovellukset toimivat nimetyssä nimiavaruudessa erillisessä yhden solmun K3s + Cilium -klusterissa kutakin rekisteröityä kohdetta kohden.

Klusterikartta · piirretty julkisen commitin 645e28a määrittelyistä ja koodista
Railshotin ylläpito- ja asiakasklusterien karttaYlläpidon K3s-klusteri ja rekisteröity asiakassovellusklusteri. Ylläpitoklusterissa railshot-system-nimiavaruus sijoittaa kojelaudan, tuote-API:n, etä-MCP:n (vain kun sen levykuva annetaan) ja koontiohjaimen platform-roolin solmuille; railshot-build-nimiavaruuden runner-Jobit ottavat GitHub Actions -töitä taintatulla build-roolin solmulla. GitHubin isännöimä release-job julkaisee testatun paketin GHCR:ään. Tuote-API commitoi työkuorman config Gitiin ja synkronoi Applicationin argocd-nimiavaruudessa, ja Argo CD toimeenpanee Deploymentin, NodePort Servicen ja NetworkPolicyn asiakasklusteriin rekisteröityyn nimiavaruuteen. Sovelluspyynnöt saapuvat toimittajan L7-sisääntulosta solmun NodePortiin ja Serviceen ja sitten sovelluksen Podiin. Käyttöönoton tuomio perustuu vain Argon tilaan ja julkisen URL:n tarkistukseen; Pod-diagnostiikka, lokit ja mittarit luetaan erillisinä signaaleina. Operaattorin asennus- ja rekisteröintisyötteet pidetään erillään asiakassovelluksen hyötykuormasta.Railshotin käyttäjäkojelauta · MCPOperaattorin bootstrapasennus · rekisteröinti · SecretGHCRlevykuvat tiivisteelläconfig Git -repositorioworkload.json · revisionToimittajan L7-sisääntuloALB · GCP LB · AmphoraSovelluksen käyttäjäjulkinen HTTPSHavainnointi-VMasiakkaan K3s:n ulkopuolella · Composerailshot-systemdashboard · nginxetä-MCP · vain levykuvan kanssabuild controller · CronJobtuote-API · cd.js → bridge.pyargocdArgo CD · ApplicationAppProject · cluster Secretuusimis-CronJob · 2 h väleinrailshot-buildrunner Job · hostNetwork · Docker socketrailshot-deploy.ymlloop job · self-hosted runnerrelease job · GitHub-hosted<app namespace>Deployment · Pod · levykuva tiivisteelläNodePort Service · LocalNetworkPolicy · luetellut CIDR:trailshot-argocd SA · tokenkube-systemCilium · Helm · VXLANrailshot-observabilitynode-exporterkube-state-metricsYlläpitoklusteri · K3sAWS · roolisolmutplatform-roolin solmutnodeSelectorbuild-roolin solmuNoSchedule taintGitHubActions · GHCRAsiakassovellusklusteri · esimerkkiyksi kutakin rekisteröityä kohdetta kohdenYksi K3s-solmu · serverCilium · kube-proxy säilytetty1workflow_dispatch2runner-Jobien täydennys3työn vastaanotto4testattu paketti5 julkaisu tiivisteellä · release job · GitHub-hosted → GHCR51workload commit · push2revision3 Application sync · tuote-API · cd.js → bridge.py → Argo CD · Application34toimeenpano nimiavaruuteen5haku tiivisteellä1HTTPS 4432NodePort3 Podiin · NodePort Service · Local → Deployment · Pod · levykuva tiivisteellä34 käytännön valvonta · Cilium · Helm · VXLAN → NetworkPolicy · luetellut CIDR:t45 kojelauta · API · Railshotin käyttäjä → dashboard · nginx51 revisio · health · levykuvat · tuote-API · cd.js → bridge.py → Argo CD · Application12julkinen HTTPS-tarkistus3Pod-diagnostiikka · ei tuomio4lokin tail · 100 riviä Podia kohden5scrape · NodePortit6Blackbox probe1platformin renderöinti · Secret2rekisteröinnin bootstrap3K3s:n · Ciliumin asennus4TokenRequest · 6 h

Koonti → levykuvan julkaisu

Tuote-API pyytää GitHub Actions -ajoa, ja build-solmun runner ottaa ja tarkistaa työn. Vain samat tarkistukset läpäissyt paketti julkaistaan GHCR:ään GitHubin isännöimällä release-jobilla.

  1. tuote-API · cd.js → bridge.pyrailshot-systemsuoritus · toimeenpano: workflow_dispatchloop job · self-hosted runnerrailshot-deploy.yml

    Tuote-API pyytää GitHub Actions -ajoa arvoilla tenant, app, lähdecommit ja kohde. API ei koskaan kutsu runner-Jobia suoraan.

  2. build controller · CronJobrailshot-systemsuoritus · toimeenpano: runner-Jobien täydennysrunner Job · hostNetwork · Docker socketrailshot-build

    Koontiohjaimen CronJob (minuutin välein, platform-solmulla) luo runner-Jobeja railshot-build-nimiavaruuteen. Sen Role sallii vain Jobien get, list ja create sekä get, update ja patch yhdelle runner-rekisteröinnin Secretille; se ei voi luoda nimiavaruuksia eikä muita Secretejä.

  3. runner Job · hostNetwork · Docker socketrailshot-buildsuoritus · toimeenpano: työn vastaanottoloop job · self-hosted runnerrailshot-deploy.yml

    build-roolin solmun runner (tarkka hostname, NoSchedule-toleraatio) ottaa loop-jobin self-hosted-tunnisteidensa perusteella ja ajaa sen. Asiakkaan lähdekoodi ajetaan olemassa olevissa rajoitetuissa Docker-koonti- ja tarkistuskonteissa.

  4. runner Job · hostNetwork · Docker socketrailshot-builddata: testattu pakettirelease job · GitHub-hostedrailshot-deploy.yml

    Loop-job jättää samat tarkistukset läpäisseen paketin, ja release-job ottaa vain sen paketin.

  5. release job · GitHub-hostedrailshot-deploy.ymldata: julkaisu tiivisteelläGHCR

    GitHubin isännöimä release-job (ubuntu-24.04) julkaisee testatun paketin levykuvan GHCR:ään rakentamatta sitä uudelleen. Levykuvien julkaisu ei koskaan tapahdu asiakassovellusklusterin sisällä.

Config Git → Argo → asiakkaan nimiavaruus

Config Git kantaa halutut resurssit ja GHCR levykuvan tavut. Argo CD toimeenpanee vain rekisteröityyn asiakasnimiavaruuteen.

  1. tuote-API · cd.js → bridge.pyrailshot-systemdata: workload commit · pushconfig Git -repositorio

    cd.js ajaa bridge.py:n, joka commitoi ja pushaa workload.jsonin vain, kun julkaisukirjaus ja rekisteröity kohde täsmäävät, ja lukee sitten etärevision takaisin. Git kantaa halutut resurssit; GHCR kantaa levykuvan tavut.

  2. config Git -repositoriodata: revisionArgo CD · Applicationargocd

    Application lukee vain rajattua config-repositoriotaan, polkuaan ja revisiotaan.

  3. tuote-API · cd.js → bridge.pyrailshot-systemsuoritus · toimeenpano: Application syncArgo CD · Applicationargocd

    Nimetty Application asetetaan server-side applylla, ja yhden tarkan revision synkronointia pyydetään ilman prunea. Tuote-API:n railshot-product-ServiceAccountilla on sekä operaattorin asentama rekisteröinnin bootstrap (create Secreteille, AppProjecteille ja Applicationeille argocd-nimiavaruudessa; get, update ja escalate nimetyille Roleille) että get- ja patch-oikeudet, jotka lisätään tarkalla nimellä kullekin validoidulle kohteelle. Kubernetesin createa ei voi rajata nimellä, joten myös tuotteen syötteen validointi pitää nimet laajuuden sisällä.

  4. Argo CD · Applicationargocdsuoritus · toimeenpano: toimeenpano nimiavaruuteen<app namespace>

    Argo CD toimeenpanee asiakasklusterin nimettyyn nimiavaruuteen rekisteröidyn klusteri-Secretin tunnistetiedolla. AppProject sallii vain nimiavaruuskohtaiset tyypit eikä klusterin laajuisia resursseja.

  5. Deployment · Pod · levykuva tiivisteellä<app namespace>data: haku tiivisteelläGHCR

    Julkaistu levykuva haetaan tiivisteellä samassa nimiavaruudessa nimellä viitatulla pull-Secretillä. Secret-arvot eivät koskaan päädy artefaktiin tai config Gitiin.

Julkinen pyyntöpolku

Sovelluspyynnöt kulkevat reittiä toimittajan L7-sisääntulo → solmun NodePort → Service → sovellus-Pod. Ciliumin käytännön valvonta on erillinen ohjaus, ei pyyntöä kuljettava vaihe. Pääsy ylläpidon kojelautaan on erillinen polku.

  1. Sovelluksen käyttäjädata: HTTPS 443Toimittajan L7-sisääntulo

    Sovelluksen käyttäjät saapuvat toimittajan L7-sisääntuloon rekisteröidyllä isäntänimellä. Kukin toimittaja toteuttaa oman sisääntulonsa.

  2. Toimittajan L7-sisääntulodata: NodePortNodePort Service · Local<app namespace>

    Sisääntulo välittää solmun yksityiseen osoitteeseen ja NodePortiin. NodePort on kohteen rekisteröinnissä varattu.

  3. NodePort Service · Local<app namespace>data: PodiinDeployment · Pod · levykuva tiivisteellä<app namespace>

    Service lähettää pyynnön saman solmun sovellus-Podiin (Deployment). Asetuksen externalTrafficPolicy Local ansiosta lähdeosoite saavuttaa NetworkPolicyn rekisteröityjen CIDR:ien tarkistuksen muuttumattomana.

  4. Cilium · Helm · VXLANkube-systemsuoritus · toimeenpano: käytännön valvontaNetworkPolicy · luetellut CIDR:t<app namespace>

    Cilium valvoo NetworkPolicya: sisääntuleva liikenne vain rekisteröidyistä CIDR:istä sovelluksen porttiin; lähtevää liikennettä ei oletuksena ole, lukuun ottamatta hyväksyttyä tietokantaosoitetta. Pilvipalomuurit ja isäntäsäännöt ovat silti tarpeen.

  5. Railshotin käyttäjädata: kojelauta · APIdashboard · nginxrailshot-system

    Käyttäjät tulevat ylläpidon sisääntulon kautta nginx-kojelautaan, ja nginx on tuote-API:n edustalla. Kojelaudan Service on NodePort vain, kun hyväksytty solmuportti annetaan; API pysyy ClusterIP:nä.

Todennus · havainnointi

Käyttöönoton tuomio perustuu vain Argon tilaan ja julkisen URL:n tarkistukseen. Pod-diagnostiikka, nykyiset lokit ja käyttömittarit ovat erillisiä signaaleja, jotka eivät koskaan muuta sitä.

  1. tuote-API · cd.js → bridge.pyrailshot-systemhavainnointi: revisio · health · levykuvatArgo CD · Applicationargocd

    Deployed edellyttää Applicationin synkronointirevisiota, tiloja Synced ja Healthy, operaatiota Succeeded sekä sitä, että Argo Applicationin tilaan kirjatut levykuvaviittaukset vastaavat katselmoidun Deploymentin tiivisteellisiä levykuvia. Kyse ei ole suorasta Podin imageID-portista, eikä vihreä Argo-tila yksin osoita vastaavuutta.

  2. tuote-API · cd.js → bridge.pyrailshot-systemhavainnointi: julkinen HTTPS-tarkistusToimittajan L7-sisääntulo

    Rekisteröity julkinen URL tarkistetaan ilman uudelleenohjauksia. Succeeded kirjataan vain, kun sekä Argon tuomio että tämä tarkistus ovat olemassa.

  3. tuote-API · cd.js → bridge.pyrailshot-systemhavainnointi: Pod-diagnostiikka · ei tuomioDeployment · Pod · levykuva tiivisteellä<app namespace>

    Argon tuomion ja julkisen tarkistuksen jälkeen Deployment, ReplicaSetit ja Podit luetaan erikseen rekisteröidyllä tunnistetiedolla, ja imageID ja valmius liitetään ready-, progressing- tai unavailable-diagnostiikkana. Epäonnistunut tai poikkeava diagnostiikka ei koskaan muuta deployed- tai succeeded-tuomiota.

  4. tuote-API · cd.js → bridge.pyrailshot-systemhavainnointi: lokin tail · 100 riviä Podia kohdenDeployment · Pod · levykuva tiivisteellä<app namespace>

    Vain parhaillaan käyttöön otetulle operaatiolle, luotetulla konfiguraatiolla ja rekisteröidyllä tunnistetiedolla. Kunkin nykyisen Podin (enintään kolme) käynnissä olevan levykuvan tiivisteen on vastattava odotettua tiivistettä; sitten Podia kohden luetaan enintään 100 peitettyä riviä tavurajan sisällä. Vanhempaan yritykseen vastataan superseded; ilman konfiguraatiota not_configured. Tämä ei ole lokien koostamista.

  5. Havainnointi-VMhavainnointi: scrape · NodePortitrailshot-observability

    Havainnointi-VM:n Prometheus kerää node-exporterin ja kube-state-metricsin kahden palomuurilla rajatun NodePortin kautta. Puuttuvat tai vanhentuneet arvot ovat tuntemattomia, eivät nollia.

  6. Havainnointi-VMhavainnointi: Blackbox probeToimittajan L7-sisääntulo

    probe_success=1 tarkoittaa 2xx-vastausta kyseisessä koetinsijainnissa. Se ei todista jokaisen käyttäjän pääsyä eikä käyttöön otettua versiota, eikä se koskaan nosta tilaa published tilaan deployed.

Operaattorin asennus · rekisteröinti

Klusterin asennus, rekisteröinnin bootstrap ja kohteen syötteet, Secretit ja tunnistetietojen uusimisen asetukset ovat operaattorin syötteitä, eivät koskaan osa asiakassovelluksen hyötykuormaa.

  1. Operaattorin bootstrapsuoritus · toimeenpano: platformin renderöinti · Secretrailshot-system

    Operaattori renderöi platform-määrittelyn render-platform.py:llä ja antaa yksityisen ylläpitokonfiguraation ja Secretit. Etä-MCP sisältyy vain, kun sen levykuva annetaan, ja henkilökohtainen yhdyskäytävä (WireGuard) vain valitsimella --personal.

  2. Operaattorin bootstrapsuoritus · toimeenpano: rekisteröinnin bootstrapAppProject · cluster Secretargocd

    Operaattori asentaa rekisteröinnin bootstrap-Rolen ja tyhjän rekisteröintien Rolen argocd-nimiavaruuteen ja valmistelee kohteen syötteet. Tuote-API:n ajamat rekisteröintiapuohjelmat (environment.py, applications.py) kirjoittavat sitten railshot-<target>-Secretin rajatulla tunnistetiedolla (clusterResources false, sallitut nimiavaruudet lueteltu) ja lisäävät validoidut tarkat nimet rekisteröintien Roleen. Sovelluskohtainen rekisteröinti sitoo app-<id>-nimiavaruuden samannimiseen AppProjectiin.

  3. Operaattorin bootstrapsuoritus · toimeenpano: K3s:n · Ciliumin asennusCilium · Helm · VXLANkube-system

    install-k3s.sh asentaa yhden solmun K3s-palvelimen (flannel, network policy, traefik ja servicelb pois; kube-proxy säilytetty), ja Cilium asennetaan Helm-releasena (kubeProxyReplacement false, VXLAN, Hubble pois).

  4. uusimis-CronJob · 2 h väleinargocdsuoritus · toimeenpano: TokenRequest · 6 hrailshot-argocd SA · token<app namespace>

    railshot-credentials-CronJob pyytää kahden tunnin välein asiakkaan SA:lle uuden kuuden tunnin tokenin. Asiakaspuolen Role sallii vain token create -toiminnon omalle SA:lleen. Kuusi tuntia on yhden tokenin TTL, ei hetki, jolloin operaattorin pääsy päättyy.

Kaikki yhteydet samalla painolla. Valitse virta, niin vain sen polku korostuu numeroiduin vaihein.

  • Yhtenäinen · pyyntöjen, pakettien, levykuvien ja määrittelyjen kulkusuunta
  • Katkoviiva · ajopyynnöt, toimeenpano, asennus, tunnistetiedot
  • Pitkä pistekatkoviiva · tilan, lokien, koettimien ja mittarien luku; erillään tuomiosta
  • Paksu musta viiva · valittu virta; numerot kertovat järjestyksen
  • Laatikko · nimiavaruus, nimi otsakkeessa (ei solmu)
  • Sisälaatta · komponentti tässä nimiavaruudessa
  • Katkoviivalaatikko · klusterien ulkopuolella
  • railshot-system · tuote
  • argocd · käyttöönoton valtuus
  • railshot-build · isännän Docker-valtuus
  • GitHub · asiakasklusteri

docs/architecture-hakemiston sijoittelupäätös lokakuun 2. päivältä (kaksi roolisolmua) ja julkisen README:n kaavio ovat historiaa; tämä kartta noudattaa commitin 645e28a määrittelyjä ja koodia. Nuolet näyttävät syyn ja suunnan, eivät todista, että jokainen toimittajapolku on nyt käytössä.

Nimiavaruudet ja solmut
Nimiavaruus on nimeämisalue: ei laitteisto eikä itsessään tietoturvaraja. Platform- ja build-roolit ovat nodeSelectorilla ja taintilla tehtyä aikataulutussijoittelua; tämä kartta ei kiinnitä ylläpitoklusterin solmumäärää. Myös Argo CD:n solmusijoittelu on erillinen tarkistus.
Build-solmun valtuudet
Runner-Jobit ajetaan hostNetworkilla, isännän Docker-socketilla, NET_ADMINilla ja rootina. Nimiavaruus, taint tai RBAC ei poista isännän Docker-valtuutta, joten tämä ei ole VM-ylläpitäjän eristys eikä hiekkalaatikko mielivaltaiselle koodille.
Asiakkaan nimiavaruus
Kukin rekisteröity kohde käyttää muuta kuin oletusnimiavaruutta ja AppProjectia (esimerkiksi tenant-demo tai sovelluskohtainen app-<id>). Luodaan vain yhden palvelun Deployment (ServiceAccount-tokenin automaattinen liittäminen pois), NodePort Service ja NetworkPolicy sekä valinnainen PVC tai migraatio-Job; Secreteihin vain viitataan nimellä (pull-Secret ja hyväksytty DATABASE_URL), niitä ei koskaan luoda.
AWS-sisääntulo
Route 53 Alias → jaettu ALB HTTPS 443 → asiakassolmun yksityinen osoite ja NodePort. Monet sovellukset käyttävät samaa solmua, kullakin oma nimiavaruus, Application ja NodePort.
GCP-sisääntulo
Globaali EXTERNAL_MANAGED HTTPS LB → vyöhykkeellinen GCE_VM_IP_PORT NEG → olemassa olevan VM:n yksityinen NodePort. Varmenteet tulevat Certificate Managerista DNS-valtuutuksella. Moduuli ei omista VM:ää eikä VPC:tä, ja yksi VM on edelleen yksittäinen vikaantumispiste.
OpenStack-sisääntulo
Amphora TLS -kuuntelija 443 Host- ja polku-L7-käytännöillä → HTTP NodePort. Oletusosoite on yksityinen VIP; Octavia, K3s, tietokanta ja DNS ovat moduulin ulkopuolella. Julkinen saavutettavuus ja paikan päällä olevan Amphoran valmius vaativat erillisen hyväksynnän, eikä paikan päällä tehtyä toimeenpanoa ole vielä todennettu tällä moduulilla.
Toimittajien välillä
Kolme sisääntuloa ovat erillisiä toteutuksia, eikä toimittajien välillä ole automaattista vikasietoa tai replikointia. Asiakassovellusklusteri on esimerkki rekisteröidystä kohteesta, ei väite, että sama käyttöönotto toimisi kaikissa pilvissä yhtä aikaa.
Operaattorin valinnat
Henkilökohtainen yhdyskäytävä (WireGuard) liittyy platformiin vain, kun operaattori ottaa käyttöön valitsimen --personal; se ei ole asiakaspilvien pakollinen polku. Tuetussa direct-tilassa havainnointi-VM voi jakaa ylläpidon ohjaus-VM:n.