Mono-repozitoriya mövzusu bir dəfədən çox müzakirə edilmişdir və bir qayda olaraq, çox aktiv mübahisələrə səbəb olur. Yaratmaqla Git-dən Docker şəkillərinə tətbiq kodunun yaradılması prosesini təkmilləşdirmək üçün nəzərdə tutulmuş açıq mənbə aləti olaraq (və sonra onları Kubernetes-ə çatdırırıq), hansı seçimin daha yaxşı olduğu barədə çox düşünmürük. Bizim üçün ilk növbədə müxtəlif fikirlərin tərəfdarları üçün lazım olan hər şeyi təmin etməkdir (əgər bu, təbii ki, sağlam düşüncəyə zidd deyilsə).
werf-in son mono-repo dəstəyi buna yaxşı nümunədir. Ancaq əvvəlcə bu dəstəyin ümumiyyətlə werf-dən istifadə ilə necə əlaqəli olduğunu və Docker Registry-nin bununla nə əlaqəsi olduğunu anlayaq ...
Məsələlər
Belə bir vəziyyəti təsəvvür edək. Şirkətin müstəqil layihələr üzərində işləyən bir çox inkişaf qrupu var. Əksər proqramlar Kubernetes-də işləyir və buna görə də konteynerləşdirilir. Konteynerləri, şəkilləri saxlamaq üçün reyestr (reyestr) lazımdır. Belə bir reyestr kimi şirkət bir hesabla Docker Hub-dan istifadə edir COMPANY. Əksər mənbə kodu saxlama sistemlərinə bənzər, Docker Hub yuvalanmış depo iyerarxiyasına icazə vermir, kimi COMPANY/PROJECT/IMAGE. Bu halda... hər bir layihə üçün ayrıca hesab yaratmadan bu məhdudiyyətlə qeyri-monolit proqramları reyestrdə necə saxlaya bilərsiniz?
Ola bilsin ki, təsvir olunan vəziyyət kiməsə əvvəlcədən tanışdır, amma ümumiyyətlə tətbiqetmənin saxlanmasının təşkili məsələsini nəzərdən keçirək, yəni. yuxarıdakı nümunəyə və Docker Hub-a istinad etmədən.
Həllər
Ərizə varsa monolit, bir şəkildə gəlir, onda heç bir sual yoxdur və biz sadəcə olaraq şəkilləri layihənin konteyner reyestrində saxlayırıq.
Tətbiq çoxsaylı komponentlər kimi təqdim edildikdə, mikroservislər, onda müəyyən bir yanaşma tələb olunur. İki şəkildən ibarət tipik bir veb tətbiqi nümunəsində: frontend и backend - mümkün variantlar bunlardır:
- Şəkilləri ayrı-ayrı yuvalanmış depolarda saxlayın:
- Hər şeyi bir depoda saxlayın və etiketdəki şəklin adını, məsələn, aşağıdakı kimi nəzərdən keçirin:
NB: Əslində, müxtəlif depolarda saxlamaq üçün başqa bir seçim var, PROJECT-frontend и PROJECT-backend, lakin dəstək, təşkili və istifadəçilər arasında hüquqların bölüşdürülməsinin mürəkkəbliyi səbəbindən bunu nəzərdən keçirməyəcəyik.
werf dəstəyi
Başlanğıcda, werf özünü yuvalanmış depolarla məhdudlaşdırırdı - xoşbəxtlikdən, əksər registrlər bu funksiyanı dəstəkləyir. Versiyadan başlayaraq , olan registrləri ilə iş əlavə etdi yuvalama dəstəklənmir, və Docker Hub onlardan biridir. Bu andan etibarən istifadəçi proqram şəkillərini necə saxlamağı seçə bilər.
Seçim altında həyata keçirilə bilər --images-repo-mode=multirepo|monorepo (standart multirepo, yəni. yuvalanmış anbarlarda saxlama). Şəkillərin reyestrdə saxlandığı nümunələri müəyyənləşdirir. Əsas əmrləri istifadə edərkən istədiyiniz rejimi seçmək kifayətdir və qalan hər şey dəyişməz qalacaq.
Çünki əksər werf variantları təyin edilə bilər mühit dəyişənləri, CI / CD sistemlərində saxlama rejimi ümumiyyətlə bütün layihə üçün qlobal olaraq təyin etmək asandır. Misal üçün, GitLab vəziyyətində sadəcə layihə parametrlərinə mühit dəyişəni əlavə edin: Parametrlər -> CI / CD -> Dəyişənlər: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Şəkillərin dərc edilməsi və tətbiqlərin yayılması haqqında danışsaq (bu proseslər haqqında müvafiq sənədləşmə məqalələrində ətraflı oxuya bilərsiniz: и ), onda rejim yalnız şəkillə işləyə biləcəyiniz şablonu müəyyən edir.
Şeytan təfərrüatlardadır
Yeni bir saxlama metodu əlavə edərkən fərq və əsas çətinlik reyestrin təmizlənməsi prosesindədir (werf tərəfindən dəstəklənən təmizləmə xüsusiyyətləri üçün bax ).
Təmizləmə zamanı werf Kubernetes klasterlərində istifadə olunan şəkilləri, həmçinin istifadəçi tərəfindən konfiqurasiya edilmiş siyasətləri nəzərə alır. Siyasətlər etiketlərin strategiyalara bölünməsinə əsaslanır. Hazırda dəstəklənən strategiyalar:
- tag, filial və commit kimi Git primitivləri ilə əlaqəli 3 strategiya;
- ixtiyari fərdi teqlər üçün 1 strategiya.
Şəkili yekun şəklin etiketlərində dərc edərkən etiket strategiyası haqqında məlumatı saxlayırıq. Məna özü sözdə olandır meta teq - Bəzi siyasətləri tətbiq etmək tələb olunur. Məsələn, Git repozitoriyasından filial və ya etiketi silərkən əlaqəli silmək məntiqlidir istifadəsiz siyasətlərimizin bir hissəsi ilə əhatə olunan reyestrdən şəkillər.
Bir depoda saxlandıqda (monorepo), şəkil etiketində meta teqdən əlavə, şəklin adı da saxlanıla bilər: PROJECT:frontend-META-TAG. Onları ayırmaq üçün biz heç bir xüsusi ayırıcı təqdim etmədik, sadəcə dərc edərkən son şəklin etiketinə lazımi dəyəri əlavə etdik.
NB: Əgər werf mənbə kodunda təsvir olunan hər şeyə baxmaqla maraqlanırsınızsa, o zaman başlanğıc nöqtəsi ola bilər .
Bu yazıda problemlərə və yanaşmamızın əsaslandırılmasına daha çox diqqət yetirməyəcəyik: etiketləmə strategiyaları, məlumatların etiketlərdə saxlanması və bütövlükdə nəşr prosesi haqqında - bütün bunlar Dmitri Stolyarovun son hesabatında ətraflı təsvir edilmişdir: “.
Xülasə
Yuvalanmamış registrlər üçün dəstəyin olmaması bizim və ya bizə məlum olan werf istifadəçiləri üçün bloklama faktoru deyildi - axırda siz hər zaman ayrıca şəkil reyestrini qaldıra bilərsiniz (və ya Google Cloud-da şərti Konteyner Reyestrinə keçə bilərsiniz) ... Bununla belə, alətin daha geniş DevOps icması üçün daha rahat olması üçün belə bir məhdudiyyətin aradan qaldırılması məntiqli görünürdü. Onu həyata keçirərək, biz konteyner reyestrinin təmizlənməsi mexanizminin yenidən işlənməsində əsas çətinliklə üzləşdik. İndi hər şey hazırdır, bunun kimsə üçün asanlaşdığını başa düşmək xoşdur və biz (layihənin əsas tərtibatçıları olaraq) bu funksiyanı daha da dəstəkləməkdə heç bir nəzərə çarpan çətinlik çəkməyəcəyik.
Bizimlə qalın və tezliklə biz sizə digər yeniliklər haqqında məlumat verəcəyik !
PS
Bloqumuzda da oxuyun:
- «";
- «.
Mənbə: www.habr.com
