Iel iam mi decidis verki artikolon pri livero en formo de Docker-ujoj kaj deb-pakaĵoj, sed kiam mi komencis, ial mi estis portita reen al la malproksimaj tempoj de la unuaj personaj komputiloj kaj eĉ kalkuliloj. Ĝenerale, anstataŭ sekaj komparoj de docker kaj deb, ni ricevis ĉi tiujn pensojn pri la temo de evoluo, kiujn mi prezentas por via konsidero.
Ajna produkto, negrave kio ĝi estas, devas iel atingi la produktajn servilojn, devas esti agordita kaj lanĉita. Pri tio estos ĉi tiu artikolo.
Mi pensos en historia kunteksto, "kio mi vidas, pri kio mi kantas", kion mi vidis kiam mi unue komencis skribi kodon kaj kion mi observas nun, kion ni mem uzas nuntempe kaj kial. La artikolo ne ŝajnigas esti plenrajta studo, kelkaj punktoj estas maltrafitaj, jen mia persona opinio pri kio estis kaj kio estas nun.
Do, en la bonaj tempoj... la plej frua livermetodo, kiun mi trovis, estis kasedoj de magnetofonoj. Mi havis komputilon BK-0010.01...
La epoko de kalkuliloj
Ne, estis eĉ pli frua momento, estis ankaŭ kalkulilo и .
Do kiam mi havis , tiam la maniero transdoni la programon estis ordinara papero en skatolo, sur kiu estis skribita programo, kiu, se necese, por ruli ĝin permane, estis skribita en la kalkulilon. Se vi volas ludi (jes, eĉ ĉi tiu antaŭdiluvia kalkulilo havis ludojn) - vi sidiĝas kaj enigas la programon en la kalkulilon. Nature, kiam la kalkulilo estis malŝaltita, la programo malaperis en forgeson. Krom la kalkulkodoj persone skribitaj sur papero, la programoj estis publikigitaj en la revuoj "Radio" kaj "Teknologio por Junularo", kaj ankaŭ estis publikigitaj en libroj de tiu tempo.
La sekva modifo estis kalkulilo , ĝi jam havas iun ŝajnon de nevolatila datumstokado. Nun la ludo aŭ programo ne devis esti enmetita permane, sed post plenumi kelkajn magiajn enirpermesilojn per la butonoj, ĝi ŝargis sin.
La grandeco de la plej granda programo en la kalkulilo estis 105 ŝtupoj, kaj la grandeco de la konstanta memoro en MK-52 estis 512 ŝtupoj.
Cetere, se estas ŝatantoj de ĉi tiuj kalkuliloj, kiuj legas ĉi tiun artikolon, dum la verkado de la artikolo mi trovis kaj kalkulilon emulilon por Android kaj programojn por ĝi. Antaŭen al la pasinteco!
Mallonga deturniĝo pri MK-52 (el Vikipedio)
MK-52 flugis en kosmon per la kosmoŝipo Soyuz TM-7. Ĝi devis esti uzata por kalkuli la surteriĝotrajektorion, se la surŝipa komputilo malsukcesus.
Ekde 52, la MK-1988 kun la Elektronika-Astro-memora vastiĝunuo estis liverita al mararmeŝipoj kiel parto de navigacia komputika ilaro.
La unuaj personaj komputiloj
Ni reiru al la tempoj . Estas klare, ke tie estis pli da memoro, kaj tajpi kodon el papero ne plu estis eblo (kvankam komence mi faris ĝuste tion, ĉar simple ne estis alia rimedo). Sonkasedoj por magnetofonoj fariĝas la ĉefa rimedo por stoki kaj liveri programaron.
Stokado sur kasedo estis kutime en formo de unu aŭ du binaraj dosieroj, ĉio alia estis enhavita ene. Fidindeco estis tre malalta, mi devis konservi 2-3 kopiojn de la programo. Ŝarĝtempoj ankaŭ estis seniluziigaj, kaj entuziasmuloj eksperimentis kun malsamaj frekvencaj kodigoj por venki ĉi tiujn mankojn. Tiutempe mi mem ankoraŭ ne okupiĝis pri profesia programaro (ne kalkulas simplajn programojn en BASIC), do, bedaŭrinde, mi ne detale rakontos al vi, kiel ĉio estis aranĝita ene. La fakto mem, ke la komputilo havis nur RAM plejparte determinis la simplecon de la datuma stokado.
La apero de fidindaj kaj grandaj stokadmedioj
Poste aperis disketoj, la kopiado estis simpligita, kaj fidindeco pliiĝis.
Sed la situacio draste ŝanĝiĝas nur kiam sufiĉe grandaj lokaj stokaĵoj aperas en formo de HDD-oj.
La speco de livero esence ŝanĝiĝas: instalilo programoj aperas, kiuj administras la procezon de agordo de la sistemo, kaj ankaŭ purigadon post forigo, ĉar programoj ne estas nur legitaj en memoron, sed jam estas kopiitaj al loka stokado, de kiu vi devas. povi malbari nenecesajn aferojn se necese.
Samtempe, la komplekseco de la provizita programaro pliiĝas.
La nombro da dosieroj en la livero pliiĝas de kelkaj ĝis centoj kaj miloj, konfliktoj inter bibliotekversioj kaj aliaj ĝojoj komenciĝas kiam malsamaj programoj uzas la samajn datumojn.
Tiutempe, la ekzisto de Linukso ankoraŭ ne estis malfermita al mi; mi vivis en la mondo de MS DOS kaj, poste, Vindozo, kaj skribis en Borland Pascal kaj Delphi, foje rigardante al C++. Multaj homoj uzis InstallShield por liveri produktojn tiam. , kiu sufiĉe sukcese solvis ĉiujn asignitajn taskojn de disfaldi kaj agordi la programaron.
Interreta epoko
Iom post iom, la komplekseco de programaraj sistemoj fariĝas eĉ pli kompleksa; de la monolito kaj labortablaj aplikoj estas transiro al distribuitaj sistemoj, maldikaj klientoj kaj mikroservoj. Nun vi devas agordi ne nur unu programon, sed aron da ili, kaj por ke ili ĉiuj funkciu kune.
La koncepto tute ŝanĝiĝis, venis Interreto, alvenis la epoko de nubaj servoj. Ĝis nun, nur en la komenca etapo, en la formo de retejoj, neniu aparte revis pri servoj. sed ĝi estis turnopunkto en kaj la evoluo kaj livero de aplikoj.
Por mi mem, mi rimarkis, ke en tiu momento estis ŝanĝo en generacioj de programistoj (aŭ ĝi estis nur en mia medio), kaj estis sento, ke ĉiuj bonaj malnovaj livermetodoj estas forgesitaj samtempe kaj ĉio komenciĝis de la tre. komenco: ĉiuj transdono komencis esti farita genuo skriptoj kaj fiere nomis ĝin "Kontinua livero". Fakte, periodo de kaoso komenciĝis, kiam la malnova estas forgesita kaj ne uzata, kaj la nova simple ne ekzistas.
Mi memoras la tempojn, kiam en nia firmao, kie mi tiam laboris (mi ne nomos ĝin), anstataŭ konstrui per formiko (maven ankoraŭ ne estis populara aŭ tute ne ekzistis), homoj simple kolektis kruĉojn en la IDE kaj serene engaĝiĝis ĝi en SVN. Sekve, deplojo konsistis el preni la dosieron de SVN kaj kopii ĝin per SSH al la dezirata maŝino. Ĝi estas tiel simpla kaj mallerta.
Samtempe, la livero de simplaj retejoj en PHP estis farita en tre primitiva maniero simple kopiante la korektitan dosieron per FTP al la cela maŝino. Kelkfoje tio ne estis la kazo - la kodo estis redaktita vive sur la produktservilo, kaj ĝi estis precipe ŝika se estis sekurkopioj ie.
RPM kaj DEB-pakaĵoj
Aliflanke, kun la disvolviĝo de la Interreto, UNIX-similaj sistemoj komencis akiri pli kaj pli da populareco, precipe, estis en tiu tempo ke mi malkovris RedHat Linukso 6, proksimume 2000. Kompreneble, ekzistis ankaŭ certaj rimedoj por liverado de programaro; laŭ Vikipedio, RPM kiel la ĉefa pakadministranto aperis jam en 1995, en la versio de RedHat Linukso 2.0. Kaj ekde tiam kaj ĝis hodiaŭ, la sistemo estis liverita en formo de RPM-pakaĵoj kaj sufiĉe sukcese ekzistas kaj disvolviĝis.
Distribuoj de la Debian-familio sekvis similan vojon kaj efektivigis liveron en la formo de deb-pakaĵoj, kiuj restis senŝanĝaj ĝis hodiaŭ.
Pakaj administrantoj permesas al vi liveri la programajn produktojn mem, agordi ilin dum la instala procezo, administri dependecojn inter malsamaj pakaĵoj, forigi produktojn kaj purigi nenecesajn erojn dum la malinstala procezo. Tiuj. plejparte, tio estas ĉio, kio necesas, tial ili daŭris plurajn jardekojn preskaŭ senŝanĝe.
Nuba komputado aldonis instaladon al pakaĵadministrantoj ne nur de fizikaj amaskomunikiloj, sed ankaŭ de nubaj deponejoj, sed esence malmulte ŝanĝiĝis.
Indas noti, ke nuntempe estas iuj movoj por foriri de deb kaj ŝanĝi al klakaj pakoj, sed pli pri tio poste.
Do, ĉi tiu nova generacio de nubaj programistoj, kiuj konis nek DEB nek RPM, ankaŭ malrapide kreskis, akiris sperton, produktoj fariĝis pli kompleksaj, kaj kelkaj pli raciaj liveraj metodoj estis bezonataj ol FTP, bash-skriptoj kaj similaj studentaj metioj.
Kaj ĉi tie venas en la bildon Docker, speco de miksaĵo de virtualigo, limigo de rimedoj kaj livermetodo. Ĝi estas moda kaj juneca nun, sed ĉu ĝi bezonas por ĉio? Ĉu ĉi tio estas panaceo?
Laŭ miaj observoj, tre ofte Docker estas proponita ne kiel racia elekto, sed simple ĉar, unuflanke, oni parolas pri ĝi en la komunumo, kaj tiuj, kiuj proponas ĝin, nur konas ĝin. Aliflanke ili plejparte silentas pri la bonaj malnovaj paksistemoj - ili ekzistas kaj faras sian laboron trankvile kaj nerimarkite. En tia situacio, vere ne ekzistas alia elekto - la elekto estas evidenta - Docker.
Mi provos dividi mian sperton pri kiel ni efektivigis Docker kaj kio okazis kiel rezulto.
Memverkitaj skriptoj
Komence, ekzistis bash-skriptoj kiuj deplojis jar-arkivojn al la postulataj maŝinoj. Ĉi tiu procezo estis administrita de Jenkins. Ĉi tio sukcese funkciis, ĉar la jar-arkivo mem jam estas aro enhavanta klasojn, rimedojn kaj eĉ agordon. Se vi metas ĉion en ĝin al la maksimumo, tiam vastigi ĝin en skripton ne estas la plej malfacila afero, kiun vi bezonas
Sed skriptoj havas plurajn malavantaĝojn:
- skriptoj estas kutime skribitaj haste kaj tial estas tiel primitivaj ke ili enhavas nur unu plejbonkazan scenaron. Ĉi tio estas faciligita de la fakto, ke la programisto interesiĝas pri rapida liverado, kaj normala skripto postulas la investon de deca kvanto da rimedoj.
- kiel sekvo de la antaŭa punkto, la skriptoj ne enhavas malinstalajn procedurojn
- neniu establita ĝisdatiga proceduro
- Kiam nova produkto aperas, vi devas skribi novan skripton
- neniu dependeca subteno
Kompreneble, vi povas skribi kompleksan skripton, sed, kiel mi skribis supre, ĉi tio estas disvolva tempo, kaj ne malplej, kaj, kiel ni scias, ĉiam ne estas sufiĉe da tempo.
Ĉio ĉi evidente limigas la amplekson de apliko de ĉi tiu deplojmetodo nur al la plej simplaj sistemoj. Venis la tempo por ŝanĝi ĉi tion.
Docker
Iam, freŝe monfaritaj mezoj komencis veni al ni, bolantaj de ideoj kaj ravantaj pri la dokisto. Nu, flago en la mano — ni faru! Estis du provoj. Ambaŭ estis malsukcesaj – ni diru, pro grandaj ambicioj, sed manko de vera sperto. Ĉu necesis devigi ĝin kaj fini ĝin per ajna maniero ebla? Estas neverŝajne - la teamo devas evolui al la bezonata nivelo antaŭ ol ĝi povas uzi la taŭgajn ilojn. Krome, uzante pretajn bildojn de Docker, ni ofte renkontis la fakton, ke la reto ne funkciis ĝuste (kio eble estis pro la malsekeco de la Docker mem) aŭ estis malfacile vastigi aliulajn ujojn.
Kiajn ĝenojn ni renkontis?
- Retaj problemoj en ponta reĝimo
- Estas maloportune vidi protokolojn en ujo (se ili ne estas konservitaj aparte en la dosiersistemo de la gastiga maŝino)
- ElasticSearch foje frostas strange ene de la ujo, la kialo ne estis determinita, la ujo estas oficiala
- Necesas uzi ŝelon ene de ujo - ĉio estas tre malkonstruita, ne ekzistas kutimaj iloj
- Granda grandeco de kolektitaj ujoj - multekosta stoki
- Pro la granda grandeco de ujoj, estas malfacile subteni plurajn versiojn
- Pli longa konstrutempo, male al aliaj metodoj (skriptoj aŭ deb-pakaĵoj)
Aliflanke, kial estas pli malbone deploji Spring-servon en formo de jar-arkivo per la sama deb? Ĉu la izolado de rimedoj vere necesas? Ĉu indas perdi oportunajn operaciumajn ilojn per plenigado de servo en tre reduktitan ujon?
Kiel praktiko montris, fakte tio ne estas necesa, la deb-pakaĵo sufiĉas en 90% de kazoj.
Kiam la bona malnova deb malsukcesas kaj kiam ni vere bezonas docker?
Por ni, ĉi tio estis disfaldi servojn en python. Multaj bibliotekoj necesaj por maŝinlernado kaj ne inkluzivitaj en la norma distribuo de la operaciumo (kaj kio estis la malĝustaj versioj), hakoj kun agordoj, la bezono de malsamaj versioj por malsamaj servoj vivantaj sur la sama gastiga sistemo kondukis al ĉi tio, ke la nura akceptebla maniero provizi ĉi tiun nuklean miksaĵon estis la docker. La laborintenso de kunmeti docker-ujo montriĝis pli malalta ol la ideo paki ĉion en apartajn deb-pakaĵojn kun dependecoj, kaj fakte neniu en sia ĝusta menso entreprenus tion.
La dua punkto, kie oni planas uzi Docker, estas disfaldi servojn laŭ la bluverda deploja skemo. Sed ĉi tie mi volas ricevi laŭpaŝan pliiĝon de komplekseco: unue, deb-pakaĵoj estas konstruitaj, kaj poste docker-ujo estas konstruita el ili.
Alklaku pakaĵojn
Ni revenu al klakpakoj. Ili unue aperis oficiale en Ubuntu 16.04. Male al la kutimaj deb-pakaĵoj kaj rpm-pakaĵoj, snap portas ĉiujn dependecojn. Unuflanke, ĉi tio ebligas al vi eviti bibliotekkonfliktojn, aliflanke, la rezulta pako estas pli granda en grandeco. Krome, ĉi tio ankaŭ povas influi la sekurecon de la sistemo: en la kazo de rapida livero, ĉiuj ŝanĝoj al la inkluzivitaj bibliotekoj devas esti kontrolataj de la programisto, kiu kreas la pakaĵon. Ĝenerale, ne ĉio estas tiel simpla kaj universala feliĉo ne venas de uzado de ili. Sed, tamen, ĉi tio estas tute racia alternativo se la sama Docker estas uzata nur kiel paka ilo kaj ne por virtualigo.
Kiel rezulto, ni nun uzas ambaŭ deb-pakaĵojn kaj docker-ujojn en racia kombinaĵo, kiujn, eble, en iuj kazoj ni anstataŭigos per klakaj pakoj.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Kion vi uzas por livero?
-
Memverkitaj skriptoj
-
Kopiu permane al FTP
-
deb-pakaĵoj
-
rpm-pakaĵoj
-
klaki pakojn
-
Docker-bildoj
-
Virtualaj maŝinaj bildoj
-
Klonu la tutan HDD
-
marioneto
-
ansible
-
Aliaj
Voĉdonis 109 uzantoj. 32 uzantoj sindetenis.
fonto: www.habr.com