Voordeel docker t.o.v. plain LXC?

[idef1x]

Ik ben me momenteel aan het verdiepen in LXC en docker en het ontgaat me een beetje waarom docker nu zo geweldig zou zijn.
Het klinkt leuk en aardig dat je een image van een applicatie in zijn omgeving kan maken en deze laten draaien, maar indien je het updaten ervan cq deployen van meerdere goed wil doen, dan dien je de configuraties en data buiten de docker container te zetten (dan wel op de host, of in een docker volume container). Dit maakt het toch alleen maar complexer, dan plain lxc te gebruiken? Daarmee kan je ook een bevroren applicatie in zijn omgeving maken (snapshot of copy)?

Ik zou mijn ubuntu VPS eigenlijk willen containeren vanwege portabiliteit naar eventueel een andere provider wanneer nodig (of thuis hosten), dus met een copy van de hele container(s) in een vergelijkbare omgeving (x86) zou dan geneog moeten zijn. Met LXC kan ik het met 1 container doen, maar als ik dit met docker wil, dan zou het beste zijn om mijn sql, owncloud, wordpress, postfix, dovecot, data etc allemaal in een aparte docker container moeten gooien en ze linken met elkaar, welke met elkaar moeten kunnen babbelen? Dit klinkt mij als veel complexer of mis ik het punt van docker nu?

[Demo]

Volgens mij is Docker niet zozeer interessant voor de thuisgebruiker die een machine wil containeren, maar vooral voor (cloud) service providers die on-demand een bepaalde service willen opschalen. Je trapt een nieuwe Docker aan, laat Puppet de provisioning doen en met een paar minuten ben je klaar.

[idef1x]

klopt, maar voor mijn thuis gebruik is het een leuke testcase (is microschalig) en wellicht heb ik er dan ook wat aan in de cloud wereld in de praktijk. Het is ook ter lering en de vermaak dus.

[CAPSLOCK2000]

LXC is alleen de container. Je gebruikt LXC typisch in gevallen waar je een soort virtuele machines wil hebben zonder de overhead van VMs. Iedere LXC-container bevat in principe een volledig systeem en wordt ook zo beheerd. De inhoud van zo'n container kan dus worden aangepast en geupdate.
Docker richt zich meer op statische applicaties. Je hebt geen complete omgeving maar precies genoeg om een bepaalde applicatie te draaien. Docker wordt vooral gebruikt om zeker te weten dat er niks verandert. Bijvoorbeeld zodat de productie-omgeving precies hetzelfde is als de testomgeving of dat alle productiemachines precies hetzelfde zijn.

Een docker image bouw je eenmalig en dan blijf er van af. Bij de volgende release van je software bouw je een nieuwe image. LXC behandel je als een normale VM waar je bv dagelijks updates laat installeren.

Alles hierboven is met grove pen geschreven. Als je wil kun je bv Docker-images bijwerken en en LXC-containers bevriezen maar dat is niet hoe het in praktijk gebruikt wordt.

Ik denk dat LXC het beste past bij wat jij wil maar ik vraag me af of het wel zin heeft. Als je alles in 1 container stopt heeft het niet zo veel zin. Ben je niet beter af met een klassieke backup?

PS. De goedkoopste VPSjes zijn vaak LXC-containers. Het zou dus kunnen dat jouw VPS al een LXC-container is.

[idef1x]

mijn VPS is een openVZ KVM machine. LXC werkt er in ieder geval op
De zin voor mij om met LXC aan de slag te gaan is 2-ledig: ten 1e om de VPS portable te maken, zodat ik alleen een copy /paste hoef te doen bij verplaatsen. Met de klassieke backup moet je maar weer afwachten of het in de nieuwe omgeving gelijk werkt of je moet hem opnieuw opbouwen en configuraties overzetten. Ten 2e ook voor er wat ervaring mee opdoen.

Zoals ik er nu tegenaan kijk OS LXC inderdaad meer voor de hand liggend.

Dank voor je toelichting

[ Voor 1% gewijzigd door idef1x op 06-04-2015 00:17 . Reden: Kennelijk is mijn VPS provider veranderd van type ]

[Blubber]

CAPSLOCK2000 schreef op vrijdag 03 april 2015 @ 14:07:
...

Een docker image bouw je eenmalig en dan blijf er van af. Bij de volgende release van je software bouw je een nieuwe image. LXC behandel je als een normale VM waar je bv dagelijks updates laat installeren.

Alles hierboven is met grove pen geschreven. Als je wil kun je bv Docker-images bijwerken en en LXC-containers bevriezen maar dat is niet hoe het in praktijk gebruikt wordt.

Wij gebruiken LXC op de manier zoals Docker het ook gebruikt. Als wij onze applicatie deployen bouwen we telkens een verse LXC container. Verder worden applicatie containers nooit geupdate. Het is veel makkelijker om gewoon een nieuwe te deployen, dan weet je zeker dat het werkt. Zeker met een onbetrouwbaar OS als Ubuntu zou ik mijn handen er niet aan branden om een draaiende container te updaten.

Het handige aan Docker is dat hij heel veel 'plumbing' voor je doet, zoals het injecteren van environment vars in de container, en het mounten van volumes in de container. Dit maakt gebruik van functionaliteit in LXC, maar als je dat allemaal met de hand moet doen is veel werk.

Het idee van Docker is dat je de container als applicatie beschouwt, dus om de container te deployen ga je niet met de config in de container zitten beunen, dat zou vergelijkbaar zijn met het aanpassen van de source code van een app om deze te configureren. In plaats daarvan gebruik je bijvoorbeeld environment variabelen of command line argumenten.

Een andere methode die er wel mooi uitziet is het Ambassador pattern. Daarbij draai je een soort doorgeefluik voor remote services op dezelfde host. Als je bijvoorbeeld een app hebt die Postgres nodig heeft, dan laat je die app altijd lokaal op bijvoorbeeld poort 1234 connecten. Je draait dan een tweede container, de ambassador, op dezelfde host die luistert op 1234 en via socat verkeer doorsluist naar de echte Postgres host. Dit is vergelijkbaar met dependency injection in OO. Dit maakt het ook mogelijk om heel makkelijk containers te testen in een CI omgeving, en daarna dezelfde container met dezelfde config te deployen in productie.

Anyway, dat gezegd hebbende, Docker is een mooie technologie, maar het kost veel tijd om het goed in gebruik te nemen. Ik denk dat dat voor een enkele VPS niet echt de tijd waard is. Als ik jouw was zou ik 'gewone' LXC containers gaan gebruiken. Je kunt altijd later nog Docker gaan gebruiken.

[FREAKJAM]

Ze zijn bij Ubuntu op dit moment ook bezig met de server variant, LXD. Ik weet niet wat hier in hoeverre al in mogelijk is, maar misschien zit er interessant leesvoer tussen.

[ Voor 13% gewijzigd door FREAKJAM op 07-04-2015 14:49 ]

[init6]

Voorheen was docker een schil om LXC heen, inmiddels hebben ze libcontainer geschreven sinds 0.8 en is lxc optioneel. Docker bied een handige interface om containers heen waarmee je snel kan zoeken, plaatsen en deployen zonder dat je je druk hoeft te maken over het plaatsen en draaien van die container op een andere locatie. Docker is een van de tools welke in dev omgevingen gebruikt worden voor continuous integration. Het helpt om snel te schakelen en om makkelijk te integreren in omgevingen.

Een voorbeeld van bijvoorbeeld een Elasticsearch docker file:

code:

#
# Elasticsearch Dockerfile
#
# https://github.com/dockerfile/elasticsearch
#

# Pull base image.
FROM dockerfile/java:oracle-java8

ENV ES_PKG_NAME elasticsearch-1.5.0

# Install Elasticsearch.
RUN \
  cd / && \
  wget https://download.elasticsearch.org/elasticsearch/elasticsearch/$ES_PKG_NAME.tar.gz && \
  tar xvzf $ES_PKG_NAME.tar.gz && \
  rm -f $ES_PKG_NAME.tar.gz && \
  mv /$ES_PKG_NAME /elasticsearch

# Define mountable directories.
VOLUME ["/data"]

# Mount elasticsearch.yml config
ADD config/elasticsearch.yml /elasticsearch/config/elasticsearch.yml

# Define working directory.
WORKDIR /data

# Define default command.
CMD ["/elasticsearch/bin/elasticsearch"]

# Expose ports.
#   - 9200: HTTP
#   - 9300: transport
EXPOSE 9200

Naast Docker zijn er alternatieven zoals Rocket, LXD en ik geloof dat Windows ook mee gaat doen met Drawbridge.

[idef1x]

Blubber schreef op dinsdag 07 april 2015 @ 12:17:
[...]

Het handige aan Docker is dat hij heel veel 'plumbing' voor je doet, zoals het injecteren van environment vars in de container, en het mounten van volumes in de container. Dit maakt gebruik van functionaliteit in LXC, maar als je dat allemaal met de hand moet doen is veel werk.

Die indruk kreeg ik inderdaad. Kwestie van containers linken (nfs, sql, etc) en je bent klaar. Je krijgt dan wel een lang commando om de container te starten als ik het goed las.

Het idee van Docker is dat je de container als applicatie beschouwt, dus om de container te deployen ga je niet met de config in de container zitten beunen, dat zou vergelijkbaar zijn met het aanpassen van de source code van een app om deze te configureren. In plaats daarvan gebruik je bijvoorbeeld environment variabelen of command line argumenten.

Je moet toch nog steeds de configuraties in de container zelf aanpassen? Je hebt bijvoorbeeld een webserver waarvan de html dir van de ene container verschilt met de andere. Je kan dat toch niet allemaal met environment vars doen? In wat voorbeeld containers op de docker hub zie ik dat men dan bijvoorbeeld de config/html dir mounten van een dir op de host, maar dat lijkt me dan ook niet helemaal de bedoeling?

Anyway, dat gezegd hebbende, Docker is een mooie technologie, maar het kost veel tijd om het goed in gebruik te nemen. Ik denk dat dat voor een enkele VPS niet echt de tijd waard is. Als ik jouw was zou ik 'gewone' LXC containers gaan gebruiken. Je kunt altijd later nog Docker gaan gebruiken.

Wie klein begint...
Dank voor je toelichting. De link over dat ambassador zal ik ook gaan lezen.

FREAKJAM schreef op dinsdag 07 april 2015 @ 14:48:
Ze zijn bij Ubuntu op dit moment ook bezig met de server variant, LXD. Ik weet niet wat hier in hoeverre al in mogelijk is, maar misschien zit er interessant leesvoer tussen.

Ik zag het ook staan op de linuxcontainers.org site, maar was pas in November 2014 geannounced en vind dat nog wat te nieuw, maar klinkt goed.

init6 schreef op dinsdag 07 april 2015 @ 19:53:
Naast Docker zijn er alternatieven zoals Rocket, LXD en ik geloof dat Windows ook mee gaat doen met Drawbridge.

Rocket kende ik ook nog niet..Zal het opzoeken. Docker kwam steeds in mijn zoek resultaten naar boven, dus wellicht dat alternatieven ondergesneeuwd raakten

[Blubber]

idef1x schreef op woensdag 08 april 2015 @ 14:36:
Je moet toch nog steeds de configuraties in de container zelf aanpassen? Je hebt bijvoorbeeld een webserver waarvan de html dir van de ene container verschilt met de andere. Je kan dat toch niet allemaal met environment vars doen? In wat voorbeeld containers op de docker hub zie ik dat men dan bijvoorbeeld de config/html dir mounten van een dir op de host, maar dat lijkt me dan ook niet helemaal de bedoeling?

Hangt van de situatie af. Je kunt inderdaad niet alles met ENV variabelen doen, maar je komt een heel eind. Zeker als je dat ambassador pattern gebruikt, dan kun je in veel gevallen dezelfde config gebruiken voor dev en prod.

De config en html dir mounten is een optie, je kunt daar een docker volume voor gebruiken. Als je dat doet ben je mijns inziens Docker aan het misbruiken. Idealiter bouw je in je CI omgeving een complete werkende, geconfigureerde container, die je dan kunt testen voor deployment. Zodat je test en prod container identiek zijn .Dat is de enige manier om zeker te weten dat alles goed werkt.

'Maar elke app is anders. En er zijn ongetwijfeld situaties waarin het handiger is om html en config te mounten via een Docker volume. Als dat voor jouw omgeving beter is dan zie ik niet in waarom je dat niet zou doen. Maar volgens mij is dat niet direct te bedoeling.

Ik zou dingen als HTML (dan heb ik het over templates) zeker in container bakken. Die wil je wellicht versionen, en het is wel zo handig om de container 'compleet' te hebben. Zo kun je makkelijk een rollback doen als je deployment faalt. Statische files zet je typisch op een of ander CDN, bijvoorbeeld Amazon S3. Maar dan heb je het direct over wat grotere deployments. Voor de huis-, tuin- en keukengebruiker zou ik zeggen, doe gewoon wat jouw uitkomt, en maak je niet te druk over wat men vind dat je zou moeten doen.

Rocket kende ik ook nog niet..Zal het opzoeken. Docker kwam steeds in mijn zoek resultaten naar boven, dus wellicht dat alternatieven ondergesneeuwd raakten

Docker is hip momenteel .