🥇Առաքման գործիքների կամ մտքերի էվոլյուցիան Docker-ի, deb-ի, jar-ի և այլ բաների վերաբերյալ

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան

Ինչ-որ պահի ես որոշեցի հոդված գրել առաքման մասին դոկեր բեռնարկղերի և դեբային փաթեթների տեսքով, բայց երբ սկսեցի, չգիտես ինչու տարվել էի առաջին անհատական համակարգիչների և նույնիսկ հաշվիչների հեռավոր ժամանակները: Ընդհանրապես, docker-ի և deb-ի չոր համեմատությունների փոխարեն ես ստացա էվոլյուցիայի թեմայով այս մտքերը, որոնք ներկայացնում եմ ձեր դատողության համար։

Ցանկացած ապրանք, անկախ նրանից, թե ինչ է այն, ինչ-որ կերպ պետք է հասնի արտադրանքի սերվերներին, կազմաձևվի և գործարկվի: Ահա թե ինչի մասին է լինելու այս հոդվածը:

Ես կանդրադառնամ պատմական համատեքստում, «այն, ինչ ես տեսնում եմ, դա այն է, ինչի մասին ես երգում եմ», այն, ինչ ես տեսա, երբ առաջին անգամ սկսեցի ծածկագիր գրել և ինչ եմ դիտում հիմա, այն, ինչ մենք ինքներս ենք օգտագործում այս պահին և ինչու: Հոդվածը չի հավակնում լինել լիարժեք ուսումնասիրության, որոշ կետեր բաց են թողնվել, սա իմ անձնական տեսակետն է, թե ինչ էր և ինչ կա հիմա:

Այսպիսով, հին բարի ժամանակներում… առաքման ամենավաղ եղանակը, որը ես հիշում եմ, ձայնագրիչներն էին: Ես ունեի համակարգիչ BK-0010.01…

Հաշվիչների դարաշրջան

Չէ, ավելի վաղ պահ է եղել, եղել է նաև հաշվիչը MK-61 и MK-52.

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Այսպիսով, երբ ես ունեի MK-61, ապա ծրագրի փոխանցման եղանակը սովորական թղթի կտոր էր տուփի մեջ, որի վրա գրված էր ծրագիրը, որը անհրաժեշտության դեպքում ձեռքով գրվում էր հաշվիչի մեջ։ Եթե ուզում ես խաղալ (այո, նույնիսկ այս նախածանցային հաշվիչը խաղեր ուներ), դու նստում ես և ծրագիր ես մտնում հաշվիչի մեջ։ Բնականաբար, երբ հաշվիչը անջատվեց, ծրագիրը մոռացության մատնվեց։ Բացի թղթի վրա ձեռքով գրված հաշվիչի ծածկագրերից, հաղորդումները տպագրվել են «Ռադիո» և «Տեխնոլոգիա երիտասարդության համար» ամսագրերում, տպագրվել նաև այն ժամանակվա գրքերում։

Հաջորդ փոփոխությունը հաշվիչն էր MK-52, այն արդեն ունի տվյալների ոչ անկայուն պահպանման որոշակի տեսք: Այժմ այլևս պետք չէր ձեռքով որևէ խաղ կամ ծրագիր մուտք գործել, այլ կոճակներով մի քանի կախարդական փոխանցումներ կատարելուց հետո այն ինքն իրեն բեռնում էր։

Հաշվիչի ամենամեծ ծրագրի չափը 105 քայլ էր, իսկ MK-52-ում մշտական հիշողության չափը՝ 512 քայլ։

Ի դեպ, եթե կան այս հաշվիչների երկրպագուներ, ովքեր կարդում են այս հոդվածը, հոդվածը գրելու ընթացքում ես գտա և՛ հաշվիչ էմուլյատոր Android-ի համար, և՛ դրա համար նախատեսված ծրագրեր: Առաջ դեպի անցյալ!

Մի փոքր շեղում MK-52-ի մասին (Վիքիպեդիայից)
MK-52-ը տիեզերք թռավ «Սոյուզ TM-7» տիեզերանավի վրա։ Այն նախատեսված էր վայրէջքի հետագիծը հաշվարկելու համար, եթե բորտ համակարգիչը խափանվեր։
52 թվականից MK-1988-ը Elektronika-Astro հիշողության ընդլայնման միավորով մատակարարվում է նավատորմի նավերին՝ որպես նավիգացիոն հաշվողական հավաքածուի մաս:

Առաջին անհատական համակարգիչները

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Վերադառնանք ժամանակներին մ.թ.ա.-0010. Հասկանալի է, որ այնտեղ ավելի շատ հիշողություն կար, և ծածկագիրը թղթից մուտքագրելն արդեն տարբերակ չէր (չնայած սկզբում ես հենց այդպես էլ արեցի, քանի որ այլ միջոց պարզապես չկար)։ Ձայնագրիչների ձայներիզները դառնում են ծրագրային ապահովման պահպանման և առաքման հիմնական միջոցը:

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Կասետի վրա պահեստը սովորաբար մեկ կամ երկու երկուական ֆայլ էր՝ ներսում մնացած ամեն ինչով: Հուսալիությունը շատ ցածր էր, անհրաժեշտ էր պահել ծրագրի 2-3 օրինակ։ Բեռնման ժամանակները նույնպես հուսադրող չէին, և էնտուզիաստները փորձեր էին անում տարբեր հաճախականության կոդավորումներով՝ այդ թերությունները հաղթահարելու համար: Այն ժամանակ ես ինքս դեռ չէի զբաղվում ծրագրային ապահովման պրոֆեսիոնալ մշակմամբ (բացի BASIC-ում պարզ ծրագրերից), ուստի, ցավոք, չեմ կարող մանրամասն պատմել, թե ինչպես էր ամեն ինչ դասավորվել ներսում։ Հենց այն փաստը, որ համակարգիչն ուներ միայն RAM, մեծապես որոշեց տվյալների պահպանման սխեմայի պարզությունը:

Հուսալի և մեծ պահեստային կրիչների առաջացում

Հետագայում հայտնվեցին անգործունյա սկավառակներ, պատճենման գործընթացը դարձավ ավելի պարզ, հուսալիությունը բարձրացավ։
Բայց իրավիճակը արմատապես փոխվում է միայն այն դեպքում, երբ հայտնվում են բավականաչափ մեծ տեղական պահեստներ HDD-ների տեսքով:

Առաքման տեսակը հիմնովին փոխվում է. հայտնվում են տեղադրող ծրագրեր, որոնք ղեկավարում են համակարգի կազմաձևման գործընթացը, ինչպես նաև մաքրումը հեռացնելուց հետո, քանի որ ծրագրերը պարզապես չեն ընթերցվում հիշողության մեջ, այլ արդեն պատճենվում են տեղական պահեստում, որտեղից անհրաժեշտության դեպքում անհրաժեշտ է մաքրել ավելորդները:

Միաժամանակ ավելանում է մատակարարվող ծրագրաշարի բարդությունը։
Առաքման մեջ ֆայլերի թիվը միավորներից հասնում է հարյուրների և հազարների, գրադարանային տարբերակների հակասությունները և այլ ուրախություններ են սկսվում, երբ տարբեր ծրագրեր օգտագործում են նույն տվյալները:

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Այդ ժամանակ գոյությունը դեռ ինձ համար բացահայտված չէր LinuxԵս ապրել եմ MS DOS-ի աշխարհում, իսկ ավելի ուշ՝ Windows, և գրել է Borland Pascal-ով և Delphi-ով, երբեմն-երբեմն փորձելով նաև C++-ը։ Այդ ժամանակ շատերը օգտագործում էին InstallShield-ը արտադրանք մատակարարելու համար։ ru.wikipedia.org/wiki/InstallShield, որը բավականին հաջողությամբ լուծեց ծրագրային ապահովման տեղակայման և կազմաձևման բոլոր խնդիրները։

Համացանցի դարաշրջան

Աստիճանաբար ծրագրային համակարգերի բարդությունը դառնում է ավելի բարդ՝ մոնոլիտներից և աշխատասեղանի հավելվածներից մինչև բաշխված համակարգեր, thin clients և microservices: Այժմ դուք պետք է կազմաձևեք ոչ միայն մեկ ծրագիր, այլ դրանց մի շարք և այնպես, որ բոլորը միասին աշխատեն:

Հայեցակարգն ամբողջությամբ փոխվեց, եկավ ինտերնետը, սկսվեց ամպային ծառայությունների դարաշրջանը։ Առայժմ այն միայն իր սկզբնական փուլում է՝ կայքերի տեսքով. ոչ ոք իրականում չի երազում ծառայությունների մասին: բայց դա շրջադարձային էր ինչպես զարգացման, այնպես էլ հավելվածների իրական առաքման ոլորտում:

Ես ինքս նկատեցի, որ այդ պահին ծրագրավորողների սերունդների փոփոխություն եղավ (թե դա պարզապես իմ շրջապատում էր), և թվում էր, թե առաքման բոլոր հին լավ մեթոդները մի պահ մոռացվեցին, և ամեն ինչ սկսվեց հենց սկզբից. Փաստորեն, սկսվել է քաոսի շրջանը, երբ հինը մոռացվում է ու չի օգտագործվում, իսկ նորը պարզապես չկա։

Հիշում եմ այն ժամանակները, երբ այն ընկերությունում, որտեղ ես աշխատում էի այն ժամանակ (անունը չեմ նշի), մրջյունների միջոցով կառուցելու փոխարեն (այդ ժամանակ maven-ը հայտնի չէր կամ ընդհանրապես գոյություն չուներ), մարդիկ պարզապես IDE-ում բանկա էին շինում և անխռով հանձնում այն SVN-ին: Համապատասխանաբար, տեղակայումը բաղկացած էր ֆայլը SVN-ից ստանալուց և այն SSH-ի միջոցով ցանկալի մեքենայի վրա պատճենելուց: Դա այնքան պարզ և կոպիտ է:

Միևնույն ժամանակ, պարզ PHP կայքերի առաքումն իրականացվել է շատ պարզունակ ձևով, պարզապես ուղղագրված ֆայլը FTP-ի միջոցով պատճենելով թիրախային մեքենային։ Երբեմն նման բան չկար՝ կոդը խմբագրվում էր ուղիղ հեռարձակմամբ պրոդյուսերական սերվերում, և հատկապես շքեղ էր, եթե ինչ-որ տեղ կրկնօրինակումներ լինեին։

RPM և DEB փաթեթներ

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Մյուս կողմից, ինտերնետի զարգացման հետ մեկտեղ, UNIX-անման համակարգերը սկսեցին ավելի ու ավելի մեծ ժողովրդականություն ձեռք բերել, մասնավորապես, հենց այդ ժամանակ ես հայտնաբերեցի RedHat-ը։ Linux 6, մոտ 2000 թվականին։ Բնականաբար, այնտեղ նույնպես կային ծրագրային ապահովումը տրամադրելու որոշակի միջոցներ։ Վիքիպեդիայի համաձայն, RPM-ը որպես հիմնական փաթեթների կառավարիչ հայտնվել է դեռևս 1995 թվականին՝ RedHat տարբերակում։ Linux 2.0։ Այդ ժամանակվանից ի վեր համակարգը մատակարարվել է որպես RPM փաթեթներ և շարունակում է զարգանալ։

Ընտանիքի բաշխումները Debian Նրանք հետևեցին նմանատիպ ուղու և իրականացրին մատակարարումը deb փաթեթների տեսքով, որը մինչ օրս անփոփոխ է մնացել։

Փաթեթների կառավարիչները թույլ են տալիս ինքնուրույն առաքել ծրագրային արտադրանք, կարգավորել դրանք տեղադրման ընթացքում, կառավարել կախվածությունը տարբեր փաթեթների միջև, հեռացնել արտադրանքները և մաքրել ավելորդ տարրերը տեղահանման ժամանակ: Նրանք. Մեծ մասամբ դա այն ամենն է, ինչ անհրաժեշտ է, այդ իսկ պատճառով դրանք տասնամյակներ շարունակ գրեթե անփոփոխ են մնացել:

Cloud computing-ն ավելացրել է տեղադրումը ոչ միայն ֆիզիկական լրատվամիջոցներից, այլև ամպային պահեստներից մինչև փաթեթների կառավարիչներ, բայց սկզբունքորեն քիչ բան է փոխվել:

Հարկ է նշել, որ ներկայումս որոշ փորձեր կան՝ հեռանալ deb-ից և դեպի snap փաթեթներ, բայց դրա մասին ավելի ուշ:

Այսպիսով, ամպային մշակողների այս նոր սերունդը, որը չգիտեր ոչ DEB, ոչ RPM, նույնպես դանդաղ աճեց, փորձ ձեռք բերեց, ապրանքներն ավելի բարդացան, և անհրաժեշտ էին առաքման ավելի խելամիտ մեթոդներ, քան FTP-ն, bash scripts-ը և նմանատիպ ուսանողական արհեստները:
Այստեղ է հայտնվում Docker-ը՝ վիրտուալացման, ռեսուրսների մեկուսացման և առաքման եղանակի մի տեսակ խառնուրդ: Հիմա նորաձև ու երիտասարդական է, բայց արդյո՞ք դա անհրաժեշտ է ամեն ինչի համար։ Սա համադարմա՞ն է:

Իմ դիտարկմամբ՝ շատ հաճախ Docker-ին առաջարկվում է ոչ թե որպես ողջամիտ ընտրություն, այլ պարզապես այն պատճառով, որ մի կողմից դրա մասին խոսում են համայնքում, իսկ առաջարկողները միայն գիտեն դա։ Մյուս կողմից, հին լավ փաթեթավորման համակարգերը հիմնականում լռում են. դրանք կան և իրենց գործն անում են հանգիստ ու աննկատ: Նման իրավիճակում այլ ընտրություն չկա՝ ընտրությունն ակնհայտ է՝ Դոկեր։

Ես կփորձեմ կիսվել իմ փորձով, թե ինչպես ենք մենք իրականացրել Docker-ը և ինչ արդյունք է տվել:

Ինքնուրույն գրված սցենարներ

Սկզբում կային bash սկրիպտներ, որոնք տեղադրում էին բանկաների արխիվները պահանջվող մեքենաներում: Այս գործընթացը ղեկավարում էր Ջենկինսը։ Սա հաջողությամբ աշխատեց, քանի որ բանկա արխիվն ինքնին արդեն դասեր, ռեսուրսներ և նույնիսկ կոնֆիգուրացիա պարունակող ժողով է: Եթե դուք ամեն ինչ դնում եք դրա մեջ առավելագույնը, ապա այն սցենարի մեջ դնելը ամենադժվար բանը չէ, որ պետք է անել

Բայց սցենարներն ունեն մի քանի թերություններ.

Սցենարները սովորաբար գրվում են հապճեպ և, հետևաբար, այնքան պարզունակ են, որ պարունակում են միայն մեկ առավել բարենպաստ սցենար: Դրան նպաստում է այն փաստը, որ մշակողը շահագրգռված է ամենաարագ առաքմամբ, իսկ նորմալ սցենարը պահանջում է արժանապատիվ ռեսուրսներ:
Նախորդ կետի հետևանքով սկրիպտները չեն պարունակում տեղահանման ընթացակարգեր
չկա արդիականացման սահմանված կարգ
Երբ հայտնվում է նոր արտադրանք, դուք պետք է գրեք նոր սցենար
ոչ կախվածության աջակցություն

Իհարկե, կարելի է բարդ սցենար գրել, բայց, ինչպես վերևում գրեցի, դրա զարգացման համար ժամանակ է պահանջվում, և ոչ պակաս, և, ինչպես գիտենք, ժամանակը երբեք չի բավականացնում:

Այս ամենը ակնհայտորեն սահմանափակում է այս տեղակայման մեթոդի կիրառման շրջանակը միայն ամենապարզ համակարգերով: Սա փոխելու ժամանակը եկել է։

դոկեր

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Ինչ-որ պահի, նոր թխված միջինները սկսեցին գալ մեզ մոտ, գաղափարներով փրփրացող և դոկերի մասին զառանցանք: Դե, արի գնանք։ Եկեք դա անենք: Երկու փորձ եղավ. Երկուսն էլ անհաջող էին, ասենք, մեծ հավակնությունների, բայց իրական փորձի բացակայության պատճառով։ Պե՞տք էր ամեն կերպ ստիպել ու ավարտել։ Քիչ հավանական է. թիմը պետք է զարգանա մինչև անհրաժեշտ մակարդակը, որպեսզի կարողանա օգտագործել համապատասխան գործիքները: Բացի այդ, պատրաստի Docker պատկերներ օգտագործելիս մենք հաճախ բախվում էինք այն փաստի հետ, որ ցանցը ճիշտ չէր աշխատում (որը հավանաբար նաև բուն Docker-ի հումքի պատճառով էր) կամ դժվար էր ընդլայնել այլ մարդկանց կոնտեյներները։

Ի՞նչ անհարմարությունների հանդիպեցինք։

Ցանցի խնդիրները կամուրջի ռեժիմում
Անհարմար է տեղեկամատյանները դիտել կոնտեյներով (եթե դրանք առանձին չեն տեղափոխվել հյուրընկալող մեքենայի ֆայլային համակարգ)
ElasticSearch-ի պարբերաբար տարօրինակ սառեցում տարայի ներսում, պատճառը պարզված չէ, տարան պաշտոնական է
Կոնտեյների ներսում կեղևն օգտագործելը անհարմար է. ամեն ինչ շատ սահմանափակ է, սովորական գործիքներ չկան
Հավաքված տարաների մեծ չափս՝ թանկ է պահելու համար
Տարաների մեծ չափերի պատճառով դժվար է աջակցել մի քանի տարբերակների:
Կառուցման ավելի երկար ժամանակ, քան այլ մեթոդներ (սկրիպտներ կամ deb փաթեթներ)

Մյուս կողմից, ինչու՞ է ավելի վատ գարնանային ծառայությունը նույն դեբի միջոցով բանկա արխիվի տեսքով տեղակայելը: Արդյո՞ք ռեսուրսների մեկուսացումն իսկապես անհրաժեշտ է: Արժե՞ կորցնել օպերացիոն համակարգի հարմար գործիքները՝ ծառայությունը խցկելով խիստ կրճատված կոնտեյների մեջ:

Ինչպես ցույց տվեց պրակտիկան, իրականում դա անհրաժեշտ չէ. Deb փաթեթը բավարար է 90% դեպքերում:

Ե՞րբ է ձախողվում հին լավ դեբը, և ե՞րբ է մեզ իսկապես անհրաժեշտ դոկեր:

Մեզ համար դա ծառայություններ էր տեղակայում python-ում: Շատ գրադարաններ, որոնք անհրաժեշտ էին մեքենայական ուսուցման համար և ներառված չէին ստանդարտ օպերացիոն համակարգի առաքման մեջ (և այն, ինչ կար, ճիշտ տարբերակը չէր), կարգավորումների հետ կապված հաքերները, նույն ընդունող համակարգում ապրող տարբեր ծառայությունների տարբեր տարբերակների անհրաժեշտությունը հանգեցրեց նրան, որ այս միջուկային խառնուրդը մատուցելու միակ ողջամիտ միջոցը Docker-ն էր: Դոկեր կոնտեյների հավաքման աշխատանքի ինտենսիվությունը պարզվեց, որ ավելի ցածր է, քան այս ամենը կախվածություններով առանձին դեբային փաթեթների մեջ փաթեթավորելու գաղափարը, և իրականում ոչ ոք իր մտքով չէր վերցնի դա:

Երկրորդ կետը, որտեղ նախատեսվում է օգտագործել docker-ը, ծառայությունների տեղակայումն է՝ օգտագործելով կապույտ-կանաչ տեղակայման սխեման: Բայց այստեղ մենք ցանկանում ենք ստանալ բարդության աստիճանական աճ՝ նախ կառուցվում են deb փաթեթներ, իսկ հետո դրանցից կառուցվում է դոկեր կոնտեյներ։

Snap փաթեթներ

Առաքման գործիքների կամ Docker-ի, deb-ի, jar-ի և այլնի մասին մտքերի էվոլյուցիան Վերադառնանք Snap փաթեթներին։ Դրանք առաջին անգամ պաշտոնապես հայտնվեցին Ubuntu Ապրիլի 16.04։ Ի տարբերություն ավանդական DEB և RPM փաթեթների, snaps-երը ներառում են բոլոր կախվածությունները։ Չնայած սա խուսափում է գրադարանային կոնֆլիկտներից, դա նաև նշանակում է, որ արդյունքում ստացված փաթեթը ավելի մեծ է։ Ավելին, սա կարող է ազդել համակարգի անվտանգության վրա. snaps տեղակայելիս փաթեթը ստեղծող մշակողը պետք է կառավարի ներառված գրադարանների բոլոր փոփոխությունները։ Ընդհանուր առմամբ, դա այդքան էլ պարզ չէ, և դրանց օգտագործումը միշտ չէ, որ փոխշահավետ իրավիճակ է։ Այնուամենայնիվ, դա լիովին ողջամիտ այլընտրանք է, եթե, օրինակ, Docker-ը օգտագործվի միայն որպես փաթեթավորման գործիք, այլ ոչ թե վիրտուալիզացիայի համար։

Արդյունքում, մենք այժմ օգտագործում ենք և՛ deb փաթեթները, և՛ docker կոնտեյներները ողջամիտ համակցությամբ, որոնք որոշ դեպքերում կարող ենք փոխարինել snap փաթեթներով:

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ: