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

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

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

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

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

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

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

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

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

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

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

• Էմուլյատոր MK-61 Android-ի համար
• Ծրագրերի կատալոգ MK-61-ի համար

Կարճ շեղում MK-52-ի մասին (Վիքիպեդիայից)

MK-52-ը տիեզերք թռավ Soyuz TM-7 տիեզերանավով։ Ենթադրվում էր, որ այն պետք է օգտագործվեր վայրէջքի հետագիծը հաշվարկելու համար, եթե բորտ համակարգիչը խափանվեր։

52 թվականից MK-1988-ը Elektronika-Astro հիշողության ընդլայնման միավորով մատակարարվում է նավատորմի նավերին՝ որպես նավիգացիոն հաշվողական հավաքածուի մաս:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RPM և DEB փաթեթներ

Մյուս կողմից, ինտերնետի զարգացման հետ մեկտեղ 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-ի պատրաստի պատկերներ օգտագործելիս մենք հաճախ բախվում էինք ցանցի ճիշտ չաշխատելու հետ (ինչը կարող էր պայմանավորված լինել հենց Docker-ի խոնավությամբ) կամ դժվար էր ընդլայնել այլ մարդկանց կոնտեյներները։

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

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

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

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

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

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

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

Snap փաթեթներ

Եկեք վերադառնանք snap փաթեթներին: Նրանք առաջին անգամ պաշտոնապես հայտնվեցին Ubuntu 16.04-ում: Ի տարբերություն սովորական deb փաթեթների և rpm փաթեթների, snap-ը կրում է բոլոր կախվածությունները: Սա մի կողմից թույլ է տալիս խուսափել գրադարանային կոնֆլիկտներից, մյուս կողմից՝ ստացված փաթեթն ավելի մեծ է չափերով։ Բացի այդ, սա կարող է ազդել նաև համակարգի անվտանգության վրա. ակնթարթային առաքման դեպքում ներառված գրադարանների բոլոր փոփոխությունները պետք է վերահսկվեն փաթեթը ստեղծող մշակողի կողմից: Ընդհանրապես, ամեն ինչ այնքան էլ պարզ չէ, և համընդհանուր երջանկությունը չի գալիս դրանց օգտագործումից։ Բայց, այնուամենայնիվ, սա միանգամայն ողջամիտ այլընտրանք է, եթե նույն Docker-ը օգտագործվի միայն որպես փաթեթավորման գործիք, այլ ոչ վիրտուալացման համար։

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

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

Ինչ եք օգտագործում առաքման համար:

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

• Ձեռքով պատճենեք FTP-ում

• deb փաթեթներ

• rpm փաթեթներ

• snap փաթեթներ

• Docker-պատկերներ

• Վիրտուալ մեքենայի պատկերներ

• Կլոնավորեք ամբողջ HDD-ը

• տիկնիկային

• ածելի

• Այլ

Քվեարկել է 109 օգտատեր։ 32 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com