Kubernetes'e uygulamalar oluşturmaya ve sunmaya yönelik açık kaynaklı GitOps CLI yardımcı programımızdır. Söz verildiği gibi, Werf'e yeni özellikler eklemenin ve geleneksel yaklaşımları revize etmenin başlangıcını işaret etti. Şimdi geliştirmede büyük bir adım ve gelecek için bir temel olan v1.1 sürümünü sunmaktan mutluluk duyuyoruz kolektör Werf. Sürüm şu anda şu adreste mevcuttur: .
Sürümün temeli, sahne depolamasının yeni mimarisi ve her iki toplayıcının (Stapel ve Dockerfile için) çalışmalarının optimizasyonudur. Yeni depolama mimarisi, birden fazla ana bilgisayardan dağıtılmış derlemelerin ve aynı ana bilgisayardaki paralel derlemelerin uygulanması olasılığının önünü açıyor.
İşin optimizasyonu, aşama imzalarının hesaplanması aşamasında gereksiz hesaplamalardan kurtulmayı ve dosya sağlama toplamlarını hesaplama mekanizmalarını daha verimli olanlarla değiştirmeyi içerir. Bu optimizasyon, werf kullanılarak proje oluşturmanın ortalama süresini azaltır. Ve tüm aşamalar önbellekte mevcut olduğunda boşta kalan yapılar aşama depolama, artık gerçekten hızlılar. Çoğu durumda yapının yeniden başlatılması 1 saniyeden kısa sürer! Bu aynı zamanda ekiplerin çalışma sürecindeki aşamaların doğrulanmasına yönelik prosedürler için de geçerlidir. werf deploy и werf run.
Bu sürümde ayrıca görsellerin içeriğe göre etiketlenmesine yönelik bir strateji ortaya çıktı: içerik tabanlı etiketleme, artık varsayılan olarak etkindir ve önerilen tek seçenektir.
Werf v1.1'deki önemli yeniliklere daha yakından bakalım ve aynı zamanda geleceğe yönelik planlarımızdan da bahsedelim.
Werf v1.1'de neler değişti?
Önbellekten aşamaları seçmek için yeni aşama adlandırma formatı ve algoritması
Yeni sahne adı oluşturma kuralı. Artık her aşama yapısı, 2 bölümden oluşan benzersiz bir aşama adı oluşturuyor: bir imza (v1.0'da olduğu gibi) ve benzersiz bir geçici tanımlayıcı.
Örneğin, tam aşama görselinin adı şu şekilde görünebilir:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...veya genel olarak:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Burada:
-
SIGNATUREsahne alanı içeriğinin tanımlayıcısını temsil eden ve Git'te bu içeriğe yol açan düzenlemelerin geçmişine bağlı olan bir aşama imzasıdır; -
TIMESTAMP_MILLISECyeni bir görüntünün oluşturulduğu sırada oluşturulan, garantili benzersiz bir görüntü tanımlayıcıdır.
Önbellekten aşama seçme algoritması Git taahhütlerinin ilişkisini kontrol etmeye dayanır:
- Werf belirli bir aşamanın imzasını hesaplar.
- В aşama depolama Belirli bir imzanın birkaç aşaması olabilir. Werf, imzayla eşleşen tüm aşamaları seçer.
- Geçerli aşama Git'e bağlıysa (git arşivi, Git yamalarıyla özel aşama:
install,beforeSetup,setup; veya git-latest-patch), bu durumda werf yalnızca mevcut taahhüdün atası olan (derlemenin çağrıldığı) bir taahhütle ilişkili aşamaları seçer. - Geriye kalan uygun aşamalardan biri seçilir; oluşturulma tarihine göre en eskisi.
Farklı Git dallarına yönelik bir aşama aynı imzaya sahip olabilir. Ancak werf, imzalar eşleşse bile farklı dallarla ilişkili önbelleğin bu dallar arasında kullanılmasını önleyecektir.
.
Sahne alanı deposunda aşamaları oluşturmak ve kaydetmek için yeni algoritma
Önbellekten aşamaları seçerken werf uygun bir aşama bulamazsa yeni bir aşamanın montaj süreci başlatılır.
Birden fazla işlemin (bir veya daha fazla ana bilgisayarda) aynı aşamayı yaklaşık olarak aynı anda oluşturmaya başlayabileceğini unutmayın. Werf iyimser bir engelleme algoritması kullanıyor aşama depolama yeni toplanan görüntüyü kaydederken aşama depolama. Bu şekilde yeni sahne yapısı hazır olduğunda werf blokları aşama depolama ve yeni toplanan bir görüntüyü, yalnızca uygun bir görüntü artık mevcut değilse oraya kaydeder (imzaya ve diğer parametrelere göre - önbellekten aşamaları seçmek için yeni algoritmaya bakın).
Yeni birleştirilmiş bir görüntünün benzersiz bir tanımlayıcıya sahip olması garanti edilir: TIMESTAMP_MILLISEC (yeni aşama adlandırma formatına bakın). durumunda aşama depolama uygun bir görüntü bulunacak, werf yeni derlenen görüntüyü atacak ve görüntüyü önbellekten kullanacak.
Başka bir deyişle: görüntüyü oluşturmayı bitiren ilk süreç (en hızlısı), onu aşamalı depolamada saklama hakkına sahip olacaktır (ve ardından tüm derlemeler için bu tek görüntü kullanılacaktır). Yavaş bir derleme süreci, daha hızlı bir sürecin mevcut aşamanın derleme sonuçlarını kaydetmesini ve bir sonraki yapıya geçmesini asla engellemez.
.
Geliştirilmiş Dockerfile oluşturucu performansı
Şu anda Dockerfile'dan oluşturulan bir görüntünün aşamaları tek bir aşamadan oluşuyor: dockerfile. İmza hesaplanırken dosyaların sağlama toplamı hesaplanır contextMontaj sırasında kullanılacaktır. Bu iyileştirmeden önce, werf yinelemeli olarak tüm dosyalar üzerinde geziniyor ve her dosyanın bağlamını ve modunu toplayarak bir sağlama toplamı elde ediyordu. V1.1'den itibaren werf, Git deposunda saklanan hesaplanmış sağlama toplamlarını kullanabilir.
Algoritma dayanmaktadır . Algoritma kayıtları dikkate alır .dockerignore ve dosya ağacını yalnızca gerektiğinde yinelemeli olarak geçer. Böylece dosya sistemini okumaktan ve algoritmanın boyuta bağımlılığından kurtulduk. context önemli değil.
Algoritma ayrıca izlenmeyen dosyaları da kontrol eder ve gerekirse bunları sağlama toplamında dikkate alır.
Dosyaları içe aktarırken iyileştirilmiş performans
Werf v1.1 sürümleri aşağıdaki durumlarda bir rsync sunucusu kullanır: . Daha önce içe aktarma, ana sistemden bir dizin bağlama kullanılarak iki adımda yapılıyordu.
MacOS'ta içe aktarma performansı artık Docker birimleriyle sınırlı değil ve içe aktarma işlemleri Linux ve Windows ile aynı sürede tamamlanıyor.
İçerik tabanlı etiketleme
Werf v1.1, görüntü içeriğine göre sözde etiketlemeyi destekler - içerik tabanlı etiketleme. Ortaya çıkan Docker görüntülerinin etiketleri, bu görüntülerin içeriğine bağlıdır.
Komutu çalıştırırken werf publish --tags-by-stages-signature veya werf ci-env --tagging-strategy=stages-signature sözde görüntüleri yayınlandı sahne imzası görüntü. Her görüntü, bu görüntünün aşamalarının kendi imzasıyla etiketlenir; bu, her aşamanın ayrı ayrı normal imzasıyla aynı kurallara göre hesaplanır, ancak görüntünün genel bir tanımlayıcısıdır.
Görüntü aşamalarının imzası şunlara bağlıdır:
- bu görselin içeriği;
- Bu içeriğe yol açan Git değişikliklerinin geçmişleri.
Git deposunda her zaman görüntü dosyalarının içeriğini değiştirmeyen sahte taahhütler bulunur. Örneğin, yalnızca yorum içeren taahhütler veya birleştirme taahhütleri veya Git'teki görüntüye aktarılmayacak dosyaları değiştiren taahhütler.
İçerik tabanlı etiketleme kullanıldığında, görüntünün içeriği değişmese bile görüntü adındaki değişiklikler nedeniyle Kubernetes'teki uygulama bölmelerinin gereksiz yeniden başlatılması sorunları çözülür. Bu arada, bir uygulamanın birçok mikro hizmetinin tek bir Git deposunda saklanmasını engelleyen nedenlerden biri de budur.
Ayrıca, içerik tabanlı etiketleme, Git dallarında etiketlemeden daha güvenilir bir etiketleme yöntemidir çünkü sonuçta ortaya çıkan görüntülerin içeriği, aynı dalın birden çok işlemini birleştirmek için CI sisteminde ardışık düzenlerin yürütülme sırasına bağlı değildir.
Bu çok önemli: şu andan itibaren aşama-imza - Mı önerilen tek etiketleme stratejisi. Komutta varsayılan olarak kullanılacaktır werf ci-env (açıkça farklı bir etiketleme şeması belirtmediğiniz sürece).
. Bu özelliğe ayrı bir yayın da ayrılacaktır. GÜNCELLENMİŞ (3 Nisan): Ayrıntılı makale .
Günlük seviyeleri
Kullanıcı artık çıktıyı kontrol etme, kayıt düzeyini ayarlama ve hata ayıklama bilgileriyle çalışma olanağına sahiptir. Seçenekler eklendi --log-quiet, --log-verbose, --log-debug.
Varsayılan olarak çıktı minimum bilgiyi içerir:
Ayrıntılı çıktıyı kullanırken (--log-verbose) werf'in nasıl çalıştığını görebilirsiniz:
Ayrıntılı çıktı (--log-debug), werf hata ayıklama bilgilerine ek olarak, kullanılan kitaplıkların günlüklerini de içerir. Örneğin Docker Registry ile etkileşimin nasıl gerçekleştiğini görebilir ve ayrıca önemli miktarda zaman geçirilen yerleri kaydedebilirsiniz:
Daha fazla plan
Uyarı! Aşağıda açıklanan seçenekler işaretlenmiştir v1.1 çoğu yakın gelecekte bu sürümde kullanıma sunulacak. Güncellemeler otomatik güncellemeler yoluyla gelecek . Bu özellikler v1.1 işlevlerinin kararlı kısmını etkilemez; görünümleri mevcut yapılandırmalarda manuel kullanıcı müdahalesi gerektirmez.
Çeşitli Docker Registry uygulamaları için tam destek (YENİ)
- Sürüm: v1.1
- Tarihler: Mart
Amaç, kullanıcının werf kullanırken kısıtlama olmaksızın özel bir uygulamayı kullanmasıdır.
Şu anda tam desteği garanti edeceğimiz aşağıdaki çözüm setini belirledik:
- Varsayılan (kitaplık/kayıt defteri)*,
- AWS ECR
- Azure*,
- Docker Merkezi
- GCR*,
- GitHub Paketleri
- GitLab Kayıt Defteri*,
- Liman*,
- İskele.
Şu anda werf tarafından tam olarak desteklenen çözümler bir yıldız işaretiyle işaretlenmiştir. Diğerleri için destek var ancak sınırlı.
İki ana sorun tespit edilebilir:
- Bazı çözümler Docker Registry API'sini kullanarak etiket kaldırmayı desteklemez, bu da kullanıcıların werf'in otomatik temizleme özelliğini kullanmasını engeller. Bu, AWS ECR, Docker Hub ve GitHub Paketleri için geçerlidir.
- Bazı çözümler, iç içe depolar olarak adlandırılan depoları (Docker Hub, GitHub Paketleri ve Quay) desteklemez veya desteklemez, ancak kullanıcının bunları kullanıcı arayüzünü veya API'yi (AWS ECR) kullanarak manuel olarak oluşturması gerekir.
Bunları ve diğer sorunları, çözümlerin yerel API'lerini kullanarak çözeceğiz. Bu görev aynı zamanda werf operasyonunun tüm döngüsünün her biri için testlerle kapsanmasını da içerir.
Dağıtılmış görüntü yapısı (↑)
- Sürüm: v1.2 v1.1 (bu özelliği uygulama önceliği artırıldı)
- Tarihler: Mart-Nisan Mart
Şu anda werf v1.0 ve v1.1, görüntüleri oluşturma ve yayınlama ve uygulamayı Kubernetes'e dağıtma işlemleri için yalnızca tek bir özel ana bilgisayarda kullanılabilir.
Werf'in dağıtılmış çalışma olanaklarını açmak için, Kubernetes'teki uygulamaların oluşturulması ve konuşlandırılması birkaç rastgele ana bilgisayarda başlatıldığında ve bu ana bilgisayarlar, yapılar (geçici çalıştırıcılar) arasında durumlarını kaydetmediğinde, werf'in kullanım yeteneğini uygulaması gerekir. Docker Registry'yi bir sahne mağazası olarak kullanın.
Daha önce werf projesi hala dapp olarak anılırken böyle bir fırsata sahipti. Ancak bu işlevselliği werf'te uygularken dikkate alınması gereken bir takım sorunlarla karşılaştık.
Dikkat. Bu özellik, toplayıcının Kubernetes bölmeleri içinde çalışmasını gerektirmez çünkü Bunu yapmak için, yerel Docker sunucusuna olan bağımlılıktan kurtulmanız gerekir (Kubernetes bölmesinde yerel Docker sunucusuna erişim yoktur, çünkü işlemin kendisi bir kapta çalışmaktadır ve werf desteklemiyor ve desteklemeyecektir) ağ üzerinden Docker sunucusuyla çalışma). Kubernetes'i çalıştırma desteği ayrı olarak uygulanacaktır.
GitHub Actions için resmi destek (YENİ)
- Sürüm: v1.1
- Tarihler: Mart
Werf belgelerini içerir (bölümler referans и rehberlik) ve werf ile çalışmaya yönelik resmi GitHub Eylemi.
Ayrıca Werf'in geçici koşucular üzerinde çalışmasına olanak tanıyacak.
Kullanıcının CI sistemiyle etkileşiminin mekaniği, uygulamayı oluşturmak/yayınlamak için belirli eylemleri başlatmak üzere çekme isteklerine etiket yerleştirmeye dayanacaktır.
Werf ile uygulamaların yerel geliştirilmesi ve konuşlandırılması (↓)
- Sürüm: v1.1
- Tarihler: Ocak-Şubat Nisan
Ana amaç, karmaşık eylemler olmadan, kutudan çıktığı gibi uygulamaları hem yerel olarak hem de üretimde dağıtmak için tek bir birleşik yapılandırma elde etmektir.
werf'in ayrıca uygulama kodunu düzenlemenin ve hata ayıklama için çalışan uygulamadan anında geri bildirim almanın uygun olacağı bir çalışma moduna sahip olması gerekir.
Yeni temizleme algoritması (YENİ)
- Sürüm: v1.1
- Tarihler: Nisan
Werf v1.1'in mevcut sürümünde prosedürde cleanup İçerik tabanlı etiketleme şemasında görsellerin temizlenmesine yönelik bir hüküm yoktur; bu görseller birikecektir.
Ayrıca werf'in mevcut sürümü (v1.0 ve v1.1), etiketleme şemaları altında yayınlanan görseller için farklı temizleme politikaları kullanır: Git şubesi, Git etiketi veya Git taahhüdü.
Git'teki taahhütlerin geçmişine dayalı olarak görüntüleri temizlemek için tüm etiketleme şemaları için birleştirilmiş yeni bir algoritma icat edildi:
- Her git HEAD (dallar ve etiketler) için en son N1 işlemiyle ilişkili N2 görselden fazlasını saklamayın.
- Her git HEAD (dallar ve etiketler) için en son N1 işlemiyle ilişkili N2 aşamasından fazla görüntüyü saklamayın.
- Herhangi bir Kubernetes kümesi kaynağında kullanılan tüm görüntüleri depolayın (yapılandırma dosyasının ve ad alanlarının tüm kube bağlamları taranır; bu davranışı özel seçeneklerle sınırlayabilirsiniz).
- Helm sürümlerinde kayıtlı, kaynak yapılandırma bildirimlerinde kullanılan tüm görüntüleri saklayın.
- Bir görüntü, git'teki herhangi bir HEAD ile ilişkilendirilmemişse (örneğin, ilgili HEAD'in kendisi silinmiş olduğundan) ve Kubernetes kümesindeki ve Helm sürümlerindeki herhangi bir bildirimde kullanılmamışsa silinebilir.
Paralel görüntü oluşturma (↓)
- Sürüm: v1.1
- Tarihler: Ocak-Şubat Nisan*
Werf'in mevcut sürümü, burada açıklanan görselleri ve yapıları toplar. werf.yaml, sırayla. Görüntülerin ve eserlerin bağımsız aşamalarını birleştirme sürecini paralelleştirmenin yanı sıra kullanışlı ve bilgilendirici çıktılar sağlamak gerekir.
* Not: GitHub Eylemleri ile werf kullanımının yanı sıra daha fazla yatay ölçeklendirme yeteneği ekleyecek olan dağıtılmış derlemenin uygulanmasına yönelik artan öncelik nedeniyle son tarih kaydırıldı. Paralel montaj, bir projeyi birleştirirken dikey ölçeklenebilirlik sağlayan bir sonraki optimizasyon adımıdır.
Dümen 3'e Geçiş (↓)
- Sürüm: v1.2
- Tarihler: Şubat-Mart Mayıs*
Yeni kod tabanına geçişi içerir ve mevcut kurulumları taşımanın kanıtlanmış, kullanışlı bir yolu.
* Not: Helm 3'e geçiş, werf'e önemli özellikler eklemeyecektir çünkü Helm 3'ün tüm temel özellikleri (3 yollu birleştirme ve yeke yok) zaten werf'te uygulanmıştır. Dahası, werf'in belirtilenlere ek olarak. Ancak bu geçiş planlarımızda kaldı ve hayata geçirilecek.
Kubernetes yapılandırmasını açıklamak için Jsonnet (↓)
- Sürüm: v1.2
- Tarihler: Ocak-Şubat Nisan-Mayıs
Werf, Kubernetes için Jsonnet formatındaki yapılandırma açıklamalarını destekleyecektir. Aynı zamanda werf, Helm ile uyumlu kalacak ve açıklama formatı seçeneği sunulacak.
Bunun nedeni, birçok kişiye göre Go şablonlarının giriş engelinin yüksek olması ve bu şablonların kodlarının anlaşılabilirliğinin de sorun yaşamasıdır.
Diğer Kubernetes konfigürasyon tanımlama sistemlerinin (örneğin, Özelleştirme) tanıtılması olasılığı da değerlendirilmektedir.
Kubernetes'te çalışma (↓)
- Sürüm: v1.2
- Tarihler: Nisan-Mayıs Mayıs-Haziran
Hedef: Görüntülerin oluşturulduğundan ve uygulamanın Kubernetes'teki çalıştırıcılar kullanılarak teslim edildiğinden emin olun. Onlar. Yeni görüntüler doğrudan Kubernetes bölmelerinden oluşturulabilir, yayınlanabilir, temizlenebilir ve dağıtılabilir.
Bu yeteneği uygulamak için öncelikle dağıtılmış görüntüler oluşturabilmeniz gerekir. (yukarıdaki noktaya bakın).
Ayrıca, oluşturucunun Docker sunucusu olmadan çalışma modu için destek gerektirir (ör. Kaniko benzeri yapı veya kullanıcı alanında derleme).
Werf, Kubernetes üzerinde derlemeyi yalnızca Dockerfile ile değil aynı zamanda artımlı yeniden yapılandırmalar ve Ansible ile Stapel oluşturucusu ile de destekleyecek.
Açık gelişime doğru bir adım
Toplumumuzu seviyoruz (, ) ve giderek daha fazla insanın Werf'i daha iyi hale getirmeye, ilerlediğimiz yönü anlamasına ve gelişime katılmasına yardımcı olmasını istiyoruz.
Yakın zamanda geçiş yapılmasına karar verildi. Ekibimizin çalışma sürecini ortaya çıkarmak amacıyla. Artık acil planları ve aşağıdaki alanlardaki mevcut çalışmaları görebilirsiniz:
- ;
- ;
- ;
- .
Sorunlarla ilgili pek çok çalışma yapıldı:
- İlgisiz olanlar kaldırıldı.
- Mevcut olanlar yeterli sayıda detay ve detayla tek bir formata getirilir.
- Fikir ve önerilerin yer aldığı yeni konular eklendi.
v1.1 sürümü nasıl etkinleştirilir
Sürüm şu anda şu adreste mevcuttur: (kanallarda kararlı и kaya gibi sağlam ancak stabilizasyon oluştukça sürümler görünecektir ea kendisi zaten kullanım için yeterince kararlıdır, çünkü kanallardan geçtim alfa и beta). Aktif Aşağıdaki şekilde:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Sonuç
Stapel ve Dockerfile oluşturucuları için yeni aşama depolama mimarisi ve oluşturucu optimizasyonları, werf'te dağıtılmış ve paralel yapıların uygulanması olasılığının önünü açıyor. Bu özellikler yakında aynı v1.1 sürümünde görünecek ve otomatik güncelleme mekanizması aracılığıyla otomatik olarak kullanıma sunulacaktır (kullanıcılar için) ).
Bu sürümde görsel içeriğini temel alan bir etiketleme stratejisi eklendi - içerik tabanlı etiketleme, bu varsayılan strateji haline geldi. Ana komut günlüğü de yeniden düzenlendi: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Bir sonraki önemli adım, dağıtılmış derlemeler eklemektir. Dağıtılmış derlemeler v1.0'dan bu yana paralel derlemelerden daha yüksek bir öncelik haline geldi çünkü bunlar werf'e daha fazla değer katıyor: geliştiricilerin dikey ölçeklendirilmesi ve çeşitli CI/CD sistemlerinde geçici oluşturuculara yönelik desteğin yanı sıra GitHub Eylemleri için resmi destek sağlama yeteneği . Bu nedenle paralel toplantıların uygulama tarihleri kaydırıldı. Ancak her iki ihtimali de mümkün olan en kısa sürede hayata geçirmek için çalışıyoruz.
Haberleri takip edin! Bizi ziyaret etmeyi unutmayın bir sorun oluşturmak, mevcut bir sorunu bulmak ve bir artı eklemek, bir PR oluşturmak veya yalnızca projenin gelişimini izlemek için.
PS
Blogumuzda da okuyun:
- «»
- «";
- Werf'teki yenilikler hakkında bir dizi not:
- «";
- «";
- «";
- «'.
Kaynak: habr.com