Енді сіз әдеттегі Docker файлын пайдаланып werf ішінде Docker кескіндерін құра аласыз

Ештен кеш жақсы. Немесе қолданбалы кескіндерді құру үшін әдеттегі Dockerfiles-ге қолдау көрсетпеу арқылы біз үлкен қателік жібердік.

туралы сөйлесеміз верф — Кез келген CI/CD жүйесімен біріктірілген және қолданбаның бүкіл өмірлік циклін басқаруды қамтамасыз ететін GitOps утилитасы:

• суреттерді жинау және жариялау,
• Kubernetes қолданбаларын орналастыру,
• арнайы саясаттарды пайдаланып пайдаланылмаған кескіндерді жою.

Жобаның философиясы DevOps инженерлеріне қолданбаларды басқаруға мүмкіндік беретін біртұтас жүйеге төмен деңгейлі құралдарды жинау болып табылады. Мүмкін болса, бар утилиталарды (мысалы, Helm және Docker) пайдалану керек. Егер мәселенің шешімі болмаса, біз бұл үшін қажеттінің бәрін жасай аламыз және қолдай аламыз.

Фон: өзіңіздің сурет жинағышыңыз

Werf ішіндегі кескін жинаушымен осылай болды: әдеттегі Dockerfile бізге жеткіліксіз болды. Егер сіз жобаның тарихына жылдам көз жүгіртсеңіз, бұл мәселе werf-тің алғашқы нұсқаларында пайда болды (содан кейін әлі де дап ретінде белгілі).

Docker кескіндерінде қолданбаларды құру құралын жасау кезінде біз Dockerfile кейбір нақты тапсырмалар үшін бізге жарамсыз екенін тез түсіндік:

1. Келесі стандартты схемаға сәйкес типтік шағын веб-қосымшаларды құру қажеттілігі:
   • жүйелік қолданбалы тәуелділіктерді орнату,
   • қолданбаға тәуелділік кітапханаларының бумасын орнату,
   • активтерді жинау,
   • және ең бастысы, суреттегі кодты тез және тиімді жаңартыңыз.
2. Жоба файлдарына өзгертулер енгізілгенде, құрастырушы өзгертілген файлдарға патч қолдану арқылы жаңа қабатты жылдам жасауы керек.
3. Егер белгілі бір файлдар өзгерсе, сәйкес тәуелді кезеңді қайта құру қажет.

Бүгінгі күні біздің коллекционерде көптеген басқа мүмкіндіктер бар, бірақ бұл бастапқы тілектер мен ұмтылыстар болды.

Жалпы, екі рет ойланбастан, біз қолданылған бағдарламалау тілімен қаруландық (төменде қараңыз) және іске асыру жолына түсті меншікті DSL! Қойылған мақсаттарға сәйкес құрастыру процесін кезең-кезеңмен сипаттау және осы кезеңдердің файлдарға тәуелділігін анықтау көзделді. Және оны толықтырды жеке коллекционер, ол DSL соңғы мақсатқа айналдырды - жиналған кескін. Алдымен DSL Ruby тілінде болды, бірақ солай Голангқа көшу — біздің коллектордың конфигурациясы YAML файлында сипаттала бастады.

Ruby ішіндегі dapp үшін ескі конфигурация

YAML жүйесіндегі werf үшін ағымдағы конфигурация

Коллектордың механизмі де уақыт өте өзгерді. Алдымен біз конфигурациямыздан жылдам уақытша Dockerfile жасадық, содан кейін уақытша контейнерлерде құрастыру нұсқауларын іске қосып, міндеттемені орындай бастадық.

NB: Қазіргі уақытта өз конфигурациясымен (YAML-де) жұмыс істейтін және Stapel коллекторы деп аталатын коллекторымыз жеткілікті қуатты құралға айналды. Оның егжей-тегжейлі сипаттамасы бөлек мақалаларға лайық және негізгі мәліметтерді мына жерден табуға болады құжаттама.

Мәселе туралы хабардар болу

Бірақ біз бірден емес, бір қателік жібергенімізді түсіндік: біз қабілет қоспадық стандартты Dockerfile арқылы кескіндерді құру және оларды бірдей түпкілікті қолданбаларды басқару инфрақұрылымына біріктіру (яғни, кескіндерді жинау, орналастыру және тазалау). Kubernetes-те орналастыру құралын қалай жасауға болады және Dockerfile қолдауын жүзеге асырмауға болады, яғни. Көптеген жобалар үшін кескіндерді сипаттаудың стандартты тәсілі?

Бұл сұраққа жауап берудің орнына біз шешімді ұсынамыз. Егер сізде Dockerfile (немесе Dockerfiles жиынтығы) бар болса және werf пайдаланғыңыз келсе ше?

NB: Айтпақшы, сіз неге werf қолданбасын қолданғыңыз келеді? Негізгі ерекшеліктер мыналарға байланысты:

• қолданбаны басқарудың толық циклі, соның ішінде кескінді тазалау;
• бір конфигурациядан бірден бірнеше кескінді құрастыруды басқару мүмкіндігі;
• Helm-үйлесімді диаграммалар үшін жақсартылған орналастыру процесі.

Олардың толық тізімін мына жерден табуға болады жоба беті.

Сонымен, егер бұрын біз конфигурацияда Dockerfile-ді қайта жазуды ұсынатын болсақ, енді біз қуана айтамыз: «Werf сіздің Docker-файлдарыңызды құруға рұқсат етіңіз!»

Қалай пайдалануға болады?

Бұл мүмкіндіктің толық орындалуы шығарылымда пайда болды werf v1.0.3-бета.1. Жалпы принцип қарапайым: пайдаланушы werf конфигурациясында бар Dockerfile жолын анықтайды, содан кейін пәрменді іске қосады. 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 әртүрлі Docker-файлдардан бірден бірнеше кескінді құру үшін:

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

Соңында, ол сондай-ақ қосымша құрастыру параметрлерін беруді қолдайды, мысалы --build-arg и --add-host - werf конфигурациясы арқылы. Dockerfile кескін конфигурациясының толық сипаттамасы мына жерден қол жетімді құжаттама беті.

Бұл қалай жұмыс істейді?

Құрастыру процесі кезінде Docker жүйесіндегі жергілікті қабаттардың стандартты кэші жұмыс істейді. Дегенмен, маңыздысы - бұл верф Dockerfile конфигурациясын оның инфрақұрылымына біріктіреді. Бұл нені білдіреді?

1. Dockerfile файлынан құрастырылған әрбір кескін деп аталатын бір кезеңнен тұрады dockerfile (верфте қандай кезеңдер бар екендігі туралы толығырақ оқуға болады осында).
2. Сахна үшін dockerfile werf Dockerfile конфигурациясының мазмұнына тәуелді қолтаңбаны есептейді. Dockerfile конфигурациясы өзгерген кезде, кезең қолтаңбасы өзгереді dockerfile және werf жаңа Dockerfile конфигурациясымен осы кезеңді қайта құруды бастайды. Егер қолтаңба өзгермесе, онда werf кескінді кэштен алады (werf-те қолтаңбаларды пайдалану туралы толығырақ сипатталған бұл есеп).
3. Содан кейін жиналған суреттерді пәрменмен жариялауға болады werf publish (немесе werf build-and-publish) және оны Kubernetes жүйесіне орналастыру үшін пайдаланыңыз. Docker тізілімінде жарияланған кескіндер стандартты werf тазалау құралдарының көмегімен тазаланады, яғни. Ескі кескіндер (N күннен асқан), жоқ Git тармақтарымен байланысты кескіндер және басқа саясаттар автоматты түрде тазаланады.

Мұнда сипатталған нүктелер туралы қосымша мәліметтерді құжаттамадан табуға болады:

• Жариялау процесі;
• Kubernetes орналастыру процесімен интеграция;
• Тазалау процесі.

Ескертулер мен сақтық шаралары

1. ADD ішінде сыртқы URL мекенжайына қолдау көрсетілмейді

Қазіргі уақытта директивада сыртқы URL мекенжайын пайдалануға қолдау көрсетілмейді ADD. Көрсетілген URL мекенжайындағы ресурс өзгерген кезде Werf қайта құруды бастамайды. Жақында бұл мүмкіндікті қосуды жоспарлап отырмыз.

2. Кескінге .git қосу мүмкін емес

Жалпы айтқанда, каталогты қосу .git суретте - зұлым жаман тәжірибе және міне, неге:

1. егер .git соңғы бейнеде қалады, бұл принциптерді бұзады 12 фактор қолданбасы: Соңғы кескін бір міндеттемеге байланысты болуы керек болғандықтан, оны орындау мүмкін болмауы керек git checkout ерікті міндеттеме.
2. .git кескіннің өлшемін арттырады (репозиторий үлкен болуы мүмкін, себебі оған үлкен файлдар бір рет қосылып, содан кейін жойылған). Арнайы міндеттемемен ғана байланыстырылған жұмыс ағашының өлшемі Git ішіндегі әрекеттер тарихына байланысты болмайды. Бұл жағдайда қосу және кейіннен алып тастау .git соңғы кескіннен жұмыс істемейді: кескін әлі де қосымша қабат алады - Docker осылай жұмыс істейді.
3. Docker қажетсіз қайта құруды бастай алады, тіпті бірдей міндеттеме салынып жатқан болса да, бірақ әртүрлі жұмыс ағаштарынан. Мысалы, GitLab жеке клондалған каталогтарды жасайды /home/gitlab-runner/builds/HASH/[0-N]/yourproject параллель құрастыру қосылғанда. Қосымша қайта құрастыру каталогтың болуына байланысты болады .git бір репозиторийдің әртүрлі клондалған нұсқаларында, тіпті бірдей міндеттеме жасалған болса да, әртүрлі болады.

Соңғы нүкте werf пайдалану кезінде де салдары бар. Werf кейбір пәрмендерді іске қосқан кезде орнатылған кэштің болуын талап етеді (мысалы werf deploy). Бұл пәрмендер іске қосылғанда, werf ішінде көрсетілген кескіндер үшін кезеңдік қолтаңбаларды есептейді werf.yaml, және олар жинақ кэшінде болуы керек - әйтпесе пәрмен жұмысын жалғастыра алмайды. Сахналық қолтаңба мазмұнға байланысты болса .git, содан кейін біз маңызды емес файлдардағы өзгерістерге тұрақсыз кэш аламыз және werf мұндай қадағалауды кешіре алмайды (толығырақ ақпаратты қараңыз. құжаттама).

Жалпы белгілі бір қажетті файлдарды ғана қосу нұсқаулар арқылы ADD кез келген жағдайда жазбаның тиімділігі мен сенімділігін арттырады Dockerfile, сонымен қатар бұл үшін жиналған кэштің тұрақтылығын жақсартады Dockerfile, Git-тегі маңызды емес өзгерістерге.

Нәтиже

Арнайы қажеттіліктер үшін өз құрылысшымызды жазудың бастапқы жолымыз қиын, адал және қарапайым болды: стандартты Dockerfile үстіне балдақтарды пайдаланудың орнына, біз шешімімізді реттелетін синтаксиспен жаздық. Оның артықшылығы да болды: Stapel коллекторы өз міндетін тамаша орындайды.

Дегенмен, өз құрылысшымызды жазу барысында біз бар Dockerfiles қолдауын жоғалттық. Бұл олқылық енді түзетілді және болашақта біз Dockerfile қолдауын және Kubernetes көмегімен таратылған құрылымдарға және құрастыруға арналған арнайы Stapel құрастырушысын әзірлеуді жоспарлап отырмыз (яғни, каникодағыдай Kubernetes ішіндегі жүгірушілерге құрастырылады).

Сонымен, егер сізде кенеттен бірнеше Dockerfiles болса... сынап көріңіз верф!

PS Тақырып бойынша құжаттар тізімі

• Жылдам бастауға арналған нұсқаулықтар;
• докер файлын құрастырушы конфигурациялары;
• Верфтегі кезеңдік құрылғы;
• Суретті жариялау процесі;
• Kubernetes орналастыру процесімен интеграция;
• Тазалау процесі;
• Dockerfile балама ретінде Stapel құрастырушы.

Сондай-ақ біздің блогта оқыңыз: «werf - біздің Kubernetes-тегі CI/CD құралы (шолу және бейне есеп)«.

Ақпарат көзі: www.habr.com