Nasazení na server: Proxmox LXC a Docker #13

Merged
david-spacil merged 4 commits from agents/claude/nasazeni into main 2026-08-22 21:32:13 +02:00
Owner

Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku. Obojí počítá jen s domácí sítí — appka nemá přihlašování a ani jedno nasazení ji nijak nezabezpečuje.

Proxmox

Jeden příkaz na uzlu, jako root — tak, jak se to u community-scripts čeká:

bash -c "$(curl -fsSL https://gitea.spacilovi.eu/david-spacil/dice-counter/raw/branch/main/deploy/pve-kostky.sh)"

Založí kontejner (Debian 13, neprivilegovaný, DHCP), počká na síť, stáhne vydanou binárku, ověří kontrolní součet a zapíše systemd službu. Aktualizace je ten samý příkaz s CTID=123 MODE=update.

Instalátor, který běží uvnitř kontejneru, je ve skriptu vložený jako text v heredocu. Jinak to nejde: přes rouru z curlu není na disku hostitele žádný soubor, který by šel poslat dovnitř. Duplicita tím nevzniká — vypsat se dá zpátky přes bash pve-kostky.sh instalator, když ho chce někdo pustit v kontejneru, který si založil sám.

Úložiště se nehádá. local-lvm na ZFS instalacích neexistuje a pct create by spadlo až po půlce práce. Teď se vybere první aktivní úložiště pro kontejnery, a když se nějaké vnutí přes STORAGE=, ověří se, že vůbec existuje.

Podoba je odkoukaná od community-scripts.org, ale nic z jejich frameworku se nestahuje. Jejich build.func si instalační skript hledá natvrdo ve vlastním repozitáři:

_install_script="$(curl -fsSL \
  "https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/${var_install}.sh")"

Ta adresa se nedá přebít, takže skript v cizím repozitáři by kontejner vytvořil a pak spadl.

Docker

cd deploy && docker compose up -d

Staví se ze zdrojáků, ne z binárky — image pak jde sestavit pro amd64 i arm64 a nezávisí na tom, jestli release pro danou architekturu proběhl. Zamčené závislosti z minulého PR dělají sestavení opakovatelné. Běží pod nerootovým uživatelem, databáze v pojmenovaném svazku.

Compose používá síť hostitele, a to je podstatné. V bridge režimu vidí kontejner uvnitř adresu 172.17.0.2, tabule ji poctivě nabídne a udělá na ni QR kód — jenže z telefonu je nedosažitelná.

Aplikace se měnit nemusela

DICE_DB, DICE_PORT a DICE_HOST pokrývají obojí. V LXC má kontejner vlastní adresu v LAN, takže hledání adres i QR kód fungují beze změny. Řádkové bufferování z minulého PR se sem trefilo: bez něj by v journalctl ani v docker logs po startu nebylo nic.


Ověřeno

Docker — skutečně postaveno a spuštěno:

  • appka běží jako uid=1000(kostky), databáze na svazku patří jí
  • /, /board, /static, /export odpovídají, healthcheck hlásí healthy
  • bridge režim ověřen empiricky, ne odhadnut: bez DICE_HOST tabule nabídne 172.17.0.3, s DICE_HOST=192.168.1.10 správnou adresu

LXC instalátor — projet v debian:13 se zástupným systemctl:

  • zjištění posledního tagu z Gitea API, stažení a ověření součtu proti skutečnému releasu v1.1.0
  • založení uživatele, rozmístění souborů, zápis unit souboru, čekání na odpověď
  • projeto znovu po vložení do heredocu, s instalátorem vytaženým zpátky ven — chová se stejně

Roura z curlu: skript stažený ze skutečné adresy v Gitee projde bash -n a bash -c "$(curl …)" se chová správně, včetně vnořeného instalátoru.

Čím jsem si jistý míň: proti skutečnému Proxmoxu jsem to nespustil — nemám ho. Ověřená je syntaxe a logika, ne chování pct create, pveam a pvesm na živém uzlu. Systemd unit běžela jen pod atrapou.

Jedna věc k releasu

Dnes se nainstaluje v1.1.0, protože novější tag není. To vydání ještě nemá --version, /export, waitress ani verzované schéma. Na to jsem při zkoušce narazil doslova — instalátor původně končil voláním kostky --version, což na v1.1.0 místo výpisu nastartovalo server a skript zůstal viset. Verze se teď čte ze souboru, ne z binárky.

Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku. Obojí počítá **jen s domácí sítí** — appka nemá přihlašování a ani jedno nasazení ji nijak nezabezpečuje. ## Proxmox Jeden příkaz na uzlu, jako root — tak, jak se to u community-scripts čeká: ```bash bash -c "$(curl -fsSL https://gitea.spacilovi.eu/david-spacil/dice-counter/raw/branch/main/deploy/pve-kostky.sh)" ``` Založí kontejner (Debian 13, neprivilegovaný, DHCP), počká na síť, stáhne vydanou binárku, **ověří kontrolní součet** a zapíše systemd službu. Aktualizace je ten samý příkaz s `CTID=123 MODE=update`. Instalátor, který běží uvnitř kontejneru, je ve skriptu vložený jako text v heredocu. Jinak to nejde: přes rouru z curlu není na disku hostitele žádný soubor, který by šel poslat dovnitř. Duplicita tím nevzniká — vypsat se dá zpátky přes `bash pve-kostky.sh instalator`, když ho chce někdo pustit v kontejneru, který si založil sám. **Úložiště se nehádá.** `local-lvm` na ZFS instalacích neexistuje a `pct create` by spadlo až po půlce práce. Teď se vybere první aktivní úložiště pro kontejnery, a když se nějaké vnutí přes `STORAGE=`, ověří se, že vůbec existuje. Podoba je odkoukaná od community-scripts.org, ale **nic z jejich frameworku se nestahuje**. Jejich `build.func` si instalační skript hledá natvrdo ve vlastním repozitáři: ```bash _install_script="$(curl -fsSL \ "https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/${var_install}.sh")" ``` Ta adresa se nedá přebít, takže skript v cizím repozitáři by kontejner vytvořil a pak spadl. ## Docker ```bash cd deploy && docker compose up -d ``` Staví se ze zdrojáků, ne z binárky — image pak jde sestavit pro amd64 i arm64 a nezávisí na tom, jestli release pro danou architekturu proběhl. Zamčené závislosti z minulého PR dělají sestavení opakovatelné. Běží pod nerootovým uživatelem, databáze v pojmenovaném svazku. **Compose používá síť hostitele, a to je podstatné.** V bridge režimu vidí kontejner uvnitř adresu `172.17.0.2`, tabule ji poctivě nabídne a udělá na ni QR kód — jenže z telefonu je nedosažitelná. ## Aplikace se měnit nemusela `DICE_DB`, `DICE_PORT` a `DICE_HOST` pokrývají obojí. V LXC má kontejner vlastní adresu v LAN, takže hledání adres i QR kód fungují beze změny. Řádkové bufferování z minulého PR se sem trefilo: bez něj by v `journalctl` ani v `docker logs` po startu nebylo nic. --- ## Ověřeno **Docker — skutečně postaveno a spuštěno:** - appka běží jako `uid=1000(kostky)`, databáze na svazku patří jí - `/`, `/board`, `/static`, `/export` odpovídají, healthcheck hlásí `healthy` - **bridge režim ověřen empiricky**, ne odhadnut: bez `DICE_HOST` tabule nabídne `172.17.0.3`, s `DICE_HOST=192.168.1.10` správnou adresu **LXC instalátor — projet v `debian:13` se zástupným `systemctl`:** - zjištění posledního tagu z Gitea API, stažení a ověření součtu proti skutečnému releasu v1.1.0 - založení uživatele, rozmístění souborů, zápis unit souboru, čekání na odpověď - projeto znovu po vložení do heredocu, s instalátorem vytaženým zpátky ven — chová se stejně **Roura z curlu:** skript stažený ze skutečné adresy v Gitee projde `bash -n` a `bash -c "$(curl …)"` se chová správně, včetně vnořeného instalátoru. **Čím jsem si jistý míň:** proti skutečnému Proxmoxu jsem to nespustil — nemám ho. Ověřená je syntaxe a logika, ne chování `pct create`, `pveam` a `pvesm` na živém uzlu. Systemd unit běžela jen pod atrapou. ## Jedna věc k releasu Dnes se nainstaluje **v1.1.0**, protože novější tag není. To vydání ještě nemá `--version`, `/export`, waitress ani verzované schéma. Na to jsem při zkoušce narazil doslova — instalátor původně končil voláním `kostky --version`, což na v1.1.0 místo výpisu nastartovalo server a skript zůstal viset. Verze se teď čte ze souboru, ne z binárky.
david-spacil added 1 commit 2026-08-22 19:13:43 +02:00
Nasazení na server: Proxmox LXC a Docker
binárka / linux (pull_request) Successful in 10s
testy / pytest (3.11) (pull_request) Successful in 1s
testy / pytest (3.12) (pull_request) Successful in 1s
testy / pytest (3.13) (pull_request) Successful in 1s
testy / pytest (3.14) (pull_request) Successful in 0s
eaa9c12ebc
Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku.

pve-kostky.sh se pouští na uzlu Proxmoxu, založí kontejner a předá řízení
lxc-install.sh, který uvnitř stáhne vydanou binárku, ověří kontrolní součet
a zapíše službu. Ty dva jsou oddělené schválně: instalátor o Proxmoxu nic
neví, takže se dá pustit i v kontejneru, který sis založil sám. Podoba je
odkoukaná od community-scripts.org, ale nic z jejich frameworku se nestahuje
— jejich build.func si instalační skript hledá natvrdo ve vlastním
repozitáři, takže mimo něj nefunguje.

Docker se staví ze zdrojáků, ne z binárky: image pak jde sestavit pro obě
architektury a nezávisí na tom, jestli release proběhl. Zamčené závislosti
z minula dělají sestavení opakovatelné.

Compose používá síť hostitele, a to je podstatné. V bridge režimu vidí
kontejner uvnitř adresu 172.17.0.2, tabule ji poctivě nabídne a udělá na ni
QR kód — jenže z telefonu je nedosažitelná. Ověřeno, ne odhadnuto; kdo bridge
potřebuje, musí nastavit DICE_HOST.

Aplikace sama nepotřebovala změnit nic. DICE_DB, DICE_PORT a DICE_HOST
pokrývají obojí a v LXC má kontejner vlastní adresu v LAN, takže hledání
adres i QR kód fungují beze změny.
david-spacil added 1 commit 2026-08-22 19:22:57 +02:00
Jeden příkaz místo dvou stažených souborů
binárka / linux (pull_request) Successful in 10s
testy / pytest (3.11) (pull_request) Successful in 0s
testy / pytest (3.12) (pull_request) Successful in 0s
testy / pytest (3.13) (pull_request) Successful in 1s
testy / pytest (3.14) (pull_request) Successful in 1s
746916a755
Instalace teď vypadá tak, jak se u community-scripts čeká:

    bash -c "$(curl -fsSL .../deploy/pve-kostky.sh)"

Dva soubory to neuměly. Přes rouru z curlu není na disku hostitele žádný
soubor, který by šel poslat do kontejneru, takže se instalátor přesunul
dovnitř skriptu jako text v heredocu. Duplicita tím nevzniká — vypsat se dá
zpátky přes `bash pve-kostky.sh instalator`, když ho chce někdo pustit
v kontejneru, který si založil sám.

Argumenty se rourou předávají mizerně, tak jde všechno i proměnnou:
CTID=123 MODE=update. Ze staženého souboru funguje i pozičně.

Ke stejné příležitosti: úložiště se přestalo hádat. local-lvm na ZFS
instalacích neexistuje a pct create by spadlo až po půlce práce; teď se
vybere první aktivní, a když se nějaké vnutí, ověří se, že vůbec existuje.
david-spacil added 1 commit 2026-08-22 21:21:12 +02:00
Šablonu vybírat podle architektury uzlu
binárka / linux (pull_request) Successful in 10s
testy / pytest (3.11) (pull_request) Successful in 1s
testy / pytest (3.12) (pull_request) Successful in 1s
testy / pytest (3.13) (pull_request) Successful in 1s
testy / pytest (3.14) (pull_request) Successful in 2s
861470da55
pveam nabízí amd64 i arm64 vedle sebe a výběr přes `sort -V | tail -1` padl
na tu abecedně poslední — tedy arm64 i na x86 uzlu. Šablona, která na uzlu
už ležela, se pak nenašla a skript začal stahovat 120 MB nepoužitelného
archivu.

Architektura se teď bere z dpkg --print-architecture a nejdřív se kouká, co
na uzlu už je; stahuje se, až když tam nic nesedí. Neúspěšné stažení navíc
skript zastaví, místo aby se šlo zakládat kontejner ze šablony, která není.

Ke stejné příležitosti Ctrl+C: bez trapu zabil jen rozdělaný podproces
a skript pokračoval dál — v hlášení od uživatele je vidět, jak po přerušeném
stahování vesele oznámil hotovou šablonu a pustil se do pct create.
david-spacil added 1 commit 2026-08-22 21:23:55 +02:00
Zapnout kontejneru nesting
binárka / linux (pull_request) Successful in 10s
testy / pytest (3.11) (pull_request) Successful in 1s
testy / pytest (3.12) (pull_request) Successful in 0s
testy / pytest (3.13) (pull_request) Successful in 1s
testy / pytest (3.14) (pull_request) Successful in 1s
83654fe6b5
Debian 13 veze systemd 257 a ten v neprivilegovaném LXC bez nestingu
nedostane, co potřebuje — Proxmox na to při startu sám upozorňuje hláškou
"Systemd 257 detected. You may need to enable nesting."

Appka i tak nastartovala, ale spoléhat se na to nemá cenu. Stejnou výchozí
hodnotu mají i community-scripts a sami varují, že moderní distribuce se
systemd nesting potřebují.
david-spacil merged commit fc2df8d86e into main 2026-08-22 21:32:13 +02:00
david-spacil deleted branch agents/claude/nasazeni 2026-08-22 21:32:17 +02:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: david-spacil/dice-counter#13