Przestrzenie robocze, instancje i hosting

Archestack zwykle wdraża partner wdrożeniowy: firma, która buduje aplikację na Archestack i dostarcza ją swoim klientom. Przez całą tę stronę prowadzi jeden przykład: firma tworząca oprogramowanie zbudowała aplikację dla laboratoriów badawczych, czyli firm, które na zlecenie innych przedsiębiorstw analizują żywność, wodę i materiały. Aplikacja śledzi każdą próbkę od przyjęcia do certyfikatu, a ta firma wdraża ją w kolejnych laboratoriach, jednym po drugim. Każde laboratorium jest klientem i każde ma własnych klientów biznesowych: producentów żywności, przedsiębiorstwa wodociągowe i zakłady produkcyjne, które przysyłają próbki.

Reszta tej strony opiera się na trzech pojęciach:

• Klient: firma, której partner dostarcza aplikację. W tym przykładzie każde laboratorium.
• Przestrzeń robocza: odizolowane środowisko, w którym pracuje klient, z własną aplikacją, własnymi danymi i własnymi członkami. Jej techniczna nazwa to tenant.
• Instancja: jedna działająca kopia Archestack. Działa w niej jedna przestrzeń robocza albo wiele.

Krótko mówiąc: klient pracuje w przestrzeni roboczej, a przestrzeń robocza działa w instancji. Poniższe sekcje wyjaśniają, czym jest przestrzeń robocza i co oddziela ją od innych, opisują dwa sposoby hostowania przestrzeni roboczych Twoich klientów i pokazują, jak laboratorium daje dostęp własnym klientom, jak hostowany jest sam Archestack i jak nowa wersja Twojej aplikacji dociera do każdego klienta.

Czym jest przestrzeń robocza

Przestrzeń robocza to odizolowane środowisko, w którym pracuje jeden klient. Mieści całą aplikację, dane, na których ta aplikacja pracuje, i ludzi, którzy mają do niej dostęp, a przy tym jest odgrodzona od wszystkich innych przestrzeni roboczych. Każde laboratorium dostaje własną.

Tenant to techniczna nazwa tej samej rzeczy. Na ekranach mowa o przestrzeni roboczej, a w API i w kodzie o tenancie; od tego słowa pochodzą określenia hostingu single-tenant i multi-tenant. Przestrzeń robocza i tenant to nie dwie warstwy i jedno nie zawiera drugiego: jedno laboratorium ma jedną przestrzeń roboczą, a API nazywa tę przestrzeń roboczą tenantem. Na tej stronie konsekwentnie piszemy o przestrzeni roboczej.

Instancja Archestack

Jeden backend dla wszystkich przestrzeni roboczych

API

Zadania w tle

Wspólne dla wszystkich przestrzeni roboczych w instancji

Konta Module Store Wersja platformy

Token dla Lab 1

Token dla Lab 2

Lab 1

Przestrzeń robocza (tenant)

Core

Runtime

Członkowie i role

Lab 2

Przestrzeń robocza (tenant)

Core

Runtime

Członkowie i role

Co zawiera przestrzeń robocza

Przestrzeń robocza obejmuje trzy rzeczy:

• Core, bazę danych PostgreSQL, która przechowuje samą aplikację: Business Entities, strony, Business Events, Script Modules, Scheduled Events, PDF Templates, packages, wydania (releases), zestawy testów, endpointy Data API i klucze API, tokeny MCP, branding, układy aplikacji, tłumaczenia, ustawienia, konta pocztowe i skrzynkę nadawczą, a także preferencje i powiadomienia jej użytkowników. Hasła i inne sekrety zapisane w tej bazie są szyfrowane, a klucze API i tokeny MCP są przechowywane wyłącznie jako hash.
• Runtime, bazę danych PostgreSQL, która przechowuje dane biznesowe: tabele i ich wiersze, w tym przykładzie próbki, analizy, wyniki, certyfikaty analiz i faktury. Schema Designer pokazuje jej strukturę dokładnie taką, jaka jest w bazie danych.
• Członków: ludzi, którzy mają dostęp, każdego z rolą w tej przestrzeni roboczej. Zaproszenia wysyła się osobno dla każdej przestrzeni roboczej.

Ponieważ aplikacja znajduje się w Core, każde z dwóch laboratoriów korzystających z tej samej aplikacji ma jej własną kopię. Zmiana wprowadzona w jednej przestrzeni roboczej zostaje tam, dopóki nie dostarczysz jej do pozostałych, i do tego właśnie służą packages. Przestrzeń robocza może też mieć własny adres, na przykład peeters.labapp.example.com. W hostingu Archestack może też działać pod własną domeną firmy, na przykład app.peeters.be: administrator dodaje ją na stronie Domains w builderze i potwierdza jednym rekordem DNS, a certyfikat pojawia się sam.

Co oddziela przestrzenie robocze od siebie

API i zadania w tle obsługują wszystkie przestrzenie robocze w instancji, ale każde żądanie i każde zaplanowane zadanie pracuje dla dokładnie jednej przestrzeni roboczej:

• Osobne bazy danych. Strony, Business Entities i zapytania jednej przestrzeni roboczej nie mogą sięgnąć do tabel innej.
• Jeden token, jedna przestrzeń robocza. Każde żądanie zalogowanego użytkownika niesie podpisany token, który wskazuje dokładnie jedną przestrzeń roboczą, i otwierane są tylko bazy tej przestrzeni roboczej.
• Żadnego awaryjnego przekierowania. Token wskazujący przestrzeń roboczą, która nie istnieje albo została zawieszona, jest odrzucany, nigdy przekierowywany do innej przestrzeni roboczej.
• Klucze, które wskazują swoją przestrzeń roboczą. Klucze API i tokeny MCP zawierają nazwę przestrzeni roboczej, do której należą, i działają tylko w niej.
• Zadania, które zostają w swojej przestrzeni roboczej. Zaplanowane zadania działają wewnątrz przestrzeni roboczej, do której należą.
• Kopie zapasowe dla każdej przestrzeni roboczej. Kopie zapasowe, przywracanie i eksport obejmują bazy Core i Runtime jednej przestrzeni roboczej, więc dane jednego klienta można przywrócić albo wyeksportować, nie dotykając danych innego.

Jedno konto, rola w każdej przestrzeni roboczej

Konta należą do instancji, członkostwa do przestrzeni roboczej. Każda osoba ma w instancji jedno konto, z jednym adresem e-mail i jednym hasłem, i może być członkiem kilku przestrzeni roboczych, w każdej z inną rolą. Konsultanci partnera mogą być adminami w przestrzeni roboczej każdego laboratorium, którym się opiekują, a pracownicy laboratorium są członkami wyłącznie własnej przestrzeni roboczej.

Ktoś, kto należy do kilku przestrzeni roboczych, przełącza się między nimi z menu awatara. Przy przełączeniu wydawany jest nowy token, który otwiera tę drugą przestrzeń roboczą i tylko ją. Usunięcie kogoś z jednej przestrzeni roboczej nie narusza jego pozostałych członkostw.

Główna przestrzeń robocza i nowe przestrzenie

Każda instancja tworzy główną przestrzeń roboczą przy pierwszym uruchomieniu. Firma, która potrzebuje jednego środowiska, po prostu w niej pracuje. Partner z wieloma klientami zostawia główną przestrzeń roboczą dla własnego zespołu i tworzy osobną przestrzeń roboczą dla każdego klienta. Utworzenie nowej przestrzeni roboczej trwa około sekundy, a na początku jest ona pusta.

Podział przestrzeni roboczej

Dwie funkcje dzielą jedną przestrzeń roboczą jeszcze dalej. Żadna z nich nie tworzy nowego środowiska: obie działają wewnątrz przestrzeni roboczej, na jej własnych bazach Core i Runtime.

• Business Units dzielą ją według zespołów, dzięki czemu każdy zespół widzi strony i Business Entities, które go dotyczą. Nie ukrywają wierszy danych, więc nie są formą oddzielenia.
• Organizacje klientów dzielą ją według klientów. Nie są osobnymi przestrzeniami roboczymi. Działają wewnątrz przestrzeni roboczej laboratorium, a nie obok niej, i nie mają własnych baz danych: klienci laboratorium korzystają z aplikacji laboratorium, to, co wprowadzą, trafia do bazy Runtime laboratorium, a każdy klient widzi tylko własne wiersze. Więcej na ten temat poniżej.

Dwa sposoby hostowania Twoich klientów

Każda przestrzeń robocza działa w instancji: jednej działającej kopii Archestack, z jej API, jej zadaniami w tle i serwerem PostgreSQL, który przechowuje bazy danych jej przestrzeni roboczych. Przestrzenie robocze w jednej instancji dzielą między sobą otaczającą je instancję, ale nie swoje bazy danych:

Przestrzenie robocze w jednej instancji dzielą też jej zasoby: procesor, pamięć i połączenia z bazą danych. Dla każdego klienta partner decyduje, czy jego przestrzeń robocza dostaje własną instancję, czy dzieli ją z przestrzeniami roboczymi innych klientów. W obu modelach każdy klient ma własną przestrzeń roboczą z własnymi bazami Core i Runtime. Różnica polega na tym, ile przestrzeni roboczych dzieli jedną instancję, a więc co dzielą ze sobą nawzajem.

Jedna przestrzeń robocza na instancję (single-tenant)

Lab 1

Archestack

API

Zadania w tle

Core

Runtime

Lab 2

Archestack

API

Zadania w tle

Core

Runtime

Lab 3

Archestack

API

Zadania w tle

Core

Runtime

Każde laboratorium dostaje własną instancję, z własnym API i własnymi zadaniami w tle, oraz przestrzeń roboczą z własnymi bazami Core i Runtime. Ten model pasuje do dużych klientów, do klientów, którzy decydują, gdzie przechowywane są ich dane, i do klientów, którzy sami wybierają moment aktualizacji. Partner może sam utrzymywać te instancje albo zainstalować instancję na koncie chmurowym laboratorium lub w jego centrum danych.

Zalety

• Najsilniejsze możliwe oddzielenie. Nic nie jest współdzielone z innymi klientami, nawet platforma.
• Własne zasoby. Mocno obciążone laboratorium nigdy nie spowalnia innego, a jego instancja jest dobrana wyłącznie do niego.
• Aktualizacje w terminie wybranym przez klienta. Każda instancja przechodzi na nową wersję platformy wtedy, gdy temu klientowi to odpowiada.
• Dane są tam, gdzie chce klient: w wybranym regionie, na jego koncie chmurowym albo na jego własnych serwerach.
• Czyste zakończenie. Przekaż instancję klientowi albo ją wyłącz.

Wady

• Każdą instancję trzeba utrzymywać: serwery, certyfikaty, kopie zapasowe, monitoring i aktualizacje, osobno dla każdego klienta.
• Nową wersję Twojej aplikacji trzeba zaimportować do każdej instancji osobno.
• Twoi pracownicy potrzebują konta w każdej instancji, w której pracują.
• Nawet najmniejszy klient potrzebuje pełnej instancji.

Kilka przestrzeni roboczych na instancję (multi-tenant)

Archestack

API

Zadania w tle

Lab 1

Core

Runtime

Lab 2

Core

Runtime

Lab 3

Core

Runtime

Jedna instancja obsługuje wiele laboratoriów. Każde laboratorium nadal jest osobną przestrzenią roboczą, z własnymi bazami Core i Runtime oraz, jeśli chcesz, własnym adresem, na przykład peeters.labapp.example.com. Administratorzy instancji tworzą nową przestrzeń roboczą w ciągu około sekundy.

Zalety

• Każdy klient nadal ma własne bazy danych, własne kopie zapasowe i własną wersję aplikacji, dopasowaną do tego, jak pracuje.
• Dodanie klienta zajmuje około sekundy, a mało aktywny klient nie kosztuje prawie nic: nieużywana przestrzeń robocza nie utrzymuje żadnych połączeń z bazą danych.
• Jedna instancja do utrzymania, zabezpieczenia i aktualizacji.
• Twoi konsultanci używają jednego konta i przełączają się między klientami z menu awatara.

Wady

• Wszyscy klienci przechodzą na nową wersję platformy w tym samym momencie.
• Klienci współdzielą zasoby instancji, więc dobierz jej rozmiar do nich wszystkich razem. Instancja, w której jednocześnie używa się więcej niż kilkudziesięciu przestrzeni roboczych, wymaga też podniesienia limitu połączeń PostgreSQL powyżej domyślnej wartości 100.
• Nową wersję Twojej aplikacji nadal instaluje się w każdej przestrzeni roboczej osobno, z Module Store instancji albo z pliku ZIP.

Porównanie

Łączenie obu modeli to norma: małe laboratoria dzielą instancję, duża grupa laboratoriów dostaje własną, a do jednych i drugich trafiają te same packages. Środowiska deweloperskie, testowe, akceptacyjne i produkcyjne to osobne przestrzenie robocze. Umieść środowisko deweloperskie, testowe i akceptacyjne w jednej instancji, a produkcyjne w osobnej, żeby aktualizacja platformy trafiła na środowisko akceptacyjne, zanim trafi na produkcję.

Klienci klienta w jego aplikacji

Laboratorium ma własnych klientów: producentów żywności, przedsiębiorstwa wodociągowe i zakłady produkcyjne, które przysyłają próbki. Chcą rejestrować wysyłane próbki i śledzić każdą z nich, gdy laboratorium nad nią pracuje. Jeden producent żywności nigdy nie może zobaczyć próbek innego producenta; laboratorium widzi je wszystkie. Laboratorium może wpuścić tych klientów do aplikacji, którą zbudował dla niego partner, jako organizacje klientów.

Partner buduje aplikację i wybiera hosting w jednym z dwóch opisanych wyżej modeli. Ani laboratorium, ani jego klienci nie zauważają, który to model. Następnie laboratorium zaprasza swoich klientów albo pozwala im zarejestrować się samodzielnie.

Organizacja klienta nie jest przestrzenią roboczą i nie ma własnych baz danych. Działa wewnątrz przestrzeni roboczej laboratorium: aplikacja należy do tej przestrzeni roboczej, każdy klient ma własnych członków, a wszystko, co wprowadzą, trafia do bazy Runtime laboratorium z oznaczeniem firmy, która to zapisała. Każdy klient widzi tylko własne wiersze, laboratorium widzi wszystkie, a klient może mieć własne jednostki podrzędne: na przykład grupa spożywcza może mieć jednostkę dla każdej ze swoich fabryk i po jednej dla każdej linii produkcyjnej w fabryce. Każda jednostka widzi własne wiersze i wiersze jednostek jej podległych. Klienci używają aplikacji w takiej postaci, w jakiej publikuje ją laboratorium, i jej nie zmieniają, a administrator każdego klienta sam zaprasza i usuwa współpracowników.

Infrastruktura hostingowa

Archestack jest dostarczany jako jeden obraz kontenera, który uruchamia zarówno API, jak i zadania w tle: Scheduled Events, wysyłkę poczty, uruchomienia zestawów testów, synchronizacje z innymi systemami i nocne kopie zapasowe. Skaluje się poziomo: uruchamiasz więcej kopii tego samego obrazu za load balancerem, gdy rośnie liczba użytkowników. Kopie koordynują się przez PostgreSQL, więc zaplanowana praca jest dzielona między nie, a każde zadanie wykonuje się tylko raz.

Load balancer

Obraz Archestack

API

Zadania w tle

Obraz Archestack

API

Zadania w tle

Obraz Archestack

API

Zadania w tle

Skaluje się poziomo

PG

Uruchomienie więcej niż jednej kopii stawia kilka wymagań otaczającej ją infrastrukturze:

• Bez sticky sessions, ale WebSockety muszą przechodzić. Każda kopia może odpowiedzieć na każde żądanie. Aktualizacje na żywo (odświeżające się tabele, kto jeszcze jest na stronie, powiadomienia) idą wyłącznie przez WebSockety, więc load balancer lub sieć, które je blokują, zostawiają działającą aplikację, ale bez aktualizacji na żywo.
• Wspólne woluminy na kopie zapasowe i pliki. Folder kopii zapasowych i folder z plikami każdej przestrzeni roboczej (przesłane pliki, logo, pliki zapisywane przez skrypty) muszą leżeć na magazynie montowanym przez każdą kopię (w Kubernetes wolumin ReadWriteMany), inaczej każda kopia widzi tylko kopie zapasowe i pliki, które sama zapisała.
• Startup probe. Kopie startujące razem przygotowują bazy danych po kolei, a przy wielu przestrzeniach roboczych do migracji trwa to chwilę. Daj kontenerom startup probe zamiast krótkiej liveness probe.
• Limity żądań są na kopię. Trzy kopie pozwalają jednemu wywołującemu na trzy razy więcej żądań niż jedna.
• Za PgBouncerem w trybie transakcyjnym skieruj ConnectionStrings__Cluster bezpośrednio na PostgreSQL: kopie rozmawiają ze sobą przez połączenie PostgreSQL, które musi pozostać otwarte.

Oprócz kontenerów instancja potrzebuje PostgreSQL 16 i proxy, które obsługuje TLS. Działa wszędzie tam, gdzie działają kontenery: na pojedynczym serwerze, na koncie w chmurze albo w klastrze Kubernetes. Może ją hostować partner, może ją hostować Archestack, może też działać na własnej infrastrukturze klienta. Dla Kubernetes jest chart Helm, a instancja może też działać pod ścieżką nazwy hosta należącej do innej aplikacji, na przykład apps.example.com/archestack/.

Nowa instancja nie ma użytkowników. Pierwsza osoba, która ją otworzy, tworzy pierwszego administratora, więc skonfiguruj ją, zanim będzie dostępna z internetu.

Strona Wydajność i dobór serwerów podaje zmierzone liczby: ile osób i przestrzeni roboczych obsługuje instancja i jakich serwerów do tego potrzebuje. Strona Hosting na AKS pokazuje, jak zainstalować instancję w Azure Kubernetes Service tak, żeby sama pozostawała na najnowszym wydaniu; strona Hosting z Dockerem robi to samo na jednym serwerze.

Jak dostarczyć aplikację do każdego klienta

Gdy każdy klient ma własną przestrzeń roboczą, każda nowa wersja aplikacji musi do niej dotrzeć. Służy do tego package:

1. Dodaj do package'a tabele, Business Entities, strony, Business Events, Script Modules, PDF Templates, Scheduled Events, zestawy testów i układy aplikacji swojej aplikacji, a potem wyeksportuj go jako ZIP.
2. Zaimportuj go do przestrzeni roboczej klienta. Import najpierw pokazuje plan, a potem wprowadza zmiany tabel w bazie Runtime tej przestrzeni roboczej.
3. Uruchom tam zestawy testów z package'a. Testy działają w osobnej bazie sandbox i nigdy nie dotykają danych klienta.
4. Opublikuj wydanie (release). To moment, w którym nowe strony docierają do użytkowników klienta. W przestrzeni roboczej, w której nigdy nie opublikowano wydania, strony są widoczne zaraz po zakończeniu importu.

Niektóre rzeczy konfiguruje się w każdej przestrzeni roboczej osobno, zamiast je dostarczać: endpointy i klucze Data API, tłumaczenia, użytkowników, role, Business Units, branding, konta pocztowe i połączenia z innymi systemami. Wszystko, co było oznaczone jako publiczne, trafia na miejsce jako prywatne, więc sama instalacja package'a nigdy nie udostępni danych klienta w internecie.

W obrębie jednej instancji moduł opublikowany w Module Store jako publiczny widzi i może zainstalować każda przestrzeń robocza tej instancji, co pozwala obejść się bez eksportu i importu. Prywatny wpis widzi tylko przestrzeń robocza, która go opublikowała. Między instancjami packages wędrują jako pliki ZIP.

Gdy aplikacja znajduje się w repozytorium git, strona Strategia wdrożeń opisuje, jak pipeline ją testuje i wdraża na każde środowisko bez przerwy w działaniu.

Pułapki

• Aktualizacja platformy trafia naraz do wszystkich przestrzeni roboczych w instancji. Klient, który musi zostać przy danej wersji, potrzebuje własnej instancji.
• Nowa przestrzeń robocza jest na początku pusta. Zainstaluj w niej swoje packages i zaproś do niej ludzi; członkostwa nie przenoszą się z innych przestrzeni roboczych.

Co dalej

Sekcja Packages opisuje budowę i eksport package'a, który dostarczasz do każdej przestrzeni roboczej. Przewodnik po Data API pokazuje, jak usługa łączy się z jedną przestrzenią roboczą za pomocą klucza API, a sekcja Database Backups opisuje kopie zapasowe poszczególnych przestrzeni roboczych.