Այժմ դուք կարող եք ստեղծել Docker պատկերներ werf-ում՝ օգտագործելով սովորական Dockerfile-ը

Լավ է ուշ քան երբեք. Կամ ինչպես մենք գրեթե լուրջ սխալ թույլ տվեցինք՝ չունենալով աջակցություն սովորական Dockerfiles-ին՝ հավելվածների պատկերներ ստեղծելու համար:

Մենք կխոսենք վերֆ — GitOps կոմունալ ծրագիր, որը ինտեգրվում է ցանկացած CI/CD համակարգի հետ և ապահովում է հավելվածի ողջ կյանքի ցիկլի կառավարումը՝ թույլ տալով.

• հավաքել և հրապարակել պատկերներ,
• հավելվածներ տեղակայել Kubernetes-ում,
• ջնջել չօգտագործված պատկերները՝ օգտագործելով հատուկ քաղաքականություն:

Նախագծի փիլիսոփայությունն է ցածր մակարդակի գործիքներ հավաքել մեկ միասնական համակարգում, որը DevOps-ի ինժեներներին հնարավորություն է տալիս վերահսկել հավելվածները: Հնարավորության դեպքում պետք է օգտագործվեն առկա կոմունալ ծառայությունները (ինչպես Helm-ը և Docker-ը): Եթե ​​որևէ խնդրի լուծում չկա, մենք կարող ենք ստեղծել և աջակցել դրա համար անհրաժեշտ ամեն ինչ։

Նախապատմություն՝ ձեր սեփական պատկերների կոլեկցիոներ

Ահա թե ինչ եղավ werf-ում պատկեր հավաքողի հետ. սովորական Dockerfile-ը մեզ չէր բավականացնում: Եթե ​​արագ նայեք նախագծի պատմությանը, ապա այս խնդիրն արդեն հայտնվել է werf-ի առաջին տարբերակներում (այնուհետև դեռ հայտնի է որպես dapp).

Docker պատկերների մեջ հավելվածներ ստեղծելու գործիք ստեղծելիս մենք արագ հասկացանք, որ Dockerfile-ը մեզ համար հարմար չէ որոշ շատ կոնկրետ առաջադրանքների համար.

1. Տիպիկ փոքր վեբ հավելվածներ կառուցելու անհրաժեշտությունը հետևյալ ստանդարտ սխեմայի համաձայն.
   • տեղադրել ամբողջ համակարգի հավելվածների կախվածությունները,
   • տեղադրել հավելվածների կախվածության գրադարանների փաթեթ,
   • հավաքել ակտիվներ,
   • և ամենակարևորը` արագ և արդյունավետ կերպով թարմացնել պատկերի կոդը:
2. Երբ փոփոխություններ են կատարվում նախագծի ֆայլերում, շինարարը պետք է արագ ստեղծի նոր շերտ՝ փոփոխված ֆայլերի վրա կարկատելով:
3. Եթե ​​որոշակի ֆայլեր փոխվել են, ապա անհրաժեշտ է վերակառուցել համապատասխան կախյալ փուլը։

Այսօր մեր կոլեկցիոները շատ այլ հնարավորություններ ունի, բայց դրանք սկզբնական ցանկություններն ու հորդորներն էին։

Ընդհանրապես, առանց երկու անգամ մտածելու, զինվեցինք մեր օգտագործած ծրագրավորման լեզվով (տես ներքեւում) և ճանապարհ ընկավ իրականացնելու համար սեփական DSL! Նպատակներին համապատասխան՝ նախատեսվում էր նկարագրել հավաքման գործընթացը փուլերով և որոշել այդ փուլերի կախվածությունը ֆայլերից: Եվ լրացրեց այն սեփական կոլեկցիոներ, որը DSL-ը վերածեց վերջնական նպատակի՝ հավաքված պատկերի։ Սկզբում DSL-ը Ruby-ում էր, բայց ինչպես անցում դեպի Գոլանգ — մեր կոլեկցիոների կազմաձևը սկսեց նկարագրվել YAML ֆայլում:

Հին կոնֆիգուրացիա dapp-ի համար Ruby-ում

Ընթացիկ կոնֆիգուրացիա werf-ի համար YAML-ում

Ժամանակի ընթացքում փոխվել է նաև կոլեկցիոների մեխանիզմը։ Սկզբում մենք պարզապես ստեղծեցինք ժամանակավոր Dockerfile on the fly մեր կոնֆիգուրացիայից, այնուհետև սկսեցինք գործարկել հավաքման հրահանգները ժամանակավոր բեռնարկղերում և կատարելագործել:

NBԱյս պահին մեր կոլեկցիոները, որն աշխատում է իր սեփական կոնֆիգուրով (YAML-ում) և կոչվում է Stapel collector, արդեն վերածվել է բավականին հզոր գործիքի: Դրա մանրամասն նկարագրությունը արժանի է առանձին հոդվածների, և հիմնական մանրամասները կարելի է գտնել այստեղ փաստաթղթավորում.

Խնդրի իրազեկում

Բայց մենք հասկացանք, և ոչ անմիջապես, որ թույլ տվեցինք մեկ սխալ՝ մենք չավելացրինք կարողությունը պատկերներ կառուցել ստանդարտ Dockerfile-ի միջոցով և ինտեգրել դրանք հավելվածների կառավարման նույն ենթակառուցվածքի մեջ (այսինքն՝ հավաքել պատկերներ, տեղակայել և մաքրել դրանք): Ինչպե՞ս կարող է հնարավոր լինել Kubernetes-ում տեղակայման գործիք ստեղծել և չներարկել Dockerfile-ի աջակցությունը, այսինքն. Նախագծերի մեծ մասի պատկերները նկարագրելու ստանդարտ միջոց:

Այս հարցին պատասխանելու փոխարեն առաջարկում ենք լուծում. Ի՞նչ անել, եթե դուք արդեն ունեք Dockerfile (կամ Dockerfiles-ի մի շարք) և ցանկանում եք օգտագործել werf-ը:

NBԻ դեպ, ինչու՞ կցանկանայիք օգտագործել werf-ը: Հիմնական հատկանիշները հանգում են հետևյալին.

• կիրառման կառավարման ամբողջական ցիկլը, ներառյալ պատկերի մաքրումը;
• մեկ կոնֆիգուրից միանգամից մի քանի պատկերների հավաքումը կառավարելու ունակություն.
• Բարելավված տեղակայման գործընթացը Helm-ի հետ համատեղելի գծապատկերների համար:

Նրանց ավելի ամբողջական ցանկը կարող եք գտնել այստեղ նախագծի էջ.

Այսպիսով, եթե ավելի վաղ մենք կառաջարկեինք վերաշարադրել Dockerfile-ը մեր կազմաձևում, այժմ մենք ուրախությամբ կասենք.

Ինչպես օգտվել

Այս հատկանիշի ամբողջական իրականացումը հայտնվեց թողարկումում werf v1.0.3-beta.1. Ընդհանուր սկզբունքը պարզ է. օգտվողը նշում է ուղին դեպի գոյություն ունեցող Dockerfile-ը werf կոնֆիգուրայում, այնուհետև գործարկում է հրամանը: werf build... և վերջ - werf-ը կհավաքի պատկերը: Դիտարկենք վերացական օրինակ.

Հայտարարենք հաջորդը Dockerfile նախագծի արմատում՝

FROM ubuntu:18.04
RUN echo Building ...

Եվ մենք կհայտարարենք werf.yamlորն օգտագործում է սա Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Բոլորը! Ձախ վազում werf build:

Բացի այդ, կարող եք հայտարարել հետևյալը werf.yaml տարբեր Dockerfiles-ից միանգամից մի քանի պատկեր ստեղծելու համար.

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Ի վերջո, այն նաև աջակցում է լրացուցիչ կառուցման պարամետրերի փոխանցում, ինչպիսիք են --build-arg и --add-host - werf config-ի միջոցով: Dockerfile պատկերի կազմաձևման ամբողջական նկարագրությունը հասանելի է այստեղ փաստաթղթերի էջ.

Ինչպես է դա աշխատում.

Կառուցման գործընթացում Docker-ի տեղական շերտերի ստանդարտ քեշը գործում է: Այնուամենայնիվ, կարևորն այն է, որ դա նույնպես է ինտեգրում է Dockerfile կոնֆիգուրացիան իր ենթակառուցվածքի մեջ. Ինչ է սա նշանակում?

1. Dockerfile-ից կառուցված յուրաքանչյուր պատկեր բաղկացած է մեկ փուլից, որը կոչվում է dockerfile (կարող եք ավելին կարդալ այն մասին, թե ինչ փուլեր են գտնվում werf-ում այստեղ).
2. Բեմի համար dockerfile werf-ը հաշվարկում է ստորագրությունը, որը կախված է Dockerfile կոնֆիգուրացիայի բովանդակությունից: Երբ Dockerfile կոնֆիգուրացիան փոխվում է, փուլի ստորագրությունը փոխվում է dockerfile և werf-ը նախաձեռնում է այս փուլի վերակառուցումը նոր Dockerfile կազմաձևով: Եթե ​​ստորագրությունը չի փոխվում, ապա werf-ը պատկերը վերցնում է քեշից (Վերֆում ստորագրությունների օգտագործման մասին ավելի շատ մանրամասներ նկարագրված են այս զեկույցը).
3. Հաջորդը, հավաքված պատկերները կարող են հրապարակվել հրամանով werf publish (Կամ werf build-and-publish) և օգտագործեք այն Kubernetes-ում տեղակայելու համար: Docker Registry-ում հրապարակված պատկերները կմաքրվեն՝ օգտագործելով ստանդարտ werf մաքրման գործիքներ, այսինքն. Հին պատկերները (ավելի քան N օր), պատկերները, որոնք կապված են գոյություն չունեցող Git մասնաճյուղերի և այլ կանոնների հետ, ինքնաբերաբար կմաքրվեն:

Այստեղ նկարագրված կետերի մասին լրացուցիչ մանրամասներ կարելի է գտնել փաստաթղթերում.

• Հրատարակման գործընթացը;
• Ինտեգրում Kubernetes-ի տեղակայման գործընթացին;
• Մաքրման գործընթաց.

Նշումներ և նախազգուշական միջոցներ

1. Արտաքին URL-ը չի աջակցվում ADD-ում

Ներկայումս հրահանգում արտաքին URL օգտագործելը չի ​​աջակցվում ADD. Werf-ը չի նախաձեռնի վերակառուցում, երբ նշված URL-ի ռեսուրսը փոխվի: Մենք նախատեսում ենք շուտով ավելացնել այս հնարավորությունը:

2. Դուք չեք կարող պատկերին ավելացնել .git

Ընդհանրապես, գրացուցակի ավելացում .git պատկերում` արատավոր վատ պրակտիկա և ահա թե ինչու.

1. Եթե .git մնում է վերջնական պատկերում, սա խախտում է սկզբունքները 12 գործոն հավելվածՔանի որ վերջնական պատկերը պետք է կապված լինի մեկ commit-ի հետ, դա չպետք է հնարավոր լինի անել git checkout կամայական կատարել.
2. .git մեծացնում է պատկերի չափը (պահեստը կարող է մեծ լինել այն պատճառով, որ մի անգամ մեծ ֆայլեր ավելացվել են դրան, իսկ հետո ջնջվել): Աշխատանքային ծառի չափը, որը կապված է միայն կոնկրետ commit-ի հետ, կախված չէ Git-ի գործողությունների պատմությունից: Այս դեպքում ավելացումը և հետագա հեռացումը .git վերջնական պատկերից չի աշխատի. պատկերը դեռ կստանա լրացուցիչ շերտ. այսպես է աշխատում Docker-ը:
3. Docker-ը կարող է նախաձեռնել անհարկի վերակառուցում, նույնիսկ եթե կառուցվում է նույն commit-ը, բայց տարբեր աշխատանքային ծառերից: Օրինակ, GitLab-ը ստեղծում է առանձին կլոնավորված դիրեկտորիաներ /home/gitlab-runner/builds/HASH/[0-N]/yourproject երբ զուգահեռ հավաքումը միացված է: Լրացուցիչ վերահավաքումը պայմանավորված կլինի նրանով, որ գրացուցակը .git տարբերվում է նույն պահեստի տարբեր կլոնավորված տարբերակներում, նույնիսկ եթե կառուցված է նույն commit-ը:

Վերջին կետը նաև հետևանքներ է ունենում werf-ի օգտագործման ժամանակ։ Werf-ը պահանջում է, որ կառուցված քեշը լինի որոշ հրամաններ գործարկելու ժամանակ (օրինակ. werf deploy) Երբ այս հրամանները գործարկվեն, werf-ը հաշվարկում է փուլային ստորագրությունները նշված պատկերների համար werf.yaml, և դրանք պետք է լինեն հավաքման քեշում, հակառակ դեպքում հրամանը չի կարողանա շարունակել աշխատանքը: Եթե ​​բեմական ստորագրությունը կախված է բովանդակությունից .git, այնուհետև մենք ստանում ենք քեշ, որն անկայուն է անհամապատասխան ֆայլերի փոփոխությունների նկատմամբ, և werf-ը չի կարողանա ներել այդպիսի անտեսումը (մանրամասների համար տե՛ս. փաստաթղթավորում).

Ընդհանուր առմամբ, ավելացնելով միայն որոշ անհրաժեշտ ֆայլեր հրահանգների միջոցով ADD ամեն դեպքում բարձրացնում է գրվածի արդյունավետությունն ու հուսալիությունը Dockerfile, և նաև բարելավում է դրա համար հավաքված քեշի կայունությունը Dockerfile, Git-ի անհամապատասխան փոփոխություններին:

Լրիվ

Հատուկ կարիքների համար մեր սեփական շինարարը գրելու մեր սկզբնական ուղին դժվար էր, ազնիվ և պարզ. ստանդարտ Dockerfile-ի վրա հենակներ օգտագործելու փոխարեն, մենք գրեցինք մեր լուծումը հատուկ շարահյուսությամբ: Եվ սա ուներ իր առավելությունները. Stapel կոլեկցիոները հիանալի է կատարում իր խնդիրը:

Այնուամենայնիվ, մեր սեփական շինարարը գրելու գործընթացում մենք մոռացանք գոյություն ունեցող Dockerfiles-ի աջակցության մասին: Այս թերությունն այժմ շտկվել է, և ապագայում մենք նախատեսում ենք զարգացնել Dockerfile-ի աջակցությունը մեր հատուկ Stapel-ի հետ մեկտեղ՝ բաշխված կառուցվածքների և Kubernetes-ի օգտագործմամբ կառուցումների համար (այսինքն՝ կառուցումներ Kubernetes-ի ներսում վազողների վրա, ինչպես արվում է kaniko-ում):

Այսպիսով, եթե հանկարծ ձեր շուրջը ընկած լինեն մի քանի Dockerfiles... փորձեք վերֆ!

PS Թեմայի վերաբերյալ փաստաթղթերի ցանկ

• Ուղեցույցներ արագ մեկնարկի համար;
• dockerfile Builder կոնֆիգուրացիաներ;
• Փուլերի սարքը werf-ում;
• Պատկերի հրապարակման գործընթացը;
• Ինտեգրում Kubernetes-ի տեղակայման գործընթացին;
• Մաքրման գործընթաց;
• Stapel շինարարը որպես Dockerfile-ի այլընտրանք.

Կարդացեք նաև մեր բլոգում.werf - մեր գործիքը CI / CD-ի համար Kubernetes-ում (ակնարկ և վիդեո զեկույց).

Source: www.habr.com