Wdrożenie modułu

Gotowy moduł publikujesz w repozytorium modułów (modules.orbito.pl), skąd firmy mogą go zainstalować. Platforma uruchamia każdy moduł w izolowanym kontenerze Docker — nie ma potrzeby konfigurowania środowiska po stronie serwera.

Do publikacji potrzebujesz konta Orbito i namespace'u, do którego należy moduł — patrz Konto i namespace'y.

Do publikacji służy omm (Orbito Modules Manager) — oficjalne CLI, odpowiednik npm publish dla modułów Orbito. Jedna komenda pakuje moduł, wysyła go do repozytorium, uruchamia build obrazu Dockera i czeka na jego wynik.

Szybki start

npm config set @orbito:registry https://git.kozminski.net.pl/api/packages/orbito/npm/   # scope @orbito w ~/.npmrc (raz)
npm i -g @orbito/omm     # instalacja CLI (raz)
omm login                # logowanie kontem Orbito: rdzeń + repozytorium (raz)
omm namespace create acme  # namespace na moduły (raz; albo dołącz do istniejącego)

cd moj-modul
omm publish              # wersja robocza (draft) — do testów
omm publish --release    # publikacja w rejestrze — widoczna dla firm

Pełny opis komend i flag znajdziesz w omm — CLI do publikacji.

Wymagania przed wdrożeniem

Przed publikacją upewnij się, że moduł spełnia poniższe wymagania:

• [ ] Plik index.js istnieje w katalogu głównym modułu
• [ ] Plik module.json zawiera pełny kod modułu (namespace/nazwa) i wersję semver — patrz Struktura modułu
• [ ] Wersja w module.json jest wyższa niż ostatnio opublikowana
• [ ] Plik package.json zawiera poprawne name, version i main wskazujące na index.js
• [ ] Zależność @orbito/api-lib jest wymieniona w dependencies
• [ ] Wszystkie metody są zarejestrowane przez Core.registerMethod()
• [ ] Strony (jeśli są) są zarejestrowane przez Pages.registerPages()
• [ ] Karta modułu istnieje w rejestrze w Twoim namespace — tworzy ją omm init <nazwa> albo panel developera (omm publish nie tworzy jej automatycznie)
• [ ] Moduł został przetestowany lokalnie

Proces wdrożenia

Wdrożenie modułu przebiega w czterech krokach:

1. Podbicie wersji — zwiększ pole version w module.json (to ono jest źródłem prawdy przy publikacji)
2. Kontrola paczki — omm pack --dry-run pokazuje dokładną listę plików, które trafią do archiwum
3. Wersja robocza — omm publish wysyła draft i czeka na build obrazu Dockera; draft służy do testów — widzą go tylko członkowie namespace'u i firmy z dostępem do modułu
4. Publikacja — omm publish --release przenosi wersję ze stanu roboczego do rejestru; poprzednia opublikowana wersja przechodzi w stan deprecated

Draft o tej samej wersji można nadpisywać dowolną liczbę razy (retry bez podbijania wersji). Wersje opublikowane są niemutowalne — poprawka wymaga nowej wersji.

Zasoby kontenera

Kontener modułu działa stale — startuje przy instalacji, reaktywacji, aktualizacji wersji i starcie rdzenia, a zatrzymuje go tylko wyłączenie lub odinstalowanie instancji. Domyślnie dostaje 128 MB RAM i 0.5 rdzenia CPU; limit ustawia operator platformy, a nie autor modułu. Przekroczenie pamięci kończy się restartem kontenera (OOM) i problemem MODULE_OOM widocznym dla firmy w rejestrze problemów. Moduł powinien więc zwalniać zasoby: nie trzymaj dużych tablic w pamięci i przetwarzaj importy strumieniowo.

Kontenery modułów mogą działać nie tylko na pojedynczym serwerze Docker, ale też w klastrze Kubernetes. Dla modułu nic się nie zmienia: obowiązują te same limity zasobów, a status, logi, statystyki i problem MODULE_OOM przy braku pamięci wyglądają tak samo.

Aktualizacja modułu

1. Wprowadź zmiany w kodzie
2. Podbij version w module.json (i dla porządku w package.json)
3. omm publish --changelog "opis zmian" — wyślij draft, zainstaluj go we własnej firmie (omm install / omm update) i sprawdź omm logs
4. omm publish --release — udostępnij nową wersję firmom