VM architektura a jiné bláznivé nápady #290
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Disassembler/Spotter-VM#290
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
dotaz:
Na základě předchozího návrhu na oddělenou strukturu vrstev VM a systém aplikačních kontejnerů se chci zeptat jestli se tím ta architektura stane výrazně univerzálnější, nebo jestli jen usnadní operace s našimi konkrétními apps? Chápu že to je dost jednoduchá otázka a složitá odpověď... nicméně proč se ptám:
Bylo by praktické do takového řešení vkládat i upe cizí (tj. ne vámi) připravené kontejnery?
Ušetřil by se tím čas, energie, peníze, problémy? Nebo spíš ne?
Tohle je zrovna konkrétní případ... stálezelené téma ofline mapového serveru OSM
https://store.docker.com/images/openmaptiles-openstreetmap-maps
Lze spekulovat, že v případě potřeby by si někdo přilepil do VM i tento docker s vektorovými mapami? Trochu skriptování navíc? A pak by asi bylo na nastavení některých aplikací, zda VMS dokáží využít offline?
Toto není jeden jediný případ, vybral jsem ho že už jsme to diskutovali a vždycky to skončilo na tom, že nejsou lidi kteří to umí rozchodit.
Pochopitelně je tématem budoucnosti i vlastnosti a konkrétní fungování toho serveru, který byste pro tyto kontejnery připravil... Nicméně to můžeme pokračovat do jiné issue.
Celé to vnímám jako dobrý systemový rozvoj hvězdoletu. Což teda není myšlenka vůbec unikátní, ale zaměření na humanitární oblast zatím ještě není běžná.
Cíl mám pořád stejný... humanitární SW... jenže jak oba vidíme, tak se některé aplikace rychle rozvíjí, jiné rychle umírají.
Můžete mne tedy jen potěšit, že v případě zájmu by šel přilepit jiný kontejner? Otevřeli bychom si tím cestu do světa , nebo spíš díru do pekla?
poslední poznámka pod čarou je jen o tom, že znám člověka, který se živí jako frontendový designer v Praze. Něco málo o mém projektu ví, ale ne příliš. Nedávno změnil práci a naznačil mi, že jeho zaměstnavatel má důležitého klienta v ČR, který pracuje na "čemsi" co je podobné mému projektu. Víc mi neřekl, protože NDA. Akorát poznamenal, že je to byznys za velký peníze, ale že ten můj přístup k věci mu přijde jako "systemovější" a víc z nadhledu.
O tom píšu proto, abyste pochopil jaké info se ke mě dostávají a jak se ty info občas spojují. Naprosto nepochybuji, že někdo někde pracuje na komerčních zakázkách s nějakým možná podobným záměrem. A že to může být supr byznys, pro konkrétního zadavatele. Za 3 měsíce hotový, hurá funguje to...
A já chci aby mě tahle konkurence netrápila, protože proti ní od začátku nemám šanci uspět u těch komerčních zákazníků. Takže proto budu hledat cokoliv, abych se jí vyhnul. To znamená hledat nějaký jiný rámec než je "konkrétní kšeft" a v tom rámci používat to, co by komerční firma spíš nepoužila. Jestli bude ten nadhled kvalitní, tak se prosadí i moje VM.
changed the description
Ano, architektura se stane výrazně univerzálnější a kdokoliv si do VM bude moci nainstalovat cokoliv, pokud to cokoliv bude mít na nějakém distribučním serveru, který se bude dát nastavit, a pokud to cokoliv bude mít odpovídající formu, která bude patřičně zdokumentovaná.
Hrubý nápad je takový, že na distribučním serveru bude existovat nějaký index, kde bude řečeno, jaké vrstvy (aplikace / archivy / balíky) se na něm nachází a jaké závislosti mají. Např. že CKAN potřebuje ActiveMQ, Solr, postgres a že ActiveMQ i Solr potřebují Javu. Pak tam budou ty jednotlivé archivy s danou vrstvou (kontejnery používají jednotlivé diskové vrstvy, které se při spuštění splácají přes sebe - tzv. overlay, čímž se šetří místo, pokud těch kontejnerů máte kýbl nebo pokud spouštíte více instancí téhož image) a pak tam bude malý archivek pro prvotní instalaci daného image. Např. skript pro konfiguraci CKAN databáze v kontejneru s postgresem, registraci Solr jádra, ActiveMQ front a vytvoření služby pro samotný CKAN kontejner. Tento skript bude v budoucnu sloužit i pro upgrade. Je to celé vlastně úplně stejný systém jako používají balíčkovací manažery na linuxech nebo Homebrew na Macu nebo Chocolatey na Windows. Pokud bude administrátor distribučního serveru lenoch, nemusí závislosti řešit vůbec a bude prostě distribuovat úplné obrazy se vším všudy.
Uživatel si tak v rozhraní najede do instalační nabídky, přihlásí se, pokud to distribuční server vyžaduje a klikne si, že chce instalovat CKAN. Aplikační manažer si na serveru přečte, jaké všechny závislostí k němu musí stáhnout, postahuje všechny archivy s obrazy a skripty, které uživatel ještě nemá, rozbalí, poskládá si strom závislostí a spustí ke všem nově staženým obrazům instalační skript. Upgrade bude později probíhat úplně stejným způsobem. Uživatel si klikne v rozhraní, že chce aktualizovat, stáhne se aktualizovaná vrstva včetně instalačního skriptu, zastaví se běžící instance daného kontejneru, nahradí se vrstva, spustí se skript který dostane informaci o tom, ze které verze na kterou se aktualizuje a provede patřičné akce, pokud jsou nějaké potřeba.
Takže ano, ve výsledku se klidně může stát, že někdo vezme dockerový kontejner z hotového úplně cizího projektu, dopíše si k němu instalační skript (v současnosti ty naše skripty mají délku mezi 5 a 20 řádky), zaindexuje si na distribučním serveru (to se dá později automatizovat) a může vesele instalovat.
Celé to zní krásně, ale zrovna Docker nám v něčem takovém dost háže klacky pod nohy, protože nedovoluje volně manipulovat s vrstavmi a neumožňuje nastavit vlastní distribuční server. Důvody, které k tomu autoři uvádí jsou IMHO dost debilní, takže teď ještě experimentuji s LXC, které má daleko méně abstrakce a umí vše, co potřebujeme. Všichni frikulíni ale bohužel distribuují aplikace v Dockeru, takže by pak použití naší platformy vyžadovalo trochu více skillu než jen tupé copy-paste.
Stav implementace k 5. říjnu 2018.
Kontejnery a vrstvy:
Aplikace běží v LXC kontejneru. Kontejner v tomto případě znamená konfigurační soubor ve kterém je nastaveno
Dále kontejner zahrnuje alespoň jednu diskovou vrstvu. Pojem "vrstva" je zde použit proto, že naše kontejnery používají souborový systém překryvných vrstev OverlayFS. To znamená, že můžeme mít například jednu diskovou vrstvu pouze se základním systémem, jednu vrstvu s python runtime a jednu vrstvu se samotnou aplikací. V konfiguraci kontejneru tyhle tři vrstvy pak splácneme dohromady, takže nemusíme mít kopii systému a kopii pythonu v image každé aplikace, která je vyžaduje a ušetříme tak hromadu místa. Docker dělá něco podobného, ale je životně závislý na přesném pořadí příkazů v
Dockerfilesouboru pro výstavbu kontejneru. Takže pokud máme jeden kontejner, kde potřebujeme systém, python a javu a druhý, kde potřebujeme systém, javu a nodejs, bude společný pouze systém, ale java už nikoliv, protože pořadí je odlišné. S LXC máme plnou kontrolu nad tím, jaké vrstvy spojujeme, takže na pořadí nejsme závislí a musíme si jen pohlídat, aby si jednotlivé vrstvy nepřepsaly něco, co přepsat nechceme, což se díky návrhu Alpine linuxu neděje.Výstupem tohoto návrhu jsou tedy jednotlivé překryvné vrstvy, které budou následně baleny do samostatných balíků. Ke každé aplikaci (tedy jen k takovým překryvným vrstvám, které obsahují koncovou webovou aplikaci a nikoliv jen závislosti) bude ještě přibalen konfigurační soubor jejího kontejneru a skripty pro instalaci, např. vytvoření databáze, nastavení hostname, mailu a Google maps API klíče v konfiguraci atd. Například k tomu, abych nainstaloval CKAN kontejner potřebuji balíky
Balíkovací sytém:
Výše vystavěné balíky jsou pak zkomprimovány pomocí kompresního algoritmu LZMA/LZMA2 (xz), který je jedním z nejefektivnějších. K tomu, aby byl balík distribuovatelným, potřebuje ještě metadata. Ta jsou drženy mimo obsah balíku a jsou známy distribučnímu serveru (a následně i klientovi, pokud se jej rozhodne stáhnout). Mezi metadata mimo jiné patří
Distribuční server pak nabízí:
Při výstavbě balíku tato metadata poskytuje builder, který si zároveň drží kompletní aktuální kopii metadat distribučního serveru (samotné balíky mít nemusí). Zároveň musí vlastnit soukromý podpisový klíč (momentálně používáme ECDSA s křivkou P-384, ale může být použit libovolný jiný), pomocí kterého při změně souboru s metadaty vytvoří nový podepsaný hash. Tento soukromý klíč není uložen na distribučním serveru ani jím distribuční server nijak nedisponuje, takže i v případě jeho napadení nebude možné podvrhnout metadata nebo obsah balíků. Vytváření nového balíku probíhá následovně:
Instalace ze strany klienta:
Klient má v základní instalaci nainstalován veřejný klíč, který pasuje k soukromému podpisovému klíči, kterým je podepisován soubor metadat. Zároveň má klient nakonfigurovanou adresu distribučního serveru. Tím je zajištěna kompletní integrita distribučního kanálu. Při jakékoliv akci s balíky, která vyžaduje účast distribučního serveru (tj. instalace, zjištění nejnovější verze balíků a upgrade), klient nejprve stáhne soubor s metadaty a jeho podepsaný hash a ověří podpis s pomocí předinstalovaného veřejného klíče. Pokud podpis nesedí, operaci ihned ukončí. Díky použití asymetrické kryptografie je podpis nefalšovatelný a jediné dva případy, jak se tento mechanismus dá obejít, jsou ukradení soukromého klíče z počítače buildera nebo injektování škodlivého veřejného klíče do VM klienta a zároveň použití jiného druhu útoku, např. podvržení DNS záznamu nebo průnik do skutečného distribučního serveru.
Klient tedy stáhne a ověří metadata a po úspěšném ověření z nich vyčte, které balíky musí stáhnout a nainstalovat k tomu, aby mohla proběhnout i instalace balíku požadovaného uživatelem. Sestaví tedy strom závislostí a ten pak porovná se souborem metadat lokálně uloženém u klienta, který obsahuje informace pouze o již nainstalovaných balících. Ty balíky, které klient ještě nemá, balíčkovací systém postupně stáhne a u staženého souboru ověří SHA512 hash uvedený v podepsaném souboru s metadaty z distribučního serveru (tzn. opět není jednoduše možné soubor podvrhnout, protože by nesouhlasil hash a není možné podvrhnout hash, protože je soubor s metadaty podepsaný). Pokud hash souhlasí, balík rozbalí a je-li přítomen instalační skript, spustí jej.
Takže například k tomu, abych nainstaloval CKAN aplikaci potřebuji balíky
Balíkovací systém tento strom závislostí splácne, zjistí, že základní systém, python2, xml a PosgreSQL už mám nainstalovány kvůli jiným aplikacím, a tak stáhne a rozbalí jen Java runtime, Solr, Redis, CKAN DataPusher a nakonec samotný kýžený CKAN.
Proces upgrade stávajících balíků zatím implementovaný nemám, ale principiálně to bude vypadat úplně stejně.
Veškeré procesy, praktiky a postupy jsou okoukány z existujících balíkovacích systémů, nejvíc jsem se inspiroval asi u Debianího
dpkg. Nemělo by na tom být nic tajného nebo obskurního, takže klidně můžete zkonzultovat s třetí stranou, jestli jsem na něco nezapomněl nebo nezjednodušil do míry, která by učinila bezpečnost neúčinnou.mentioned in issue #301
Potřebuji exekutivní rozhodnutí.
Z 99% jsem dokončil transformaci balíčkovacího backendu na APK (nativní Alpine linux systém), jak jsme řešili po mailech na konci října a začátku listopadu. Čím víc jej testuji, tím méně se mi to celé líbí.
Na jednu stranu je fajn, že nemusíme řešit věci jako
Na druhou stranu ale
Možné směry, kterými se vydat:
a) Pokračovat ve výstavbě nad Alpine systémem bez podrobného přehledu dění a selhání komponent řešit logikou ve vlastních skriptech (v post-upgrade kontrolovat zda aplikace byla vůbec někdy nainstalována a pokud ne, tak místo zbytku post-upgrade provést post-install). - Nejméně pracné, ale náchylné k neočekávaným chybám.
b) Pokračovat ve výstavbě nad Alpine systémem, ale postavit si vlastní abstrakci pro zjišťování, stahování a instalaci závislostí - tj. místo workflow "zadej instalaci balíku aplikace a nech APK ať se o vše postará -> počkej na dokončení instalace nebo chybu" bude "zjisti závislosti balíku aplikace -> po jednom stáhni instalační balíky pro Alpine -> po jednom zadej instalace lokálně stažených balíku". Tím si zlepšíme viditelnost a kontrolu nad tím, co se děje, takže i odolnost proti chybám. - Středně složité, ale už z toho děláme rovnák na vohejbák na rovnák na vohejbák.
c) Alpine balíky zahodit a vrátit se zpět k vlastnímu řešení. Všechno si budeme muset řešit sami, ale budeme mít úplnou svobodu nad tím, jak to bude vypadat a úplnou kontrolu nad tím co a v jakém pořadí se bude dít. Většinu už máme napsanou a otestovanou. - Středně složité, se zvyšující se složitostí s postupným přidáváním featur.
Osobně bych byl samozřejmě pro možnost c) a pokračování ve vlastním řešení, ale já už jsem takovej, že si vždycky chci dělat všechno po svém, což mnohdy nemusí být vyhovující pro všechny zúčastněné, takže se radši ptám. Ta problematika je samozřejmě trochu hlubší, takže pokud máte nějaké dotazy na funkce, údržbu nebo další rozdíly, rád je zodpovím, abychom se dobrali nějakého pevného směru.
jak to čtu, tak se přikláním k c) ačkoliv tuším, že to "může" mít jak výhody, tak i nevýhody. Nikdy nic není dokonalé. Akorát nejsem expert, tím jste vy.
Abych byl v pohodě s c) tak bych od vás potřeboval nějaký příslib, že ještě chvíli vydržíte na tom pracovat do stavu, který bych laicky popsal jako "stable core" a další budoucnost je ve hvězdách, sice na různých potížích růstu, ale řekněme, že s dobrou vůlí se k blízkým hvězdám dobereme.
Teď neumím formulovat přesnější technický dotaz. Asi mne napadnou otázky až mi představíte nové věci, nebo až se začnu šťourat v těch dalších plánech.
v závěsu je pak varianta b) ... která ale má pro mne slabou pozici... Bylo by později hloupé navazovat nějaké kooperace... a s rovnákem bychom rychle od někoho sklidili čočku za to, co v tu chvíli jistě už bude nějak lépe a dokonaleji vyřešeno... Samože je těžké obhajovat se, když kdokoli umí být po bitvě mudrlantem. Proto bych asi nás oba spíš chránil před b) a důvěřoval v c) kde musím sázet ve vaši zkušenost.
Ještě stručně aktualizuju můj výhled. Pracovně se mi nerýsuje žádné dramatické zlepšení pro rok 2019, takže dál pokračuji jako OBZP. 2020 se zlepší jen pokud vybojuji pár osobních bitev o příjmy z budoucí práce, bydlení. Peníze na tento projekt stále existují, jen existují i neznámé proměnné, které ještě budu muset vynaložit. A tak jediné, co je je pevné, nejsou moje běžné příjmy, jen pomalé úspory. S těmi budu muset vyjít i pro ty další vývojové kroky a snad i zapojené lidi. Můžete mi to usnadnit tím, že mi pomůžete při pozdějším zasvěcení dalšího člověka. (ano, už jste mi to navrhoval, tak s tím taky trochu počítám)
Výhled vnějších do sfér, do kterých projekt směřuju, je poněkud neradostný. Tj. události se množí rycheji, než je nám milé. Neumím se radovat z vážných zpráv, byť by mi měly nést víc potenciálních příležitostí. Těmito info vás ale neobtěžuju, protože je lepší se soustředit na práci, abychom ji dotáhli.
jinak mi tento vývojový milník nevadí, chápu jej jako nutné poznání v procesu a nemám problém změnit dosavadní strukturu, dál o tom takto přemýšlet a hledat nejlepší cestu. Díky za to!
Vrátil jsem tedy vývojovou větev k vlastnímu balíčkovacímu řešení, přičemž jsem do něj zakomponoval drahocenné poznatky získané při práci s APK balíky a abuild systémem. Jsem velice rád, že jsme tuto větev prozkoumali, protože mi pomohlo ujasnit si a zjednodušit některé věci ve workflow identifikace závislostí -> stažení balíků -> zaručení čistého prostředí -> instalace balíků -> registrace aplikací pro GUI. Myslím, že to teď máme v téměř optimálním stavu. K naprosté dokonalosti to pak dovedeme s finálním (nebo alespoň semifinálním) web GUI.
Nicméně jsem se pokusil nainstalovat a zkontrolovat všechny aplikace, které dosud máme sestavené a připadám si jako takové to tříleté dítě, co sbírá balónky a vždy, když se nahne pro další mu ten předchozí vypadne. Namátkou:
K tomu navíc
Takže zdokumentuji instalační a balíčkovací procedury a pak se po x-té pokusím opětovně zprovoznit aktuální verze aplikací a pak snad už pojedeme dál.
ok, super zpráva.
s těmi aktualizacemi to je mrzuté, ale viděl bych to jako indicie k rozhodnutí, jak často se věnovat aktualizacím těch konkrétních SW. A které se později samy vyřadí z evoluce.
takže při nějakých zvlášť vypečených situacích nepáchejte harakiri, napište mi co si o tom myslíte a můžeme to posoudit.
u CC už víme, že takto nám poslouží maximálně jako technologické demo, že to umíme kontejnerovat. O budoucnosti rozhodne i autor a jeho plán "nové verze"... fakt jsem zvědav.
u dalších SW je to výběr s čím se asitak můžeme potkat. Moje další SW se +/- staví pořád na tom samém. Detaily objevíme až při bližším ohledání.
Tak to šlo podstatně lépe než jsem očekával.
Takže appky máme vesměs naházené na aktuální verze a funkční (Na vaší VM, kterou jste stahoval loni v listopadu ale nepojedou, protože balíčkovací systém a vmmgr už se zas posunul o kousek dál. To doladíme záhy). Teď konečně dorazím tu dokumentaci.
(on asi neví že J.P. = trendspotter, takže zatím nemá smysl ho dál dráždit. Má za sebou velké množství práce s provozem CC, ale dost trpí, že není financovaný a nemá lidi na vývoj... )
Dokumentace technické a technologické části vypocena zde: https://dl.dasm.cz/spotter-doc/index.html . Teď už mě konečně může přejet náklaďák.
Pak, až budeme konsolidovat ty Vaše webové appky a jiné worpressy, přesuneme dokumentaci společně s repozitářem a ostatními opičárnami na server k Vám, ať se to neválí na mé odkladištní subdoméně.
mentioned in issue #337
další kroky se serverem budou v issue https://git.spotter.cz/Spotter-Cluster/Spotter-Cluster/issues/294 nebo nových issue
closed