Napi runtime-parancsok
Ezeket a parancsokat a motherrepo gyökerében használd, az első setup után. Az egységes runtime a gyökér .env fájlt olvassa. A tmux a Docker-folyamatokhoz csatlakozik. Nem futtat második backend-stacket.
Válaszd ki a műveletet
| Cél | Parancs | Hatás |
|---|---|---|
| Konfiguráció ellenőrzése | bash devstack.sh validate | Elutasítja az érvénytelen konfigurációt. Nem helyettesíti az alkalmazás-ellenőrzéseket. |
| Images építése | bash devstack.sh build | Felépíti a kiválasztott image-eket. Ez nem hoz létre egészséges, futó stacket. |
| Teljes development indítás | bash startDevServers.sh | Inicializálja a függőségeket, és development végrehajtást választ |
| Teljes production indítás | bash startDevServers.sh --prod | Lefordítja és elindítja a fordított szolgáltatásokat |
| Ennek a példánynak a leállítása | bash stopDevServer.sh | Leállítja a kezelt alkalmazásokat és a helyi infrastruktúrát, megőrzi a volume-okat és a kulcsokat |
| Konfiguráció alkalmazása production-újraépítés nélkül | bash restartDevServers.sh | Újra létrehozza a szolgáltatásokat a mentett végrehajtási módokkal és az aktuális konfigurációval |
| Production végrehajtás kiválasztása | bash restartDevServers.sh --prod | Lefordítja a szolgáltatásokat, és production végrehajtást választ |
| Változatlan, előkészített konténerek folytatása | bash quickStarter.sh | Elindítja a leállított meglévő konténereket build, újralétrehozás vagy új konfiguráció nélkül |
| Állapot ellenőrzése | bash devstack.sh status | Megjeleníti a kiválasztott példány szolgáltatásait |
| BFF-naplók követése | bash devstack.sh logs bff | Megjeleníti a naplókat. A Ctrl+C befejezi a naplónézést. |
Az újraindítás megőrzi az adatokat, de megszakítja a felhasználók munkáját. Nem futtat initialize lépést, adatbázis-inicializálást vagy sémamigrációt. A sima újraindítás nem építi újra a production artifactokat. A development watcherek betölthetik a forrásszerkesztéseket. A lefordított production kódhoz explicit production build kell. A gyors indítás nem alkalmazza a módosított .env fájlt, a forrásválasztást, az endpointot, a jelszót vagy a módot. Ezekhez használd a sima újraindítást.
Egy szolgáltatás helyreállítása
bash devstack.sh restart bff
bash devstack.sh start bff
Ezek a parancsok a szolgáltatás mentett módját használják. A --prod opciós célzott start kifejezetten production módot választ az adott szolgáltatásra. A célzott restart elutasítja a --prod opciót. Lásd a végrehajtási módokat.
Célzott művelet előtt ellenőrizd a függőségeket és a provider-kiválasztást. A parancs nem tud providert aktiválni, és nem tudja pótolni a hiányzó első bootstrap-lépést. Valódi remote módban a helyi célzott parancs nem kezeli a Coolify helyettesítő infrastruktúráját.
Módosított production-kód publikálása
Egy tudatos, teljes production kiadáshoz, az ellenőrzött és kiválasztott forrásból:
bash restartDevServers.sh --prod
Ez újraépíti a production artifactokat, és production végrehajtást választ a kiválasztott szolgáltatásokra. Nem helyettesíti a külön szükséges séma- vagy függőség-előkészítést. A kiadás előtt nézd át a forrás kompatibilitását és a mentéseket.
Egy célzott hotfixhez használd a csatolt terminál eljárást. A célzott restart nem épít. A bash devstack.sh start SERVICE --prod csak egy már leállított, előkészített szolgáltatás-konténerhez épít. Futó konténert elutasít. Célzott szolgáltatásműveletet ne helyettesíts teljes stack-leállítással.
Az egységes production docs a lefordított statikus kimenetet szolgálja ki, ehhez docs production build kell. Az egységes development docs a npm start parancsot futtatja, amely a forrást figyeli. Lásd a dokumentációs módokat.
Profilok és végrehajtás
A választható profilok extra szolgáltatásokat választanak ki. Nem változtatják meg az infrastruktúra elhelyezését. A normál setup tartalmazza a FormGen- és a docs-mcp szolgáltatást. A Google OAuth, a szinkronizálási és a figyelési jelölők a megfelelő profilokat választják ki. Ezek bekapcsolása előtt a provider setup legyen teljes.
Az ECS_APPLICATION_SOURCE_ROOT egy átnézett pillanatképre rögzítheti az alkalmazáskódot. Az eredeti checkoutból indított újraindítás is ezt a pillanatképet használja. Olvasd el a forrásválasztást, mielőtt helyi szerkesztést várnál.
Terminál csatlakoztatása
bash devServerAttach.sh
Válaszd ki a kívánt szolgáltatást. A parancs a tényleges konténerfolyamathoz csatol. A Ctrl+C leállíthatja ezt a szolgáltatást. A Ctrl+P, majd a Ctrl+Q lecsatolja a terminált, a szolgáltatás pedig tovább fut. Ne indíts mellette másik kézi folyamatot.
A bash memmonitor.sh az alkalmazás- és konténermemóriát mutatja. Nem teremt több kapacitást. A tmux-sessionök, illetve a hiányzó sessionök nem bizonyítják a szolgáltatás készenlétét.
Hideg indítás vagy reset előtt
Linuxon és WSL-en ellenőrizd a free -h, az uptime, a docker ps, a tmux list-sessions és a bash memmonitor.sh kimenetét. macOS-en a memóriához használd a Docker Desktop erőforrásait és az Activity Monitort.
Hideg bootstrap vagy destruktív reset előtt válassz ki egy teljes stacket. Csak azt a példányt állítsd le, amelyet le akarsz állítani, a saját checkoutjából. Őrizd meg a nem kapcsolódó production konténereket.
A resetDevServers.sh, a startDevServers.sh --reset és a down -v adatokat törölhet. Ezek nem napi helyreállítási parancsok. Engedélyezett adattörlés előtt olvasd el a pontos reset-határt. A konfiguráció, az adatbázis, az objektumtároló és a titkosítási kulcsok mentéseit külön tartsd meg. A partialRemote mód a reset és a cleanup kérést akkor is elutasítja, ha szimuláció fut. Ne változtass elhelyezést a védelem megkerülésére.
Ellenőrizd az eredményt
Indítás után ellenőrizd az állapotot, valamint a kiírt Account- és BFF HTTPS-címeket. Nézd meg a bejelentkezést, egy engedélyezett mailboxot, egy üzenettörzset, a keresést és az érintett funkciót. Írási műveletnél különböztesd meg az elfogadást a provider megerősítésétől.
Ha egy adatbázis vagy egy másik kötelező szolgáltatás meghibásodik, a közös session-ellenőrző SESSION_UNAVAILABLE hibát dob. A közös jogosultsági hibaátalakítót használó védett API-route-ok erre a hibára HTTP 503 választ adnak vissza. A kifejezett hozzáférés-megtagadás az esettől függően megtartja a HTTP 401 vagy 403 kódot. Ellenőrizd az érintett szolgáltatást, majd miután a szolgáltatás egészséges, küldd újra a kérést, vagy töltsd újra az oldalt. Adatbázis-kiesésnél nem kell cookie-kat törölni, kulcsot cserélni, adatot resetelni vagy újra bejelentkezni. A célzott runtime-parancsokat lásd a szolgáltatás-helyreállításnál.
A közös web Prisma adapter egyetlen további acquisition lépést engedélyez ugyanabból a poolból egy új fizikai kapcsolat timeoutja után, még az SQL előtt. Ehhez látható idle kapcsolat kell, várakozó kérés és leállítási folyamat nélkül. Nem játszik vissza SQL-, request-, autentikációs, model- vagy tool-műveletet. A pool limitek, a timeoutok és a grantek változatlanok maradnak.
A DB_POOL_RECOVERY csak egy kísérletet jelez, poolonként percenként legfeljebb egyszer, a siker bizonyítása nélkül. A publikus connect hívásnál race alakulhat ki, amely új fizikai klienst nyithat, és még egy meglévő timeoutot vehet igénybe. A hálózati okot ez nem javítja ki. Kövesd a fenti HTTP 503 helyreállítási tanácsot reset nélkül.
Szolgáltatás memóriakorlát-hibájánál javítsd és indítsd újra az adott szolgáltatást, miközben az egészséges szolgáltatások futnak. Az OOMKilled=true önmagában nem bizonyítja a host teljes memóriakimerülését. A teljes stack érintettségét ne feltételezd, amíg nem vizsgáltad a host memóriáját és a kernel-bizonyítékokat.
Lásd a Docker-referenciát a proxyhoz, a tanúsítványokhoz, a tárolási határokhoz és a hibaelhárításhoz.
Pontos reset-határ
Ez hatókör-referencia, nem hibaelhárítási eljárás. A gyökér reset-útvonal ellenőrzi a fulllocal elhelyezést és a klón tulajdonosát, leállítja a saját szolgáltatásait, lecsatolja ennek a példánynak az ingress-ét a proxyról, és -v nélkül futtatja a Compose down parancsot. Ezután csak a DATA_VOLUMES listában szereplő logikai nevű, saját volume-okat törli:
| Törölt logikai volume | Érintett adat |
|---|---|
postgres-data | Helyi PostgreSQL-adatok |
seaweedfs-data | Helyi fájlobjektumok |
opensearch-data | Keresési adatok |
kafka-ui-data | Kafka UI állapota |
kafka-broker1-data, kafka-broker2-data, kafka-broker3-data | Helyi broker-adatok |
kafka-connect-data | Connect állapota |
kafka-ksqldb-state | ksqlDB állapota |
flink-jobmanager-data, flink-taskmanager-data, flink-checkpoints | Flink állapota és checkpointjai |
A többi named volume ezen a reset-útvonalon megmarad. Megmarad a gyökérkonfiguráció, a hoston helyben tárolt kulcsok és tanúsítványok, a közös proxy állapota, a tunnel tulajdonlása és a többi klón. Ez nem helyettesíti a mentéseket. A cleanup-deployment-docker.sh ugyanazt az őrzött reset-határt használja.
A sima Compose down -v egy másik, szélesebb volume-törlési művelet. Ne használd projekt-resetre helyette. A partialRemote mód a reset és a cleanup kérést a módosítás előtt elutasítja, szimulációval is. Ne válts elhelyezést ennek megkerülésére.