Live bootable VM nebo přesun na diskový oddíl #513
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: Spotter-Cluster/Spotter-VM#513
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?
Pardon, pokud je tato otázka příliš laická, nicméně mne zajímá:
našel jsem videum na tvorbu bootovacího drive z virtual machine, nicméně to už je předpokládám z nainstalované VM, nikoliv ze souboru .OVA používá tam software Systemback
Ptám se teď na nějaký známý, používaný postup. Tj. nemyslím tím, abychom nyní vynalézali dosud neobjevené, nebo se snažili o nějaký nestandardní hack. Jsem si vědom, že tu můžou vzniknout problémy s kompatibilitou hardware.
abych vysvětlil záměr: Instalaci na diskový oddíl myslím na typicky lokální počítač, který by byl schopný poskytnout výkon na běh VM. Přebootováním na tento oddíl by se stal server dostupným na IP adrese, doméně, a pak už by se dal použít přes síť.
Tento záměr tedy není kvůli instalacím klasického hostingu, nebo cloudů typu AWS nebo jiných globálních cloudových služeb. Byl by především pro lokální, tj. ne-hostingové servery. To znamená, že pro cloudy tuto VM nechci a nebudu řešit.
Pokud by příprava na tuto funkčnost vyžadovala nějakou úpravu, nebo vývoj v kódu co máme, bylo by to možné? Stalo by se to součástí základní nabídky VM, nebo to lze mít jako "Advanced services"?
Předpokládám, že by k tomu měla být dokumentace.
Celý tento nápad by mi vylepšil způsob použití VM a mohl bych to také tak sdělovat: "Software je možný spustit přes virtualizační platformu, jako LiveBoot, nebo nainstalovat na diskový oddíl"
Máte k tomu nějakou poznámku?
Kdyby se vám chtělo vyzkoumat, nebo vyrobit potřebné věci pro tuto funkčnost, zaplatím co si řeknete.
To jsou zas takové nevinné dotazy, u kterých je kloudná odpověď na dvacet normostran. "Bylo by možné..." No bylo, ale kurva za jakou cenu.
1 ) "bootovací VM" je trochu oxymoron. bootovací může být médium a to pak obsahuje instalátor nebo live image. VM je bootovatelná z principu, ale provozuschopná pouze pod hypervizorem. Ve videumu převádí image VM do live image, kterážto tímto krokem přestává být VM. Na to pod linuxem nejsou potřeba žádné speciální nástroje, drtivá většina distribucí má svoje, případně je distro tak nekomplikované, že stačí prostě překopírovat adresářovou strukturu a nainstalovat zavaděč. Ten Systemback, co tak koukám, je akorát nějaká lehká automatizace těchto úkonů.
2 ) "Jsem si vědom, že tu můžou vzniknout problémy s kompatibilitou hardware" je velmi zdrženlivě řečeno. Ve skutečnosti je to shitstorm nevídaných rozměrů. Náš systém čistě navržený a nakonfigurovaný pro běh ve VM. Obvykle je v operačních systémech hora ovladačů pro nejrůznější hardware, aby se systémové jádro vůbec nějak rozjelo. Alpine virt, který používáme, nemá prakticky žádné, což je právě to, co nám umožňuje dosáhnout tak malých a přenositelných velikostí image. Má pouze ovladače pro virtuální hardware. Kdyby mělo obsahovat ovladače komponenty, které mu umožní fungovat i na většině hardware, bude mít nejméně 20násobnou velikost.
Stejně tak naše konfigurace a skripty počítají s tím, že pojedou v unifikovaném prostředí. Ve chvíli, kdy do hry přitáhneme skutečný hardware nebo ještě navíc bootování z vyměnitelných médií, znamená to, že musíme tak půl roku práce na projektu od základu předělat. Musíme začít podporovat různé zavaděče (Extlinux pro BIOS, Syslinux pro ISO, GRUB2 pro UEFI, atd). Musíme začít počítat s tím, že systém místo virtuálního disku běží z bůhvíčeho, takže musíme například přestat předpokládat, že disk je šifrovaný. Musíme začít podporovat systémy s více než jednou síťovou kartou a s jinými typy než jen ethernet (tzn. třeba WiFi). A to jsou jen věci, které mě napadají bez hlubšího zamyšlení.
Teoreticky by se dal vytvořit instalátor vlastní distribuce založené na Alpine a vytvořit dokument, kde budou popsány jednotlivé kroky pro instalaci systému. Individuální hardware bude vždy vyžadovat individuální instalaci, ale pokud dosáhne nějakého společného bodu (nastavený disk, nakonfigurovaná síťová karta atd.), dají se balíky se software potřebným k ovládání a běhu kontejnerů doinstalovat z Vašeho apk repozitáře a budou fungovat tak, jako na VM. Možná by se dala udělat i nějaká naivní bezobslužná instalace, ale k tomu Alpine kvůli svému minimalismu moc vhodné není. Debian nebo Ubuntu by tu udělali lepší službu.
Nicméně znovu zdůrazňuji, že samotné kontejnery běží prakticky kdekoliv. Bavíme se o čtyřech různých vrstvách, které prezentujete, což je ten obrázek v dokumentaci ke SPOC Overview.
Takže ta věta "Software je možný spustit přes virtualizační platformu, jako LiveBoot, nebo nainstalovat na diskový oddíl" už platí, pokud rozlišujete "software" a "systém". SPOC a vlastní aplikační kontejnery jsou software a fungují kdekoliv. Jen k nim není to webové rozhraní VMMgr, protože to má primárně zprostředkovávat ovládání systému (VM). Když není VM, nedává smysl mít VMMgr. Pokud ale chcete bezobslužnou instalaci celého systému, který software out-of-the-box obsahuje, už je to trochu jiný příběh a v podstatě úplně nový projekt.
Tady asi nerozumím, jak s tím souvisí bootování. VM může být přece dostupná na síti úplně stejně jako fyzický stroj, stačí když je virtuální síťový adaptér v bridgi a ne přes NAT. Ostatně takto dostupné jsou všechny VM na mém hypervizoru.
hm, já nejsem uplný debil, já to jen neumím napsat těmi přesnými slovy a zároveň dát najevo, že něco z toho chápu, ale ne všechno. Nevím hlavně to, co se dá na serverech zařídit, protože jsem se servery v této úrovni nezískal zkušenost.
Můj bývalý zaměstnavatel mne používal jako cvičenou opici, takže jsem dělal na klientských počítačích jen to, na co byl postup a víc ani hovno. Udělat nějaké školení nebo zvýšit znalost v serverových virtualizacích mu přišlo zbytečné, takže jsem to nikdy neviděl.
Nevim jak mam odlišit termín VM ve všech významech, použil jsem to ve smyslu "jeden přenositelný soubor s operačním prostředím" zkusím to tako:
3 scénáře:
to co existuje
download .OVA ----> nahrát přes nějaký tool jako Rufus nebo jiné Kung-fu na externí medium ----> zasunout do PC , nabootovat ------> přihlásit se z jiného PC browserem na zjevenou adresu ----> nastavit potřebné údaje ----> stáhnout aplikace a používat jako server
download .OVA do pc ----> v PC mám prázdný diskový oddíl ----> s pomocí postupu nebo instalačního skriptu nebo replikovatelného Kung-fu přesunu .OVA do diskového oddílu + nastavím možnost volitelného bootu ------> nabootuju do nového diskového oddílu ------> zjeví se mi adresa na kterou se z jiného PC připojím a po zalogování nastavím potřebné údaje
Asi si to představuji moc jednoduše.
Když jsem před mnoha lety zkoušel poprvé nějaké to Ubuntu, tak jedna ze stažitelných instalačních image byla s Win instalátorem, který umožňoval linux zkusit nainstalovat, nebo spustit live. Najs. To mne tehdy pomohlo seznámit se s Linuxem na uživatelské rovině.
V našem případě po vás nechci, abyste vyráběl totéž, čili nějaký .exe instalátor, Taky je mi jasné, že instalační image jakéhokoliv OS má v sobě jinou sadu základních ovladačů a postupů jak to nainstalovat. Zatímco naše .ova je velmi úsporný vehement který to neřeší.
Takže já nevím jak se s tím a s hypervizorem dá pracovat na úrovni serveru, vím pouze jak se pracuje s hypervizorem jako klientskou aplikací.
Proto se ptám tak hloupě.
ano, vím že kontejnery se dají spouštět "takřka kdekoliv" taky vím, že jste se snažil o jejich vzájemnou koexistenci čtyř různých vrstev a o to asi jde.
Myslím že nikdo neni zvědavý na sdělení "tady si nainstaluj našich 20 různých kontejnerů, které dají instalovat kdekoliv..." a pak budeš mít to, co pan spotter tak komplikovaně lepil. Podobně jako jsem před pěti lety nebyl zvědavý na odpovědi vývojářů Sahany, že instalace je jednoduchá, tady je na to náš instalační skript ... (tehdy myslim ani neměli docker, ale po internetech se povalovaly NEFUNKČNÍ instalace téhož 5 let staré.) a s tím jsem se sám potýkal dlouho, pak jsem měsíce obcházel různé linuxové kutily ať mi s tím pomůžou a polovina neměla čas, chuť, protože musela vydělávat peníze, utrácet čas, nebo obojí a druhá polovina to ani s nejvyším úsilím nedokázala nainstalovat.
Nakonec jste vy realizoval "replikovatelný blbovzdorný postup" a já se mohl po několika letech instalace začít věnovat zjišťování, co ta aplikace vlastně neumí.
No a teď si to představte třeba 20x.
Tenhle dotaz je také o tom, co udělat "trochu" uživatelsky možné a zároveň aby to nebylo "všechno špatně, zpátky na začátek". Když bude mít někdo na serveru hypervizor, tak hurá, tím by mohlo být vše jednodušší.
Když ale někdo řekne "žádný hypervizor nemam, nechci a nepotřebuji, tudíž je váš cirkus naprd, tak ho asi rovnou pošlu dořiti, to je mimoběžné a nemá cenu dál diskutovat.
Samozřejmě teď se jen ptám, není to výzva k činnosti.
No ale tohle z principu není možné. Resp. je to značně a zbytečně komplikované, protože obraz VM je jiná fáze téhož procesu jako (samo)instalační bootovací médium. Obraz VM = bootovací médium + instalace a konfigurace v homogenním prostředí. Takže pokud chceme jednotnou cestu pro všechny větve, tak, jak je popisujete, musíme celý ten proces tvorby VM image změnit tak, aby fungoval i v prostředí, o kterém nic nevíme. To, co máme teď je tzv. Virtual appliance, jejíž smysl tkví právě v tom, že je distribuována jako hotovka bez procesu instalace. V případě, že nevíme na čem ten OS pojede, musí být součástí spouštění i proces instalace, ať už je jakkoliv automatizovaná.
To je důvod proč se třeba i POSM distribuuje jen jako ISO. Resp. dokonce tři image s různými předkonfigurovanými softwary k instalaci. Pokud jste někdy někde viděl i VM image POSM, znamená to jen, že někdo vzal to ISO, nainstaloval jej do VM a ty pak znovu zabalil. Pokud chceme být schopni vytvořit něco podobného, potřebujeme k tomu celý ten toolchain nutný k instalaci, který teď nemáme, protože Alpine je, podobně jako Sahana, skládačka, která umožňuje všechno, pokud k tomu máte patřičný skill. Byla vybrána právě proto, že původní požadavek na štíhlé prostředí VM plnila dokonale. Pokud chceme umožnit totéž i bez skillu, buďto kolem toho musíme postavit obrovské lešení anebo je to skutečně "všechno špatně, zpátky na začátek" a začít používat něco, co ty nástroje pro blbuvzdornou instalaci už obsahuje. Ono teda Alpine průvodce instalací taky má, ale je značně méně zářivý než třeba u toho Ubuntu a nepředpokládá, že uživatel je poloviční debil, třeba jako to Ubuntu.
Náš proces instalace v tuhle chvíli vypadá tak, jak je popsáno v prvním šedém boxu Virtual machine installation. Připadá Vám to komplikované? Myslím, že 4 zdokumentované příkazy zvládne skoro každý. Ale ty příkazy jsou jen 4 právě proto, že přesně víme, jak vypadá stroj na který se instaluje. Pokud to nevíme, musíme na to přijít nějakou chytristikou, kterou teď nemáme, protože jsem ji nikdy nepotřebovali anebo se zeptat uživatele. Ale zase tu narážíme na konflikt jednoduchosti a funkce, protože pokud to má být jednoduché, musíme tomu odebrat maximum funkcí. Při té nejjednodušší instalaci OS se instalátor typicky ptá na nastavení
I kdybychom nakrásně nastavili jazyk na angličtinu, čas na UTC, layout na en_US, všechna rozhraní na DHCP, repozitáře na globální umístění, software na to, co chceme my, na roota zakázali heslo a uživatelský účet nevytvářeli, pořád nám zbývá nastavení disku, což je právě ta nejsložitější a nejchoulostivější část z celého procesu. Ubuntu ve svém instalátoru má něco jako "smaž všechno a instaluj na čisto" a "použij všechno volné místo". V případě dual bootu se navíc přidává problematika zavaděče, protože Windowsí bootloader neumí pracovat z linuxem, ale naopak to jde, takže by se uživateli nainstaloval GRUB2, na který by čuměl jako tele na nová vrata a který vyžaduje značné porozumění toho, co se vlastně děje a co dělat, pokud se to náhodu dít přestane. Jinými slovy - dualboot rozhodně není pro každého.
No ale pokud tím chcete instalovat i on-premises servery (t.j. jakékoliv fyzické stroje, které mají plnit funkci serveru), tak Vás zase umlátí IT admini Cat5 kabely, protože instalovat OS, aniž by se třeba zeptal na IP adresu interface nebo vůbec na to který interface použít je úděsná prasečina. Stejně tak nemožnost nastavení časové zóny ztěžuje jakékoliv debugoávní. A o problému layoutu klávesnice ani nemluvím, protože na tom už jste si v začátcích nabil hubu sám.
No a pak zase - pokud ty funkce odebereme z instalace, musíme je zpřístupnit jinde. Mají být ve webovém rozhraní pro správu VM, které najednou kvůli veškeré variabilitě nabude stonásobně na složitosti anebo prostě adminům řekneme "hele, je to systém jako každý jiný, vlezte si tam po SSH a nastavte z komandlajny". A co kdybychom jim rovnou řekli "hele, je to systém jako každý jiný, nainstalujte si ho jak chcete, aniž bychom Vám kecali do úplně všeho, nakonfigurujte tak, aby těch pět zdokumentovaných věcí pasovalo a pak si doinstalujte tadyhle balík SPOC."
Aha ale to už teď vlastně máme. Fakt to nechceme zachovat? Ten blbuvzdorný replikovatelný postup jde vyrobit i pro instalaci celého systému IMHO udělá stokrát lepší službu než nějaký blackbox instalační skript.
No a to už vůbec nemluvím o tom, že live image (váš bod 2) a instalační médium (váš bod 3) jsou zase úplně jiná liga.
máte se mnou velkou trpělivost :) Za vysvětlení děkuji, občas prostě dojdu k otázkám, které spouští jen komplikace. Na náročné změny teď skutečně neni čas ani prostor.
asi jen odložím, v tuto chvíli nevím . Linux KVM a XEN
To jsou hypervizory. Ještě Vám tam do svaté troji chybí QEMU.
Xen je type-1 hypervizor (bare metal, paravirtualizace), QEMU je emulátor, který umí emulovat různé typy a architektury hardware. Sám může fungovat jako type-2 hypervizor (hosted) a Xen jej používá pro hardware-assisted virtualizaci. KVM je něco jako "akcelerátor", který zpřístupňuje různé virtualizační vychytávky skrze kernel hostitelského systému, třeba přímý přístup k procesoru, které by se jinak také musely emulovat. Ten ale funguje pouze na linuxovém kernelu. Jiné typy kernelů (BSD, darwin, NT) musejí použít jiné typy virtualizace a akcelerace.
Na všech možných kombinacích těcho hypervizorů SpotterVM funguje. Typicky se na linuxech používá QEMU-KVM, na kterém jsem jej testoval a na kterém mimochodem taky jede Váš server u Hetznerů.