A Microsoft Windows Server 2016 konténerei a technológia kiterjesztését jelentik az ügyfelek számára. A Microsoft fejlesztési folyamatuk részeként tervezi az ügyfelek fejlesztését, üzembe helyezését, és most konténeres alkalmazástárolást.
Mivel az alkalmazások telepítési aránya folyamatosan növekszik, és az ügyfelek napi vagy akár óránkénti rendszerességgel használják az alkalmazásverziók telepítését, a fejlesztői billentyűzetellenőrző alkalmazások gyors üzembe helyezése kritikus fontosságú az üzleti sikerhez. Ezt a folyamatot a konténerek felgyorsítják.
Míg a virtuális gépek képesek alkalmazásokat adatközpontokban, a felhőbe és onnan áthelyezni, a virtualizációs erőforrásokat tovább oldják a konténerek az operációs rendszer virtualizációja (rendszerszoftver) révén. Ezt a döntést, a virtualizációnak köszönhetően lehetővé teszi az alkalmazások gyors szállítását.
A Windows Technology Container kettőt tartalmaz különféle típusok konténerek, Windows Server Container és Hyper-V tárolók. Mindkét típusú tároló létrehozása, kezelése és működése azonos módon történik. Még ugyanazt a konténerképet is gyártják és fogyasztják. Különböznek egymás között a tároló, a gazdagép operációs rendszer és a gazdagépen futó összes többi tároló között létrejött elszigeteltség szintjében.
Windows Server tárolók: Több tárolópéldány futhat egyidejűleg egy gazdagépen névtér-, erőforrás-kezelési és folyamatleválasztási technológiákon keresztül biztosított elkülönítéssel. A Windows Server-tárolók ugyanazon a magon osztoznak, üzemeltetve.
Hyper-V konténerek: Több tárolópéldány futhat egyidejűleg egy gazdagépen. Azonban minden tároló egy dedikált virtuális gépen belül van megvalósítva. Ez kernelszintű elkülönítést biztosít az egyes Hyper-V-tárolók és a gazdagép-tároló között.
A Microsoft a tárolóban tartalmaz egy Docker-eszközkészletet, amellyel nemcsak Linux-tárolókat, hanem Windows Server- és Hyper-V-tárolókat is kezelhet. A Linux- és Windows-közösségen belüli együttműködés részeként a Docker-élmény kibővült egy PowerShell-modul létrehozásával a Docker számára, amely immár nyílt forráskódú. A PowerShell-modul a Docker REST API segítségével helyileg vagy távolról is kezelheti a Linux és a Windows Server tárolókat. A fejlesztők elégedettek azzal, hogy platformunk nyílt forráskódú fejlesztése révén újításokat hajtanak végre az ügyfelek számára. A jövőben azt tervezzük, hogy a technológiát a Hyper-V-hez hasonló innovációkkal együtt ügyfeleinkhez is eljuttatjuk.
Vásároljon Windows Server 2016-ot
Kedvezményes áron kínáljuk a Windows Server 2016 megvásárlását Hivatalos partner Microsoft Oroszországban - DATASYSTEM cégek. Lehetősége lesz tanácsot kérni, valamint ingyenesen letöltheti a Windows Server 2016-ot tesztelés céljából, ha felveszi a kapcsolatot műszaki támogatási szakembereinkkel. Windows Server 2016 ár kérésre. Üzleti ajánlat a Windows Server 2016 vásárlásában való részvételhez kérésre e-mailben kaphat:A konténertechnológia feltárása
Windows Server 2016
A Windows Server 2016 egyik figyelemre méltó új funkciója a tárolók támogatása. Ismerjük meg őt jobban
A modern rendszerek már régóta eltávolodtak az egy operációs rendszer - egy szerver elvétől. A virtualizációs technológiák lehetővé teszik a szervererőforrások hatékonyabb felhasználását, lehetővé téve több operációs rendszer futtatását, elválasztva azokat egymástól és egyszerűsítve az adminisztrációt. Aztán ott voltak a mikroszolgáltatások, amelyek lehetővé teszik az elszigetelt alkalmazások önálló, könnyen kezelhető és méretezhető összetevőként történő telepítését. A Docker mindent megváltoztatott. Az alkalmazás környezettel együtt történő szállításának folyamata annyira egyszerűvé vált, hogy a végfelhasználót érdekli. A konténerben lévő alkalmazás úgy működik, mintha egy teljes értékű operációs rendszert használna. A virtuális gépekkel ellentétben azonban nem töltik be saját másolataikat az operációs rendszerről, a könyvtárakról, a rendszerfájlokról stb. A tárolók egy elszigetelt névteret kapnak, amelyben minden szükséges erőforrás elérhető az alkalmazás számára, de nem lehet kilépni. Ha módosítania kell a beállításokat, akkor csak a fő operációs rendszertől való eltérések kerülnek mentésre. Ezért a konténer a virtuális gépekkel ellentétben nagyon gyorsan elindul és kevésbé terheli a rendszert. A konténerek hatékonyabban használják fel a szerver erőforrásait.
Tárolók a Windows rendszeren
A Windows Server 2016 rendszerben a meglévő virtualizációs technológiák – Hyper-V és Server App-V virtuális alkalmazások – mellett a Windows Server Containers konténerek támogatása is hozzáadásra került, a Container Management verem absztrakciós rétegen keresztül valósítva meg, amely megvalósítja az összes szükséges funkciót. A technológiát még a Technical Preview 4-ben jelentették be, de azóta sok minden változott az egyszerűsítés irányába, és a korábban írt utasítások el sem olvashatók. Ugyanakkor kétféle "saját" konténer javasolt - Windows-konténerek és Hyper-V konténerek. És valószínűleg egy másik fő lehetőség a Docker-eszközök használata a PowerShell-parancsmagok mellett a konténerek kezelésére.
A Windows konténerek elvileg a FreeBSD Jailre vagy a Linux OpenVZ-re hasonlítanak, egy magot használnak az operációs rendszerrel, amelyet a többi erőforrással (RAM, hálózat) együtt megosztanak egymás között. Az operációs rendszer fájlok és szolgáltatások az egyes tárolók névterébe vannak leképezve. Az ilyen típusú konténerek hatékonyan használják fel az erőforrásokat, csökkentik a többletköltséget, és ezáltal lehetővé teszik az alkalmazások sűrűbb elhelyezését. Mivel a konténer alapképei egy maggal "vannak" csomóponttal, a verzióiknak egyeznie kell, különben a működés nem garantált.
A Hyper-V tárolók egy további szigetelőréteget használnak, és minden tárolóhoz saját mag és memória tartozik. Az elkülönítést az előző típustól eltérően nem az operációs rendszer kernel, hanem a Hyper-V hypervisor végzi (a Hyper-V szerepkört igényli). Az eredmény kevesebb többletterhelést jelent, mint a virtuális gépek, de nagyobb elszigeteltség, mint a Windows-tárolók. Ebben az esetben a tároló futtatásához ugyanazzal az operációs rendszer kernellel kell rendelkeznie. Ezek a tárolók Windows 10 Pro/Enterprise rendszeren is telepíthetők. Különösen érdemes megjegyezni, hogy a tároló típusát nem a létrehozáskor, hanem a telepítéskor választják ki. Vagyis bármely tároló futtatható Windows-ként és Hyper-V változatként is.
A tárolóban lévő operációs rendszerként a kivágott Server Core vagy Nano Server kerül felhasználásra. Az első a Windows Sever 2008-ban jelent meg, és nagyobb kompatibilitást biztosít a meglévő alkalmazásokkal. A második még lecsupaszítottabb, mint a Server Core, és úgy tervezték, hogy monitor nélkül fusson, lehetővé téve a szerver futtatását a lehető legkisebb konfigurációban a Hyper-V-vel, a fájlszerverrel (SOFS) és a felhőszolgáltatásokkal való használatra, 93%-kal kevesebbet igényelve. hely. Csak a legszükségesebb komponenseket tartalmazza (.Net CoreCLR-rel, Hyper-V, Clustering stb.).
A képformátum tárolásra szolgál. merevlemez vhdx. A tárolók, akárcsak a Docker esetében, képekként kerülnek mentésre a tárolóban. Amiben mindegyik nem menti el a teljes adathalmazt, hanem csak a különbségeket létrehozott kép az alaptól. Az indításkor pedig minden szükséges adat a memóriába kerül. A Virtuális kapcsoló a tároló és a fizikai hálózat közötti hálózati forgalom kezelésére szolgál.
Hogyan csomagoljunk egy alkalmazást egy Docker-tárolóba?Van egy NodeJS-ben írt alkalmazásom. Hogyan csomagolhatom Docker-képbe, hogy tárolóként fusson?
A Docker egy konténerkezelő rendszer POSIX-kompatibilis operációs rendszerekhez (jelenleg a Linux támogatott). A Docker egyik jellemzője, hogy egy alkalmazást az összes szükséges környezettel úgy csomagolhat, hogy az egy másik rendszeren futhasson anélkül, hogy hosszas és bonyolult függőségek telepítése vagy forrásból történő építése folyamatban lenne. A telepítésre kész csomagolt alkalmazást "image"-nek nevezzük. A Docker képek „sablonokon” – előre konfigurált munkakörnyezeteken – alapulnak. Felfoghatjuk ezeket operációs rendszer disztribúcióknak, bár ez nem teljesen igaz. A Docker dokumentációjának elolvasásával saját sablont is létrehozhat. Ennek a megközelítésnek az az előnye, hogy az alkalmazás képfájlja csak magát az alkalmazást tartalmazza, és a hozzá szükséges környezet automatikusan letöltődik a sablontárból. A Docker kicsit olyan, mint a chroot vagy a bsd jail, de másképp működik.
Fontos különbséget tenni a „tároló” és a „kép” fogalmak között. A tároló az alkalmazás futó példánya, a kép pedig egy fájl, amely az alkalmazást tárolja, és amelyből a tároló létrejön.
Tegyük fel, hogy van egy NodeJS-alkalmazása, amelyet egy tárolóba szeretne csomagolni. Tegyük fel, hogy az alkalmazást futtató fájl neve server.js, és az alkalmazás a 8000-es porton figyel a futtatásra. A „node:carbon” sablont használjuk. Az alkalmazás konténerbe helyezéséhez létre kell hoznia egy "Dockerfile" fájlt abban a könyvtárban, ahol az alkalmazásfájlok találhatók, amely leírja a kép előkészítésének paramétereit:
$ érintse meg a Dockerfile-t
A fájl tartalma valahogy így nézhet ki:
# Adja meg a használni kívánt sablont FROM node:carbon # Hozza létre az alkalmazás munkakönyvtárát a tárolóban WORKDIR /usr/src/app # Telepítse az alkalmazás függőségeit az npm segítségével # Másolja ki a package.json ÉS a package-lock.json fájlt is, ha van COPY csomag* json ./ RUN npm install # Másolja az alkalmazás fájljait a COPY képfájlba. . # Nyissa meg a 8000-es portot, hogy az elérhető legyen az EXPOSE 8000 tárolón kívül # Hajtsa végre a parancsot az alkalmazás CMD tárolón belüli futtatásához [ "npm", "start" ]
A szükségtelen fájlok képből való kizárásához felsorolhatja a nevüket a ".dockerignore" fájlban. Használhat maszkot (*.log).
A kép a következő paranccsal készül:
$ docker build -t felhasználónév/node-web-app .
$ docker images # Példa REPOSITORY TAG ID LÉTREHOZOTT csomópont carbon 1934b0b038d1 5 napja felhasználónév/csomópont-web-alkalmazás legfrissebb d64d3505b0d2 1 perce
A tároló indítása képből a következő paranccsal történik:
$ docker run -p 49160:8000 -d felhasználónév/node-web-app
Ez a példa létrehoz egy tárolót a „felhasználónév/csomópont-web-alkalmazás” képből, és azonnal elindul. A 8000-es alkalmazásport elérhető a helyi gépen (localhost), és ahhoz, hogy „kint” elérhető legyen, a 49160-as portra „továbbítódik”. Bármilyen szabad portot választhat, ezen kívül lehetőség van az alkalmazás továbbítására is. port "ahogy van" a " -p 8000:8000" opció megadásával.
A következő parancs kiadásával láthatja, hogy a tároló fut:
$ docker ps # Példa ID IMAGE COMMAND ... PORTS ecce33b30ebf felhasználónév/csomópont-web-alkalmazás:legújabb npm indítás ... 49160->8000
A tárolót különféle parancsokkal lehet kezelni, megadva ennek a tárolónak az azonosítóját:
$ docker szünet ecce33b30ebf - szüneteltesse az ecce33b30ebf azonosítójú tárolót
$ docker önéletrajz ecce33b30ebf - önéletrajz konténer azonosítója ecce33b30ebf
$ docker stop ecce33b30ebf - stop konténer azonosítóval ecce33b30ebf
$ docker rm ecce33b30ebf - távolítsa el a tárolót (ez eltávolítja az alkalmazás által a tárolóban létrehozott összes adatot)
Kész! Vagy az imák segítettek, vagy az áldozatok, de most már futtathatja a Docker konténereket a Windows belsejében. A nagyszerű hír a Windows Server 2016 megjelenésével érkezett. És nem valami ügyesen elrejtett virtuális gépről, vagy Linux kernelen futó Windows emulációról beszélünk – az igazi Windows egy igazi Dockerben fut, működő Dockerfile-lel, docker- komponálás és egyéb dokkoló trükkök .
Korlátozások
De ez nem jelenti azt, hogy mostantól bármilyen tárolót bárhol futtathat. Tekintettel arra, hogy a Docker konténerek "áthelyezik" az operációs rendszer kernelt a gazdagépükről (különben saját operációs rendszerrel kellene rendelkezniük, és virtuális géppé kell alakulniuk), a Windows konténerek csak a Windows 10 Pro legfrissebb évfordulós frissítésén futhatnak, ill. Windows Server 2016.
A második pont az, hogy továbbra sem lehet natív Linux-tárolót futtatni Windowson. Az Anniversary Update saját Linux alrendszerrel rendelkezik (amivel például egy igazi Bash-t is futtathat), de ez alulmarad egy teljes értékű Linux kernelhez, így egy rejtett virtuális gép továbbra is szükséges ugyanahhoz a konténerhez az Ubuntuval Windowson. .
Végül mindkét konténer futtatható Windows gépen egyszerre, de tánccal. Ha ezt a parancsot Windows Server 2016-on futtatja, és a Docker telepítve van (egy évvel ezelőtt ezt a boszorkányságot hívtam volna), akkor működni fog:
De ha a parancs után megpróbálja elindítani az Ubuntu tárolót, a Docker szomorú lesz:
A probléma az, hogy a Windows és Linux konténereket különböző Docker démonok szolgálják ki, amelyek ennek ellenére ugyanazt a csatornát használják a parancssorral való kommunikációhoz. Vagyis egyszerre csak egy démon lehet aktív. A hivatalos Docker webhelyen található egy „Docker for Windows” béta, amely megpróbálja kijavítani a problémát (egyelőre csak Windows 10 Pro és Enterprise rendszeren). De még akkor is, ha Windowsról Linux konténerekre szeretne váltani, be kell másznia a beállítások menübe, vagy kommunikálnia kell a parancssorral:
PowerShell
& "C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon
& "C:\Program Files\Docker\Docker\DockerCli.exe"-SwitchDaemon |
Windows képek
Eddig csak két alapkép létezik konténeres Windows rendszerrel:
Saját alapképet (karckép) nem készíthet.
A Windows Server Core image akár 10 koncertet is nyom, és általában úgy viselkedik, mint egy teljes értékű Windows Server 2016. Például az MS SQL és a teljes értékű .NET-keretrendszer probléma nélkül telepítve van. Ha az alkalmazás nem támaszkodik nagymértékben a felhasználói felületre, akkor az is települ.
A Nano Server valamivel érdekesebb. Ez egy nagyon optimalizált és lecsupaszított Windows Server, amely kevesebb, mint egy koncert. De van elég korlátozás: nincsenek 32 bites alkalmazások, UI, RDP, PowerShell levágása stb. Ez azonban nem akadályozza meg, hogy ugyanazt az IIS-t, .NET Core-t és még néhány MySQL-t is telepítsünk a Nano Serverre.
És elképzelhette volna valaki pár éve, hogy egy Dockerfile-ban egyszerre lehet találkozni "Microsoft", "Windows" és "PowerShell"-lel?
A microsoft/windowsservercore-ról RUN powershell -Command....
A microsoft/windowsservercore-ról FUTTATJA a powershell-Command parancsot. . . . |
Ez a Windows a Dockerben! Még mindig abszurdnak hangzik.
Az elszigeteltség fokai
A Windows-tárolók két elkülönítési módban futhatnak:
- Windows Server tárolók
- Hyper-V konténerek
Az első Windows módban a konténerek ugyanúgy viselkednek, mint az összes többi tároló a Dockerben: közös magot használnak az operációs rendszerrel, a tárolófolyamatok elszigeteltek, de továbbra is láthatók a gazdagép folyamatfán stb. Ez az alapértelmezett és a legtöbb gyors út futtassa a tárolót az ablakokon.
A második esetben a konténer egy speciális Hyper-V virtuális gépbe kerül. Ez persze rossz hatással van az indítási sebességre, de az elkülönítés teljes.
Következtetés
A Windows a Dockerben nagyszerű hír. Még ha nem is rohan a termékek konténerbe helyezésével, ez egy nagyszerű eszköz az egységtesztek, a gyártógépek, a demószerverek, a sandboxok elkülönítésére – mindenre, amihez korábban virtuális gépet kellett létrehoznia. Ha a Microsoftnak mégis sikerül nanoszervert futtatnia Linuxon, akkor megbocsátom nekik, hogy a közelmúltban leállt a két hónappal korábban meggondolatlanul megvásárolt Microsoft Band 2.
*A nix rendszerek natív módon valósítják meg a többfeladatos működést, és eszközöket kínálnak a folyamatok elkülönítésére és vezérlésére. Az olyan technológiák, mint a chroot(), amely a fájlrendszer szintjén biztosítja az elkülönítést, a FreeBSD Jail, amely korlátozza a kernelstruktúrákhoz való hozzáférést, az LXC és az OpenVZ, régóta ismertek és széles körben használtak. De a technológia fejlődésének lendülete a Docker volt, amely lehetővé tette az alkalmazások kényelmes elosztását. Ez most a Windowsba is eljutott.
Tárolók a Windows rendszeren
A modern szerverek túlságosan teljesítenek, és az alkalmazások néha még egy részét sem használják. Ennek eredményeként a rendszerek egy ideig „tétlenül” működnek, felmelegítve a levegőt. A megoldást a virtualizáció jelentette, amely lehetővé teszi több operációs rendszer futtatását egy szerveren, garantáltan megosztva azokat egymás között, és mindegyikhez megfelelő mennyiségű erőforrást rendelve. De a fejlődés nem áll meg. A következő szakasz a mikroszolgáltatások, amikor az alkalmazás minden része külön kerül telepítésre, önellátó komponensként, amely könnyen méretezhető a kívánt terhelésre és frissíthető. Az elkülönítés megakadályozza, hogy más alkalmazások megzavarják a mikroszolgáltatást. A Docker projekt megjelenésével, amely leegyszerűsítette az alkalmazások csomagolásának és szállításának folyamatát a környezettel együtt, a mikroszolgáltatások architektúrája további lendületet kapott a fejlesztésben.
A tárolók a virtualizáció egy másik típusa, amely külön környezetet biztosít az alkalmazások futtatásához, az úgynevezett OS virtualizációt. A konténerek egy izolált névtér használatával valósulnak meg, amely tartalmazza a munkához szükséges összes erőforrást (virtualizált neveket), amelyekkel interakcióba léphet (fájlok, hálózati portok, folyamatok stb.), és amelyen nem léphet túl. Vagyis az operációs rendszer csak azt mutatja a tárolónak, ami ki van választva. A konténerben lévő alkalmazás úgy gondolja, hogy ez az egyetlen, és minden korlátozás nélkül teljes értékű operációs rendszerben fut. Ha módosítani kell egy meglévő fájlt, vagy újat kell létrehozni, a konténer másolatokat kap a fő host operációs rendszertől, és csak a megváltozott részek marad meg. Ezért nagyon hatékony több tároló telepítése egyetlen gazdagépen.
A tárolók és a virtuális gépek közötti különbség az, hogy a konténerek nem töltik be saját másolataikat az operációs rendszerről, a könyvtárakról, a rendszerfájlokról stb. operációs rendszer mintha megosztanák a tárolóval. Az egyetlen további követelmény az alkalmazás tárolóban való futtatásához szükséges erőforrások. Ennek eredményeként a konténer pillanatok alatt elindul, és kevésbé terheli a rendszert, mint a virtuális gépek esetében. A Docker jelenleg 180 000 alkalmazást kínál a tárolóban, a formátumot pedig az Open Container Initiative (OCI) egységesíti. De a kerneltől való függés azt jelenti, hogy a konténerek nem működnek más operációs rendszerben. A Linux-tárolókhoz Linux API szükséges, így a Windows nem működik Linuxon.
Egészen a közelmúltig a Windows fejlesztői két virtualizációs technológiát kínáltak: a virtuális gépeket és a Server App-V virtuális alkalmazásokat. Mindegyiknek megvan a maga alkalmazási rése, előnyei és hátrányai. Most a kínálat szélesebb lett – a Windows Server 2016-ban megjelentek a konténerek (Windows Server Containers). És bár a TP4 idején a fejlesztés még nem fejeződött be, az új technológiát már most is működés közben látni és következtetéseket levonni. Megjegyzendő, hogy a felzárkózás és a kész technológiák birtokában az MS fejlesztői bizonyos kérdésekben kicsit tovább mentek, így a konténerek használata könnyebbé és sokoldalúbbá vált. A fő különbség az, hogy kétféle tárolót kínálnak: Windows és Hyper-V konténereket. A TP3-ban csak az elsők voltak elérhetőek.
A Windows-tárolók ugyanazt a kernelt használják, mint az operációs rendszer, amely dinamikusan meg van osztva egymás között. A terjesztési folyamatot (CPU, RAM, hálózat) az operációs rendszer veszi át. Opcionálisan korlátozhatja a tárolóhoz hozzárendelt maximálisan elérhető erőforrásokat. Az operációs rendszer fájlok és a futó szolgáltatások az egyes tárolók névteréhez vannak leképezve. Az ilyen típusú konténerek hatékonyan használják fel az erőforrásokat, csökkentik a többletköltséget, és ezáltal lehetővé teszik az alkalmazások sűrűbb elhelyezését. Ez a mód némileg a FreeBSD Jailre vagy a Linux OpenVZ-re emlékeztet.
A Hyper-V tárolók további szigetelési réteget biztosítanak a Hyper-V-vel. Minden tárolóhoz saját kernel és memória tartozik, az elkülönítést nem az operációs rendszer kernel, hanem a Hyper-V hypervisor végzi. Az eredmény a virtuális gépekkel azonos szintű elszigeteltség, kevesebb többletterheléssel, mint egy virtuális gép, de több, mint a Windows-tárolók. Az ilyen típusú tároló használatához telepítenie kell a Hyper-V szerepkört a gazdagépen. A Windows-tárolók alkalmasabbak megbízható környezetben való használatra, például amikor ugyanannak a szervezetnek az alkalmazásai futnak egy kiszolgálón. Ha egy szervert sok vállalat használ, és nagyobb elszigeteltségre van szükség, a Hyper-V konténerek valószínűleg értelmesebbek.
A Win 2016 konténereinek fontos jellemzője, hogy a típust nem a létrehozáskor, hanem a telepítéskor választják ki. Vagyis bármely konténer elindítható Windows és Hyper-V néven is.
A Win 2016-ban a konténerekért a Container Management verem absztrakciós réteg felel, amely az összes szükséges funkciót megvalósítja. A tároláshoz a VHDX merevlemez képformátumot használják. A tárolók, akárcsak a Docker esetében, képekként tárolódnak a tárolóban. Ráadásul mindegyik nem egy teljes adathalmazt ment el, hanem csak a létrehozott kép és az alapkép közötti különbségeket, és az indításkor minden szükséges adatot kivetít a memóriába. A Virtuális kapcsoló a tároló és a fizikai hálózat közötti hálózati forgalom kezelésére szolgál.
A tároló operációs rendszere Server Core vagy Nano Server lehet. Az első általában nem újdonság hosszú ideig, és biztosítja magas szint kompatibilitás a meglévő alkalmazásokkal. A második egy még lecsupaszítottabb, monitor nélküli verzió, amely lehetővé teszi a szerver futtatását a lehető legkisebb konfigurációban a Hyper-V, fájlszerver (SOFS) és felhőszolgáltatások használatához. A grafikus felület természetesen hiányzik. Csak a legszükségesebb komponenseket tartalmazza (.NET CoreCLR-rel, Hyper-V, Clustering és így tovább). De végül 93%-kal kevesebb helyet foglal el, és kevesebb kritikus javítást igényel.
Még egy érdekes pont. A tárolók kezeléséhez a hagyományos PowerShell mellett a Dockert is használhatja. És hogy lehetővé tegye a nem natív segédprogramok Win rendszeren való futtatását, az MS a Docker API és eszközkészlet kibővítésében társult. Minden fejlesztés nyitott és elérhető a Docker projekt hivatalos GitHubjában. A Docker-kezelési parancsok minden tárolóra vonatkoznak, mind a Win-, mind a Linux-tárolókra. Bár természetesen a Linuxon létrehozott konténer nem indítható el Windowson (és fordítva). Jelenleg a PowerShell funkcionalitása korlátozott, és csak a helyi tárolókkal való együttműködést teszi lehetővé.
Konténerek telepítése
Az Azure rendelkezik a szükséges Windows Server 2016 Core with Containers Tech Preview 4 lemezképével, amelyet telepíthet és használhat a tárolók felfedezéséhez. Ellenkező esetben mindent magának kell konfigurálnia. Helyi telepítéshez Win 2016 szükséges, és mivel a Win 2016-ban található Hyper-V támogatja a beágyazott virtualizációt (Nested virtualization), lehet fizikai vagy virtuális szerver is. Az alkatrész telepítésének folyamata szabványos. Válassza ki a megfelelő elemet a Szerepkörök és szolgáltatások hozzáadása varázslóban, vagy a PowerShell használatával adja ki a parancsot
PS>Install-WindowsFeature Containers
Ennek során a Virtual Switch hálózati vezérlő is telepítésre kerül, azt azonnal konfigurálni kell, különben a további műveletek hibát generálnak. Nézzük a hálózati adapterek nevét:
PS> Get-NetAdapter
A működéshez szükségünk van egy külső típusú vezérlőre. A New-VMSwitch parancsmag sok paraméterrel rendelkezik, de a példa kedvéért legyünk minimális beállításokkal:
PS> Új-VMSwitch -Név Külső -NetAdapterName Ethernet0
Ellenőrizzük:
PS> VMSwitch letöltése | ahol ($_.SwitchType –eq "Külső") 
A Windows tűzfal blokkolja a kapcsolatot a tárolóval. Ezért létre kell hoznia egy engedélyezési szabályt, legalább a PowerShell távoli távoli csatlakozásának lehetőségéhez, ehhez engedélyezzük a TCP / 80-at, és létrehozunk egy NAT-szabályt:
PS> Új-NetFirewallRule -Name "TCP80" -Megjelenítési név "HTTP on TCP/80" -Protokoll tcp -LocalPort 80 -Művelet Engedélyezés -Engedélyezve Igaz PS> Add-NetNatStaticMapping -NatName "ContainerNat" -NatName "ContainerNat" -0ternal.IPAddress0 -External.IPAddress0.0. Belső IP-cím 192.168.1.2 -InternalPort 80 -ExternalPort 80
Van egy másik egyszerű telepítési lehetőség. A fejlesztők elkészítettek egy szkriptet, amely lehetővé teszi az összes függőség automatikus telepítését és a gazdagép konfigurálását. Használhatja, ha akarja. A szkripten belüli paraméterek segítenek megérteni az összes mechanizmust:
PS> https://aka.ms/tp4/Install-ContainerHost -OutFile C:\Install-ContainerHost.ps1 PS> C:\Install-ContainerHost.ps1
Van egy másik lehetőség - egy kész virtuális gép telepítése konténer támogatással. Ehhez ugyanazon az erőforráson van egy szkript, amely automatikusan végrehajtja az összeset kívánt műveleteket. részletes utasításokat szerepel az MSDN-en. Töltse le és futtassa a szkriptet:
PS> wget -uri https://aka.ms/tp4/New-ContainerHost -OutFile c:\New-ContainerHost.ps1 PS> C:\New-ContainerHost.ps1 –VmName WinContainer -WindowsImage ServerDatacenterCore 
A név tetszőleges, a -WindowsImage pedig a készülő kép típusát jelzi. A lehetőségek a következők lehetnek: NanoServer, ServerDatacenter. A Docker is azonnal telepítésre kerül, hiányáért vagy jelenlétéért a SkipDocker és IncludeDocker paraméter felelős. Az indítás után megkezdődik a kép betöltése és konvertálása, a folyamat során meg kell adnia egy jelszót a virtuális gépbe való belépéshez. Maga az ISO fájl elég nagy, majdnem 5 GB. Ha a csatorna lassú, a fájl letölthető egy másik számítógépre, majd átnevezhető WindowsServerTP4-re, és átmásolható a C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks mappába. A telepített virtuális gépre az összeállítás során beállított jelszó megadásával tudunk bejelentkezni, és dolgozni.
Most már közvetlenül a konténerek használatához léphet.
Konténerek használata PowerShell-lel
A Containers modul 32 PowerShell-parancsmagot tartalmaz, amelyek egy részének dokumentációja még mindig hiányos, bár általában elegendő ahhoz, hogy minden működjön. A lista könnyen elérhető:
PS> Get-Command -modul Containers 
Az elérhető képek listáját a Get-ContainerImage parancsmag segítségével kaphatja meg, tárolók - Get-Container. Tároló esetén az Állapot oszlopban az aktuális állapota látható: leállt vagy fut. De amíg a technológia fejlesztés alatt áll, az MS nem biztosított tárolót, és ahogy említettük, míg a PowerShell egy helyi tárhellyel dolgozik, ezért Önnek kell létrehoznia a kísérletekhez.
Tehát van egy szerverünk támogatással, most már magukra a konténerekre van szükségünk. Ehhez beállítjuk a ContainerProvider csomagszolgáltatót.
Továbbra is csak a tagok számára elérhető
1. lehetőség: Csatlakozzon a "webhely" közösséghez, hogy elolvassa az oldalon található összes anyagot
A meghatározott időszakban a közösséghez való tagság hozzáférést biztosít az ÖSSZES Hacker anyaghoz, növeli a személyes kumulatív kedvezményt, és lehetővé teszi, hogy professzionális Xakep Score értékelést gyűjtsön!
