Docker, az informatika kikötőmunkása

Korábban már írtam virtuális gépekről és azt is megmutattam, hogyan alakítható ki vele egy komplett fejlesztői tesztkörnyezet. Már ez a fajta virtualizáció is sokat segített bizonyos problémák megoldásában. Van azonban egy másik lehetőség, amikor nem egy virtuális gépet indítasz egy teljes értékű operációs rendszerrel, hanem csak az alkalmazásod számára biztosítod azokat a programkönyvtárakat, binárisokat, amit valójában el szeretnél indítani. Valószínűleg legtöbbetek számára ez alapján egy egyszerű "jail" ugrik be, ahol egy programot be lehet zárni a fájlrendszernek egy adott területére és csak az azon belüli fájlokat látja. Gyakorlatilag valóban valahol itt kezdődött minden.

Később

viszont már a jail (börtön) mellett megjelent a container (konténer) fogalma és az LXC (Linux Containers) lehetőséget adott arra, hogy a Linux kernel képességeit (namespaces, cgroups) kihasználva egy program által felhasználható erőforrásokat (memória, processzor) is korlátozni lehessen és a program többek között ne lássa az "eredeti" operációs rendszeren levő felhasználókat, egyéb futó programokat és a hálózatát sem.

Docker

Valójában a Docker ezekre, a már régóta létező megoldásokra támaszkodik, de azoknak a kezelését leegyszerűsíti és egy speciális konfigurációs fájlban (Dockerfile) leírhatóvá teszi a futtatandó program virtuális környezetének, azaz a konténernek az alapját, mint egy sablon. Ezt a sablont nevezzük a Docker nyelvén "image"-nek. Számtalan hivatalos és a közösség által feltöltött image elérhető ingyenesen a Docker Hub-ról, és időnként más szerverekről is..

Tehát

  • a Dockefile-ban leírod, hogy mire van szüksége a programodnak. Például egy webszerverre.
  • A Dockerfile-ból egy paranccsal létrehozod az image-et
  • Az image-ből elindíthatsz akárhány példányban azonos alappal/fájlrendszerrel rendelkező konténereket, amiben elindul optimális esetben egyetlen darab program (egész pontosan process)

Ugyanakkor ezek az elindult konténerek nem másolatai lesznek az image-nek, tehát nem fog 1 darab 100 megabájtos image-ből elindított 10 konténer 1 gigabájt helyet elfoglalni, mert az image-ben levő fájlokon olvasható módban osztoznak a konténerek. Csak akkor nő a konténer mérete, ha ezeken a fájlokon változtatsz, vagy új fájlokat mentesz rá, ugyanis az image-ben levő fájlok nem változtathatók a konténerből és ekkor jön csak létre a változott fájl másolata. Ugyanezen okból az image fájljainak törlésekor sem csökken a konténer mérete, mert csak a konténerben lesz töröltként látható. Azaz nem látható. Írni csak a konténer fájlrendszerét lehet és a felhasznált tárhely ezek méretétől függ.

Ráadásul a konténer létrehozásakor azt is meghatározhatod paraméterekkel, hogy mennyi erőforrást tudjon felhasználni a benne futó szoftver és milyen módon tudjon kommunikálni a külvilággal, a konténert futtató operációs rendszerrel, vagy akár a többi konténerrel. Ami azt jelenti, hogy szükség esetén a konténeren kívülről meg lehet osztani a konténerrel mappákat, át lehet irányítani portokat (például a webszerver 80-as portjára a konténerben) és engedélyezhetsz olyan rendszerutasításokat, amiket alapértelmezetten a konténerekből nem lehet futtatni.

Ám itt még nem áll meg a tudomány

Ahogyan a kernel képességeit kihasználta az LXC, majd a Docker mindezt egyszerűbbé tette egy Dockerfile-lal és a docker paranccsal, a Docker konténerek indítását és azok kapcsolatainak leírását tovább könnyíti a Docker Compose, ami már nem egy image leírását teszi lehetővé, hanem egy több konténerből álló, összetett alkalmazás felépítésének és indításának.

Azokról nem is beszélve, amik ezeknek a konténercsoportoknak a kezelésében és felügyelésben segítenek (pl. Docker Swarm), illetve webes adminisztrációs felületet is adnak akár egy több gépből álló klaszter működtetésére, alkalmazások skálázására (egy alkalmazás szétosztható több gépre, több példányban indítható). A legtöbb célra nem csak egy megoldás létezik. Így a Dockernek, a Docker Compose-nak és még a klasztereket menedzselő eszközöknek is vannak alternatíváik. Némelyik ingyenes, de vannak fizetős, enterprise verziók is.

Talán egy kis kedvcsináló lehet, hogy ma már Windowsra is készülnek image-ek Microsoft szoftverekkel, illetve a Google is ilyen konténerekkel dolgozik. A Kubernetest eredetileg a Google kezdte fejleszteni, ami szintén konténerek kezelésére, skálázására használható klaszterben.

Az a célom

hogy az ezekkel kapcsolatos tapasztalataimat megosszam és megpróbáljam minél érthetőbb nyelvre fordítani az információkat, ezzel valamelyest kiegyenesítve a fogalmak és eszközök határtalan labirintusát. Ha tetszik az ötlet és érdekel a téma, kedveld a bejegyzést Facebookon, vagy szólj hozzá a cikkhez, hogy ezzel is megerősítsd, hogy jó irányba tartok.

További források

Kategóriák: 
Megosztás/Mentés

Új hozzászólás