Сиз азыр кадимки Dockerfile аркылуу werf ичинде Docker сүрөттөрүн кура аласыз

Эч качан караганда кеч жакшы. Же колдонмонун сүрөттөрүн түзүү үчүн кадимки Dockerfiles колдоого алынбай, кандайча олуттуу ката кетирдик.

Биз сүйлөшөбүз werf — GitOps утилитасы ар кандай CI/CD системасы менен интеграцияланган жана колдонмонун бүткүл жашоо циклин башкарууну камсыздайт, бул:

• сүрөттөрдү чогултуу жана жарыялоо,
• Kubernetesте тиркемелерди жайгаштыруу,
• атайын саясаттарды колдонуу менен колдонулбаган сүрөттөрдү жок кылуу.

Долбоордун философиясы DevOps инженерлерине тиркемелерди башкарууга мүмкүнчүлүк берген бирдиктүү бирдиктүү системага төмөнкү деңгээлдеги куралдарды чогултуу болуп саналат. Мүмкүн болсо, учурдагы утилиталар (Helm жана Docker сыяктуу) колдонулушу керек. Эгерде кандайдыр бир маселе чечилбесе, биз бул үчүн зарыл болгон нерселердин баарын түзүп, колдой алабыз.

Фон: өзүңүздүн сүрөт коллекционериңиз

Бул werfтеги сүрөт жыйноочу менен болгон окуя: кадимки Dockerfile биз үчүн жетишсиз болчу. Эгерде сиз долбоордун тарыхына тез көз чаптырсаңыз, бул көйгөй werfтин биринчи версияларында пайда болгон (анда дагы dapp катары белгилүү).

Докер сүрөттөрүнө тиркемелерди куруу куралын түзүп жатып, биз 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 сиздин Dockerfile файлдарыңызды түзсүн!"

пайдалануу кандай?

Бул функциянын толук ишке ашырылышы релизде пайда болду werf v1.0.3-beta.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 бир эле учурда ар кандай Dockerfiles бир нече сүрөттөрдү куруу үчүн:

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 (верфте кандай этаптар бар экендиги жөнүндө көбүрөөк окуй аласыз бул жерде).
2. Сахна үчүн dockerfile werf Dockerfile конфигурациясынын мазмунуна көз каранды кол тамганы эсептейт. Dockerfile конфигурациясы өзгөргөндө, баскычтын кол тамгасы өзгөрөт dockerfile жана werf жаңы Dockerfile конфигурациясы менен бул этапты кайра курууну демилгелейт. Эгерде кол тамга өзгөрбөсө, анда werf сүрөттү кэштен алат (werf кол тамгасын колдонуу жөнүндө көбүрөөк маалымат сүрөттөлгөн бул отчет).
3. Андан кийин, чогултулган сүрөттөр буйрук менен жарыяланышы мүмкүн werf publish (же werf build-and-publish) жана аны Kubernetesке жайылтуу үчүн колдонуңуз. Докер реестрине жарыяланган сүрөттөр стандарттуу werf тазалоо куралдарын колдонуу менен тазаланат, б.а. Эски сүрөттөр (N күндөн эски), жок Git бутактары менен байланышкан сүрөттөр жана башка саясаттар автоматтык түрдө тазаланат.

Бул жерде сүрөттөлгөн пункттар жөнүндө көбүрөөк маалымат документациядан тапса болот:

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

Эскертүүлөр жана сактык чаралары

1. Тышкы URL ADDде колдоого алынбайт

Учурда директивада тышкы URL колдонуу колдоого алынбайт ADD. Көрсөтүлгөн URL дарегиндеги ресурс өзгөргөндө Werf кайра курууну баштабайт. Бул функцияны жакында кошууну пландап жатабыз.

2. Сүрөткө .git кошо албайсыз

Жалпысынан алганда, каталогду кошуу .git сүрөттө - жаман жаман практика жана бул жерде эмне үчүн:

1. эгер .git акыркы сүрөттө кала берет, бул принциптерди бузат 12 фактордук колдонмо: Акыркы сүрөттөлүш бир милдеттенмеге байланыштуу болушу керек болгондуктан, аны жасоого болбойт git checkout өзүм билемдик кылуу.
2. .git сүрөттүн көлөмүн көбөйтөт (репозиторий чоң болушу мүмкүн, анткени ага бир жолу чоң файлдар кошулуп, андан кийин жок кылынган). Белгилүү бир милдеттенме менен гана байланышкан жумуш дарагынын өлчөмү Гиттеги операциялардын тарыхынан көз каранды болбойт. Бул учурда, кошуу жана андан кийинки алып салуу .git акыркы сүрөттөлүш иштебейт: сүрөт дагы эле кошумча катмарга ээ болот - Docker ушундай иштейт.
3. Докер керексиз реконструкцияны башташы мүмкүн, ал тургай, бир эле милдеттенме курулуп жатса да, бирок ар кандай жумушчу дарактардан. Мисалы, GitLab өзүнчө клондолгон каталогдорду түзөт /home/gitlab-runner/builds/HASH/[0-N]/yourproject параллелдүү чогултуу иштетилгенде. Кошумча кайра чогултуу каталогуна байланыштуу болот .git бир репозиторийдин ар кандай клондолгон версияларында, бир эле милдеттенме курулса да, ар кандай болот.

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

жалпы кээ бир керектүү файлдарды гана кошуу көрсөтмөлөр аркылуу ADD кандай болгон күндө да жазылгандын натыйжалуулугун жана ишенимдүүлүгүн жогорулатат Dockerfile, ошондой эле бул үчүн чогултулган кэштин туруктуулугун жакшыртат Dockerfile, Гиттеги тиешеси жок өзгөрүүлөргө.

жыйынтык

Белгилүү муктаждыктар үчүн өзүбүздүн куруучубузду жазуудагы алгачкы жолубуз кыйын, чынчыл жана түз болду: стандарттуу Dockerfile үстүнө балдактарды колдонуунун ордуна, биз чечимибизди ыңгайлаштырылган синтаксис менен жаздык. Жана мунун өзүнүн артыкчылыктары бар эле: Stapel жыйноочу өз милдетин эң сонун аткарат.

Бирок, өзүбүздүн куруучубузду жазуу процессинде биз учурдагы Dockerfiles колдоосун унутуп калдык. Бул кемчилик азыр оңдолду жана келечекте биз Dockerfile колдоосун иштеп чыгууну пландаштырып жатабыз, ошондой эле биздин жеке Stapel куруучубуз менен бөлүштүрүлгөн монтаждоо жана Кубернетес аркылуу чогултуу үчүн (б.а. Каникодо жасалгандай Кубернетестин ичиндеги жөө күлүктөргө чогултуу).

Ошентип, сизде күтүлбөгөн жерден бир нече Dockerfile бар болсо ... аракет кылуу werf!

PS Тема боюнча документтердин тизмеси

• Тез баштоо үчүн көрсөтмөлөр;
• докер файл куруучу конфигурациялары;
• Верфтеги этаптар аппараты;
• Сүрөттү жарыялоо процесси;
• Kubernetes жайылтуу процесси менен интеграция;
• Тазалоо процесси;
• Dockerfileге альтернатива катары Stapel куруучу.

Биздин блогдон дагы окуңуз: "werf - Kubernetesтеги CI / CD үчүн биздин курал (сереп жана видео отчет)«.

Source: www.habr.com