🥇werf цуглуулагч дахь контент дээр суурилсан шошго: яагаад, яаж ажилладаг вэ?

верф нь манай нээлттэй эхийн GitOps CLI хэрэгсэл юм. IN хувилбар 1.1 Зураг цуглуулагч дээр шинэ функцийг нэвтрүүлсэн: зургийг контентоор нь шошголох эсвэл агуулгад суурилсан шошго. Өнөөг хүртэл werf-ийн ердийн шошголох схем нь Docker зургийг Git tag, Git салбар эсвэл Git commit-ээр тэмдэглэдэг байв. Гэхдээ эдгээр бүх схемүүд нь шинэ шошго стратегиар бүрэн шийдэгдсэн сул талуудтай. Энэ талаархи дэлгэрэнгүй мэдээлэл, яагаад ийм сайн болохыг захын доор харуулав.

Нэг Git репозитороос микро үйлчилгээний багцыг гаргаж байна

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

Үйлчилгээнүүд нь үнэхээр бие даасан, нэг програмтай холбоогүй байх тохиолдол байдаг. Энэ тохиолдолд тэдгээрийг тусдаа төслүүдэд байрлуулах бөгөөд тэдгээрийг гаргах нь төсөл тус бүрт тусдаа CI/CD процессоор явагдана.

Гэсэн хэдий ч бодит байдал дээр хөгжүүлэгчид ихэвчлэн нэг програмыг хэд хэдэн бичил үйлчилгээнд хуваадаг боловч тус бүрдээ тусдаа репозитор болон төсөл бий болгох нь... илт хэтрүүлсэн хэрэг юм. Энэ нөхцөл байдлыг цаашид авч үзэх болно: хэд хэдэн ийм микро үйлчилгээнүүд нь нэг төслийн репозиторид байрладаг бөгөөд CI/CD дахь нэг процессоор дамжуулан хувилбарууд гардаг.

Git салбар болон Git тагаар тэмдэглэгээ хийх

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

Шинэ Git таг үүсгэх үед, жишээлбэл, шинэ хувилбар гарах үед Docker Бүртгэлийн бүх төслийн зурагт шинэ Docker тагийг үүсгэнэ.

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Эдгээр шинэ зургийн нэрийг Helm загваруудаар дамжуулан Kubernetes тохиргоонд шилжүүлсэн. тушаалаар байршуулалтыг эхлүүлэх үед werf deploy талбарыг шинэчилж байна image Kubernetes дахь нөөц нь өөрчлөгдсөн зургийн улмаас харгалзах нөөцийг дахин эхлүүлж байна.

асуудал: үнэн хэрэгтээ өмнөх хувилбараас хойш зургийн агуулга өөрчлөгдөөгүй (Git tag), гэхдээ зөвхөн түүний Docker шошготой тохиолдолд энэ нь тохиолддог. нэмэлт энэ програмыг дахин эхлүүлж, үүний дагуу зарим нэг зогсолт хийх боломжтой. Хэдийгээр энэ дахин эхлүүлэх бодит шалтгаан байгаагүй.

Үүний үр дүнд одоогийн хаяглалтын схемийн дагуу хэд хэдэн тусдаа Git агуулахыг хаах шаардлагатай болсон бөгөөд эдгээр хэд хэдэн агуулахыг нэвтрүүлэх ажлыг зохион байгуулахад асуудал үүсдэг. Ерөнхийдөө ийм схем нь хэт ачаалалтай, төвөгтэй болж хувирдаг. Шаардлагагүй дахин эхлүүлэхгүйн тулд олон үйлчилгээг нэг репозитортой болгож, Docker хаягуудыг үүсгэх нь дээр.

Git commit-ээр тэмдэглэгээ хийх

werf нь Git commits-тэй холбоотой шошголох стратегитай байдаг.

Git-commit нь Git репозиторын агуулгыг тодорхойлох танигч бөгөөд Git репозитор дахь файлуудын засварын түүхээс хамаардаг тул Docker Registry-д дүрсийг шошголоход ашиглах нь логик юм.

Гэсэн хэдий ч Git commit-ээр тэмдэглэгээ хийх нь Git салбарууд эсвэл Git хаягуудаар шошголохтой адил сул талуудтай:

Ямар ч файлыг өөрчлөхгүй хоосон амлалт үүсгэж болох ч зургийн Docker хаяг өөрчлөгдөх болно.
Файлуудыг өөрчлөхгүй нэгтгэх үүрэг үүсгэж болох боловч зургийн Docker шошго өөрчлөгдөх болно.
Зурганд импортлогдоогүй Git дээрх файлуудыг өөрчлөх үүрэг даалгавар өгч, зургийн Docker шошго дахин өөрчлөгдөх болно.

Гит салбарын нэрийг шошголох нь зургийн хувилбарыг тусгаагүй болно

Git салбаруудын шошголох стратегитай холбоотой өөр нэг асуудал бий.

Салбарын нэрээр шошголох нь тухайн салбар дээрх амлалтуудыг он цагийн дарааллаар дараалан цуглуулсан тохиолдолд ажиллана.

Хэрэв одоогийн схемд хэрэглэгч тодорхой салбартай холбоотой хуучин амлалтаа сэргээж эхэлбэл werf нь хуучин амлалтад зориулсан зургийн шинэ хувилбартай харгалзах Docker тагийг ашиглан зургийг дахин бичих болно. Одооноос эхлэн энэ шошгыг ашиглах нь pod-уудыг дахин эхлүүлэх үед зургийн өөр хувилбарыг татах эрсдэлтэй бөгөөд үүний үр дүнд манай програм CI системтэй холболтоо алдаж, синхрончлолгүй болно.

Нэмж дурдахад, нэг салбар руу дараалан шахаж, хооронд нь богино хугацаанд оруулснаар хуучин амлалт нь шинэээс хожуу эмхэтгэгдэж болно: зургийн хуучин хувилбар нь Git салбар таг ашиглан шинийг дарж бичнэ. Ийм асуудлуудыг CI/CD системээр шийдэж болно (жишээлбэл, GitLab CI-д сүүлийнх нь хэд хэдэн үүрэг даалгавар өгөхөд зориулагдсан). Гэсэн хэдий ч бүх системүүд үүнийг дэмждэггүй бөгөөд ийм үндсэн асуудлаас урьдчилан сэргийлэх илүү найдвартай арга байх ёстой.

Агуулгад суурилсан шошго гэж юу вэ?

Тэгэхээр контент дээр суурилсан шошго гэж юу вэ - зургийг контентоор нь шошголох.

Docker тагийг үүсгэхийн тулд Git командуудыг (Git салбар, Git таг...) биш, харин дараахтай холбоотой шалгах нийлбэрийг ашигладаг.

зургийн агуулга. Зургийн ID шошго нь түүний агуулгыг илэрхийлдэг. Шинэ хувилбар бүтээх үед зураг дээрх файлууд өөрчлөгдөөгүй бол энэ танигч өөрчлөгдөхгүй;
Git дээр энэ зургийг бүтээсэн түүх. Git-ийн өөр салбаруудтай холбоотой зургууд болон werf-ээр дамжуулан өөр өөр бүтээх түүхүүд өөр өөр ID шошготой байх болно.

Ийм таних тэмдэг гэж нэрлэгддэг зургийн тайзны гарын үсэг.

Зураг бүр нь дараах үе шатуудаас бүрдэнэ. from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch гэх мэт. Үе шат бүр нь түүний агуулгыг тусгасан тодорхойлогчтой - тайзны гарын үсэг (тайзны гарын үсэг).

Эдгээр үе шатуудаас бүрдэх эцсийн зургийг эдгээр үе шатуудын багцын гарын үсэг гэж нэрлэдэг. гарын үсэг зурах үе шат, - зургийн бүх үе шатыг ерөнхийд нь харуулж байна.

Тохиргооны зураг бүрийн хувьд werf.yaml ерөнхий тохиолдолд өөрийн гарын үсэг, үүний дагуу Docker шошго байх болно.

Тайзны гарын үсэг нь эдгээр бүх асуудлыг шийддэг.

Git-ийн хоосон амлалтуудад тэсвэртэй.
Git-д тэсвэртэй нь зурагт хамааралгүй файлуудыг өөрчлөх үүрэгтэй.
Салбарын хуучин Git commits-ийн бүтцийг дахин эхлүүлэх үед зургийн одоогийн хувилбарыг шинэчлэх асуудал гарахгүй.

Энэ нь одоо санал болгож буй шошгололтын стратеги бөгөөд бүх CI системүүдийн werf-д анхдагч юм.

werf дээр хэрхэн идэвхжүүлж, ашиглах вэ

Одоо тушаалд тохирох сонголт байна werf publish: --tag-by-stages-signature=true|false

CI системд шошголох стратеги нь тушаалаар тодорхойлогддог werf ci-env. Өмнө нь түүний параметрийг тодорхойлсон werf ci-env --tagging-strategy=tag-or-branch. Одоо, хэрэв та зааж өгвөл werf ci-env --tagging-strategy=stages-signature эсвэл энэ сонголтыг зааж өгөхгүй бол werf нь шошголох стратегийг анхдагчаар ашиглах болно stages-signature. Баг werf ci-env командын шаардлагатай тугуудыг автоматаар тохируулах болно werf build-and-publish (эсвэл werf publish), тиймээс эдгээр командуудад нэмэлт сонголт оруулах шаардлагагүй.

Жишээлбэл, тушаал:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... дараах зургуудыг үүсгэж болно:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

энд 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d нь зургийн үе шатуудын гарын үсэг юм backendболон f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - зургийн үе шатуудын гарын үсэг frontend.

Тусгай функцийг ашиглах үед werf_container_image и werf_container_env Helm загварт ямар нэг зүйлийг өөрчлөх шаардлагагүй: эдгээр функцууд нь зургийн зөв нэрийг автоматаар үүсгэх болно.

CI систем дэх жишээ тохиргоо:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Тохиргооны талаарх дэлгэрэнгүй мэдээллийг баримтаас авах боломжтой:

Нийт

Шинэ сонголт werf publish --tag-by-stages-signature=true|false.
Шинэ сонголтын утга werf ci-env --tagging-strategy=stages-signature|tag-or-branch (хэрэв заагаагүй бол өгөгдмөл байх болно stages-signature).
Хэрэв та Git commits-д тэмдэглэгээ хийх сонголтыг өмнө нь ашиглаж байсан бол (WERF_TAG_GIT_COMMIT эсвэл сонголт werf publish --tag-git-commit COMMIT), дараа нь шошголох стратеги руу шилжихээ мартуузай үе шат-гарын үсэг.
Шинэ төслүүдийг шинэ тэмдэглэгээний схемд нэн даруй шилжүүлэх нь дээр.
Werf 1.1 руу шилжихдээ хуучин төслүүдийг шинэ хаяглалтын схемд шилжүүлэхийг зөвлөж байна, гэхдээ хуучин шошго эсвэл салбар дэмжсэн хэвээр байна.

Агуулгад суурилсан шошго нь нийтлэлд дурдсан бүх асуудлыг шийддэг.

Git-ийн хоосон амлалтуудад Docker тагийн нэрийн эсэргүүцэл.
Docker тагийн нэрний Git-д тэсвэртэй байдал нь зурагт хамааралгүй файлуудыг өөрчилдөг.
Гит салбаруудад зориулсан хуучин Git коммитуудад зориулсан бүтцийг дахин эхлүүлэх үед зургийн одоогийн хувилбарыг шинэчлэх асуудал гарахгүй.

Үүнийг хэрэглэ! Мөн манайхаар зочлохоо бүү мартаарай GitHubасуудал үүсгэх эсвэл одоо байгаа асуудлыг олох, нэмэх нэмэх, PR үүсгэх эсвэл төслийн хөгжлийг үзэх.

PS

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

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

Werf цуглуулагч дахь контент дээр суурилсан шошго: яагаад, яаж ажилладаг вэ?