← Wszystkie podręczniki
W trakcie budowy · wersja robocza wymaga manifestu wydania
Podręcznik techniczny
Budowanie SIFYBOX z wielu usług
W jaki sposób kompilować wersjonowane obrazy do usług, których potrzebuje dany proces, i uruchamiać każdą z nich lokalnie lub zdalnie.
01
1. Trzy warstwy dostawy
- DERS opublikuje niezmienny plik bazowy compose.yaml oraz manifest wydania z pełnymi nazwami obrazów i ich skrótami.
- Instalacja doda wartości niebędące tajnymi do pliku site.env: publiczny adres URL, adresy usług, strefę czasową i wybrany tryb działania.
- Hasła, tokeny i certyfikaty są przekazywane osobno jako pliki tajne Docker lub za pośrednictwem Vault. Nie powinny znajdować się w wersji ani w Git.
- Zmiana klienta jest dokonywana w obsługiwanym pliku nadrzędnym lub za pośrednictwem zmiennych, a nie poprzez modyfikację bazy dostawców.
02
2. Parametry obrazu i wydania
Host rejestru jest wspólny, ale pełne ścieżki, nazwy i skróty muszą pochodzić z manifestu obsługiwanego przez wydanie. Poniższa notacja to docelowy wzorzec projektowy, a nie gotowy podręcznik wydania.
Przykład roboczyZastąp wartości <…> danymi z wydania
# .env.release — spravuje DERS spolu s konkrétním releasem
# Úplné názvy image a digesty se přebírají z release manifestu.
OOD_IMAGE=registry.ders.cz/<PROJECT>/<OOD_IMAGE>@sha256:<DIGEST>
DOG_IMAGE=registry.ders.cz/<PROJECT>/<DOG_IMAGE>@sha256:<DIGEST>
FS_IMAGE=registry.ders.cz/<PROJECT>/<FS_IMAGE>@sha256:<DIGEST>
ZST_IMAGE=registry.ders.cz/<PROJECT>/<ZST_IMAGE>@sha256:<DIGEST>
EPK_IMAGE=registry.ders.cz/<PROJECT>/<EPK_IMAGE>@sha256:<DIGEST>
WSCS_IMAGE=registry.ders.cz/<PROJECT>/<WSCS_IMAGE>@sha256:<DIGEST>
CUL_IMAGE=registry.ders.cz/<PROJECT>/<CUL_IMAGE>@sha256:<DIGEST>
CULWS_IMAGE=registry.ders.cz/<PROJECT>/<CULWS_IMAGE>@sha256:<DIGEST>
POSTGRES_IMAGE=<SUPPORTED_POSTGRES_IMAGE>@sha256:<DIGEST>
# .env.site — nesekretní parametry konkrétní instalace
PUBLIC_BASE_URL=https://<SIFYBOX_FQDN>
TZ=Europe/Prague
DOG_BASE_URL=http://dog:<PORT_FROM_RELEASE>
FS_BASE_URL=http://fs:<PORT_FROM_RELEASE>
ZST_BASE_URL=http://zst:<PORT_FROM_RELEASE>
EPK_BASE_URL=http://epk:<PORT_FROM_RELEASE>
WSCS_BASE_URL=http://wscs:<PORT_FROM_RELEASE>
CUL_BASE_URL=http://cul:<PORT_FROM_RELEASE>
CULWS_BASE_URL=http://culws:<PORT_FROM_RELEASE>03
3. Włączanie usług lokalnych
Docelowy wzorzec projektowy: każda opcjonalna usługa ma swój własny profil Compose. Gdy profil nie jest włączony, adres BASE_URL musi wskazywać na zweryfikowaną zdalną instancję. Konkretne profile i zmienne muszą zostać zatwierdzone przez repozytorium aplikacji.
Przykład roboczyZastąp wartości <…> danymi z wydania
name: sifybox
services:
ood:
image: ${OOD_IMAGE:?OOD_IMAGE is required}
env_file:
- /etc/sifybox/env/site.env
environment:
DOG_BASE_URL: ${DOG_BASE_URL:?DOG_BASE_URL is required}
FS_BASE_URL: ${FS_BASE_URL:?FS_BASE_URL is required}
ZST_BASE_URL: ${ZST_BASE_URL:?ZST_BASE_URL is required}
EPK_BASE_URL: ${EPK_BASE_URL:?EPK_BASE_URL is required}
CUL_BASE_URL: ${CUL_BASE_URL:?CUL_BASE_URL is required}
CULWS_BASE_URL: ${CULWS_BASE_URL:?CULWS_BASE_URL is required}
secrets:
- db_password
dog:
image: ${DOG_IMAGE:?DOG_IMAGE is required}
profiles: [dog-local]
networks: [sifybox-backend]
fs:
image: ${FS_IMAGE:?FS_IMAGE is required}
profiles: [fs-local]
networks: [sifybox-backend]
zst:
image: ${ZST_IMAGE:?ZST_IMAGE is required}
profiles: [zst-local]
networks: [sifybox-backend]
epk:
image: ${EPK_IMAGE:?EPK_IMAGE is required}
profiles: [epk-local]
networks: [sifybox-backend]
wscs:
image: ${WSCS_IMAGE:?WSCS_IMAGE is required}
profiles: [wscs-local]
networks: [sifybox-backend]
cul:
image: ${CUL_IMAGE:?CUL_IMAGE is required}
profiles: [cul-local]
networks: [sifybox-backend]
culws:
image: ${CULWS_IMAGE:?CULWS_IMAGE is required}
profiles: [culws-local]
networks: [sifybox-backend]
networks:
sifybox-backend:
internal: true
secrets:
db_password:
file: /etc/sifybox/secrets/db_password04
4. Tryb lokalny i zdalny
Przykład roboczyZastąp wartości <…> danymi z wydania
# Lokální sestava: služby běží jako kontejnery stejného Compose projektu
docker compose --env-file /etc/sifybox/env/release.env --env-file /etc/sifybox/env/site.env config --quiet
# Vzdálená služba: její profil se nezapne a BASE_URL vede na řízený endpoint.
# Příklad: WSCS_BASE_URL=https://<REMOTE_WSCS_FQDN>
docker compose --env-file /etc/sifybox/env/release.env --env-file /etc/sifybox/env/site.env config --quietUwaga: Samo wyłączenie profilu nie wystarczy. Przed rozpoczęciem walidacji należy zweryfikować dostępność usługi zdalnej, TLS, uwierzytelnianie, kompatybilność wersji API oraz zakaz cyklicznego lub publicznie niepożądanego kierowania ruchem sieciowym.
05
5. Zasady dla każdej usługi opcjonalnej
- Tylko jeden aktywny cel: lokalny kontener lub zdalny punkt końcowy.
- Ta sama wersja kontraktu API w obu trybach.
- Osobny test stanu zdrowia/gotowości i jasno określone oczekiwane wyniki.
- TLS i identyfikacja techniczna nawet w obrębie zaufanej sieci, jeśli wymaga tego model bezpieczeństwa.
- Limit czasu, ponowna próba, wyłącznik i identyfikator korelacji opisane w profilu integracji.
- Zmiana trybu jest kontrolowaną zmianą z opcją testu i powrotu, a nie edycją na żywo.
06
6. Przykład decyzji o składzie
- OOD lokalnie: rdzeń konkretnej instalacji i definicja jej procesu.
- DOG lokalnie lub współdzielony: w zależności od wrażliwości danych wejściowych, wydajności i odpowiedzialności za szablon.
- FS i ZST lokalnie lub jako zarządzana usługa wewnętrzna: tylko po potwierdzeniu rozdziału najemców i uprawnień.
- EPK i WSCS lokalnie lub zdalnie: w zależności od architektury podpisów, dostępności modułu HSM i dostawcy podpisów.
- CUL/CULWS według lokalizacji dokumentu, jego przechowywania, wydajności i powiązania eSSL.
- Każda decyzja jest rejestrowana w dzienniku instalacji, łącznie z danymi właściciela, strumienia danych i metodą odzyskiwania.
Następna instrukcja