Doc­ker-con­tai­ners voor ho­me- en web­ser­vers

Doc­ker-con­tai­ners voor thuis- en web­ser­vers

C’t Magazine - - Inhoud - Door Pe­ter Sie­ring

Con­tai­ners zijn zo cool dat Mi­cro­soft ze in Win­dows on­der­steunt en via zijn cloud aan­biedt. Ze zijn een uit­komst voor ont­wik­ke­laars en cloud-ex­ploi­tan­ten, maar heb je ook voor­de­len van de­ze tech­niek als je een ho­me- of web­ser­ver hebt? Een doe-het-zelf-ex­pe­ri­ment ...

Dank­zij vir­tu­a­li­sa­tie kun je meer­de­re be­stu­rings­sys­te­men en ser­vers op één root­ser­ver hos­ten. Met pro­gram­ma's zo­als VMwa­re, User Mo­de Li­nux, Xen, KVM en Hy­per-V maak je vir­tu­e­le ma­chi­nes waar­op je bij­voor­beeld de fire­wall van je thuis­net­werk, een web­ser­ver of een ftp-ser­ver laat draai­en. Wan­neer je al met BSDJails, OpenVZ of in chroot-en­vi­ron­ments werkt, ben je al be­kend met het con­cept van con­tai­ners. In dit ar­ti­kel ge­ven we prak­tijk­voor­beel­den van Doc­ker en zijn con­tai­ners.

Zo­dra je meer over Doc­ker wilt we­ten, kom je al­ler­lei vak­jar­gon te­gen met ter­men als lay­ers, roll­back, or­ches­tra­ti­on en de­ploy, die voor­al voor toe­pas­sin­gen in het groot gel­den. Maar wan­neer je prak­tijk- en de­tail­voor­beel­den zoekt die je hel­pen met het op klei­ne schaal op­zet­ten van een ho­me- of een web­ser­ver, moet je de in­for­ma­tie bij­een­schra­pen en over­al van­daan ha­len. Daar­om pro­be­ren we in dit ar­ti­kel een even­wicht te vin­den tus­sen een prak­ti­sche in­lei­ding en een be­grij­pe­lij­ke uit­leg. Dit is niet meer dan een ken­nis­ma­king met Doc­ker. Als je Doc­ker pro­duc­tief wilt ge­brui­ken, ont­kom je er op den duur niet aan on­li­ne ex­tra in­for­ma­tie te le­zen.

Als ba­sis voor de eer­ste stap­pen met Doc­ker ge­brui­ken we een root­ser­ver waar­op meer­de­re vir­tu­e­le Apa­che-ma­chi­nes voor on­der an­de­re een blog, Own­cloud, Git met we­bin­ter­fa­ce en een ftp-ser­ver voor het la­den van web­con­tent staan. Al die sys­te­men heb­ben een SSL-cer­ti­fi­caat van Let's En­crypt.

Wan­neer je vol­gens goed Doc­ker-ge­bruik één ser­vi­ce per con­tai­ner aan­houdt, za­del je je­zelf op met ex­tra werk. Want waar vroe­ger een Vir­tu­alHost-be­stand en een paar muis­klik­ken vol­doen­de wa­ren voor de cer­ti­fi­ca­ten, moet je nu meer­de­re con­tai­ners on­der­hou­den. Maar wat je aan de ene kant aan ex­tra werk en tijd in­ves­teert, win je dank­zij kant-en-kla­re con­tai­ners weer te­rug. Op Doc­ker Hub staan na­me­lijk con­tai­ners met blogsoft­wa­re, met Git­web, Own­cloud en zelfs ftp-ser­vers. Je hoeft geen tar-be­stan­den uit te pak­ken, geen rech­ten in te stel­len of een in­stal­la­tie­hand­lei­ding van de ont­wik­ke­laar te le­zen. Om­dat de main­tai­ners van de ima­ges dat al al­le­maal voor je heb­ben ge­daan, kom je als

het wa­re in een ge­spreid bed. Bo­ven­dien is de daad­wer­ke­lij­ke ap­pli­ca­tie in de ima­ge meest­al mo­der­ner dan de ver­sie die een dis­tri­bu­tie als pak­ket zou heb­ben.

In wer­king zet­ten

Voor­dat je met ima­ges aan de slag kunt, moet je de Doc­ker-om­ge­ving eerst in­stal­le­ren en star­ten. Dat kan op meer­de­re ma­nie­ren, bij­voor­beeld met in­stal­la­tie­pak­ket­ten voor Win­dows of macOS. In dit ar­ti­kel leg­gen we het uit aan de hand van een Li­nux-sys­teem met De­bi­an 9 (Stretch). Om­dat Doc­ker geen bij­zon­de­re ei­sen aan de pro­ces­sor stelt, mag de dis­tri­bu­tie ook in een vir­tu­e­le ma­chi­ne of op een vir­tu­e­le ser­ver draai­en.

Voeg de vol­gen­de re­gel aan de pack­a­ge-re­po­si­to­ry's in /etc/apt/sour­ces.list toe:

deb https://down­load.doc­ker.com/li­nux/— de­bi­an stretch sta­ble

In­stal­leer daar­na de on­der­steu­ning voor HTTPS-ver­bin­din­gen in de pack­a­ge-ma­na­ger, down­load de open­ba­re PGP-sleu­tel en voeg die toe aan de lijst van ver­trouw­de sleu­tels en in­stal­leer Doc­ker tot slot.

apt-get in­stall apt-trans­port-https apt-get in­stall curl curl -fsSL https://down­load.doc­ker.com/—

li­nux/de­bi­an/gpg | apt-key add - apt-get up­da­te apt-get in­stall doc­ker-ce

Met het vol­gen­de com­man­do kom je er­ach­ter of Doc­ker werkt:

doc­ker run hel­lo-world

Daar­mee start je een mi­ni­ma­le con­tai­ner die de tekst 'Hel­lo from Doc­ker!' met wat aan­vul­len­de in­for­ma­tie op het scherm toont. Voor­dat Doc­ker start, down­lo­adt die de ima­ge 'hel­lo-world' van de Doc­ker Hub, waar dan een con­tai­ner van ge­maakt wordt. Je kunt ima­ges dus als een tem­pla­te be­schou­wen en con­tai­ners als in­stan­tie. Doc­ker geeft el­ke con­tai­ner die het van een ima­ge maakt een kunst­ma­ti­ge naam. Wel­ke dat is, zie je in de laat­ste ko­lom van de ta­bel als je het com­man­do doc­ker ps -a uit­voert, bij­voor­beeld 'zen_k­hor­a­na'. Dat com­man­do toont al­le be­staan­de con­tai­ners. Wan­neer je de op­tie '-a' weg­laat, wor­den al­leen de ac­tie­ve con­tai­ners ge­toond.

Ori­ën­ta­tie

Met doc­ker ima­ge ls of doc­ker ima­ges krijg je een over­zicht van al­le ima­ges die je bin­nen­ge­haald hebt. In de laat­ste ko­lom 'VIR­TU­AL SIZES' zie je hoe­veel schijf­ruim­te el­ke ima­ge lo­kaal in­neemt. De ima­ge van het zo­juist ge­star­te hel­lo-world is slechts twee ki­lo­by­te groot en be­vat al­leen een ELF-pro­gram­ma dat de tekst weer­geeft. In een ima­ge kan meer staan, maar dat hoeft ze­ker geen vol­le­di­ge Li­nux run­ti­me-om­ge­ving te zijn. Voor het pro­gram­ma 'hel­lo­world' zijn de ker­ne­lin­ter­fa­ces ge­noeg.

Er zijn meer­de­re mo­ge­lijk­he­den om uit te vin­den wat er in een ima­ge zit. Je kunt hem met doc­ker ima­ge sa­ve > /tmp/ hel­lo.tar als TAR-be­stand op­slaan, waar­van je de in­houd – we­der­om TAR-be­stan­den – als een ui met la­gen kunt uit­pak­ken. Je kunt ook op de naam van een ima­ge goog­e­len. Als je naar 'li­bra­ry/hel­lo-world' zoekt, staan op de eer­ste pa­gi­na met re­sul­ta­ten al de be­lang­rij­ke do­mei­nen hub. doc­ker.com en github.com (aan­ge­vuld met de pre­fix 'doc­ker-li­bra­ry').

De web­si­te van Doc­ker Hub (https:// hub.doc­ker.com/_/hel­lo-world) be­schrijft de ima­ge die je met de doc­ker-run-op­dracht hebt op­ge­haald. Bij der­ge­lij­ke be­schrij­vin­gen staan meest­al aan­wij­zin­gen voor het ge­bruik van de ima­ge, zo­als het in­stel­len van een wacht­woord voor de ser­vi­ces die in de ima­ge aan­ge­bo­den wor­den. Ver­der staat er op de Doc­ker Hub-si­te van een ima­ge meest­al nog een ver­wij­zing naar het pro­ject­plat­form GitHub, waar je de build-in­struc­ties, een bug­trac­ker en meer in­for­ma­tie vindt. Vaak heb je die ge­de­tail­leer­de in­for­ma­tie la­ter no­dig. Of­fi­ci­ë­le ima­ges heb­ben 'li­bra­ry' of 'doc­ker-li­bra­ry' als pre­fix voor hun naam. 'Of­fi­ci­eel' be­te­kent in de­ze con­text niet dat de ima­ges van Doc­ker zelf ko­men, maar al­leen dat het team ge­spon­sord wordt dat de ima­ges naar de Doc­ker Hub uplo­adt. Het team moet aan de hand van goe­de voor­beel­den to­nen wat de best­prac­ti­ces bij het bou­wen van ima­ges zijn, de ima­ges goed do­cu­men­te­ren en even­tu­e­le vei­lig­heid­sup­da­tes snel in de ima­ges ver­wer­ken. Maar ga­ran­ties zijn er niet.

De Doc­ker Hub biedt een spe­ci­a­le ser­vi­ce voor ge­re­gi­streer­de ge­brui­kers. Voor die gra­tis re­gi­stra­tie is al­leen een e-mail­adres no­dig en we ra­den dat ook echt aan. De ser­vi­ce con­tro­leert re­gel­ma­tig of de 'of­fi­ci­ë­le' ima­ges be­ken­de vei­lig­heids­lek­ken heb­ben. Al­leen teams en ont­wik­ke­laars die voor hun ei­gen re­po­si­to­ry op Doc­ker Hub be­ta­len, kun­nen die ser­vi­ce in­ko­pen. Dat geeft de ge­brui­ker toch meer ver­trou­wen in hun ima­ges.

Nog een laat­ste op­mer­king over de bouw­plan­nen op GitHub: daar­in kun je zien hoe de ima­ge ge­maakt is. Het voor het ma­ken van een ima­ge cen­tra­le be­stand Doc­ker­fi­le be­schrijft niet al­leen hoe de ima­ge in el­kaar ge­zet is, maar ook wel­ke ex­ter­ne bron­nen er­voor no­dig zijn. Die in­for­ma­tie is niet, of slechts met heel veel moei­te, uit een vol­tooi­de ima­ge te her­lei­den. Naast de in­for­ma­tie uit Doc­ker­fi­le en de ove­ri­ge do­cu­men­ta­tie is de bug­trac­ker een gro­te bron van ken­nis. Daar­in wor­den

veel­ge­stel­de vra­gen en pro­ble­men be­ant­woord en op­ge­lost.

Eer­ste ser­vi­ce

Het com­man­do doc­ker se­arch git­web op de com­mand­line is vol­doen­de om op Doc­ker Hub naar de een­vou­di­ge web­ser­ver Git­web te zoe­ken waar­mee je met een web­brow­ser in Git-re­po­si­to­ry's kunt bla­de­ren. Die zoek­op­dracht le­vert min­stens ze­ven­tien re­sul­ta­ten op, maar geen en­ke­le daar­van is een 'of­fi­ci­ë­le' ima­ge. Het over­zicht heeft drie hulp­vol­le ko­lom­men. Stars geeft aan hoe an­de­re ge­brui­kers een ima­ge be­oor­de­len. Als er OK in Of­fi­ci­al staat, gaat het om een 'of­fi­ci­ë­le' ima­ge en Au­to­ma­ted geeft aan of een ima­ge au­to­ma­tisch op­nieuw ge­maakt wordt wan­neer de main­tai­ner hem up­da­tet.

Op Doc­ker Hub zie je hoe vaak een be­paal­de ima­ge ge­bruikt werd (Pulls). Als je het over­zicht nauw­keu­rig be­kijkt, kom je ima­ges te­gen waar­van de GitHub-pa­gi­na's niet meer be­staan of waar­van de in­houd al ja­ren niet bij­ge­werkt is. Om­dat je die bij voor­keur níet moet ge­brui­ken, houd je een lijst­je over van fa­vo­rie­te ima­ges die je kunt uit­pro­be­ren. Want zo snel je ze aan het draai­en krijgt, zo snel kom je er ook weer van­af.

We kie­zen de mi­ni­ma­le aan­pak en ge­brui­ken 'fraous­tin/git­web'. Met doc­ker pull fraous­tin/git­web down­load je de ima­ge. Met doc­ker run -d --na­me git­web fraous­tin/git­web maak en start je daar een con­tai­ner van die je de naam 'git­web' geeft. De web­ser­ver in die con­tai­ner werkt stan­daard met de poor­ten 80 en 443 voor een web­brow­ser of Git-client.

Voor­dat je een ver­bin­ding met de web­ser­ver kunt ma­ken, moet je eerst een ge­brui­kers­ac­count en een re­po­si­to­ry ma­ken. Daar heeft de main­tai­ner van de ima­ge een­vou­di­ge scripts voor ge­schre­ven die je met Doc­ker aan­roept. Met

doc­ker exec git­web addauth test test_ww

maak je de ge­brui­ker 'test' met het wacht­woord 'test_ww' aan en met

doc­ker exec git­web ad­drepos test

maak je een re­po­si­to­ry met de naam 'test'. Om er­ach­ter te ko­men hoe je de web­ser­ver in de con­tai­ner kunt be­rei­ken, ge­bruik je het com­man­do doc­ker in­spect git­web | more, dat de con­fi­gu­ra­tie van de con­tai­ner ge­de­tail­leerd weer­geeft. Bij­na aan het eind van dat over­zicht staan bij Net­work de net­werk­ge­ge­vens in­clu­sief het ip-adres dat doc­ker aan de con­tai­ner ge­ge­ven heeft.

Zon­der ver­de­re tus­sen­komst geeft Doc­ker pri­va­te ip-adres­sen aan al­le ge­star­te con­tai­ners en kop­pelt hij ze aan de brid­ge 'doc­ker0' die tij­dens het star­ten van de Doc­ker-dae­mon in­ge­richt werd. De Doc­ker-host waar­op de Doc­ker-dea­mon draait, krijgt meest­al het eer­ste ip-adres van het net­werk, bij­voor­beeld 172.17.0.1. De eer­ste con­tai­ner krijgt dan 172.17.0.2. Je kunt dat adres di­rect in een web­brow­ser op de host in­ty­pen, als die een gra­fi­sche ge­brui­kers­in­ter­fa­ce heeft. Heb je geen gra­fi­sche in­ter­fa­ce no­dig, dan maak je een SSH-ver­bin­ding via een SOCKSproxy (zie het ka­der 'Brug­gen bou­wen met SSH en SOCKS-proxy' hier­naast).

Weg­werp­maat­schap­pij

In­dien de ser­vi­ces van bui­ten het host­sys­teem toe­gan­ke­lijk moe­ten zijn, moet je de in­struc­ties daar­voor al bij het ma­ken van de con­tai­ner mee­ge­ven. Je kunt de in­stel­lin­gen daar­voor niet ach­ter­af bij een draai­en­de con­tai­ner uit­voe­ren om­dat dat te­gen de ba­sis­prin­ci­pes van con­tai­ners in­druist. Con­tai­ners zijn in prin­ci­pe zon­der waar­de. Gooi de Git­web-con­tai­ner weg en start hem op­nieuw met

doc­ker rm -f git­web doc­ker run -d --na­me git­web fraous­tin/git­web

Als je met de brow­ser dan weer ver­bin­ding met de web­ser­ver maakt, leer je een be­lang­rij­ke les: het lijkt als­of Git­web de con­fi­gu­ra­tie­be­stan­den ver­ge­ten is, want de ge­brui­ker en de re­po­si­to­ry zijn weg. Dat is geen fout, maar juist de be­doe­ling. Je moet vóór het star­ten van een con­tai­ner na­me­lijk aan­ge­ven wel­ke ge­ge­vens hij per­ma­nent moet op­slaan en Doc­ker dan la­ten we­ten wáár die da­ta op­ge­sla­gen moe­ten wor­den.

Doe je dat niet, dan maakt de Doc­ker-dae­mon tij­dens de eer­ste start au­to­ma­tisch één of meer­de­re vo­lu­mes voor der­ge­lij­ke da­ta aan en geeft die dan een naam die uit wil­le­keu­ri­ge te­kens be­staat. Zo­lang de con­tai­ner niet ver­wij­derd wordt, blijft die de vo­lu­mes ook na een her­start ge­brui­ken. Door het ver­wij­de­ren van de con­tai­ner wordt de kop­pe­ling ver­bro­ken, met als re­sul­taat dat een nieu­we con­tai­ner van de­zelf­de ima­ge een vers vo­lu­me be­vat. Met doc­ker in­spect git­web kom je erach-

ter waar de vo­lu­mes van een con­tai­ner zich be­vin­den. Bij een stan­daard­in­stal­la­tie staan on­der Mount en Sour­ce in de map /var/lib/doc­ker/vo­lu­mes één of meer­de­re sub­map­pen die ein­di­gen op '_da­ta'. Met doc­ker vo­lu­me ls --fil­ter dang­ling=true zie je de over­bo­dig ge­wor­den vo­lu­mes en met doc­ker vo­lu­me pru­ne ver­wij­der je ze.

Om er al voor het star­ten van een con­tai­ner ach­ter te ko­men waar de ge­ge­vens staan die per­ma­nent op­ge­sla­gen moe­ten wor­den, voer je doc­ker in­spect fraous­tin/ git­web uit. Dus niet voor de con­tai­ner, maar voor de ima­ge. Zoek dan naar Vo­lu­mes. In dit voor­beeld zul je zien dat het '/var/lib/ git' is. Als je dat weet, start je Git­web met een vo­lu­me dat je zelf een naam geeft:

doc­ker run -d --na­me git­web -v git­we­brepos:/var/lib/git fraous­tin/git­web

Doc­ker maakt dan au­to­ma­tisch een vo­lu­me met de naam git­we­brepos aan door op de host de map var/lib/doc­ker/git­we­brepos te cre­ë­ren.

In dit voor­beeld is dat nog steeds niet vol­doen­de voor de ima­ge fraous­tin/git­web om de toe­gangs­ge­ge­vens te her­stel­len die je via doc­ker exec git­web addauth had aan­ge­maakt. Die staan in het be­stand /etc/nginx/.ht­passwd, dat de ma­ker van de ima­ge he­laas niet op de juis­te wij­ze ge­de­cla­reerd heeft. Als je de op­los­sing daar­voor wilt we­ten, moet je de bron­nen be­stu­de­ren en din­gen uit­pro­be­ren. Dan kom je er­ach­ter dat je het pro­bleem met dit con­fi­gu­ra­tie­be­stand een­vou­dig op­lost door het be­stand al voor het aan­ma­ken van de con­tai­ner te ma­ken:

mk­dir -p /usr/lo­cal/sha­re/doc­ker;touch /usr/lo­cal/sha­re/doc­ker/.git­we­b_—

ht­passwd

Bij het star­ten voeg je het be­stand als op­tie toe. Het ge­he­le com­man­do is dan:

doc­ker run -d --na­me git­web -v git­we­brepos:/var/lib/git -v /usr/lo­cal/sha­re/doc­ker/—

.git­we­b_ht­passwd:/etc/nginx/.ht­passwd fraous­tin/git­web

Wan­neer je de Git­web-con­tai­ners al­tijd met die op­ties aan­maakt, gaan er geen ge­ge­vens ver­lo­ren.

Com­mu­ni­ce­ren met de we­reld

Met die ba­sis­ken­nis kun je an­de­re ima­ges draai­en. We ra­den je aan zo lang met dok­ker run en doc­ker rm te oe­fe­nen tot je ze­ker weet dat je daar­bij geen ge­ge­vens ver­liest. Het ver­schilt per con­tai­ner hoe je ze con­fi­gu­reert. Be­hal­ve de werk­wij­ze met scripts in Git­web wor­den de ge­ge­vens ook vaak als om­ge­vings­va­ri­a­be­len mee­ge­ge­ven. We­bap­pli­ca­ties ver­za­me­len hun ge­ge­vens meest­al via con­fi­gu­ra­tie­pa­gi­na's die ver­schij­nen wan­neer je de ap­pli­ca­tie voor de eer­ste keer in een brow­ser opent.

Als je een shell-ses­sie in een draai­en­de con­tai­ner wilt star­ten, kan dat met doc­ker exec -it git­web /bin/sh. Daar­na kun je de con­tai­ner van­af de com­mand­line on­der­zoe­ken en con­fi­gu­re­ren. Ont­houd dat even­tu­e­le wij­zi­gin­gen al­leen per­ma­nent zijn bij be­stan­den die bui­ten de draai­en­de con­tai­ner op­ge­sla­gen wor­den, dus op vo­lu­mes of in een ex­ter­ne da­ta­ba­se. Met het com­man­do doc­ker com­mit veran­der je een con­tai­ner weer in een ima­ge, maar die moet je niet te vaak ge­brui­ken. Daar­mee maak je al­leen ima­ges zon­der bouw­plan (Doc­ker­fi­le) die moei­lijk te on­der­hou­den zijn.

Zon­der ver­de­re con­fi­gu­ra­tie blij­ven de ser­vi­ces van de con­tai­ner al­leen toe­gan­ke­lijk van­af het host­sys­teem. Dat komt door­dat Doc­ker el­ke con­tai­ner in een pri­va­te net­werk zet, wat ver­ge­lijk­baar is met de si­tu­a­tie van een thuis­net­werk ach­ter een rou­ter die ver­bin­ding met in­ter­net maakt. Er is geen port­for­war­ding die het ver­keer naar een poort van de host door­stuurt naar een pro­ces in de con­tai­ner. Doc­ker kan zo'n port­for­war­ding in­rich­ten als je dat tij­dens het star­ten van de con­tai­ner aan­geeft. De ex­tra pa­ra­me­ter die je daar­voor no­dig hebt is bij­voor­beeld -p 8001:80. Die ver­bindt poort 80 van de Git­web-web­ser­ver met poort 8001 van de host.

Voor web­ser­vi­ces zou dat snel een on­werk­ba­re si­tu­a­tie op­le­ve­ren, ze­ker als meer­de­re con­tai­ners als vir­tu­e­le hosts via één of­fi­ci­eel ip-adres op de stan­daard web­poor­ten 80 en 443 be­reik­baar moe­ten zijn. Dat pro­bleem los je op met de ima­ge jwil­der/nginx-proxy, die een voor­af ge­con­fi­gu­reer­de nginx-web­ser­ver als au­to­ma­ti­sche re­ver­se-proxy be­vat.

De re­ver­se-proxy­ser­ver luis­tert aan een spe­ci­a­le Unix-so­c­ket waar de Doc­ker zijn API aan­biedt (/var/run/doc­ker.so­ck). Om­dat je (hac­ker)aan­val­len op de host niet kunt uit­slui­ten, geef je al­leen be­trouw­ba­re con­tai­ners toe­gang tot die so­c­ket. Zo­dra je een nieu­we con­tai­ner start, krijgt de proxy dat via de so­c­ket te ho­ren. Wan­neer die con­tai­ner een spe­ci­fie­ke om­ge­vings­va­ri­a­be­le in de vorm van de pa­ra­me­ter -e VIRTUAL_HOST=git­web.example.com, heeft, maakt de proxy een bij­pas­send con­fi­gu­ra­tie­be­stand dat in de nginx-ser­ver ge­la­den wordt. Daar­door kun­nen ver­zoe­ken van de

Wan­neer je een ge­re­gi­streer­de ge­brui­ker bent, kun je bij Doc­ker Hub zien wel­ke vei­lig­heids­lek­ken 'of­fi­ci­ë­le' ima­ges heb­ben.

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.