Druhý krok po #16, rovnou celý. Dvojkolejnost dávala smysl pro projekt
s neznámými uživateli; tady běží jedna instance a ta je přemigrovaná.
Pryč je:
- deploy/pve-kostky.sh (přesměrování na nový skript)
- stěhování ze starého jména v instalátoru včetně bloku STARY_*
- záložní jméno přílohy kostky-* v instalátoru
- věšení příloh pod dvěma jmény v obou workflow
- záloha na ~/.local/share/kostky/dice.db ve storage.py
- odstavce o přechodu v README
Jediné, co ve zdrojácích zůstalo, je docstring "Pravidla hry v kostky"
v core.py — to je česky pojmenovaná hra, ne identifikátor.
POZOR na pořadí: instalátor teď hledá jen dice-counter-*, a poslední
vydání (v1.2.1) má na releasu pouze kostky-*. Do otagování v1.2.2 tedy
`update` ani čerstvá instalace nemají co stáhnout. Merge a tag patří
k sobě.
Ověřeno v debianím kontejneru: čistá instalace, druhé spuštění za sebou,
a vydání bez nových jmen spadne se srozumitelnou hláškou místo toho, aby
sáhlo po starém. Binárka postavená lokálně zakládá databázi v
…/dice-counter/ a starou vedle sebe ignoruje. 118 testů.
Closes#19
Projekt se jmenuje dice-counter, ale skoro všude vystupoval jako kostky.
Tohle je první ze dvou kroků podle #16: nová jména se zavádějí vedle
starých, aby běžící instalace nic nerozbilo.
Nově:
binárka a spec dice-counter.spec, dist/dice-counter
přílohy releasu dice-counter-linux-x86_64 a spol.
služba v LXC dice-counter.service
cesty v LXC /opt/dice-counter, /var/lib/dice-counter
uživatel dice-counter
hostname LXC dice-counter
instalátor deploy/pve-dice-counter.sh
datový adresář ~/.local/share/dice-counter a obdoby
co appka hlásí "dice-counter <verze>" v banneru i v patičce
Stará jména zatím fungují dál:
- Přílohy se na release věší pod oběma jmény.
- Instalátor umí stáhnout i kostky-*, takže starší vydání jdou
nainstalovat pořád.
- deploy/pve-kostky.sh zůstává jako přesměrování — příkaz `update`
v už založených kontejnerech chodí pro instalátor právě tam.
- Kontejnery z dřívějška se při aktualizaci přestěhují samy: služba
se přejmenuje a databáze se přesune do /var/lib/dice-counter, takže
o historii her nikdo nepřijde.
- Binárka sáhne po ~/.local/share/kostky/dice.db, dokud nová databáze
neexistuje.
Při zkoušení přechodu vyplavala chyba, která tu byla už předtím: příkaz
`update` si nový instalátor uloží do $HOME_DIR/install.sh a odtud ho
pustí, takže `install -m 755 "$0" "$HOME_DIR/install.sh"` kopírovalo
soubor sám na sebe. install to odmítne, se `set -e` spadl celý update.
Ošetřeno testem `-ef`.
Ověřeno v debianím kontejneru: přechod ze staré instalace (včetně běhu
instalátoru z adresáře, který se během něj maže), čistá instalace, běh
proti releasu, kde je jen stará příloha, a druhé spuštění za sebou.
Refs #16
Balíček se po publikaci objevil jen pod uživatelem, záložka Packages
u repozitáře zůstala prázdná. Gitea páruje kontejnerový balíček s repozitářem
podle labelu org.opencontainers.image.source a image dosud neměl labely
vůbec žádné.
Kromě source ještě title, description, url a version — ta se plní z build
argumentu, takže sedí s tím, co hlásí --version.
Služba, container_name, svazek a uživatel uvnitř image se jmenovaly kostky.
Teď je nejlevnější chvíle to srovnat: compose se dá použít teprve od tohohle
PR, takže svazek kostky-data zatím nikde neexistuje a není co migrovat. Po
vydání by to už chtělo přesun dat.
Uživateli zůstává uid 1000, takže vlastnictví souborů v /data nezávisí na
jménu a bind mounty se nerozbijí.
LXC strana (kostky.service, /opt/kostky, /var/lib/kostky) zůstává na #16 —
tam přejmenování znamená migraci běžícím instalacím.
Compose soubor měl v sobě build: context: .., takže si image stavěl z
lokálních zdrojáků a bez naklonovaného repozitáře byl k ničemu. Proti LXC
cestě, kde se stahuje hotová binárka, to byla nesrovnalost.
Nové workflow staví image na domácím runneru a při vydání ho pošle do
registru Gitey, pro amd64 i arm64. Compose se tím smrskl na jeden soubor,
který si člověk stáhne a rovnou spustí.
Automatický token Actions na balíčky nestačí — Gitea to zatím neumí a sama
v dokumentaci odkazuje na osobní token. Je v secrets pod PACKAGE_TOKEN;
jméno nesmí začínat na GITEA_, ten prefix si Gitea vyhrazuje.
Nad pull requesty se image staví a zkouší, ale nepublikuje. Dockerfile do
teď v CI žádné pokrytí neměl a rozbil by se až při releasu.
Image se jmenuje podle repozitáře, dice-counter. Zbytek projektu pořád mluví
o kostkách; sjednocení je na samostatné issue, protože se dotkne vydaných
binárek i běžících instalací.
Dvě věci, které se u community-scripts čekají a chyběly.
V kontejneru je nově /usr/bin/update, takže aktualizace je jedno slovo. Sám
si přitom obnoví i instalátor z main, aby nejel napořád na té verzi skriptu,
se kterou se instalovalo. Cesta z uzlu (MODE=update) zůstává.
A konzole: kontejner schválně nemá root heslo, jenže pak se do konzole ve
webu Proxmoxu nedalo dostat — uživatel žádné přihlašovací údaje nezná a ani
nemá odkud. Autologin přes container-getty@1 to řeší přesně tak, jak to
dělají community-scripts. Nová práva to nikomu nedává, kdo má web Proxmoxu,
má root na uzlu tak jako tak. Vypíná se AUTOLOGIN=0.
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í.
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.
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.
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.
gitea-actions
david-spacil