HU
RAILSHOT.
Vissza a terembe

Railshot

AI deployment & operations platform

Helyben készült webalkalmazás telepítése előkészített felhős és helyszíni környezetekbe, majd üzemeltetése.

AI-alapú telepítési és üzemeltetési platform, amely a helyben készült webalkalmazást előkészített felhős vagy helyszíni környezetekbe viszi, és tovább üzemelteti.

2026. szeptember 28. – 2026. október 4. · Lezárult

Csapatprojekt · saját feladatom: CI tervezése és megvalósítása, CSP-klaszterek és Ansible-interfész, üzemeltetés, csapaton belüli kódfelülvizsgálat és integráció

SoftBank Hackathon 2026 powered by KOREC & ProgateA selejtező résztvevője · a döntőbe jutók kihirdetése 2026. október 26-án várható (2026. október 7-i állapot)

  • Webes felületMegvalósítva · hackathon
  • MCP-szerverMegvalósítva · távoli · helyi

Az üzemeltetési és az ügyfélalkalmazás-klaszterek elkülönülnek, a nyilvános útvonal pedig a telepítésvezérléstől külön marad.

Az üzemeltetési K3s-ben az irányítópult, a termék-API és a build controller platformszerepű csomópontokon, a runner Jobok pedig egy buildszerepű csomóponton futnak, a telepítést az Argo CD végzi. Az ügyfélalkalmazások minden regisztrált célhoz külön egycsomópontos K3s + Cilium klaszter kijelölt namespace-ében futnak.

Klasztertérkép · a nyilvános 645e28a commit deklarációi és kódja alapján
A Railshot üzemeltetési és ügyfélklaszter-térképeAz üzemeltetési K3s-klaszter és egy regisztrált ügyfélalkalmazás-klaszter. Az üzemeltetési klaszterben a railshot-system namespace az irányítópultot, a termék-API-t, a távoli MCP-t (csak ha a konténerképe rendelkezésre áll) és a build controllert platformszerepű csomópontokra helyezi; a railshot-build namespace runner Jobjai a taint-tel ellátott buildszerepű csomóponton veszik át a GitHub Actions jobokat. Egy GitHub által hosztolt release job a tesztelt csomagot a GHCR-be publikálja. A termék-API a munkaterhelést a config Gitbe commitolja, és szinkronizál egy Applicationt az argocd namespace-ben, az Argo CD pedig Deploymentet, NodePort Service-t és NetworkPolicyt alkalmaz az ügyfélklaszterben regisztrált namespace-re. Az alkalmazáskérések egy szolgáltatói L7-belépési ponton át érkeznek a csomópont NodePortjára és Service-ére, majd az alkalmazás Podjára. A telepítési ítélet kizárólag az Argo-állapoton és a nyilvános URL ellenőrzésén alapul; a Pod-diagnosztika, a naplók és a metrikák külön jelekként olvasandók. Az üzemeltető telepítési és regisztrációs bemenetei elkülönülnek a tenant alkalmazás payloadjától.Railshot-felhasználóirányítópult · MCPÜzemeltetői bootstraptelepítés · regisztráció · SecretGHCRdigest szerinti konténerképekconfig Git-tárolóworkload.json · revisionSzolgáltatói L7-belépési pontALB · GCP LB · AmphoraAlkalmazásfelhasználónyilvános HTTPSMegfigyelő VMaz ügyfél-K3s-en kívül · Composerailshot-systemdashboard · nginxtávoli MCP · csak konténerképpelbuild controller · CronJobtermék-API · cd.js → bridge.pyargocdArgo CD · ApplicationAppProject · cluster Secretmegújító CronJob · 2 óránkéntrailshot-buildrunner Job · hostNetwork · Docker socketrailshot-deploy.ymlloop job · self-hosted runnerrelease job · GitHub-hosted<app namespace>Deployment · Pod · digest konténerképNodePort Service · LocalNetworkPolicy · csak a felsorolt CIDR-ekrailshot-argocd SA · tokenkube-systemCilium · Helm · VXLANrailshot-observabilitynode-exporterkube-state-metricsÜzemeltetési klaszter · K3sAWS · szerepalapú csomópontokplatformszerepű csomópontoknodeSelectorbuildszerepű csomópontNoSchedule taintGitHubActions · GHCRÜgyfélalkalmazás-klaszter · példaregisztrált célonként egyEgy K3s-csomópont · serverCilium · a kube-proxy megmarad1workflow_dispatch2runner Job pótlása3a job átvétele4tesztelt csomag5 közzététel digest szerint · release job · GitHub-hosted → GHCR51workload commit · push2revision3 Application sync · termék-API · cd.js → bridge.py → Argo CD · Application34alkalmazás a namespace-re5letöltés digest szerint1HTTPS 4432NodePort3 a Podhoz · NodePort Service · Local → Deployment · Pod · digest konténerkép34 szabályzat érvényesítése · Cilium · Helm · VXLAN → NetworkPolicy · csak a felsorolt CIDR-ek45 irányítópult · API · Railshot-felhasználó → dashboard · nginx51 revízió · health · konténerképek · termék-API · cd.js → bridge.py → Argo CD · Application12nyilvános HTTPS-ellenőrzés3Pod-diagnosztika · nem az ítélet4naplóvég · Podonként 100 sor5scrape · NodePortok6Blackbox probe1platform renderelése · Secret2regisztrációs bootstrap3K3s · Cilium telepítése4TokenRequest · 6 h

Build → konténerkép közzététele

A termék-API GitHub Actions-futtatást kér, a build-csomóponton futó runner pedig átveszi és ellenőrzi a jobot. Csak az ugyanazokon az ellenőrzéseken átment csomagot publikálja egy GitHub által hosztolt release job a GHCR-be.

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

    A termék-API tenant, app, source commit és cél megadásával kér GitHub Actions-futtatást. Az API soha nem hív közvetlenül runner Jobot.

  2. build controller · CronJobrailshot-systemrunner Job pótlásarunner Job · hostNetwork · Docker socketrailshot-build

    A build controller CronJob (percenként, egy platformcsomóponton) runner Jobokat hoz létre a railshot-build namespace-ben. Role-ja csak a Jobok get, list és create műveletét, valamint az egyetlen runner-regisztrációs Secret get, update és patch műveletét engedi; namespace-eket vagy más Secreteket nem hozhat létre.

  3. runner Job · hostNetwork · Docker socketrailshot-builda job átvételeloop job · self-hosted runnerrailshot-deploy.yml

    A buildszerepű csomóponton (pontos hostname, NoSchedule toleration) futó runner a self-hosted címkéi alapján átveszi és futtatja a loop jobot. Az ügyfél forráskódja a meglévő korlátozott Docker build- és ellenőrző konténerekben fut.

  4. runner Job · hostNetwork · Docker socketrailshot-buildtesztelt csomagrelease job · GitHub-hostedrailshot-deploy.yml

    A loop job hátrahagyja az ugyanazokon az ellenőrzéseken átment csomagot, a release job pedig csak ezt a csomagot veszi át.

  5. release job · GitHub-hostedrailshot-deploy.ymlközzététel digest szerintGHCR

    Egy GitHub által hosztolt release job (ubuntu-24.04) újraépítés nélkül publikálja a tesztelt csomag konténerképét a GHCR-be. Konténerkép-közzététel soha nem történik az ügyfélalkalmazás-klaszteren belül.

Config Git → Argo → ügyfél-namespace

A config Git a kívánt erőforrásokat, a GHCR a konténerkép bájtjait hordozza. Az Argo CD csak a regisztrált ügyfél-namespace-re alkalmaz.

  1. termék-API · cd.js → bridge.pyrailshot-systemworkload commit · pushconfig Git-tároló

    A cd.js futtatja a bridge.py-t, amely csak akkor commitolja és pusholja a workload.json-t, ha a közzétételi feljegyzés és a regisztrált cél egyezik, majd visszaolvassa a távoli revíziót. A Git a kívánt erőforrásokat, a GHCR a konténerkép bájtjait hordozza.

  2. config Git-tárolórevisionArgo CD · Applicationargocd

    Az Application csak a korlátozott config-tárolóját, útvonalát és revízióját olvassa.

  3. termék-API · cd.js → bridge.pyrailshot-systemApplication syncArgo CD · Applicationargocd

    A megnevezett Applicationt server-side applyjal állítja be, és egyetlen pontos revízió szinkronizálását kéri prune nélkül. A termék-API railshot-product ServiceAccountja egyszerre birtokolja az üzemeltető által telepített regisztrációs bootstrapet (create a Secretekre, AppProjectekre és Applicationökre az argocd-ben; get, update és escalate a megnevezett Role-okra), valamint minden ellenőrzött célhoz pontos név szerint hozzáfűzött get- és patch-jogosultságot. A Kubernetes create művelete név szerint nem korlátozható, ezért a nevek hatókörben tartását a termék bemeneti validálása is biztosítja.

  4. Argo CD · Applicationargocdalkalmazás a namespace-re<app namespace>

    Az Argo CD a regisztrált klaszter-Secret hitelesítő adatával alkalmaz az ügyfélklaszter kijelölt namespace-ére. Az AppProject csak namespace-szintű típusokat enged, klaszterszintű erőforrásokat nem.

  5. Deployment · Pod · digest konténerkép<app namespace>letöltés digest szerintGHCR

    A közzétett digest szerinti konténerképet egy ugyanabban a namespace-ben név szerint hivatkozott pull Secrettel tölti le. Secret-értékek soha nem kerülnek az artefaktumba vagy a config Gitbe.

Nyilvános kérésútvonal

Az alkalmazáskérések útja: szolgáltatói L7-belépési pont → csomópont NodePort → Service → alkalmazás-Pod. A Cilium szabályzat-érvényesítése külön vezérlés, nem a kérést továbbító lépés. Az üzemeltetési irányítópultra vezető út külön útvonal.

  1. AlkalmazásfelhasználóHTTPS 443Szolgáltatói L7-belépési pont

    Az alkalmazás felhasználói a regisztrált hostnéven érik el a szolgáltató L7-belépési pontját. Minden szolgáltató a saját belépési pontját valósítja meg.

  2. Szolgáltatói L7-belépési pontNodePortNodePort Service · Local<app namespace>

    A belépési pont a csomópont privát címére és NodePortjára továbbít. A NodePort a cél regisztrálásakor kiosztott érték.

  3. NodePort Service · Local<app namespace>a PodhozDeployment · Pod · digest konténerkép<app namespace>

    A Service ugyanazon a csomóponton lévő alkalmazás-Podhoz (Deployment) küldi a kérést. externalTrafficPolicy Local mellett a forráscím változatlanul jut el a NetworkPolicy regisztrált CIDR-eket vizsgáló ellenőrzéséhez.

  4. Cilium · Helm · VXLANkube-systemszabályzat érvényesítéseNetworkPolicy · csak a felsorolt CIDR-ek<app namespace>

    A Cilium érvényesíti a NetworkPolicyt: bejövő forgalom csak a regisztrált CIDR-ekből az alkalmazás portjára; kimenő forgalom alapból nincs, kivéve egy jóváhagyott adatbáziscímet. A felhőalapú tűzfalak és a hosztszabályok továbbra is számítanak.

  5. Railshot-felhasználóirányítópult · APIdashboard · nginxrailshot-system

    A felhasználók az üzemeltetési belépési ponton át érkeznek az nginx-irányítópultra, az nginx pedig a termék-API előtt áll. Az irányítópult Service-e csak jóváhagyott node port megadása esetén NodePort; az API ClusterIP marad.

Ellenőrzés · megfigyelés

A telepítési ítélet kizárólag az Argo-állapoton és a nyilvános URL ellenőrzésén alapul. A Pod-diagnosztika, az aktuális naplók és az üzemeltetési metrikák külön jelek, amelyek soha nem változtatják meg.

  1. termék-API · cd.js → bridge.pyrailshot-systemrevízió · health · konténerképekArgo CD · Applicationargocd

    A deployed állapothoz kell az Application sync-revíziója, a Synced és Healthy állapot, az operation Succeeded, és az, hogy az Argo Application állapotában rögzített konténerkép-hivatkozások egyezzenek a felülvizsgált Deployment digest szerinti konténerképeivel. Ez nem közvetlen Pod-imageID-kapu, és önmagában a zöld Argo-állapot nem igazolja az egyezést.

  2. termék-API · cd.js → bridge.pyrailshot-systemnyilvános HTTPS-ellenőrzésSzolgáltatói L7-belépési pont

    A regisztrált nyilvános URL ellenőrzése átirányítások nélkül történik. Succeeded csak az Argo-ítélettel és ezzel az ellenőrzéssel együtt rögzül.

  3. termék-API · cd.js → bridge.pyrailshot-systemPod-diagnosztika · nem az ítéletDeployment · Pod · digest konténerkép<app namespace>

    Az Argo-ítélet és a nyilvános ellenőrzés után a Deploymentet, a ReplicaSeteket és a Podokat a regisztrált hitelesítő adattal külön olvassa, és az imageID-t és a készenlétet ready, progressing vagy unavailable diagnosztikaként fűzi hozzá. Egy sikertelen vagy eltérő diagnosztika soha nem módosítja a deployed vagy succeeded ítéletet.

  4. termék-API · cd.js → bridge.pyrailshot-systemnaplóvég · Podonként 100 sorDeployment · Pod · digest konténerkép<app namespace>

    Csak az éppen telepített műveletre, a megbízható konfigurációval és a regisztrált hitelesítő adattal. Minden aktuális Podnál (legfeljebb háromnál) a futó konténerkép digestjének egyeznie kell a várt digesttel; ezután Podonként legfeljebb 100 kitakart sort olvas bájtkorláton belül. Egy régebbi kísérletre superseded, konfiguráció nélkül not_configured a válasz. Ez nem naplóaggregáció.

  5. Megfigyelő VMscrape · NodePortokrailshot-observability

    A megfigyelő VM-en futó Prometheus két, tűzfallal korlátozott NodePorton át gyűjti a node-exporter és a kube-state-metrics adatait. A hiányzó vagy elavult érték ismeretlen, nem nulla.

  6. Megfigyelő VMBlackbox probeSzolgáltatói L7-belépési pont

    A probe_success=1 azt jelenti, hogy az adott próbahelyen 2xx válasz érkezett. Nem bizonyítja sem minden felhasználó hozzáférését, sem a telepített verziót, és soha nem lépteti elő a published állapotot deployeddá.

Üzemeltetői telepítés · regisztráció

A klasztertelepítés, a regisztrációs bootstrap és a célbemenetek, a Secretek és a hitelesítőadat-megújítás beállítása üzemeltetői bemenetek, soha nem részei a tenant alkalmazás payloadjának.

  1. Üzemeltetői bootstrapplatform renderelése · Secretrailshot-system

    Az üzemeltető a render-platform.py-jal rendereli a platformdeklarációt, és megadja a nem nyilvános üzemeltetési konfigurációt és Secreteket. A távoli MCP csak akkor kerül bele, ha a konténerképe rendelkezésre áll, a személyes gateway (WireGuard) pedig csak --personal esetén.

  2. Üzemeltetői bootstrapregisztrációs bootstrapAppProject · cluster Secretargocd

    Az üzemeltető telepíti az argocd-be a regisztrációs bootstrap Role-t és egy üres registrations Role-t, és előkészíti a célbemeneteket. Ezután a termék-API által futtatott regisztrációs segédek (environment.py, applications.py) hatókörhöz kötött hitelesítő adattal megírják a railshot-<target> Secretet (clusterResources false, felsorolt engedélyezett namespace-ek), és az ellenőrzött pontos neveket hozzáfűzik a registrations Role-hoz. Az alkalmazásonkénti regisztráció egy app-<id> namespace-t azonos nevű AppProjecthez köt.

  3. Üzemeltetői bootstrapK3s · Cilium telepítéseCilium · Helm · VXLANkube-system

    Az install-k3s.sh egycsomópontos K3s servert telepít (flannel, network policy, traefik és servicelb kikapcsolva; kube-proxy megtartva), a Cilium pedig Helm-releaseként települ (kubeProxyReplacement false, VXLAN, Hubble kikapcsolva).

  4. megújító CronJob · 2 óránkéntargocdTokenRequest · 6 hrailshot-argocd SA · token<app namespace>

    A railshot-credentials CronJob kétóránként új, hatórás tokent kér az ügyfél SA-jához. Az ügyféloldali Role csak a saját SA-ja token create műveletét engedi. A hat óra egyetlen token TTL-je, nem az üzemeltetői hozzáférés vége.

Minden kapcsolat azonos vastagsággal. Válasszon egy folyamatot, hogy csak annak útvonala emelődjön ki, számozott lépésekkel.

  • Folytonos · a kérések, csomagok, konténerképek és deklarációk áramlási iránya
  • Szaggatott · futtatási kérések, alkalmazás, telepítés, hitelesítő adatok
  • Hosszú pontvonalas · állapot, naplók, próbák, metrikák olvasása; az ítélettől elkülönítve
  • Vastag fekete vonal · a kiválasztott folyamat; a számok a sorrendet jelzik
  • Doboz · egy namespace, fejlécében a nevével (nem csomópont)
  • Belső chip · komponens a namespace-ben
  • Szaggatott doboz · a klasztereken kívül
  • railshot-system · termék
  • argocd · telepítési jogkör
  • railshot-build · hoszt-Docker-jogkör
  • GitHub · ügyfélklaszter

A docs/architecture október 2-i elhelyezési döntése (két szerepcsomópont) és a nyilvános README ábrája előzmény; ez a térkép a 645e28a deklarációit és kódját követi. A nyilak okot és irányt jelölnek, nem bizonyítják, hogy minden szolgáltatói útvonal most éles.

Namespace-ek és csomópontok
A namespace névtartomány: nem hardver, és önmagában nem is biztonsági határ. A platform- és buildszerep nodeSelectorral és tainttel megadott ütemezési elhelyezés; ez a térkép nem rögzíti az üzemeltetési klaszter csomópontszámát. Az Argo CD csomóponti elhelyezése szintén külön ellenőrizendő.
A build-csomópont jogköre
A runner Jobok hostNetworkkel, a hoszt Docker-socketjével, NET_ADMIN-nal és rootként futnak. Namespace, taint vagy RBAC nem szünteti meg a hoszt-Docker-jogkört, így ez sem VM-adminisztrátori elszigetelés, sem tetszőleges kódhoz való sandbox.
Ügyfél-namespace
Minden regisztrált cél nem alapértelmezett namespace-t és AppProjectet használ (például tenant-demo, vagy alkalmazásonként app-<id>). Csak egyetlen szolgáltatás Deploymentje (a ServiceAccount-token automatikus csatolása kikapcsolva), NodePort Service-e és NetworkPolicyja, valamint egy opcionális PVC vagy migrációs Job jön létre; a Secretekre csak név szerint hivatkozik (a pull Secret és egy jóváhagyott DATABASE_URL), soha nem hozza létre őket.
AWS-belépési pont
Route 53 Alias → közös ALB HTTPS 443 → az ügyfélcsomópont privát címe és NodePortja. Több alkalmazás is ugyanazt a csomópontot használja, mindegyik saját namespace-szel, Applicationnel és NodePorttal.
GCP-belépési pont
Globális EXTERNAL_MANAGED HTTPS LB → zonális GCE_VM_IP_PORT NEG → a meglévő VM privát NodePortja. A tanúsítványok a Certificate Managerből származnak DNS-engedélyezéssel. A modul sem a VM-et, sem a VPC-t nem birtokolja, és egyetlen VM egyetlen hibapont marad.
OpenStack-belépési pont
Amphora TLS-listener 443 Host- és útvonalalapú L7-szabályokkal → HTTP NodePort. Az alapértelmezett cím privát VIP; az Octavia, a K3s, az adatbázis és a DNS a modulon kívül esik. A nyilvános elérhetőség és a helyszíni Amphora-készenlét külön átvételt igényel, és helyszíni alkalmazást ezzel a modullal még nem igazoltak.
Szolgáltatók között
A három belépési pont különálló megvalósítás, a szolgáltatók között nincs automatikus failover vagy replikáció. Az ügyfélalkalmazás-klaszter egy regisztrált cél példája, nem állítás arról, hogy ugyanaz a telepítés egyszerre fut minden felhőn.
Üzemeltetői beállítások
A személyes gateway (WireGuard) csak akkor csatlakozik a platformhoz, ha az üzemeltető bekapcsolja a --personal kapcsolót; az ügyfélfelhők számára nem kötelező útvonal. A támogatott direct módban a megfigyelő VM osztozhat az üzemeltetési vezérlő VM-en.