🥇 Контейнерийн дүрсийг "ухаалаг" цэвэрлэх асуудал, түүнийг werf

Уг нийтлэлд Кубернетес рүү хүргэсэн үүлэн программуудад зориулсан орчин үеийн CI/CD дамжуулах хоолойн бодит байдалд контейнерийн бүртгэлд (Docker Registry ба түүний аналогууд) хуримтлагдсан зургийг цэвэрлэхэд тулгарч буй асуудлуудыг авч үзэх болно. Зургийн хамаарлын гол шалгуурууд, цэвэрлэгээг автоматжуулах, орон зай хэмнэх, багуудын хэрэгцээг хангахад тулгарч буй бэрхшээлийг харуулав. Эцэст нь, тодорхой Нээлттэй эхийн төслийн жишээн дээр бид эдгээр бэрхшээлийг хэрхэн даван туулах талаар танд хэлэх болно.

Танилцуулга

Контейнерын бүртгэл дэх зургийн тоо хурдацтай өсч, илүү их зай эзэлдэг бөгөөд ингэснээр түүний өртөг мэдэгдэхүйц нэмэгдэх болно. Бүртгэлд байгаа зайны зөвшөөрөгдөх өсөлтийг хянах, хязгаарлах эсвэл хадгалахын тулд дараахь зүйлийг зөвшөөрнө.

зураг дээр тогтсон тооны шошго ашиглах;
зургуудыг ямар нэгэн байдлаар цэвэрлэ.

Эхний хязгаарлалтыг заримдаа жижиг багуудад хүлээн зөвшөөрдөг. Хэрэв хөгжүүлэгчид хангалттай байнгын шошготой бол (latest, main, test, boris гэх мэт), бүртгэл нь томрохгүй бөгөөд удаан хугацааны туршид та үүнийг цэвэрлэх талаар огт бодох шаардлагагүй болно. Эцсийн эцэст, бүх хамааралгүй зургуудыг устгаж, цэвэрлэх ажил үлдэхгүй (бүх зүйлийг ердийн хог цуглуулагч хийдэг).

Гэсэн хэдий ч энэ арга нь хөгжлийг ихээхэн хязгаарладаг бөгөөд орчин үеийн CI/CD төслүүдэд хэрэглэх нь ховор байдаг. Хөгжлийн салшгүй хэсэг байсан автоматжуулалт, энэ нь танд шинэ функцийг турших, ашиглах, хэрэглэгчдэд илүү хурдан хүргэх боломжийг олгодог. Жишээлбэл, манай бүх төслүүдэд CI дамжуулах хоолой нь амлалт бүрээр автоматаар үүсдэг. Үүн дээр зургийг угсарч, туршиж, дибаг хийх, үлдсэн шалгалтыг хийх зорилгоор Кубернетесийн янз бүрийн хэлхээнд шилжүүлж, хэрэв бүх зүйл хэвийн бол өөрчлөлтүүд эцсийн хэрэглэгчдэд хүрдэг. Энэ бол пуужингийн шинжлэх ухаан байхаа больсон, гэхдээ олон хүмүүсийн өдөр тутмын үзэгдэл - та энэ нийтлэлийг уншиж байгаа тул магадгүй танд зориулагдсан байх магадлалтай.

Алдаа засах, шинэ функцийг боловсруулах нь зэрэгцэн явагддаг бөгөөд хувилбаруудыг өдөрт хэд хэдэн удаа хийх боломжтой тул боловсруулах үйл явц нь нэлээд олон тооны үүрэг хариуцлага дагалддаг нь ойлгомжтой. бүртгэлд байгаа олон тооны зураг. Үүний үр дүнд бүртгэлийг үр дүнтэй цэвэрлэх ажлыг зохион байгуулах асуудал гарч ирдэг, i.e. хамааралгүй зургуудыг арилгах.

Гэхдээ зураг хамааралтай эсэхийг яаж тодорхойлох вэ?

Зургийн хамаарлын шалгуур

Ихэнх тохиолдолд гол шалгуур нь:

1. Эхнийх нь (хамгийн тод, хамгийн шүүмжлэлтэй) нь тэр зургууд юм одоогоор Kubernetes-д ашиглагдаж байна. Эдгээр зургийг арилгах нь үйлдвэрлэлийн сул зогсолтын зардалд хүргэж болзошгүй (жишээлбэл, зургийг хуулбарлахад шаардлагатай байж болно) эсвэл аль нэг гогцоонд дибаг хийх багийн хүчин чармайлтыг үгүйсгэж болно. (Энэ шалтгааны улмаас бид бүр тусгайлан хийсэн Прометей экспортлогч, ямар ч Kubernetes кластерт ийм зураг байхгүй байгааг хянадаг.)

2. Хоёрдугаарт (тодорхой бус, гэхдээ бас маш чухал бөгөөд дахин мөлжлөгтэй холбоотой) - зургууд ноцтой асуудал илэрсэн тохиолдолд буцаахад шаардлагатай одоогийн хувилбарт. Жишээлбэл, Helm-ийн хувьд эдгээр нь хувилбарын хадгалагдсан хувилбаруудад ашиглагддаг зургууд юм. (Дашрамд хэлэхэд, Helm-д өгөгдмөл байдлаар хязгаар нь 256 засвар байдаг, гэхдээ хэн ч үүнийг хадгалах шаардлагагүй юм. ийм олон тооны хувилбарууд уу?..) Эцсийн эцэст бид, ялангуяа, дараа нь ашиглахын тулд хувилбаруудыг хадгалдаг, өөрөөр хэлбэл. Шаардлагатай бол тэдэн рүү "буцааж".

3. Гуравдугаарт - хөгжүүлэгчийн хэрэгцээ: Тэдний одоогийн ажилтай холбоотой бүх зураг. Жишээлбэл, хэрэв бид PR-ийн талаар бодож байгаа бол хамгийн сүүлийн амлалт, тухайлбал өмнөх амлалтад тохирсон зургийг үлдээх нь утга учиртай: ингэснээр хөгжүүлэгч ямар ч ажилдаа хурдан буцаж, хамгийн сүүлийн үеийн өөрчлөлтүүдтэй ажиллах боломжтой болно.

4. Дөрөвдүгээрт - зургууд Манай програмын хувилбаруудтай тохирч байна, өөрөөр хэлбэл эцсийн бүтээгдэхүүн: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra гэх мэт.

Анхааруулга: Энд тодорхойлсон шалгууруудыг янз бүрийн компаниудын олон арван хөгжүүлэлтийн багуудтай харилцаж байсан туршлага дээр үндэслэн томъёолсон болно. Гэсэн хэдий ч, мэдээжийн хэрэг, хөгжлийн үйл явцын онцлог, ашигласан дэд бүтцээс хамааран (жишээлбэл, Kubernetes-ийг ашигладаггүй) эдгээр шалгуурууд өөр байж болно.

Сонголт ба одоо байгаа шийдлүүд

Контейнерын бүртгэлтэй алдартай үйлчилгээнүүд нь дүрмээр бол өөрийн зургийг цэвэрлэх бодлогыг санал болгодог: тэдгээрт та шошгыг бүртгэлээс устгах нөхцлийг тодорхойлж болно. Гэсэн хэдий ч эдгээр нөхцөл нь нэр, үүсгэх хугацаа, шошгоны тоо* гэх мэт параметрүүдээр хязгаарлагддаг.

* Контейнерын бүртгэлийн тусгай хэрэгжилтээс хамаарна. Бид дараах шийдлүүдийн боломжуудыг авч үзсэн: Azure CR, Docker Hub, ECR, GCR, GitHub багцууд, GitLab Контейнер Бүртгэл, Харбор Бүртгэл, JFrog Artifactory, Quay.io - 2020 оны XNUMX-р сарын байдлаар.

Энэ параметрийн багц нь дөрөв дэх шалгуурыг хангахад хангалттай, өөрөөр хэлбэл хувилбарт тохирох зургийг сонгоход хангалттай. Гэсэн хэдий ч бусад бүх шалгуурын хувьд хүлээлт, санхүүгийн боломжоос хамааран ямар нэгэн буулт хийх шийдлийг (илүү хатуу эсвэл эсрэгээр илүү зөөлөн бодлого) сонгох хэрэгтэй.

Жишээлбэл, хөгжүүлэгчдийн хэрэгцээтэй холбоотой гуравдахь шалгуурыг баг доторх үйл явцыг зохион байгуулах замаар шийдэж болно: зургийн тодорхой нэршил, тусгай зөвшөөрлийн жагсаалт, дотоод хэлэлцээрийг хөтлөх. Гэхдээ эцэст нь үүнийг автоматжуулах шаардлагатай хэвээр байна. Хэрэв бэлэн шийдлүүдийн чадвар хангалтгүй бол та өөрөө ямар нэгэн зүйл хийх хэрэгтэй.

Эхний хоёр шалгуурын нөхцөл байдал ижил байна: тэдгээрийг гадаад системээс өгөгдөл хүлээн авахгүйгээр хангах боломжгүй - програмуудыг байрлуулсан систем (манай тохиолдолд Кубернетес).

Git дэх ажлын урсгалын дүрслэл

Та Git дээр ийм зүйл ажиллаж байна гэж бодъё:

Диаграмм дээрх толгойтой дүрс нь Kubernetes-д одоогоор ямар ч хэрэглэгчдэд (эцсийн хэрэглэгчид, тестер, менежерүүд гэх мэт) байршуулсан эсвэл хөгжүүлэгчид дибаг хийх болон үүнтэй төстэй зорилгоор ашигладаг контейнерийн зургийг заана.

Цэвэрлэх бодлого нь зөвхөн зургийг хадгалахыг зөвшөөрвөл яах вэ (устгахгүй) өгөгдсөн шошгоны нэрээр?

Ийм дүр зураг хэнийг ч баярлуулахгүй нь ойлгомжтой.

Бодлого нь зургийг устгахгүй байхыг зөвшөөрвөл юу өөрчлөгдөх вэ? өгөгдсөн хугацааны интервалын дагуу / сүүлийн амлалтын тоо?

Үр дүн нь хамаагүй дээр болсон ч хамгийн тохиромжтой зүйлээс хол байна. Эцсийн эцэст бид алдааг засахын тулд бүртгэлд зураг оруулах шаардлагатай (эсвэл бүр K8-д байрлуулсан) хөгжүүлэгчидтэй хэвээр байна ...

Зах зээлийн өнөөгийн байдлыг нэгтгэн дүгнэхэд: чингэлэг бүртгэлд байдаг функцууд нь цэвэрлэхэд хангалттай уян хатан байдлыг санал болгодоггүй бөгөөд үүний гол шалтгаан нь гадаад ертөнцтэй харилцах ямар ч боломжгүй. Ийм уян хатан байдлыг шаарддаг багууд Docker Registry API (эсвэл холбогдох хэрэгжүүлэлтийн эх API) ашиглан зургийг "гаднаас" устгах ажлыг бие даан хэрэгжүүлэхээс өөр аргагүй болж байна.

Гэсэн хэдий ч бид янз бүрийн бүртгэлийг ашиглан янз бүрийн багуудад зураг цэвэрлэх ажлыг автоматжуулах бүх нийтийн шийдлийг хайж байсан ...

Бүх нийтийн дүр төрхийг цэвэрлэх бидний зам

Энэ хэрэгцээ хаанаас гардаг вэ? Үнэн хэрэгтээ бид хөгжүүлэгчдийн тусдаа бүлэг биш, харин CI/CD-ийн асуудлыг цогцоор нь шийдвэрлэхэд тусалж, олонд нь нэгэн зэрэг үйлчилдэг баг юм. Үүний гол техникийн хэрэгсэл бол Нээлттэй эхийн хэрэгсэл юм верф. Үүний онцлог нь нэг функцийг гүйцэтгэдэггүй боловч угсрахаас эхлээд байрлуулах хүртэлх бүх үе шатанд тасралтгүй хүргэх үйл явцыг дагалддаг.

Зургийг бүртгэлд нийтлэх* (барьсны дараа шууд) нь ийм хэрэгслийн тодорхой үүрэг юм. Зургийг тэнд хадгалахаар байрлуулсан тул хэрэв таны хадгалах хэмжээ хязгааргүй бол та дараагийн цэвэрлэгээг хариуцах хэрэгтэй. Бид заасан бүх шалгуурыг хангаж, үүнд хэрхэн амжилтанд хүрсэн талаар цаашид хэлэлцэх болно.

* Бүртгэлүүд нь өөр өөр байж болох ч (Docker Registry, GitLab Container Registry, Harbor гэх мэт) хэрэглэгчид ижил асуудалтай тулгардаг. Манай тохиолдолд бүх нийтийн шийдэл нь бүртгэлийн хэрэгжилтээс хамаардаггүй, учир нь нь бүртгэлээс гадуур ажилладаг бөгөөд хүн бүрт ижил зан үйлийг санал болгодог.

Хэдийгээр бид werf-ийг жишээ болгон ашиглаж байгаа ч ашигласан аргууд нь ижил төстэй бэрхшээлтэй тулгарсан бусад багуудад хэрэг болно гэж найдаж байна.

Тиймээс бид завгүй болсон гадна Контейнерын бүртгэлд аль хэдийн суулгасан боломжуудын оронд зургийг цэвэрлэх механизмыг хэрэгжүүлэх. Эхний алхам нь Docker Registry API-г ашиглан шошгоны тоо болон тэдгээрийг үүсгэсэн цаг (дээр дурдсан) ижил энгийн бодлогыг бий болгох явдал байв. Тэдэнд нэмсэн байршуулсан дэд бүтцэд ашигласан зураг дээр үндэслэн жагсаалтыг зөвшөөрөх, өөрөөр хэлбэл Кубернетес. Сүүлийнх нь бүх байршуулсан нөөцийг давтаж, утгуудын жагсаалтыг авахын тулд Kubernetes API ашиглахад хангалттай байсан. image.

Энэхүү өчүүхэн шийдэл нь хамгийн чухал асуудлыг (шалгуур №1) шийдсэн боловч цэвэрлэх механизмыг сайжруулах бидний аяллын зөвхөн эхлэл байсан юм. Дараагийн, илүү сонирхолтой алхам бол шийдвэр байв нийтлэгдсэн зургуудыг Git түүхтэй холбох.

Шошголох схемүүд

Эхлэхийн тулд бид эцсийн зураг нь цэвэрлэхэд шаардлагатай мэдээллийг хадгалах аргыг сонгож, шошгоны схем дээр үйл явцыг бий болгосон. Зургийг нийтлэхдээ хэрэглэгч тодорхой шошголох сонголтыг сонгосон (git-branch, git-commit буюу git-tag) болон харгалзах утгыг ашигласан. CI системд эдгээр утгыг орчны хувьсагчдад үндэслэн автоматаар тохируулсан. Үнэндээ эцсийн зураг нь тодорхой Git командтай холбоотой байв, шошгон дээр цэвэрлэхэд шаардлагатай өгөгдлийг хадгалах.

Энэ арга нь Git-ийг үнэний цорын ганц эх сурвалж болгон ашиглах боломжийг олгосон багц бодлогыг бий болгосон.

Git дэх салбар/тааг устгах үед бүртгэл дэх холбогдох зургууд автоматаар устгагдана.
Git хаягууд болон амлалтуудтай холбоотой зургийн тоог сонгосон схемд ашигласан шошгоны тоо болон холбогдох амлалт үүсгэсэн цаг хугацаагаар хянаж болно.

Ерөнхийдөө үр дүнд хүрсэн хэрэгжилт нь бидний хэрэгцээг хангасан боловч удалгүй шинэ сорилт биднийг хүлээж байв. Git команд дээр суурилсан шошголох схемийг ашиглах явцад бид хэд хэдэн дутагдалтай тулгарсан. (Тэдний тайлбар нь энэ нийтлэлийн хамрах хүрээнээс хэтэрсэн тул хүн бүр дэлгэрэнгүй мэдээлэлтэй танилцаж болно. энд.) Тиймээс шошголох (контент дээр суурилсан шошго) илүү үр дүнтэй арга руу шилжихээр шийдсэний дараа бид зураг цэвэрлэх хэрэгжилтийг дахин авч үзэх шаардлагатай болсон.

Шинэ алгоритм

Яагаад? Агуулгад суурилсан шошгололтын тусламжтайгаар шошго бүр нь Git дэх олон үүрэг хариуцлагыг хангаж чадна. Зургийг цэвэрлэхдээ та цаашид төсөөлж чадахгүй зөвхөн Бүртгэлд шинэ шошго нэмсэн амлалтаас.

Цэвэрлэх шинэ алгоритмын хувьд шошголох схемээс татгалзаж, бүтээхээр шийдсэн мета зургийн үйл явц, тус бүр нь дараах зүйлсийг хадгалдаг:

нийтлэлийг гүйцэтгэсэн үүрэг (зураг нь контейнерийн бүртгэлд нэмэгдсэн, өөрчлөгдсөн эсвэл хэвээр байгаа эсэх нь хамаагүй);
болон угсарсан зурагт тохирох бидний дотоод танигч.

Өөрөөр хэлбэл, хангасан гэсэн үг нийтлэгдсэн хаягуудыг Git-д үүрэг даалгавартай холбох.

Эцсийн тохиргоо ба ерөнхий алгоритм

Цэвэрлэгээг тохируулах үед хэрэглэгчид одоо байгаа зургийг сонгох бодлогод хандах боломжтой болсон. Ийм бодлого бүрийг дараахь байдлаар тодорхойлдог.

олон лавлагаа, жишээлбэл. Скан хийх явцад ашигладаг Git хаягууд эсвэл Git салбарууд;
мөн багцаас лавлагаа бүрийн хайсан зургийн хязгаар.

Дүрслэхийн тулд өгөгдмөл бодлогын тохиргоо иймэрхүү харагдаж эхэлсэн:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

Энэ тохиргоо нь дараах дүрэмд нийцсэн гурван бодлогыг агуулна.

Сүүлийн 10 Git шошгонд (шошго үүсгэсэн огноогоор) зургийг хадгал.
Сүүлийн долоо хоногт нийтлэгдсэн 2-оос илүүгүй зургийг сүүлийн долоо хоногт идэвхтэй байгаа 10-аас илүүгүй сэдвийн хүрээнд хадгал.
Салбаруудад зориулж 10 зураг хадгална уу main, staging и production.

Эцсийн алгоритм нь дараах алхмууд хүртэл буурдаг.

Контейнерын бүртгэлээс манифестуудыг татаж байна.
Kubernetes-д ашигласан зургуудыг оруулахгүй, учир нь Бид K8s API дээр санал асуулга явуулснаар тэдгээрийг аль хэдийн урьдчилан сонгосон.
Git-н түүхийг сканнердаж, тодорхой бодлогод тулгуурлан зургийг хасч байна.
Үлдсэн зургуудыг устгаж байна.

Бидний дүрслэл рүү буцаж ирэхэд werf-д ийм зүйл тохиолддог:

Гэсэн хэдий ч, та werf ашигладаггүй байсан ч гэсэн нэг юм уу өөр хувилбарт (зураг шошголох дуртай аргын дагуу) дэвшилтэт зургийг цэвэрлэх ижил төстэй аргыг бусад систем/хэрэгслүүд дээр хэрэглэж болно. Үүнийг хийхийн тулд үүссэн асуудлуудыг санаж, тэдгээрийн шийдлийг аль болох жигд нэгтгэх боломжийг олгодог стекээсээ олоход хангалттай. Бидний туулсан зам таны хэргийг шинэ нарийн ширийн зүйл, бодлоор харахад тусална гэж найдаж байна.

дүгнэлт

Эрт орой хэзээ нэгэн цагт ихэнх багууд бүртгэлийн халих асуудалтай тулгардаг.
Шийдэл хайхдаа эхлээд зургийн хамаарлын шалгуурыг тодорхойлох шаардлагатай.
Алдартай чингэлэг бүртгэлийн үйлчилгээний санал болгож буй хэрэгслүүд нь "гадна ертөнц" -ийг харгалздаггүй маш энгийн цэвэрлэгээг зохион байгуулах боломжийг олгодог: Kubernetes-д ашигласан зургууд болон багийн ажлын явцын онцлог.
Уян хатан, үр ашигтай алгоритм нь CI/CD процессын талаар ойлголттой байх ёстой бөгөөд зөвхөн Docker зургийн өгөгдөлтэй ажиллахгүй байх ёстой.

PS

Мөн манай блог дээрээс уншина уу:

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

Контейнерийн дүрсийг "ухаалаг" цэвэрлэх асуудал, түүнийг werf дэх шийдэл