[Docker] ESXi naar Docker

[Antrax]

Al enige tijd draait er een ESXi omgeving in mijn server park thuis die laatst gemigreerd is naar 6.0. Helaas ben ik het een beetje zat aan het worden om voor elk wissenwasje een nieuwe OS te installeren (inmiddels al een aantal maanden een soort ovf klaar staan) maar het blijft veel werk,

Ik heb de laatste tijd veel gelezen over Docker en ik vroeg mij af of iemand ervaring heeft met Docker als de host OS. Dus i.p.v. ESXi alleen een boot2docker image draaien? Of is er een betere lichte OS die als docker host kan dienen?

Er draaien wat MySQL Databases, een webserver, plex en wat andere vms op ESXi die ook via een container zouden kunnen draaien.

Ik hoor graag jullie meningen.

[H!GHGuY]

Ik denk dat je sowieso iets fout doet.

Als je een ESXi omgeving hebt, hoef je maar 1 keer een guest te installeren. Daarna maak je voor elke nieuwe machine een clone van de basisinstall en installeer je daarin de toepassing die je wil.

Dat is bij Docker niet anders (behalve dat het om containers gaat en niet om virtualisatie). Je moet nog altijd een docker container opzetten met de nodig software en configuratie.
Eigenlijk is dat quasi evenveel werk, behalve dat het starten/stoppen sneller is.

Je kan ook eens naar CoreOS kijken (met rocket). Minimalistisch OS waarin het de bedoeling is alles als container te draaien.

[Hero of Time]

Docker klinkt leuk, maar laat je niet meeslepen in de hype. Dit is dan thuis, maar er zijn een hoop bedrijven die flink meer moeten betalen aan IT sinds ze alles naar de 'cloud' hebben gestuurd. En enige garantie van bereikbaarheid van zowel de cloud provider als je ISP heb je niet altijd, in house heb je daar meer controle over. Dit gaat ook op voor Docker images. Je hebt nu iets wat je snapt, volledig beheerst en als er iets is, kan je 't zo oplossen. Met docker images moet je eerst leren hoe het werkt, wat je met het netwerk moet doen (dit is ook een struikelpunt voor velen) en als er een issue is, zit je weer een lange tijd te rotzooien voordat het is opgelost.

Denk dus goed ga wat je op je hals haalt.

[H!GHGuY]

Als aanvulling: Docker is idd nog niet volwassen. Voor thuisgebruik doe je maar wat, natuurlijk.
Wat Docker networking betreft kijk je best eens naar pipeworks (https://github.com/jpetazzo/pipework).

Ik vind het ook een beetje vreemd dat iedereen die Docker images van het net zomaar vertrouwt, plus de Docker policy van zomaar om het even wat te downloaden als de naam maar klopt.

[himlims_]

lxc/puppet hanteren we hier

docker is opzich wel aardig, maar ik durf het niet aan om dat hier in productie te draaien. voor beetje hobbye enzo prima, maar serieuze omgeving ....

[CAPSLOCK2000]

Strict genomen is Docker niet je host OS. Dat blijft gewoon Linux. boot2docker start een lichtgewicht Linux en daarboven start je Docker-containers.
Ik heb er zelf geen ervaring mee. Mijn indruk is dat Docker toch nog wel enigzins pionieren is en je bij problemen nog steeds een hoop kennis nodig hebt. Als het installeren van het OS je grootste probleem is dan ben je misschien beter af met dat te optimaliseren/automatiseren/klonen zoals H!GHGuY en himlims_ al suggereren.

Maar misschien is het voor jou situatie wel een prima oplossing. Als ik jou was zou ik boot2docker eerst in een VM installeren en er een beetje mee experimenteren. Als dat bevalt kun je vmware vervangen. Ik ben benieuwd naar je ervaringen.

[himlims_]

docker heeft ondersteuning voor RHEL en centos de deur gewezen

https://github.com/docker/docker/issues/14365

[Antrax]

Bedankt voor alle reacties. Ik ga het eerst maar eens in een VM testen voordat ik het -misschien- volledig ga gebruiken.

[init6]

Hero of Time schreef op dinsdag 30 juni 2015 @ 20:26:
Docker klinkt leuk, maar laat je niet meeslepen in de hype. Dit is dan thuis, maar er zijn een hoop bedrijven die flink meer moeten betalen aan IT sinds ze alles naar de 'cloud' hebben gestuurd. En enige garantie van bereikbaarheid van zowel de cloud provider als je ISP heb je niet altijd, in house heb je daar meer controle over. Dit gaat ook op voor Docker images. Je hebt nu iets wat je snapt, volledig beheerst en als er iets is, kan je 't zo oplossen. Met docker images moet je eerst leren hoe het werkt, wat je met het netwerk moet doen (dit is ook een struikelpunt voor velen) en als er een issue is, zit je weer een lange tijd te rotzooien voordat het is opgelost.

Denk dus goed ga wat je op je hals haalt.

Wat is er mis met jezelf een beetje ontwikkelen en nieuwe dingen leren.

Docker is niets nieuws, het bouwt op container technieken welke reeds bestonden alleen dan met een lekkere api en wat tools. Eerst was er LXC welke gebruikt voornamelijk werd voor resource containment. Nu word het gebruikt om monolithische applicaties in stukken te hakken in microservices waardoor agile werkwijzes mogelijk worden. Er zijn op dit moment vele bedrijven welke docker/containers in productie gebruiken. Google draait alles, dus ook vm's van google compute of gmail, in containers.

[Hero of Time]

Er is niets mis met zelfontwikkeling, maar ik geef alleen de waarschuwing dat het veel complexer kan worden dan de TS voor ogen zou hebben. Op het werk hebben ze (een groepje ontwikkelaars) geprobeerd om Docker te gebruiken, maar dat is grandioos mislukt. Ik had zeer beperkte opties in de containers waardoor het debuggen van de netwerk issues die ze hadden zo goed als niet te doen was. De standaard optie om NAT te gebruiken is niet ideaal, binden op IP van de host wilden ze ook niet, omdat de software dan reageerde op de hostnaam van de docker machine, met z'n eigen problemen daarmee. Als laatst bridge gebruiken van LXC maar dat vereiste weer dat in het gehele VMware platform op de virtuele switches promiscuous mode aan moest staan. Er is een reden waarom dat standaard uit is.

Dus, het klinkt leuk maar je kan een onnodig complexe omgeving aan het bouwen zijn voor iets dat eigenlijk heel simpel moet zijn. Wil je het 'apart' draaien, dan kan je altijd nog naar chroot/jail kijken.

[FRidh]

Wellicht is Nix wat voor jou? Ik ben er een beetje mee aan het experimenteren en het is heel makkelijk om declaratief containers te specificeren.

Om wat preciezer te zijn, je kan 1 configuratie bestand maken met daarin de configuratie van je host systeem, en de containers. Vervolgens `nixos rebuild switch` en je systeem wordt gebouwd, inclusief containers en klaar. Updates? `nixos rebuild switch --update` en de host inclusief alle containers worden geupdate.
Ik denk dat je de containers wel kan vergelijken met de FreeBSD jails, hoewel ik daar zelf nooit mee heb gewerkt.
http://nixos.org/nixos/ma...ec-declarative-containers
Er is ook een pakket voor plex. Waarschuwing, het werkt allemaal wel even net anders dan andere distro's.

[init6]

Hero of Time schreef op zaterdag 04 juli 2015 @ 23:35:
Er is niets mis met zelfontwikkeling, maar ik geef alleen de waarschuwing dat het veel complexer kan worden dan de TS voor ogen zou hebben. Op het werk hebben ze (een groepje ontwikkelaars) geprobeerd om Docker te gebruiken, maar dat is grandioos mislukt. Ik had zeer beperkte opties in de containers waardoor het debuggen van de netwerk issues die ze hadden zo goed als niet te doen was.

Zelf een container starten en daarin de tools gooien welke je nodig hebt voor debuggen? Minimal distro installaties zijn vrij verkrijgbaar.

De standaard optie om NAT te gebruiken is niet ideaal

Puur uit interesse: Wat is jouw reden om NAT niet te gebruiken?

binden op IP van de host wilden ze ook niet, omdat de software dan reageerde op de hostnaam van de docker machine, met z'n eigen problemen daarmee. Als laatst bridge gebruiken van LXC maar dat vereiste weer dat in het gehele VMware platform op de virtuele switches promiscuous mode aan moest staan. Er is een reden waarom dat standaard uit is.

IPV6?
Gekeken naar port/socket binding of port binding dmv service discovery?

Dus, het klinkt leuk maar je kan een onnodig complexe omgeving aan het bouwen zijn voor iets dat eigenlijk heel simpel moet zijn. Wil je het 'apart' draaien, dan kan je altijd nog naar chroot/jail kijken.

Niet elk project is gebaat bij docker, net zoals niet elk project gebaat is bij altijd hetzelfde doen omdat het makkelijk is.

[Hero of Time]

Het ging op m'n werk om Jboss-Fuse. Die heeft bepaalde poorten en elke instance gebruikt dezelfde poorten, dus NAT is geen optie. IP binding ook niet, want wat ze in Fuse gebruiken werkte weer met hostnamen en het gaat een beetje lastig om een cluster op te bouwen van 3x dezelfde hostnaam.

Simpel gezegd, ze wilden Docker gebruiken om development wat simpeler en sneller te maken zonder extra machines te hoeven inzetten. Maar de tijd was te beperkt om hier echt mee aan de slag te gaan.

[Anoniem: 464235]

Waarom niet gewoon je favoriete hypervisor met PXE kickstart installaties over het netwerk. Sind een paar weken ben ik hier aan begonnen en het scheelt me elke keer weer tijd.

[Bigs]

himlims_ schreef op donderdag 02 juli 2015 @ 23:59:
docker heeft ondersteuning voor RHEL en centos de deur gewezen

https://github.com/docker/docker/issues/14365

Dat is wel typerend voor de community waar Docker uit voorkomt, alles bleeding edge en niet denken aan de lange termijn. Het gaat dan wel alleen om CentOS 6 maar dat is de komende jaren nog gewoon een gangbaar OS.

Nee ik hou het lekker bij vSphere, als de TS zich wat meer verdiept in de best practices werkt dat voor zijn doel net zo makkelijk als Docker. Docker is vooral gericht op applicatieontwikkelaars die helemaal wild zijn van microservices en andere inefficiënte abstracties en mensen die honderden machines in een willekeurige cloud willen uitrollen.

[Hero of Time]

Anoniem: 464235 schreef op dinsdag 07 juli 2015 @ 09:48:
Waarom niet gewoon je favoriete hypervisor met PXE kickstart installaties over het netwerk. Sind een paar weken ben ik hier aan begonnen en het scheelt me elke keer weer tijd.

Dat is ook wat er eerst werd gedaan, maar omdat het aanmaken van een VM meer tijd kost dan een docker image en de resources op het VMWare platform beperkt, was het een logisch alternatief. Als het werkte. En we gebruikten RH Satellite waar beperkte hoeveelheid machines mee te beheren was. Dat limiet was al snel bereikt.

[CAPSLOCK2000]

Docker heeft zeker z'n plek maar je moet het wel goed doen. Het beeld wordt een beetje verpest door developers die het gebruiken om geen systeembeheer te hoeven doen en zich te isoleren van de realiteit en hun omgeving te bevriezen en nooit updates te doen. Dat proef ik ook een beetje in deze thread, de "het werkt toch, wat zeur je nou"-mentaliteit.
Daarmee wil ik niet zeggen dat Docker alleen maar verkeerd gebruikt wordt. In een OTAP straat kan het heel prettig zijn maar je moet het wel blijven beheren. Een halfzachte implementatie zal alleen maar meer werk opleveren in plaats van minder maar de last wordt van development verschoven naar operations.

[Anoniem: 464235]

Hero of Time schreef op dinsdag 07 juli 2015 @ 11:36:
[...]

Dat is ook wat er eerst werd gedaan, maar omdat het aanmaken van een VM meer tijd kost dan een docker image en de resources op het VMWare platform beperkt, was het een logisch alternatief. Als het werkte. En we gebruikten RH Satellite waar beperkte hoeveelheid machines mee te beheren was. Dat limiet was al snel bereikt.

Dat klopt, aan de andere kant; kun je de tijd die het kost om een gautomagiseerde installatie te laten lopen echt tot 'het kosten van tijd' rekenen? Ik schiet een installatie in en 10 min. later is dat ding klaar incl. ssh keys om ansible een profiel over de machine te laten leggen.

Als je echter direct een machine nodig hebt en elke minuut telt lijkt de tijdswinst me gegrond. Ook valt het me op dat docker als vervanging gezien word van virtualisatie. Ik kijk vooralsnog de kat uit de boom

[Hero of Time]

Hmmja, hier is het nogal amateuristisch opgebouwd, dus een machine is niet in 10 minuten klaar. Daarnaast moet de machine nog bij Puppet aangemeld worden (certificaat signen) en dan komt de rest pas.

[ppl]

Als ik zo naar de vraagstelling kijk dan is het handig om eerst even te kijken naar hoe men nu alles installeert en vervolgens verder kijkt naar de automatiseringsmogelijkheden. Denk dan aan het uitrollen van images/unattended installations via PXE voor een basis installatie en configuratie via puppet om er een specifieke server van te maken. Met het nodige aan scripting werk kun je dit proces ook redelijk automatiseren. Als je dit thuis doet en je hebt maar 1 ESXi server dan kun je het nodige zelfs via de commandline doen (het zou direct via de shell of via de API).

Mocht je iets willen a la Docker wat wel heel goed supported en volwassen is en waarvan er inmiddels ook diverse productieomgevingen zijn waarbij het gebruikt wordt dan zit je al snel aan containers in Solaris en jails in FreeBSD.

himlims_ schreef op donderdag 02 juli 2015 @ 23:59:
docker heeft ondersteuning voor RHEL en centos de deur gewezen

https://github.com/docker/docker/issues/14365

Jij hebt versienummers de deur gewezen zo te zien:

RedHat themselves only support Docker on RHEL7 (as stated by https://access.redhat.com/solutions/1378023, and confirmed by several people)

Cruciaal stukje informatie...en een nog crucialer stuk informatie staat verderop, dat is een post die beschrijft waarom RHEL6/CentOS6 een probleem vormen (te weten de kernel).

[ Voor 27% gewijzigd door ppl op 09-07-2015 20:43 ]