Rhywsut ar un adeg penderfynais ysgrifennu erthygl am ddosbarthu ar ffurf cynwysyddion Docker a phecynnau deb, ond pan ddechreuais, am ryw reswm fe'm cariwyd yn ôl i amseroedd pell y cyfrifiaduron personol cyntaf a hyd yn oed cyfrifianellau. Yn gyffredinol, yn lle cymariaethau sych o docwr a dyled, cawsom y meddyliau hyn ar bwnc esblygiad, yr wyf yn ei gyflwyno i chi ei ystyried.
Rhaid i unrhyw gynnyrch, ni waeth beth ydyw, gyrraedd y gweinyddwyr cynnyrch rywsut, rhaid ei ffurfweddu a'i lansio. Dyna beth fydd yr erthygl hon yn ymwneud.
Byddaf yn meddwl mewn cyd-destun hanesyddol, “yr hyn rwy'n ei weld yw'r hyn rwy'n canu amdano,” yr hyn a welais pan ddechreuais ysgrifennu cod gyntaf a'r hyn yr wyf yn ei arsylwi nawr, yr hyn yr ydym ni ein hunain yn ei ddefnyddio ar hyn o bryd a pham. Nid yw'r erthygl yn esgus bod yn astudiaeth lawn, mae rhai pwyntiau'n cael eu methu, dyma fy marn bersonol i o'r hyn oedd a beth sydd nawr.
Felly, yn yr hen ddyddiau da... y dull cynharaf o ddosbarthu a ddarganfyddais oedd tapiau casét o recordwyr tâp. Roedd gen i gyfrifiadur BK-0010.01...
Oes y cyfrifianellau
Na, roedd eiliad hyd yn oed yn gynharach, roedd yna gyfrifiannell hefyd и .
Felly pan gefais , yna'r ffordd i drosglwyddo'r rhaglen oedd darn arferol o bapur mewn blwch yr ysgrifennwyd rhaglen arno, a oedd, os oedd angen, i'w redeg â llaw, wedi'i ysgrifennu yn y gyfrifiannell. Os ydych chi eisiau chwarae (ie, roedd gan y gyfrifiannell antedilwaidd hon gemau) - rydych chi'n eistedd i lawr ac yn nodi'r rhaglen yn y gyfrifiannell. Yn naturiol, pan ddiffoddwyd y gyfrifiannell, diflannodd y rhaglen i ebargofiant. Yn ogystal â'r codau cyfrifiannell a ysgrifennwyd ar bapur yn ei law ei hun, cyhoeddwyd y rhaglenni yn y cylchgronau “Radio” a “Technology for Youth”, ac fe'u cyhoeddwyd hefyd mewn llyfrau o'r cyfnod hwnnw.
Yr addasiad nesaf oedd cyfrifiannell , mae ganddo eisoes rywfaint o storio data nad yw'n gyfnewidiol. Nawr nid oedd yn rhaid mynd i mewn i'r gêm neu'r rhaglen â llaw, ond ar ôl perfformio rhai pasiau hudol gyda'r botymau, fe lwythodd ei hun.
Maint y rhaglen fwyaf yn y gyfrifiannell oedd 105 cam, a maint y cof parhaol yn MK-52 oedd 512 cam.
Gyda llaw, os oes yna gefnogwyr o'r cyfrifianellau hyn yn darllen yr erthygl hon, yn y broses o ysgrifennu'r erthygl fe wnes i ddod o hyd i efelychydd cyfrifiannell ar gyfer Android a rhaglenni ar ei gyfer. Ymlaen i'r gorffennol!
Digression byr am MK-52 (o Wicipedia)
Hedfanodd MK-52 i'r gofod ar y llong ofod Soyuz TM-7. Roedd i fod i gael ei ddefnyddio i gyfrifo'r llwybr glanio rhag ofn i'r cyfrifiadur ar y bwrdd fethu.
Ers 52, mae'r MK-1988 gydag uned ehangu cof Elektronika-Astro wedi'i gyflenwi i longau'r Llynges fel rhan o becyn cyfrifiadurol mordwyo.
Y cyfrifiaduron personol cyntaf
Gadewch i ni fynd yn ôl at yr amseroedd . Mae’n amlwg bod mwy o gof yno, ac nid oedd teipio cod o ddarn o bapur bellach yn opsiwn (er mai dyna’n union y gwnes i ar y dechrau, oherwydd yn syml, nid oedd unrhyw gyfrwng arall). Mae casetiau sain ar gyfer recordwyr tâp yn dod yn brif ddull o storio a dosbarthu meddalwedd.
Roedd storio ar gasét fel arfer ar ffurf un neu ddwy ffeil ddeuaidd, roedd popeth arall wedi'i gynnwys y tu mewn. Roedd dibynadwyedd yn isel iawn, roedd yn rhaid i mi gadw 2-3 copi o'r rhaglen. Roedd amseroedd llwytho hefyd yn siomedig, ac arbrofodd selogion gydag amgodiadau amlder gwahanol i oresgyn y diffygion hyn. Ar y pryd, nid oeddwn i fy hun yn ymwneud â datblygu meddalwedd proffesiynol eto (heb gyfrif rhaglenni syml yn SYLFAENOL), felly, yn anffodus, ni fyddaf yn dweud wrthych yn fanwl sut y trefnwyd popeth y tu mewn. Roedd y ffaith mai dim ond RAM oedd gan y cyfrifiadur ar y cyfan yn pennu symlrwydd y cynllun storio data.
Ymddangosiad cyfryngau storio dibynadwy a mawr
Yn ddiweddarach, ymddangosodd disgiau hyblyg, symleiddiwyd y broses gopïo, a chynyddodd dibynadwyedd.
Ond mae'r sefyllfa'n newid yn ddramatig dim ond pan fydd storfeydd lleol digon mawr yn ymddangos ar ffurf HDDs.
Mae'r math o gyflenwi yn newid yn sylfaenol: mae rhaglenni gosodwyr yn ymddangos sy'n rheoli'r broses o ffurfweddu'r system, yn ogystal â glanhau ar ôl ei dynnu, gan nad yw rhaglenni'n cael eu darllen yn y cof yn unig, ond maent eisoes wedi'u copïo i storfa leol, y mae angen i chi wneud hynny. gallu clirio pethau diangen os oes angen.
Ar yr un pryd, mae cymhlethdod y meddalwedd a gyflenwir yn cynyddu.
Mae nifer y ffeiliau yn y dosbarthiad yn cynyddu o ychydig i gannoedd a miloedd, mae gwrthdaro rhwng fersiynau llyfrgell a llawenydd eraill yn dechrau pan fydd rhaglenni gwahanol yn defnyddio'r un data.
Ar y pryd, nid oedd bodolaeth Linux yn agored i mi eto; roeddwn i'n byw ym myd MS DOS ac, yn ddiweddarach, Windows, ac yn ysgrifennu yn Borland Pascal a Delphi, weithiau'n edrych tuag at C ++. Defnyddiodd llawer o bobl InstallShield i ddosbarthu cynhyrchion yn ôl bryd hynny. , a lwyddodd i ddatrys yr holl dasgau a neilltuwyd o ran defnyddio a ffurfweddu'r feddalwedd.
Oes rhyngrwyd
Yn raddol, mae cymhlethdod systemau meddalwedd yn dod yn fwy cymhleth fyth; o'r monolith a'r cymwysiadau bwrdd gwaith mae trosglwyddiad i systemau gwasgaredig, cleientiaid tenau a microwasanaethau. Nawr mae angen i chi ffurfweddu nid yn unig un rhaglen, ond set ohonynt, ac fel eu bod i gyd yn gweithio gyda'i gilydd.
Newidiodd y cysyniad yn llwyr, daeth y Rhyngrwyd, cyrhaeddodd cyfnod gwasanaethau cwmwl. Hyd yn hyn, dim ond yn y cam cychwynnol, ar ffurf gwefannau, nid oes neb wedi breuddwydio'n arbennig am wasanaethau. ond roedd yn drobwynt o ran datblygu a chyflwyno ceisiadau.
I mi fy hun, sylwais fod yna newid ar y foment honno mewn cenedlaethau o ddatblygwyr (neu dim ond yn fy amgylchedd i), ac roedd teimlad bod yr holl hen ddulliau cyflwyno da yn cael eu hanghofio ar un eiliad a bod popeth yn dechrau o'r iawn. dechrau: dechreuwyd gwneud pob cyflwyniad yn sgriptiau pen-glin a'i alw'n falch yn “Cyflenwi parhaus”. Mewn gwirionedd, mae cyfnod o anhrefn wedi dechrau, pan fydd yr hen yn cael ei anghofio a heb ei ddefnyddio, ac nid yw'r newydd yn bodoli.
Rwy'n cofio'r adegau pan yn ein cwmni lle roeddwn i'n gweithio bryd hynny (ni fyddaf yn ei enwi), yn lle adeiladu trwy forgrugyn (nid oedd maven yn boblogaidd eto neu nid oedd yn bodoli o gwbl), roedd pobl yn syml yn casglu jariau yn y DRhA ac wedi ymrwymo'n dawel. ei fod yn SVN. Yn unol â hynny, roedd y defnydd yn cynnwys adfer y ffeil o SVN a'i chopïo trwy SSH i'r peiriant a ddymunir. Mae mor syml a thrwsgl.
Ar yr un pryd, gwnaed cyflwyno gwefannau syml yn PHP mewn ffordd gyntefig iawn trwy gopïo'r ffeil wedi'i chywiro trwy FTP i'r peiriant targed. Weithiau nid oedd hyn yn wir - roedd y cod yn cael ei olygu'n fyw ar y gweinydd cynnyrch, ac roedd yn arbennig o chic os oedd copïau wrth gefn yn rhywle.
Pecynnau RPM a DEB
Ar y llaw arall, gyda datblygiad y Rhyngrwyd, dechreuodd systemau tebyg i UNIX ennill mwy a mwy o boblogrwydd, yn benodol, yr adeg honno y darganfyddais RedHat Linux 6, tua 2000. Yn naturiol, roedd yna hefyd ffyrdd penodol ar gyfer cyflwyno meddalwedd; yn ôl Wikipedia, roedd RPM fel y prif reolwr pecyn eisoes yn ymddangos yn 1995, yn y fersiwn o RedHat Linux 2.0. Ac ers hynny a hyd heddiw, mae'r system wedi'i chyflwyno ar ffurf pecynnau RPM ac mae wedi bod yn bodoli ac yn datblygu'n eithaf llwyddiannus.
Dilynodd dosbarthiad y teulu Debian lwybr tebyg a gweithredu darpariaeth ar ffurf pecynnau dadleuol, sydd wedi aros yn ddigyfnewid hyd heddiw.
Mae rheolwyr pecynnau yn caniatáu ichi gyflwyno'r cynhyrchion meddalwedd eu hunain, eu ffurfweddu yn ystod y broses osod, rheoli dibyniaethau rhwng gwahanol becynnau, tynnu cynhyrchion a glanhau eitemau diangen yn ystod y broses ddadosod. Y rhai. ar y cyfan, dyna'r cyfan sydd ei angen, a dyna pam y bu iddynt bara sawl degawd bron heb newid.
Mae cyfrifiadura cwmwl wedi ychwanegu gosodiad i reolwyr pecyn nid yn unig o gyfryngau ffisegol, ond hefyd o ystorfeydd cwmwl, ond yn sylfaenol ychydig sydd wedi newid.
Mae'n werth nodi bod rhai symudiadau ar hyn o bryd tuag at symud i ffwrdd o deb a newid i becynnau snap, ond mwy ar hynny yn nes ymlaen.
Felly, tyfodd y genhedlaeth newydd hon o ddatblygwyr cwmwl, nad oedd yn gwybod na DEB nac RPM, yn araf hefyd, enillodd brofiad, daeth cynhyrchion yn fwy cymhleth, ac roedd angen rhai dulliau cyflwyno mwy rhesymol na FTP, sgriptiau bash a chrefftau myfyrwyr tebyg.
A dyma lle mae Docker yn dod i mewn i'r llun, math o gymysgedd o rithwiroli, amffinio adnoddau a dull cyflwyno. Mae'n ffasiynol ac yn ifanc nawr, ond a oes ei angen ar gyfer popeth? A yw hyn yn ateb i bob problem?
O’m harsylwadau, yn aml iawn cynigir Docker nid fel dewis rhesymol, ond yn syml oherwydd, ar y naill law, y sonnir amdano yn y gymuned, a’r rhai sy’n ei gynnig yn unig sy’n gwybod hynny. Ar y llaw arall, ar y cyfan maent yn dawel am yr hen systemau pecynnu da - maent yn bodoli ac yn gwneud eu gwaith yn dawel ac yn ddisylw. Mewn sefyllfa o'r fath, nid oes unrhyw ddewis arall mewn gwirionedd - mae'r dewis yn amlwg - Docker.
Byddaf yn ceisio rhannu fy mhrofiad o sut y gwnaethom weithredu Docker a'r hyn a ddigwyddodd o ganlyniad.
Sgriptiau hunan-ysgrifenedig
I ddechrau, roedd sgriptiau bash a oedd yn defnyddio archifau jariau i'r peiriannau gofynnol. Rheolwyd y broses hon gan Jenkins. Gweithiodd hyn yn llwyddiannus, gan fod yr archif jar ei hun eisoes yn gynulliad sy'n cynnwys dosbarthiadau, adnoddau a hyd yn oed ffurfweddiad. Os rhowch bopeth i'r eithaf, yna nid ei ehangu i sgript yw'r peth anoddaf sydd ei angen arnoch chi
Ond mae gan sgriptiau sawl anfantais:
- mae sgriptiau fel arfer yn cael eu hysgrifennu ar frys ac felly mor gyntefig fel eu bod yn cynnwys un senario achos gorau yn unig. Hwylusir hyn gan y ffaith bod gan y datblygwr ddiddordeb mewn darpariaeth gyflym, ac mae sgript arferol yn gofyn am fuddsoddi swm teilwng o adnoddau.
- o ganlyniad i'r pwynt blaenorol, nid yw'r sgriptiau'n cynnwys gweithdrefnau dadosod
- dim gweithdrefn uwchraddio sefydledig
- Pan fydd cynnyrch newydd yn ymddangos, mae angen i chi ysgrifennu sgript newydd
- dim cefnogaeth dibyniaeth
Wrth gwrs, gallwch chi ysgrifennu sgript soffistigedig, ond, fel yr ysgrifennais uchod, amser datblygu yw hwn, ac nid y lleiaf, ac, fel y gwyddom, nid oes digon o amser bob amser.
Mae hyn i gyd yn amlwg yn cyfyngu ar ystod y defnydd o'r dull lleoli hwn i'r systemau symlaf yn unig. Mae'r amser wedi dod i newid hyn.
Docker
Ar ryw adeg, dechreuodd canolwyr wedi'u bathu'n ffres ddod atom, yn llawn syniadau ac yn frwd am y docwr. Wel, fflag mewn llaw - gadewch i ni ei wneud! Bu dwy ymgais. Roedd y ddau yn aflwyddiannus - gadewch i ni ddweud, oherwydd uchelgeisiau mawr, ond diffyg profiad go iawn. A oedd angen ei orfodi a'i orffen trwy unrhyw fodd posibl? Mae'n annhebygol - rhaid i'r tîm esblygu i'r lefel ofynnol cyn y gall ddefnyddio'r offer priodol. Yn ogystal, wrth ddefnyddio delweddau Docker parod, rydym yn aml yn dod ar draws y ffaith nad oedd y rhwydwaith yn gweithio'n gywir (a allai fod oherwydd lleithder y Dociwr ei hun) neu ei bod yn anodd ehangu cynwysyddion pobl eraill.
Pa anghyfleustra y daethom ar eu traws?
- Problemau rhwydwaith yn y modd pont
- Mae'n anghyfleus gweld logiau mewn cynhwysydd (os na chânt eu storio ar wahân yn system ffeiliau'r peiriant gwesteiwr)
- Weithiau mae ElasticSearch yn rhewi'n rhyfedd y tu mewn i'r cynhwysydd, nid yw'r rheswm wedi'i benderfynu, mae'r cynhwysydd yn swyddogol
- Mae angen defnyddio cragen y tu mewn i gynhwysydd - mae popeth wedi'i dynnu i lawr, nid oes unrhyw offer cyfarwydd
- Maint mawr y cynwysyddion a gasglwyd - drud i'w storio
- Oherwydd maint mawr y cynwysyddion, mae'n anodd cefnogi fersiynau lluosog
- Amser adeiladu hirach, yn wahanol i ddulliau eraill (sgriptiau neu becynnau dadleuol)
Ar y llaw arall, pam ei bod hi'n waeth defnyddio gwasanaeth Gwanwyn ar ffurf archif jar trwy'r un deb? A oes gwir angen ynysu adnoddau? A yw'n werth colli offer system weithredu cyfleus trwy stwffio gwasanaeth i gynhwysydd llawer llai?
Fel y dangosodd arfer, mewn gwirionedd nid yw hyn yn angenrheidiol, mae'r pecyn deb yn ddigon mewn 90% o achosion.
Pryd mae'r hen deb da yn methu a phryd mae gwir angen dociwr?
I ni, roedd hyn yn defnyddio gwasanaethau mewn python. Roedd angen llawer o lyfrgelloedd ar gyfer dysgu peiriannau ac nad oeddent wedi'u cynnwys yn nosbarthiad safonol y system weithredu (a beth oedd y fersiynau anghywir), haciau gyda gosodiadau, arweiniodd yr angen am fersiynau gwahanol ar gyfer gwahanol wasanaethau sy'n byw ar yr un system letyol at hyn , mai'r unig ffordd resymol o gyflwyno'r cymysgedd niwclear hwn oedd y docwr. Roedd dwyster llafur cydosod cynhwysydd dociwr yn troi allan i fod yn is na'r syniad o bacio'r cyfan i becynnau dadleuol ar wahân gyda dibyniaethau, ac mewn gwirionedd ni fyddai neb yn eu iawn bwyll yn ymgymryd â hyn.
Yr ail bwynt lle rydym yn bwriadu defnyddio Docker yw defnyddio gwasanaethau gan ddefnyddio'r cynllun defnyddio gwyrddlas. Ond yma rwyf am gael cynnydd graddol mewn cymhlethdod: yn gyntaf, mae pecynnau deb yn cael eu hadeiladu, ac yna mae cynhwysydd docwr yn cael ei adeiladu oddi wrthynt.
Pecynnau snap
Gadewch i ni ddychwelyd i becynnau snap. Fe wnaethant ymddangos yn swyddogol gyntaf yn Ubuntu 16.04. Yn wahanol i'r pecynnau deb arferol a'r pecynnau rpm, mae snap yn cario'r holl ddibyniaethau. Ar y naill law, mae hyn yn eich galluogi i osgoi gwrthdaro llyfrgell, ar y llaw arall, mae'r pecyn canlyniadol yn fwy o ran maint. Yn ogystal, gall hyn hefyd effeithio ar ddiogelwch y system: yn achos cyflenwi snap, rhaid i'r datblygwr sy'n creu'r pecyn fonitro'r holl newidiadau i'r llyfrgelloedd sydd wedi'u cynnwys. Yn gyffredinol, nid yw popeth mor syml ac nid yw hapusrwydd cyffredinol yn dod o'u defnyddio. Ond, serch hynny, mae hwn yn ddewis arall hollol resymol os defnyddir yr un Dociwr fel offeryn pecynnu yn unig ac nid ar gyfer rhithwiroli.
O ganlyniad, rydym bellach yn defnyddio pecynnau deb a chynwysyddion docwyr mewn cyfuniad rhesymol, ac efallai, mewn rhai achosion, y byddwn yn eu disodli â phecynnau snap.
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Beth ydych chi'n ei ddefnyddio ar gyfer danfon?
-
Sgriptiau hunan-ysgrifenedig
-
Copïwch â llaw i FTP
-
pecynnau deb
-
pecynnau rpm
-
pecynnau snap
-
Docker-delweddau
-
Delweddau peiriant rhithwir
-
Cloniwch y HDD cyfan
-
pypedau
-
ansible
-
eraill
Pleidleisiodd 109 o ddefnyddwyr. Ymataliodd 32 o ddefnyddwyr.
Ffynhonnell: hab.com