Sa paanuman sa isang punto ay nagpasya akong magsulat ng isang artikulo tungkol sa paghahatid sa anyo ng mga lalagyan ng Docker at mga pakete ng deb, ngunit noong nagsimula ako, sa ilang kadahilanan ay dinala ako pabalik sa malalayong panahon ng mga unang personal na computer at kahit na mga calculator. Sa pangkalahatan, sa halip na tuyong paghahambing ng docker at deb, nakuha namin ang mga kaisipang ito sa paksa ng ebolusyon, na ipinakita ko para sa iyong pagsasaalang-alang.
Anumang produkto, anuman ito, ay dapat na makarating sa mga server ng produkto, dapat na i-configure at ilunsad. Iyan ang tatalakayin ng artikulong ito.
Iisipin ko sa isang kontekstong pangkasaysayan, "kung ano ang nakikita ko ay kung ano ang aking kinakanta," kung ano ang nakita ko noong una akong nagsimulang magsulat ng code at kung ano ang naobserbahan ko ngayon, kung ano ang ginagamit natin sa ngayon at bakit. Ang artikulo ay hindi nagpapanggap na isang ganap na pag-aaral, ang ilang mga punto ay hindi nakuha, ito ang aking personal na pananaw sa kung ano ang noon at kung ano ang ngayon.
Kaya, noong unang panahon... ang pinakamaagang paraan ng paghahatid na nakita ko ay mga cassette tape mula sa mga tape recorder. Mayroon akong computer na BK-0010.01...
Ang panahon ng mga calculator
Hindi, may mas naunang sandali, mayroon ding calculator ΠΈ .
Kaya kapag nagkaroon ako , kung gayon ang paraan upang ilipat ang programa ay isang ordinaryong piraso ng papel sa isang kahon kung saan nakasulat ang isang programa, na, kung kinakailangan, upang patakbuhin ito nang manu-mano, ay isinulat sa calculator. Kung gusto mong maglaro (oo, kahit na ang antediluvian calculator na ito ay may mga laro) - umupo ka at ipasok ang programa sa calculator. Naturally, kapag ang calculator ay naka-off, ang programa ay nawala sa limot. Bilang karagdagan sa mga code ng calculator na nakasulat sa papel sa kanyang sariling kamay, ang mga programa ay nai-publish sa mga magasin na "Radio" at "Teknolohiya para sa Kabataan", at nai-publish din sa mga libro noong panahong iyon.
Ang susunod na pagbabago ay isang calculator , mayroon na itong ilang pagkakahawig ng hindi pabagu-bagong pag-iimbak ng data. Ngayon ang laro o programa ay hindi kailangang ipasok nang manu-mano, ngunit pagkatapos magsagawa ng ilang mahiwagang pass sa mga pindutan, na-load ito mismo.
Ang laki ng pinakamalaking programa sa calculator ay 105 hakbang, at ang laki ng permanenteng memorya sa MK-52 ay 512 hakbang.
Sa pamamagitan ng paraan, kung may mga tagahanga ng mga calculator na ito na nagbabasa ng artikulong ito, sa proseso ng pagsulat ng artikulo ay natagpuan ko ang parehong calculator emulator para sa Android at mga programa para dito. Isulong sa nakaraan!
Isang maikling digression tungkol sa MK-52 (mula sa Wikipedia)
Lumipad sa kalawakan ang MK-52 sa Soyuz TM-7 spacecraft. Ito ay dapat na gamitin upang kalkulahin ang landing trajectory kung sakaling nabigo ang on-board na computer.
Mula noong 52, ang MK-1988 na may Electronica-Astro memory expansion unit ay ibinibigay sa mga barko ng Navy bilang bahagi ng isang navigational computing kit.
Ang unang mga personal na computer
Balik tayo sa mga panahon . Malinaw na mayroong higit na memorya doon, at ang pag-type ng code mula sa isang piraso ng papel ay hindi na isang opsyon (bagaman sa una ay ginawa ko iyon, dahil wala nang ibang medium). Ang mga audio cassette para sa mga tape recorder ay nagiging pangunahing paraan ng pag-iimbak at paghahatid ng software.
Ang imbakan sa isang cassette ay karaniwang nasa anyo ng isa o dalawang binary file, lahat ng iba ay nakapaloob sa loob. Napakababa ng pagiging maaasahan, kailangan kong magtago ng 2-3 kopya ng programa. Nakakadismaya rin ang mga oras ng paglo-load, at nag-eksperimento ang mga mahilig sa iba't ibang frequency encoding upang malampasan ang mga pagkukulang na ito. Sa oras na iyon, ako mismo ay hindi pa kasali sa propesyonal na pag-unlad ng software (hindi binibilang ang mga simpleng programa sa BASIC), kaya, sa kasamaang-palad, hindi ko sasabihin sa iyo nang detalyado kung paano nakaayos ang lahat sa loob. Ang mismong katotohanan na ang computer ay mayroon lamang RAM para sa karamihan ay tinutukoy ang pagiging simple ng pamamaraan ng pag-iimbak ng data.
Ang paglitaw ng maaasahan at malaking storage media
Nang maglaon, lumitaw ang mga floppy disk, pinasimple ang proseso ng pagkopya, at tumaas ang pagiging maaasahan.
Ngunit ang sitwasyon ay kapansin-pansing nagbabago lamang kapag may sapat na malalaking lokal na imbakan na lumilitaw sa anyo ng mga HDD.
Ang uri ng paghahatid ay pangunahing nagbabago: lumilitaw ang mga installer program na namamahala sa proseso ng pag-configure ng system, pati na rin ang paglilinis pagkatapos ng pag-alis, dahil ang mga programa ay hindi lamang binabasa sa memorya, ngunit kinopya na sa lokal na imbakan, kung saan kailangan mong makapag-alis ng mga hindi kinakailangang bagay kung kinakailangan.
Kasabay nito, ang pagiging kumplikado ng ibinigay na software ay tumataas.
Ang bilang ng mga file sa paghahatid ay tataas mula sa iilan hanggang daan-daan at libu-libo, ang mga salungatan sa pagitan ng mga bersyon ng library at iba pang mga kagalakan ay nagsisimula kapag ang iba't ibang mga programa ay gumagamit ng parehong data.
Sa oras na iyon, ang pagkakaroon ng Linux ay hindi pa bukas sa akin; Nabuhay ako sa mundo ng MS DOS at, nang maglaon, Windows, at nagsulat sa Borland Pascal at Delphi, kung minsan ay tumitingin sa C++. Maraming tao ang gumamit ng InstallShield para maghatid ng mga produkto noon. , na medyo matagumpay na nalutas ang lahat ng mga nakatalagang gawain ng pag-deploy at pag-configure ng software.
Panahon ng internet
Unti-unti, nagiging mas kumplikado ang pagiging kumplikado ng mga software system; mula sa monolith at desktop application ay mayroong paglipat sa mga distributed system, thin client at microservice. Ngayon ay kailangan mong i-configure hindi lamang isang programa, ngunit isang hanay ng mga ito, at upang silang lahat ay magtulungan.
Ang konsepto ay ganap na nagbago, ang Internet ay dumating, ang panahon ng mga serbisyo sa ulap ay dumating. Sa ngayon, sa paunang yugto lamang, sa anyo ng mga website, walang partikular na pinangarap ng mga serbisyo. ngunit ito ay isang pagbabago sa parehong pagbuo at paghahatid ng mga aplikasyon.
Para sa aking sarili, napansin ko na sa sandaling iyon ay nagkaroon ng pagbabago sa mga henerasyon ng mga developer (o ito ay sa aking kapaligiran lamang), at may pakiramdam na ang lahat ng magagandang lumang paraan ng paghahatid ay nakalimutan sa isang sandali at ang lahat ay nagsimula mula sa pinakadulo. simula: ang lahat ng paghahatid ay nagsimulang gawin ang mga script ng tuhod at buong pagmamalaki na tinawag itong "Patuloy na paghahatid". Sa katunayan, ang isang panahon ng kaguluhan ay nagsimula, kapag ang luma ay nakalimutan at hindi ginagamit, at ang bago ay hindi umiiral.
Naaalala ko ang mga panahon na sa aming kumpanya kung saan ako nagtrabaho noon (hindi ko na ito pangalanan), sa halip na magtayo sa pamamagitan ng langgam (hindi pa sikat si maven o wala pa talaga), ang mga tao ay nangolekta lamang ng mga garapon sa IDE at matahimik na nakatuon. ito sa SVN. Alinsunod dito, ang deployment ay binubuo ng pagkuha ng file mula sa SVN at pagkopya nito sa pamamagitan ng SSH sa nais na makina. Napakasimple at clumsy nito.
Kasabay nito, ang paghahatid ng mga simpleng site sa PHP ay ginawa sa napaka-primitive na paraan sa pamamagitan lamang ng pagkopya ng naitama na file sa pamamagitan ng FTP sa target na makina. Minsan hindi ito ang kaso - ang code ay na-edit nang live sa server ng produkto, at ito ay lalong chic kung may mga backup sa isang lugar.
RPM at DEB packages
Sa kabilang banda, sa pag-unlad ng Internet, ang mga sistemang tulad ng UNIX ay nagsimulang makakuha ng higit at higit na katanyagan, lalo na, sa oras na iyon ay natuklasan ko ang RedHat Linux 6, humigit-kumulang 2000. Naturally, mayroon ding ilang mga paraan para sa paghahatid ng software; ayon sa Wikipedia, ang RPM bilang pangunahing manager ng package ay lumitaw na noong 1995, sa bersyon ng RedHat Linux 2.0. At mula noon at hanggang ngayon, ang sistema ay naihatid sa anyo ng mga RPM packages at medyo matagumpay na umiiral at umuunlad.
Ang mga distribusyon ng pamilyang Debian ay sumunod sa isang katulad na landas at ipinatupad ang paghahatid sa anyo ng mga pakete ng deb, na nanatiling hindi nagbabago hanggang ngayon.
Pinapayagan ka ng mga manager ng package na ihatid ang mga produkto ng software mismo, i-configure ang mga ito sa panahon ng proseso ng pag-install, pamahalaan ang mga dependency sa pagitan ng iba't ibang mga pakete, alisin ang mga produkto at linisin ang mga hindi kinakailangang item sa panahon ng proseso ng pag-uninstall. Yung. para sa karamihan, iyon lang ang kailangan, kaya naman tumagal sila ng ilang dekada na halos hindi nagbabago.
Ang cloud computing ay nagdagdag ng pag-install sa mga manager ng package hindi lamang mula sa pisikal na media, kundi pati na rin mula sa mga cloud repository, ngunit sa panimula ay kaunti lang ang nagbago.
Kapansin-pansin na sa kasalukuyan ay may ilang mga hakbang patungo sa paglayo sa deb at paglipat sa mga snap package, ngunit higit pa sa paglaon.
Kaya, itong bagong henerasyon ng mga cloud developer, na walang alam sa DEB o RPM, ay dahan-dahan ding lumaki, nakakuha ng karanasan, naging mas kumplikado ang mga produkto, at ilang mas makatwirang paraan ng paghahatid ang kailangan kaysa sa FTP, mga script ng bash at mga katulad na likhang sining ng mag-aaral.
At ito ay kung saan ang Docker ay dumating sa larawan, isang uri ng pinaghalong virtualization, resource delimitation at paraan ng paghahatid. Ito ay sunod sa moda at kabataan ngayon, ngunit kailangan ba ito para sa lahat? Ito ba ay isang panlunas sa lahat?
Mula sa aking mga obserbasyon, kadalasan ang Docker ay iminungkahi hindi bilang isang makatwirang pagpipilian, ngunit dahil lamang, sa isang banda, ito ay pinag-uusapan sa komunidad, at ang mga nagmumungkahi nito ay alam lamang ito. Sa kabilang banda, sa karamihan ay tahimik sila tungkol sa magagandang lumang sistema ng packaging - umiiral sila at ginagawa ang kanilang trabaho nang tahimik at hindi napapansin. Sa ganoong sitwasyon, wala talagang ibang pagpipilian - ang pagpipilian ay halata - Docker.
Susubukan kong ibahagi ang aking karanasan kung paano namin ipinatupad ang Docker at kung ano ang nangyari bilang isang resulta.
Mga script na isinulat sa sarili
Sa una, may mga script ng bash na nag-deploy ng mga archive ng jar sa mga kinakailangang makina. Ang prosesong ito ay pinamahalaan ni Jenkins. Matagumpay itong gumana, dahil ang archive ng jar mismo ay isa nang pagpupulong na naglalaman ng mga klase, mapagkukunan at kahit na pagsasaayos. Kung ilalagay mo ang lahat dito sa maximum, kung gayon ang pagpapalawak nito sa isang script ay hindi ang pinakamahirap na bagay na kailangan mo
Ngunit ang mga script ay may ilang mga kawalan:
- ang mga script ay kadalasang isinusulat nang mabilis at samakatuwid ay napaka-primitive na naglalaman lamang sila ng isang pinakamahusay na sitwasyong sitwasyon. Ito ay pinadali ng katotohanan na ang developer ay interesado sa mabilis na paghahatid, at ang isang normal na script ay nangangailangan ng pamumuhunan ng isang disenteng halaga ng mga mapagkukunan
- bilang resulta ng nakaraang punto, ang mga script ay hindi naglalaman ng mga pamamaraan sa pag-uninstall
- walang itinatag na pamamaraan ng pag-upgrade
- Kapag lumitaw ang isang bagong produkto, kailangan mong magsulat ng bagong script
- walang suporta sa dependency
Siyempre, maaari kang magsulat ng isang sopistikadong script, ngunit, tulad ng isinulat ko sa itaas, ito ang oras ng pag-unlad, at hindi bababa sa, at, tulad ng alam natin, palaging walang sapat na oras.
Ang lahat ng ito ay malinaw na nililimitahan ang saklaw ng aplikasyon ng paraan ng pag-deploy na ito sa mga pinakasimpleng system lamang. Oras na para baguhin ito.
Manggagawa sa pantalan
Sa ilang mga punto, nagsimulang dumating sa amin ang mga bagong gawang middle, na nagngangalit sa mga ideya at nagngangalit tungkol sa docker. Well, flag sa kamay - gawin natin ito! Mayroong dalawang pagtatangka. Parehong hindi matagumpay - sabihin nating, dahil sa mahusay na mga ambisyon, ngunit kakulangan ng tunay na karanasan. Kailangan bang pilitin ito at tapusin sa anumang paraan na posible? Ito ay malamang na hindi - ang koponan ay dapat umunlad sa kinakailangang antas bago nito magamit ang mga naaangkop na tool. Bilang karagdagan, kapag gumagamit ng mga yari na Docker na imahe, madalas naming nakatagpo ang katotohanan na ang network ay hindi gumana nang tama (na maaaring dahil sa kahalumigmigan ng Docker mismo) o mahirap palawakin ang mga lalagyan ng ibang tao.
Anong mga abala ang naranasan namin?
- Mga problema sa network sa bridge mode
- Hindi maginhawang tingnan ang mga log sa isang lalagyan (kung hindi sila nakaimbak nang hiwalay sa file system ng host machine)
- Ang ElasticSearch paminsan-minsan ay kakaibang nagyeyelo sa loob ng lalagyan, ang dahilan ay hindi pa natukoy, ang lalagyan ay opisyal
- Kinakailangan na gumamit ng isang shell sa loob ng isang lalagyan - lahat ay nahuhubad, walang mga pamilyar na tool
- Malaking sukat ng mga nakolektang lalagyan - mahal mag-imbak
- Dahil sa malaking sukat ng mga container, mahirap suportahan ang maraming bersyon
- Mas mahabang oras ng pagbuo, hindi katulad ng ibang mga pamamaraan (mga script o deb package)
Sa kabilang banda, bakit mas masahol pa ang pag-deploy ng serbisyo ng Spring sa anyo ng isang archive ng jar sa pamamagitan ng parehong deb? Kailangan ba talaga ang paghihiwalay ng mapagkukunan? Sulit ba ang pagkawala ng maginhawang mga tool sa operating system sa pamamagitan ng pagpupuno ng isang serbisyo sa isang napakababang lalagyan?
Tulad ng ipinakita ng kasanayan, sa katotohanan ay hindi ito kinakailangan, ang pakete ng deb ay sapat sa 90% ng mga kaso.
Kailan nabigo ang magandang lumang deb at kailan talaga natin kailangan ng docker?
Para sa amin, ito ay pag-deploy ng mga serbisyo sa python. Maraming mga aklatan na kailangan para sa machine learning at hindi kasama sa karaniwang pamamahagi ng operating system (at kung ano ang naroon ay ang mga maling bersyon), mga hack na may mga setting, ang pangangailangan para sa iba't ibang mga bersyon para sa iba't ibang mga serbisyo na naninirahan sa parehong host system ay humantong sa ito , na ang tanging makatwirang paraan upang maihatid ang nuclear mixture na ito ay ang docker. Ang lakas ng paggawa ng pag-assemble ng isang docker container ay naging mas mababa kaysa sa ideya ng pag-iimpake ng lahat ng ito sa magkahiwalay na mga pakete ng deb na may mga dependency, at sa katunayan walang sinuman sa kanilang tamang pag-iisip ang gagawa nito.
Ang pangalawang punto kung saan pinaplano naming gamitin ang Docker ay ang pag-deploy ng mga serbisyo gamit ang blue-green deploy scheme. Ngunit dito gusto kong makakuha ng unti-unting pagtaas sa pagiging kumplikado: una, ang mga deb package ay binuo, at pagkatapos ay isang docker container ay binuo mula sa kanila.
Snap na mga pakete
Bumalik tayo sa snap packages. Una silang opisyal na lumitaw sa Ubuntu 16.04. Hindi tulad ng karaniwang mga pakete ng deb at mga pakete ng rpm, ang snap ay nagdadala ng lahat ng mga dependency. Sa isang banda, pinapayagan ka nitong maiwasan ang mga salungatan sa library, sa kabilang banda, mas malaki ang laki ng resultang package. Bilang karagdagan, maaari din itong makaapekto sa seguridad ng system: sa kaso ng snap delivery, lahat ng pagbabago sa mga kasamang library ay dapat na subaybayan ng developer na lumikha ng package. Sa pangkalahatan, hindi lahat ay napakasimple at ang pangkalahatang kaligayahan ay hindi nagmumula sa paggamit nito. Ngunit, gayunpaman, ito ay isang ganap na makatwirang alternatibo kung ang parehong Docker ay ginagamit lamang bilang isang tool sa packaging at hindi para sa virtualization.
Bilang resulta, ginagamit na namin ngayon ang parehong mga deb package at docker container sa isang makatwirang kumbinasyon, na, marahil, sa ilang mga kaso ay papalitan namin ng mga snap package.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Ano ang ginagamit mo sa paghahatid?
-
Mga script na isinulat sa sarili
-
Manu-manong kopyahin sa FTP
-
mga pakete ng deb
-
mga pakete ng rpm
-
snap packages
-
Docker-images
-
Mga imahe ng virtual machine
-
I-clone ang buong HDD
-
papet
-
ansible
-
Iba
109 mga gumagamit ang bumoto. 32 user ang umiwas.
Pinagmulan: www.habr.com