Rewrite SPOC for podman #8

New Issue

2020-05-29T10:49:15+02:00

Disassembler commented

2020-05-29 10:49:15 +02:00

(Migrated from git.spotter.cz)

Podman is finally mature enough and starts to be supported also by Alpine linux maintainers. Podman is a successor to Docker, without all its shortcomings - doesn't need an always-running daemon, supports private registry, is light-ish on disk size. It is also becoming an industry standard and has large user and developer base. There are curerently virtually no points against it and with the current state of SPOC being a conveience wrapper on top of LXC developed by a single person, conversion to Podman is a no-brainer.

Reproducer to get the development environment running on Alpine linux 3.13.5:

Rootful:

# Add edge community repo
echo "http://dl-cdn.alpinelinux.org/alpine/edge/community" >>/etc/apk/repositories

# Install packages and start service
apk add git podman
service podman start

# Test podman
podman pull alpine:3.13
git clone https://github.com/docker-library/postgres.git
cd postgres/13/alpine
podman build --tag postgres:latest .
podman run -d -e POSTGRES_PASSWORD=password --name postgres postgres
podman ps
podman exec -it -u postgres postgres psql

Extra steps for rootless:

# Configure user and start additional services
adduser -D spoc
echo "spoc:100000:65536" >>/etc/subuid
echo "spoc:100000:65536" >>/etc/subgid
sed -i 's/podman_user="root"/podman_user="spoc"/' /etc/init.d/podman
service podman restart
su - spoc -c 'podman system migrate'

(If service is not used, rootless podman requires modprobe fuse, modprobe tun)

Podman is finally mature enough and starts to be supported also by Alpine linux maintainers. Podman is a successor to Docker, without all its shortcomings - doesn't need an always-running daemon, supports private registry, is light-ish on disk size. It is also becoming an industry standard and has large user and developer base. There are curerently virtually no points against it and with the current state of SPOC being a conveience wrapper on top of LXC developed by a single person, conversion to Podman is a no-brainer. Reproducer to get the development environment running on Alpine linux 3.13.5: Rootful: ```bash # Add edge community repo echo "http://dl-cdn.alpinelinux.org/alpine/edge/community" >>/etc/apk/repositories # Install packages and start service apk add git podman service podman start # Test podman podman pull alpine:3.13 git clone https://github.com/docker-library/postgres.git cd postgres/13/alpine podman build --tag postgres:latest . podman run -d -e POSTGRES_PASSWORD=password --name postgres postgres podman ps podman exec -it -u postgres postgres psql ``` Extra steps for rootless: ```bash # Configure user and start additional services adduser -D spoc echo "spoc:100000:65536" >>/etc/subuid echo "spoc:100000:65536" >>/etc/subgid sed -i 's/podman_user="root"/podman_user="spoc"/' /etc/init.d/podman service podman restart su - spoc -c 'podman system migrate' ``` (If service is not used, rootless podman requires `modprobe fuse`, `modprobe tun`)

Disassembler commented

2021-02-08 09:03:36 +01:00

(Migrated from git.spotter.cz)

changed the description

Podhorecky commented

2021-04-13 20:43:24 +02:00

(Migrated from git.spotter.cz)

Podman 3.1.0 released
https://podman.io/releases/2021/04/02/podman-release-v3.1.0.html

Podman 3.1.0 released https://podman.io/releases/2021/04/02/podman-release-v3.1.0.html

Disassembler commented

2021-04-14 18:09:09 +02:00

(Migrated from git.spotter.cz)

mentioned in issue Podhorecky/Spotter-Media#42

Podhorecky commented

2021-04-18 22:46:47 +02:00

(Migrated from git.spotter.cz)

Ok, navážu na diskusi z tohoto vlákna https://git.spotter.cz/Podhorecky/Spotter-Media/-/issues/42#note_4978 a udělám nabídku.

Pokud myslíte že cesta přes Podman + vyšívání featur kolem toho může vyústit do nástroje na deploymenty, tak OK, zkusme se o tom bavit jako o pokračujícím projektu.

K tomu bych měl diskusní příspěvek:

ohledně návrhu features máte k tomu významné slovo, protože já se o tom upřimně vim velmi málo
ohledně financování k tomu máte příležitost navrhnout co si představujete, pokud se vám to chce dělat. Já jen abych věděl kolik mam na to nasbírat prázdných lahví. Nemusí to být přesná částka, může to být i vyjádřeno procenty vašich ideálních představ o částce.
ohledně využití mám představu že to bude stále pod ootevřenou licencí, ale přemýšlím že by to byla spíš licence "custom" která by užití upravovala na užší "klientelu". Představte si to podobně jako licenci CoopCycle, která je k dispozici komunitám ve prospěch komunit. Ne tedy kdejakému podnikateli. V případě zdejšího projektu bych to tedy rád omezil (asi) na cílovku konající veřejný prospěch. Tedy nějak jinak řečeno, že nejsem ochotný vyvíjet produkt někomu, kdo spokojeně funguje v libovolné IT firmě a tento SW by bez mrknutí oka mohl použít pro firemní účely, ať už jsou jakékoliv zvrhlé. Je mi líto, ale na tak šlechetnou frajeřinu vážně nemám dost vlastních životů.
To se týká i Vás, ... tj. pokud vyrobíme něco užitečného, nemám problém když to budou používat jedinci pro své malé projekty. Včetně vás na své pokusy, cojávim. Ale nepřišlo by mi fér, kdybyste to svému zaměstnavateli otáčející mnohamilionové zakázky předvedl jako "free tool na cokoliv" A váš nadřízený by ani nepotřeboval tomu věnovat svých 5 vteřin života. To mě nebaví. Ještě nevim jak to vyjádřit.
ohledně vašich osobních motivací klidně napište jak to vidíte, stojím o to aby tam nějaké byly.
ohledně dosavadních 4 let pokusů s VM - mnohé mne poučilo a i přes opakované výkyvy euforie (když se mi něco jevilo jako možné) a depresí, (kdykoliv jsem se dozvěděl že už to dělat nebudete, nebo že mi někdo řiká "nikoho nezajímáš, debile") to přesto považuji za projekt, kterým jsem se posunul dál, než v mnohých jiných životních etapách. Takže co se týče samotné VM s pár SW, ještě nad tím budu přemýšlet, než řeknu nějaký verdikt. Zatím to bude sloužit jako testovací polygon. Moc mne mrzí, že tuto diskusi otevírám ještě před tím, než vůbec mohl někdo posoudit, o co fakticky jde. Příčinou je víc věcí, bohužel limitem je čas a mindset cizích lidí. Obojí nedokážu ovlivnit ani řečmi, ani penězi.
ohledně mého zacílení projektu který prezentuji na Spotter.ngo se v hrubých rysech nic nemění, ale budu asi muset trochu změnit detaily a komunikační strategii. Ještě nevím jak přesně. Zatím vše to, co jsem kdy napsal o rizicích v budoucnosti, tak neodvolávám. Protože ty rizika se budou stále zvyšovat. A je vesměs jedno, že malé sub-promile lidí to na své práci a životním stylu v ideálním případě nepoznají.
ohledně UFO softwarů - jsem si jist, že se kdykoliv mohu seznámit se SW, který bude ve velmi strašidelném stavu a nebude mít žádný hotový kontejner. Pak tedy bude muset nastoupit kung-fu někoho, kdo se o kontejnerování a tedy zahrnutí do projektu pokusí. Bylo by možná zajímavé, aby to mohl být podle námi poskytnutých notiček kdokoliv bude mít zájem.
ohledně mého hostingu na pokusy - je mi líto, ale nejsem v situaci, kdy bych se mohl rozdovádět a vše řešil na hostingu, který bych platil v pro mne neúnosných částkách. Takže můj hosting zůstane co nejmenší, nemohu ho libovolně rozšiřovat, když jsem nezaměstnaný. A tím tedy budu muset potlačit nějaké své halucinace a fungovat s minimem online SW. Co to znamená pro vývoj, sám nevím :(

Ok, navážu na diskusi z tohoto vlákna https://git.spotter.cz/Podhorecky/Spotter-Media/-/issues/42#note_4978 a udělám nabídku. Pokud myslíte že cesta přes Podman + vyšívání featur kolem toho může vyústit do nástroje na deploymenty, tak OK, zkusme se o tom bavit jako o pokračujícím projektu. K tomu bych měl diskusní příspěvek: - **ohledně návrhu features** máte k tomu významné slovo, protože já se o tom upřimně vim velmi málo - **ohledně financování** k tomu máte příležitost navrhnout co si představujete, pokud se vám to chce dělat. Já jen abych věděl kolik mam na to nasbírat prázdných lahví. Nemusí to být přesná částka, může to být i vyjádřeno procenty vašich ideálních představ o částce. - **ohledně využití** mám představu že to bude stále pod ootevřenou licencí, ale přemýšlím že by to byla spíš licence "custom" která by užití upravovala na užší "klientelu". Představte si to podobně jako licenci CoopCycle, která je k dispozici komunitám ve prospěch komunit. Ne tedy kdejakému podnikateli. V případě zdejšího projektu bych to tedy rád omezil (asi) na cílovku konající veřejný prospěch. Tedy nějak jinak řečeno, že nejsem ochotný vyvíjet produkt někomu, kdo spokojeně funguje v libovolné IT firmě a tento SW by bez mrknutí oka mohl použít pro firemní účely, ať už jsou jakékoliv zvrhlé. Je mi líto, ale na tak šlechetnou frajeřinu vážně nemám dost vlastních životů. To se týká i Vás, ... tj. pokud vyrobíme něco užitečného, nemám problém když to budou používat jedinci pro své malé projekty. Včetně vás na své pokusy, cojávim. Ale nepřišlo by mi fér, kdybyste to svému zaměstnavateli otáčející mnohamilionové zakázky předvedl jako "free tool na cokoliv" A váš nadřízený by ani nepotřeboval tomu věnovat svých 5 vteřin života. To mě nebaví. Ještě nevim jak to vyjádřit. - **ohledně vašich osobních motivací** klidně napište jak to vidíte, stojím o to aby tam nějaké byly. - **ohledně dosavadních 4 let pokusů s VM** - mnohé mne poučilo a i přes opakované výkyvy euforie (když se mi něco jevilo jako možné) a depresí, (kdykoliv jsem se dozvěděl že už to dělat nebudete, nebo že mi někdo řiká "nikoho nezajímáš, debile") to přesto považuji za projekt, kterým jsem se posunul dál, než v mnohých jiných životních etapách. Takže co se týče samotné VM s pár SW, **ještě nad tím budu přemýšlet, než řeknu nějaký verdikt.** Zatím to bude sloužit jako testovací polygon. Moc mne mrzí, že tuto diskusi otevírám ještě před tím, než vůbec mohl někdo posoudit, o co fakticky jde. Příčinou je víc věcí, bohužel limitem je čas a mindset cizích lidí. Obojí nedokážu ovlivnit ani řečmi, ani penězi. - **ohledně mého zacílení projektu** který prezentuji na Spotter.ngo se v hrubých rysech nic nemění, ale budu asi muset trochu změnit detaily a komunikační strategii. Ještě nevím jak přesně. Zatím vše to, co jsem kdy napsal o rizicích v budoucnosti, tak neodvolávám. Protože ty [rizika se budou stále zvyšovat](https://www.dni.gov/index.php/global-trends-home). A je vesměs jedno, že malé sub-promile lidí to na své práci a životním stylu v ideálním případě nepoznají. - **ohledně UFO softwarů** - jsem si jist, že se kdykoliv mohu seznámit se SW, který bude ve velmi strašidelném stavu a nebude mít žádný hotový kontejner. Pak tedy bude muset nastoupit kung-fu někoho, kdo se o kontejnerování a tedy zahrnutí do projektu pokusí. Bylo by možná zajímavé, aby to mohl být podle námi poskytnutých notiček kdokoliv bude mít zájem. - **ohledně mého hostingu na pokusy** - je mi líto, ale nejsem v situaci, kdy bych se mohl rozdovádět a vše řešil na hostingu, který bych platil v pro mne neúnosných částkách. Takže můj hosting zůstane co nejmenší, nemohu ho libovolně rozšiřovat, když jsem nezaměstnaný. A tím tedy budu muset potlačit nějaké své halucinace a fungovat s minimem online SW. Co to znamená pro vývoj, sám nevím :(

Disassembler commented

2021-04-19 11:04:16 +02:00

(Migrated from git.spotter.cz)

changed the description

Disassembler commented

2021-04-19 19:06:33 +02:00

(Migrated from git.spotter.cz)

Ha. Koukám, že jsme se skoro trefili do toho správného okamžiku. Nedávno byla mergnutá vlastnost, která umožňuje nastavovat vazby mezi jednotlivými kontejnery v podu a očekávám, že bude k dispozici v příštím release, nejpozději za měsíc.

ohledně návrhu features

To je na tomhle řešení právě to krásné. Drtivá většina features, které pro stavbu a běh kontejnerů potřebujeme, už tu byly navrženy. Teoreticky by nám to mělo nahradit minimálně 90 % SPOC a celé LXC runtime. Budeme muset řešit akorát balení do blbuvzdorných balíčků, tj. instalační skripty a nějaký frontend k tomu, u kterého zůstane většina funkcí zachována a kde se budeme motat kolem potřeb popsaných ve Spotter-Cluster/vmmgr#4 a které teoreticky můžeme vyřešit za cenu toho, že budeme okázale ignorovat některá dosavadní specifika frontendu, jako třeba že Sahana má velký čudlík o dvojité velkosti na prvním místě.

A ani to balení nemusíme řešit úplně bezpodmínečně, protože to už je právě ta Vaše přidaná hodnota. V základu budeme mít pouze kontejnery a instrukce jak z nich sestavit funkční prostředí. Teprve VM a VMMgr přidají tu úroveň pohodlnosti, kdy uživatel ty instrukce nebude nucen vykopírovávat a spouštět sám, ale provedou se na uživatelův povel automaticky, za cenu toho, že se mu "samo" neudělá úplně všechno, ale jen ty nejnutnější kroky k tomu, aby dosáhl běžícího prostředí pro otestování, na základě kterého se mohl rozhodnout, zda chce investovat prostředky (ať už časové nebo finanční) do dalších úprav či ostrého nasazení mimo VM.

ohledně financování

Opět nedokážu úplně odhadnout kolik klacků se mi pod nohama objeví, ale takhle střízlivě od pasu bych to viděl tak na 7 MD práce než z toho začne lézt nějaký prototyp, 20 než to bude prezentovatelné i Vám a 40 než do toho překlopíme všechno, co momentálně máme a budeme moci začít používat tak, jak teď používáme SPOC + VMMgr. Čas sice udávám v člověkodnech, ale reálně tomu více než 4 hodiny denně obětovat nemůžu, a to ještě ne každý den.

ohledně využití

Připomínám, že my tu toho moc nevymýšlíme. My jen regurgitujeme již vymyšlené a dáváme tomu nějakou fazónu stravitelnou pro klikače. Pořád jsme vázáni licencemi produktů, které pro tyto účely používáme. Rozdělení a free a non-free obsahu bude probíhat pořád stejným způsobem, t.j. bude existovat veřejný a neveřejný repozitář. Přístup do obou z nich bude pod Vaší kontrolou, přičemž ten neveřejný bude chráněn jmény a hesly rozdávanými oproti NDA a dalším zviřátkům dle vašeho uvážení.

ohledně vašich osobních motivací

Mno, mám-li to říct úplně na férovku, tak má osobní motivace je zejména tak, že když Vám s tím fláknu a odjedu pěstovat ovce na Fiji, tak má náhrada nebude muset studovat nějakou lehce obskurní technologii, která, byť staví na ověřených postupech a používá nástroje používané i jinde, není mainstreamová. Podman je nástupcem Dockeru (Docker kontejnery v Podmanu fungují) a Docker je prakticky synonymum pro kontejnery, což je ostatně vidět i na tom, jakými způsoby se všechny ty aplikace distribuují. Docker image má minimálně třetina z nich. Image pro LXC jich má přesně nula, a to počítám i těch 100 aplikací, které jste si vysnil a na které jsem se ještě ani nedíval. Ten můj SPOC sice dělá všechno proto, aby přepis Docker kontejneru pro LXC usnadnil, ale pořád je k tomu potřeba více zkušeností a dovedností než k napsání tří příkazů, které kontejner vyčarují přímo ze zdrojáku na GitHubu. Pokud aplikace recept na sestavení kontejneru nemá, musí se vyrobit a nakontejnerovat úplně stejným způsobem jako to děláme teď, jen pro jiný podvozek.

Současně s tím je má motivace taková, že až konečně získáte ty miliony z grantů a budete chtít ty aplikace reálně nasazovat, na Fiji neodjedu a budu Vám místo toho schopen poskytnou součinnost při jejich nasazování s vědomím toho, že jsem udělal maximum pro to, aby ta aplikace jela fakt prakticky kdekoliv. A pokud ji admin nějaké té neziskovky nebude schopen zprovoznit, že problém není na straně vybraných technologií a jejich obskurnosti, ale prostě v tom, že je to matlák, kterého budeme jej moci odkázat na statisíce manuálů, článků a průvodců o naprosto přesně totožné technologii, kterou mimo nás pro taková nasazení používají miliony dalších lidí.

ohledně dosavadních 4 let pokusů s VM

Váš bod je sice o něčem jiném, nicméně ty 4 rohy vývoje nevyletí komínem. Měníme pouze motor hvězdoletu a místo zážehového ze sekačky na trávu instalujeme vznětový z tanku. Podvozek, převodovka, volant, kastle a hlavně celý jeho náklad s drobnými úpravami zůstávají.

ohledně mého zacílení projektu

Jop, záměrem se nic nemění ani na straně technologií. Jenom se už nesnažíme stůj co stůj ušetřit každý bajt. To nám už celkem úspěšně sabotují ty samotné aplikace. Takže výměnou technologie svolíme k tomu, že budeme schopni rychleji vytvářet hodnoty, za cenu toho, že instalace serveru přes CDMA modem na Chromebook nebude nadále možná (resp. praktická)

ohledně UFO softwarů

Spousta těch softwarů právě ten kontejner má. Rozhodně ne všechny, ale i kdyby jej měl jeden z deseti, pořád je to o 10 procentních bodů víc než teď, takže nějaký rapid deployment můžeme udělat.

ohledně mého hostingu na pokusy

Chápu. Ono se to vyplácané místo dá redukovat i s tím Dockerem a Podmanem, ale opět to vyžaduje přepsat si skoro celý recept pro sestavení kontejneru od začátku. Uvidíme jak moc zlé to bude s tím, co tam máte teď. Zatím je na nějaké odhady brzo. Tady není na vině ani tak ten systém pro sestavení a běh kontejnerů jako spíš ty samotné aplikace, které staví na té samé premise - doručit funkce v prvé řadě rychle, v druhé řadě funkčně a teprve až v následujících řadách efektivně a úsporně. Že v mnoha případech nedojde ani na tu druhou řadu už víte sám.

Ha. Koukám, že jsme se skoro trefili do toho správného okamžiku. Nedávno byla [mergnutá vlastnost](https://github.com/containers/podman/pull/9754), která umožňuje nastavovat vazby mezi jednotlivými kontejnery v podu a očekávám, že bude k dispozici v příštím release, nejpozději za měsíc. > ohledně návrhu features To je na tomhle řešení právě to krásné. Drtivá většina features, které pro stavbu a běh kontejnerů potřebujeme, už tu byly navrženy. Teoreticky by nám to mělo nahradit minimálně 90 % SPOC a celé LXC runtime. Budeme muset řešit akorát balení do blbuvzdorných balíčků, tj. instalační skripty a nějaký frontend k tomu, u kterého zůstane většina funkcí zachována a kde se budeme motat kolem potřeb popsaných ve Spotter-Cluster/vmmgr#4 a které teoreticky můžeme vyřešit za cenu toho, že budeme okázale ignorovat některá dosavadní specifika frontendu, jako třeba že Sahana má velký čudlík o dvojité velkosti na prvním místě. A ani to balení nemusíme řešit úplně bezpodmínečně, protože to už je právě ta Vaše přidaná hodnota. V základu budeme mít pouze kontejnery a instrukce jak z nich sestavit funkční prostředí. Teprve VM a VMMgr přidají tu úroveň pohodlnosti, kdy uživatel ty instrukce nebude nucen vykopírovávat a spouštět sám, ale provedou se na uživatelův povel automaticky, za cenu toho, že se mu "samo" neudělá úplně všechno, ale jen ty nejnutnější kroky k tomu, aby dosáhl běžícího prostředí pro otestování, na základě kterého se mohl rozhodnout, zda chce investovat prostředky (ať už časové nebo finanční) do dalších úprav či ostrého nasazení mimo VM. > ohledně financování Opět nedokážu úplně odhadnout kolik klacků se mi pod nohama objeví, ale takhle střízlivě od pasu bych to viděl tak na 7 MD práce než z toho začne lézt nějaký prototyp, 20 než to bude prezentovatelné i Vám a 40 než do toho překlopíme všechno, co momentálně máme a budeme moci začít používat tak, jak teď používáme SPOC + VMMgr. Čas sice udávám v člověkodnech, ale reálně tomu více než 4 hodiny denně obětovat nemůžu, a to ještě ne každý den. > ohledně využití Připomínám, že my tu toho moc nevymýšlíme. My jen regurgitujeme již vymyšlené a dáváme tomu nějakou fazónu stravitelnou pro klikače. Pořád jsme vázáni licencemi produktů, které pro tyto účely používáme. Rozdělení a free a non-free obsahu bude probíhat pořád stejným způsobem, t.j. bude existovat veřejný a neveřejný repozitář. Přístup do obou z nich bude pod Vaší kontrolou, přičemž ten neveřejný bude chráněn jmény a hesly rozdávanými oproti NDA a dalším zviřátkům dle vašeho uvážení. > ohledně vašich osobních motivací Mno, mám-li to říct úplně na férovku, tak má osobní motivace je zejména tak, že když Vám s tím fláknu a odjedu pěstovat ovce na Fiji, tak má náhrada nebude muset studovat nějakou lehce obskurní technologii, která, byť staví na ověřených postupech a používá nástroje používané i jinde, není mainstreamová. Podman je nástupcem Dockeru (Docker kontejnery v Podmanu fungují) a Docker je prakticky synonymum pro kontejnery, což je ostatně vidět i na tom, jakými způsoby se všechny ty aplikace distribuují. Docker image má minimálně třetina z nich. Image pro LXC jich má přesně nula, a to počítám i těch 100 aplikací, které jste si vysnil a na které jsem se ještě ani nedíval. Ten můj SPOC sice dělá všechno proto, aby přepis Docker kontejneru pro LXC usnadnil, ale pořád je k tomu potřeba více zkušeností a dovedností než k napsání tří příkazů, které kontejner vyčarují přímo ze zdrojáku na GitHubu. Pokud aplikace recept na sestavení kontejneru nemá, musí se vyrobit a nakontejnerovat úplně stejným způsobem jako to děláme teď, jen pro jiný podvozek. Současně s tím je má motivace taková, že až konečně získáte ty miliony z grantů a budete chtít ty aplikace reálně nasazovat, na Fiji neodjedu a budu Vám místo toho schopen poskytnou součinnost při jejich nasazování s vědomím toho, že jsem udělal maximum pro to, aby ta aplikace jela fakt prakticky kdekoliv. A pokud ji admin nějaké té neziskovky nebude schopen zprovoznit, že problém není na straně vybraných technologií a jejich obskurnosti, ale prostě v tom, že je to matlák, kterého budeme jej moci odkázat na statisíce manuálů, článků a průvodců o naprosto přesně totožné technologii, kterou mimo nás pro taková nasazení používají miliony dalších lidí. > ohledně dosavadních 4 let pokusů s VM Váš bod je sice o něčem jiném, nicméně ty 4 rohy vývoje nevyletí komínem. Měníme pouze motor hvězdoletu a místo zážehového ze sekačky na trávu instalujeme vznětový z tanku. Podvozek, převodovka, volant, kastle a hlavně celý jeho náklad s drobnými úpravami zůstávají. > ohledně mého zacílení projektu Jop, záměrem se nic nemění ani na straně technologií. Jenom se už nesnažíme stůj co stůj ušetřit každý bajt. To nám už celkem úspěšně sabotují ty samotné aplikace. Takže výměnou technologie svolíme k tomu, že budeme schopni rychleji vytvářet hodnoty, za cenu toho, že instalace serveru přes CDMA modem na Chromebook nebude nadále možná (resp. praktická) > ohledně UFO softwarů Spousta těch softwarů právě ten kontejner má. Rozhodně ne všechny, ale i kdyby jej měl jeden z deseti, pořád je to o 10 procentních bodů víc než teď, takže nějaký rapid deployment můžeme udělat. > ohledně mého hostingu na pokusy Chápu. Ono se to vyplácané místo dá redukovat i s tím Dockerem a Podmanem, ale opět to vyžaduje přepsat si skoro celý recept pro sestavení kontejneru od začátku. Uvidíme jak moc zlé to bude s tím, co tam máte teď. Zatím je na nějaké odhady brzo. Tady není na vině ani tak ten systém pro sestavení a běh kontejnerů jako spíš ty samotné aplikace, které staví na té samé premise - doručit funkce v prvé řadě rychle, v druhé řadě funkčně a teprve až v následujících řadách efektivně a úsporně. Že v mnoha případech nedojde ani na tu druhou řadu už víte sám.

Podhorecky commented

2021-04-19 20:31:02 +02:00

(Migrated from git.spotter.cz)

Ok, zatim se to dá celé taknějak akceptovat. S penězi snad asi taky, už plánuji chodit na modlení a čekám na zázrak. To s těmi pokusy o granty to ode mne není žertem, já jen tuším, že to nejdřív nebude snadný. Na druhou stranu zase věřím, že po nalezení jednoho kvalitního followera to může být snažší. Jen nevím jak ho najít.

Teď tedy termíny na tohle nehrotim, ani nemam další doplňující návrhy.
Vnímám to tak, že se nejdřív v tom zorientujeme a po měsíci se uvidí.

Moje nedodělávky snad později dopadnou.

Ok, zatim se to dá celé taknějak akceptovat. S penězi snad asi taky, už plánuji chodit na modlení a čekám na zázrak. To s těmi pokusy o granty to ode mne není žertem, já jen tuším, že to nejdřív nebude snadný. Na druhou stranu zase věřím, že po nalezení jednoho kvalitního followera to může být snažší. Jen nevím jak ho najít. Teď tedy termíny na tohle nehrotim, ani nemam další doplňující návrhy. Vnímám to tak, že se nejdřív v tom zorientujeme a po měsíci se uvidí. Moje nedodělávky snad později dopadnou.

Disassembler commented

2021-04-26 16:02:46 +02:00

(Migrated from git.spotter.cz)

mentioned in issue #9

Disassembler commented

2021-05-08 20:54:36 +02:00

(Migrated from git.spotter.cz)

Chvilku se mi udělalo volno, tak jsem kouknul na to, jakým způsobem se dá spravovat distribuce těch imagů. Trocha dovysvětlení k tomu OCI (#9) - OCI je specifikace, která sjednocuje náležitosti kolem kontejnerů a nařizuje jaké náležitosti musejí jednotlivé aplikace sestavující image nebo provozující kontejnery splňovat, a jaké náležitosti musí poskytovat metadata těch imagů a kontejnerů, aby si to spolu všechno rozumělo.

Můžete si to představit jako datový formát. Třeba takový MP4 je na tom principiálně dost podobně (koneckonců je to multimedia container). MP4 neříká, co má být obsahem souboru a dokonce ani nařizuje jaký kodek musí být použit, ale nařizuje jak má být soubor s videem strukturován a jaká metadata musí poskytovat. Jakákoliv aplikace, která MP4 rozumí jej pak může přečíst, přehrát, případně i vytvořit. Na jedné straně potravního řetězce v Premiéře někdo zpracuje zdroje k videu, vyprodukuje MP4 a nahraje třeba někam do Pandory. Ta tomu MP4 formátu rozumí a umožní uživateli zjistit informace o videu ještě předtím, než jej vůbec stáhne nebo spustí. Uživatel si soubor stáhne, jebne ho třeba do VLC playeru, který tomu formátu taky rozumí, otevře si brambůrky a oddává se konzumu. S OCI je to úplně stejné. Na jedné straně někdo nějak vytvoří image splňující ty OCI náležitosti, a je úplně jedno jakými nástroji nebo způsoby, dokud výstup odpovídá specifikaci. Zbuilděný image, resp. jeho jednotlivé vrstvy a metadata nahraje do tzv. "registru", což je nějaká serverová aplikace, která mimo samotných dat skrze API poskytuje informace o imagích, které z nich vyčte opět jen díky tomu, že všechny komponenty mluví stejnou řečí. Na druhé straně se uživatel libovolným OCI-kompatibilním nástrojem do toho registru připojí, obraz si i s metadaty stáhne a vytvoří si z něj instanci kontejneru.

Vypisuji se s tím proto, aby bylo jasné, že nic jako "Docker image" nebo "podman kontejner" vlastně neexistuje, protože na tom, jakým nástrojem byla ta data vytvořena, zprostředkována nebo používána vůbec nezáleží. Všechno je to OCI. Rozdíly jsou až ve vlastnostech, které nesouvisejí s OCI. Třeba ve způsobu jakým zprostředkovávají přístup k systémovým prostředkům (např. síťovým adaptérům) nebo že Docker běží trvale jako daemon proces, na rozdíl od podmanu, který pouze nastavuje prostředí ve kterém pak přímo kontejner spustí. LXC s OCI umí také pracovat, ale kontejnery, které v současnosti používáme OCI nejsou. Naproti tomu všelijaké Kubernetesy, OpenShifty, AWS a Azure cloudy nepoužívají ani Docker ani podman, ale protože rozumí OCI, i tak umožňují použití OCI imagů a kontejnerů. V tom je ten úplně nejhlavnější benefit toho použití podmanu, resp. OCI - Umožníme tím instalaci a běh Vašich aplikací na hromadě existujících komerčních i nekomerčních platforem a SpotterVM bude tou platformou jen v případech, kdy nebude uživateli k dispozici žádná jiná.

No, takže zpět k tématu - Podman se dá použít k výstavbě i konzumaci OCI, takže mi zbývalo vyřešit jak ty OCI image distribuovat. Nejlepší volbou se v současnosti jeví použití Docker registru (+konfigurace). Koukal jsem, že OCI registr umí dělat i GitLab (ve Vaši instanci je vypnutý), ale ten ve skutečnosti používá ten Dockeří registr a poněkud komplikovaně se nastavuje, takže si s ním moc nepomůžeme. Mimo to existují i další nástroje, jako třeba Quay, který integruje i hezké featury pro vyhledávání zranitelností a všelijaké jiné opičárny, ale jeho použití je ještě komplikovanější. Komerční variantu Quay.io pro distribuci a management OCI imagů používáme i v Red Hatu. Spousta providerů poskytuje hosting OCI registru jako službu, ale to pro Vás začne být zajímavé, až budete mít ty miliony z grantů.

Ten dockeří registr běží jako služba navíc, kterou pak budeme muset nainstalovat na server. Služba samotná je relativně malá (nějakých 30 MB), nicméně OCI specifikace říká, že vrstvy mohou být komprimovány pouze pomocí gzipu. Ten je oproti současně používanému xz sice podstatně rychlejší, ale má horší kompresní poměr, takže nacpat všechno na stávající server u Hetznerů bude nejspíš docela výzva. Tohle je bohužel trend posledních 20 let, kterému se nevyhneme. Chceme-li používat široce rozšířené technologie, projeví se to na využitém diskovém prostoru, protože diskový prostor je prý levný. Mno... jak pro koho.

Současně s tím jsem vykoumal, jakým způsobem se tam dá vyrobit to omezení přístupu k aplikacím, které mají být dostupné pouze vybraným uživatelům (na základě NDA a vašeho rozhodnutí). Ten dockeří registr sice nic takového přímo nepodporuje, ale protože to API je docela dobře vymyšlené, dá se to řešit na úrovni HTTP požadavků. Podařilo se mi to nastavit tak, že mám tři úrovně oprávnění - neautentizovaný přístup pro stažení volných kontejnerů, autentizovaný pro stažení omezených a autentizovaný + příslušnost k administrátorské skupině pro nahrávání a úpravu obrazů v registru. Jedinou nevýhodou je, že i neautentizovaný uživatel bude schopen vidět, že ty omezené obrazy existují, ale nebude schopen se k nim dostat nebo z nich vyčíst žádná metadata. Bude tedy například vědět jen že v našem registru existuje repozitář "sahana", ale už nebude schopen zjistit, co v něm je. Pokud by to byl problém, museli bychom pro správu registru použít jinou aplikaci, která ty přístupy umí řešit přímo v sobě.

Kdyby se náhodou přihodilo, že bych tu instalaci a nastavení registru neřešil já, tak si sem odkládám poznámky, na které je možno navázat

# Install registry without TLS (TLS offloaded on proxy)
mkdir /var/lib/registry

podman run -d \
    --privileged  \
    -p 5000:5000 \
    -v /var/lib/registry:/var/lib/registry \
    -e REGISTRY_STORAGE_DELETE_ENABLED=true \
    --name registry \
    docker.io/library/registry:2


# Install Apache proxy
apk add apache2 apache2-brotli apache2-http2 apache2-proxy apache2-ssl
# optionally apk add apache2-ctl apache2-utils

# Append to /etc/apache2/httpd.conf
<VirtualHost *:443>
  ServerName podman.dasm.cz
  Protocols h2 http/1.1

  SSLEngine on
  SSLCertificateFile /etc/acme-sh/podman.dasm.cz/fullchain.cer
  SSLCertificateKeyFile /etc/acme-sh/podman.dasm.cz/podman.dasm.cz.key

  Header always set "Docker-Distribution-Api-Version" "registry/2.0"
  Header onsuccess set "Docker-Distribution-Api-Version" "registry/2.0"
  RequestHeader set X-Forwarded-Proto "https"

  ProxyRequests off
  ProxyPreserveHost on

  ProxyPass /error/ !
  ProxyPass /v2 http://127.0.0.1:5000/v2
  ProxyPassReverse /v2 http://127.0.0.1:5000/v2

  <Location /v2>
    AuthName "Registry Authentication"
    AuthType basic
    AuthUserFile "/etc/apache2/registry/.htpasswd"
    AuthGroupFile "/etc/apache2/registry/.htgroups"

    <Limit GET HEAD>
      Require valid-user
    </Limit>

    <Limit POST PUT DELETE PATCH>
      Require group admin
    </Limit>
  </Location>

  <LocationMatch "^/v2(/(_catalog|(redis|postgres)/.*)?)?$">
    Require all granted
    <Limit POST PUT DELETE PATCH>
      AuthName "Registry Authentication"
      AuthType basic
      AuthUserFile "/etc/apache2/registry/.htpasswd"
      AuthGroupFile "/etc/apache2/registry/.htgroups"
      Require group admin
    </Limit>
  </LocationMatch>
</VirtualHost>

# Create password and group files
mkdir /etc/apache2/registry
htpasswd -c /etc/apache2/registry/.htpasswd admin
htpasswd /etc/apache2/registry/.htpasswd user
echo "admin: admin" >/etc/apache2/registry/.htgroups

# Restart Apache
service apache2 restart

Následujícím krokem je vymyslet jakým způsobem komponovat jednotlivá aplikační prostředí. docker-compose (který používá například karrot) a podman-compose zatím nejsou dostatečně vzájemně kompatibilní (třeba zrovna to nastavení sítě, které Docker dělá jinak, tam trochu hapruje), ale v následujícím měsíci jsou plánovány nějaké změny pro podman 3.2, které by tu kompatibilitu měly zlepšit.

Chvilku se mi udělalo volno, tak jsem kouknul na to, jakým způsobem se dá spravovat distribuce těch imagů. Trocha dovysvětlení k tomu OCI (#9) - OCI je specifikace, která sjednocuje náležitosti kolem kontejnerů a nařizuje jaké náležitosti musejí jednotlivé aplikace sestavující image nebo provozující kontejnery splňovat, a jaké náležitosti musí poskytovat metadata těch imagů a kontejnerů, aby si to spolu všechno rozumělo. Můžete si to představit jako datový formát. Třeba takový MP4 je na tom principiálně dost podobně (koneckonců je to _multimedia container_). MP4 neříká, co má být obsahem souboru a dokonce ani nařizuje jaký kodek musí být použit, ale nařizuje jak má být soubor s videem strukturován a jaká metadata musí poskytovat. Jakákoliv aplikace, která MP4 rozumí jej pak může přečíst, přehrát, případně i vytvořit. Na jedné straně potravního řetězce v Premiéře někdo zpracuje zdroje k videu, vyprodukuje MP4 a nahraje třeba někam do Pandory. Ta tomu MP4 formátu rozumí a umožní uživateli zjistit informace o videu ještě předtím, než jej vůbec stáhne nebo spustí. Uživatel si soubor stáhne, jebne ho třeba do VLC playeru, který tomu formátu taky rozumí, otevře si brambůrky a oddává se konzumu. S OCI je to úplně stejné. Na jedné straně někdo nějak vytvoří image splňující ty OCI náležitosti, a je úplně jedno jakými nástroji nebo způsoby, dokud výstup odpovídá specifikaci. Zbuilděný image, resp. jeho jednotlivé vrstvy a metadata nahraje do tzv. "registru", což je nějaká serverová aplikace, která mimo samotných dat skrze [API](https://docs.docker.com/registry/spec/api/#detail) poskytuje informace o imagích, které z nich vyčte opět jen díky tomu, že všechny komponenty mluví stejnou řečí. Na druhé straně se uživatel libovolným OCI-kompatibilním nástrojem do toho registru připojí, obraz si i s metadaty stáhne a vytvoří si z něj instanci kontejneru. Vypisuji se s tím proto, aby bylo jasné, že nic jako "Docker image" nebo "podman kontejner" vlastně neexistuje, protože na tom, jakým nástrojem byla ta data vytvořena, zprostředkována nebo používána vůbec nezáleží. Všechno je to OCI. Rozdíly jsou až ve vlastnostech, které nesouvisejí s OCI. Třeba ve způsobu jakým zprostředkovávají přístup k systémovým prostředkům (např. síťovým adaptérům) nebo že Docker běží trvale jako daemon proces, na rozdíl od podmanu, který pouze nastavuje prostředí ve kterém pak přímo kontejner spustí. LXC s OCI umí také pracovat, ale kontejnery, které v současnosti používáme OCI nejsou. Naproti tomu všelijaké Kubernetesy, OpenShifty, AWS a Azure cloudy nepoužívají ani Docker ani podman, ale protože rozumí OCI, i tak umožňují použití OCI imagů a kontejnerů. V tom je ten úplně nejhlavnější benefit toho použití podmanu, resp. OCI - Umožníme tím instalaci a běh Vašich aplikací na hromadě existujících komerčních i nekomerčních platforem a SpotterVM bude tou platformou jen v případech, kdy nebude uživateli k dispozici žádná jiná. No, takže zpět k tématu - Podman se dá použít k výstavbě i konzumaci OCI, takže mi zbývalo vyřešit jak ty OCI image distribuovat. Nejlepší volbou se v současnosti jeví použití [Docker registru](https://github.com/distribution/distribution) (+[konfigurace](https://docs.docker.com/registry/configuration/)). Koukal jsem, že OCI registr umí dělat i GitLab (ve Vaši instanci je vypnutý), ale ten ve skutečnosti používá ten Dockeří registr a poněkud komplikovaně se nastavuje, takže si s ním moc nepomůžeme. Mimo to existují i další nástroje, jako třeba [Quay](https://github.com/quay/quay), který integruje i hezké featury pro vyhledávání zranitelností a všelijaké jiné opičárny, ale jeho použití je ještě komplikovanější. Komerční variantu Quay.io pro distribuci a management OCI imagů používáme i v Red Hatu. Spousta providerů poskytuje hosting OCI registru jako službu, ale to pro Vás začne být zajímavé, až budete mít ty miliony z grantů. Ten dockeří registr běží jako služba navíc, kterou pak budeme muset nainstalovat na server. Služba samotná je relativně malá (nějakých 30 MB), nicméně OCI specifikace říká, že vrstvy mohou být komprimovány pouze pomocí gzipu. Ten je oproti současně používanému xz sice podstatně rychlejší, ale má horší kompresní poměr, takže nacpat všechno na stávající server u Hetznerů bude nejspíš docela _výzva_. Tohle je bohužel trend posledních 20 let, kterému se nevyhneme. Chceme-li používat široce rozšířené technologie, projeví se to na využitém diskovém prostoru, protože diskový prostor je prý levný. Mno... jak pro koho. Současně s tím jsem vykoumal, jakým způsobem se tam dá vyrobit to omezení přístupu k aplikacím, které mají být dostupné pouze vybraným uživatelům (na základě NDA a vašeho rozhodnutí). Ten dockeří registr sice nic takového přímo nepodporuje, ale protože to API je docela dobře vymyšlené, dá se to řešit na úrovni HTTP požadavků. Podařilo se mi to nastavit tak, že mám tři úrovně oprávnění - neautentizovaný přístup pro stažení volných kontejnerů, autentizovaný pro stažení omezených a autentizovaný + příslušnost k administrátorské skupině pro nahrávání a úpravu obrazů v registru. Jedinou nevýhodou je, že i **neautentizovaný uživatel bude schopen vidět, že ty omezené obrazy existují**, ale nebude schopen se k nim dostat nebo z nich vyčíst žádná metadata. Bude tedy například vědět jen že v našem registru existuje repozitář "sahana", ale už nebude schopen zjistit, co v něm je. Pokud by to byl problém, museli bychom pro správu registru použít jinou aplikaci, která ty přístupy umí řešit přímo v sobě. Kdyby se náhodou přihodilo, že bych tu instalaci a nastavení registru neřešil já, tak si sem odkládám poznámky, na které je možno navázat ``` # Install registry without TLS (TLS offloaded on proxy) mkdir /var/lib/registry podman run -d \ --privileged \ -p 5000:5000 \ -v /var/lib/registry:/var/lib/registry \ -e REGISTRY_STORAGE_DELETE_ENABLED=true \ --name registry \ docker.io/library/registry:2 # Install Apache proxy apk add apache2 apache2-brotli apache2-http2 apache2-proxy apache2-ssl # optionally apk add apache2-ctl apache2-utils # Append to /etc/apache2/httpd.conf <VirtualHost *:443> ServerName podman.dasm.cz Protocols h2 http/1.1 SSLEngine on SSLCertificateFile /etc/acme-sh/podman.dasm.cz/fullchain.cer SSLCertificateKeyFile /etc/acme-sh/podman.dasm.cz/podman.dasm.cz.key Header always set "Docker-Distribution-Api-Version" "registry/2.0" Header onsuccess set "Docker-Distribution-Api-Version" "registry/2.0" RequestHeader set X-Forwarded-Proto "https" ProxyRequests off ProxyPreserveHost on ProxyPass /error/ ! ProxyPass /v2 http://127.0.0.1:5000/v2 ProxyPassReverse /v2 http://127.0.0.1:5000/v2 <Location /v2> AuthName "Registry Authentication" AuthType basic AuthUserFile "/etc/apache2/registry/.htpasswd" AuthGroupFile "/etc/apache2/registry/.htgroups" <Limit GET HEAD> Require valid-user </Limit> <Limit POST PUT DELETE PATCH> Require group admin </Limit> </Location> <LocationMatch "^/v2(/(_catalog|(redis|postgres)/.*)?)?$"> Require all granted <Limit POST PUT DELETE PATCH> AuthName "Registry Authentication" AuthType basic AuthUserFile "/etc/apache2/registry/.htpasswd" AuthGroupFile "/etc/apache2/registry/.htgroups" Require group admin </Limit> </LocationMatch> </VirtualHost> # Create password and group files mkdir /etc/apache2/registry htpasswd -c /etc/apache2/registry/.htpasswd admin htpasswd /etc/apache2/registry/.htpasswd user echo "admin: admin" >/etc/apache2/registry/.htgroups # Restart Apache service apache2 restart ``` Následujícím krokem je vymyslet jakým způsobem komponovat jednotlivá aplikační prostředí. `docker-compose` (který používá například karrot) a `podman-compose` zatím nejsou dostatečně vzájemně kompatibilní (třeba zrovna to nastavení sítě, které Docker dělá jinak, tam trochu hapruje), ale v následujícím měsíci jsou plánovány nějaké změny pro podman 3.2, které by tu kompatibilitu měly zlepšit.

Podhorecky commented

2021-05-08 22:25:21 +02:00

(Migrated from git.spotter.cz)

ok, díky za detailní vysvětlení, s tím příkladem MP4 snadno pochopitelné. Také díky za nějaký průzkum a návrh jak řešit ty distribuce. Jako plán to vypadá vychytrale. Okolnosti zatím beru jak píšete, myslím že hlavní výzva je dát to nahrubo dokupy a teprv pak řešit ty detaily.
Za mne teď k tomu nemám žádné nové nápady ani časy, takže akorát se těším na novinky z githubu a překládám si něco do zásoby.

ok, díky za detailní vysvětlení, s tím příkladem MP4 snadno pochopitelné. Také díky za nějaký průzkum a návrh jak řešit ty distribuce. Jako plán to vypadá vychytrale. Okolnosti zatím beru jak píšete, myslím že hlavní výzva je dát to nahrubo dokupy a teprv pak řešit ty detaily. Za mne teď k tomu nemám žádné nové nápady ani časy, takže akorát se těším na novinky z githubu a překládám si něco do zásoby.

Disassembler commented

2021-05-09 17:07:40 +02:00

(Migrated from git.spotter.cz)

changed the description

Disassembler commented

2021-05-09 17:12:03 +02:00

(Migrated from git.spotter.cz)

changed the description

Disassembler commented

2021-07-11 01:14:23 +02:00

(Migrated from git.spotter.cz)

Jen takový průběžný update, aby Vám nebylo smutno - Kontejnerový registr se mi podařilo rozběhat nativně, takže část té opičárny z mého předchozího příspěvku nebude ani potřeba. Naopak management přístupů bude možná o drobek složitější než jsem předpokládal, ale to je naštěstí relativně dobře ohraničený problém, takže až bude skutečně aktuální, půjde vyřešit bez větších komplikací.

Co se týče SPOC backendu - šťourám se tu v tom poslední týden a nějakého nezanedbatelného pokroku dosahuji, viz poslední dva commity ve větvi podman. Cca 2000 řádků kódu přidaných nebo změněných. Dokonce to programuji tak, jako bych to myslel vážně, tedy i včetně veškerých souborů pro instalaci přes pip a unit testů, kterými pokrývám 100 % kódu, heč. Myslím, že v tuto chvíli je backend hotový, takže mi jej zbývá jen otestovat nějakými integračními a systémovými testy a pak se můžu vrhnout na úpravu frontendu a přebalování aplikací z LXC do OCI formátu. Nějakou dovolenou během letních měsíců ještě mám, takže před třetí vlnou nejspíš ještě něco udělat stihnu.

Jen takový průběžný update, aby Vám nebylo smutno - Kontejnerový registr se mi podařilo rozběhat nativně, takže část té opičárny z mého předchozího příspěvku nebude ani potřeba. Naopak management přístupů bude možná o drobek složitější než jsem předpokládal, ale to je naštěstí relativně dobře ohraničený problém, takže až bude skutečně aktuální, půjde vyřešit bez větších komplikací. Co se týče SPOC backendu - šťourám se tu v tom poslední týden a nějakého nezanedbatelného pokroku dosahuji, viz poslední dva commity ve větvi [podman](https://git.spotter.cz/Spotter-Cluster/spoc/-/commits/podman). Cca 2000 řádků kódu přidaných nebo změněných. Dokonce to programuji tak, jako bych to myslel vážně, tedy i včetně veškerých souborů pro instalaci přes pip a unit testů, kterými pokrývám 100 % kódu, heč. Myslím, že v tuto chvíli je backend hotový, takže mi jej zbývá jen otestovat nějakými integračními a systémovými testy a pak se můžu vrhnout na úpravu frontendu a přebalování aplikací z LXC do OCI formátu. Nějakou dovolenou během letních měsíců ještě mám, takže před třetí vlnou nejspíš ještě něco udělat stihnu.

Podhorecky commented

2021-07-11 09:33:17 +02:00

(Migrated from git.spotter.cz)

Díky za zprávu, to zní nadějně. Já denně překládám všechny sw, které mne zajímají, používám k tomu i DeepL, který je viditelně šikovnější při překladu než je Google. Jestli chápu dobře, frontend upravíte jen v minimální nutnosti pro naše otestování nového backendu. Jsem docela nahnut k tomu využít nakonec kód DIAL pro front a po bližším průzkumu vlastností jej přizpůsobit pro náš účel.

Díky za zprávu, to zní nadějně. Já denně překládám všechny sw, které mne zajímají, používám k tomu i DeepL, který je viditelně šikovnější při překladu než je Google. Jestli chápu dobře, frontend upravíte jen v minimální nutnosti pro naše otestování nového backendu. Jsem docela nahnut k tomu využít nakonec kód [DIAL](https://git.spotter.cz/Spotter-Cluster/Spotter-Cluster/-/issues/109) pro front a po bližším průzkumu vlastností jej přizpůsobit pro náš účel.

Disassembler commented

2021-07-11 10:24:55 +02:00

(Migrated from git.spotter.cz)

DeepL je super. Užívejte, než jej nějaký Apple, Microsoft, Google nebo Jiný Amazon sežere a rozjebe.

Jestli chápu dobře, frontend upravíte jen v minimální nutnosti pro naše otestování nového backendu.

No, jakože ano, ale vzhledem k tomu, že mění celá platforma, nebude to změna úplně triviální. Například už nebude nadále vidět postup instalace takovým způsobem jako doposud, protože neexistuje způsob jak jej nějakým inteligentním způsobem převést do UI. Místo toho plánuji do UI pustit náhled toho, co se děje v terminálu, protože instance kontejneru přes podman vypadá třeba takto - https://asciinema.org/a/160217 - (tohle je sice docker, ale tato část vypadá úplně stejně i s podmanem).

Jsem docela nahnut k tomu využít nakonec kód DIAL

Pokud se "kódem" myslí UI/UX, pak je mi to celkem fuk a klidně jej můžeme vykrást z DIALu. Jinak je tohle docela neprůchozí. Jak se přes DIAL instalují kontejnery? Jak se managují certifikáty? Jak se restartuje VM? Nic z toho se tam nedělá, DIAL je prostě jenom katalog. Takže tak 75 % si stejně budeme muset napsat po svém, v kterémžto případě nedává smysl přebírat kód určený k něčemu úplně jinému. Fronted který potřebujeme my slouží k managementu VM (to je ta Vaše přidaná hodnota), jehož součástí je i management aplikací.

Leda že bychom celou tu ideu VM opustili, což si s podmanem už konečně můžeme dovolit udělat, a pak bychom potřebovali jen nějaký katalog s aplikacemi a dokumentací k nim, která by uživateli řekla: "Pusť příkaz spoc install sahana, vygeneruj si TLS certifikát, na webovém serveru si nastav tyhle tři řádky proxy, spusť aplikaci přes spoc start sahana a frčíš." V takovém případě by se pole působnosti DIALu daleko více přibližovalo tomu, co potřebujeme, nicméně pak už by ta aplikace s katalogem neběžela na VM (mimo jiné i proto, že by žádná nebyla), ale jako webík někde u Vás na serveru.

DeepL je super. Užívejte, než jej nějaký Apple, Microsoft, Google nebo Jiný Amazon sežere a rozjebe. > Jestli chápu dobře, frontend upravíte jen v minimální nutnosti pro naše otestování nového backendu. No, jakože ano, ale vzhledem k tomu, že mění celá platforma, nebude to změna úplně triviální. Například už nebude nadále vidět postup instalace takovým způsobem jako doposud, protože neexistuje způsob jak jej nějakým inteligentním způsobem převést do UI. Místo toho plánuji do UI pustit náhled toho, co se děje v terminálu, protože instance kontejneru přes podman vypadá třeba takto - https://asciinema.org/a/160217 - (tohle je sice docker, ale tato část vypadá úplně stejně i s podmanem). > Jsem docela nahnut k tomu využít nakonec kód [DIAL](https://git.spotter.cz/Spotter-Cluster/Spotter-Cluster/-/issues/109) Pokud se "kódem" myslí UI/UX, pak je mi to celkem fuk a klidně jej můžeme vykrást z DIALu. Jinak je tohle docela neprůchozí. Jak se přes DIAL instalují kontejnery? Jak se managují certifikáty? Jak se restartuje VM? Nic z toho se tam nedělá, DIAL je prostě jenom katalog. Takže tak 75 % si stejně budeme muset napsat po svém, v kterémžto případě nedává smysl přebírat kód určený k něčemu úplně jinému. Fronted který potřebujeme my slouží k managementu VM (to je ta Vaše přidaná hodnota), jehož součástí je i management aplikací. Leda že bychom celou tu ideu VM opustili, což si s podmanem už konečně můžeme dovolit udělat, a pak bychom potřebovali jen nějaký _katalog_ s aplikacemi a dokumentací k nim, která by uživateli řekla: "Pusť příkaz `spoc install sahana`, vygeneruj si TLS certifikát, na webovém serveru si nastav tyhle tři řádky proxy, spusť aplikaci přes `spoc start sahana` a frčíš." V takovém případě by se pole působnosti DIALu daleko více přibližovalo tomu, co potřebujeme, nicméně pak už by ta aplikace s katalogem neběžela na VM (mimo jiné i proto, že by žádná nebyla), ale jako webík někde u Vás na serveru.

Podhorecky commented

2021-07-11 10:43:23 +02:00

(Migrated from git.spotter.cz)

Pokud se "kódem" myslí UI/UX, pak je mi to celkem fuk a klidně jej můžeme vykrást z DIALu.

Ano, v principu jsem spekuloval hlavně o UI. Tedy doufám, že jsem vás nevyděsil. To znamená, že vše co děláme my je prioritní podle našeho návrhu a je pro mne důležité jak to navrhnete a realizujete. Vaše prvky které SPOC poskytne nutně musíme nějak ladit podle sebe.
Interfacem se chci přiblížit tak, aby bylo z mého projektu poznat na pohled, že se zabývám konkrétními oblastmi a tedy i softwary. Stále nemám nikoho, kdo by to pro mne udělal a tak se jako tonoucí chytám této příležitosti. Jestli UI bude nakonec jako lehký makeup umístěný na online hostingu - to je asi možné. Všechno důležité bude od vás na VM. Bez toho makeupu se mi bude hůře vysvětlovat cokoliv.

> Pokud se "kódem" myslí UI/UX, pak je mi to celkem fuk a klidně jej můžeme vykrást z DIALu. **Ano, v principu jsem spekuloval hlavně o UI.** Tedy doufám, že jsem vás nevyděsil. To znamená, že vše co děláme my je prioritní podle našeho návrhu a je pro mne důležité jak to navrhnete a realizujete. Vaše prvky které SPOC poskytne nutně musíme nějak ladit podle sebe. Interfacem se chci přiblížit tak, aby bylo z mého projektu poznat na pohled, že se zabývám konkrétními oblastmi a tedy i softwary. Stále nemám nikoho, kdo by to pro mne udělal a tak se jako tonoucí chytám této příležitosti. Jestli UI bude nakonec jako lehký makeup umístěný na online hostingu - to je asi možné. Všechno důležité bude od vás na VM. Bez toho makeupu se mi bude hůře vysvětlovat cokoliv.

Podhorecky commented

2021-07-11 11:13:23 +02:00

(Migrated from git.spotter.cz)

Respektive ještě takto: Stále pracujeme na obsahu a formě, která naplní misi tohoto projektu. Ještě nevim jak přesně to od vás dopadne a jsem přesvědčen že tomu dáváte maximum. A to znamená, že když bude v dokumentaci vypsáno +/- 15 spotterovských příkazů na udělání všeho co chceme, a ty se použíjí v příkazové řádce, tak OK, beru to jako že to tak musí být a je nejvhodnější. A pak bude někde UI o tom, že se zabýváme konkrétními SW a ty mají konkrétní vlastnosti a podmínky instalace. To bych měl rád v tom UI, ne jen jako markdown v adminovské dokumentaci.

v misi by měla být stále ta decentralizace a samostatnost toho co předáváme uživateli, aby projekt od spottera dával smysl.

Respektive ještě takto: Stále pracujeme na obsahu a formě, která naplní misi tohoto projektu. Ještě nevim jak přesně to od vás dopadne a jsem přesvědčen že tomu dáváte maximum. A to znamená, že když bude v dokumentaci vypsáno +/- 15 spotterovských příkazů na udělání všeho co chceme, a ty se použíjí v příkazové řádce, tak OK, beru to jako že to tak musí být a je nejvhodnější. A pak bude někde UI o tom, že se zabýváme konkrétními SW a ty mají konkrétní vlastnosti a podmínky instalace. To bych měl rád v tom UI, ne jen jako markdown v adminovské dokumentaci. v misi by měla být stále ta decentralizace a samostatnost toho co předáváme uživateli, aby projekt od spottera dával smysl.

Podhorecky commented

2021-07-18 10:38:34 +02:00

(Migrated from git.spotter.cz)

tady jsem si dovolil vizualizovat svou představu jak jsem pochopil současný stav. Neni to detailní ani kvalitní, když to kreslim bez myši.
Je možné že jsem něco nechytnul, nebo si představuji blbě, takže váš jistější pohled může být správnjější. (nejsou v něm přesně zachyceny toky a charakter dat které mezi tim proběhnou. ) Plán beru že je založen především na tom SPOC environmentu, takže vše ostatní viditelné pro uživatele má roli faceliftu UI.

Předpokládám, že později dojde na přesnější, přestože ne zcela detailní, náčrt našeho řešení, může se i objevit v dokumentaci. Případně upřesnitr dosavadní grafy
V tuto chvíli vás nechávám pracovat na tom, co máte v plánu, takže nemusíte hned reagovat.

Zdroj grafu mam zas v tom kreslícím sw na nextcloudu

tady jsem si dovolil vizualizovat svou představu jak jsem pochopil současný stav. Neni to detailní ani kvalitní, když to kreslim bez myši. Je možné že jsem něco nechytnul, nebo si představuji blbě, takže váš jistější pohled může být správnjější. (nejsou v něm přesně zachyceny toky a charakter dat které mezi tim proběhnou. ) Plán beru že je založen především na tom SPOC environmentu, takže vše ostatní viditelné pro uživatele má roli faceliftu UI. Předpokládám, že později dojde na přesnější, přestože ne zcela detailní, náčrt našeho řešení, může se i objevit v dokumentaci. Případně upřesnitr dosavadní grafy V tuto chvíli vás nechávám pracovat na tom, co máte v plánu, takže nemusíte hned reagovat. Zdroj grafu mam zas v tom kreslícím sw na nextcloudu ![graf](/uploads/75e3de2d7846226c55c8f8bb91502871/graf.png)

Podhorecky commented

2021-07-18 10:54:21 +02:00

(Migrated from git.spotter.cz)

ještě k tomu DIAL - podle mých pozorování se vývojáři dál snaží vytvářet prostředí, které odkazuje na SW a další stavební bloky a pravděpodobně také zprostředkuje instalační podmínky a skripty pro instalaci (víc nevim). Tohle si asi ověřím teprve až budu mít toto lépe přeloženo a k vyzkoušení jako nějaký admin. DIAL umožňuje přístup více uživatelských rolí, od obyčejného uživatele, přes majitele SW až po adminy kteří organizují obsah katalogu. DIAL řešení chápu a dává mi smysl, naše řešení je takový rozvíjející krok stranou, který dává větší důraz na uživatelské deploymenty.

Podhorecky commented

2021-08-01 11:48:57 +02:00

(Migrated from git.spotter.cz)

@Disassembler jak jste na tom s postupem?

Disassembler commented

2021-08-01 16:33:41 +02:00

(Migrated from git.spotter.cz)

Zatím nijak. Trochu času budu mít v týdnu 9. - 15. srpna a pokud zase někdo nebude umírat (momentálně umírá, snažíme se tomu zabránit neschváleným lékem z Číny cca za 80k CZK, protože schválený lék zatím neexistuje a nemoc je smrtelná; strašná sranda, někdy Vám o tom třeba povím) mám v plánu pohnout s tím frontendem (resp. hlavně API mezi backendem a frontendem) a zbude-li čas, přebalit i pár kontejnerů. Co se týče mých časových dispozic, od loňska se celkem nic nezměnilo (resp. změnilo, ale pro Vás k horšímu, takže se o tom snad ani nebudu zmiňovat), takže to co jsem tehdy psal (níže pro připomenutí) stále platí.

Stále se mnou můžete počítat ve věci občasných konzultací ohledně SpotterVM a věcí souvisejících a stále budu fungovat jako Váš serverový sysadmin. Dovolí-li to souhra mého stavu a volného času, občas možná i něco přicmrdnu do SpotterVM nebo upstreamu Sahany, čistě ze zvědavosti a dlouhé chvíle, bez nároku na jakoukoliv kompenzaci.

Zatím nijak. Trochu času budu mít v týdnu 9. - 15. srpna a pokud zase někdo nebude umírat (momentálně umírá, snažíme se tomu zabránit neschváleným lékem z Číny cca za 80k CZK, protože schválený lék zatím neexistuje a nemoc je smrtelná; strašná sranda, někdy Vám o tom třeba povím) mám v plánu pohnout s tím frontendem (resp. hlavně API mezi backendem a frontendem) a zbude-li čas, přebalit i pár kontejnerů. Co se týče mých časových dispozic, od loňska se celkem nic nezměnilo (resp. změnilo, ale pro Vás k horšímu, takže se o tom snad ani nebudu zmiňovat), takže to co jsem tehdy psal (níže pro připomenutí) stále platí. > Stále se mnou můžete počítat ve věci občasných konzultací ohledně SpotterVM a věcí souvisejících a stále budu fungovat jako Váš serverový sysadmin. Dovolí-li to souhra mého stavu a volného času, občas možná i něco přicmrdnu do SpotterVM nebo upstreamu Sahany, čistě ze zvědavosti a dlouhé chvíle, bez nároku na jakoukoliv kompenzaci.

Podhorecky commented

2021-08-01 16:37:50 +02:00

(Migrated from git.spotter.cz)

ach tak.. vpořádku. jen jsem ťuknul, víc v tom teď není. Řešte co dokážete a přeji hodně síly.

Sign in to join this conversation.