Jos tulet kehitysmaailmasta tai "hardcore"-tietojenkäsittelytieteen maailmasta, on hyvin todennäköistä, että säilöt Windowsissa Ne saattavat kuulostaa taikuuden ja markkinoinnin välimaastolta. Ja jos olet myös kamppaillut porttien, SSL-varmenteiden tai käyttöönottojen kanssa, jotka epäonnistuvat Linuxissa, mutta toimivat Windows-tietokoneellasi, on normaalia miettiä, onko kaikki tämä puhe... Docker WindowsissaKubernetes ja vastaavat teknologiat ovat todella järkeviä Microsoft-ympäristössä.
Todellisuudessa Windowsin säilöt ovat paljon järkevämpiä kuin miltä näyttää.Mutta ne eivät aina sovi kaikkiin tilanteisiin tai skenaarioihin. Tässä artikkelissa tarkastelemme lähemmin, mitä kontit ovat (sekoittamatta niitä virtuaalikoneihin), miten ne erityisesti toimivat Windowsissa, niiden etuja ja haittoja verrattuna virtuaalikoneihin, niiden roolia kehitys-, tuotanto- ja OT/PLC-ympäristöissä sekä milloin niitä kannattaa käyttää... ja milloin voi olla parempi pitäytyä vanhoissa tavoissa.
Mikä tarkalleen ottaen on säilö (myös Windowsissa)?
Säiliö on pohjimmiltaan ns. kevyt, eristetty ohjelmistopaketti Se sisältää sovelluksen ja kaiken sen suorittamiseen tarvittavan: kirjastot, riippuvuudet, kokoonpanon, käyttäjätilan järjestelmätiedostot jne. Sen sijaan, että se kantaisi mukanaan täydellistä käyttöjärjestelmää kuten virtuaalikone, se jakaa isäntäkäyttöjärjestelmän ytimen.
Voit kuvitella säiliön ns. laatikko erittäin hyvin suljettu Se paljastaa vain ehdottoman välttämättömän. Sisälle sijoitat sovelluksesi (esimerkiksi Icecast-palvelimen, SCADA-järjestelmän tai .NET-rajapinnan) sekä sen tarvitsemat kirjastot ja työkalut. Ulkopuolelta tämä laatikko toimii kuin itsenäinen minijärjestelmä, mutta todellisuudessa se on riippuvainen alla olevasta Windows- tai Linux-ytimestä.
Windowsissa säilöt toimivat hyödyntämällä järjestelmään integroitu konttitoiminto (Windows Server 2016 tai uudempi ja Windows 10/11 versiosta 1607 alkaen kehityskäyttöön). Tämä tarkoittaa, että voit suorittaa Windows-säilöjä natiivisti Windows Serverissä.
Kehittäjän tai ylläpitäjän kannalta tärkeintä on, että säilö tarjoaa ennustettava ja toistettavissa oleva ympäristöSe, mikä toimii kannettavalla tietokoneellasi, toimii samalla tavalla palvelimella, pilvessä tai reunalla, koska kaikki kulkee pakattuna samaan kuvaan.
Windows-järjestelmissä tämä ominaisuus on erityisen hyödyllinen .NET Framework -sovelluksille, .NET-sovelluksille, Windows Server -palveluille tai vanhoille ohjelmistoille, jotka haluat eristää, pakata ja siirtää ilman, että puolta järjestelmää tarvitsee määrittää uudelleen joka kerta.
Miten kontit sopivat Microsoftin ekosysteemiin
Microsoft on ottanut tämän ongelman erittäin vakavasti ja tarjoaa melko täydellinen ekosysteemi työskennellä sekä Windows- että Linux-konttien kanssa, kattaen kaiken paikallisesta kehityksestä massiiviseen käyttöönottoon pilvessä.
Kehitysosiossa voit Suorita säilöt Windows 10/11:ssä Docker Desktopin, joka hyödyntää Windowsin säilötoimintoja, tai WSL2:n Linux-version avulla voit helposti suorittaa säilöpalveluita työtietokoneellasi testausta, virheenkorjausta ja levykuvan valmistelua varten.
Työkalut kuten Visual Studio ja Visual Studio -koodi Niillä on sisäänrakennettu tuki Dockerille, hallinta Docker Composen avullaKubernetes ja Helm. Näiden avulla voit lisätä Dockerfile-tiedoston projektiin, debugata säilön sisällä tai luoda tarvittavat määritelmät Kubernetes-klustereissa käyttöönottoa varten melko helposti.
Kun olet pakannut hakemuksesi, voit julkaise säilön kuvat lokissaTässä kohtaa Docker Hub (julkinen) tai yksityiset rekisterit, kuten Azure Container Registry (ACR), tulevat mukaan kuvaan, sillä organisaatiosi hallitsee, kuka lataa ja mitä versioita kussakin ympäristössä käytetään ja miten. ota säilöt käyttöön etäpalvelimilla.
Laajamittainen käyttöönotto on avainasemassa Azure Kubernetes -palvelu (AKS)Näin voit hallita kymmeniä, satoja tai tuhansia säilöjä Azure-virtuaalikoneissa, olivatpa ne sitten mukautettuja Windows-palvelimia tai Linux-jakeluja, kuten Ubuntu. Käytettävissäsi on myös hybridivaihtoehtoja Azure Arcin, AKS:n Azure Stack Hubissa tai integraatioita OpenShiftin kanssa paikallisissa ympäristöissä.
Paikallisesti, jos et halua luottaa Azureen, se on täysin mahdollista. Kubernetesin rakentaminen Windows Serverille joko itsenäisesti tai käytä muita Microsoftin tukemia tai integroimia alustoja, kuten Red Hat OpenShiftiä Windows-konttituella.
Kuinka säilöt toimivat sisäisesti Windowsissa
Windows-kontti on pohjimmiltaan prosessi tai prosessien joukko jotka toimivat isäntäkäyttöjärjestelmän ytimen päällä. Mutta (tämä on tärkeää) järjestelmän erillisellä näkymällä. Tämä "suodatettu näkymä" koskee tiedostojärjestelmää, rekisteriä, verkkoa ja muita resursseja.
Mielenkiintoinen asia on, että säiliö Sillä ei ole suoraa ja rajoittamatonta pääsyä ytimeen.Vaikka se jakaa sen, se näkee virtualisoidun (kerrostetun) tiedostojärjestelmän, eristetyn rekisterin ja resurssit, jotka säilömoottori esittää ikään kuin ne olisivat "omiaan". Mutta todellisuudessa niitä hallinnoi isäntä.
Käynnissä olevan säilön sisällä tekemäsi muutokset otetaan käyttöön lyhytaikainen kirjoituskerrosKun säilö sammutetaan, kyseinen kerros voidaan hylätä, jolloin järjestelmä palaa alkuperäiseen levykuvan tilaan. Jos haluat todella säilyttää tiedot, voit liittää ulkoisia levyasemia tai tallennusresursseja (levyjä, SMB-jakoja, Azure Files -tiedostoja jne.).
Microsoft tarjoaa useita viralliset peruskuvat Windows-mallit, joille voit rakentaa säilöt:
- WindowsSuuri kuva, jossa on lähes kaikki Windows-rajapinnat ja -palvelut (ilman palvelinrooleja).
- Windows ServerSamankaltainen, mutta suunniteltu palvelinskenaarioihin, joissa on kaikki Windows Serverin API-rajapinnat ja roolit.
- Windows Server CorePienennetty versio, jossa on vähemmän tilaa, mutta joka sisältää täyden .NET Frameworkin ja useimmat palvelinroolit.
- Nano-palvelinErittäin kevyt levykuva, optimoitu .NETille ja tietyille rooleille, ihanteellinen, kun haluat minimoida koon ja hyökkäyspinnan.
Nämä kuvat on rakennettu pinotut kerroksetYksi kerros voi sisältää perusjärjestelmän, toinen .NET-ajonaikaisen ympäristön, kolmas yhteiset kirjastosi ja lopuksi oman sovelluksesi. Jos useat sovellukset jakavat osia näistä tasoista, isäntä lataa ja tallentaa ne vain kerran, mikä säästää paljon tilaa ja aikaa.
Säiliöiden käytön tärkeimmät edut Windowsissa
Päivittäisessä toiminnassa kontit tarjoavat konkreettisia etuja kehittäjille, järjestelmänvalvojille ja tietoturvatiimeille, erityisesti silloin, kun ympäristö pyörii Windowsin ympärillä.
Kehittäjille: sama sovellus, sama toiminta kaikkialla
Kehityksen näkökulmasta konttien suuri etu on se, että ympäristö lakkaa olemasta muuttuva tekijäLuot levykuvan, joka sisältää tarkan .NET-version, tarvittavat DLL-tiedostot, aputyökalut, IIS- tai Kestrel-kokoonpanon jne., ja kyseinen levykuva otetaan käyttöön samalla tavalla kaikissa ympäristöissä.
Tämä vähentää merkittävästi klassisia "se toimii koneellani, mutta ei palvelimella" -ongelmia. Lisäksi jokainen kehittäjä voi Luo täydellinen ympäristö sekunneissa tuhoamatta Windowsiasi: tietokantoja, jonoja, apupalveluita... Kaikki erillisissä säilöissä, jotka voidaan tuhota ja luoda uudelleen ilman pelkoa.
Projekteissa, joissa osa pinosta toimii Linuxissa (esimerkiksi Node.js-mikropalvelut tai tietokantasäiliöt) ja toinen osa Windowsissa (palvelut, jotka ovat riippuvaisia tietyistä API-rajapinnoista), voit koordinoida kaiken samalta koneelta. docker-compose- tai Kubernetes-manifestiversion ja portin yhtenäisyyden ylläpitäminen.
IT-tiimeille: laitteiston parempi käyttö ja vähemmän kaaosta
Ylläpitäjille säilöt mahdollistavat lisää levitystiheyttä Windows-palvelimilla voi olla useita konteissa olevia sovelluksia vähemmillä isännillä tai virtuaalikoneilla yksittäisten asennusten sijaan sen sijaan, että käytössä olisi yksi virtuaalikoni sovellusta kohden (täydellinen käyttöjärjestelmä ja korjauspäivitykset).
Päivitykset muuttavat myös lähestymistapaansa. Sen sijaan, että he kävisivät jokaisella palvelimella muokkaamassa binäärejä tai korjauspäivityksiä, he Luo uusi kuva muutoksen avulla (uusi koodi tai päivitetty kirjasto) lähetetään rekisteriin ja otetaan käyttöön, jolloin edellinen versio voidaan palauttaa voimaan, jos ongelmia ilmenee.
Ympäristöissä, joissa aiemmin oli kymmeniä koneita Windows on vanhentunut, "koska se toimii"Siirtyminen hyvin suunniteltuihin kontteihin antaa sinun eristää kyseiset sovellukset ja siirtää ne vähitellen nykyaikaisempiin alustoihin säilyttäen samalla paremman keskitetyn hallinnan.
Turvallisuuden vuoksi: eristys, minimaalinen pinta-ala ja keskitetty ohjaus
Konttien suojaus ei ole automaattista eikä täydellistä, mutta se tarjoaa oikein käytettynä erittäin tehokkaita työkaluja. Ensinnäkin jokainen kontti toimii seuraavien ominaisuuksien kanssa: rajoitetut käyttöoikeudet ja eristetyt resurssitTämä vähentää tunkeutumisen vaikutusta verrattuna suoraan isäntäjärjestelmässä suoritettavaan sovellukseen.
Kubernetes-klustereissa voit segmentoida ympäristön nimiavaruudet ja verkkokäytännötjotta eri palvelut kommunikoivat keskenään vain, kun se on nimenomaisesti sallittu. Tämä sopii hyvin yhteen periaatteiden, kuten "vähiten käyttöoikeuksien" ja "Nollaluottamus Windows Serverissä"Erityisen mielenkiintoista jatkoaikatilanteissa."
On myös helpompi toteuttaa ns. toimitusketjun turvallisuussykliTarkistat rekisterin levykuvat haavoittuvuuksien varalta, vaadit, että kaikki levykuvat tulevat allekirjoitetuista lähteistä, hallitset ajonaikaista kokoonpanoa (käyttöoikeudet, liitokset, ominaisuudet jne.) ja asennat korjaustiedostoja rakentamalla levykuvat uudelleen sen sijaan, että koskeisit manuaalisesti live-järjestelmiin.
Kun Windows ei hallitse resursseja hyvin... mutta käytät silti säilöjä.
Monilla ihmisillä on käsitys (joissakin tapauksissa varsin perusteltu), että Windows ei ole tehokkuuden kuningas resurssien kulutuksen suhteen. Varsinkin verrattuna palvelinoptimoituihin Linux-jakeluihin. Tämä johtaa loogiseen kysymykseen: miksi monimutkaistaa asioita Windows-konteilla, jos minulla on jo virtuaalikoneita tai jos voisin vain siirtää kaiken Linuxiin?
On useita syitä, miksi Windows-konttien käyttö voi olla järkevää, vaikka nämä rajoitukset hyväksyttäisiinkin:
- Windowsiin vahvasti linkitetyt sovelluksetMonia yritysratkaisuja, COM+-komponentteja, Windows-kohtaisia API-rajapintoja käyttäviä palveluita tai vanhoja .NET Framework -sovelluksia ei voida helposti siirtää Linuxiin.
- Standardoidut liiketoimintaympäristötOrganisaatiot, joiden koko toiminta perustuu Active Directoryyn, ryhmäkäytäntöihin, valvonta- ja varmuuskopiointityökaluihin, jotka on suunniteltu Windowsille.
- Tiimejä, joilla on kokemusta Microsoft-teknologioistaIT-henkilöstö on tottuneempi Windows Serverin, Hyper-V:n ja Microsoftin työkalujen kanssa kuin pelkkien Linux-klusterien hallintaan.
Tässä tilanteessa säilöi Windowsissa Se mahdollistaa paremman johdonmukaisuuden, nopeamman käyttöönoton, siirrettävyyden ja automaation, vaikka peruspalvelin ei olisikaan maailman kevyin. Jälkeenpäin voit aina optimoida Nano Server- tai Server Core -levykuvien ja ääniresurssien käytännöillä.
Verkko, portit, IP-osoitteet ja SSL Windows-konteissa
Yksi ensimmäisistä päänsäryistä aloittelevalle konttien kanssa on sen ymmärtäminen, Miten portteja ja IP-osoitteita hallitaan terve verkkoinfrastruktuuriJos olet joskus kamppaillut useiden palveluiden suorittamisen kanssa samoissa porteissa tai HTTPS:n määrittämisen kanssa säilöillä, tämä kuulostaa tutulta.
Oletusarvoisesti jokaisella säilöllä on oma oma eristetty verkkotilaSisäisesti se voi kuunnella portteja 80, 443, 8000… aivan kuin se olisi yksin. Temppu on siinä, että säilömoottori tai orkestroija hoitaa näiden sisäisten porttien yhdistämisen isäntäportteihin tai virtuaalipalveluihin klusterin sisällä.
Se tarkoittaa sitä Et tarvitse Raspberry Pi:tä palveluun. vain koska kaikki haluavat käyttää porttia 80. Voit määrittää useita säilöjä kuuntelemaan porttia 80 sisäisesti ja yhdistää jokaisen eri porttiin isännässä (esim. 8081, 8082…) tai piilottaa ne käänteisen välityspalvelimen tai Ingressin taakse, joka toimii ainoana etupäänä.
IP-osoitteiden osalta yksinkertaisissa tilanteissa jokainen säilö saa yhden virtuaaliverkon sisäinen IP-osoite jotka hallitsevat Dockeria tai Kubernetesia. Monimutkaisemmissa ympäristöissä käytetään CNI-laajennuksia ja päällekkäisverkkoja, jotta kontit voivat nähdä toisensa johdonmukaisesti useiden solmujen välillä.
Mitä SSL/TLS-salausYleisin lähestymistapa on välttää varmenteiden hallintaa erikseen kussakin säilössä ja sen sijaan keskittää ne yhteen käyttöliittymään: käänteiseen välityspalvelimeen, kuten Nginx, Traefik, HAProxy, tai Windowsissa IIS:ään tai Application Gatewayhin Azuressa. Tämä käyttöliittymä lopettaa HTTPS:n ja välittää liikenteen sisäisen HTTP:n kautta säilöihin. Voit myös liittää varmenteita säilöjen sisälle, mutta tämä vaikeuttaa hallintaa ja uusimista.
Kontit ja OT/PLC: Todellista muutosta vai IT-fantasiaa?
Teollisuusautomaation ja PLC:iden maailmassa tilanne on yleensä aivan erilainen kuin perinteisissä datakeskuksissa. On yleistä havaita Teollisuuden HMI:t ja PC:t, joissa on vanhemmat Windows-versiotAjurit, jotka ovat vahvasti sidoksissa tiettyyn laitteistoon, järjestelmiin, joita ei ole korjattu vuosiin, ja arkkitehtuureihin, jotka on suunniteltu periaatteella "jos se ei ole rikki, älä korjaa sitä".
Ohjelmiston näkökulmasta Kubernetesin, reunalaskennan ja konttien lupaus kuulostaa houkuttelevalta: laitteistoriippumattomuus, korkea käytettävyys, itsekorjaus, homogeeniset käyttöönotot ja puolustavat arkkitehtuurit, jotka lähestyvät "nollaluottamusta". Ongelmana on, että todellisuudessa on muita rajoituksia.
Voiko yksi konttipohjainen kehäarkkitehtuuri Apua? Vastaus on yleensä "kyllä, mutta", monien pilottihankkeiden kokemusten perusteella. Kyllä, koska:
- Se mahdollistaa vanhojen OT-sovellusten kapseloinnin, mikä vähentää niiden suoraa altistumista verkolle.
- Se helpottaa datayhdyskäytävien, aggregaattoreiden, historiapalveluiden tai analytiikan käyttöönottoa lähellä konetta.
- Se tarjoaa korkean käytettävyyden ja itsekorjausvaihtoehtoja komponenteille, jotka eivät ole kriittisiä ihmisten tai laitoksen turvallisuuden kannalta.
Ja "mutta", koska lisää monimutkaisuuden kerroksiaTiimejä on koulutettava, klustereita on hallittava, integroitava erittäin rajoitettuihin OT-verkkoihin ja toimittava rinnakkain PLC-toimittajien kanssa, jotka eivät välttämättä virallisesti tue näitä arkkitehtuureja.
Teollisen kyberturvallisuuden näkökulmasta tämäntyyppistä arkkitehtuuria pidetään yhä enemmän kohtuullinen askel kohti suurempaa eristystä ja kontrolliaEdellyttäen, että verkon segmentointia noudatetaan, kullakin solmulla suoritettavat tiedot ovat tiukasti rajoitettuja ja OT:n ja IT:n välinen vahva koordinointi säilyy.
Virtuaalikoneet vs. kontit: kumpaa käyttää kussakin tapauksessa
Ikivanhaan kysymykseen ”kontit vai virtuaalikoneet?” ei ole yhtä vastausta. Yleensä päädyt käyttämään Molemmat teknologiat tarpeen mukaan.
Jos sinun täytyy juosta erilaisia kokonaisia käyttöjärjestelmiä Samanaikaisesti virtuaalikone on edelleen paras vaihtoehto, jos haluat eristää työkuorman mahdollisimman hyvin sääntelyvaatimusten vuoksi tai käyttää ohjelmistoa, joka olettaa sillä olevan täyden järjestelmänhallinnan. Se on myös paras valinta, kun haluat erittäin vahvan erottelun eri vuokralaisten tai asiakkaiden välille.
Jos etsit on käyttöönoton nopeus, skaalautuvuus ja resurssien tehokas käyttöJa jos sovelluksesi toimivat sujuvasti samassa käyttöjärjestelmäperheessä (esimerkiksi useita .NET-sovelluksia Windows Serverillä), säilöt ovat selvästi houkuttelevampi vaihtoehto.
Monissa yritysympäristöissä on hybridimalli: virtuaalipalvelimet (Hyper-V:ssä, VMwaressa tai pilvessä) toimivat solmuina konttiklusterissa. Näiden virtuaalikoneiden päälle otetaan käyttöön Kubernetes, Docker Swarm tai jokin muu orkestroija, ja sieltä kaikki uudet tai päivitetyt sovellukset pakataan kontteihin.
Windows-kehitys ja Linux-käyttöönotto: todellisuuden törmäys
Hyvin yleinen ongelma, erityisesti Windowsissa kehittävissä ja Linuxissa (kontissa tai palvelimella) käyttöön ottavissa tiimeissä, on tiedostojärjestelmän eroWindows käsittelee tiedostonimiä tyypillisesti kirjainkokoa huomioimatta, kun taas Linux Tiedosto.ts y tiedosto.ts Ne ovat eri asioita.
Tämä johtaa todella ikäviin virheisiin. Esimerkiksi paikallisesti toimivan koodin tuonnit (koska Windows ei huomioi isoja kirjaimiamutta ne kaatuvat Linux-säilössä, koska tiedostonimessä on eri kirjain. Tämä on klassinen ongelma pinoissa, kuten TypeScript, Node, modernit käyttöliittymät jne.
Ainoa tapa todella välttää se on omaksua selkeät ja tiukat nimeämiskäytännöt projektin alusta alkaen (esimerkiksi kaikki consistent kebab-case- tai camelCase-tiedostoissa) ja vahvista sitä automatisoiduilla työkaluilla: linttereillä, Linux-ympäristöissä testejä suorittavilla CI-validoinneilla ja kirjainkokoherkkiä polkuja tarkistavilla koodikatselmuksilla.
Yritykset, jotka ottavat koodin laadun vakavasti, sisällyttävät nämä kontrollit tyypillisesti CI/CD-prosessiin, jotta isojen kirjainten kirjoitusvirheet, kirjoitusvirheet tai virheelliset riippuvuudet merkitään ennen tuotantoon pääsyä. Tämä on entistä tärkeämpää, kun lopullinen käyttöönotto on konttikoska siinä kaikki nuo taustalla olevan käyttöjärjestelmän yksityiskohdat tulevat havaittaviksi.
Lisäksi riippuvuuksien, suorituksenaikaisten versioiden ja ympäristökohtaisten kokoonpanojen hallinta on kriittistä, kun aloitat työskentelyn pilvi, tekoäly ja hallitut palvelut (AWS, Azure jne.), joissa infrastruktuuri on homogeenisempi ja vähemmän suvaitsevainen tyypillisiä Windows-työpöytä"kikkoja" kohtaan.
Tärkeimmät ja vaihtoehtoiset työkalut konttien maailmassa
Vaikka Dockerista ja Kubernetesista on tullut tosiasiallinen standardi, konttiekosysteemi on laaja ja tarjoaa monia vaihtoehtoja eri monimutkaisuustasoille ja tarpeisiin.
Docker: lähes kaiken perusta
Docker teki konttien kanssa työskentelystä suositun modernin tavan ja on edelleen suosittu. yhdyskäytävä useimmille laitteilleDocker Enginen avulla käynnistät ja hallinnoit säilöjä. Dockerfilen avulla määrität deklaratiivisesti, miten kuvat rakennetaan. Lopuksi Docker Hubin tai yksityisten rekisterien avulla voit jakaa nämä kuvat muiden ympäristöjen tai tiimien kanssa.
Windows-ympäristöissä Docker on erityisen hyödyllinen luoda toistettavia kehitysympäristöjä, minimoi "Frankenstein-asennukset" palvelimilla ja rakenna vankka perusta myöhemmälle skaalautumiselle monimutkaisempiin orkestroijiin.
Kubernetes: orkestrointia suuressa mittakaavassa
Kun sovellus alkaa käyttää useita palveluita, tietokantoja, jonoja, käyttöliittymiä ja muita säilökomponentteja, on vain ajan kysymys, milloin tarvitset orkestroijaKubernetes (K8s) on laajimmin käytetty avoimen lähdekoodin alusta konttien käyttöönoton, skaalauksen ja hallinnan automatisointiin.
Kubernetesissa ryhmittelet toisiinsa liittyvät säilöt palotMäärität käyttöönotot, jotka määrittävät haluamasi replikoiden määrän kullekin palvelulle, ja paljastat nämä podit verkkopalveluiden kautta. Ohjaustaso hoitaa kuormituksen tasapainotuksen työsolmujen välillä, valvoo instanssien kuntoa, käynnistää ne uudelleen, jos ne vikaantuvat, ja skaalaa ylös tai alas kysynnän mukaan.
Hybridi- ja pilviympäristöissä alustat, kuten AKS (Azure Kubernetes Service), GKE (Google Kubernetes Engine) tai EKS (Amazon Elastic Kubernetes Service), yksinkertaistavat hallittujen Kubernetes-ratkaisujen käyttöönottoa. Näin voit keskittyä sovelluksiisi ja jättää osan klusterinhallinnasta palveluntarjoajalle.
Muut työkalut ja vaihtoehdot
Dockerin ja Kubernetesin lisäksi on olemassa muita ratkaisuja, jotka kattavat erityistarpeet tai arkkitehtuuriset mieltymykset:
- podmanSamanlainen kuin Docker, mutta ilman keskitettyä daemonia; erittäin arvostettu joissakin Linux-ympäristöissä.
- KonttiDockerin käyttämä konttimoottori; sitä voidaan käyttää erikseen.
- OpenShiftRed Hatin Kubernetes-pohjainen alusta, jossa on monia lisäominaisuuksia yrityskehitykseen ja -toimintaan.
- NomadiHashiCorpin orkestroija on joissakin tapauksissa Kubernetesia yksinkertaisempi käyttää, ja se pystyy hallitsemaan perinteisiä säilöjä ja hyötykuormia.
- LXD"Täyden järjestelmän" tyyppiset säilöt Linuxissa, hyödyllisiä, kun haluat jotain klassisen säilön ja kevyen virtuaalikoneen väliltä.
- KulkuriSe ei ole konttipohjainen, mutta se on silti hyödyllinen toistettavien kehitysympäristöjen luomiseen virtuaalikoneiden kanssa tai jopa yhdistettynä Dockeriin.
Koko tämä matka tekee siitä niin, että kun kysyt itseltäsi, Windowsin säilöt ovat järkeviäVastaus riippuu vähemmän itse teknologiasta ja enemmän siitä, sopiiko se sovelluksiisi, tiimiisi ja toimintamalliisi. Monissa tapauksissa konttiratkaisut ovat paras tapa saavuttaa merkittävä parannus käyttöönotossa, siirrettävyydessä ja tietoturvassa hylkäämättä Windows-ekosysteemiä. Toisissa tapauksissa voi olla järkevämpää pitäytyä perinteisissä virtuaalikoneissa tai valita suoraan Linux. Tärkeintä on ymmärtää komponentit hyvin, jotta voidaan tehdä tietoon perustuvia päätöksiä siitä, milloin, miten ja missä konttiratkaisut kannattaa toteuttaa.