HSK WEBKDModernizacja kontroli dostępu z bezpieczniejszym rdzeniem domenowym
HSK WebKD to enterprise system kontroli dostępu i RCP, nie strona wizytówka. CloudFloo modernizuje oprogramowanie wokół serwerów RCP, kontrolerów i czytników TKD, posiadaczy PKD, kart KAD, uprawnień indywidualnych i grupowych, harmonogramów, zdarzeń, raportów, pracy zdalnej i bramek wdrożenia, zachowując operacyjne zachowanie systemu.
01 · Kontekst operacyjny
WebKD działa w operacyjnej warstwie obiektu. Operatorzy pracują z serwerami RCP, kontrolerami i czytnikami TKD, posiadaczami PKD, kartami KAD, harmonogramami, sekwencjami, zdarzeniami, raportami czasu obecności, komunikatami, modułami DOD i pracą zdalną.
Modernizacja zaczyna się więc od mapy domeny, a nie od nowej skórki UI. System musi zachować sposób podejmowania decyzji dostępowych, przeliczania uprawnień, aktualizacji czytników i diagnozowania zdarzeń.
CloudFloo traktuje ten projekt jako oprogramowanie enterprise: wiele modułów, starsze ograniczenia, fizyczne urządzenia, dane operacyjne i ścieżka wdrożenia z wycofaniem zmian oraz kontrolą migracji.
02 · Moduły domenowe i kontrakty
Backend NestJS jest zorganizowany wokół jawnych modułów WebKD: RCP, TKD, PKD, KAD, Uprawnienia, Zdarzenia, Harmonogram, Sekwencja, Grupa, GLC, Kontrola, Komunikat, raporty, access control, licencje, monitoring, job status, kolejki i administracja.
Kontrola dostępu jest modelowana jako uprawnienia funkcjonalne i uprawnienia do danych. Operator może mieć dostęp do funkcji, ale jednocześnie być ograniczony do konkretnych grup, posiadaczy, czytników lub zakresów organizacyjnych.
OpenAPI, kontrolery, DTO, frontendowe klienty API i dokumentacja domenowa dają zespołowi wspólny kontrakt. Celem jest zmiana krytycznego zachowania przez kontrolowane wycinki, nie przez ukryte powiązania.
03 · Runtime i lokalna platforma
Runtime to więcej niż jeden proces webowy. Frontendy React i ingress API komunikują się z podami NestJS; backend używa TypeORM/Postgres, Redis query cache, kolejek Bull, adaptera Socket.IO Redis, logowania, throttlingu, guardów, interceptorów i endpointów health.
Komunikacja RCP może działać w backendzie albo przez dedykowany rcp-worker za flagą funkcji. To daje bezpieczną ścieżkę oddzielania komunikacji z urządzeniami od powierzchni API bez przepisywania wszystkiego naraz.
Lokalny development używa Dockera, manifestów Kubernetes, Skaffold, obrazów API-site/mock, Postgresa, Redisa i danych E2E, żeby środowisko deweloperskie było bliżej realnej topologii.
04 · Kontrola wdrożeń i migracji
Ścieżka wdrożenia opiera się o Nx affected builds, GitHub Actions, obrazy kontenerowe, Helm i wartości dla każdego środowiska. Staging i produkcja mogą budować tylko zmienione części, uruchamiać testy, publikować obrazy i wdrażać przez chart.
Migracje bazy są bramkami wdrożenia. Helm uruchamia zadanie migracyjne, pody backendu czekają w init-containerze na sukces migracji, a skrypty wdrożeniowe czyszczą zablokowane zadania przed ponowieniem. To zapobiega sytuacji, w której zła migracja po cichu psuje produkcję.
05 · Dlaczego to ma wartość dla HSK
System taki jak WebKD zbiera ryzyko, gdy wiedza żyje tylko w ludziach, starych założeniach lub rozproszonych ścieżkach kodu. Modernizacja zamienia tę wiedzę w moduły, kontrakty, testy, bramki wdrożenia i diagramy, które zespół może analizować.
Wartość nie polega na przepisywaniu dla samego przepisywania. Chodzi o mniej niewiadomych przed zmianą, bezpieczniejsze zachowanie uprawnień, powtarzalne środowiska, jasną odpowiedzialność za wdrożenie i lepszą ścieżkę dla DOD, pracy zdalnej, raportów, monitoringu oraz separacji RCP.
Jak system jest naprawdę złożony.
Decyzje dostępowe łączą karty, osoby, czytniki, uprawnienia, harmonogramy i zdarzenia
Rdzeń domeny jest grafem, nie listą CRUD. Posiadacze PKD dostają karty KAD, uprawnienia mogą być indywidualne lub grupowe, struktury GLC i czytniki definiują zakres fizyczny, a harmonogramy, sekwencje, zdarzenia i raporty zamykają pętlę operacyjną.
Dlatego opis WebKD potrzebuje diagramów architektury. Zmiana jednej części domeny może dotknąć uprawnień efektywnych, przeładowań czytników, rekordów czasu obecności i widoczności operatora.
- Moduły backendu obejmują RCP, TKD, PKD, KAD, Uprawnienia, Zdarzenia, Harmonogram, Sekwencja, Grupa, GLC, Kontrola, Komunikat, raporty i kontrolę dostępu.
- Uprawnienia funkcjonalne i uprawnienia do danych są osobnymi warstwami.
- Trasy frontendu odzwierciedlają domeny operatora: urządzenia, karty, posiadacze, zdarzenia, harmonogramy, sekwencje, raporty, użytkownicy i DOD.
Operatorzy React, moduły NestJS, Postgres, Redis, kolejki i ścieżka rcp-worker
Topologia operacyjna łączy frontendy React, API ingress, pody NestJS, Postgres/TypeORM, Redis query cache, kolejki Bull, adapter Socket.IO Redis, logowanie, throttling, guardy i opcjonalną separację rcp-worker.
To daje realistyczną powierzchnię modernizacji: poprawić granice modułów, bezpiecznie wydzielić komunikację z urządzeniami, dodać testy wokół uprawnień i utrzymać środowisko lokalne blisko produkcji.
- Backend NestJS używa TypeORM/Postgres i Redis dla cache oraz kolejek.
- Tryb RCP microservice może przenieść komendy urządzeń z backendu do rcp-worker.
- Skaffold buduje obrazy backendu, frontendu, API-site, mockservera i workera dla lokalnego Kubernetes.
Migracje i rollout są jawne, nie są efektem ubocznym wdrożenia
Architektura wdrożenia używa Nx affected builds, GitHub Actions, obrazów, wartości Helm, migration Job, init-containera wait-for-migration, probes i skryptów, które czyszczą zablokowane operacje przed ponowieniem.
To ważne, bo systemy kontroli dostępu nie tolerują niejasnego stanu wdrożenia. Migracja schematu, rollout API i wydanie frontendu muszą być skoordynowane.
- PR, staging, produkcja i E2E mają osobne przepływy w GitHub Actions.
- Helm migration Job działa zanim pody backendu będą ready.
- Pody backendu bramkują start przez init container czekający na sukces migracji.
Zacznij od dwutygodniowego audytu systemu.
Sprawdzimy architekturę, ryzyka, ścieżkę wdrożenia i miejsca, w których AI lub automatyzacja mogą pomóc bez utraty kontroli nad produkcją.