Fórum Root.cz
Hlavní témata => Server => Téma založeno: maxlink 04. 10. 2016, 16:26:31
-
Mam ubuntu 16.04 LTS 64bit 48GB RAM, raid ssd, chci kontejnery, mám jít cestou dockeru nebo raději LXC/LXD nebo úplně něco jiného, nechci KVM, v kontejnerech budou "jednoduché" mašinky www server public, www server internal, email server, samba a dohled (zabbix), chci to mít od sebe oddělené, v kontejnerech předpokládám opět ubuntu server LTS.
Jde mi primárně o jednoduchost a docker moc neznám a přijde mi složitý, přikláním se spíše k LXC.
Ideálně na jeden "command" vytvořit virtuálku s danou velikost RAM, HDD a nějakou síť jako bridge z nějakého základního image (debootstrap 16.04 LTS) a na zbytek mám ansible scripty, které tam pustím a ty už mi jí setupnou k mému obrazu.
Díky za radu, nějak si nemohu vybrat.
Max
-
Zkousel jsem zabbix v dockeru a prislo mi ze to je "jako se drbat levou nohou za pravim uchem" obzvlaste kdyz budes chtit monitorovat obsahy dalsich dockeru.
Nakonec jsem se vydal cestou XenServeru free
-
Mam ubuntu 16.04 LTS 64bit 48GB RAM, raid ssd, chci kontejnery, mám jít cestou dockeru nebo raději LXC/LXD nebo úplně něco jiného, nechci KVM, v kontejnerech budou "jednoduché" mašinky www server public, www server internal, email server, samba a dohled (zabbix), chci to mít od sebe oddělené, v kontejnerech předpokládám opět ubuntu server LTS.
Jde mi primárně o jednoduchost a docker moc neznám a přijde mi složitý, přikláním se spíše k LXC.
Ideálně na jeden "command" vytvořit virtuálku s danou velikost RAM, HDD a nějakou síť jako bridge z nějakého základního image (debootstrap 16.04 LTS) a na zbytek mám ansible scripty, které tam pustím a ty už mi jí setupnou k mému obrazu.
Díky za radu, nějak si nemohu vybrat.
Max
Tak on by se podle me na toto dal pouzit i vagrant, vyhodou je ze si clovek pak muze spoustet "virtualky" v dockeru nebo v kvm ci virtualboxu...
-
Dělal jsem konsolidaci několika stávající serverů na jeden a lxc mě příjemně překvapilo svou jednoduchostí a stabilitou. Vlastně stačilo připojit stávající disková pole strojů do nového serveru a nakonfigurovat jednotlivá lxc.conf. Síť do bridge, využily se původní IP adresy serverů. Nakonec jsem nejvíc bojoval se systemd v jessie hostitele :-) Pro uživatele se nezměnilo vůbec nic.
Svého času jsem si hrál s dockerem, ale nevyhovoval mi princip kontejneru jedné aplikace, mít celý systém (i když mini) kvůli jedné aplikaci a nemoci se jednoduše přihlásit k ní do terminálu. Ale moje požadavky byly samozřejmě jiné a dnes už je docker asi zase jinde...
-
Opravdu zalezi, co presne potrebujes.
1) Docker ti zajisti jenoduchou spravu kontejneru/snadnou orchestraci (kubernetes/openshift origin) a je to v podstate takovy standard dnes (i kdyz se resi odklony k ocid atp. ale to je zatim dost nepodstatne). Hlavnim rozdilem je, ze bys mel mit jednu sluzbu v kontejneru tzn jeden docker pro Apache(s php treba) dalsi container pro DB/dalsi pro messaging - tohle ti umozni pak snadno aplikaci skalovat/migrovat jinam. Dalsi rozdil je v updatech v dockeru mas image a kontejner (predstv si binarku a proces) a vzdy updatujes image a restartujes kontejnery z ni vytvorene - tzn kontejnery v podstate nemaji stav - to ma ohromou vyhodu - kdyz se ti neco nezad muzes kontejner restartovat do casto rpredikovatelneho stavu - stary mezitim odlejt do staging kde ho debuggujes a produkce zatim muze(dle problemu) bezet.
2) LXC/LXD/Openvz se spis snazi spustit cely system v kontejneru je to takova spis lehci virtualizace. Ekosystem nastroju je takovy z minuleho tisicileti. Ma to sve pouziti, ale vyzaduje to jiny skillset u admina - v podstate je to porad server ktery udrzujes delas updaty standadrne atp.
3) systemd-nspawn je takove zajimave reseni nekde mezi - prinasi to relativne snadnou spravu - integraci do systemd (machinectl) - rekl bych ze tohle je asi nejsnazsi zpusob jak se na kontejnery dnes podivat z hlediska Linux admina, ktery se snazi uvazovat racionalne a nevidi rude pri zmince o systemd
Obecne je otazka jakou techologii zvolit dost slozita a dost se lisi ceho vlastne chces dosahnout.
-
Díky za shrnutí, nahodil jsem LXC, chci spíše "celé servery" v kontejneru né jen jednotlivé app.
Díky Max
Opravdu zalezi, co presne potrebujes.
1) Docker ti zajisti jenoduchou spravu kontejneru/snadnou orchestraci (kubernetes/openshift origin) a je to v podstate takovy standard dnes (i kdyz se resi odklony k ocid atp. ale to je zatim dost nepodstatne). Hlavnim rozdilem je, ze bys mel mit jednu sluzbu v kontejneru tzn jeden docker pro Apache(s php treba) dalsi container pro DB/dalsi pro messaging - tohle ti umozni pak snadno aplikaci skalovat/migrovat jinam. Dalsi rozdil je v updatech v dockeru mas image a kontejner (predstv si binarku a proces) a vzdy updatujes image a restartujes kontejnery z ni vytvorene - tzn kontejnery v podstate nemaji stav - to ma ohromou vyhodu - kdyz se ti neco nezad muzes kontejner restartovat do casto rpredikovatelneho stavu - stary mezitim odlejt do staging kde ho debuggujes a produkce zatim muze(dle problemu) bezet.
2) LXC/LXD/Openvz se spis snazi spustit cely system v kontejneru je to takova spis lehci virtualizace. Ekosystem nastroju je takovy z minuleho tisicileti. Ma to sve pouziti, ale vyzaduje to jiny skillset u admina - v podstate je to porad server ktery udrzujes delas updaty standadrne atp.
3) systemd-nspawn je takove zajimave reseni nekde mezi - prinasi to relativne snadnou spravu - integraci do systemd (machinectl) - rekl bych ze tohle je asi nejsnazsi zpusob jak se na kontejnery dnes podivat z hlediska Linux admina, ktery se snazi uvazovat racionalne a nevidi rude pri zmince o systemd
Obecne je otazka jakou techologii zvolit dost slozita a dost se lisi ceho vlastne chces dosahnout.
-
nemoci se jednoduše přihlásit k ní do terminálu
Sice trochu offtopic, ale možná se to bude někomu hodit:
docker exec -it container_id bash
Samozřejmě, je nutné tam ten bash mít :-) ale v nouzi stačí i dash. Horší je to když chci něco poeditovat, ale i ed stačí a člověka zocelí ;-)
-
Samozřejmě, je nutné tam ten bash mít :-) ale v nouzi stačí i dash. Horší je to když chci něco poeditovat, ale i ed stačí a člověka zocelí ;-)
Editovat v bezicim containeru by clovek nic nemel, oedituju image a pak restartuju - jinak si zadelavam na dost problemu. A kdyz uz nutne je treba neco takoveho je mozne si editor pomoci 'docker cp' dohrat nebo pomoci clone() vlezt do spravneho filesystem namespace.
-
To je přesně ten důvod, proč mi docker nevyhovuje. I základní úkony jsou velice komplikované - třeba v tom bashi bych si chtěl spustit screen a něco v něm sledovat - přežije ten screen ukončení toho připojení?
Na editaci něčeho nestačí pouhé ssh + edit. Ale jak říkám, mám jiné požadavky, než ke kterým je docker určen.
-
ja by som kontajnery nenazyval virtualizaciou, kedze to z principu virtualizacia nieje. Je to obycajny kernel procesovy namespace a control grupy. Zalezi uz len na poziadavkach a konfiguracii kolko % user space ma byt zdielana s "hostom" a kolko unikatna per kontainer.
-
Jak se updatuje system v tech LXC kontainerech? Jde to hromadne pro vsechny, pokud vychazi ze stejneho zakladu?