Ինչ է Դոկերը. համառոտ էքսկուրսիա դեպի պատմություն և հիմնական աբստրակցիաներ

Մեկնարկեց օգոստոսի 10-ին Slurm-ում Docker վիդեո դասընթաց, որում մենք ամբողջությամբ վերլուծում ենք այն՝ հիմնական աբստրակցիաներից մինչև ցանցային պարամետրեր։

Այս հոդվածում մենք կխոսենք Docker-ի պատմության և նրա հիմնական աբստրակցիաների մասին՝ Image, Cli, Dockerfile: Դասախոսությունը նախատեսված է սկսնակների համար, ուստի դժվար թե այն հետաքրքրի փորձառու օգտատերերին: Չի լինի արյուն, կույր աղիք կամ խորը ընկղմում: Հենց հիմունքները.

Ինչ է Docker-ը

Եկեք տեսնենք Docker-ի սահմանումը Վիքիպեդիայից։

Docker-ը ծրագրային ապահովում է՝ բեռնարկղային միջավայրերում հավելվածների տեղակայումն ու կառավարումն ավտոմատացնելու համար:

Այս սահմանումից ոչինչ պարզ չէ: Հատկապես անհասկանալի է, թե ինչ է նշանակում «միջավայրերում, որոնք աջակցում են կոնտեյներացմանը»: Պարզելու համար եկեք հետ գնանք ժամանակը: Սկսենք այն դարաշրջանից, որը ես պայմանականորեն անվանում եմ «մոնոլիտ դարաշրջան»:

Մոնոլիտ դարաշրջան

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

Կենդանիները ընտանի կենդանիներ են։ Միաձույլ դարաշրջանում մենք մեր սերվերներին վերաբերվում էինք ինչպես ընտանի կենդանիների՝ խնամված և փայփայված՝ փոշու բծերը փչելով: Իսկ ռեսուրսների ավելի լավ կառավարման համար մենք օգտագործեցինք վիրտուալացում. վերցրեցինք սերվերը և կտրեցինք այն մի քանի վիրտուալ մեքենաների մեջ՝ դրանով իսկ ապահովելով շրջակա միջավայրի մեկուսացումը։

Hypervisor-ի վրա հիմնված վիրտուալացման համակարգեր

Հավանաբար բոլորը լսել են վիրտուալացման համակարգերի մասին՝ VMware, VirtualBox, Hyper-V, Qemu KVM և այլն: Դրանք ապահովում են հավելվածների մեկուսացում և ռեսուրսների կառավարում, բայց ունեն նաև թերություններ: Վիրտուալիզացիա անելու համար ձեզ հարկավոր է հիպերվիզոր: Իսկ հիպերվիզորը ռեսուրս է: Իսկ վիրտուալ մեքենան ինքնին սովորաբար մի ամբողջ վիթխարի է` ծանր պատկեր, որը պարունակում է օպերացիոն համակարգ, Nginx, Apache և, հնարավոր է, MySQL: Պատկերը մեծ է, և վիրտուալ մեքենան անհարմար է աշխատել: Արդյունքում, վիրտուալ մեքենաների հետ աշխատելը կարող է դանդաղ լինել: Այս խնդիրը լուծելու համար վիրտուալացման համակարգեր են ստեղծվել միջուկի մակարդակում:

Միջուկի մակարդակի վիրտուալացման համակարգեր

Միջուկի մակարդակի վիրտուալիզացիան աջակցվում է OpenVZ, Systemd-nspawn, LXC համակարգերով: Նման վիրտուալացման վառ օրինակ է LXC-ը (Linux Containers):

LXC-ն օպերացիոն համակարգի մակարդակի վիրտուալացման համակարգ է՝ Linux օպերացիոն համակարգի մի քանի մեկուսացված օրինակներ մեկ հանգույցի վրա գործարկելու համար: LXC-ն չի օգտագործում վիրտուալ մեքենաներ, այլ ստեղծում է վիրտուալ միջավայր՝ իր սեփական պրոցեսի տարածությամբ և ցանցային ստեկով:

Հիմնականում LXC-ն ստեղծում է կոնտեյներներ: Ո՞րն է տարբերությունը վիրտուալ մեքենաների և բեռնարկղերի միջև:

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

Վիրտուալացման և կոնտեյներացման միջև եղած տարբերությունները կարելի է տեսնել դիագրամում:
Կան ապարատային հիպերվիզորներ, OS-ի վերևում գտնվող հիպերվիզորներ և կոնտեյներներ:

Սարքավորումների հիպերվիզորները հիանալի են, եթե իսկապես ցանկանում եք ինչ-որ բան մեկուսացնել: Որովհետև հնարավոր է մեկուսացնել հիշողության էջերի և պրոցեսորների մակարդակով։

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

Ինչ է օգտագործվում միջուկի մակարդակում կոնտեյներացման համար

Հիմնական տեխնոլոգիաները, որոնք թույլ են տալիս ստեղծել այլ գործընթացներից մեկուսացված կոնտեյներ, Անվանատարածքներն են և Կառավարման Խմբերը:

Անվանատարածքներ՝ PID, Ցանցային, Մոնտաժ և Օգտագործող: Կան ավելին, բայց հասկանալու համար մենք կկենտրոնանանք դրանց վրա:

PID անվանումների տարածքը սահմանափակում է գործընթացները: Երբ, օրինակ, մենք ստեղծում ենք PID Անվանատարածք և այնտեղ տեղադրում պրոցես, այն դառնում է PID 1: Սովորաբար համակարգերում PID 1-ը համակարգված է կամ սկզբնական: Համապատասխանաբար, երբ մենք գործընթացը տեղադրում ենք նոր անվանատարածքում, այն նաև ստանում է PID 1:

Networking Namespace-ը թույլ է տալիս սահմանափակել/մեկուսացնել ցանցը և տեղադրել ձեր սեփական միջերեսները ներսում: Mount-ը ֆայլային համակարգի սահմանափակում է: Օգտատեր - օգտատերերի սահմանափակում:

Կառավարման խմբեր՝ հիշողություն, պրոցեսոր, IOPS, ցանց՝ ընդհանուր առմամբ մոտ 12 կարգավորում: Հակառակ դեպքում դրանք կոչվում են նաև Cgroups («C-groups»):

Վերահսկիչ խմբերը կառավարում են ռեսուրսները կոնտեյների համար: Վերահսկիչ խմբերի միջոցով կարող ենք ասել, որ կոնտեյները չպետք է սպառի որոշակի քանակությամբ ռեսուրսներ:

Կոնտեյներացման լիարժեք աշխատանքի համար օգտագործվում են լրացուցիչ տեխնոլոգիաներ՝ հնարավորություններ, Copy-on-write և այլն:

Կարողություններն այն են, երբ մենք գործընթացին ասում ենք, թե ինչ կարող է անել և ինչ չի կարող: Միջուկի մակարդակում սրանք պարզապես bitmaps են բազմաթիվ պարամետրերով: Օրինակ, արմատային օգտվողն ունի լիարժեք արտոնություններ և կարող է անել ամեն ինչ: Ժամանակի սերվերը կարող է փոխել համակարգի ժամանակը. այն ունի հնարավորություններ Time Capsule-ում, և վերջ: Օգտագործելով արտոնությունները՝ դուք կարող եք ճկուն կերպով կարգավորել գործընթացների սահմանափակումները և դրանով իսկ պաշտպանել ձեզ:

Copy-on-write համակարգը թույլ է տալիս մեզ աշխատել Docker պատկերների հետ և օգտագործել դրանք ավելի արդյունավետ:

Docker-ը ներկայումս համատեղելիության խնդիրներ ունի Cgroups v2-ի հետ, ուստի այս հոդվածը կենտրոնանում է հատկապես Cgroups v1-ի վրա:

Բայց վերադառնանք պատմությանը։

Երբ վիրտուալացման համակարգերը հայտնվեցին միջուկի մակարդակում, դրանք սկսեցին ակտիվորեն օգտագործվել: Հիպերվիզորի վերին ծախսերը անհետացան, բայց որոշ խնդիրներ մնացին.

• մեծ պատկերներ. նրանք մղում են օպերացիոն համակարգ, գրադարաններ, տարբեր ծրագրերի մի փունջ նույն OpenVZ-ի մեջ, և վերջում պատկերը դեռ բավականին մեծ է ստացվում.
• Փաթեթավորման և առաքման նորմալ ստանդարտ չկա, ուստի կախվածության խնդիրը մնում է: Կան իրավիճակներ, երբ երկու կոդ օգտագործում են նույն գրադարանը, բայց տարբեր տարբերակներով։ Նրանց միջեւ կարող է կոնֆլիկտ լինել։

Այս բոլոր խնդիրները լուծելու համար եկել է հաջորդ դարաշրջանը։

Կոնտեյների դարաշրջան

Երբ հասավ բեռնարկղերի դարաշրջանը, նրանց հետ աշխատելու փիլիսոփայությունը փոխվեց.

• Մեկ գործընթաց՝ մեկ կոնտեյներ։
• Մենք փոխանցում ենք գործընթացին անհրաժեշտ բոլոր կախվածությունները իր կոնտեյներով: Սա պահանջում է կտրել մոնոլիտները միկրոծառայությունների մեջ:
• Որքան փոքր է պատկերը, այնքան լավ. կան ավելի քիչ հնարավոր խոցելիություններ, այն ավելի արագ է գլորվում և այլն:
• Դեպքերը դառնում են անցողիկ:

Հիշո՞ւմ եք, թե ինչ ասացի ընտանի կենդանիների ընդդեմ անասունների մասին: Նախկինում ատյանները նման էին ընտանի կենդանիների, իսկ հիմա նմանվել են անասուններին։ Նախկինում կար մոնոլիտ՝ մեկ հավելված։ Այժմ դա 100 միկրոսերվիս է, 100 կոնտեյներ: Որոշ տարաներ կարող են ունենալ 2-3 կրկնօրինակ: Մեզ համար պակաս կարևոր է դառնում վերահսկել յուրաքանչյուր կոնտեյներ։ Մեզ համար ավելի կարևոր է հենց ծառայության առկայությունը. ինչ է անում այս բեռնարկղերի հավաքածուն: Սա փոխում է մոնիտորինգի մոտեցումները։

2014-2015 թվականներին Docker-ը ծաղկեց՝ այն տեխնոլոգիան, որի մասին մենք հիմա կխոսենք:

Դոկերը փոխեց փիլիսոփայությունը և ստանդարտացված հավելվածի փաթեթավորումը: Օգտագործելով Docker-ը, մենք կարող ենք փաթեթավորել հավելվածը, ուղարկել այն պահեստ, ներբեռնել այն այնտեղից և տեղակայել այն:

Մենք դնում ենք այն ամենը, ինչ անհրաժեշտ է Docker կոնտեյների մեջ, ուստի կախվածության խնդիրը լուծվում է: Docker-ը երաշխավորում է վերարտադրելիությունը: Կարծում եմ՝ շատերը հանդիպել են անվերարտադրելիության՝ ամեն ինչ աշխատում է քեզ մոտ, դու այն մղում ես արտադրության, և այնտեղ այն դադարում է աշխատել։ Docker-ի հետ այս խնդիրը վերանում է: Եթե ​​ձեր Docker կոնտեյները գործարկվի և կատարի այն, ինչ պետք է անի, ապա մեծ հավանականությամբ այն կսկսի արտադրվել և նույնը կանի այնտեղ:

Շեղում վերևի մասին

Միշտ վեճեր են լինում ընդհանուր ծախսերի վերաբերյալ։ Որոշ մարդիկ կարծում են, որ Docker-ը լրացուցիչ բեռ չի կրում, քանի որ այն օգտագործում է Linux միջուկը և դրա բոլոր գործընթացները, որոնք անհրաժեշտ են կոնտեյներացման համար: Օրինակ, «եթե ասում եք, որ Docker-ը գլխավերեւում է, ապա Linux միջուկը գլխավերեւում է»:

Մյուս կողմից, եթե ավելի խորանաք, իսկապես մի քանի բան կան Docker-ում, որոնք, երկարությամբ, կարելի է ասել, որ գլխավերեւում են:

Առաջինը PID անվանատարածքն է: Երբ պրոցեսը տեղադրում ենք անունների տարածքում, այն նշանակվում է PID 1: Միևնույն ժամանակ, այս պրոցեսն ունի մեկ այլ PID, որը գտնվում է հյուրընկալողի անվանատարածքում՝ բեռնարկղից դուրս: Օրինակ, մենք գործարկեցինք Nginx-ը կոնտեյներով, այն դարձավ PID 1 (հիմնական գործընթաց): Իսկ հոսթի վրա այն ունի PID 12623: Եվ դժվար է ասել, թե որքան գերավճար է դա:

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

Եվ ևս մեկ նշում կատարման մասին. Միջուկի որոշ պարամետրեր փոխանցվում են հոսթից դեպի կոնտեյներ: Մասնավորապես, ցանցի որոշ պարամետրեր. Հետևաբար, եթե ցանկանում եք գործարկել Docker-ում բարձր կատարողականություն, օրինակ, ինչ-որ բան, որն ակտիվորեն կօգտագործի ցանցը, ապա գոնե պետք է կարգավորեք այս պարամետրերը: Որոշ nf_conntrack, օրինակ.

Docker հայեցակարգի մասին

Docker-ը բաղկացած է մի քանի բաղադրիչներից.

1. Docker Daemon-ը նույն Container Engine-ն է; գործարկում է կոնտեյներներ.
2. Docker CII-ը Docker կառավարման կոմունալ ծրագիր է:
3. Dockerfile - հրահանգներ, թե ինչպես ստեղծել պատկեր:
4. Պատկեր — պատկեր, որից գլորված է տարան:
5. Տարա:
6. Docker ռեեստրը պատկերների պահոց է:

Սխեմատիկորեն նման բան է թվում.

Docker daemon-ն աշխատում է Docker_host-ում և գործարկում կոնտեյներներ: Կա Հաճախորդ, որն ուղարկում է հրամաններ՝ կառուցեք պատկերը, ներբեռնեք պատկերը, գործարկեք կոնտեյները: Docker daemon-ը գնում է ռեեստր և կատարում դրանք: Docker հաճախորդը կարող է մուտք գործել ինչպես տեղական (մինչև Unix վարդակից), այնպես էլ TCP-ի միջոցով հեռավոր հոսթից:

Եկեք անցնենք յուրաքանչյուր բաղադրիչի միջով:

Docker Daemon - սա սերվերի մասն է, այն աշխատում է հյուրընկալող մեքենայի վրա. ներբեռնում է պատկերներ և գործարկում դրանցից կոնտեյներներ, ստեղծում է ցանց բեռնարկղերի միջև, հավաքում տեղեկամատյանները: Երբ ասում ենք «ստեղծիր պատկեր», դևն էլ է դա անում։

Docker CLI — Docker-ի հաճախորդի մաս, կոնսոլի կոմունալ ծրագիր՝ դեյմոնի հետ աշխատելու համար: Կրկնում եմ՝ այն կարող է աշխատել ոչ միայն լոկալ, այլ նաև ցանցի միջոցով։

Հիմնական հրամաններ.

docker ps - ցուցադրել կոնտեյներներ, որոնք ներկայումս աշխատում են Docker հոսթում:
դոկերի պատկերներ - ցույց տալ տեղական ներբեռնված պատկերները:
docker search <> - որոնել պատկեր ռեեստրում:
docker pull <> - ներբեռնեք պատկեր ռեեստրից մեքենա:
docker build < > - հավաքել պատկերը:
docker run <> - գործարկել կոնտեյները:
docker rm <> - հեռացնել բեռնարկղը:
docker logs <> - բեռնարկղերի տեղեկամատյաններ
docker start/stop/restart <> - աշխատում է կոնտեյների հետ

Եթե ​​դուք տիրապետում եք այս հրամաններին և վստահ եք դրանք օգտագործելու մեջ, ապա օգտագործողի մակարդակում ինքներդ ձեզ 70%-ով տիրապետեք Docker-ին:

dockerfile - պատկեր ստեղծելու հրահանգներ: Գրեթե յուրաքանչյուր հրահանգի հրաման նոր շերտ է: Դիտարկենք մի օրինակ։

Ահա թե ինչ տեսք ունի Dockerfile-ը. հրամաններ ձախ կողմում, արգումենտներ՝ աջ: Յուրաքանչյուր հրաման, որը գտնվում է այստեղ (և ընդհանրապես գրված է Dockerfile-ում) ստեղծում է նոր շերտ Image-ում:

Անգամ ձախ կողմին նայելով՝ կարելի է մոտավորապես հասկանալ, թե ինչ է կատարվում։ Մենք ասում ենք. «ստեղծեք թղթապանակ մեզ համար», սա մեկ շերտ է: «Դարձնել թղթապանակը աշխատել» մեկ այլ շերտ է և այլն: Շերտավոր տորթը հեշտացնում է կյանքը։ Եթե ​​ես ստեղծեմ մեկ այլ Dockerfile և ինչ-որ բան փոխեմ վերջին տողում. ես գործարկում եմ այլ բան, քան «python» «main.py», կամ տեղադրում եմ կախվածություն մեկ այլ ֆայլից, ապա նախորդ շերտերը կվերօգտագործվեն որպես քեշ:

պատկեր - սա տարաների փաթեթավորում է, տարաները գործարկվում են պատկերից: Եթե ​​մենք նայում ենք Docker-ին փաթեթների կառավարչի տեսանկյունից (կարծես մենք աշխատում ենք deb կամ rpm փաթեթների հետ), ապա պատկերն ըստ էության rpm փաթեթ է: Yum install-ի միջոցով մենք կարող ենք տեղադրել հավելվածը, ջնջել այն, գտնել այն պահեստում և ներբեռնել այն։ Մոտավորապես նույնն է այստեղ. կոնտեյներները գործարկվում են պատկերից, դրանք պահվում են Docker ռեգիստրում (yum-ի նման՝ պահեստում), և յուրաքանչյուր պատկեր ունի SHA-256 հեշ, անուն և պիտակ:

Պատկերը կառուցված է Dockerfile-ի հրահանգների համաձայն: Dockerfile-ի յուրաքանչյուր հրահանգ ստեղծում է նոր շերտ: Շերտերը կարող են կրկին օգտագործվել:

Docker ռեեստր Docker պատկերների պահոց է: ՕՀ-ի նման, Docker-ն ունի հանրային ստանդարտ ռեգիստր՝ dockerhub: Բայց դուք կարող եք ստեղծել ձեր սեփական պահեստը, ձեր սեփական Docker ռեեստրը:

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

«Մեկ կոնտեյներ, մեկ գործընթաց» պահանջը կապված է PID Անվանատարածքի հետ: Երբ PID 1-ով գործընթացը սկսվում է Անվանատարածքում, եթե այն հանկարծակի մահանում է, ապա ամբողջ կոնտեյները նույնպես մահանում է: Եթե ​​այնտեղ երկու գործընթաց է ընթանում՝ մեկը կենդանի է, մյուսը՝ մեռած, ապա կոնտեյները դեռ կշարունակի ապրել: Բայց սա Լավագույն փորձի հարց է, դրանց մասին կխոսենք այլ նյութերում։

Դասընթացի առանձնահատկությունները և ամբողջական ծրագիրը ավելի մանրամասն ուսումնասիրելու համար խնդրում ենք հետևել հղմանը.Docker վիդեո դասընթաց.

Հեղինակ՝ Մարսել Իբրաև, Kubernetes-ի հավաստագրված ադմինիստրատոր, Southbridge-ի պրակտիկ ինժեներ, Slurm դասընթացների խոսնակ և մշակող:

Source: www.habr.com