Hello everyone!
Ես իսկապես ուզում եմ անմիջապես թեմային անցնել, բայց ավելի ճիշտ կլինի մի փոքր պատմել իմ պատմության մասին.
Մուտք
Ես ծրագրավորող եմ, ով ունի սերվերի վրա մեկ էջի, scala/java և nodejs հավելվածների մշակման փորձ:
Բավականին երկար ժամանակ (միանշանակ մի երկու-երեք տարի) ես այն կարծիքին էի, որ Docker-ը երկնքից մանանա է և ընդհանրապես շատ թույն գործիք, և բացարձակապես յուրաքանչյուր ծրագրավորող պետք է կարողանա օգտագործել այն: Եվ սրանից հետևում է, որ յուրաքանչյուր ծրագրավորող պետք է ունենա Docker-ը տեղադրված իր տեղական մեքենայի վրա: Ինչ վերաբերում է իմ կարծիքին, նայեք թափուր աշխատատեղերը, որոնք տեղադրված են նույն հը. Յուրաքանչյուր երկրորդը պարունակում է docker-ի նշում, և եթե դուք ունեք այն, դա կլինի ձեր մրցակցային առավելությունը 😉
Իմ ճանապարհին ես հանդիպեցի շատ մարդկանց՝ Դոկերի և նրա էկոհամակարգի նկատմամբ իրենց տարբեր վերաբերմունքով: Ոմանք ասացին, որ սա հարմար բան է, որը երաշխավորում է միջպլատֆորմային ֆունկցիոնալությունը: Երկրորդները չհասկացան, թե ինչու պետք է վազեն կոնտեյներներով և ինչ շահույթ կունենա դրանից, երրորդները բոլորովին հոգ չէին տանում և չէին անհանգստանում (ուղղակի ծածկագիրը գրեցին և գնացին տուն, ես նրանց նախանձում եմ. ճանապարհ :)
Օգտագործման պատճառները
Ինչու՞ օգտագործեցի docker-ը: Հավանաբար հետևյալ պատճառներով.
- տվյալների բազայի գործարկում, հավելվածների 99%-ն օգտագործում է դրանք
- գործարկելով nginx-ը frontend-ի բաշխման և proxying-ի համար
- դուք կարող եք հավելվածը փաթեթավորել դոկերի պատկերով, այս կերպ իմ հավելվածը կաշխատի այնտեղ, որտեղ կա դոկեր, բաշխման խնդիրն անմիջապես լուծվում է
- ծառայության հայտնաբերում տուփից դուրս, դուք կարող եք ստեղծել միկրոսերվիսներ, յուրաքանչյուր կոնտեյներ (միացված ընդհանուր ցանցին) հեշտությամբ կարող է հասնել մյուսի միջոցով, շատ հարմար է
- Զվարճալի է ստեղծել կոնտեյներ և «խաղալ» դրա մեջ:
Այն, ինչ ինձ միշտ դուր չի գալիս docker-ում.
- Որպեսզի իմ հավելվածն աշխատի, ինձ պետք է հենց Docker-ը սերվերում: Ինչու՞ ինձ դա պետք է, եթե իմ հավելվածներն աշխատում են jre-ով կամ nodejs-ով, և նրանց համար նախատեսված միջավայրն արդեն սերվերում է:
- եթե ես ուզում եմ գործարկել իմ (մասնավոր) տեղական կառուցված պատկերը հեռավոր սերվերի վրա, ապա ինձ պետք է իմ սեփական դոկերի պահեստը, ինձ անհրաժեշտ է ռեեստրը, որպեսզի ինչ-որ տեղ աշխատի, և ես նույնպես պետք է կարգավորեմ https-ը, քանի որ docker cli-ն աշխատում է միայն https-ի վրա: Օ՜, անիծյալ... կան, իհարկե, պատկերը տեղական միջոցով պահպանելու տարբերակներ
docker saveև պարզապես ուղարկիր պատկերը scp-ի միջոցով... Բայց դա մարմնի շատ շարժումներ է: Եվ բացի այդ, այն կարծես «հենակների» լուծում լինի, քանի դեռ չի հայտնվել ձեր սեփական պահեստը docker-compose. Դա անհրաժեշտ է միայն բեռնարկղերի գործարկման համար: Այսքանը: Նա այլ բան չի կարող անել։Docker-composeունի իր ֆայլերի տարբերակների մի փունջ, իր շարահյուսությունը: Ինչքան էլ դա դեկլարատիվ լինի, ես չեմ ուզում կարդալ նրանց փաստաթղթերը։ Ինձ դա ուրիշ տեղ պետք չի լինի։- Երբ աշխատում են թիմում, մարդկանց մեծամասնությունը Dockerfile-ը գրում է շատ ծուռ, չի հասկանում, թե ինչպես է այն պահվում, ավելացնում են այն ամենը, ինչ իրենց պետք է և պետք չէ պատկերին, ժառանգում են պատկերներից, որոնք չկան Dockerhub-ում կամ մասնավոր պահոցում, ստեղծում են որոշ պատկերներ:
docker-composeֆայլեր տվյալների բազաներով, և ոչինչ չի պահպանվում: Միևնույն ժամանակ, ծրագրավորողները հպարտորեն հայտարարում են, որ Docker-ը հիանալի է, նրանց համար ամեն ինչ տեղական է, և HR-ը կարևոր է թափուր աշխատատեղում գրում. «Մենք օգտագործում ենք Docker-ը և մեզ անհրաժեշտ է նման աշխատանքային փորձ ունեցող թեկնածու»: - Ինձ անընդհատ հետապնդում են Docker-ում ամեն ինչ բարձրացնելու մասին մտքերը՝ postgresql, kafka, redis: Ափսոս, որ ամեն ինչ չէ, որ աշխատում է բեռնարկղերում, ամեն ինչ չէ, որ հեշտ է կարգավորել և գործարկել: Սա աջակցվում է երրորդ կողմի մշակողների կողմից, և ոչ թե իրենք վաճառողների կողմից: Եվ ի դեպ, անմիջապես հարց է ծագում. վաճառողները չեն անհանգստանում իրենց արտադրանքը Docker-ում պահպանելու մասին, ինչո՞ւ է սա, գուցե նրանք ինչ-որ բան գիտեն:
- Միշտ հարց է առաջանում կոնտեյներային տվյալների կայունության մասին։ և այնուհետև դուք մտածում եք, արդյոք ես պարզապես պետք է տեղադրեմ հյուրընկալող գրացուցակը կամ ստեղծեմ դոկերի ծավալ կամ պատրաստեմ տվյալների կոնտեյներ, որն այժմ կա
deprecated? Եթե ես տեղադրում եմ գրացուցակ, ապա ես պետք է համոզվեմ, որ կոնտեյների մեջ օգտագործողի uid-ը և gid-ը համընկնում են կոնտեյները գործարկող օգտագործողի id-ի հետ, հակառակ դեպքում կոնտեյների կողմից ստեղծված ֆայլերը կստեղծվեն արմատային իրավունքներով: Եթե ես օգտագործեմvolumeապա տվյալները պարզապես կստեղծվեն որոշներում/usr/*և նույն պատմությունը կլինի uid-ով և gid-ով, ինչպես առաջին դեպքում: Եթե դուք գործարկում եք երրորդ կողմի բաղադրիչ, դուք պետք է կարդաք փաստաթղթերը և փնտրեք հարցի պատասխանը. «Ո՞ր բեռնարկղերում է բաղադրիչը գրում ֆայլեր»:
Ինձ միշտ դուր չի եկել այն փաստը, որ ես ստիպված էի շատ երկար շփվել Docker-ի հետ սկզբնական փուլումԵս հասկացա, թե ինչպես գործարկել կոնտեյներները, ինչ պատկերներից գործարկել, պատրաստեցի Make-Ֆայլեր, որոնք պարունակում էին երկար Docker հրամանների կեղծանուններ: Ես ատում էի docker-compose-ը, քանի որ չէի ուզում սովորել այլ գործիք դոկերի էկոհամակարգում: ԵՎ docker-compose up Դա ինձ անհանգստացնում էր, հատկապես, եթե նրանք դեռ այնտեղ էին հանդիպում build կոնստրուկցիաներ, այլ ոչ թե արդեն հավաքված պատկերներ: Այն ամենը, ինչ ես իսկապես ուզում էի, պարզապես արտադրանք պատրաստելն էր արդյունավետ և արագ: Բայց ես չկարողացա հասկանալ, թե ինչպես օգտագործել docker-ը:
Ներկայացնում ենք Ansible-ը
Վերջերս (երեք ամիս առաջ) ես աշխատեցի DevOps թիմի հետ, որի գրեթե յուրաքանչյուր անդամ բացասական վերաբերմունք ուներ Docker-ի նկատմամբ։ Պատճառներով.
- docker կանոնները iptables (չնայած դուք կարող եք անջատել այն daemon.json-ում)
- docker-ը խելագարված է, և մենք այն չենք գործարկի արտադրության մեջ
- եթե docker daemon-ը վթարի է ենթարկվում, ապա ենթակառուցվածքով բոլոր կոնտեյներները համապատասխանաբար վթարի են ենթարկվում
- դոկերի կարիք չկա
- ինչու դոկեր, եթե կան Ansible և վիրտուալ մեքենաներ
Նույն աշխատանքում ես ծանոթացա մեկ այլ գործիքի՝ Ansible-ի հետ։ Ես մեկ անգամ լսել եմ դրա մասին, բայց ես չեմ փորձել գրել իմ սեփական գրքույկները: Եվ հիմա ես սկսեցի գրել իմ առաջադրանքները, և հետո իմ տեսլականը ամբողջովին փոխվեց: Որովհետև ես հասկացա. Ansible-ն ունի նույն դոկեր կոնտեյներներ գործարկելու մոդուլներ, պատկերների կառուցումներ, ցանցեր և այլն, և կոնտեյներները կարող են գործարկվել ոչ միայն տեղական, այլև հեռավոր սերվերների վրա: Իմ ուրախությունը սահմաններ չուներ. ես գտա ՆՈՐՄԱԼ գործիք և դեն նետեցի իմ Makefile և docker-compose ֆայլերը, դրանք փոխարինվեցին yaml առաջադրանքներով: Կոդը կրճատվել է՝ օգտագործելով այնպիսի կառուցվածքներ, ինչպիսիք են loop, whenԵւ այլն:
Docker երրորդ կողմի բաղադրիչները գործարկելու համար, ինչպիսիք են տվյալների բազաները
Վերջերս ծանոթացա ssh թունելների հետ։ Պարզվեց, որ շատ հեշտ է հեռավոր սերվերի պորտը «փոխանցել» տեղական նավահանգիստ։ Հեռավոր սերվերը կարող է լինել կամ ամպի մեջ գտնվող մեքենա կամ VirtualBox-ում աշխատող վիրտուալ մեքենա: Եթե իմ գործընկերոջը կամ ինձ անհրաժեշտ է տվյալների շտեմարան (կամ որևէ այլ երրորդ կողմի բաղադրիչ), մենք կարող ենք պարզապես սերվերը գործարկել այս բաղադրիչով և անջատել այն, երբ սերվերի կարիք չկա: Նավահանգիստների վերահասցեավորումը տալիս է նույն ազդեցությունը, ինչ տվյալների բազան, որն աշխատում է դոկեր կոնտեյներով:
Այս հրամանը փոխանցում է իմ տեղական նավահանգիստը postgresql աշխատող հեռավոր սերվերին.
ssh -L 9000:localhost:5432 [էլեկտրոնային փոստով պաշտպանված]
Հեռավոր սերվերի օգտագործումը լուծում է թիմի զարգացման խնդիրը: Նման սերվերը կարող է օգտագործվել միանգամից մի քանի ծրագրավորողների կողմից, նրանք կարիք չունեն, որ կարողանան կարգավորել postgresql-ը, հասկանալ Docker-ը և այլ բարդությունները: Հեռավոր սերվերի վրա դուք կարող եք տեղադրել նույն տվյալների բազան հենց Docker-ում, եթե դժվար է տեղադրել որոշակի տարբերակ: Մշակողներին անհրաժեշտ է միայն ապահովել ssh մուտք:
Վերջերս կարդացի, որ SSH թունելները սովորական VPN-ի սահմանափակ գործառույթ են: Դուք կարող եք պարզապես տեղադրել OpenVPN կամ այլ VPN իրականացումներ, կարգավորել ենթակառուցվածքը և տրամադրել այն ծրագրավորողներին օգտագործման համար: Սա այնքան թույն է:
Բարեբախտաբար, AWS-ը, GoogleCloud-ը և մյուսները ձեզ տալիս են անվճար օգտագործման մեկ տարի, այնպես որ օգտագործեք դրանք: Նրանք էժան են, եթե դրանք անջատեք, երբ դրանք չեն օգտագործվում: Ես միշտ մտածում էի, թե ինչու ինձ պետք կգա gcloud-ի նման հեռակառավարվող սերվերը, թվում է, որ ես գտել եմ դրանք:
Որպես տեղական վիրտուալ մեքենա, դուք կարող եք օգտագործել նույն Alpine-ը, որն ակտիվորեն օգտագործվում է դոկեր կոնտեյներներում: Դե, կամ մի քանի այլ թեթև բաշխումներ՝ մեքենան ավելի արագ բեռնելու համար:
Ներքևի գիծ. դուք կարող եք և պետք է գործարկեք տվյալների բազաները և այլ ենթակառուցվածքային բարիքներ հեռավոր սերվերների վրա կամ վիրտուալ տուփում: Ինձ այս նպատակների համար դոկեր պետք չէ:
Մի փոքր դոկերի պատկերների և բաշխման մասին
Ես արդեն գրել եմ որում ես ուզում էի փոխանցել, որ docker պատկերների օգտագործումը որևէ երաշխիք չի տալիս: Դոկերի պատկերները անհրաժեշտ են միայն դոկեր կոնտեյներ ստեղծելու համար: Եթե դուք արդիականացնում եք դոկերի պատկերի, ապա դուք արդիականացնում եք՝ օգտագործելու դոկեր կոնտեյներներ և միայն դրանք կօգտագործեք:
Դուք տեսե՞լ եք որևէ տեղ, որտեղ ծրագրային ապահովման մշակողները տեղափոխում են իրենց արտադրանքը միայն դոկերի պատկերով:
Ապրանքների մեծ մասի արդյունքը երկուական ֆայլեր են կոնկրետ հարթակի համար, դրանք պարզապես ավելացվում են դոկերի պատկերին, որը ժառանգվում է ցանկալի հարթակից: Երբևէ մտածե՞լ եք, թե ինչու են այդքան շատ նմանատիպ պատկերներ dockerhub-ում: Մուտքագրեք nginx օրինակ, կտեսնեք 100500 պատկեր տարբեր մարդկանցից: Այս մարդիկ իրենք չեն մշակել nginx-ը, նրանք պարզապես ավելացրել են պաշտոնական nginx-ը իրենց դոկերի պատկերին և համեմել այն իրենց կոնֆիգուրացիաներով՝ կոնտեյներներ գործարկելու հարմարության համար:
Ընդհանրապես, դուք կարող եք պարզապես պահել այն tgz-ում, եթե ինչ-որ մեկին պետք է գործարկել այն docker-ում, ապա թույլ տվեք tgz ավելացնել Dockerfile-ին, ժառանգել ցանկալի միջավայրից և ստեղծել լրացուցիչ buns, որոնք չեն փոխում հավելվածն ինքնին tgz-ում: Յուրաքանչյուր ոք, ով կստեղծի դոկերի պատկեր, կիմանա, թե ինչ է tgz-ը և ինչ է իրեն անհրաժեշտ աշխատելու համար: Ահա թե ինչպես եմ ես օգտագործում docker-ը
Ներքևի գիծ. Ինձ դոկեր ռեեստրի կարիք չկա, ես կօգտագործեմ ինչ-որ S3 կամ պարզապես ֆայլերի պահեստավորում, ինչպիսին է google drive/dropbox-ը
Docker CI-ում
Բոլոր ընկերությունները, որտեղ ես աշխատել եմ, նման են: Նրանք սովորաբար մթերային են: Այսինքն՝ նրանք ունեն մեկ հավելված, մեկ տեխնոլոգիական ստեկ (լավ, գուցե մի քանի կամ երեք ծրագրավորման լեզու)։
Այս ընկերությունները օգտագործում են դոկեր իրենց սերվերների վրա, որտեղ աշխատում է CI գործընթացը: Հարց. Ինչու՞ պետք է ձեր սերվերների վրա նախագծեր կառուցեք դոկեր կոնտեյներով: Ինչու՞ պարզապես չպատրաստել միջավայր build-ի համար, օրինակ՝ գրել Ansible գրքույկ, որը կտեղադրի nodejs, php, jdk, պատճենել ssh ստեղները և այլն, սերվերի վրա, որտեղ կառուցումը տեղի կունենա:
Հիմա ես հասկանում եմ, որ սա իմ ոտքին կրակում է, քանի որ դոկերն իր մեկուսացմամբ ոչ մի օգուտ չի բերում։ Խնդիրներ, որոնք ես հանդիպեցի CI-ի հետ docker-ում.
- կրկին ձեզ հարկավոր է դոկերի պատկեր ստեղծելու համար: դուք պետք է փնտրեք պատկեր կամ գրեք ձեր սեփական dockerfile-ը:
- 90% -ը, որ դուք պետք է փոխանցեք որոշ ssh բանալիներ, գաղտնի տվյալներ, որոնք դուք չեք ցանկանում գրել դոկերի պատկերին:
- կոնտեյները ստեղծվում է և մեռնում, դրա հետ միասին կորչում են բոլոր քեշերը: Հաջորդ կառուցումը նորից կներբեռնի նախագծի բոլոր կախվածությունները, ինչը ժամանակատար և անարդյունավետ է, իսկ ժամանակը փող է:
Մշակողները նախագծեր չեն կառուցում դոկեր կոնտեյներներում (մի ժամանակ ես այդպիսի երկրպագու էի, իսկապես, անցյալում խղճում եմ ինձ համար xD): Java-ում հնարավոր է ունենալ մի քանի տարբերակ և մեկ հրամանով փոխել այն, ինչ հիմա ձեզ անհրաժեշտ է։ Nodejs-ում էլ է այդպես, nvm կա։
Արտադրողականություն
Կարծում եմ, որ docker-ը շատ հզոր և ճկուն գործիք է, սա նրա թերությունն է (տարօրինակ է հնչում, այո): Դրա օգնությամբ ընկերությունները հեշտությամբ կարող են կառչել դրա վրա և օգտագործել այն, որտեղ անհրաժեշտ է և ոչ անհրաժեշտ: Մշակողները գործարկում են իրենց բեռնարկղերը, որոշ միջավայրեր, այնուհետև այդ ամենը սահուն կերպով հոսում է CI և արտադրություն: DevOps-ի թիմը գրում է ինչ-որ կոդ՝ այս բեռնարկղերը գործարկելու համար:
Օգտագործեք միայն միացված դոկերը ամենաթարմը փուլ ձեր աշխատանքային հոսքի մեջ, սկզբից մի քաշեք այն նախագծի մեջ: Դա չի լուծի ձեր բիզնեսի խնդիրները: Նա միայն ԱՅԼ հարթություն կտեղափոխի խնդիրները և կառաջարկի իր լուծումները, դուք կրկնակի աշխատանք կկատարեք։
Երբ դոկեր է անհրաժեշտԵս եկել եմ այն եզրակացության, որ docker-ը շատ լավ է օպտիմիզացնում տվյալ գործընթացը, բայց ոչ հիմնական ֆունկցիոնալությունը կառուցելու գործում
Եթե դեռ որոշել եք օգտագործել docker, ապա.
- չափազանց զգույշ եղեք
- մի ստիպեք մշակողներին օգտագործել docker-ը
- տեղայնացրեք դրա օգտագործումը մեկ տեղում, մի տարածեք այն Dockfile-ի և docker-compose-ի բոլոր պահեստներում
PS:
- Վերջերս հանդիպեցի և նրանք ասում են, որ դա շատ լավ է աշխատում Ansible-ի հետ և թույլ է տալիս միավորել պատկերների կառուցման գործընթացը (ներառյալ դոկերի պատկերը)
Շնորհակալություն ընթերցման համար, մաղթում եմ թափանցիկ որոշումներ ձեր գործերում և արդյունավետ աշխատանքային օրեր։
Source: www.habr.com