Gyakorlati példákon keresztül bemutatom, hogyan lehet konténereket létrehozni és mi a különbség konténer és virtuális gép között. Mivel szeretném, ha mindenki számára nyilvánvaló lenne, hogy nem csak Docker konténerek léteznek, ezért az LXD-t fogom telepíteni, amivel LXC konténerket és virtuális gépeket is lehet kezelni.

A korábbi WSL-es Docker cikk folytatásaként most a frissen telepített gépek elmentésével folytatom, így bármikor vissza lehet állni egy korábbi verzióra. Beállítom az alapértelmezett felhasználót is, amit az exportáláskor elfelejt a gép, illetve végig mutatom azt is, milyen állapotai lehetnek a WSl gépeknek. Ha mentést nem is szeretnél a gépeidről, de ugyanabból a disztribúcióból többet is szeretnél telepíteni különböző célokra, akkor is érdemes tovább olvasni. A videón pedig gyakorlatban is követheted a beállításokat.

Bár a WSL 2 telepítéséhez nincs szükség Hyper-V -re, mint a Docker Desktophoz, de a VirtualMachinePlatform engedélyezése is befolyásolja a többi virtualizáló szoftver működését, mint a VirtualBox vagy a VMWare Workstation. VirtualBox esetén például le kellhet tiltani a VT-x/AMD-V opciót, vagy a következő üzenet fogadhat:

Failed to open a session for the virtual machine ubuntu-dev
Cannot enable nested VT-x/AMD-V without nested paging and unrestricted guest execution

Windows 10-ben a legegyszerűbben a Docker Desktop telepítésével futtathatsz Docker konténereket. Az előnye még, hogy nem csak Linux vagy Windows konténereket tudsz vele futtatni, hanem egyidőben mindkettőt. Bár egyszerre csak az egyiket támogatja, de a konténereid nem vesznek el, amikor a két mód között átváltasz, csak a docker parancs a kiválasztott módnak megfelelő docker démont fogja látni alapértelmezetten. Előfordulhat, hogy nem akarod engedélyezni a Hyper-V feature-t, de az alapértelmezett telepítés szerint az kötelező. Én viszont mutatok egy módszert ennek kikerülésére, persze ára is van. Ha nem szeretsz olvasni, azs em gond. Dőlj hátra és élvezd az oktatóvideót.

A 2020-as év sok területen hozott változást és úgy tűnik, a Docker sem maradt kivétel. Azon túl, hogy természetesen tovább fejlődött, néhány új szabály bevezetése miatt át kell kell gondolni a korábbi használati szokásokat. Az egyik nagy előny ugyanis az volt eddig, hogy bármilyen gépen is dolgoztam, ha volt internet hozzáférésem, le tudtam tölteni a szükséges Docker image-eket, fel tudtam telepíteni több gépre is egymás után a Docker Hub-ról letöltött programokat, törölni tudtam és újra el tudtam készíteni egy virtuális gépet, hogy egymás után többször is leteszteljek egy telepítést az alaprendszerből kiindulva. Ez viszont megváltozott, amit lehet kezelni, és sokaknak fel sem fog tűnni a változás, de lesznek sokan, illetve valószínűleg már vannak sokan, akiknek feltűnt és kénytelenek voltak változtatni a módszereiken.

A korábbi cikkekben előkerültek már a függvények, amikkel egy fájlon belül is önálló egységekre bonthatók a nagyobb szkriptek, illetve egyfajta függvénykönyvtárként bárki számára átadhatók. Ez nagyon jó, de néha talán feleslegesnek tűnik egy egyszerűbb feladatra. Ilyenkor jöhetnek jól az álnevek, avagy aliasok. Más részt viszont az alias sem való mindenre és nem is minden esetben alternatíva függvényre vagy változóra. Ebben a cikkben megmutatom mindhárom előnyét, hátrányát, hogy mindig a legmegfelelőbbet választhasd.

A Docker fejlődése megállíthatatlan, persze az új feature-ök jelentősége olykor megkérdőjelezhető, de a szubjektív véleményem, hogy nagyon is jó irányba tartó. A 19.03-as verzióval megjelent a context, ami egyszerűbbé teszi a távoli Docker démonok elérését, ugyanakkor előtte sem volt lehetetlen. Tudtad-e, hogy már a 18.09-es verziótól van lehetőség akár távoli unix Docker sockethez is csatlakozni SSH-n keresztül pusztán a Docker kliens segítségével? Vagy talán nem is hiányzott, mert anélkül is meg lehet és meg lehetett oldani. Hogy pontosan miről is van szó, kiderül a cikkből.

Korábban már szó volt az alapokról és a változók témaköréről, de az eddig bemutatott Ansible 2.8 működését az alapbeállításokra bíztam, habár nem kevés létezik az Ansible viselkedésének módosítására, finomítására. Annyira, hogy a telepítéssel külön programot is kapsz ezek lekérdezésére, ha nem az online dokumentációt szeretnéd böngészni. Nem beszélve arról, hogy alkalmazásuk is többféle módon történhet. A cikkből megtudhatod, milyen módszerek vannak a konfigurációra, és néhány fontosabb beállítást is megismerhetsz. Olvasd tovább a cikket és tégy egy újabb lépést a magabiztos Ansible használat felé.

Ha Linuxon szeretnél adminisztrátori jogosultsággal futtatni utasításokat, gyakran egy nem adminisztrátor felhasználóval lépsz be, majd a sudo paranccsal szerzel az adott utasítás futtatásának idejére adminisztrátori jogosultságot, avagy root jogot. Ugyancsak gyakori, hogy egy program elég nagyra nő, hogy a sok-sok shell script mellett, azokban függvényeket is írsz. A nagy kérdés, hogy mi van, ha ezek közül az egyik függvénynek adminisztrátori jogokkal kell működnie, de az azt meghívó szkriptnek nem. Egy részt, talán itt az ideje újratervezni, de talán megvan az okod rá és kioktatás helyett okításra van szükséged, ezért a következőkben megosztok veled pár lehetőséget. Az alábbiak megértéséhez érdemes elolvasni a Bash argumentumok és titkaik című cikket is.

A Bash egy népszerű Linux shell, amit ugyan kényelmi szempontból sokan leváltanak a termináljukban egy másfajta alapértelmezett shellre, például Z shellre, de a szkriptek továbbra is Bash-hez készülnek. Van egy-két sajátossága a Bash-nek, de az olyan alap funkció, mint az argumentumok átadásának működése néha úgy tűnik, kevés figyelmet kap, hiszen más shellekben is hasonlóan működik, nincsen benne semmi különleges. De vajon valóban így van? Ki mered jelenteni, hogy mindent tudsz róluk? Ha igen, a cikk talán nem neked készült. Régóta írok Bash szkripteket is, de mégis volt, aminek én sem voltam teljesen tudatában. Olvasd tovább a cikket és teszteld le a saját tudásodat is.