Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 65 reacties

Docker en CoreOS, twee bedrijven die elk een eigen koers leken te varen, gaan samen met onder andere The Linux Foundation, Google, Microsoft en Amazon werken aan het Open Container Project. Dit initiatief moet een opensource en breed gedragen software-containerformaat opleveren.

containersHet 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.

De uiteindelijke specificatie van het Open Container Format moet er voor zorgen dat dergelijke containers op alle platformen draaien, zoals op Docker, CoreOS en Kurma. Ook moet de standaard open worden ontwikkeld zonder dat een partij de koers kan bepalen. Daarvoor moet The Linux Foundation zorg gaan dragen.

Deelnemers aan het Open Container Project reageren verheugd op de aangekondigde samenwerking tussen de belangrijkste partijen in de virtualisatiemarkt. De directeur van CoreOS laat aan TechCrunch weten dat Docker weliswaar de facto de standaard is, maar dat er nog het nodige aan verbeterd kan worden door gezamenlijk aan de specificatie te sleutelen. Ook Docker zegt dat de stap tot het vrijgeven van de specificatie noodzakelijk was om de ontwikkeling van containers verder te versnellen, terwijl Google denkt dat met name softwareontwikkelaars op termijn zullen profiteren van het project.

Er ontstond eind vorig jaar onenigheid toen ontwikkelaars van CoreOS uit onvrede besloten om een eigen containerformaat te ontwikkelen, naast dat van Docker. Ook hadden zij een eigen runtime voor ogen. Hierdoor dreigde er versplintering in de ontwikkeling van opensource containertechnologie.

Moderatie-faq Wijzig weergave

Reacties (65)

En wat doen die containers? Iets meer uitleg in het artikel zou voor mij wel fijn zijn...

Edit: Ah dit is een goede omschrijving denk ik:
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.
In tegenstelling tot VMs heb je een extra laag minder (want je hebt geen guest operation system nodig): https://www.docker.com/whatisdocker
Containers include the application and all of its dependencies, but share the kernel with other containers. They run as an isolated process in userspace on the host operating system. They’re also not tied to any specific infrastructure – Docker containers run on any computer, on any infrastructure and in any cloud.

[Reactie gewijzigd door Luuk1983 op 23 juni 2015 10:56]

Het gaat om LXC (Linux containers).

Wat momenteel een bijv. een chaos is, is networking tussen verschillende containers daar willen ze o.a. afspraken over gaan maken om dit in de toekomst te verbeteren.
Het gaat NIET om LXC. Docker gebruikt geen LXC meer. Wat docker wel gebruikt is een eigen dingetje om cgroups heen. LXC gebruikt ook cgroups. Dat is de overeenkomst.

Daarnaast doet docker veel meer: container registry, netwerk managen etc etc etc etc etc etc. (expres zoveel etc... want docker doet (te) veel)

[Reactie gewijzigd door DeuTeRiuM op 23 juni 2015 12:17]

Klopt inderdaad, LXC is een heel ander systeem en niet voor applicatie isolatie, alhoewel het met een OS mogelijk is. Ik gebruik Docker vooral in combinatie met mijn OpenVZ containers. Zo kan ik alle applicaties (wordpress etc.) netjes scheiden per linux container. Dit kan natuurlijk ook op dedicated hardware.

--

Ben ook vooral benieuwd wat Microsoft hier precies mee gaat doen volgend jaar. SSH support komt eraan. Dit heeft vast te maken met Docker ;)

Docker is nog niet echt ready voor in productie omgevingen, het laat veel resten achter die niet goed op te schonen zijn. Hiervoor zijn verschillende linux oplossingen, maar een container opschonen is nog niet zo eenvoudig. Een simpele container als WordPress neemt al veel geheugen in gebruik.

Docker bouwt blokken/containers op je huidige OS en kan hiermee applicaties isoleren. Je kan hierdoor de blokken/containers aan elkaar koppelen en laten synchroniseren. Bijv. WordPress en MySQL. Hiervoor hoef je niets extra's te doen. Je kan een container aanmaken en weer weggooien of opnieuw uitrollen in een paar seconden.

Erg leuk spul, gaat ook een belangrijke rol spelen vanaf volgend jaar. Onmisbaar voor bedrijven die in de big-data bepaalde diensten willen aanbieden. Met docker is het in een paar seconden uitgerold. Opschoning en verbetering voor die tijd is hard nodig! Deze combinatie gaat goed werken!

Voor mensen/tweakers die ook erg enthousiast zijn:
http://www.ubuntu.com/cloud/tools/lxd
Ubuntu is ook erg druk met het onderliggende platform!

[Reactie gewijzigd door Tombastic op 23 juni 2015 17:49]

Microsoft heeft vorig jaar oktober al aangekondigd Docker te gaan ondersteunen in Windows Server. Nano Server wordt de Windows-equivalent van CoreOS, als ik het goed begrijp.

Waarom Docker 'nog niet echt ready voor in productie' omdat het 'veel resten achterlaat' snap ik niet. Met multi-line RUN instructies hoef je dat probleem ook helemaal niet te hebben?
Dit is een reactie waar ik geen informatie uit kan halen. Tuurlijk heeft MS dit officieel aangekondigd begin dit jaar. (ondersteuning voor Windows Nano)
http://azure.microsoft.co...he-next-generation-cloud/

Verder is dat een voorbeeld en een probleem van Docker wat in het algemeen voor iedereen een struikelblok is, zoek dit maar eens op. Dit probleem is er wel en zonder bepaalde commando's niet netjes op te schonen.
Bron: http://stackoverflow.com/...ove-old-docker-containers
https://github.com/docker/docker/issues/479

Er zijn natuurlijk alternatieven om het op te schonen, maar hier zit ik niet op te wachten. Zo zijn er nog een aantal kleine punten.

Maar goed, die kom je tegen als je het draait ;)

[Reactie gewijzigd door Tombastic op 23 juni 2015 21:51]

Ik bedoelde https://news.microsoft.com/2014/10/15/dockerpr/ - al was vanavond http://azure.microsoft.co...-platforms-and-win-hearts een concretere invulling van die plannen.

http://jasonwilder.com/bl.../squashing-docker-images/ al naar gekeken? Docker is inderdaad volop in ontwikkeling om dergelijke dingen glad te strijken, maar dan verschillen we kennelijk van mening of dat het productieklaar maakt.
Wat ik al zei, er zijn alternatieven zoals je nu aangeeft. Zo is er nog een berg met fouten die te verbeteren zijn. Dit moet in Docker zelf gewoon goed geregeld zijn.

Dat Microsoft hiermee verder wilt gaan klopt. Dat het in combinatie met Docker/Nano gaat, hadden ze pas 2 maanden terug aangegeven.
Heb gisteren de keynote gezien van de docker conference 2015 en is nog steeds beschikbaar op:

http://www.dockercon.com

Ik ben zeer enthousiast geraakt van de presentatie van Solomon Hykes (founder). Wat helemaal super is, is dat alle grote bedrijven die docker ondersteunen samenwerken

T 2:13:00
the most useful thing we've done at docker is not technology, it's getting people to agree on something
Bewijs, kijk hier eens: https://www.opencontainers.org/pressrelease

Dit wordt groot. Dit is groots. Echt super cool.
Dit doet mij denken aan de microkernel architectuur, maar dan mss met een modernere aanpak.
Dankjewel, want ik vermoedde al lichtelijk dat het niet om dingen als een mkv container ging. Echter dacht ik meer richting install packages zoals je die onder linux distro's hebt. Dat bleek het dus ook niet te zijn. Sterker nog, ik had nog nooit gehoord van dit soort containers.
Gezien de comments is de term containers voor veel tweakers nog nieuw :)
De link van Luuk1983 naar https://www.docker.com/whatisdocker is een goed startpunt.
Hierbij wat extra informatie:

Virtualisatie kent iedereen ws wel :) Containers is feitelijk een alias voor Operating System level virtualisation. OS-level virtualisation houdt in dat de zogeheten "containers" (de afscherming waarbinnen het proces/de processen draaien) van elkaar en de host gescheiden worden door zogeheten namespaces, een feature die door de kernel mogelijk wordt gemaakt.
Deze namespaces isoleren bijvoorbeeld de processen en networking van een container. Ook biedt dit de mogelijkheid resource-constraints (CPU, Mem, IO, etc) op te leggen.
Hier komt geen hardware virtualisatie inclusief de bijbehorende overhad aan te pas. OS-level virtualisatie is dus efficiënter met je resources, maar biedt daarentegen wel minder isolatie dan VM's (je deelt tenslotte de kernel met de host en de eventuele andere containers)

De bekendste OS-level virtualisatie opties waren/zijn OpenVZ en LXC voor Linux, Jails voor BSD en Solaris Zones/Solaris Containers. Al deze varianten werken gelijk aan een VM: Ze booten een compleet OS op basis van een zogeheten image, niet anders dan een iso of een 1 op 1 kopie van een geinstalleerd OS.
Je start dus bijvoorbeeld een complete Ubuntu install inclusief het init systeem Upstart en alle via Upstart gestartte processen of een RedHat install inclusief het init systeem systemd en alle via sytemd gestartte processen.
Aangezien je nog steeds een compleet OS moet booten bood dit wel voordelen maar werd niet het maximale uit deze voordelen gehaald.
Daarnaast was de useability van met name LXC (wat de standaard OS-level virtualisatie techniek/tool binnen Linux is geworden) wat lastig aangezien er geen gemakkelijke tools waren om de images te maken.

Sinds +-2 jaar is Docker met een opmars bezig. Het voornaamste verschil is dat er in de regel slechts 1 proces binnen een container gestart wordt ipv een compleet OS te booten. Dit i.c.m. een aantal handige kernel features maakt het mogelijk om containers instant te laten starten en de resource requirements aanzienlijk te verlagen.
Daarnaast biedt Docker een praktische en simpele manier aan om de bijbehorende images te bouwen. Dit is feitelijk een packaging mechanisme dat applicaties onafhankelijk van het host OS (zo lang het Linux is) kan package, distribueren en draaien.

Ik hoop dat dit wat onduidelijkheid wegneemt voor iedereen :)

P.S. Het is uiteraard ook mogelijk om het ene proces dat binnen Docker gestart wordt een init systeem of iets als supervisord te laten zijn waardoor je wel meerdere processen binnen een Docker container kunt draaien.

[Reactie gewijzigd door aaahaaap op 24 juni 2015 16:29]

Wat die containers doen lijkt me niet passend in slechts een klein artikel. Dat is hetzelfde als bij ieder artikel over Nvidia of AMD uit gaan leggen wat een videokaart doet.
Een goed achtergrond artikel, dat zou wel een goede toevoeging zijn wat mij betreft. Daar kan ook dieper in worden gegaan op de onderlinge verschillen die er nu zijn en welke problemen dat veroorzaakt.
Een complete uitleg lijkt me inderdaad een beetje overbodig, maar je kan volgens mij best in 1 a 2 zinnen even aanhalen wat een container doet. Hoe je het ook went of keert, een videokaart zullen veel mensen hier best kennen, maar ik had na het lezen van het artikel echt geen enkel, maar dan ook echt geen enkel idee waar het nou over ging. Ik dacht dat het ging over misschien een nieuw zip-format ofzo? Of een container om bestanden op te slaan. Geen idee. En ik kan me voorstellen dat dit onderwerp wat abstracter is dan videokaarten wat hier denk ik meer common knowledge is.
In je laatste vergelijking zit je goed. Een container om files op te slaan.
Een container om files op te slaan
Daar heb je al standaard packaging formaten voor zoals het de open packaging format (gebruikt in ebooks) en open packaging specifications (gebruikt voor office files)

Het gaat hier volgens mij specifiek om containers voor systeem images voor virtualisatie.

[Reactie gewijzigd door 80466 op 23 juni 2015 14:19]

Da's volgens mij ook veel te breed. Er zijn maar zat gestandaardiseerde containers, zoals mkv, zip, rar, avi, en daar gaat het hier volgens mij toch echt niet om.
Maar in een klein artikel over usb-c bij de oneplus mag er wel een hele alinea uitleg over wat usb-c inhoudt terwijl daar laatst al een groot artikel over is geweest? 8)7
Gewoon even in 1 of 2 zinnen: Een container is een ...

Dan staat er ook een plaatje van zeecontainers bij en ik dacht al: Wat doen IT bedrijven nou met containers?
Mij lijkt het dat de auteur zelf niet in staat is het in 1a2 zinnen uit te leggen en het dus maar aan de community laat. Bij andere artikelen wordt dat wel gedaan, vaak over onderwerpen ook meer standaard zijn imho.

Ik dacht bvb eerst dat het over mkv-achtige containers ging :9
Dank u, daar was ik ook naar op zoek!
Absoluut belangrijk dat je weet wat het is - maar T.net is een techsite- waar iedereen kan Googlen :P
Afgelopen jaar is er genoeg nieuws geweest wat betreft containers
Google op 'containers' en je krijgt transportcontainers. Er wordt nergens *software*containers vermeld.

En voor een techsite zijn er wel heel veel offtopic berichten dan.
Je ziet ook de termen CoreOS en Docker in het artikel staan. Even zoeken op "docker containers" levert voldoende interessante informatie op. Beetje intelligent zoeken is ook iets wat je van bezoekers van een techsite mag verwachten.
Of van de redactie. Dat geeft het artikel net iets meer dan een persbericht vertalen.
Ik snap ook echt niet waar het nou over gaat, nooit geweten dat zeecontainers een OS draaien??
Dus dank voor de uitleg :)

Edit: ja ja, offtopic 8)7

[Reactie gewijzigd door olivierh op 23 juni 2015 12:58]

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 ).
Maar wat is het verschil met APPV? APPV doet namelijk het zelfde. Een Applicatie "Container" welke geïsoleerd is van andere componenten met eventueel delen van host-os resources of totale isolatie met de mogelijkheid om meerdere containers van de zelfde applicatie naast elkaar te draaien waarbij bijvoorbeeld alleen de applicatie versie anders is, of andere database koppelingen et cetera.
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 ).
In grotere Enterprise omgingen is dit al lang de standaard, ben zelf al bijna een decennia hiermee bezig, maar tja, het is Windows dus niet interessant.
Maar het virtualiseren van applicaties in hun eigen container en runspace is gewoon geweldig. Met name door de isolatie en het voorkomen van conflicten tussen versies van componenten.

Echter of het een oplossing is voor virussen is een ander iets. Alles wat IO heeft naar buiten is gewoon kwetsbaar. Ja de basis container zal niet besmet worden, maar kan wel als doorgeefluik dienen, en containers met persitant writeable area's kunnen een virus of andere bedreiging gewoon opslaan en een herstart van de container laten overleven.
Zoals je zegt... het is meer een Enterprice omgeving gedoe. Docker in mijn mening is a stap dichter bij de gewone man. *haha*. Er zijn veel leuke technologie maar vaak zijn ze closed source want de bedrijven willen hun klanten aan hun binden ( niets mis mee maar ook de reden waarom je dit soort tech tot op heden maar beperkt zag op de gewone markt ).

Is het een oplossing voor virussen? Nowp... Je zal altijd virussen hebben maar bekijk het zo:

* Nu: Virus/Trojan ... daar gaat gans je systeem. Eenmaal dat toegang heeft, kruipt zo een beestje overal.
* Isolatie: De virus is vaak beperkt tot de container waar het in zit. Kan het naar buiten proberen te geraken via extern opslag of andere API's dat het programma aanspreekt.

Jazeker ... maar het is een pak moeilijker en zelf als het buiten de container x geraakt, zelf dan is het nog enorm moeilijk om alle containers te infecteren.

De perfecte muur bestaat niet want er zal wel altijd iemand zijn dat de muur kan slopen via een klein gaatje. Maar je kan het hun wel enorm moeilijk maken tot het punt dat het hun tijd / moeite niet meer waard is.

Nu ( in geval van Windows ) is het nog altijd een grote grap. Linux is beter maar zonder containers is gans je root OS even kwetsbaar. Het is gewoon te makkelijk ( vind ik persoonlijk ).

Ik ben iemand dat een grondig hekel heeft aan de rommel dat iedere OS veroorzaakt. Het maakt niet uit of het windows of linux of macOS is, ieder OS waarbij je applicaties kan installeren begint gewoon na de eerste installatie al "vervuild" te geraken. Upgrade je applicaties blijft er vaak rommel achter. Verwijder je ze. Meer rommel.

Of je wilt je OS upgraden onder Linux. Al vaak meegemaakt dat dit dan conflicten geeft met bepaalde programma's. Ondanks dat het beter georganiseerd is in Linux loop je ook nog tegen stoten aan.

Persoonlijk zou ik geen enkel probleem hebben bijvoorbeeld dat Windows enz gewoon puur een simpel kernel is en waarbij alles, maar ook alles in zijn eigen container draait. Secure als hell en het is niet alsof de performances zo danig beïnvloed zal worden. Wil je je systeem opkuisen? Verwijder alle containers in a grote opkuis. En je moet niet eens herstarten of je windows herinstalleren. Maar ja... zal niet gebeuren voor verschillende redenen ;-)
Ik ben eigenlijk helemaal geen fan van containers. De techniek heeft zeker z'n plaats maar de meeste toepassingen maken er verkeerd gebruik van.

Wat de meeste gebruikers van containers namelijk willen is een bevroren softwarestack waar nooit meer iets aan verandert. Een soort appliance. In veel gevallen betekent dit dat de software in zo'n container nooit wordt gepatched en je in die container dus allerlei kwetsbaarheden mee sleept. Je bent min of meer afhankelijk van de leverancier van zo'n container om voor security updates te zorgen. Dat doen ze misschien wel voor hun eigen applicatie maar vaak niet voor de rest van de software in zo'n container. Als gebruiker weet je niet eens wat er in zo'n container zit en het is ook niet de bedoeling dat je er zelf iets aan verandert.

Op een traditioneel Linux systeem staan al je libraries centraal geinstalleerd en als je die patched dan is het in één keer geregeld voor alle applicaties die er gebruik van maken. Bij containers zal je bij ieder securityprobleem in een veel gebruikte library al je containers apart moeten laten bijwerken door de leveranciers.

Daarmee is niet gezegd dat er geen goede toepassingen van containers zijn. Het is bijvoorbeeld een fijne techniek om een complete software-stack door je OTAP-straat te bewegen of om te zorgen dat al je developers dezelfde ontwikkelomgeving gebruiken.

Je moet het alleen niet als appliance inzetten. (Hetzelfde verhaal kan ik overigens ook houden over de VMs en appliacnes die sommige leveranciers bieden).
Als je niet tevreden bent met de beheerder van een container. Gebruik dan de container van een ander persoon. Ben je niet tevreden van de beheerder van van alle containers. Neem een kopie van hun container en beheer je eigen versies ervan dat je update / security patched.

Dat is juist de vrijheid van docker hun container systeem. Je bent niet gedwongen om de rest van je level gelinkt te zijn aan die ene beheerder / container / ...

Ik wil gerust geld inzetten dat de docker registry containers meer up to date / gepatched gaan zijn, dan de containers dat je zelf beheerd! Als je een container gebruikt van iemand dat weinig gebruikers heeft, ja ... dan kan je in zo een toestanden lopen maar vaak zijn de populaire containers ook die dat het meeste onderhouden worden. Laat staan als je gebruik maakt van de OFFICIËLE! containers. Je weet toch dat heel wat programma ontwikkelaars nu ook een officiële versie van hun software container op docker staan hebben, dat ze in sysc houden met hun ontwikkelingscode?

Dom voorbeeld:

https://registry.hub.docker.com/_/nginx/

Je kan al je containers laten upgraden net zoals op Linux centraal door naar de latest versie te gaan. Docker heeft support daarvoor ingebouwd.

En als gebruiker kan je PERFECT weten wat er in een container zit. De container installatie script zijn open source / leesbaar. Je ziet perfect ieder commando dat uitgevoerd word!

Wil je zien wat ze uithalen:

https://github.com/nginxi...38de804038266d/Dockerfile

De link voor de registry / installatie file staat puur bij iedere image. Open voor het publiek, je ziet exact wat iedere image doet.


Sorry dat ik het zeg maar veel van je argumenten zijn niet van toepassing.

Op een traditioneel Linux systeem staat alles centraal en ja kan je alles in één peer updaten. Maar zodat je meer gaat doen dan een paar websites hosten dat draaien op één PHP/MYSQL versie, dan word alles ingewikkelder en vanuit security standpunt is gans je systeem in gevaar als er maar één bug misbruikt word.
Ik moet even voorop stellen dat ik vooral ervaring heb met VMs en nog maar weinig met containers. De manier van gebruik lijkt echter veel op elkaar daarom vind ik dat ik mag extrapoleren.
Als je niet tevreden bent met de beheerder van een container. Gebruik dan de container van een ander persoon. Ben je niet tevreden van de beheerder van van alle containers. Neem een kopie van hun container en beheer je eigen versies ervan dat je update / security patched.
Dan moet ik wel die keuze hebben. Ik heb nu een aantal VMs draaien van leveranciers die ik min of meer moet draaien omdat ze bv management tools voor hardware bevatten. Die kan ik niet zomaar bij een andere leverancier gaan halen. Als ik naar de updates kijk die ik daar voor ontvang dan weet ik dat ze niet goed worden bijgewerkt.
Ik verwacht dat die leveranciers vroeg of laat ook met containers aankomen en dat die containers net zo veel onderhoud krijgen als de VMs die ik nu moet draaien.
Sorry dat ik het zeg maar veel van je argumenten zijn niet van toepassing.
We hebben verschilllende use-cases voor ogen. Als je zelf de containers beheerd en alles wat er in zit dan is het een prima systeem.

Ik heb heb bezwaren tegen containers die door een externe partij afgeleverd worden omdat het "handig" is en waar vervolgens niet wekelijks security-patches voor komen maar die juist helemaal bevroren worden. Dat is uiteindelijk een kwestie van een slechte partner maar containers werken dat soort gedrag wel in de hand.
Je geval is een meer uitzondering dan regel.

Ik heb ook al docker containers gezien waar ze gewoon ngenix, php, enz allemaal in één container smijten ipv alles apart. De oude stijl van VM's in feiten. Je zal altijd wel mensen of bedrijven hebben, dat hun voeten vegen met een deftige separatie.

Welke containers heb je al gezien dat zo met de voeten vegen? Ik zou zelf durven zeggen dat het eigenlijk niet zo veel uitmaakt.

Stel dat je container Shipyard download. Standaard zit er een databank container aan gelinkt. Je argumentatie is, als die persoon dat Shipyard beheerd, de databank niet upgrade dat je mogelijk bugs/security leaks enz niet opgelost kunt krijgen.

Ik kan je zeggen dat als er geen specifieke aanpassingen gedaan zijn aan de database container, dat je deze gerust kan overschrijven met een nieuw versie. Neem de Shipyard installatie script en pas de required database container aan. Als men de boel deftig designed, zit de database bestanden in een data container, en kan je zonder enige problemen upgraden naar de laatste versie.

Een voorbeeld hoe normaal moet een deftig installatie er kan uitzien ( als je wilt ):

* Webserver container
* Webserver Data container ( waar je code in zit ).
* Webserver Configuratie container ( configuratie bestand ). Zotte overkill ;)
* PHP container
* PHP Configuratie container ( configuratie bestand ). Zie boven.

Indien je dit allemaal wilt beheren onder één packet. Maak dan Applicatie X aan, met als installatie de latest versies. Aangezien je data & config apart zijn, is het een simpel feit van de engine containers te upgraden.

Nu ... als we spreken van het geval van Shipyard, je kan de boel overnemen. Dat is het leuke van docker hun open systeem. Het enige nadeel is, als de ontwikkelaars zo lui zijn, dat ze alles hardcoderen in hun containers. Maar dat kan je altijd met alle applicaties voor krijgen.

Dat is zoals een newbie PHP programmeur dat geen anti-sql injectie toepast in zijn code. Je zal altijd verschillende niveau's hebben van ontwikkelaars of firma's.

Is dit docker hun probleem / fout dat er bepaalde bedrijven stoten uithalen zoals dat? Nee ... sorry maar je kan dit niet echt afschrijven op docker of de andere VM programma's zoals VirtualBox. Het goede nieuwe is als die spullen draaien in een VM, is dat de schade dat ze kunnen uithalen beperkt is. Het is beter dan dat je die programma's onder je main OS zit te draaien, waarlangs een hacker dan toegang zal hebben tot alles op je server ( of zelf je gans netwerk! ).

Containers werken dat gedrag niet in de hand. Als een bedrijf een slechte update filosofie heeft, zal het feit dat ze met containers werken of puur root os werken geen beetje verschil uitmaken.
En dat is prima op te lossen met centraal beheer door projecten als Atomic en Shipyard, en mogelijk iets als Puppet (of hoe de vervanger daar ook van mag heten)
Ik weet niet of ik je opmerking begrijp. Wat is prima op te lossen? Dat containers niet gepatched worden?

De tools die je linkt zijn handig om zelf containers mee te beheren maar helpen niet bij containers die je van een vendor krijgt. Die zal de vendor zelf moeten patchen. Als ik het goed begrijp want ik heb Atomic en Shipyard zelf nog niet gebruikt.

Je kan in principe zo'n container open maken en zelf patchen maar dat is niet de bedoeling en de leverancier zal er geen support meer op willen geven.
Ja, mijn opmerking gaat over het patchen van containers. Als je een container download/krijgt ben jij verantwoordelijk ervoor, niet de vendor (als ik de EULA's van wat containers die ik voorbij zag komen goed gelezen heb).

En als een container aan het net hangt is het sowieso jouw zaak om het te beveiligen met een (hardwarematige) firewall.
Ik wil er zelf ook voor verantwoordelijk zijn maar veel afnemers van containers willen dat eigenlijk niet. Die willen een container omdat alles dan "gewoon" werkt en niet stuk gaat bij onderhoud aan de host. Dat klopt alleen zolang je niks aan die container verandert.

Het is prima mogelijk om goed met containers om te gaan maar de vragen die ik er over krijg zijn vooral van mensen die het als excuus zien om geen systeembeheer te hoeven doen.
De kracht van containers is juist dat de container niet veranderd wordt. Hierdoor kan je een perfect versiebeheer toepassen waarbij je OTAP kunt toepassen op een container zonder dat je het onderliggende OS hoeft aan te passen. Een container blijft gewoon het zelfde tot er vanuit het OTAP proces een nieuwe container komt met de bijgewerkte versie.
Er is juist geen enkele reden meer om oude images/draaiende containers te hebben. De stappen om een image te bouwen leg je vast een zgn Dockerfile, een aanpassing + nieuwe build daarvan is secondenwerk en zoals hieronder ook al genoemd gemakkelijk te automatiseren. Komt er op neer dat je het concept van Continuous Integration en Continous Delivery toepast voor je infrastructuur/images.

Specifiek over oude images waar je zelf geen beheer over hebt:
In de praktijk komt het er op neer dat nagenoeg iedereen die containers echt gebruikt zijn eigen registry (artifact store voor images) heeft en zijn eigen (base)images beheert.

Mocht het zo zijn dat je een (base)image hebt die baseert op een publieke image en die wordt niet geupdate: Zolang je publieke images gebruikt die gebouwd worden dmv automated builds (en dat zou altijd moeten zijn anders heb je geen idee wat voor code je aan het uitvoeren bent!) zit je goed. Dat een image aan automated build is betekend namelijk dat de bijbehorende Dockerfile en de eventuele verdere benodigdheden direct uit de publiek toegankelijke (git) repository van de eigenaar van de image gehaald worden om de image te bouwen. Dit betekend dus ook dat iedereen deze files kan downloaden/clonen en er zijn eigen (base)image van kan maken.

[Reactie gewijzigd door aaahaaap op 24 juni 2015 16:27]

Gezien de commentaren hierboven lijkt het begrip Docker nog niet erg bekend. Ik raad iedereen aan zich hierin onmiddelijk te verdiepen en goed de verschillen met Virtual Machines te onderzoeken. We gaan nog veel horen (en gebruikenmaken) van Dockers.

Dockers zijn containters die applicaties van elkaar isoleren. Het is ook mogelijk om Dockers te koppelen bv DB en applicatielaag. Behalve het isolatie voordeel, is het grote voordeel de wijze van uitrol van de applicatie. De applicatie wordt namelijk compleet geinstalleerd in de container uitgerold, inclusief de nodige settings voor OS en netwerk! Reuze makkelijk in een OTAP.
Echter de containers draaien wel in het zelfde OS waardoor een aantal voordelen van VMs niet voor Dockers gelden.

Dockers kunnen nu al op een aantal NAS modellen (van bv Synology) gebruikt worden.
Toevallig gister eens mee gespeeld (op XPenology) - ntopng installeren is een aardig process, met docker is het klik-klik draaien, mooi spul.

Het draait ook heel licht. Weet er nog niet het fijne van maar veel potentieel zie ik wel.
even voor de duidelijkheid je kan dus zeg maar een youtube container maken en die zo op alle platformen draaien die docker ondersteunen?
Vet, dit wordt mooi.

Containerization is het isoleren van verschillende applicaties runnend hetzelfde OS. Dit is efficienter dan virtualiseren omdat er minder overhead is en het geeft een duidelijke beschrijving wat de dependencies van een willekeurige applicatie is.

Waar het ook een oplossing voor biedt is b.v. applicaties die verschillende versies van b.v. PHP of Java nodig hebben op dezelfde machine te kunnen draaien.

Zie ook
https://en.wikipedia.org/...stem-level_virtualization
Puur voor verschillende versies van Java of PHP draaien heb je echt geen containers nodig hoor. Uiteindelijk denk ik dat je er vooral op het gebied van security, afschermen van omgevingen van elkaar, iets mee opschiet. En uiteraard simpeler deployen, alhoewel het op dit moment best nog tricky kan zijn.
En hoe wil jij het dan voor elkaar krijgen dat site A PHP 5.6.x draait en site B (op dezelfde server) PHP 5.7.x?

Edit: En dan heb ik het over PHP op *nix

[Reactie gewijzigd door sfranken op 23 juni 2015 13:28]

Nou, dat kan met IIS prima. Gewoon op een andere site een andere PHP versie kiezen met PHP manager. Geen docker nodig
Dank, ik heb mijn reactie gewijzigd. IIS doe ik (bewust) niks mee, en dat hoort in mijn ogen ook niet samen met PHP. Tuurlijk, het kan, maar je kiest niet voor IIS en Windows om PHP te draaien, je kiest voor IIS en Windows voor ASP(.NET) in mijn ogen.
PHP is tegenwoordig standaard ondersteund door Microsoft in IIS en werkt perfect. Overigens nog nooit problemen gehad met het implementeren van PHP onder IIS, sterker nog, het is binnen een paar minuten in te richten en te configureren als je weet waar je mee bezig bent. En voor de snelheid hoef je het ook niet te laten.

Daarnaast is het onder IIS zeer eenvoudig om meerdere sites naast elkaar te draaien met een andere PHP versie per site. Onder Apache weet ik het niet hoe dat gaat maar onder IIS is het simpel. Wat snel kan onder IIS is zelfs gewoon een site schakelen tussen PHP versies, handig bij een upgrade van PHP.

[Reactie gewijzigd door Wim-Bart op 23 juni 2015 15:21]

juist op het gebied van security is docker nog niet volwassen genoeg om volledig daarop te drijven, dat dien je minimaal buiten je containers om goed geregeld te hebben.

dat gaat overigens wel goed komen in de toekomst hoor :)
Volgens mij maakt het plaatje het verhaal een beetje verwarrend.
Welk plaatje? Dat van de zeecontainers? Dat is nou juist de analogie die vaak wordt gebruikt om het concept van containers uit te leggen en daarom heel passend.
Welk plaatje? Dat van de zeecontainers? Dat is nou juist de analogie die vaak wordt gebruikt om het concept van containers uit te leggen en daarom heel passend.
Ik ken allebei de bedrijven niet, en met name de naam "Docker" is dan toch verwarrend, omdat het bijvoorbeeld zou kunnen gaan om de automatisering van zeecontainers, als je op het plaatje af moet gaan.
Maar ik was dus even overtuigd dat het over zeecontainers ging en vond het vreemd dat hier niet al lang en breed een standaard voor bestond.
Die bestaat gelukkig al, de TEU; Twenty feet-equivalent. Dit is de helft van de container zoals de meesten die kennen, de FEU (raden waar die voor staat ;) ).

Inhoud van containerschepen wordt aangegeven met de TEU. De Maersk Triple-e klasse (een-na-grootste containerschepen) kan er bijvoorbeeld 18.000 kwijt.
Die bestaat gelukkig al, de TEU; Twenty feet-equivalent. Dit is de helft van de container zoals de meesten die kennen, de FEU (raden waar die voor staat ;)
Een zeecontainer is in verhouding wel een 'dom' rechthoekig stuk blik waar alleen maar een paar ogen op zitten waar een hijskraan op past.

Ik dacht even dat ze het hadden over een standaard voor interoperabiliteit van 'slimme' containers die zelf een computer of chip aan boord zouden hebben en dus zelf een stuk interactie hebben met de haven, het schip of de kraan waar ze door moeten worden opgepikt.
Dit dus. Ik las het artikel en keek naar de plaatjes en vroeg me af waarom al deze bedrijven geïnteresseerd zijn in zeecontainers.
Ik zie het inderdaad al voor me met alle tweakers die zich afvragen of die containers vol zitten met hardware (aka. noodserverpark).
Dit dus. Ik las het artikel en keek naar de plaatjes en vroeg me af waarom al deze bedrijven geïnteresseerd zijn in zeecontainers.
Zoals het artikel stelt: omdat ze hun eigen koers vaarden. ;)
Idd. Ik wist ook totaal niet om wat voor "containers" het ging, en dacht al dat de linux foundation andere markten ging aanboren, deze van de zeecontainers... Leek me raar :-)
Het duurde tot halverwege het artikel dat ik doorhad dat het niet over echte containers ging (van een maritieme achtergrond komende).
'Open source formaat' verbaasde me al zo, omdat er allang een standaardformaat bestaat voor de container, de TEU.

Waarom bij vrij straightforward artikels over toevoeging van een usb-c poort wel extra info wordt gegeven over wat die poort inhoudt, en waarom hier niet, is voor mij een raadsel.
Het is inderdaad verwarrend. Enfin, een "Docker" is dus gewoon een "chroot" omgeving in een gebruikersvriendelijk jasje.
Echt gebruiks vriendelijk zijn die dockers niet.
Had het op de synology draaien, maar nog niet een aan de praat gekregen.

Of ze moeten het deployen makkelijker maken of/en een beter handleiding komen.
in de registry staan alle dockers, zoek daar iets en installeer het, dan draait het (op synology).
bij de registry zelf staan soms ook instructies, dan kun je het makkelijker vanaf de commandline draaien.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True