Ik zie dat het docker concept een beetje nieuw is voor de meeste mensen.
Een vlugge vergelijking zodat het simpeler te begrijpen is:
* Je hebt full virtualisatie zoals VirtualBox etc ... hier draai je een compleet OS in een virtuele laag. Door dat het een full virtualisatie is, kan je zowat iedere OS draaien in deze container. Windows, MacOS, Linux bovenop je basis systeem. Het maakt niet uit wat je draait omdat je virtueel laag totaal gescheiden is van je host OS. Het nadeel is omdat alles virtueel draait, krijg je een grondig performance hit. Men heeft de virtualisatie de laatste jaren sneller gemaakt maar je zal nooit 100% dezelfde snelheid behalen als je host OS.
* Dan heb je semi virtualisatie zoals openvz ( en docker ). Deze virtualisatie draait eigenlijk puur op je host OS door middel van het kernel te gebruiken maar beperkt de applicaties door namespacing enz. Hierdoor kan je applicaties draaien in een "aparte" omgeving, zonder dat je massieve performance verliest hebt zoals bij full virtualisatie.
Het nadeel is dat je enkel applicaties kan draaien, dat gebruik maken van dat OS. Een Linux Host OS kan geen Windows draaien. Een windows Host OS can geen Linux draaien. Linux kan Linux draaien.
Het grote voordeel is dat je gans de isolatie, portabiliteit enz overneem van een full virtualisatie, maar dat je het cross-os mogelijkheid verliest ( wat gecompenseerd word door het feit dat je bijna puur dezelfde snelheid behoud als je host OS systeem ).
Het grote verschil tussen bijvoorbeeld OpenVZ en Docker is als volgend:
* In OpenVZ maak je een container aan, gebaseerd op een OS image. Bijvoorbeeld: Je draait op Debian, je wilt een Unbuntu VM aanmaken. Geen enkel probleem. Je download de image, je installeert het en je draait deze in een paar commando regels. Dan ga je in je container en je installeert je applicaties: PHP/MYSQL/Memcache/... whatever.
Je container is mobiel. Je kan het aanmaken in development en later releasen in een online productie server. Het nadeel is dat iedere container eigenlijk een eigen OS is. Je moet iedere container up to date houden. Enz ... Heb je 10 VM's staan met PHP, well ... have fun met ze allemaal te updaten. Wil je container 1 waar PHP 5.4 op staat uittesten met PHP 5.5, dan moet je ofwel een kopie maken, de nieuwe container upgraden. Testen. En later weeral de originele productie container upgraden enz ...
* Docker werkt een beetje anders. Je installeert nog altijd een image maar de installatie image is een volledige zelf contained applicatie. In tegenstelling tot bijvoorbeeld openvz, moet je image zo weinig mogelijk zaken bevatten omdat je niet in de container zit te installeren.
Docker heeft een registry waar je 100.000 images op vind.
https://registry.hub.docker.com/
Je wilt een project met PHP/Mysql/Memcache. Je zegt aan docker om PHP 5.4 te downloaden. Net zoals je doet met bijvoorbeeld met debian: apt-cache search PHP, kan je met docker zoeken naar welke images beschikbaar zijn. Wil je een specifieke image gebruiken, dan geef je gewoon in xxxx/PHP:versie. ( xxxx is de beheerder van die image ).
Stel je download de PHP 5.4 image. Je download de Mysql xx image. Je download de Memcache image. Je linkt de 3 images via het netwerk.
En nu ga je in je image rommelen door zaken te installeren in de bijvoorbeeld PHP 5.4 image...
NOT!!! Je blijft met je handen af van je image inhoud als het niet nodig is.
Nadat je je website opgezet hebt, de databank gelinkt, de memcache gelinkt heb je die 3 processen dat draaien. Wil je nog een website opzetten met PHP 5.4. Geen enkel probleem. Je kan een clone maken van de bestaande PHP 5.4 image. Een paar zaken aanpassen en voila. Nu hebben we 2 websites draaiende. Maar wat als we de Website 1 willen upgraden naar PHP 5.5? Ga je in de PHP5.4 image kruipen en die manueel upgraden. NEEEEEE!!!
Je download de PHP 5.5 image en je ontkoppeld de Website 1 van de PHP 5.4 image en koppelt deze met de PHP 5.5 image. Geen gedoe met upgrades. Geen gekloot met als er iets misloopt. Is er een probleem met je PHP script in je Website 1... geen probleem. Je kan direct teruggaan naar je 5.4 zonder een massieve downgrade or uren prutsen. Wat je vroeger uren kosten om containers te kopiëren, upgraden en herstellen bij problemen, kan je nu in minuten uitproberen, testen en teruggaan naar vorige versies.
Wil je je databank upgraden? Memcache? enz ...
Is er een nadeel? Ja ... je bent meer afhankelijk van de beheerder van de basis image, want zij beheren die image. Stel dat je PHP 5.4 van Jeff gedownload hebt ( Jeff/PHP5.4 ). Er zijn security patchen uitgekomen. Maar de Jeff is op vakantie of beheert de image niet meer.
Wat te doen?
* Je kan simpelweg een nieuwe image van de Dirk/PHP5.4 downloaden, welke wel de image up to date houd. En deze gebruiken als je basis PHP5.4 image.
* Je kan het beheer van de image overnemen, en je eigen private registry opzetten.
* Je kan revisies maken van images.
* Snapshot van de acties dat je uitvoerde.
* Je kan simpel een ubuntu image downloaden, commando uitvoeren en nooit meer terugkijken naar die image ( want je hebt twee image type: de default dat je één maal draait voor een commando uit te voeren of de demon type dat permanent draait ).
Nu we spreken over private registry... je kan je eigen images beheren in een prive registry. Stel dat je applicatie X maakt. Deze applicatie maakt gebruik van PHP/PostgreSQL/... Je maakt deze image aan, met de requirements linkt eraan. Je deploy de Applicatie X v1.0 op de productie server. Automatisch worden al de nodige andere images ook gedownload ( ze zijn gelinkt aan de master image ).
In development maak je Applicatie X 1.1. En X 1.2. En X 1.3 ( welke op PHP 5.5 draait ). Nu wil je X 1.3 op productie brengen. Je simpel upgrade de deployment op de server naar de latest versie.
Technische gezien krijg je een volledige GIT / deployment achtige toestand met versies, revisies maar dan met puur de images.
Docker hun image script is vrij simpel: De installatie script neemt een basis image ( bijvoorbeeld debian ), en je draait een hoop van de standaard debian commando's op dat image. Wil je gebruik maken van RedHat, dan neem je in je installatie script de basis image van RedHat, en je draait de standaard RedHat commando's daarop.
Docker zorgt voor de deployment, de registry, de standaardisatie commando's zodat de containers kunnen spreken met elkaar, enz enz ...
Ik hoop dat deze uitleg docker iets simpeler maakt. Het is verdoemt ingewikkeld omdat je een enorme oude gedachten gang van virtualisatie uit je kop moet halen. Veel mensen denken nog in container = installeer alles daarin. En volgende container installeer alles daarin. En volgende ... en je hebt een soep van containers, waar je uiteindelijk geen deftig idee meer hebt van wat draait wat.
Voor de mensen dat de werking willen begrijpen zonder dat je hooft gaat rondspinnen zoals in de Exorcist kan ik je de volgende uitleg enkel maar aanraden:
https://youtu.be/4W2YY-qBla0
Deze heer legt de commando's en werking in uitstekende detail uit. En maakt het simpeler om te begrijpen dat heel wat van de online tutorials. Ik hoop dat dit het iets simpeler maakt want het is een verdoemt ingewikkeld topic om uit te leggen. Zelf voor ervaren VM beheerders is de gedachten concept een grondig twist, laat staan voor mensen dat nog maar weinig ervaring hebben met VM's. Laat staat docker hun concept van applicatie beperkingen.
Tussen haakjes: Het plezant van docker is, dat mensen nu zelf grafische applicaties draaien in puur isolatie door middel van SSH en socket X11 forward.
Dit is eigenlijk wat de toekomst moet zijn. Alle applicaties in hun eigen container. Het zal virussen enz grondig inperken. En het houd je core OS veel properder ( geen gedwongen reformats omdat je windows verdubbeld is in grote met rommel dll's enz ).
Het Open Container Format zal gebaseerd zijn op het containerformaat dat Docker heeft ontwikkeld. Ook de runtime moet onderdeel gaan uitmaken van deze nieuwe specificatie. Daarvoor zal Docker de draft specification vrijgeven, waarbij leden van The Linux Foundation en bedrijven als Microsoft, Google en Amazon hebben aangegeven zich achter de verder te ontwikkelen standaard zullen scharen.
/i/1385568455.png?f=fpa)
/i/1355322651.png?f=fpa)
:strip_exif()/i/1345729991.gif?f=fpa)
:strip_exif()/i/1297428829.gif?f=fpa)
:strip_exif()/i/1296486229.gif?f=fpa)
/u/102837/Windows%25208%2520logo.png?f=community){kind=small}
:strip_exif()/u/56159/archer.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/266225/simonscat.jpeg?f=community){kind=small}
/u/146669/Ammy.png?f=community){kind=small}
:strip_icc():strip_exif()/u/295941/rsz_hur7v5.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/253641/crop686f9cec6f8b1_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/5698/klein.jpg?f=community){kind=small}
/u/113601/crop5e3f183d640f8_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community){kind=small}
:strip_exif()/u/26425/got1.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/408989/crop5613f0d80e7bb_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/281517/winn.jpg?f=community){kind=small}
/u/36103/avatar_60.png?f=community){kind=avatar}
:strip_exif()/u/69716/disgaea2_thief.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/6764/cergorach.jpg?f=community){kind=small}
/u/407403/WAhack.png?f=community){kind=small}
:strip_icc():strip_exif()/u/561203/Beedo-Minion.jpg?f=community){kind=small}