Izolált teszt-példány

A teszt-példány a saját fizikai forrásgyökeréből futtatja a nyilvános életciklus-szkripteket. Csatolásai, tulajdonosi címkéi, inicializálói, konfigurációja és futásidejű állapota az adott másolathoz tartoznak. Az ECS_INSTANCE_ID shell-felülírása nem választja ki biztonságosan.

Először a teszt-setupban készítsd elő az útvonalakat és az előfeltételeket.

Rögzített teszt-bundle parancsok

Az eredeti projektgyökérből futtasd:

bash testInstance.sh prepare
bash testInstance.sh status
bash testInstance.sh start
bash testInstance.sh stop
bash testInstance.sh quick-start
bash testInstance.sh restart

A prepare forrás-snapshotot és konfigurációt hoz létre a szolgáltatások indítása nélkül. Megtagadja a meglévő vagy részleges snapshot automatikus cseréjét. Az új vagy módosított forrást fájlspecifikus --include-source RELATIVE_FILE jóváhagyással kell felvenni az előkészítés során. Az útvonal- és titokszűrők továbbra is érvényesek. A későbbi termékmódosítások nem kerülnek automatikusan a snapshotba.

Az életciklus-parancsok ellenőrzik a provenance (eredet) meglétét, a konfigurációt, a Docker-tulajdonjogot és az izolációs határokat. Az indításhoz gazdagépmemória- és kizárólagossági ellenőrzés is kell. Külön projektazonosító nem ad külön RAM-ot.

Csatlakozás a futó teszt-terminálokhoz

Az eredeti projektgyökérből csatlakozz a meglévő, futó teszt-terminálokhoz:

bash testServerAttach.sh

Ha csak a BFF szolgáltatáshoz csatlakozol, használd:

bash testServerAttach.sh bff

A helper a futó BFF konténerek alapján keresi meg a klóngyökeret az .agenttemp/ vagy a .docker-state/ alatt. Pontosan egy gyökérnek kell megfelelnie az ECS_TEST_INSTANCE=true vagy az ECS_PUBLIC_HOST_PREFIX=test beállításnak. Nulla vagy több találat esetén futtasd a bash devServerAttach.sh parancsot a célzott futtatókörnyezet saját gyökeréből.

Ezek a parancsok nem indítanak el és nem indítanak újra szolgáltatásokat. A tmuxról való leváláshoz nyomd meg a Ctrl+b, majd a d billentyűt. Közvetlen Docker-csatlakozásnál nyomd meg a Ctrl+p, majd a Ctrl+q billentyűkombinációt.

Deploymentből származtatott nyilvános originek

A nyilvános hosztnevek használhatják a forrás deployment nevét, miközben a teszt megtartja a saját futásidejű identitását. Az új teszt-előkészítés átveszi a forrásból az ECS_ORIGIN_DEPLOYMENT_ID értéket, vagy ha az hiányzik, az ECS_INSTANCE_ID értéket. Ezután beállítja az ECS_PUBLIC_HOST_PREFIX=test értéket az izolált futásidejű beállítások kiosztása előtt.

Ez a két opcionális selector vezérli a nyilvános neveket:

Változó	Fogyasztó	Cél	Típus vagy formátum	Kötelező ekkor	Alapértelmezés	Példa	Megkötések vagy biztonság
ECS_ORIGIN_DEPLOYMENT_ID	Runtime setup, Compose feloldás, proxy planner	Kiválasztja a deployment címkét a nyilvános hosztokban	Kisbetűs deployment címke, 1–40 karakter	Opcionális	ECS_INSTANCE_ID	ttrmb	Az első karakter betű vagy számjegy. A többi karakter kisbetű, számjegy vagy kötőjel. Nem módosítja a futásidejű tulajdonjogot.
ECS_PUBLIC_HOST_PREFIX	Runtime setup, Compose feloldás, proxy planner	Egy címkét ad minden nyilvános szolgáltatásnév elé	Üres vagy egy kisbetűs DNS-címke, legfeljebb 63 karakter	Opcionális	Üres	test	A csupasz test értéket használd, záró pont nélkül. A nem üres címke első és utolsó karaktere betű vagy számjegy.

Az URL-minta https://[prefix.]service.<origin-deployment>.<suffix>:<port>. A meglévő DEV_DOMAIN_SUFFIX és NPM_HTTPS_PORT adja a suffixet és a portot. Az alapértelmezett értékük ecas.local és 8443.

A ttrmb forrás deploymenttel, a test prefixszel és ezekkel az alapértelmezésekkel a nyolc származtatott beállítás:

Származtatott változó	Érték
MAILGEN_PUBLIC_URL	https://test.bff.ttrmb.ecas.local:8443
BETTER_AUTH_URL	https://test.account.ttrmb.ecas.local:8443
NEXT_PUBLIC_BETTER_AUTH_URL	https://test.account.ttrmb.ecas.local:8443
ACCOUNT_PUBLIC_URL	https://test.account.ttrmb.ecas.local:8443
NEXT_PUBLIC_ACCOUNT_URL	https://test.account.ttrmb.ecas.local:8443
FORMGEN_BETTERAUTH_URL	https://test.formgen.ttrmb.ecas.local:8443
DOCUSAURUS_PUBLIC_URL	https://test.docs.ttrmb.ecas.local:8443
DOCUSAURUS_MCP_PUBLIC_URL	https://test.docs.ttrmb.ecas.local:8443/mcp/

Bármelyik nem üres selector bekapcsolja mind a nyolc érték származtatását a szokásos futásidejű konfigurációfeloldás során. Ehhez a módhoz ne állíts be nyolc független URL-felülírást. Ha mindkét selector üres, a szokásos futásidejű beolvasás megtartja a meglévő explicit BETTER_AUTH_URL, NEXT_PUBLIC_BETTER_AUTH_URL és FORMGEN_BETTERAUTH_URL értékeket. A setup újraszámítása ekkor is mind a nyolc URL-t származtatja.

A selectorok nem nevezik át a konténereket, az upstream aliasokat, a volume-okat, a hálózatokat, az adatbázis-identitásokat és a távoli névtereket. Az ecas-test futtatókörnyezetben a példa BFF útvonal továbbra is az ecas-test-bff:5173 célra mutat. Az Account útvonal külön az ecas-test-account:5573 célra mutat.

Az új előkészítés mindkét kiszámított böngésző-origint rögzíti a manifestben. Az életciklus admission-ellenőrzéshez routing-jóváhagyás és a tárolt originekkel való pontos egyezés kell. A selectorok eltávolítása nem kapcsolja ki ezt az ellenőrzést. A tárolt originek nélküli, korábbi selectormentes manifestek megtartják a korábbi admission-szerződésüket.

A meglévő befagyasztott bundle-t hagyd változatlanul. A gyökérforrás szerkesztései nem frissítik a konfigurációját, a másolt helpereit vagy a korábbi bizonyítékait. Az új origin-működéshez készíts elő kifejezetten jóváhagyott új snapshotot. Ne írd át a korábbi manifesteket vagy jóváhagyásokat.

Hitelesítési izoláció

A megosztott hitelesítéshez párosított HTTPS BFF és Account hosztok kellenek azonos deployment suffixszel, prefixszel és porttal. A példapárnál a közös cookie domain .ttrmb.ecas.local. A teszt cookie prefix ecas-shared-test. A prefix nélküli deployment megtartja az ecas-shared értéket.

A teszt BFF OAuth state cookie neve ecas_test_oauth_state. Az Account az ecas_account_test_oauth_state nevet használja. A prefix nélküli deploymentek megtartják az ecas_oauth_state és az ecas_account_oauth_state neveket. Ezek a nevek elkülönítik a teszt sessionöket és az OAuth state-et az éles nevektől.

A testvérhosztok továbbra is közös szülődomaint használnak. A cookie-nevek nem képeznek biztonsági határt egy ellenséges testvérhoszttal szemben. Tarts fenn külön teszt-adatbázisokat, auth secreteket és felügyelt proxy-útvonalakat.

Az önálló Account fejlesztés csak akkor tartja meg a host-only, nem secure cookie-kat, ha mindkét beállított alkalmazás-origin HTTP-t és pontos localhost értéket használ, felhasználói adatok nélkül. A vegyes nyilvános és localhost originek, valamint a többi loopback írásmód nem kapja meg ezt a kivételt.

Böngészős bejelentkezés előtt lásd a tanúsítvány-megbízhatóságot és a Microsoft callbackeket. A friss Microsoft-bejelentkezéshez beállított BFF Microsoft hitelesítő adatok és jóváhagyott, le nem járt tenant-kapcsolat is kell, kikapcsolt Graph workerek mellett is. Az OAuth-beállítások és a redirect-regisztráció önmagában nem elég. Az operátori előkészítéshez és a külön backend Graph hitelesítő adatokhoz lásd a friss Microsoft-bejelentkezés előfeltételeit.

A normál seed nem hozza létre az első tenant-kapcsolatot egy friss izolált adatbázisban. A Microsoft alkalmazás-bejelentkezés előtt végezd el a szabályszerű operátori setupot. Bejelentkezés után külön kapcsold össze a postafiókot, majd az onboarding előtt generáld le a személyes kulcsot, erősítsd meg a backupot, és aktiváld a kulcsot. A böngészős kulcs-setuphoz megbízható HTTPS origint használj. A meglévő tulajdonos helyreállítási útvonalához és az egyező onboarder/WebhookCatcher client state beállításhoz lásd a hivatkozott előfeltételeket. Az éles tárolási hitelesítő adatokat, a titkosítási kulcsokat, a sessionöket és az adatokat tartsd izoláltan.

A helyes konfiguráció önmagában nem igazolja a sikeres bejelentkezést, a kijelentkezési izolációt vagy az OAuth roundtripet.

Adatok és erőforrások

A generált teszt-konfiguráció friss helyi tárhelyet, hitelesítési és titkosítási anyagot, valamint izolált Kafka- és Qdrant-névtereket használ. A kiválasztott elhelyezés valódi partialRemote. A provider- és ingress-jelzőket a teszt-szabályzat letiltja. Nem másol át éles postafiók-adatokat.

A rögzített wrapper továbbra is personal-only módban fut, letiltott Microsofttal és véletlenszerű ECAS_DEPLOYMENT_TENANT_ID authorization névtérrel. A külön előkészített, operátor által engedélyezett Microsoft-változathoz az első authorization bootstrap előtt kell a tervezett, ellenőrzött app-only Entra tenant. Állítsd az ECAS_DEPLOYMENT_TENANT_ID értékét erre a BACKEND_TENANT_ID értékre. Tarts fenn független adatbázisokat, hitelesítési és titkosítási kulcsokat, tárolókat, távoli névtereket és cookie-kat. A tenant-identitás önmagában nem izolálja a tárhelyet.

Előkészítés vagy migráció előtt lásd a Microsoft tenant kiválasztását és a meglévő állapot korlátait. Egy már inicializált teszt nem tud tenantot váltani pusztán .env módosítással. A legacy admission-útvonal jelenleg nem támogatja a friss Microsoft-onboardingot eltérő deployment tenantok között.

Az alapértelmezett generált teszt-profil továbbra is ECS_MEMORY_GIB=30, bounded módban, 4 GiB swap-kerettel. Nem örökli a nagyobb éles profilt. A kiválasztott szolgáltatásoknál az indítási minimum-ellenőrzés a mérvadó.

A megfigyelt 33 kiválasztott szolgáltatással futó, külön előkészített és operátor által engedélyezett Microsoft-tesztnek most nagyobb meglévő profil kell. Az onboarder minimuma 2048 MiB, a teljes fejlesztői independent queue minimuma pedig 768 MiB. Ez az összeállítás a 30 GiB-os profil minimumszintjein 32,192 MiB-ot igényel, ami meghaladja azt a profilt. A meglévő 35+ GiB-os profil minimumszintjein 38,592 MiB kell. A kiválasztott 40 GiB-os profil lefedi ezeket a minimumokat. Ez a választás nem általános alapértelmezés, nem garantált szabad RAM, és nem bizonyítja a sikeres indítást vagy a postafiók elkészültét.

Szokásos újraindítás előtt csak egy teljes stacket tarts aktívan, és ellenőrizd a gazdagép RAM- és swap-admission feltételeit. Őrizd meg az adatbázisokat, az object store-okat, a volume-okat és a kulcsokat. A jóváhagyott profilmódosítást a kiválasztott fizikai futtatókörnyezet gyökeréből indított szokásos újraindítással alkalmazd. Ne állítsd alaphelyzetbe az adatokat. Egy szolgáltatás cgroup out-of-memory (OOM) hibája nem bizonyít gazdagépszintű OOM-ot. A teljes stack leállítása előtt ellenőrizd a gazdagép memóriáját és a kernel OOM-bizonyítékokat.

A jelenlegi Graph FTS export chunkonként egy elemet dolgoz fel, ami csökkenti a batch-pufferelést. Egyetlen nagy elemnek továbbra is megfelelő szolgáltatási memóriakeret kell. A sikeres indítást és a postafiók elkészültét csak tényleges futási bizonyíték alapján rögzítsd. A 40 GiB kiválasztása önmagában egyik eredményt sem bizonyítja.

A teszt-image build-célok külön-külön futnak. A normál inicializálás minden runtime esetében image targetenként külön Compose build parancsot futtat, a teszt-jelzőtől függetlenül. A sikertelen build nem jelent készenlétet. A folytatás előtt javítsd a jelzett előfeltételt.

Proxy-határok

A teszt proxy-útvonal nem tudja elindítani vagy újraindítani a megosztott proxyt. Használj meglévő proxyt, és külön hostokat, callbackeket és tanúsítványokat. A névfeloldásnak működnie kell a böngésző gépén és a szerver vagy WSL hoszton is. Jóváhagyott Nginx-útvonalak hozzáadásakor elég lehet a konfiguráció újratöltése, a konténer újraindítása nélkül.

A tanúsítvány létrehozása, a hosztnév-lefedettség és a böngészőoldali megbízhatóság külön ellenőrzés. A SAN-ok határozzák meg a hosztnév-lefedettséget, a megjelenített tanúsítvány CN értékétől függetlenül. A T3 preview futhat Linux/WSL környezetben, miközben a felülete Windowson fut. A Windows Root megbízhatóság nem fedi le ezt a preview-t.

Használd a böngészős tanúsítvány-megbízhatósági eljárást a tényleges böngészőkörnyezethez. Az útmutató leírja a kiszolgált tanúsítvány fingerprintjének ellenőrzését és a Windows-jóváhagyást. Kitér a Chromium NSS adatbázisának kiválasztására, a pontos leaf trustra és a célzott böngésző-újraindításra. A Linux rendszerszintű megbízhatóság önmagában nem eredményez Chromium NSS elfogadást. Bejelentkezés előtt ellenőrizd mindkét kiválasztott hosztot bekapcsolt HTTPS tanúsítvány-ellenőrzéssel.

Az eredeti PostgreSQL- és S3-tárolókat, valamint a többi biztonsági mentési teszttárolót tartsd a teszt-példányon kívül. A leállítás a teszt-adatokat is megőrzi. Ez az útmutató nem ad engedélyt resetre vagy volume-törlésre.

Külön előkészített forrás-snapshotok

A forrás-acceptance ellenőrzés külön előkészített fizikai snapshotot is használhat friss futásidejű azonosítóval és privát konfigurációval. Ez operátor által kezelt setup. A testInstance.sh nem választ ki egyedi azonosítót. A meglévő rögzített ecas-test bundle-t őrizd meg érintetlenül.

Indítás előtt ellenőrizd a tárhelyet, a titkosítási kulcsokat, a tulajdonosi címkéket, a hálózatokat és a nyilvános routingot. A forrás tárhelyét és kulcsait hagyd változatlanul. Őrizd meg a megosztott proxyt és a nem kapcsolódó monitoring szolgáltatásokat.

A szokásos életciklus-szkripteket a kiválasztott fizikai futtatókörnyezet gyökeréből futtasd. Cseréld le a /path/to/prepared-runtime útvonalat az ellenőrzött könyvtárra:

cd /path/to/prepared-runtime
bash startDevServers.sh
bash stopDevServer.sh
bash quickStarter.sh
bash restartDevServers.sh

Ezek külön életciklus-műveletek. A quickStarter.sh a meglévő konténereket folytatja. Nem alkalmaz új konfigurációt, és nem készít elő hiányzó konténereket. Ehhez a munkafolyamathoz ne használj resetet.

A snapshot source provenance ellenőrzése

Előkészítés előtt commitold a megvalósítást minden érintett repositoryban. Az előkészítés megváltoztathatatlan commitokat választ ki a gyökér repositoryhoz és a kiválasztott al-repositorykhoz. Átmásolja a commitolt fájlokat, a jóváhagyott fájlspecifikus overlay-eket és a kötelező snapshot helpereket. A nem commitolt alkalmazásszerkesztéseket a folyamat nem veszi fel automatikusan a snapshotba.

A build- vagy böngészős bizonyítékok értékelése előtt ellenőrizd a kiválasztott repository-revíziókat és fájl-hasheket a source manifestben. Ellenőrizd, hogy ezek lefedik-e a tervezett megvalósítást. Ellenőrizd a ténylegesen feloldott ECS_APPLICATION_SOURCE_ROOT értéket, valamint az azt használó application mountokat és build contexteket is.

Az ECS_APPLICATION_SOURCE_ROOT a runtime roottól külön választja ki az alkalmazáskódot. Az alapértelmezett értéke .. Egy átnézett abszolút source root átirányíthatja a kódot, miközben a konfiguráció, a runtime identity, az állapot és az adatok a klónhoz kötve maradnak. A tágabb konfigurációs szerződéshez lásd a kanonikus környezet-referenciát.

A gyökérben végzett szerkesztések nem frissítik a korábban előkészített bundle-t vagy annak másolt lifecycle helpereit. Ha az aktuális forrásra van szükség, készíts elő új fizikai snapshotot a tervezett commitokból. Őrizd meg a régi snapshotot, a rögzített manifestjét és a korábbi bizonyítékait. Az újraindítás nem váltja ki a snapshot előkészítését. A forrás-ellenőrzések önmagukban nem bizonyítják a sikeres indítást vagy a böngészős folyamatot.

Külön előkészített placement-változatok váltása

Az operátor külön privát FullLocal és PartialRemote környezeti változatokat készíthet elő ugyanannak az ellenőrzött futtatókörnyezetnek. Az aktív gyökér .env választja ki a placementet. A FullLocal az ECS_DEPLOYMENT_MODE=fulllocal és az ECS_REMOTE_SIMULATION=false beállítást használja. A valódi PartialRemote az ECS_DEPLOYMENT_MODE=partialRemote és az ECS_REMOTE_SIMULATION=false beállítást használja.

Őrizd meg a helyi PostgreSQL-t, az S3-at, a hitelesítési és titkosítási kulcsokat, valamint a volume-okat mindkét változatban. Az aktív .env cseréje előtt állítsd le a ténylegesen kiválasztott futtatókörnyezetet a jelenlegi konfigurációjával. Ezután szokásos starttal vagy restarttal alkalmazd a kiválasztott konfigurációt. A quickStarter.sh csak a meglévő konténereket folytatja, és nem tudja alkalmazni a váltást. Ne használj resetet, és ne törölj volume-okat.

A valódi PartialRemote változatban a KAFKA_CLUSTER_ID értékének egyeznie kell a ténylegesen kiválasztott, saját tulajdonú távoli cluster REMOTE_KAFKA_EXPECTED_CLUSTER_ID értékével. A FullLocal változat megtartja a saját helyi cluster-azonosítóját és broker-adatait. Az egyedi Kafka topicok és consumer groupok izolálják az alkalmazás-névtereket. Ezek nem helyettesítik a cluster-identitást. Az egyedi Qdrant collection egy másik külön névtér.

A távoli KNOWLEDGE_QDRANT_COLLECTION collectionnek már léteznie kell 1536 vektormérettel és Cosine távolsággal. A normál Qdrant dependency preflight csak lekéri (GET) a collectiont. Valódi távoli módban HTTP 404 válasz esetén hibával leáll, és nem tudja létrehozni. Az operátor a normál Qdrant admin API-n keresztül hozhat létre új, saját tulajdonú, hiányzó collectiont. Soha ne irányíts át régi adatot, és ne használd újra másik deployment collection-nevét.

A placement váltása előtt lásd a távoli deployment placementet és állapotátvitelt. Az Office-hoz továbbra is kell a pontos public-origin és útvonal-tulajdonjog. A sikeres távoli dependency-próbák nem igazolják a teljes hibrid alkalmazás-folyamatot vagy az Office callbacket.

A production buildekhez kell a futásidejű DATABASE_URL és a NODE_ENV=production. A szokásos bash startDevServers.sh --prod konténerindítás a Compose-on keresztül adja át a production környezetet. A DATABASE_URL nélküli csupasz gazdagépi build modulimportálás közben elbukhat. A NODE_ENV=development beállítású gazdagépi build prerenderelés közben elbukhat. A production buildekhez az előkészített futásidejű konfigurációt használd. A sikeres build nem igazolja a hitelesített böngészős vagy távoli szolgáltatási acceptance-t.

A szokásos hideg indítás írásvédetten csatolja a kanonikus adatbázis SQL-t a /runtime/database-sql útvonalra. Az adatbázis-inicializáló betölti az actor-jogosultsági és policy SQL-t, majd lefuttatja a normál seedet. A tényleges authorization migrációkat csak akkor futtatja, ha a betterauth.user és az authorization.subjects globálisan üres, és a deployment tenantnak nincs migrációs markere. A meglévő adatbázisokhoz továbbra is az explicit authorization migrációs folyamat kell. Ne kerüld meg az authorization gate-et, és ne szúrj be migrációs markert a migrációk nélkül.

A fejlesztői HMR elfogadja a MAILGEN_PUBLIC_URL hosztnevét a meglévő Account auth hosztnevek mellett az allowedDevOrigins listában. Ez wildcard nélkül engedélyezi a beállított BFF origint. Tartsd összhangban a nyilvános browser és auth URL-eket a proxy-útvonalakkal. A next.config.js módosítása után indítsd újra a BFF fejlesztői szolgáltatást.

A MAILGEN_PUBLIC_URL a pontos origint (séma, hosztnév és port) is hozzáadja a BFF hitelesített realtime és cookie sync folyamataihoz. A HTTP origin-ellenőrzések is tartalmazzák a Complexity mutációknál, a jóváhagyásoknál, a composer draft attachmenteknél, az admin proxy mutációknál és a keresési mutációknál. Ezek az ellenőrzések az URL origint használják, míg a HMR csak a hosztnevet használja. Állítsd be a konkrét nyilvános URL-t, wildcard nélkül. A session- és jogosultság-ellenőrzések továbbra is érvényesek.