Tek depo konusu birden fazla kez tartışılmıştır ve kural olarak çok aktif tartışmalara neden olur. yaratarak Git'ten Docker görüntülerine uygulama kodu oluşturma (ve ardından bunları Kubernetes'e teslim etme) sürecini iyileştirmek için tasarlanmış açık kaynaklı bir araç olarak, hangi seçeneğin en iyi olduğu konusunda fazla düşünmüyoruz. Farklı görüşlerin destekçileri için gerekli olan her şeyi sağlamak bizim için birincil öneme sahiptir (eğer bu sağduyuyla çelişmiyorsa tabii).
werf'in yakın zamandaki mono-repo desteği buna iyi bir örnektir. Ama önce bu desteğin genel olarak werf kullanımıyla nasıl bir ilişkisi olduğunu ve Docker Registry'nin bununla ne ilgisi olduğunu anlayalım...
Sorunlar
Böyle bir durumu hayal edelim. Şirketin bağımsız projeler üzerinde çalışan birçok geliştirme ekibi vardır. Çoğu uygulama Kubernet'lerde çalışır ve bu nedenle kapsayıcılıdır. Kapları, görüntüleri saklamak için bir kayıt defterine (kayıt defteri) ihtiyacınız vardır. Böyle bir kayıt defteri olarak şirket, Docker Hub'ı tek bir hesapla kullanır. COMPANY. Çoğu kaynak kodu depolama sistemine benzer şekilde, Docker Hub, iç içe depo hiyerarşisine izin vermiyor, örneğin COMPANY/PROJECT/IMAGE. Bu durumda… monolitik olmayan uygulamaları her proje için ayrı bir hesap oluşturmadan bu sınırlama ile kayıt defterinde nasıl saklayabilirsiniz?
Belki açıklanan durum birisine ilk elden tanıdık gelebilir, ancak genel olarak uygulama depolamayı düzenleme konusunu ele alalım, yani. yukarıdaki örneğe ve Docker Hub'a atıfta bulunmadan.
çözeltisi yolları
Eğer uygulama yekpare, tek bir görüntüde gelir, sonra soru kalmaz ve görüntüleri projenin kapsayıcı kayıt defterine kaydederiz.
Bir uygulama birden çok bileşen olarak sunulduğunda, mikro hizmetler, o zaman belirli bir yaklaşım gereklidir. İki görüntüden oluşan tipik bir web uygulaması örneğinde: frontend и backend - olası seçenekler şunlardır:
- Görüntüleri ayrı yuvalanmış depolarda depolayın:
- Her şeyi tek bir havuzda saklayın ve örneğin etiketteki resim adını aşağıdaki gibi düşünün:
NB: Aslında, farklı depolara kaydetme seçeneği de var, PROJECT-frontend и PROJECT-backend, ancak destek, organizasyon ve hakların kullanıcılar arasında dağıtılmasının karmaşıklığı nedeniyle bunu dikkate almayacağız.
zayıf destek
Başlangıçta, werf kendini iç içe depolarla sınırladı - neyse ki çoğu kayıt defteri bu özelliği destekliyor. Sürümden başlayarak , kayıt defterleriyle çalışma eklendi yuvalama desteklenmiyorve Docker Hub bunlardan biri. Bu noktadan itibaren, kullanıcının uygulama görüntülerini nasıl saklayacağına dair bir seçeneği vardır.
Seçenek altında uygulama mevcuttur --images-repo-mode=multirepo|monorepo (varsayılan multirepo, yani yuvalanmış depolarda depolama). Görüntülerin kayıt defterinde depolandığı kalıpları tanımlar. Temel komutları kullanırken istenen modu seçmek yeterlidir ve diğer her şey değişmeden kalacaktır.
Çoğu werf seçeneği ayarlanabildiği için Ortam DeğişkenleriCI / CD sistemlerinde, depolama modunun tüm proje için genel olarak ayarlanması genellikle kolaydır. Örneğin, GitLab durumunda sadece proje ayarlarında bir ortam değişkeni ekleyin: Ayarlar -> CI / CD -> Değişkenler: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Görüntüleri yayınlamaktan ve uygulamaları kullanıma sunmaktan bahsedersek (bu süreçler hakkında ayrıntılı olarak ilgili belge makalelerinde okuyabilirsiniz: и ), mod yalnızca görüntüyle çalışabileceğiniz şablonu belirler.
Ayrıntıdaki Şeytan
Yeni bir depolama yöntemi eklerken fark ve ana zorluk, kayıt defterini temizleme sürecindedir. (wef tarafından desteklenen temizleme özellikleri için, bkz. ).
Werf, temizlerken Kubernetes kümelerinde kullanılan görüntülerin yanı sıra kullanıcı tarafından yapılandırılan ilkeleri de dikkate alır. Politikalar, etiketlerin stratejilere bölünmesine dayanır. Şu anda desteklenen stratejiler:
- Etiket, şube ve taahhüt gibi Git ilkelleriyle bağlantılı 3 strateji;
- İsteğe bağlı özel etiketler için 1 strateji.
Görüntüyü yayınlarken etiket stratejisi hakkındaki bilgileri nihai görüntünün etiketlerinde saklarız. Anlamın kendisi sözde meta etiketi - Bazı politikaların uygulanması için gereklidir. Örneğin, bir Git deposundan bir dal veya etiketi silerken ilgili silme işlemi mantıklıdır. kullanılmamış politikalarımızın bir parçası olan kayıt defterinden görüntüler.
Bir havuza kaydedildiğinde (monorepo), resim etiketinde meta etikete ek olarak resmin adı da saklanabilir: PROJECT:frontend-META-TAG. Bunları ayırmak için herhangi bir özel ayırıcı kullanmadık, sadece yayınlarken nihai görüntünün etiketine gerekli değeri ekledik.
NB: Werf kaynak kodunda açıklanan her şeye bakmakla ilgileniyorsanız, başlangıç noktası şu olabilir: .
Bu makalede, yaklaşımımızın sorunlarına ve gerekçelerine daha fazla dikkat etmeyeceğiz: etiketleme stratejileri, verileri etiketlerde depolama ve bir bütün olarak yayınlama süreci - tüm bunlar, Dmitry Stolyarov'un yakın tarihli bir raporunda ayrıntılı olarak açıklanmaktadır: "'.
özetleme
İç içe geçmiş kayıt defterleri için destek eksikliği, bizim veya bildiğimiz wef kullanıcıları için bir engelleyici faktör değildi - sonuçta, her zaman ayrı bir görüntü kaydı oluşturabilirsiniz (veya Google Cloud'da koşullu bir Container Registry'ye geçebilirsiniz) ... Ancak, Aracın daha geniş DevOps topluluğu için daha uygun olması için böyle bir kısıtlamanın kaldırılması mantıklı görünüyordu. Bunu uygularken, kapsayıcı kayıt defteri temizleme mekanizmasını elden geçirme konusunda temel zorlukla karşılaştık. Artık her şey hazır olduğuna göre, birisi için bunun daha kolay hale geldiğini anlamak güzel ve biz (projenin ana geliştiricileri olarak) bu özelliği daha fazla desteklemekte gözle görülür bir zorluk yaşamayacağız.
Bizimle kalın, çok yakında size diğer yeniliklerden bahsedeceğiz. !
PS
Blogumuzda da okuyun:
- «";
- «'.
Kaynak: habr.com