Czym jest instalacja

Instalacja AlgoJudge to stos Docker Compose. Dostarczamy go jako osobne repozytorium, AlgoJudge-Ops: klonujesz je, konfigurujesz przez plik .env i uruchamiasz.

To repozytorium nie zawiera kodu aplikacji i niczego nie buduje. Każdy obraz pobieramy z GHCR po tagu i właśnie dlatego aktualizacja sprowadza się do docker compose pull, a wycofanie do wskazania digestu. Pliki Compose, które budują ze źródeł, leżą w repozytoriach produktowych i są tam oznaczone jako deweloperskie; to co innego.

Usługi

Siedem usług pod siedmioma nazwami profili. Server i Client mają po dwie, dzięki czemu można podnieść jedną połowę bez drugiej; oba Runnery dzielą jeden profil.

Do maszyny dopasowuje się tory, a nie Runnery. Runner ocenia równocześnie tyle testów jednego zgłoszenia, ile mówi RUNNER_TESTS_AT_ONCE — każdy na własnym torze — a jeden tor to praca za jeden rdzeń, więc poszerzenie Runnera wymaga od maszyny tyle samo, co dołożenie kolejnego. Więcej torów niż rdzeni fizycznych nie przyspiesza oceniania, a psuje jego rzetelność — i dlatego host, któremu zostaje zapas mocy, podnosi RUNNER_TESTS_AT_ONCE, zamiast dokładać trzeci Runner. Tabelę znajdziesz w Czego wymaga host.

Niosą je trzy sieci Compose, żeby baza nie była osiągalna z krawędzi, a ruch oceniania dał się oddzielić od HTTP:

Server jako jedyny stoi we wszystkich trzech. PostgreSQL siedzi wyłącznie w backend i w żadnym układzie nie ma portu na hoście. Port do sieci publikuje tylko nginx; dwie publikacje na pętli zwrotnej wymienione wyżej są po to, żeby dało się użyć curl i podstawić własne proxy.

Sieć edge ma jawnie zapisaną podsieć, domyślnie 172.28.0.0/24. To nie kwestia porządku: Server odmawia startu, dopóki nie wskażesz mu, czyim słowom o adresie odwiedzającego ma wierzyć, a podsieci wylosowanej przez Dockera nie dałoby się nazwać.

Cztery układy

Wybierasz je przez COMPOSE_PROFILES w .env. Żaden nie wymaga edycji pliku Compose.

external-runner to dodatek do każdego z nich, a nie kolejny układ. Dopisz go obok runner albo daj mu osobną maszynę; nie ma go w zestawie domyślnym, bo loguje się do zewnętrznego archiwum na tamtejsze konto — Zewnętrzny sędzia mówi, czego wymaga i czego za Ciebie nie zrobi.

Runner może działać na zupełnie innej maszynie

Każdy host z Runnerem klonuje to samo repozytorium, przełącza je na wydanie, na którym działa host aplikacji, i uruchamia COMPOSE_PROFILES=runner z dwiema wartościami w swoim .env:

SERVER_URL=https://twoja.domena
RUNNER_NAME_PREFIX=lab-a       # inny na każdym hoście

Taki host potrzebuje Dockera Engine 26 lub nowszego (albo Podmana 5) i miejsca tam, gdzie Docker trzyma wolumeny: pamięć podręczna i katalogi robocze Runnerów leżą na maszynie, która ocenia, a nie na hoście aplikacji. Na starszym silniku Runner odmawia oceniania i nie ma układu, który by to obchodził — patrz Gdzie Runnery trzymają swoje bajty.

Przedrostek nazywa każdy Runner na hoście — lab-a-1 i lab-a-2 — i musi się różnić między hostami, inaczej Runnery z dwóch maszyn pojawią się w panelu pod tymi samymi nazwami.

Każde połączenie nawiązuje sam Runner. Nie potrzebuje portu przychodzącego i pracuje zza domowego routera, bez własnego adresu. W compose.yaml celowo nie ma depends_on na Server: na hoście z samym Runnerem nie ma usługi Server, na której można by polegać — Runner sam ponawia próby połączenia.

Każdy Runner rejestruje się osobno i każdy wymaga osobnego zatwierdzenia, więc host z dwoma Runnerami to dwa zatwierdzenia.

Co działa obok stosu, a nie w nim

Instalacja potrzebuje dostawcy OIDC i żadne z dwóch wspieranych wdrożeń tożsamości nie jest usługą w compose.yaml. Działa obok tego stosu, pod własną nazwą hosta. Tożsamość to rozdział o wyborze i rejestracji dostawcy.

Dokąd dalej