Та одоо ердийн Dockerfile ашиглан werf дээр Docker зургийг бүтээх боломжтой

Хэзээ ч үгүй ​​байснаас оройтсон нь дээр. Эсвэл бид програмын дүрсийг бүтээх ердийн Dockerfiles-д дэмжлэг үзүүлээгүйгээс ноцтой алдаа гаргах шахсан.

Бид ярилцах болно верф — GitOps хэрэгсэл нь ямар ч CI/CD системтэй нэгдсэн бөгөөд хэрэглээний бүхэл бүтэн амьдралын мөчлөгийг удирдаж, дараах боломжийг олгоно.

• зураг цуглуулах, нийтлэх,
• Kubernetes дахь програмуудыг байрлуулах,
• тусгай бодлого ашиглан ашиглагдаагүй зургийг устгах.

Төслийн философи нь доод түвшний хэрэгслүүдийг нэг нэгдсэн системд цуглуулж, DevOps инженерүүдэд программуудыг хянах боломжийг олгодог. Боломжтой бол одоо байгаа хэрэгслүүдийг (Helm, Docker гэх мэт) ашиглах хэрэгтэй. Асуудлыг шийдэх арга байхгүй бол бид үүнд шаардлагатай бүх зүйлийг бий болгож, дэмжиж чадна.

Суурь: өөрийн зураг цуглуулагч

Werf дахь зураг цуглуулагчтай ийм зүйл тохиолдсон: ердийн Dockerfile бидэнд хангалтгүй байсан. Хэрэв та төслийн түүхийг хурдан харвал энэ асуудал werf-ийн эхний хувилбаруудад аль хэдийн гарч ирсэн (тэр үед одоо ч гэсэн. дапп гэгддэг).

Докерын дүрс дээр програм бүтээх хэрэгсэл бүтээх явцад бид Dockerfile нь зарим нэг тодорхой ажлуудад тохиромжгүй болохыг ойлгосон.

1. Дараахь стандарт схемийн дагуу ердийн жижиг вэб програмуудыг бүтээх хэрэгцээ:
   • системийн өргөн хэрэглээний хамаарлыг суулгах,
   • програмын хамаарлын сангуудын багцыг суулгах,
   • хөрөнгө цуглуулах,
   • Хамгийн гол нь зурган дээрх кодыг хурдан бөгөөд үр дүнтэй шинэчлээрэй.
2. Төслийн файлд өөрчлөлт оруулах үед бүтээгч нь өөрчилсөн файлд засвар хийж шинэ давхарга үүсгэх ёстой.
3. Хэрэв тодорхой файлууд өөрчлөгдсөн бол холбогдох хамааралтай үе шатыг дахин бүтээх шаардлагатай болно.

Өнөөдөр манай цуглуулагч өөр олон боломжуудтай боловч эдгээр нь анхны хүсэл, хүсэл эрмэлзэл байв.

Ерөнхийдөө бид хоёр ч удаа бодолгүйгээр өөрсдийн ашигладаг програмчлалын хэлээр зэвсэглэсэн (доороос үзнэ үү) мөн хэрэгжүүлэх замдаа орсон өөрийн DSL! Зорилгодоо нийцүүлэн угсрах үйл явцыг үе шаттайгаар тайлбарлаж, эдгээр үе шатуудын файлуудаас хамаарлыг тодорхойлохыг зорьсон. Тэгээд нөхөж өгсөн өөрийн цуглуулагч, энэ нь DSL-ийг эцсийн зорилго болгон хувиргасан - угсарсан зураг. Эхлээд DSL нь Ruby-д байсан, гэхдээ адил Голанг руу шилжих - манай цуглуулагчийн тохиргоог YAML файлд дүрсэлж эхэлсэн.

Ruby дахь dapp-д зориулсан хуучин тохиргоо

YAML дээрх werf-ийн одоогийн тохиргоо

Коллекторын механизм ч цаг хугацааны явцад өөрчлөгдсөн. Эхлээд бид тохиргооноосоо түр зуурын Dockerfile үүсгээд дараа нь түр зуурын саванд угсралтын зааварчилгааг ажиллуулж эхэлсэн.

NB: Одоогийн байдлаар өөрийн тохиргоотой (YAML-д) ажилладаг, Stapel коллектор гэж нэрлэгддэг коллектор маань нэлээд хүчирхэг хэрэгсэл болон хөгжсөн байна. Түүний нарийвчилсан тайлбар нь тусдаа нийтлэл байх ёстой бөгөөд үндсэн мэдээллийг эндээс олж болно баримт бичиг.

Асуудлын талаархи мэдлэг

Гэхдээ бид нэг алдаа хийснээ тэр даруй биш ухаарсан: бид чадвараа нэмээгүй стандарт Dockerfile ашиглан зураг бүтээх мөн тэдгээрийг ижил төгсгөлийн хэрэглээний удирдлагын дэд бүтцэд нэгтгэх (жишээ нь зураг цуглуулах, байрлуулах, цэвэрлэх). Kubernetes-д байршуулах хэрэгсэл хийж, Dockerfile-ийн дэмжлэгийг хэрэгжүүлэхгүй байж яаж болох вэ, i.e. Ихэнх төслийн зургийг дүрслэх стандарт арга уу?

Энэ асуултад хариулахын оронд бид шийдлийг санал болгож байна. Хэрэв танд Dockerfile (эсвэл Dockerfile-ийн багц) байгаа бөгөөд werf ашиглахыг хүсвэл яах вэ?

NB: Дашрамд хэлэхэд та яагаад werf ашиглахыг хүсэх болов? Үндсэн шинж чанарууд нь дараах байдалтай байна.

• зураг цэвэрлэх зэрэг програмын удирдлагын бүрэн мөчлөг;
• нэг тохиргооноос хэд хэдэн зургийг нэгэн зэрэг удирдах чадвар;
• Helm-тэй нийцтэй диаграмыг байршуулах процессыг сайжруулсан.

Тэдгээрийн бүрэн жагсаалтыг эндээс олж болно төслийн хуудас.

Тиймээс, хэрэв бид өмнө нь өөрийн тохиргоонд Dockerfile-ийг дахин бичихийг санал болгож байсан бол одоо бид баяртайгаар: "Werf-д Dockerfile-ээ бүтээхийг зөвшөөрнө үү!"

Хэрхэн ашиглах вэ?

Энэ функцийн бүрэн хэрэгжилт нь хувилбарт гарч ирэв 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 дахь локал давхаргын стандарт кэш ажилладаг. Гэсэн хэдий ч хамгийн чухал зүйл бол werf юм Dockerfile тохиргоог өөрийн дэд бүтцэд нэгтгэдэг. Энэ юу гэсэн үг вэ?

1. Dockerfile-ээс бүтээгдсэн зураг бүр нь нэг үе шатаас бүрдэнэ dockerfile (та werf-д ямар шат дамждаг талаар дэлгэрэнгүй уншиж болно энд).
2. Тайзны хувьд dockerfile werf нь Dockerfile тохиргооны агуулгаас хамаарах гарын үсгийг тооцоолдог. Dockerfile тохиргоо өөрчлөгдөхөд үе шатны гарын үсэг өөрчлөгдөнө dockerfile болон werf нь шинэ Dockerfile тохиргоогоор энэ үе шатыг дахин бүтээх ажлыг эхлүүлдэг. Хэрэв гарын үсэг өөрчлөгдөхгүй бол werf нь кэшээс зургийг авдаг (werf-д гарын үсгийг ашиглах талаар дэлгэрэнгүй мэдээллийг доор тайлбарласан болно энэ тайлан).
3. Дараа нь цуглуулсан зургуудыг тушаалаар нийтэлж болно werf publish (эсвэл werf build-and-publish) болон үүнийг Kubernetes-д байршуулахад ашиглаарай. Docker Registry-д нийтлэгдсэн зургуудыг стандарт 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. Докер нь ижил үүрэг гүйцэтгэж байгаа ч өөр өөр ажлын модноос шаардлагагүй дахин бүтээх ажлыг эхлүүлж болно. Жишээлбэл, 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-ийн дэмжлэгийг өөрийн хувийн Stapel бүтээгчтэй хамт түгээх болон Kubernetes-ийг ашиглан бүтээх (жишээ нь, kaniko-д хийдэг шиг Kubernetes доторх гүйгч дээр бүтээдэг) хийхээр төлөвлөж байна.

Тэгэхээр, хэрэв танд гэнэт хэд хэдэн Докер файлууд хэвтэж байвал ... оролдоод үз верф!

PS Сэдвийн талаархи баримт бичгийн жагсаалт

• Хурдан эхлүүлэх гарын авлага;
• dockerfile бүтээгчийн тохиргоо;
• Werf дахь шат төхөөрөмж;
• Зураг нийтлэх үйл явц;
• Kubernetes байршуулах үйл явцтай нэгтгэх;
• Цэвэрлэх үйл явц;
• Dockerfile-ийн өөр хувилбар болох Stapel бүтээгч.

Мөн манай блогоос уншина уу: "werf - Кубернетес дэх CI / CD-д зориулсан манай хэрэгсэл (тойм болон видео тайлан)".

Эх сурвалж: www.habr.com