server // services inrichten: plain, lxc, esxi?

[EnnaN]

Omdat hardware weer eens niet meewerkt is het kennelijk tijd om een nieuwe thuisserver in te richten, en ik vroeg me af of er een slimmere manier is dan een simpele machine met rechtstreekse install van alles.

Mijn huidige server is een ubuntu 12.04 (LTS) waar een aantal dingen op draait, zoals

* Een aantal fileserver taken (smb, nfs, afp)
* LAMP stack ter ondersteuning van de webapps en voor testen websites
* downloads: sickbeard, couchpotato, sabnzbd, spotweb, deluge
* domoticz
* nagios
* Verder wordt hij gebruikt als machine om wat op te compilen, testen en spelen met projectjes.

Een mogelijkheid voor de nieuwe install is om gewoon de opvolger in te richten met (waarschijnlijk) 14.04, de boel weer te installeren en dan klaar te zijn. Maar ik vroeg me af in hoeverre een andere oplossing mogelijk is, bv met virutalisatie.

Doel: 'handigheid'. Dat kan bv zijn dat verschillende servers makkelijker gescheiden zijn (en bij problemen er maar 1 ding issues heeft, een bepaalde library makkelijk kan geupdate worden omdat er minder dependencys zijn per onderdeel, etc), je evt snel een clone kan starten vanuit de template, etc.

Opties volgens mij

* ESXi : Heb ik ervaring mee, maar eerlijk gezegd lijkt het me best wel veel overhead geven om voor elk apart doel hier een volledige server in te richten. Ook de backupmogelijkheden van zo'n server zijn niet ideaal. Je kan een template maken van een VM, maar daar houd het bij de gratis versie nogal op.
* LXC: beetje ervaring mee (als in, wel eens 1 gebruikt). Ik zie hier mogelijkheden, maar ben er nog niet helemaal uit hoe je dat inricht. Verschillende LXC's gebridged aanbieden, en dan je installs volledig via ansible oid doen? Dan zou je bij problemen gewoon nieuwe kunnen deployen, zo nodig op een andere machine?
* andere virtualisatie-vorm?

Een optie zou dan bv zijn om een 'blokje' voor domoticz, een blokje downloads, een blokje fileserver etc te maken. Maar als het dan toch zo ver is zou een mogelijkheid om het makkelijk te knippen en plakken naar een andere machine (evt met install tussendoor vanuit een playbook) wel gaaf zijn.

Grootste gedeelte van de tijd draait het ding gewoon en wordt er weinig mee gedaan behalve 'gebruikt' overigens, dus heel veel gaafheid in beheer is natuurlijk mooi qua tweaker-interesse, maar het blijft een vrij simpel thuisservertje.

Als ik dit zo tik lijkt ik geloof ik te neigen naar een simpele basis 14.04 te maken, en LXC's te maken voor een aantal services / service groepen. Maar daarvan weet ik niet of je bv makkelijk alle install "los" kan houden (zodat je die snel nog een keer kan doen) en hou bruikbaar een dergelijke omgeving is.

Hoe doen jullie het of zouden jullie het willen doen als je toch overnieuw moet beginnen?

[Hero of Time]

Naast dit alles, heb je ook naar KVM gekeken? Hier kan je net als ESXi templates e.d. maken, maar ben je niet gelimiteerd in de mogelijkheden die de gratis licentie bied zoals bij ESXi, omdat er helemaal geen licentiekosten zijn.

Ik zou hoe dan ook een paar zaken gescheiden houden. Je fileserver en downloads zullen vast wel bij elkaar komen, maar compileren zou ik toch in een aparte install willen doen om zo m'n main install schoon te houden van allerlei development packages.

LXC klinkt ook erg aardig, ik ken alleen Docker als zoiets maar ook daar heb ik eigenlijk nooit mee gewerkt (net als KVM overigens).

[EnnaN]

Goed punt, die had er eigenlijk bij gemoeten.
KVM als vervanger ESXi kan inderdaad vrij goed voor zover ik weet, hoewel in mijn geval ik meer prettige ervaringen met ESXi heb (hoewel dat kan veranderen).

LXC vs KVM is een ander geval: KVM doet wel virtualisatie, en heeft dus een laagje er tussen. LXC heeft dat niet; je zit dus wel vast aan je main kernel. Dat is voor zover ik van plan ben te gebruiken geen probleem (denk ik).

Docker vs LXC is natuurlijk ook een discussie, weer 1 die ik vergeten was. Ik moet eerlijk zeggen dat ik dat verschil niet zo weet, daar duik ik in.

Iemand een idee over provisioning? Hoe maak ik mijn landscape aan software (wat, als je het sec neemt, gewoon een simpel thuisservertje is, maar goed) zo dat ik het makkelijk ergens anders // opnieuw // etc kan releasen. Ansible? Puppet? is dat uberhaubt niet meer werk dan nuttig is? want een andere oplossing is gewoon /etc backuppen en ogen dicht...

(dat laatste heb ik niet heel veel voordeel van , want ik ga nu direct van 12.04 naar 14.04, en voor ik dat compatible heb draaien kan ik net zo goed die twee flags zelf omzetten )

[Verwijderd]

Je kunt ook gaan kijken naar CoreOS en dan met name naar Docker of Rocket. Of je pakt Arch en gaat aan de slag met Docker. Het verschil tussen lxc en Docker is vrij groot. Je kunt hier genoeg over vinden op de Docker site.

Mijn ideale setup:

KVM VM's met CoreOS en vervolgens alle app/services in docker containers.

[EnnaN]

hmm, waarom draai je daar meerdere CoreOS VM;s? Als ik je goed begrijp heb je dus een install waarin je KVM's hebt waar dan weer CoreOS op draait. Is dat niet een stapje te 'diep' ?

CoreOS ken ik niet daar zou ik ook naar moeten zoeken. staat op de lijst

[smeerbartje]

Relaxt topic; op m'n werk ook veel met Docker bezig en ik wil m'n home-server eigenlijk ook volledige "dockerizen". Probleem is volgens mij wel een rechten-ding. Om in je "nzbget"-container bij een share te kunnen die je "smb"-container heeft gemaakt, dáár voorzie ik nogal wat problemen.

[ Voor 42% gewijzigd door smeerbartje op 28-12-2014 22:13 ]

[EnnaN]

ik wou eigenlijk daarvoor een vrij open "data" plek maken: evt op een aparte machine (bv op een NAS), of anders een NAS-vm waar iedereen bij kan. Zo kunnen de clients er uiteindelijk ook van lezen. Denk dat NFS misschien beter is dan docker? weet eigenlijk niet.

Wat ik nog niet helemaal vat bij docker: ik heb een dockerfile waar alles in moet staan -> maar wat als ik settings verander? Bv domoticz is een docker file van te vinden, maar alle veranderingen die ik doe, verdwijnen die dan niet als ik een update wil doen (en dus een nieuwe unit moet bouwen, toch?)

[Hero of Time]

smeerbartje schreef op zondag 28 december 2014 @ 22:12:
Relaxt topic; op m'n werk ook veel met Docker bezig en ik wil m'n home-server eigenlijk ook volledige "dockerizen". Probleem is volgens mij wel een rechten-ding. Om in je "nzbget"-container bij een share te kunnen die je "smb"-container heeft gemaakt, dáár voorzie ik nogal wat problemen.

Enige probleem wat je daar in zou kunnen zien, is als je weinig ervaring hebt met netwerken en bridgen. Op mijn werk wil een ontwikkelteam ook gebruik maken van Docker en dat kan prima. Je maakt een bridge interface aan, hangt daar je fysieke eth0 aan en al je Docker instances maken gebruik van die bridge. Alles kan dan met elkaar communiceren, uitgaande dat je IP nummering klopt en iptables of firewalld niet in de weg gaat zitten.

[Basz0r]

Ik zou het Docker gedeelte alleen voor je Webserver gedeelte gebruiken. Mijn ervaring is dat je toch zo nu en dan iets in het OS zelf qua configuratie wil wijzigen, en om dan continu je docker files hierop aan te passen is niet ideaal. Het is qua beheersgemak in productie omgevingen ideaal, maar voor een thuisomgeving is het overkill.

Mijn advies is om op de fysieke hardware Linux KVM te draaien en hierop diverse VM'etjes te draaien voor de services die je wil scheiden (Fileserver VM, Download VM, Monitoring VM, etc.). Dan kan je altijd nog een VM opbouwen waarmee je bijv. Docker images maakt voor je webomgevingen (Docker is ideaal voor OTAP omgevingen).

Het KVM gedeelte kan je ook vervangen met LXC, maar als je dan een nieuw OS (FreeBSD/Windows) zou willen testen op je thuisserver zit je met het limiet dat LXC alleen kernel gebaseerde virtualisatie is.

[smeerbartje]

Hero of Time schreef op maandag 29 december 2014 @ 10:51:
[...]

Enige probleem wat je daar in zou kunnen zien, is als je weinig ervaring hebt met netwerken en bridgen. Op mijn werk wil een ontwikkelteam ook gebruik maken van Docker en dat kan prima. Je maakt een bridge interface aan, hangt daar je fysieke eth0 aan en al je Docker instances maken gebruik van die bridge. Alles kan dan met elkaar communiceren, uitgaande dat je IP nummering klopt en iptables of firewalld niet in de weg gaat zitten.

Dat bedoel ik niet . Ik bedoel dat Docker container één (de nzbget container) een file aanmaakt en dat deze file eigenlijk vanuit de host niet te benaderen is (heeft ook user root, etc). Om dan de file "benaderbaar" te maken zit er eigenlijk niets anders op dan een andere container (samba ofzo) in de lucht te gooien en beide container te "linken".

[Basz0r]

smeerbartje schreef op maandag 29 december 2014 @ 21:31:
[...]

Dat bedoel ik niet . Ik bedoel dat Docker container één (de nzbget container) een file aanmaakt en dat deze file eigenlijk vanuit de host niet te benaderen is (heeft ook user root, etc). Om dan de file "benaderbaar" te maken zit er eigenlijk niets anders op dan een andere container (samba ofzo) in de lucht te gooien en beide container te "linken".

Bedoel je niet toevallig het volgende? https://docs.docker.com/userguide/dockervolumes/ onder het kopje 'Mount a Host Directory as a Data Volume'

[smeerbartje]

Mounten kan, maar werkt primitief. Ik stuit hier vaak op techten-issues. Op de host worden files vanuit een container dan weggeachreven als root.

[Demo]

Misschien is LXC dan toch niet zo'n slechte keuze. Ik heb alles op mijn thuisserver inmiddels in containers ondergebracht, inclusief mijn router De wifi-interface wordt aan de namespace van het LXC-proces toegewezen en vervolgens in de container gebridged met de LAN-interface. Ipv de standaard Linux bridging gebruik ik OpenVswitch voor het onderlinge netwerkverkeer op de host. Storage wordt eveneens door een container geserveerd via NFS. Bij het aanmaken van een nieuwe container wordt Puppet geïnstalleerd, die zorgt grotendeels voor de verdere inrichting.

[EnnaN]

Bij docker zou ik dan de configuratie natuurlijk via de dockerfile kunnen provisionen. Het lijkt me nogal fijn om gewoon 1 ding te hebben + een config, en vanaf daar een nieuwe instantie te kunnen maken. Lekker overzichtelijk.

Vooral het backupen van een LXC moet ik nog even zien. Als dat makkelijk kan is dat natuurlijk fijn, maar die zit wel iets 'dieper' verweven met je huidige systeem, dus kun je niet zomaar bij een evt nieuwe verhuizing porten lijkt me?

Overigens hoef je natuurlijk niet voor 1 systeem te kiezen: een paar ingewikkelde dingen waarbij je echt "op een systeem" wilt werken kan je op LXC draaien, een paar dingen die makkelijk een dockerfile krijgen kunnen prima op docker draaien? Krijg je wel een wat gespleten systeem, maar otoh, ook kennis van beide?

[Hero of Time]

Kennis van beide is leuk, maar heb je er naast het hobbyen nog meer aan, zoals zakelijk? Houd ook rekening mee dat hoe complexer je het systeem maakt, hoe waarschijnlijker het is dat iets zomaar stuk gaat zonder dat je weet waarom en de oorzaak niet eens kan vinden, laat staan een oplossing. Je hebt genoeg opties om uit te voeren, maar blijf bij dit principe: KISS.

[EnnaN]

Helemaal mee eens! Maar in dit geval tikt het nog een beetje ook aan 'zakelijk'. Daar ga ik denk ik niet dingen door elkaar gebruiken, maar om een keuze te kunnen maken tussen welk systeem je gaat gebruiken als development omgeving bijvoorbeeld is het wel fijn om ze allemaal te kennen. Maar je hebt zeker gelijk bij KISS. Nu moet ik zeggen dat een LXC al vrij simpel is, dus dat is meer een goede manier om een frankensteinsysteem te voorkomen, en verder niet heel veel extra gedoe lijkt me.

Mijn eigen besluit is iig dat mijn basissyteem een Ubuntu 14.04 wordt waar ik zo weinig mogelijk userland onzin op wil hebben.

De eerste stap is, omdat daar al een mooi systeem voor is, een sabnzbd installatie. Dat kan heel mooi met docker. En mijn eigen vraag over de config is daarmee ook beantwoord: wat deze sabnzbd docker doet is een directory voor de downloads (nogal wiedes) maar ook 1 voor de config aanbieden. Zo heb ik nu dus een hele kleine "sabnzbd-docker" dir met de dockerfile, een start.sh en de config directory, vanwaar ik altijd een nieuwe variant kan starten. Erg chill. zie https://forums.sabnzbd.org/viewtopic.php?f=1&t=18039

Hetzelfde wil ik doen voor domoticz: er zweeft zelfs al ergens een dockerfile voor rond zag ik. Die is op debian gebaseerd, ik weet nog niet of ik liever ubuntu heb (nouja, dat weet ik wel, maar ik weet niet of het het waard is dat om te schrijven). Enige wat ik dan nog moet doen is de 'config dir extern' methode maken, en dan kan daar de db file staan.

Uiteindelijke doel is een kleine bak (repository? backup?) met dirs voor mijn server-apps die ik gebruik, waar dan wat dockerfiles en wat config dirs in staan.

Voor alle dingen waar ik het niet voor elkaar krijg of waar het niet handig voor is (bv een speel-test-dev omgeving) kan ik een LXC gebruiken.

[Hero of Time]

Hetzelfde wil ik doen voor domoticz: er zweeft zelfs al ergens een dockerfile voor rond zag ik. Die is op debian gebaseerd, ik weet nog niet of ik liever ubuntu heb (nouja, dat weet ik wel, maar ik weet niet of het het waard is dat om te schrijven).

Waarom zou je iets dat voor Debian is gemaakt moeten herschrijven voor Ubuntu? Ubuntu is als basis op Debian gebouwd, dus alles wat op Debian werkt, werkt net zo op Ubuntu. Dat maakt het zoeken naar een oplossing zoveel makkelijker en het vinden van software ook, evenals het uitwisselen van software. Je moet alleen niet lopen rommelen met systeemlibraries van beide distro's op 1 systeem.

[EnnaN]

Het maakt op dit moment niet zoveel uit, maar als ik wat aan die dockerfile moet klussen ben ik bekender met Ubuntu dan met Debian.

Het 'herschrijven' zal denk ik niet meer zijn dan het veranderen van "FROM debian" naar "FROM ubuntu", dus echt spannend is het niet. Als dat het enige is kan je ook discussieren waarom je het dan zou doen, geef ik toe, maar dat is dan ook meer een gevoel denk ik. Maar het is dus een beetje een non-point, mee eens.

[EnnaN]

Voor de geinteresseerden: dit heb ik er van gemaakt: https://github.com/NanneHuiges/domoticz-docker

Wat er nu gebeurd is dat je database die je mogelijkl hebt vanuit de context directory in je nieuwe docker container wordt gecopied. Een andere optie was geweest om deze in een mounted volume te zetten, en dan tijdens de build een symlink aan te maken bedacht ik me later.

De orginele file waar ik vanuit begonnen ben doet nog allemaal spannende dingen met de service (startupdifle veranderen met sed bv), om dan vervolgens te draaien als rechtstreeks command: dat leek me niet nodig dus dat heb ik weggelaten.

bottom line is dat je nu met die Dockerfile en een copy van je database (of alleen een database en een github account) op elke machine zo weer een draaiend systeem hebt.