Моно репозиторын сэдвийг нэгээс олон удаа хэлэлцсэн бөгөөд дүрмээр бол маш идэвхтэй маргаан үүсгэдэг. Бүтээснээр Git-ээс Docker зураг руу програмын код үүсгэх үйл явцыг сайжруулахад зориулагдсан нээлттэй эхийн хэрэглүүрийн хувьд (дараа нь Кубернетес рүү хүргэх) бид аль сонголт нь илүү дээр вэ гэдгийг нэг их боддоггүй. Бидний хувьд янз бүрийн үзэл бодлыг дэмжигчдэд шаардлагатай бүх зүйлийг хангах нь чухал юм (хэрэв энэ нь мэдээжийн хэрэг эрүүл ухаантай зөрчилдөхгүй бол).
werf-ийн саяхан хийсэн моно-репогийн дэмжлэг нь үүний тод жишээ юм. Гэхдээ эхлээд энэ дэмжлэг нь werf ашиглахтай хэрхэн холбоотой болохыг, мөн Docker Registry үүнтэй ямар холбоотой болохыг олж мэдье ...
Асуудал
Ийм нөхцөл байдлыг төсөөлөөд үз дээ. Тус компани нь бие даасан төслүүд дээр ажилладаг хөгжлийн олон багтай. Ихэнх програмууд Kubernetes дээр ажилладаг тул контейнерт хадгалагддаг. Контейнер, зураг хадгалахын тулд танд бүртгэл (бүртгэл) хэрэгтэй. Ийм бүртгэлийн хувьд компани нь нэг данстай Docker Hub ашигладаг COMPANY. Ихэнх эх код хадгалах системтэй адил, Docker Hub нь үүрлэсэн репозиторын шатлалыг зөвшөөрдөггүйгэх мэт COMPANY/PROJECT/IMAGE. Энэ тохиолдолд… төсөл бүрт тусдаа бүртгэл үүсгэхгүйгээр энэ хязгаарлалттай цул бус програмуудыг бүртгэлд хэрхэн хадгалах вэ?
Магадгүй тайлбарласан нөхцөл байдал нь хэн нэгэнд танил байж магадгүй, гэхдээ програмын хадгалалтыг зохион байгуулах асуудлыг ерөнхийд нь авч үзье, жишээлбэл. дээрх жишээ болон Docker Hub-г дурдаагүй.
Шийдэл
Хэрэв програм цул, нэг зураг дээр ирдэг, дараа нь ямар ч асуулт байхгүй бөгөөд бид зүгээр л зургийг төслийн контейнерийн бүртгэлд хадгалдаг.
Програмыг олон бүрэлдэхүүн хэсэг болгон харуулах үед, бичил үйлчилгээ, дараа нь тодорхой арга барил шаардлагатай. Хоёр зургаас бүрдэх ердийн вэб програмын жишээн дээр: frontend и backend - боломжит сонголтууд нь:
- Зургийг тусдаа үүрлэсэн хадгалах санд хадгалах:
- Бүгдийг нэг агуулахад хадгалж, шошгон дээрх зургийн нэрийг, жишээлбэл, дараах байдлаар авч үзье.
NB: Үнэндээ өөр өөр репозиторуудад хадгалах өөр сонголт бий. PROJECT-frontend и PROJECT-backend, гэхдээ бид үүнийг анхаарч үзэхгүй, учир нь дэмжлэг, зохион байгуулалт, хэрэглэгчдийн хоорондох эрхийг хуваарилах нь нарийн төвөгтэй байдаг.
werf дэмжлэг
Эхэндээ werf нь үүрлэсэн агуулахаар хязгаарлагдаж байсан - аз болоход ихэнх бүртгэлүүд энэ функцийг дэмждэг. Хувилбараас эхлэн , бүртгэлтэй ажил нэмсэн үүрлэхийг дэмждэггүй, мөн Docker Hub нь тэдний нэг юм. Энэ үеэс эхлэн хэрэглэгч програмын зургийг хэрхэн хадгалах сонголттой болно.
Сонголтоор хэрэгжүүлэх боломжтой --images-repo-mode=multirepo|monorepo (өгөгдмөл multirepo, өөрөөр хэлбэл үүрлэсэн репозиторуудад хадгалах). Энэ нь зураг бүртгэлд хадгалагдах хэв маягийг тодорхойлдог. Үндсэн командуудыг ашиглахдаа хүссэн горимыг сонгоход хангалттай бөгөөд бусад бүх зүйл өөрчлөгдөхгүй хэвээр үлдэнэ.
Учир нь ихэнх werf сонголтуудыг тохируулж болно орчны хувьсагч, CI / CD системд хадгалах горимыг бүхэлд нь төслийн хувьд дэлхий даяар тохируулахад хялбар байдаг. Жишээлбэл, GitLab-ийн хувьд Төслийн тохиргоонд орчны хувьсагчийг нэмэхэд л хангалттай: Тохиргоо -> CI / CD -> Хувьсагч: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Хэрэв бид зураг нийтлэх, програмуудыг нэвтрүүлэх талаар ярих юм бол (та эдгээр үйл явцын талаар холбогдох баримт бичгийн нийтлэлээс дэлгэрэнгүй уншиж болно: и ), дараа нь горим нь зөвхөн зурагтай ажиллах загварыг тодорхойлно.
Чөтгөр нарийн ширийн зүйлд байдаг
Хадгалах шинэ аргыг нэмэхэд тулгарч буй ялгаа ба гол бэрхшээл нь бүртгэлийг цэвэрлэх үйл явц юм (werf-ээр дэмжигдсэн цэвэрлэх функцуудыг үзнэ үү ).
Цэвэрлэхдээ werf нь Kubernetes кластерт ашигласан зургууд болон хэрэглэгчийн тохируулсан бодлогыг харгалзан үздэг. Бодлого нь шошгыг стратегид хуваахад үндэслэдэг. Одоогоор дэмжигдсэн стратегиуд:
- Tag, branch, commit гэх мэт Git командуудаар холбогдсон 3 стратеги;
- Дурын захиалгат шошгонд зориулсан 1 стратеги.
Бид зургийг эцсийн зургийн шошгонд нийтлэхдээ шошгоны стратегийн талаарх мэдээллийг хадгалдаг. Утга нь өөрөө гэж нэрлэгддэг зүйл юм мета шошго - Зарим бодлогыг хэрэгжүүлэх шаардлагатай. Жишээлбэл, Git репозитороос салбар эсвэл тагийг устгах үед холбогдох устгах нь логик юм ашиглагдаагүй Манай бодлогын нэг хэсэг болох бүртгэлийн газрын зургууд.
Нэг агуулахад хадгалсан үед (monorepo), зургийн шошгонд мета хаягаас гадна зургийн нэрийг хадгалах боломжтой: PROJECT:frontend-META-TAG. Тэдгээрийг салгахын тулд бид ямар нэгэн тусгай тусгаарлагчийг оруулаагүй бөгөөд нийтлэхдээ эцсийн зургийн шошгон дээр шаардлагатай утгыг нэмсэн.
NB: Хэрэв та werf эх кодод тайлбарласан бүх зүйлийг үзэх сонирхолтой байгаа бол эхлэх цэг нь байж болно .
Энэ нийтлэлд бид өөрсдийн хандлагын асуудал, үндэслэлд илүү их анхаарал хандуулахгүй: стратеги шошголох, өгөгдлийг шошгонд хадгалах, нийтлэх үйл явцын талаар - энэ бүгдийг Дмитрий Столяровын саяхан гаргасан тайланд дэлгэрэнгүй тайлбарласан болно: "".
Нэгтгэн дүгнэхэд
Бүртгэлгүй бүртгэлийг дэмжихгүй байгаа нь бидний хувьд эсвэл бидний мэддэг werf хэрэглэгчдийн хувьд саад болохгүй байсан - эцэст нь та үргэлж тусдаа зургийн бүртгэл үүсгэж болно (эсвэл Google Cloud дахь нөхцөлт Контейнер Бүртгэл рүү шилжиж болно) ... Гэсэн хэдий ч, Ийм хязгаарлалтыг арилгах нь хэрэгсэл нь илүү өргөн DevOps нийгэмлэгт илүү тохиромжтой байхын тулд логик юм шиг санагдсан. Үүнийг хэрэгжүүлснээр бид чингэлэгийн бүртгэлийг цэвэрлэх механизмыг дахин боловсруулахад гол хүндрэлтэй тулгарсан. Одоо бүх зүйл бэлэн болсон тул энэ нь хэн нэгэнд илүү хялбар болсон гэдгийг ойлгоход таатай байна, бид (төслийн гол хөгжүүлэгчдийн хувьд) энэ функцийг цаашид дэмжихэд мэдэгдэхүйц бэрхшээл гарахгүй.
Бидэнтэй хамт байгаарай, тун удахгүй бид бусад шинэлэг зүйлсийн талаар танд хэлэх болно !
PS
Мөн манай блог дээрээс уншина уу:
- «";
- «".
Эх сурвалж: www.habr.com