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

Dziewięć usług i siedem nazw profili — Server i Client mają po dwie, dzięki czemu można podnieść jedną połowę bez drugiej.

Cztery to punkt odniesienia, a nie minimum. Tyle pasuje do ośmiu rdzeni fizycznych i zostawia cztery na całą resztę; na mniejszej maszynie uruchom mniej, bo więcej Runnerów niż rdzeni fizycznych nie przyspiesza oceniania, a psuje jego rzetelność. 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 piąty 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 i uruchamia COMPOSE_PROFILES=runner z trzema wartościami w swoim .env:

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

Przedrostek nazywa wszystkie cztery — lab-a-1 do lab-a-4 — 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 czterema Runnerami to cztery 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