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ä.
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.
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.
tuote-API · cd.js → bridge.py
railshot-systemsuoritus · toimeenpano: workflow_dispatchloop job · self-hosted runnerrailshot-deploy.ymlTuote-API pyytää GitHub Actions -ajoa arvoilla tenant, app, lähdecommit ja kohde. API ei koskaan kutsu runner-Jobia suoraan.
build controller · CronJob
railshot-systemsuoritus · toimeenpano: runner-Jobien täydennysrunner Job · hostNetwork · Docker socketrailshot-buildKoontiohjaimen 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ä.
runner Job · hostNetwork · Docker socket
railshot-buildsuoritus · toimeenpano: työn vastaanottoloop job · self-hosted runnerrailshot-deploy.ymlbuild-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.
runner Job · hostNetwork · Docker socket
railshot-builddata: testattu pakettirelease job · GitHub-hostedrailshot-deploy.ymlLoop-job jättää samat tarkistukset läpäisseen paketin, ja release-job ottaa vain sen paketin.
release job · GitHub-hosted
railshot-deploy.ymldata: julkaisu tiivisteelläGHCRGitHubin 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.
tuote-API · cd.js → bridge.py
railshot-systemdata: workload commit · pushconfig Git -repositoriocd.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.
config Git -repositoriodata: revisionArgo CD · Application
argocdApplication lukee vain rajattua config-repositoriotaan, polkuaan ja revisiotaan.
tuote-API · cd.js → bridge.py
railshot-systemsuoritus · toimeenpano: Application syncArgo CD · ApplicationargocdNimetty 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ä.
Argo CD · Application
argocdsuoritus · 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.
Deployment · Pod · levykuva tiivisteellä
<app namespace>data: haku tiivisteelläGHCRJulkaistu 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.
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.
Toimittajan L7-sisääntulodata: NodePortNodePort Service · Local
<app namespace>Sisääntulo välittää solmun yksityiseen osoitteeseen ja NodePortiin. NodePort on kohteen rekisteröinnissä varattu.
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.
Cilium · Helm · VXLAN
kube-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.
Railshotin käyttäjädata: kojelauta · APIdashboard · nginx
railshot-systemKä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ä.
tuote-API · cd.js → bridge.py
railshot-systemhavainnointi: revisio · health · levykuvatArgo CD · ApplicationargocdDeployed 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.
tuote-API · cd.js → bridge.py
railshot-systemhavainnointi: julkinen HTTPS-tarkistusToimittajan L7-sisääntuloRekisteröity julkinen URL tarkistetaan ilman uudelleenohjauksia. Succeeded kirjataan vain, kun sekä Argon tuomio että tämä tarkistus ovat olemassa.
tuote-API · cd.js → bridge.py
railshot-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.
tuote-API · cd.js → bridge.py
railshot-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.
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.
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.
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.
Operaattorin bootstrapsuoritus · toimeenpano: rekisteröinnin bootstrapAppProject · cluster Secret
argocdOperaattori 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.
Operaattorin bootstrapsuoritus · toimeenpano: K3s:n · Ciliumin asennusCilium · Helm · VXLAN
kube-systeminstall-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).
uusimis-CronJob · 2 h välein
argocdsuoritus · 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.