Wakati fulani, niliamua kuandika makala kuhusu utoaji wa vyombo vya Docker na vifurushi vya Debian, lakini nilipoanza, ghafla nilisafirishwa kurudi siku za mbali za kompyuta za kwanza za kibinafsi na hata vihesabu. Kwa hiyo, badala ya kulinganisha kavu ya Docker na Debian, nilimaliza na mawazo haya juu ya mada ya mageuzi, ambayo ninawasilisha kwako kwa kuzingatia kwako.
Bidhaa yoyote, haijalishi ni nini, lazima kwa namna fulani ifikie seva za uzalishaji, isanidiwe, na iendeshwe. Hiyo ndiyo makala hii inahusu.
Nitakuwa nikitafakari hili katika muktadha wa kihistoria, "ninachokiona ndicho ninachoimba," nilichoona nilipokuwa naanza kuweka msimbo na kile ninachokiona sasa, kile ambacho sisi wenyewe tunatumia kwa sasa na kwa nini. Makala haya hayadai kuwa utafiti wa kina, na baadhi ya pointi zimeachwa. Ni mtazamo wangu binafsi juu ya kile kilichokuwa na kilichopo sasa.
Kwa hivyo, zamani za kale… njia ya awali zaidi ya utoaji ninayokumbuka ilikuwa kanda za kaseti. Nilikuwa na kompyuta ya BK-0010.01…
Umri wa Vikokotoo
Hapana, kulikuwa na wakati wa mapema, pia kulikuwa na kikokotoo. и .
Kwa hiyo ndipo nilipopata , njia ya kuhamisha programu ilikuwa kipande rahisi cha karatasi ya mraba na programu iliyoandikwa juu yake. Wakati inahitajika, programu iliingizwa kwa mikono kwenye kikokotoo. Ikiwa ungetaka kucheza (ndio, hata kikokotoo hiki cha maji kabla ya gharika kilikuwa na michezo), ungekaa chini na kuingiza programu kwenye kikokotoo. Kwa kawaida, wakati kikokotoo kilizimwa, programu ilipotea bila kusahaulika. Mbali na misimbo ya kikokotoo iliyoandikwa kwa mkono, programu zilichapishwa katika majarida ya "Redio" na "Teknolojia kwa Vijana," na pia zilichapishwa katika vitabu vya wakati huo.
Marekebisho yaliyofuata yalikuwa kikokotoo , tayari ilikuwa na mfano fulani wa hifadhi ya data isiyo tete. Sasa, mchezo au programu haikuhitajika tena kuingizwa kwa mikono; baada ya mibofyo michache ya vitufe vya kichawi, ingepakia kiotomatiki.
Ukubwa wa programu kubwa zaidi katika calculator ilikuwa hatua 105, na ukubwa wa kumbukumbu ya kudumu katika MK-52 ilikuwa hatua 512.
Kwa njia, ikiwa kuna mashabiki wa vikokotoo hivi wanaosoma nakala hii, wakati wa kuiandika, nilipata emulator ya kikokotoo cha Android na programu zake. Mbele, katika siku za nyuma!
Kicheko kidogo kuhusu MK-52 (kutoka Wikipedia)
MK-52 iliruka angani kwenye chombo cha anga za juu cha Soyuz TM-7. Ilikusudiwa kutumiwa kuhesabu njia ya kutua katika tukio la kushindwa kwa kompyuta ya ubao.
MK-52 yenye kitengo cha upanuzi wa kumbukumbu ya Elektronika-Astro imetolewa kwa meli za Jeshi la Wanamaji tangu 1988 kama sehemu ya kitengo cha kompyuta ya urambazaji.
Kompyuta za kwanza za kibinafsi
Turudi kwenye nyakati Kwa kawaida, kulikuwa na kumbukumbu zaidi, na kuandika msimbo kutoka kwa kipande cha karatasi haikuwa chaguo tena (ingawa ndivyo nilivyofanya mwanzoni, kwa sababu hapakuwa na njia nyingine yoyote ya kuhifadhi). Kanda za kaseti za sauti zikawa njia kuu za kuhifadhi na kutoa programu.
Hifadhi kwenye kaseti kwa kawaida ilijumuisha faili moja au mbili za jozi, na kila kitu kingine kikihifadhiwa ndani. Kuegemea kulikuwa duni sana, ikihitaji nakala mbili au tatu za programu kudumishwa. Nyakati za upakiaji pia zilikuwa za kukatisha tamaa, na wapenda shauku walijaribu mifumo mbalimbali ya usimbaji wa masafa ili kuondokana na mapungufu haya. Bado sikuwa msanidi programu mtaalamu wakati huo (kando na programu rahisi za BASIC), kwa hivyo samahani kusema siwezi kwenda kwa undani juu ya jinsi kila kitu kilipangwa ndani. Ukweli kwamba kompyuta tu ilikuwa na RAM kwa kiasi kikubwa iliamua unyenyekevu wa mpango wa kuhifadhi data.
Kuibuka kwa vyombo vya habari vya kuaminika na kubwa vya kuhifadhi
Baadaye, diski za floppy zilionekana, mchakato wa kunakili ukawa rahisi, na uaminifu uliongezeka.
Lakini hali inabadilika sana tu wakati vifaa vya kutosha vya uhifadhi wa ndani katika mfumo wa HDD vinaonekana.
Njia ya uwasilishaji inabadilika kimsingi: programu za kisakinishi zinaibuka ambazo zinasimamia mchakato wa usanidi wa mfumo, pamoja na kusafisha baada ya kufutwa, kwani programu hazisomwi tu kwenye kumbukumbu, lakini zinakiliwa kwa uhifadhi wa ndani, ambayo lazima uweze kufuta faili zisizohitajika ikiwa ni lazima.
Wakati huo huo, utata wa programu iliyotolewa huongezeka.
Idadi ya faili katika usambazaji huongezeka kutoka chache hadi mamia na maelfu, migogoro kati ya matoleo ya maktaba huanza, na furaha nyingine hutokea wakati programu tofauti zinatumia data sawa.
Wakati huo, uwepo ulikuwa bado haujafunuliwa kwangu LinuxNiliishi katika ulimwengu wa MS DOS na, baadaye, Windows, na aliandika katika Borland Pascal na Delphi, mara kwa mara akijaribu C++. Wakati huo, wengi walitumia InstallShield kusambaza bidhaa. , ambayo ilifanikiwa kabisa kutatua kazi zote za kupeleka na kusanidi programu.
Umri wa Mtandao
Mifumo ya programu hatua kwa hatua inakuwa ngumu zaidi, ikihama kutoka kwa programu za monoliths na desktop hadi mifumo iliyosambazwa, wateja nyembamba, na huduma ndogo. Sasa, sio programu moja tu inayohitaji kusanidiwa, lakini seti yao, zote zinafanya kazi pamoja bila mshono.
Dhana ilibadilika kabisa, mtandao ulifika, na zama za huduma za wingu zilianza. Ingawa hizi zilikuwa bado katika hatua zao za mwanzo, katika mfumo wa tovuti, hakuna mtu aliyetamani sana huduma hizi. Lakini hii ilikuwa hatua ya mabadiliko katika maendeleo na utoaji wa maombi.
Niliona mabadiliko ya kizazi katika watengenezaji wakati huo (au labda ni mimi tu), na ilionekana kama njia zote nzuri za utoaji wa zamani ziliachwa mara moja, na kila kitu kilianza tena: utoaji wote ulifanyika kwa maandishi ya muda, kwa kiburi inayoitwa "Utoaji Unaoendelea." Kwa kweli, kipindi cha machafuko kilikuja, na mbinu za zamani zimesahauliwa na zisizotumiwa, na mpya hazipo kabisa.
Nakumbuka wakati, kwenye kampuni niliyofanyia kazi wakati huo (sitaitaja jina), badala ya kujenga na Ant (Maven haikuwa maarufu wakati huo, au haikuwepo), watu wangeunda tu jar kwenye IDE yao na kuikabidhi kwa SVN bila utunzaji. Upelekaji, basi, ulijumuisha kuvuta faili kutoka kwa SVN na kuinakili juu ya SSH hadi kwa mashine inayolengwa. Ilikuwa rahisi na isiyofaa kama hiyo.
Wakati huo huo, kutoa tovuti rahisi za PHP kulifanyika kwa njia ya zamani sana, kwa kunakili faili iliyohaririwa kupitia FTP kwa mashine inayolengwa. Wakati mwingine hii haikuwa muhimu hata kidogo—msimbo ulihaririwa moja kwa moja kwenye seva ya uzalishaji, na ilikuwa nzuri sana ikiwa kulikuwa na nakala rudufu.
Vifurushi vya RPM na DEB
Kwa upande mwingine, pamoja na maendeleo ya mtandao, mifumo kama ya UNIX ilianza kupata umaarufu unaoongezeka; hasa, ilikuwa wakati huo nilipogundua RedHat Linux 6, karibu mwaka 2000. Kwa kawaida, kulikuwa na njia fulani za kuwasilisha programu huko pia. Kulingana na Wikipedia, RPM kama meneja mkuu wa kifurushi ilionekana mwaka 1995, katika toleo la RedHat. Linux 2.0. Tangu wakati huo, mfumo umekuwa ukitolewa kama vifurushi vya RPM na unaendelea kustawi.
Mgawanyo wa familia Debian Walifuata njia kama hiyo na kutekeleza uwasilishaji katika mfumo wa vifurushi vya deni, ambavyo bado havijabadilika hadi leo.
Wasimamizi wa vifurushi hukuruhusu kutoa bidhaa za programu wenyewe, kusanidi wakati wa usakinishaji, kudhibiti utegemezi kati ya vifurushi tofauti, kuondoa bidhaa, na kusafisha sehemu zisizo za lazima wakati wa kusanidua. Hiyo ndiyo yote unayohitaji, ndiyo sababu wamevumilia kwa miongo kadhaa bila kubadilika.
Kompyuta ya wingu imeongeza uwezo wa usakinishaji kwa wasimamizi wa vifurushi sio tu kutoka kwa media halisi lakini pia kutoka kwa hazina za wingu, lakini kimsingi kidogo imebadilika.
Inafaa kukumbuka kuwa kwa sasa kuna hatua kadhaa za kuhama kutoka kwa deni na kuelekea vifurushi vya snap, lakini zaidi juu ya hilo baadaye.
Kwa hivyo, kizazi hiki kipya cha watengenezaji wa wingu, ambao hawakujua DEB wala RPM, pia walikua polepole, walipata uzoefu, bidhaa zikawa ngumu zaidi, na njia za uwasilishaji zinazofaa zaidi zilihitajika kuliko FTP, hati za bash, na hacks kama hizo zilizoundwa na wanafunzi.
Na hapa ndipo Docker inapoingia, aina ya mchanganyiko wa uvumbuzi, kutengwa kwa rasilimali, na njia ya uwasilishaji. Ni ya kisasa na ya ujana, lakini ni muhimu kwa kila kitu? Je, ni panacea?
Katika uzoefu wangu, Docker mara nyingi hupendekezwa sio kama chaguo la busara, lakini kwa sababu, kwa upande mmoja, ni mazungumzo ya jamii, na wale wanaoipendekeza hawajui chochote kuihusu. Kwa upande mwingine, mifumo mizuri ya vifungashio vya zamani hupuuzwa kwa kiasi kikubwa—bado wako karibu, wakifanya kazi yao kimya kimya na bila kutambuliwa. Katika hali hii, hakuna chaguo lingine - chaguo ni dhahiri: Docker.
Nitajaribu kushiriki uzoefu wangu wa jinsi tulivyotekeleza Docker na matokeo yalikuwa nini.
Maandishi ya kujiandikisha
Hapo awali, kulikuwa na maandishi ya bash ambayo yalipeleka kumbukumbu za jar kwenye mashine zinazolengwa. Jenkins alisimamia mchakato huu. Hii ilifanya kazi kwa mafanikio, kwani kumbukumbu ya jar yenyewe tayari ni muundo, iliyo na madarasa, rasilimali, na hata usanidi. Ikiwa utapakia kila kitu ndani yake, kisha kuitenganisha kuwa hati sio jambo gumu zaidi kufanya.
Lakini maandishi yana shida kadhaa:
- Hati kawaida huandikwa kwa haraka na kwa hivyo ni za zamani sana hivi kwamba zina hali moja tu ya hali bora. Hii inawezeshwa na ukweli kwamba msanidi ana nia ya utoaji wa haraka, wakati hati inayofaa inahitaji uwekezaji mkubwa wa rasilimali.
- Kama matokeo ya hoja iliyotangulia, hati hazina taratibu za uondoaji
- hakuna utaratibu wa uboreshaji uliowekwa
- Wakati bidhaa mpya inaonekana, unahitaji kuandika hati mpya
- hakuna msaada wa utegemezi
Kwa kweli, unaweza kuandika maandishi ya kisasa, lakini, kama nilivyoandika hapo juu, hii inachukua muda kwa maendeleo, na sio kidogo, na, kama tunavyojua, hakuna wakati wa kutosha.
Yote haya yanaweka mipaka kwa uwazi upeo wa njia hii ya kupeleka kwa mifumo rahisi tu. Ni wakati wa kubadili hilo.
Docker
Wakati fulani, tulianza kupata vipengee vipya vya kati, tukibubujika na mawazo na kukerwa kuhusu Docker. Naam, twende! Tulijaribu mara mbili. Wote wawili walishindwa-wacha tuseme, kwa sababu ya tamaa kubwa lakini ukosefu wa uzoefu wa ulimwengu halisi. Je, tunapaswa kuiharakisha na kuimaliza kwa gharama yoyote? Haiwezekani—timu inahitaji kubadilika hadi kufikia kiwango kinachohitajika kabla ya kutumia zana zinazofaa. Zaidi ya hayo, wakati wa kutumia picha za Docker zilizotengenezwa tayari, mara nyingi tulikumbana na matatizo ya mtandao (ambayo huenda yalitokana na hali isiyotengenezwa ya Docker yenyewe) au matatizo ya kupanua vyombo vya watu wengine.
Je, ni usumbufu gani tuliokumbana nao?
- Matatizo ya mtandao katika hali ya daraja
- Haifai kutazama kumbukumbu kwenye kontena (isipokuwa zimehifadhiwa kando katika mfumo wa faili wa mashine ya mwenyeji)
- ElasticSearch mara kwa mara huganda kwa kushangaza ndani ya chombo, sababu haijabainishwa, chombo ni rasmi.
- Ni vigumu kutumia shell ndani ya chombo - kila kitu ni mdogo sana, hakuna zana zinazojulikana
- Ukubwa mkubwa wa vyombo vilivyokusanywa - ghali kuhifadhi
- Kwa sababu ya saizi kubwa ya vyombo, ni ngumu kuunga mkono matoleo mengi.
- Muda mrefu zaidi wa ujenzi ikilinganishwa na njia zingine (hati au vifurushi vya deb)
Kwa upande mwingine, kwa nini huduma ya Spring kwenye kumbukumbu ya JAR ni mbaya zaidi kuliko kuipeleka kupitia kifurushi cha DEB? Je, kutengwa kwa rasilimali ni muhimu kweli? Inafaa kupoteza zana rahisi za mfumo wa kufanya kazi kwa kubandika huduma kwenye chombo kilichovuliwa sana?
Kama mazoezi yameonyesha, hii sio lazima kabisa; kifurushi cha deb kinatosha katika 90% ya kesi.
Deb nzuri ya zamani inashindwa lini na ni lini tunahitaji docker?
Kwa sisi, hii ilihusisha kupeleka huduma za Python. Maktaba nyingi zinazohitajika kwa ajili ya kujifunza kwa mashine ambazo hazikujumuishwa katika usambazaji wa kawaida wa mfumo wa uendeshaji (na kilichojumuishwa kilikuwa katika matoleo yasiyo sahihi), udukuzi wa usanidi, na hitaji la matoleo tofauti ya huduma tofauti zinazoendeshwa kwenye mfumo mmoja wa mwenyeji kulimaanisha kuwa Docker ndiyo njia pekee ya busara ya kuwasilisha mchanganyiko huu wa kernel. Kuunda kontena la Docker kuligeuka kuwa kazi ngumu zaidi kuliko kufunga kila kitu katika vifurushi tofauti vya .deb vilivyo na vitegemezi—na, kusema ukweli, hakuna mtu mwenye akili timamu ambaye angejaribu hilo.
Eneo la pili ambapo Docker imepangwa kutumika ni kwa ajili ya kupeleka huduma kwa kutumia mpango wa upelekaji wa bluu-kijani. Hata hivyo, hapa tunataka ongezeko la taratibu katika utata: kwanza, tunajenga vifurushi vya deb, na kisha tunajenga chombo cha Docker kutoka kwao.
Mifuko ya snap
Turudi kwenye vifurushi vya picha. Vilionekana rasmi kwa mara ya kwanza katika Ubuntu Aprili 16.04. Tofauti na vifurushi vya kawaida vya DEB na RPM, vifurushi vya picha hujumuisha utegemezi wote. Ingawa hii huepuka migogoro ya maktaba, pia inamaanisha kuwa kifurushi kinachotokana ni kikubwa zaidi. Zaidi ya hayo, hii inaweza kuathiri usalama wa mfumo: wakati wa kusambaza vifurushi, msanidi programu anayeunda kifurushi lazima adhibiti mabadiliko yote kwenye maktaba zilizojumuishwa. Kwa ujumla, si rahisi sana, na kuzitumia sio kila wakati hali ya faida kwa wote. Hata hivyo, ni mbadala unaofaa kabisa ikiwa, kwa mfano, Docker inatumika tu kama zana ya ufungashaji, si kwa ajili ya uboreshaji.
Kwa hivyo, kwa sasa tunatumia mchanganyiko unaofaa wa vifurushi vya madeni na kontena za Docker, ambazo tunaweza kubadilisha na vifurushi vya haraka katika visa vingine.
Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. tafadhali.
Unatumia nini kwa utoaji?
Maandishi ya kujiandikisha
Kunakili mwenyewe kwa FTP
vifurushi vya deb
vifurushi vya rpm
Vifurushi vya Snap
Picha za Docker
Picha za mashine halisi
Kufunga HDD nzima
bandia
inayohusika
P "SЂSѓRіRѕRμ
Watumiaji 109 walipiga kura. Watumiaji 32 walijizuia.
Chanzo: mapenzi.com
