Positsioon, milles väidetakse, et operatsioonisüsteemi tasemel konteinerisse paigutamine, mille kanooniliseks eeskujuks on Docker, ei ole pelgalt kasulik tööriistavalik, vaid põhitehnoloogia operatiiv- ja infotehnoloogia lähendamiseks. Argument puudutab otseselt kõige tugevamaid vastuväiteid ja järeldab, et need on pigem kõrvaldatavad kui diskvalifitseerivad.
Preambula
Konteinerite kasutuselevõtuga tööstuskeskkonda kaasneb püsiv skeptitsism. Vastuväited on tuttavad: tööstussüsteemide elutsüklid mõõdetakse aastakümnetes, mitte kasutuselevõtutsüklid minutites; reaalajas jõudlusnõuded ei talu üldotstarbelise käitusaja ettearvamatust; kümnete konteineritega kokkupuutuva Linuxi tuuma käitamise tagajärjed ei ole piisavalt mõistetavad; operatsioonitehnoloogia (OT) tööjõu küpsus ei vasta tänapäevaste pilvepõhiste tööriistade töö keerukusele.
Igal neist vastuväidetest on tõe tuum. Ükski neist, väidab käesolev artikkel, ei kannata tõsist uurimist.
Lõputöö on otsene: operatsioonisüsteemi tasemel konteinerisse paigutamine – mille kanooniliseks eeskujuks on Docker – on tööstustarkvara jaoks õige alussubstraat. Selle kasutuselevõtt ei ole moe, vaid arhitektuurilise vajaduse küsimus. Alternatiivid on hullemad. Vastuväited, kuigi tõelised, tuvastavad pigem teadaolevate lahendustega tehnilisi probleeme kui põhimõttelisi kokkusobimatuid.
See artikkel koosneb kaheksast osast. Esimene määrab, mis Docker tehniliselt on, eristades tehnoloogiat turunduspinnast. Teises paigutatakse konteinerid nende ajaloolisesse päritolu, et hajutada muljet, et tegemist on uudse ja tõestamata tehnoloogiaga. Kolmas iseloomustab tööstustarkvara juurutamise probleemi, mille lahendamiseks sobivad eriti hästi konteinerid. Neljas jätkab jaatavat juhtumit. Viies seisab silmitsi peamiste vastuväidetega. Kuues kirjeldab arhitektuurilisi mustreid, mis on esile kerkinud tootmistööstuses. Seitsmendas uurib lahtisi probleeme ja vastutustundliku lapsendamise tingimusi. Kaheksas kordab ja kaitseb keskset väidet.
Sihtrühmaks on arhitekt või insenerijuht, kes kaalub, kas siduda tööstusliku tootesarjaga konteinerinfrastruktuur. Argument on mõeldud kasulikuks just seetõttu, et see ei meelita tehnoloogiat.
Mis Docker tegelikult on?
Puhas argument nõuab puhast objekti. Docker on tugevalt ülekoormatud termin ja suur segadus konteinerite üle peetavates tööstuslikes aruteludes tuleneb otseselt ebatäpsusest, mida arutatakse.
Otseses mõttes viitab Docker operatsioonisüsteemi tasemel virtualiseerimise konkreetsele teostusele Linuxis, mille andis algselt välja 2013. aastal dotCloud (hiljem Docker, Inc.) [1]. Praeguses praktikas hõlmab termin mitut eristatavat komponenti: konteineri käituskeskkond (algselt "libcontainer", hiljem "containerd" ja "runc"), pildivorming ja registriprotokoll, käsurea tööriist ja deemoni arhitektuur.
Aluseks olevad tehnilised primitiivid on kerneli funktsioonid, mitte Dockeri spetsiifilised leiutised:
Linuxi nimeruumid [2] pakuvad süsteemiressursside protsessitasemel isolatsiooni. Seitse nimeruumi tüüpi – PID, võrk, ühendus, UTS, IPC, kasutaja ja cgroup – võimaldavad üheskoos protsesside rühmal töötada protsessiidentifikaatorite, võrguliideste, failisüsteemi kinnituste, hostinime ja domeeni, protsessidevaheliste sidekanalite, kasutaja- ja rühmaidentifikaatorite ning juhtrühma hierarhiate isoleeritud vaates. Konteiner on tuuma tasemel protsessipuu, mille nähtavat süsteemi olekut piiravad need nimeruumid.
Juhtrühmad (cgroups) [3], mis algselt töötati välja Google'is ja liideti 2007. aastal Linuxi tuumaga, pakuvad ressursside arvestust ja piiramist. Protsessori jagamist, mälupiiranguid, I/O ribalaiust ja seadme juurdepääsu saab piirata protsessirühmade kaupa. cgroups v2, kerneli versioonis 4.5 (2016) kasutusele võetud ühtne hierarhia, mis muudeti 2021. aastaks enamikus distributsioonides vaikeseadeks, parandas oluliselt ressursside juhtimise mudelit.
OverlayFS [4] ja sarnased liitfailisüsteemid võimaldavad kihilist pildimudelit, mis eristab Dockerit varasematest konteinersüsteemidest. Pilt on kirjutuskaitstud kihtide virn; jooksev konteiner lisab peale kirjutatava kihi. Konteinerite ja hostide vahel jagatakse identseid kihte, mis tagab olulise salvestusruumi ja võrgu tõhususe.
Krüptograafilise räsi abil tuvastatud pildikihtide sisuaadresseeritav salvestusruum võimaldab garantiid, millel pole tavapärastes juurutusmudelites samaväärset: juurutatud artefakti bait-baidi reprodutseeritavus. Arendaja tööjaamas tähisega „sha256:abc...” tuvastatud kujutis on biti-identne kujutisega, mille tuvastab sama räsi tootmislüüsil, olenemata sellest, millal või kuhu see tõmmatakse.
Need primitiivid ei ole Dockeri väljamõeldised. Need on Linuxi kerneli funktsioonid, mille Docker tooteks kokku pani. Nende olemasolu ja stabiilsus on ammu enne konteinerite populaarset kasutuselevõttu ja nüüd reguleeritakse neid avatud spetsifikatsiooniga.
Alates 2015. aastast on konteineri ökosüsteem standarditud avatud konteineri algatuse (OCI) [5] raames, mis annab kolm spetsifikatsiooni: käitusaja spetsifikatsioon, pildi spetsifikatsioon ja levitamise spetsifikatsioon. Praktiline tagajärg on see, et ettevõte Docker on nüüd üks juurutaja paljude avatud standardite seas ja tootmises kasutatavad konteinerite käitusajad – konteiner, CRI-O, Podman – töötavad nende spetsifikatsioonide kaudu. Dockeri kasutamine 2025. aastal tähendab OCI konteinerite kasutamist; bränd ja tehnoloogia on lahti ühendatud.
See ühemõttelisus on oluline, sest vastuväited Dockerile puudutavad sageli kas ettevõtet, ajaloolist deemoni arhitektuuri või perifeerset tööriista – mitte aluseks olevaid tehnilisi primitiive, mis on argumendi püsiv sisu.
Konteineriseerimise ajalooline liin
Konteinerid pole uued. Populaarne narratiiv, mis asetab nende päritolu Dockeri 2013. aasta väljaandele, varjab nelja kümnendi pikkust päritolu, mis mõjutab oluliselt seda, kuidas tehnoloogiat tuleks tööstuslikuks kasutamiseks hinnata. Pika sugupuuga küps tehnoloogia väärib teistsugust tõendusstandardit kui arenev tehnoloogia ja konteinerid on ühemõtteliselt esimene.
Liin algab sõnaga "chroot", mis võeti kasutusele Unixi versioonis 7 1979. aastal [6]. chroot võimaldas protsessi piirata failisüsteemi alampuuga, mis on esimene laialt levinud süstemaatiline failisüsteemi tasemel isoleerimisprimitiiv. Selle turvapiirangud tunnistati varakult – „chroot” ei olnud kunagi loodud turvapiiriks –, kuid see pani aluse failisüsteemi virtualiseerimisele.
FreeBSD vanglad [7], mille Poul-Henning Kamp ja Robert Watson 2000. aastal hostiteenuse pakkuja palvel tutvustasid, laiendasid "chrooti" protsessi ja võrgu isolatsiooniga, luues tänapäevases mõistes äratuntavalt konteineri. Vanglad kavandati algusest peale turvapiirina ja neid on tootmises kasutatud peaaegu veerand sajandit. Nende kasutuselevõtt võrguseadmetes – pfSense, opnSense, NetApp – annab pika kogemuse konteinerite kohta missioonikriitilistes rollides.
aastal välja antud Solarise tsoonid [8] pakkusid kommertskvaliteetset konteinerit koos tugeva isolatsioonigarantiiga, integreerituna Solarise teenusehaldussüsteemiga ja mida kasutati ettevõtte tootmises alates käivitamisest. Sun Microsystemsi inseneriinvesteering tsoonidesse oli märkimisväärne ja tehnoloogiat kasutati keskkondades – telekommunikatsioonilülitites, finantstehingute süsteemides –, mis on vähemalt sama kriitilised kui tüüpilised tööstuslikud juurutused.
Linuxi konteinerid (LXC) [9], mis tekkisid alates ligikaudu aastast 2008, tõid Linuxile konteinerite funktsionaalsuse ülalpool käsitletud nimeruumide ja cgroups-primitiivide kaudu. LXC oli Dockeri otsene tehniline eelkäija; Dockeri varased versioonid olid tegelikult arendajakogemuse kiht üle LXC.
Dockeri panus 2013. aastal ei olnud tehniline uudsus tuuma mõistes. Nimeruumid olid eksisteerinud aastaid; cgroups liideti 2007. aastal. Dockeri panus oli pildivorming, registriprotokoll ja arendajakogemus, mis muutis olemasolevad kerneli primitiivid tavalistele rakenduste arendajatele kättesaadavaks. Tehnoloogia oli kolmkümmend viis aastat vana, kui Docker selle kasutatavaks muutis.
Google'i süsteem Borg [10], Kubernetese eelkäija, oli kogu Google'i tootmisparki kasutanud konteinerites umbes 2003. aastast – kümme aastat enne Dockeri olemasolu. Selleks ajaks, kui Docker jõudis 2014. aastal versioonini 1.0, töötas Google nädalas miljardeid konteinereid. Argument, et mahutitehnoloogia on suuremahulises tootmises tõestamata, põrkub selle empiirilise rekordiga.
Tööstusliku kasutuselevõtu puhul ei ole oluline küsimus, kas tehnoloogia on küps – see ilmselgelt on –, vaid see, kas tööstusespetsiifilised kasutuselevõtumustrid on küpsed. Seda küsimust käsitletakse 6. jaotises.
Tööstustarkvara juurutamise probleem
Selleks, et konteinerite puhul tööstuses jaataks, tuleb täpselt iseloomustada probleemi, mida konteinerid lahendavad. Tööstustarkvara juurutamist on ajalooliselt mõjutanud patoloogiate kogum, mis ei ole tööstusliku kontekstiga juhuslik, vaid tulenevad otseselt selle struktuurilistest omadustest.
Seadmete pikad elutsüklid põhjustavad sõltuvuse triivi. 2010. aastal kasutusele võetud tööstuskontroller võib veel 2030. aastal töötada – kasutusiga on kaks aastakümmet. 2010. aasta tarkvarakeskkond ei ole aga 2030. aasta tarkvarakeskkond. Teegi versioonid, kompilaatorite tööriistaahelad, käitusaegsed tõlgid ja operatsioonisüsteemi tuumad arenevad. Tavapärane vastus – kogu virna külmutamine juurutamise ajal – tekitab hooldamatu artefakti: kontroller võib käitada oma algset tarkvara, kuid seda ei saa ohutult värskendada, parandada ega muuta, ilma et oleks oht sõltuvusi ettearvamatul viisil katkestada. See on sõltuvuse triivi probleem.
Heterogeensed juurutamise sihtmärgid suurendavad integratsiooni keerukust. Tööstustarkvara võib olla vajalik poolel tosinal sihtplatvormil töötamiseks: erinevad SoC-arhitektuurid, erinevad Linuxi distributsioonid, erinevad kerneli versioonid, erinevad glibc-versioonid. Iga tarkvaramuudatuse testimise kombinatoorika iga sihtplatvormi suhtes on lahendamatu ilma rakenduse ja selle hostkeskkonna vahelise tugeva isolatsioonita. Ilma isolatsioonita peab integratsioonitestimine olema ammendav; isolatsiooni korral võib see olla selektiivne.
Värskendusmehhanismid on ajalooliselt olnud rabedad. Tavapärane tööstuslik värskendus – püsivara kujutis, mis on välkmällu välkuv ja mille tagasipööramine nõuab tavaliselt füüsilist juurdepääsu – ei toeta üksikasjalikke, sagedasi ja jälgitavaid värskendusi, mida tänapäevased turbeasendid nõuavad. Nüüd ilmnevad kriitilised haavatavused ja need vajavad parandamist päevade kuni nädalate jooksul; tööstusliku püsivara värskendustsüklid, mida mõõdetakse kuudes või aastates, on ohumudelite jaoks üha ebapiisavad.
Reprodutseeritavus on töös oluline, kuid tehniliselt raskesti mõistetav. Kui tööstussüsteem ebaõnnestub, nõuab diagnostikaprotsess rikke taasesitamist kontrollitud keskkonnas. Kui tootmissüsteemi tarkvarakeskkonda ei saa täpselt reprodutseerida – kuna see loodi teatud teegi versioonide, konfiguratsioonifailide ja käitusaja oleku kombinatsioonist, mida keegi täielikult ei dokumenteerinud –, muutub diagnoos arheoloogiaks. See on tööstustarkvara suhtes kohaldatav taasesitatavuse kriis ja see on andnud tööstusele intsidentidele reageerimise aja kalliks maksma.
Rakenduste ja operatsioonisüsteemi vaheline piir on vähenenud. Kaasaegsed tööstuslikud rakendused sõltuvad suurest osast operatsioonikeskkonnast: konkreetsed teegid, kindlad tuumamoodulid, kindlad süsteemiüksused, spetsiifilised failisüsteemi paigutused. Ajalooline mudel - "rakenduse juurutamine, OS on kellegi teise probleem" - ei vasta tööreaalsusele, kus rakendused ja nende sõltuvused on läbi põimunud ja neid tuleb koos juurutada.
Kõik need patoloogiad on põhimõtteliselt lahendatavad ainult hoolika inseneridistsipliiniga. Praktikas näitavad tööstustarkvara empiirilised andmed, et inseneridistsipliin on üksi ebapiisav, kuna patoloogiad on struktuuriliselt põhjustatud lõhest rakenduse ja selle keskkonna vahel. Konteinerid täidavad selle lünga, juurutades rakenduse koos selle sõltuvustega ühe muutumatu artefaktina. See ei ole stiililine eelistus; see on struktuurne abinõu struktuurse probleemi lahendamiseks.
Jaatav juhtum
Iseloomustatud probleemiga saab tööstustarkvara konteinerite puhul jaatava juhtumi teha kuuel põhjusel.
Container suitability for industrial software criteria
bar chart4.1 Krüptograafiline reprodutseeritavus
Konkreetse SHA-256 kokkuvõttega tuvastatud kujutis on bittidena igal hostil, mis seda tõmbab. See on tugevam garantii kui ükski tavaline juurutusmehhanism. Kui tootmises toimub intsident, saab täpset tarkvarakeskkonda, milles juhtum juhtus – arendaja tööjaamas, testkeskkonnas, regulatiivses auditis – matemaatilise kindlusega reprodutseerida.
Selle garantii diagnostilist väärtust on raske üle hinnata. Iga praktiku kogemuse kohaselt on tööstuslike intsidentidele reageerimise diagnooside "ei suutnud reprodutseerida" hind märkimisväärne. Krüptograafiline reprodutseeritavus välistab selle tarkvarakihi tõrkerežiimi, jättes allesjäänud reprodutseerimatuse allikateks ainult tõeliselt raskesti taasesitavad keskkonnategurid – andurite müra, elektromagnetilised häired, mehaaniline kulumine.
Sama garantii toetab vastavust ja auditit. Kui tööstuslik kasutuselevõtt peab regulatiivsetel eesmärkidel näitama, et kohapeal töötav tarkvara on täpselt see tarkvara, mis valideeriti ja heaks kiideti, näeb kujutise kokkuvõte selle demonstratsiooni vormis, mis on krüptograafiliselt võltsimiskindel.
4.2 Aatomi kasutuselevõtt ja tagasivõtmine
Tavapärastel tööstuslikel uuendustel on omadus, et neid ei saa otsekohe tagasi pöörata. Püsivaravärskendus, mis osutub tootmises problemaatiliseks, nõuab kas füüsilist juurdepääsu uuesti vilkumiseks või keerukat värskendusmehhanismi, mis sisaldab A/B-sektsioone ja selgesõnalist tagasipööramise tuge – ja isegi need mehhanismid on püsivara tasemel tavaliselt kõik või mitte midagi.
Konteinerite juurutamine on individuaalse töökoormuse granulaarsuse juures ülioluline. Uue konteineri kujutis tõmmatakse, kinnitatakse ja käivitatakse; vana pilt peatatakse. Kui uus pilt ei läbi ühtegi tervisekontrolli, siis üleminek ennistatakse. Süsteemi olek ebaõnnestunud juurutamise lõppedes on identne selle olekuga juurutuse alguses.
Sellel varal on olulised tegevuse tagajärjed. See võimaldab agressiivset värskendussagedust ilma operatsiooniriski proportsionaalse suurenemiseta. See võimaldab Canary juurutamist – katsetada uut pilti autopargi alamhulgas enne laiemat kasutuselevõttu. See võimaldab automaatset tagasipööramist vastuseks telemeetriasignaalidele. Ükski neist mustritest ei ole tavapäraste püsivara värskendamise mehhanismidega teostatav.
4.3 Sõltuvuse isoleerimine
Igal konteineril on oma sõltuvused. Kaks ühes hostis asuvat konteinerit võivad sõltuda sama teegi ühildumatutest versioonidest ja mõlemad töötavad õigesti. Hosti operatsioonisüsteem peab pakkuma ainult tuuma; kasutajaruumi sõltuvused on pildil kapseldatud.
Selle vara tööstuslik tähtsus seisneb selles, et tööstuslik lüüs võib majutada mitut rakendust – võib-olla on need välja töötatud erinevate müüjate poolt, võib-olla kasutusele võetud erinevatel aegadel, võib-olla olenevalt tavapäraste raamatukogude erinevatest versioonidest – ilma integratsiooni keerukuseta, mis sellisel kaasresidendist ajaloos on olnud. Uue rakenduse juurutamine ei ohusta olemasolevate rakenduste purunemist, kuna sõltuvused ei toimi.
See on rakenduste turu mudeli struktuurne võimaldaja, mida on piiratud eduga üritatud tööstuslike kontrollerite jaoks mitu aastakümmet kasutada. Konteineritepõhine rakenduste levitamine muudab turu teostatavaks, kuna integratsiooniprobleem, mis on ajalooliselt peamine takistus, on enamasti lahendatud.
4.4 Töökoormuse teisaldatavus
Arendaja kohalikus keskkonnas töötav konteineri kujutis töötab suure täpsusega tootmisväravas. Sama pilt töötab andmekeskuse x86 serveris või ARM-põhises tööstuslüüsis, arvestades mitme arhitektuuriga kujutist. Täitmiskeskkond on juurutamiskontekstides suures osas muutumatu.
Sellel teisaldatavusel on tööstustarkvara jaoks kaks olulist tagajärge. Esiteks kõrvaldab see suure hulga integratsioonivigu – need, mis on põhjustatud arendus- ja tootmiskeskkondade erinevustest. Teiseks muudab see pilve ja serva vahelise piiri pigem kasutuselevõtuotsuseks kui arhitektuuriliseks otsuseks. Sama töökoormus võib töötada mõlemas asukohas ja asukohta saab muuta ilma koodi muutmata. See on serva-pilve kaasdisaini praktiline võimaldaja [11], kus töökoormused liiguvad tasandite vahel vastavalt operatiivvajadusele.
4.5 Turvatäiustused paljasmetalli kasutuselevõtuga
Sage eksiarvamus käsitleb konteinereid nõrgema turvapiirina kui virtuaalmasinaid ja järeldab, et konteinerid kujutavad endast turvalisuse taandarengut. Võrdlus on õige, kuid järeldus vale, sest asjakohane võrdlus ei ole konteiner-vs-VM, vaid konteiner-vs-konteiner – see tähendab, et ajalooline alternatiiv konteineriseeritud tööstuslikule kasutuselevõtule ei ole virtualiseeritud juurutamine; see on paljasmetallist kasutuselevõtt ilma isolatsioonita.
Selle ajaloolise baasjoone taustal on konteinerid ühemõtteliselt edasi arenenud. Need pakuvad:
NIST eriväljaanne 800-190 [12] annab autoriteetse viite konteineri turvakonfiguratsioonile reguleeritud keskkondades. Õigesti konfigureeritud konteinerid, millel on juurteta täitmine, võimekuse tühistamine, seccomp-filtreerimine ja kujutiste skannimine, on oluliselt tugevam turvapositsioon kui nende asendatavad paljast metallist tööstuslikud juurutused.
Õigustatud mure – et kernel on suurem ründepind kui hüperviisor – kehtib kitsastes tingimustes ja seda käsitletakse jaotises 5.
- Protsessi isoleerimine nimeruumide kaudu, vältides juhuslikke või pahatahtlikke häireid kaasresidentsete rakenduste vahel.
- Ressursipiirangud cgroupide kaudu, takistades üksikul rakendusel hostiressursse ammendumast.
- Võimaluse kaotamine, ohtlike Linuxi võimaluste eemaldamine konteineriprotsessidest vaikimisi.
- Kirjutuskaitstud juurfailisüsteemid, mis välistavad suure osa ekspluatatsioonijärgsest püsivusest.
- Seccompi filtrid, mis piiravad saadaolevaid süsteemikõnesid konteineripõhisele protsessile.
- AppArmori ja SELinuxi integratsioon, pakkudes kohustuslikke juurdepääsu kontrolle.
4.6 Toimimise ühtlustamine kaasaegse tarkvarapraktikaga
Jaatava käände viimane element on võib-olla kõige olulisem, kuigi seda on kõige raskem kvantifitseerida. Konteinerid toovad tööstustarkvara samasse töötööriistaahelasse laiema tarkvaratööstusega. Pidevad integratsioonitorud, tarneahela turbetööriistad, jälgitavuse virnad, juurutamise automatiseerimissüsteemid – kõik need on konteineripõhised.
Sellest järeldub, et tööstustarkvaraarendus võib värvata laiemalt tarkvarainseneri tööturult, võtta kasutusele hüperskaalas valideeritud tavasid ja tööriistu ning integreeruda pilvepõhise ökosüsteemiga ilma spetsiaalselt kohandamata. Tööstustarkvara arenduse ajalooline eraldatus laiemast tarkvaraökosüsteemist – sellega kaasnevate talentide nappuse, tööriistade lünkade ja turvalisuse puudujääkidega – lahustub konteinerite kasutuselevõtuga.
See mõju on struktuurne ja pikaajaline. Selle tagajärjed ilmnevad üle kümne aasta või kauemgi, kuid liikumissuund on selge: tööstustarkvara arendus muutub nii tööriistade kui ka praktika poolest tänapäevasest rakenduste arendusest eristamatuks.
Vastuväidetele vastamine
Tõsine propageerimine peab tegelema vastuväidete tugevaimate vormidega, mitte kõige nõrgematega. See jaotis käsitleb nelja kõige sagedamini esitatud vastuväidet tööstusliku konteineri vedamise vastu.
5.1 Reaalajas toimivuse vastuväide
Konteinerid kasutavad mittedeterministlikku ajakava ja ressursside konkurentsi, mis diskvalifitseerib nad reaalajas tööstuslikust töökoormusest.
Vastulausel on eeliseid selle tugevaimas vormis, kuid vorm, milles see tavaliselt esitatakse, on liiga laiaulatuslik. Tööstuslikud töökoormused reaalajas ei ole monoliitsed; need ulatuvad tugevast reaalajas liikumisjuhtimisest (tähtajad mikrosekundites, ülejäänud tähtaeg võrdub ohutusjuhtumiga) pehme reaalajas protsessijuhtimiseni (tähtajad kümnetes millisekundites, aeg-ajalt möödalaskmised on lubatud) kuni mittereaalajas analüüsini (tähtaeg puudub).
Raske reaalajas töökoormuse jaoks on konteinerid tõepoolest sobimatud, kuid sama ei sobi ka tavaline Linux. Raske reaalajas Linuxis nõuab PREEMPT_RT [13] või samaväärse paigatud tuuma, hoolikat CPU afiinsust, reaalajas tuumade eraldamist planeerijast ja mittereaalajas töökoormuste välistamist reaalajas domeenist. Need nõuded on konteinerisse paigutamisest sõltumatud. Õigesti konfigureeritud reaalajas Linuxi süsteem suudab majutada reaalajas töökoormust konteinerites, millel on täielikud reaalajas garantiid, eeldusel, et järgitakse konfiguratsioonidistsipliini.
Kvantitatiivsed mõõtmised kinnitavad seda. PREEMPT_RT Linuxi [14] konteineriseeritud reaalajas töökoormuste võrdlusnäitajad näitavad latentsusaega madalates mikrosekundites võrreldes tühimetalli täitmisega – isegi nõudliku tööstusliku töökoormuse taluvuse piires. Üldkulud tulenevad suures osas cgroup-arvestusest, mille saab valikuliselt keelata reaalajas olevate cgruppide jaoks, kus deterministlik latentsus on olulisem kui peeneteraline ressursiarvestus.
Pehme reaalajas ja mittereaalajas töökoormuse puhul – mis hõlmab valdavat enamust tööstustarkvarast – toovad konteinerid CPU-ga seotud töökoormuste puhul 1–3% üldkulusid ja I/O-ga seotud töökoormuste puhul statistiliselt tühised üldkulud. See ei ole tõsine takistus.
5.2 Turvalisuse piiride vastuväide
Konteinerite põgenemise haavatavused avastatakse rutiinselt; konteinereid ei saa usaldada suure väärtusega tööstusliku töökoormuse turvapiirina.
Vastuväide ühendab kaks erinevat väidet. Esimene – konteinerite põgenemise haavatavused on olemas – on tõsi. Teist – et see diskvalifitseerib konteinerid tööstuslikust kasutusest – ei järgne, sest on olemas ka virtuaalmasina põgenemised ja paljasmetalli juurutustel pole põgenemiseks üldse piire. Asjakohane küsimus on turvahoiak alternatiivide, mitte täiuslikkuse suhtes.
Ajaloolised andmed konteinerite põgenemise haavatavuste kohta on informatiivsed. Peamised CVE-d – runc CVE-2019-5736, Dirty Pipe CVE-2022-0847, CVE-2024-0132 NVIDIA konteineri tööriistakomplektis – on igal juhul paigatud päevade jooksul pärast avalikustamist ja ökosüsteemis levitatud nädalatega. Korralikult hooldatud süsteemide kokkupuuteaken on olnud lühike.
Töökoormuste jaoks, mis nõuavad hüperviisori tasemel isoleerimist, pakuvad kerged VM-põhised konteineri käitusajad – Kata Containers [15], Firecracker [16], gVisor [17], säilitades samal ajal konteineri liidese. Need tehnoloogiad võimaldavad hübriidset juurutamist, kus enamik töökoormusi töötab tavalistes konteinerites, samas kui eriti tundlikud töökoormused töötavad mikro-VM-ides, mida kõike haldab sama orkestreerimiskiht.
Tööstusliku konteineriseerimise tõsine turvaprobleem ei ole tuuma ründepind; see on tarneahel. Konteineri kujutis, mis on koostatud ebausaldusväärsetest põhikujutistest, ohustatud hoidlatest võetud pakettidest, ilma päritoluta torujuhtmetest, on kompromissi vektor, mida konteineri isoleerimine ei lahenda. Vastus sellele väljakutsele, mida käsitletakse jaotises 6, on tarneahela turberaamistike (nt SLSA) [18] vastuvõtmine ja allkirjastatud piltide levitamine Sigstore'i kaudu [19].
5.3 Stateful Workload Vastuväide
Konteinerid olid mõeldud olekuta töökoormuse jaoks. Tööstuslikud rakendused on sügavalt olekupõhised ja nende sundimine olekuta mudelisse loob halva arhitektuuri.
Eeldus on osaliselt õige – varajased konteinerjuhised rõhutasid kodakondsusetust –, kuid järeldus mitte. Konteinermudel mahutab olekupõhise töökoormuse mahuühenduste, orkestreeritud keskkondades püsivate mahtude ja selgesõnaliste andmehaldusprimitiivide kaudu. Nõutav distsipliin on muuta olek väliselt adresseeritavaks ja selgesõnaliselt hallatavaks, mitte kaudselt rakenduse käitusmälus.
See distsipliin on tööstuslike rakenduste jaoks tegelikult kasu, mitte kulu. Olekupõhine tööstusrakendus, mille olek on kaudne, dokumenteerimata ja käitusmäluga mässitud, on just selline rakendus, mida on võimatu siluda, mida on võimatu migreerida ja mille tõrke korral on võimatu taastada. Konteinerimisprotsess sunnib oleku välistamist ja selgesõnalist haldamist, luues rakendusi, mis on vastupidavamad, mitte vähem.
Tõeliselt kindlate tööstuslike töökoormuste jaoks – ajaloolised andmebaasid, kalibreerimisandmed, konfiguratsioonisalved – pakub konteineri ökosüsteem küpset tööriista: püsivad mahud koos sobiva failisüsteemi tagavaraga, operaatorimustrid andmebaasi elutsüklite haldamiseks ja salvestuskihiga integreeritud varundusprimitiivid.
5.4 Operatsiooni keerukuse vastuväide
Konteinerite orkestreerimine toob kaasa operatsiooni keerukuse, mida OT-meeskonnad pole valmis haldama. Alternatiiv – lihtsad püsivaravärskendused – on toimivalt lihtsam, isegi kui tehniliselt kehvem.
Vastulausel on oluline empiiriline tugi. Kubernetest peetakse laialdaselt operatiivselt keerukaks ja selle kasutamiseks vajalikud oskused ei ole OT-meeskondades tavaliselt elanikud.
Vastuväite kvalifitseerivad aga kaks tähelepanekut. Esiteks ei nõua konteineri juurutamine Kubernetesi. Ühe sõlmega tööstuslike juurutuste puhul, mis kirjeldavad valdavat enamust servalüüsi stsenaariumidest, pakuvad Docker Compose, Podman või süsteemiga hallatavad konteineriüksused tööpinna, mis on keerukuselt võrreldav tavapärase teenusehaldusega. Täielikku orkestreerimispakki on vaja ainult masinapargi mastaabis juurutamiseks ja sellisel skaalal kompenseeritakse orkestreerimise keerukust tegevusest saadav kasu.
Teiseks on kerge orkestreerimine – K3s [20], KubeEdge [21], MicroK8s – oluliselt vähendanud masinapargi mastaabis servajuurutamise keerukust. Ajalooline Kubernetese keerukuse profiil peegeldas selle päritolu hüperskaalamise töökoormusest; kergekaalulised variandid on spetsiaalselt välja töötatud äärekasutamise tööreaalsuse jaoks.
Sügavam vastus operatsioonilise keerukuse vastuväidetele on see, et mittekonteinerite tööstustarkvara toimimise keerukust on aastakümneid alahinnatud. Dokumenteerimata sõltuvused, kordumatud intsidendid, kasutuselevõtuprotsessid, mis eksisteerivad ainult hõimuteadmistena teatud inseneride peades – need on toimimise keerukuse vormid, mida ei mõõdeta, kuna need pole nähtavad. Konteinerorkestreerimise nähtav keerukus asendab nähtamatut keerukust, mis oli alati olemas. See, kas tegemist on kasutuskoormuse netokasvu või -vähenemisega, sõltub konkreetsest kasutuselevõtust, kuid eeldus, et konteineriteta baasjoon on töökorras lihtne, ei jää kontrolli alla.
Arhitektuurimustrid tööstuslikuks kasutuselevõtuks
Üleminek teoreetiliselt kaitstavuselt kasutuselevõetavale praktikale sõltub arhitektuurimustrite küpsusest. Tootmistööstuses kasutusele võetud mustrid nõuavad selget kirjeldamist.
6.1 Ühe sõlmega lüüsi juurutamine
Kõige tavalisem muster on ühe sõlmega lüüs: tööstuslik lüüs, mis käitab väikest hulka konteinerrakendusi, mille orkestratsioonipinnaks on Docker Compose või süsteemi hallatavad konteineriüksused. Värskendused tõmmatakse keskregistrist, valikuliselt ajakava järgi, mis on määratletud Vahitorni-sarnase kooskõlastusahelaga. Olek püsib kohalike mahtudeni koos keskse infrastruktuuri varuga.
Selle mustri tugevuseks on töö lihtsus. Selle nõrk külg on see, et autopargi mastaabis haldamist otseselt ei toetata – iga lüüsi hallatakse iseseisvalt. Kümnete kuni madalate sadade lüüside juurutamiseks on see vastuvõetav. Suuremate autoparkide jaoks on sobivam järgmine muster.
6.2 Fleet-Scale orkestreerimine
Autopargi mastaabis juurutamiseks pakuvad kerged Kubernetese distributsioonid (K3s, KubeEdge) kogu masinapargi orkestreerimist. Igast lüüsist saab sõlm – kas ühe sõlme klastrina või suurema klastri töötaja sõlmena – ning töökoormusi planeeritakse, värskendatakse ja vaadeldakse Kubernetesi standardsete tööriistade abil.
Mustri tugevuseks on küpse ökosüsteemiga laevastiku mastaabis haldamine. Selle nõrkuseks on punktis 5.4 käsitletud toimimise keerukus, mis õigustab mustrit ainult piisava ulatusega.
6.3 GitOps Edge'i konfigureerimiseks
Mõlema mustri puhul kirjeldatakse versioonikontrollitud hoidlas deklaratiivselt lüüside konfiguratsiooni – milliseid konteinereid käivitatakse, milliseid pilte juurutatakse, millised ressursid eraldatakse. Lüüsis või pilves oleval kontrolleril töötav kooskõlastuskontroller (Flux, Argo CD, Fleet) jälgib lõhet vaadeldava ja soovitud oleku vahel ning rakendab selle sulgemiseks vajalikke muudatusi.
Selle mustri tugevuseks on kontrollitavus ja aatomilisus laevastiku tasandil. Täielik sõidukipargi konfiguratsiooni ajalugu on jäädvustatud Gitis. Rollback on Giti operatsioon. Muster on laenatud peaaegu muutmata pilvepõhistest operatsioonidest ja see tõlgib hästi servadesse.
6.4 Tarneahela turvalisus
Tööstusliku kasutuselevõtu puhul on konteineripiltide tarneahela turvalisus operatiivselt oluline. Küps muster sisaldab:
See ei ole tööstusliku juurutamise puhul vabatahtlik. Tarneahela rünnakud, mis on viimase viie aasta jooksul toimunud tarkvara pakendamise ökosüsteemide vastu – SolarWinds, erinevad npm ja PyPI kompromissid – näitavad, et oht on reaalne ja kaitsemeetmed on vajalikud.
- Kujutise loomine usaldusväärses dokumenteeritud päritoluga CI infrastruktuuris (SLSA raamistik [18])
- Pildi allkirjastamine Sigstore'iga [19] või samaväärsega
- Päritolutõend vastavalt spetsifikaadile [22]
- Tarkvara materjalide koostamine pärast SPDX [23] või CycloneDX
- Pidev haavatavuse kontrollimine Trivy, Grype'i või kaubanduslike ekvivalentidega
- Sissepääsu kontroll lüüsi tasemel, mis keeldub allkirjastamata või haavatavatest piltidest
6.5 Riistvara juurdepääsu mustrid
Tööstuslikud töökoormused nõuavad sageli juurdepääsu füüsilisele riistvarale: jadapordid, GPIO-viigud, CAN-siinid, tööstuslikud väljasiinid, GPU-kiirendid. Konteinermudel mahutab selle seadme cgruppide ja selgesõnaliste seadmekinnituste kaudu.
Distsiplineeritud muster on panna konkreetsed seadmed konkreetsetele konteineritele selle asemel, et käitada privilegeeritud konteinereid, millel on täielik juurdepääs hostile. Kerneli seadme cgroup kontroller võimaldab täpset juurdepääsukontrolli. udev-reeglid võivad vastendada füüsilised seadmed stabiilsete nimedega, millele konteinerid viitavad. GPU-juurdepääsu jaoks pakuvad NVIDIA Container Toolkit ja samaväärsed riistvarajuurdepääsu ilma privileegide suurendamiseta.
6.6 Reaalajas suurendamine
Reaalajas nõuetega juurutuste puhul ühendab muster PREEMPT_RT kerneli, protsessori isoleerimise alglaadimisparameetri `isolcpus' kaudu, spetsiaalsed reaalajas c-rühmad ja töökoormuse hoolika paigutuse. Konteineri liides on säilinud, kuid selle aluseks olev planeerija on konfigureeritud reaalajas töökoormuse jaoks.
See on inseneritöö, mitte funktsioonide lipp, vaid see on hästi dokumenteeritud inseneritöö [13][14], mis pakub latentsusprofiile, mis vastavad kõikidele nõuetele, välja arvatud kõige nõudlikumad reaalajas töökoormused.
Avatud probleemid ja vastutustundlik lapsendamine
Tööstusliku konteineri vedamise vajadus on tugev, kuid mitte ebamäärane. Mitmed lahtised probleemid nõuavad selgesõnalist tunnustamist.
Kujutise suuruse distsipliin. Konteinerite kujutised kasvavad sageli gigabaitideni kogunenud sõltuvuste, silumistööriistade ja põhikujutise paisumise tõttu. Piiratud ribalaiusega tööstuslike juurutuste puhul, kus piltide tõmbamine toimub mobiilside- või satelliidiühenduste kaudu, on see kulukas. Distsiplineeritud tavad (distroosideta baaspildid [24], mitmeastmelised järgud, hoolikas sõltuvushaldus) hoiavad enamiku töökoormuste puhul tootmispildid alla 100 MB, kuid distsipliin ei ole automaatne.
Oskuste arendamine. Konteinerite ökosüsteem eeldab sellise toimimise keerukust, mida tööstusinseneride meeskondades ei esine ühtlaselt. Selle lünga kaotamine nõuab selget investeeringut koolitusse, tööpinda vähendavatesse tööriistadesse ja mustritesse, mis võimaldavad OT-meeskondadel kasutada konteinerite infrastruktuuri, ilma et nad saaksid Kubernetese spetsialistideks.
Jälgitavus sõidukipargi skaalal. Tuhande konteinerite lüüsi kaudu loodud telemeetria loob omaette telemeetria. Valimine, milliseid mõõdikuid väljastada, millise täpsusega ja kuidas neid koondada, on lahendamata inseneriprobleem. OpenTelemetry [25] on olukorda parandanud, kuid servaspetsiifilised mustrid jäävad vähearenenud.
Pikaajaline kujutise säilitamine. Täna juurutatud konteineri kujutis peab jääma käitatavaks täna juurutatud riistvaraga, viieteistkümne aasta pärast pärast seda, kui kujutist algselt hostinud register on omanikku vahetanud või lakanud eksisteerimast. Tööstuslikud juurutused nõuavad selgesõnalist kujutise säilitamist – kohalikud registrid, arhiveeritud pildid, dokumenteeritud sõltuvused –, mis ei ole laiema konteineri ökosüsteemi vaiketöörežiim.
Riistvara abstraktsioonipiirangud. Mõni tööstuslik riistvara – eriti FPGA-d, spetsiaalsed I/O-kaardid ja patenteeritud kerneli draiveritega riistvara – ei abstraheerita puhtalt konteinermudelisse. Nende töökoormuste puhul on konteinerisse paigutamine osaline: kasutajaruumi komponent on konteinerisse paigutatud, samas kui kerneli draiver jääb hostitaseme probleemiks. See on vastuvõetav, kuid loob seose, mida distsiplineeritud kasutuselevõtt peab selgesõnaliselt haldama.
Need probleemid on tõelised ja nõuavad pidevaid inseneriinvesteeringuid. Need ei muuda jaatavat juhtumit kehtetuks; nad kvalifitseerivad selle.
Lõppargument
Argumendi võib esitada kompaktselt. Tööstustarkvara on ajalooliselt kannatanud struktuurse probleemi käes: lõhe rakenduse ja töökeskkonna vahel on kontrollimatu, põhjustades sõltuvuse triivi, reprodutseeritavuse tõrkeid, juurutamise haprust ja raskesti kaitstavaid turvapositsioone. Konteinerid täidavad selle lünga, juurutades rakenduse koos selle sõltuvustega krüptograafiliselt reprodutseeritava, atomaarselt värskendatava ja isoleeritava artefaktina. Tehnoloogia on oma kontseptuaalsetelt alustelt neli aastakümmet vana, seda juhivad avatud standardid ja mis on operatiivselt kinnitatud hüperskaalamise skaalal. Tööstusliku kasutuselevõtu vastu esitatud vastuväited on tõelised, kuid kontrollitavad – need tuvastavad teadaolevate lahendustega tehnilisi probleeme, mitte struktuurseid vastuolusid.
Struktuurne alternatiiv konteineriseerimisele on ajaloolise praktika jätkamine: eritellimusel kasutuselevõtt platvormi kohta, reprodutseerimatud tootmiskeskkonnad, rabed värskendusmehhanismid ja tööisolatsioon laiemast tarkvara ökosüsteemist. See alternatiiv ei ole stabiilne tasakaal. See on status quo, mille piirangud on praegu piisavalt nähtavad, et tööstus liigub sellest eemale, ja küsimus ei ole selles, kas konteinerid kasutusele võtta, vaid kuidas neid hästi kasutusele võtta.
Järgnev soovitus on otsene. Tööstuslikud tootesarjad tuleks algusest peale kavandada konteinerites kasutamiseks. Vajalikud investeeringud – tarneahela turvalisusse, vaadeldavuse tööriistadesse, oskuste arendamisse, kuvandi säilitamise distsipliini – tuleks selgelt kavandada ja eelarvesse lisada. Jaotises 6 kirjeldatud mustreid tuleks praktika küpsedes omaks võtta, kohandada ja edasi arendada.
Alternatiiv on jääda arhitektuurirežiimi, mis on oma elujõulisuse ära elanud. Üleminek ei ole kulukas. See on oluliselt odavam kui selle tegemata jätmine.
References
[1] S. Hykes. Linuxi konteinerite tulevik. PyCon USA, 2013.
[2] E. W. Biederman. "Globaalsete Linuxi nimeruumide mitu eksemplari." Linux Symposium, 2006.
[3] P. B. Menage. "Linux-i tuumale üldiste protsessikonteinerite lisamine." Linux Symposium, 2007.
[4] N. Brown. "Ülekatte failisüsteem." Linuxi tuuma dokumentatsioon, 2014.
[5] Avatud konteinerite algatus. Käitusaja spetsifikatsioonid, kujutise spetsifikatsioonid ja levitamise spetsifikatsioonid. 2017–praegu. https://opencontainers.org
[6] D. M. Ritchie ja K. Thompson. Unixi programmeerija käsiraamat, seitsmes väljaanne. Bell Laboratories, 1979.
[7] P.-H. Kamp ja R. N. M. Watson. "Vanglad: kõikvõimsa juure piiramine." Teine rahvusvaheline SANE konverents, 2000.
[8] D. Price ja A. Tucker. "Solarise tsoonid: operatsioonisüsteemi tugi kaubandusliku töökoormuse konsolideerimiseks." USENIX LISA, 2004.
[9] D. Lezcano jt. Linux Containers (LXC) projekt. 2008–praegu. https://linuxcontainers.org
[10] A. Verma jt. "Google'i laiaulatuslik klastrihaldus koos Borgiga." EuroSys, 2015.
[11] B. Burns et al. "Borg, Omega ja Kubernetes." ACMi teatised, 59(5), 2016.
[12] National Institute of Standards and Technology. Rakenduse konteineri turvajuhend. NISTi eriväljaanne 800-190, 2017.
[13] T. Gleixner ja I. Molnar. PREEMPT_RT: Linuxi tuuma reaalajas eesõiguspaigad. https://wiki.linuxfoundation.org/realtime/
[14] L. Abeni jt. Konteineripõhine reaalajas planeerimine Linuxi tuumas. ACM SIGBED ülevaade, 16(3), 2019.
[15] Kata konteinerite projekt. Kata konteinerid: konteinerite kiirus, VM-ide turvalisus. https://katacontainers.io
[16] A. Agache jt. "Firecracker: kerge virtualiseerimine serverita rakenduste jaoks." USENIX NSDI, 2020.
[17] gVisori projekt. gVisor: rakenduse kernel konteineritele. Google, 2018. https://gvisor.dev
[18] Google jt. Tarneahela tasemed tarkvaraartefaktide jaoks (SLSA). Open Source Security Foundation, 2021–praegu. https://slsa.dev
[19] Linuxi sihtasutus. Sigstore: tarkvara allkirjastamine kõigile. https://sigstore.dev
[20] Rancher Labs / SUSE. K3s: kerge Kubernetes. https://k3s.io
[21] CNCF. KubeEdge: Kubernetes-Native Edge Computing Framework. https://kubeedge.io
[22] S. Torres-Arias jt. "in-toto: talust lauani garantiide pakkumine bittide ja baitide jaoks." USENIXi turvalisus, 2019.
[23] Linuxi sihtasutus. Tarkvarapaketi andmevahetuse (SPDX) spetsifikatsioon. ISO/IEC 5962:2021.
[24] Google. Distroless konteineri pildid. https://github.com/GoogleContainerTools/distroless
[25] OpenTelemetry projekt. OpenTelemetry spetsifikatsioon. CNCF, 2019–praegu. https://opentelemetry.io
[26] C. Fowler. "Prügi oma serverid prügikasti ja põletage oma kood: muutumatu infrastruktuur ja ühekordsed komponendid." 2013. aasta.
[27] J. Cappos et al. "Tarkvaravärskendussüsteemide ellujäämise võtmekompromiss." ACM CCS, 2010. (The Update Framework / TUF.)
[28] Rahvusvaheline elektrotehnikakomisjon. IEC 62443-4-1: Turvalise tootearenduse elutsükli nõuded. 2018.
[29] B. Cantrill ja J. Bonwick. "Reaalmaailma samaaegsus." ACMi teatised, 51(11), 2008.
[30] M. Souppaya, J. Morello ja K. Scarfone. NIST SP 800-204C: DevSecOpsi juurutamine teenusevõrguga mikroteenustel põhineva rakenduse jaoks. 2022.
*See artikkel on osa Modibusi tehnilisest sarjast. Tööstusvärav Modibus MB213 on loodud esmaklassiliseks konteinerarvutiplatvormiks, mis toetab Dockeri, Podmani ja kergekaalulisi Kubernetese distributsioone. Riistvaraline kiirendus on konteineris töökoormustele juurdepääsetav jaotises 6 kirjeldatud mustrite kaudu. Tehniliste arutelude või platvormipäringute saamiseks võtke ühendust aadressil [info@modibus.com].