Docker dhe kontejnerët: përfitimet, kostot operative dhe zgjedhja e platformës

Imazhi, kontejneri dhe makina virtuale

Një aplikacion mund të funksionojë në testim, por të dështojë në një server për shkak të versionit të mjedisit të ekzekutimit, një biblioteke që mungon ose një cilësimi lokal të pavërejtur. Kontejnerët i pakësojnë këto dallime duke kaluar një paketë të gjurmueshme nëpër zhvillim, testim dhe prodhim. Ata nuk zëvendësojnë arkitekturën e përshtatshme ose funksionimin me përgjegjësi të qarta.

Një imazh është paketa e versionuar e aplikacionit dhe skedarët e mjedisit të ekzekutimit; një kontejner është një instancë në punë. Jepni konfigurimin dhe të dhënat e hyrjes veçmas dhe ruani në mënyrë të pavarur të dhënat e qëndrueshme. Kontejnerët Linux ndajnë kernelin e mjedisit të ekzekutimit, ndërsa një makinë virtuale ka një sistem operativ mysafir. Kontejnerët shpesh punojnë brenda makinave virtuale, prandaj këto qasje mund të plotësojnë njëra-tjetrën.

«Identik kudo» është tepër e përgjithshme: arkitektura e procesorit, sistemi operativ, lejet, shërbimet e jashtme dhe memoria ende ndikojnë në sjellje. Një imazh mund të jetë i madh dhe një aplikacion mund të niset ngadalë gjatë ngarkimit të të dhënave. Matni përmirësimin real të publikimit në vend që të supozoni vendosje universalisht më të vogla ose më të shpejta.

Zgjidhni platformën sipas situatës

Docker e dokumenton Compose në një server të vetëm prodhimi me konfigurim specifik për prodhimin. Ai nuk kufizohet te zhvillimi, por nuk krijon më vete një mjedis me disa serverë dhe disponueshmëri të lartë.

Merrni parasysh Kubernetes kur publikimet e pavarura, shumë ngarkesa pune dhe vendosja automatike zgjidhin punë operacionale të përsëritura. Rinisja kërkon kapacitet, të dhëna dhe varësi të disponueshme. Një vendosje me pak ndërprerje kërkon instanca të mjaftueshme në punë dhe versione të përputhshme gjatë kalimit.

• Portal i vogël i brendshëm dhe një ekip: një makinë virtuale me Compose dhe vendosje të dokumentuar; pranoni rrezikun e përbashkët të dështimit të një hosti të vetëm.
• Aplikacion publik me pak personel platforme: një shërbim i menaxhuar kontejnerësh; vlerësoni kufizimet e platformës, kostot e përdorimit dhe eksportin e të dhënave.
• Disa ekipe dhe shërbime të pavarura: orkestrimi, mundësisht Kubernetes; caktoni përgjegjësinë për cluster-in, rrjetin, politikat dhe përditësimet e platformës.

Shembull: një portal klientësh me import çdo natë

Supozoni se portali përbëhet nga një aplikacion uebi, një bazë të dhënash dhe një proces importi që publikohen së bashku nga një ekip i vogël. Ndërtoni aplikacionin dhe importuesin si imazhe të veçanta, të identifikueshme, duke e lënë bazën e të dhënave në platformën e saj ekzistuese të mirëmenaxhuar. Publikimet e riprodhueshme të aplikacionit nuk kërkojnë migrimin e të gjitha të dhënave njëkohësisht.

Testoni të njëjtat imazhe që synohen për prodhim, me të dhëna hyrjeje dhe të dhëna testimi të veçanta. Jepini importuesit një kufi memorie të bazuar në matje, që një skedar i madh të mos i marrë portalit burimet në mënyrë të paparashikueshme. Para zgjerimit në disa hoste, përgatitni shprehimisht skedarët e përbashkët, sesionet dhe gjendjen e importit për atë projektim.

Ndërtimet e riprodhueshme kërkojnë sërish përditësime

Ndërtimet me disa faza i ndajnë mjetet e ndërtimit nga imazhi i ekzekutimit. Varësitë e fiksuara dhe një imazh bazë i identifikueshëm e bëjnë një publikim të riprodhueshëm, por ngrijnë edhe versionet e pranishme në atë moment. Imazhet ekzistuese nuk marrin automatikisht paketa të reja. Planifikoni imazhe të rindërtuara dhe të testuara.

Regjistroni identifikuesin e imazhit, revizionin e kodit burimor, ndryshimet e konfigurimit dhe migrimet e bazës së të dhënave. Një etiketë e ndryshueshme si latest nuk mjafton më vete. Mbajini sekretet në administrimin e kredencialeve të mjedisit; përfshirja e tyre brenda një imazhi i shpërndan me çdo shkarkim dhe e ndërlikon rotacionin.

Të dhënat dhe kthimi pas janë pjesët më të vështira

Rinisja e një kontejneri mund të zëvendësojë procesin e aplikacionit, por nuk mund të rikthejë të dhënat e klientëve të ndryshuara aksidentalisht. Vëllimet e qëndrueshme dhe bazat e të dhënave kanë nevojë për kopje rezervë të testuara. Një imazh më i vjetër është kthim pas i vlefshëm vetëm nëse e kupton skemën aktuale; ndajini ndryshimet në faza të përputhshme kur është e nevojshme.

Para zgjedhjes së platformës, bini dakord për ndërprerjen e tolerueshme, mbështetjen e publikimeve dhe mbulimin gjatë pushimeve ose sëmundjes. Kostot përfshijnë regjistrin e imazheve, regjistrat e ngjarjeve, monitorimin, kopjet rezervë dhe kohën e personelit. Një server i lirë me shumë mbështetje manuale mund të kushtojë më shumë në total se një shërbim i menaxhuar.

Mateni projektin pilot kundrejt një problemi ekzistues

Dokumentoni kush e ndërton aplikacionin, hapat manualë të publikimit dhe dallimet midis testimit dhe prodhimit. Zgjidhni një aplikacion me kufij të qartë, varësi të kuptuara dhe pasoja dështimi të menaxhueshme. Një sistem bazë kritik i padokumentuar rrallë është vendi më i mirë për të mësuar njëkohësisht një platformë të re funksionimi.

Vendosni një objektiv të verifikueshëm: një person i dytë mund të vendosë një version të miratuar në një mjedis testimi bosh duke ndjekur dokumentacionin. Matni punën aktive, kohën totale dhe korrigjimet manuale. Përsëriteni me një publikim tjetër; një kontejner i nisur me sukses nuk është provë e mjaftueshme.

Testoni burimet dhe defektet në mënyrë realiste

Përdorni një ngarkesë përfaqësuese: hyrje të njëkohshme, një kërkim dhe importin më të madh normal. Vëzhgoni kohën e përgjigjes, memorien, CPU-në dhe hapësirën e lirë në disk. Kufijtë ndihmojnë vetëm kur njihet sjellja në prag; kufijtë tepër të ngushtë mund të shkaktojnë vetë incidente.

Në testim, ushtroni një rinisje, një varësi përkohësisht të padisponueshme dhe një proces në sfond të dështuar. Prisni gabime të kuptueshme, mungesë të punës së dyfishuar në heshtje dhe regjistra që identifikojnë publikimin. Qëllimi është një proces dështimi i kontrolluar, jo grumbullimi i skenarëve arbitrarë të defekteve.

Publikimi i dytë provon mundësinë e funksionimit

Pranimi përfshin një përditësim imazhi dhe një ndryshim të vogël të përputhshëm të të dhënave. Kontrolloni rrugëtimet e dakordësuara të përdoruesve para dhe pas. Dokumentoni kur funksionon kthimi te imazhi i vjetër dhe kur të dhënat e reja kërkojnë fillimisht rakordim; mos e lini këtë vendim për momentin e një ndërprerjeje.

Dorëzimi cakton mirëmbajtjen e imazhit bazë, hostit, mjedisit të ekzekutimit, regjistrit të imazheve dhe aplikacionit, edhe nëse një furnizues i vetëm i kryen të gjitha. Përcaktoni ruajtjen e imazheve, vëllimin e regjistrave dhe paralajmërimet e rritjes. Vetëm kur përditësimet dhe mbulimi nga zëvendësuesit funksionojnë duhet të bëhet projekti pilot një standard i ripërdorshëm.