Ja jūs nākat no izstrādes vai "nopietnās" datorzinātnes pasaules, ļoti iespējams, ka konteineri operētājsistēmā Windows Tie varētu izklausīties pēc kaut kā pa vidu starp maģiju un mārketingu. Un, ja jums ir bijušas grūtības ar portiem, SSL sertifikātiem vai izvietojumiem, kas neizdodas operētājsistēmā Linux, bet darbojas jūsu Windows datorā, ir normāli domāt, vai visas šīs runas par... Docker operētājsistēmā WindowsKubernetes un līdzīgas tehnoloģijas patiešām ir jēgpilnas Microsoft vidē.
Realitāte ir tāda, ka Konteineri operētājsistēmā Windows ir daudz jēgpilnāki, nekā šķiet.Taču tie ne vienmēr ir piemēroti katrai situācijai vai scenārijam. Šajā rakstā mēs tuvāk aplūkosim, kas ir konteineri (nejaucot tos ar virtuālajām mašīnām), kā tie tieši darbojas operētājsistēmā Windows, to priekšrocības un trūkumus salīdzinājumā ar virtuālajām mašīnām, to lomu izstrādes, ražošanas un OT/PLC vidē, kā arī to, kad ir vērts tos izmantot… un kad varētu būt labāk pieturēties pie vecajām metodēm.
Kas īsti ir konteiners (arī operētājsistēmā Windows)?
Konteiners būtībā ir viegls, izolēts programmatūras pakotne Tajā ir iekļauta lietojumprogramma un viss nepieciešamais tās darbībai: bibliotēkas, atkarības, konfigurācija, lietotāja režīma sistēmas faili utt. Tā vietā, lai pārnēsātu pilnīgu operētājsistēmu, piemēram, virtuālo mašīnu, tā koplieto resursdatora operētājsistēmas kodolu.
Jūs varētu iedomāties konteineru kā kaste ļoti labi noslēgta Tas atklāj tikai to, kas ir absolūti nepieciešams. Iekšpusē jūs ievietojat savu lietojumprogrammu (piemēram, Icecast serveri, SCADA sistēmu vai .NET API), kā arī precīzas bibliotēkas un rīkus, kas tai nepieciešami. No ārpuses šī kaste darbojas kā autonoma mini sistēma, bet patiesībā tā ir atkarīga no pamatā esošā Windows vai Linux kodola.
Sistēmā Windows konteineri darbojas, izmantojot sistēmā integrēta konteinera funkcionalitāte (Windows Server 2016 vai jaunāka versija, kā arī Windows 10/11, sākot no versijas 1607, izstrādei). Tas nozīmē, ka varat palaist Windows konteinerus lokāli operētājsistēmā Windows Server.
Izstrādātājam vai administratoram galvenais ir tas, ka konteiners piedāvā paredzama un atkārtojama videKas darbojas jūsu klēpjdatorā, darbosies tāpat arī serverī, mākonī vai perifērijā, jo viss pārvietojas vienā un tajā pašā attēlā.
Windows sistēmās šī iespēja ir īpaši noderīga .NET Framework lietojumprogrammām, .NET lietojumprogrammām, Windows Server pakalpojumiem vai mantotai programmatūrai, kuru vēlaties izolēt, iesaiņot un pārvietot, katru reizi nepārkonfigurējot pusi sistēmas.
Kā konteineri iederas Microsoft ekosistēmā
Microsoft ir uztvēris šo problēmu ļoti nopietni un piedāvā diezgan pilnīga ekosistēma strādāt ar konteineriem gan Windows, gan Linux vidē, aptverot visu, sākot no lokālas izstrādes līdz masveida izvietošanai mākonī.
Izstrādes sadaļā jūs varat Palaidiet konteinerus operētājsistēmā Windows 10/11 Izmantojot Docker Desktop, kas izmanto Windows konteineru funkcionalitāti vai WSL2 operētājsistēmai Linux, varat ērti palaist konteinerizētus pakalpojumus savā darba datorā testēšanai, atkļūdošanai un attēlu sagatavošanai.
Līdzīgi rīki Visual Studio un Visual Studio kods Viņiem ir iebūvēts Docker atbalsts, administrēšana ar Docker ComposeKubernetes un Helm. Tas ļauj projektam pievienot Dockerfile failu, atkļūdot konteinerā vai diezgan vienkārši ģenerēt nepieciešamās definīcijas izvietošanai Kubernetes klasteros.
Kad pieteikums ir iepakots, varat Publicēt konteinera attēlus žurnālāŠeit noder Docker Hub (publiskie) vai privātie reģistri, piemēram, Azure Container Registry (ACR), kur jūsu organizācija kontrolē, kas augšupielādē, kas lejupielādē un kuras versijas tiek izmantotas katrā vidē, kā arī to, kā. izvietot konteinerus attālos serveros.
Runājot par liela mēroga izvietošanu, galvenais elements ir Azure Kubernetes pakalpojums (AKS)Tas ļauj jums vadīt desmitiem, simtiem vai tūkstošiem konteineru Azure virtuālajās mašīnās neatkarīgi no tā, vai tie ir pielāgoti Windows serveri vai Linux distribūcijas, piemēram, Ubuntu. Jums ir arī hibrīdas iespējas ar Azure Arc, AKS Azure Stack Hub platformā vai integrācijas ar OpenShift lokālajā vidē.
Lokāli, ja nevēlaties paļauties uz Azure, tas ir pilnīgi iespējams. veidot Kubernetes operētājsistēmā Windows Server vai nu patstāvīgi, vai arī izmantojiet citas platformas, kuras atbalsta vai integrē Microsoft, piemēram, Red Hat OpenShift ar Windows konteineru atbalstu.
Kā konteineri darbojas iekšēji operētājsistēmā Windows
Windows konteiners būtībā ir process vai procesu kopums kas darbojas virs resursdatora operētājsistēmas kodola. Bet (tas ir svarīgi) ar izolētu sistēmas skatu. Šis "filtrētais skats" attiecas uz failu sistēmu, reģistru, tīklu un citiem resursiem.
Interesanti ir tas, ka konteiners Tam nav tiešas un neierobežotas piekļuves kodolam.Lai gan tas to koplieto, tas redz virtualizētu (slāņotu) failu sistēmu, izolētu reģistru un resursus, ko konteinera dzinējs attēlo tā, it kā tie būtu "savus". Taču patiesībā tos pārvalda resursdators.
Izmaiņas, ko veicat darbojošā konteinerā, tiek piemērotas a īslaicīgs rakstīšanas slānisKad konteiners izslēdzas, šo slāni var atmest, atgriežot sistēmu sākotnējā attēla stāvoklī. Ja vēlaties patiesi saglabāt datus, varat pievienot ārējos sējumus vai krātuves resursus (diskus, SMB koplietojumus, Azure failus utt.).
Microsoft piedāvā vairākus oficiālie bāzes attēli Windows veidnes, uz kurām veidot konteinerus:
- WindowsLiels attēls ar gandrīz visiem Windows API un pakalpojumiem (bez servera lomām).
- Windows ServerLīdzīgi, bet paredzēti serveru scenārijiem ar pilnu Windows Server API un lomu komplektu.
- Windows Server CoreSamazināta versija ar mazāk vietas, bet ietver pilnu .NET Framework un lielāko daļu servera lomu.
- Nano serverisĪpaši viegls attēls, optimizēts .NET un noteiktām specifiskām lomām, ideāli piemērots, ja vēlaties samazināt izmēru un uzbrukuma virsmu.
Šie attēli ir veidoti sakrauti slāņiViens slānis var saturēt bāzes sistēmu, cits — .NET izpildlaiku, vēl viens — jūsu koplietojamās bibliotēkas un vēl viens — jūsu pašu lietojumprogrammu. Ja vairākas lietotnes koplieto šo slāņu daļas, resursdators tās lejupielādē un saglabā tikai vienu reizi, ietaupot daudz vietas un laika.
Galvenās konteineru izmantošanas priekšrocības operētājsistēmā Windows
Ikdienas darbībās konteineri piedāvā konkrētas priekšrocības izstrādātājiem, sistēmu administratoriem un drošības komandām, īpaši, ja vide griežas ap Windows.
Izstrādātājiem: viena un tā pati lietotne, viena un tā pati darbība visur
No attīstības viedokļa konteineru lielākā priekšrocība ir tā, ka vide pārstāj būt mainīgaJūs izveidojat attēlu ar precīzu .NET versiju, nepieciešamajiem DLL, palīgrīkiem, IIS vai Kestrel konfigurāciju utt., un šis attēls tiek izvietots vienādi visās vidēs.
Tas ievērojami samazina klasiskās problēmas, kas rodas, kad "tas darbojas manā datorā, bet ne serverī". Turklāt katrs izstrādātājs var Izveidojiet pilnīgu vidi dažu sekunžu laikā neiznīcinot jūsu Windows: datubāzes, rindas, palīgpakalpojumus... Viss izolētos konteineros, kurus var iznīcināt un atjaunot bez bailēm.
Projektos, kuros daļa no steka darbojas operētājsistēmā Linux (piemēram, Node.js mikropakalpojumi vai datubāzes konteineri), bet otra daļa — operētājsistēmā Windows (pakalpojumi, kas ir atkarīgi no konkrētiem API), visu var koordinēt no vienas un tās pašas iekārtas. docker-compose vai Kubernetes manifestssaglabājot versiju un portu konsekvenci.
IT komandām: labāka aparatūras izmantošana un mazāks haoss
Administratoriem konteineri ļauj palielināt lietošanas blīvumu Windows serveros, tā vietā, lai katrai lietojumprogrammai būtu viena virtuālā mašīna (ar pilnu operētājsistēmu un ielāpiem), daudzas konteinerizētas lietojumprogrammas var būt mazākā skaitā resursdatoru vai virtuālo mašīnu, pārvaldot attēlus, nevis atsevišķas instalācijas.
Arī atjauninājumi maina savu pieeju. Tā vietā, lai ietu katrā serverī, lai modificētu bināros failus vai ielāpus, tie ir Izveidojiet jaunu attēlu ar izmaiņām (jauns kods vai atjaunināta bibliotēka) tiek nosūtīts uz reģistru un izvietots, atstājot iepriekšējo pieejamu atritei, ja rodas problēmas.
Vidēs, kur iepriekš bija desmitiem mašīnu ar Windows ir novecojis, "jo tas darbojas"Migrācija uz labi izstrādātiem konteineriem ļauj izolēt šīs lietojumprogrammas un pakāpeniski pārvietot tās uz modernākām bāzēm, vienlaikus saglabājot lielāku centralizētu kontroli.
Drošībai: izolācija, minimāla virsmas platība un centrālā vadība
Konteineru drošība nav ne automātiska, ne perfekta, taču tā piedāvā ļoti spēcīgus rīkus, ja tos izmanto pareizi. Pirmkārt, katrs konteiners darbojas ar ierobežotas atļaujas un izolēti resursiTas samazina ielaušanās ietekmi, salīdzinot ar lietojumprogrammu, kas darbojas tieši resursdatora sistēmā.
Kubernetes klasteros vidi var segmentēt pēc vārdtelpas un tīkla politikaslai dažādi pakalpojumi sazinātos savā starpā tikai tad, ja tas ir skaidri atļauts. Tas labi atbilst tādiem principiem kā "vismazākās privilēģijas" un "Nulles uzticēšanās Windows Server"Īpaši interesanti pagarinājuma scenārijos."
Ir arī vieglāk ieviest piegādes ķēdes drošības ciklsJūs skenējat reģistra attēlus, lai noteiktu ievainojamības, pieprasāt, lai visi attēli būtu no parakstītiem avotiem, kontrolējat izpildlaika konfigurāciju (privilēģijas, pievienojumus, iespējas utt.) un lietojat ielāpus, atjaunojot attēlus, nevis manuāli pieskaroties tiešsaistes sistēmām.
Kad Windows slikti pārvalda resursus... bet jūs joprojām izmantojat konteinerus.
Daudziem cilvēkiem ir uzskats (dažos gadījumos diezgan pamatots), ka Windows nav efektivitātes karalis resursu patēriņa ziņā. Īpaši salīdzinājumā ar serverim optimizētām Linux distribūcijām. Tas noved pie loģiska jautājuma: kāpēc sarežģīt lietas ar Windows konteineriem, ja man jau ir virtuālās mašīnas vai ja es varētu visu vienkārši pārvietot uz Linux?
Ir vairāki iemesli, kāpēc pat pieņemot šos ierobežojumus, Windows konteineri var būt jēgpilni:
- Lietojumprogrammas, kas cieši saistītas ar WindowsDaudzus uzņēmumu risinājumus, COM+ komponentus, pakalpojumus, kas izmanto operētājsistēmai Windows paredzētus API, vai mantotas .NET Framework lietojumprogrammas nevar viegli migrēt uz Linux.
- Standartizēta biznesa videOrganizācijas, kuru visa darbība ir balstīta uz Active Directory, GPO, uzraudzības un dublēšanas rīkiem, kas izstrādāti operētājsistēmai Windows.
- Komandas ar pieredzi Microsoft tehnoloģijāsIT darbinieki labāk pārzina Windows Server, Hyper-V un Microsoft rīkus, nekā tikai Linux klasteru pārvaldību.
Šajās situācijās, konteinerizēt operētājsistēmā Windows Tas nodrošina lielāku konsekvenci, ātrāku izvietošanu, pārnesamību un automatizāciju, pat ja bāzes resursdators nav pasaulē vieglākais. Pēc tam vienmēr var optimizēt, izmantojot Nano Server vai Server Core attēlus un skaņas resursu politikas.
Tīkls, porti, IP adreses un SSL Windows konteineros
Viena no pirmajām galvassāpēm, kas rodas, sākot darbu ar konteineriem, ir izpratne Kā tiek pārvaldītas ostas un IP adreses veselīga tīkla infrastruktūraJa kādreiz esat cīnījies, mēģinot palaist vairākus pakalpojumus vienās un tajās pašās pieslēgvietās vai konfigurēt HTTPS ar konteineriem, tas jums šķitīs pazīstami.
Pēc noklusējuma katram konteineram ir savs sava izolēta tīkla telpaIekšēji tas var klausīties 80., 443., 8000. portos… it kā tas būtu viens pats. Knifs ir tāds, ka konteineru dzinējs vai orķestrators apstrādā šo iekšējo portu kartēšanu uz resursdatora portiem vai virtuālajiem pakalpojumiem klasterī.
Tas nozīmē, ka Pakalpojumam nav nepieciešams Raspberry Pi. tikai tāpēc, ka visi vēlas izmantot 80. portu. Jums var būt vairāki konteineri, kas iekšēji klausās 80. portā, un katru no tiem var piesaistīt citam resursdatora portam (piemēram, 8081, 8082…) vai arī paslēpt tos aiz apgrieztā starpniekservera vai Ingress, kas darbojas kā vienotā priekšējā daļa.
Attiecībā uz IP adresēšanu vienkāršos scenārijos katrs konteiners saņem vienu virtuālā tīkla iekšējā IP adrese kas pārvalda Docker vai Kubernetes. Sarežģītākās vidēs tiek izmantoti CNI spraudņi un pārklājuma tīkli, lai konteineri varētu konsekventi redzēt viens otru vairākos mezglos.
In Cuanto al SSL/TLS šifrēšanaVisizplatītākā pieeja ir izvairīties no sertifikātu atsevišķas pārvaldības katrā konteinerā, tā vietā centralizējot tos priekšējā galā: apgrieztā starpniekservera, piemēram, Nginx, Traefik, HAProxy, vai operētājsistēmās Windows, IIS vai Application Gateway pakalpojumā Azure. Šis priekšējā galā pārtrauc HTTPS un pārsūta datplūsmu uz konteineriem, izmantojot iekšējo HTTP. Sertifikātus var arī pievienot konteineriem, taču tas sarežģī pārvaldību un atjaunošanu.
Konteineri un OT/PLC: reālas pārmaiņas vai IT fantāzija?
Rūpnieciskās automatizācijas un PLC pasaulē situācija parasti ir diezgan atšķirīga no tradicionālajiem datu centriem. Bieži var konstatēt Industriālie HMI un datori ar vecākām Windows versijāmDraiveri, kas ir cieši saistīti ar konkrētu aparatūru, sistēmām, kurām gadiem ilgi nav atjaunināti ielāpi, un arhitektūrām, kas izstrādātas pēc principa "ja tas nav salūzis, nelabo to".
No programmatūras viedokļa Kubernetes, perifērijas skaitļošanas un konteineru solījums izklausās pievilcīgs: aparatūras neatkarība, augsta pieejamība, pašatjaunošanās, homogēnas izvietošanas un aizsardzības arhitektūras, kas tuvojas "nulles uzticēšanās" līmenim. Problēma ir tā, ka realitātē ir citi ierobežojumi.
Vai var uz konteineru bāzes veidota perimetra arhitektūra Palīdzība? Atbilde, pamatojoties uz daudzu pilotprojektu un projektu pieredzi, parasti ir "jā, bet". Jā, jo:
- Tas ļauj iekapsulēt mantotas OT lietojumprogrammas, samazinot to tiešo iedarbību uz tīklu.
- Tas atvieglo datu vārteju, apkopotāju, historizācijas pakalpojumu vai analītikas izvietošanu tuvu iekārtai.
- Tas nodrošina augstu pieejamību un pašremontēšanas iespējas komponentiem, kas nav kritiski svarīgi cilvēku vai iekārtas drošībai.
Un "bet" tāpēc, ka pievieno sarežģītības slāņusIr jāapmāca komandas, jāpārvalda klasteri, nepieciešama integrācija ar ļoti ierobežotiem OT tīkliem un jāpastāv līdzās PLC pakalpojumu sniedzējiem, kas, iespējams, oficiāli neatbalsta šīs arhitektūras.
No rūpnieciskās kiberdrošības viedokļa šāda veida arhitektūra arvien vairāk tiek uzskatīta par saprātīgs solis ceļā uz lielāku izolāciju un kontroliAr nosacījumu, ka tiek ievērota tīkla segmentācija, katrā mezglā palaistās darbības ir stingri ierobežotas un tiek uzturēta stingra koordinācija starp OT un IT.
Virtuālās mašīnas salīdzinājumā ar konteineriem: kuru izmantot katrā gadījumā
Uz mūžseno jautājumu “konteineri vai virtuālās mašīnas?” nav vienas atbildes. Parasti beigās izmantosiet Abas tehnoloģijas atkarībā no vajadzībām.
Ja jums ir nepieciešams skriet dažādas pilnīgas operētājsistēmas Vienlaikus, lai pēc iespējas izolētu darba slodzi normatīvo prasību dēļ vai palaistu programmatūru, kas pieņem, ka tai ir pilnīga sistēmas kontrole, virtuālā mašīna joprojām ir labākā izvēle. Tā ir arī labākā izvēle, ja vēlaties ļoti spēcīgu atdalīšanu starp dažādiem nomniekiem vai klientiem.
Ja tas, ko meklējat, ir izvietošanas ātrums, mērogojamība un efektīva resursu izmantošanaUn, ja jūsu lietojumprogrammas var ērti darboties vienā un tajā pašā operētājsistēmu saimē (piemēram, vairākas .NET lietotnes operētājsistēmā Windows Server), tad konteineri ir nepārprotami pievilcīgāka iespēja.
Daudzās uzņēmumu vidēs ir sastopams hibrīda modelis: virtuālie serveri (Hyper-V, VMware vai mākonī), kas kalpo kā mezgli konteineru klasterī. Virs šīm virtuālajām mašīnām tiek izvietots Kubernetes, Docker Swarm vai cits orķestrators, un no turienes visas jaunās vai jauninātās lietotnes tiek iesaiņotas konteineros.
Windows izstrāde un Linux ieviešana: realitātes sadursme
Ļoti izplatīta problēma, īpaši komandās, kas izstrādā programmatūru operētājsistēmā Windows un izvieto to Linux (konteinerā vai serverī), ir atšķirība failu sistēmāWindows parasti apstrādā failu nosaukumus kā reģistrnejutīgus, savukārt Linux Fails.ts y fails.ts Tās ir dažādas lietas.
Tas noved pie dažām patiešām nepatīkamām kļūdām. Piemēram, imports kodā, kas darbojas lokāli (jo Windows ignorē lielo burtu lietošanutaču tie avarē Linux konteinerā, jo faktiskajam faila nosaukumam ir cits burts. Šī ir klasiska problēma tādos stekos kā TypeScript, Node, modernās frontend sistēmas utt.
Vienīgais veids, kā no tā patiesi izvairīties, ir adoptēt skaidras un stingras nosaukumu konvencijas jau no projekta sākuma (piemēram, viss, kas iekļauts konsekventajā kebab-case vai camelCase) un pastiprināt to ar automatizētiem rīkiem: linteriem, CI validācijām, kas veic testus Linux vidē, koda pārskatiem, kas pārbauda reģistrjutīgus ceļus.
Uzņēmumi, kas nopietni uztver koda kvalitāti, parasti iekļauj šīs kontroles CI/CD ķēdē, lai visas lielo burtu kļūdas, nepareizi uzrakstīti ceļi vai nederīgas atkarības tiktu atzīmētas pirms nonākšanas ražošanā. Tas ir vēl jo svarīgāk, ja galīgā izvietošana ir konteinersjo tieši tur kļūst pamanāmas visas šīs pamatā esošās operētājsistēmas detaļas.
Turklāt atkarību, izpildlaika versiju un videi specifisko konfigurāciju pārvaldība kļūst kritiski svarīga, sākot darbu ar mākonis, mākslīgais intelekts un pārvaldītie pakalpojumi (AWS, Azure utt.), kur infrastruktūra ir viendabīgāka un mazāk toleranta pret tipiskiem Windows darbvirsmas "trikiem".
Galvenie un alternatīvie rīki konteineru pasaulē
Lai gan Docker un Kubernetes ir kļuvuši par faktisko standartu, konteineru ekosistēma ir plaša un piedāvā daudzas iespējas dažādiem sarežģītības līmeņiem un vajadzībām.
Docker: gandrīz visa pamats
Docker popularizēja mūsdienīgu veidu, kā strādāt ar konteineriem, un joprojām ir šī metode. vārteja lielākajai daļai iekārtuAr Docker Engine jūs palaižat un pārvaldāt konteinerus. Ar Dockerfile jūs deklaratīvi definējat, kā veidot attēlus. Visbeidzot, ar Docker Hub vai privātiem reģistriem jūs kopīgojat šos attēlus ar citām vidēm vai komandām.
Windows vidēs Docker ir īpaši noderīgs izveidot reproducējamas izstrādes vides, samaziniet “Frankenšteina instalācijas” serveros un izveidojiet stabilu pamatu, lai vēlāk varētu paplašināt iespējas sarežģītākiem orķestrēšanas risinājumiem.
Kubernetes: orķestrēšana plašā mērogā
Kad lietojumprogramma sāk izmantot vairākus pakalpojumus, datubāzes, rindas, front-end un citus konteinerizētus komponentus, ir tikai laika jautājums, kad jums būs nepieciešams orķestrisKubernetes (K8s) ir visplašāk izmantotā atvērtā pirmkoda platforma konteineru izvietošanas, mērogošanas un pārvaldības automatizēšanai.
Kubernetes vidē jūs grupējat saistītus konteinerus pākstisJūs definējat izvietojumus, kas norāda, cik repliku vēlaties katram pakalpojumam, un jūs šīs vienības publiskojat, izmantojot tīkla pakalpojumus. Vadības plakne apstrādā slodzes līdzsvarošanu starp darba mezgliem, uzrauga instanču stāvokli, restartē tās kļūmes gadījumā un mērogošanu atbilstoši pieprasījumam.
Hibrīda un mākoņvidē tādas platformas kā AKS (Azure Kubernetes Service), GKE (Google Kubernetes Engine) vai EKS (Amazon Elastic Kubernetes Service) vienkāršo pārvaldīto Kubernetes izvietošanu. Tas ļauj koncentrēties uz lietojumprogrammām, atstājot daļu klasteru pārvaldības pakalpojumu sniedzēja ziņā.
Citi rīki un alternatīvas
Papildus Docker un Kubernetes ir arī citi risinājumi, kas aptver īpašas vajadzības vai arhitektūras preferences:
- PodmansLīdzīgi kā Docker, bet bez centrālā dēmona; ļoti novērtēts dažās Linux vidēs.
- KonteinersKonteineru dzinējs, uz kuru paļaujas Docker; to var izmantot atsevišķi.
- openshiftRed Hat Kubernetes platforma ar daudzām papildu funkcijām uzņēmumu attīstībai un darbībai.
- KlejotājuDažos gadījumos HashiCorp orķestrators ir vienkāršāk lietojams nekā Kubernetes, un tas spēj pārvaldīt tradicionālos konteinerus un lietderīgās slodzes.
- LXD"Pilnas sistēmas" tipa konteineri operētājsistēmā Linux, kas ir noderīgi, ja vēlaties kaut ko starp klasisko konteineru un vieglu virtuālo mašīnu.
- VagrantTas nav balstīts uz konteineriem, taču joprojām ir noderīgs reproducējamu izstrādes vides iestatīšanai ar virtuālajām mašīnām vai pat apvienojumā ar Docker.
Viss šis ceļojums padara to tādu, ka, kad tu sev jautā, vai Konteineriem operētājsistēmā Windows ir jēgaAtbilde mazāk ir atkarīga no pašas tehnoloģijas un vairāk no tā, vai tā atbilst jūsu lietojumprogrammām, komandai un darbības modelim. Daudzos gadījumos konteinerizācija ir labākais veids, kā panākt ievērojamu izvietošanas, pārnesamības un drošības uzlabojumu, neatstājoties no Windows ekosistēmas. Citos gadījumos varētu būt saprātīgāk pieturēties pie tradicionālajām virtuālajām mašīnām vai izvēlēties tieši Linux. Svarīgi ir labi izprast komponentus, lai pieņemtu pamatotus lēmumus par to, kad, kā un kur ir vērts konteinerizēt.