🥇Artık normal bir Docker dosyası kullanarak werf'te Docker görüntüleri oluşturabilirsiniz

Geç olsun güç olmasın. Veya uygulama görüntüleri oluşturmak için normal Dockerfiles desteğine sahip olmayarak neredeyse ciddi bir hata yaptığımızı.

hakkında konuşacağız Werf — Herhangi bir CI/CD sistemiyle entegre olan ve tüm uygulama yaşam döngüsünün yönetimini sağlayan GitOps yardımcı programı şunları sağlar:

görselleri toplayıp yayınlayın,
Kubernetes'te uygulamaları dağıtın,
özel politikalar kullanarak kullanılmayan görselleri silin.

Projenin felsefesi, düşük seviyeli araçları DevOps mühendislerine uygulamalar üzerinde kontrol sağlayan tek bir birleşik sistemde toplamaktır. Mümkünse mevcut yardımcı programlar (Helm ve Docker gibi) kullanılmalıdır. Bir sorunun çözümü yoksa bunun için gereken her şeyi oluşturabilir ve destekleyebiliriz.

Arka plan: kendi resim toplayıcınız

Werf'teki görüntü toplayıcıda olan da buydu: olağan Dockerfile bizim için yeterli değildi. Projenin geçmişine hızlı bir şekilde bakarsanız, bu problemin werf'in ilk versiyonlarında zaten ortaya çıktığını görürsünüz (daha sonra hala dapp olarak bilinir).

Docker görüntülerine uygulamalar oluşturmak için bir araç oluştururken, Dockerfile'ın bazı çok özel görevler için bizim için uygun olmadığını hemen fark ettik:

Aşağıdaki standart şemaya göre tipik küçük web uygulamaları oluşturma ihtiyacı:
- sistem çapında uygulama bağımlılıklarını yükleyin,
- bir dizi uygulama bağımlılığı kitaplığı yükleyin,
- varlıkları toplamak,
- ve en önemlisi görseldeki kodu hızlı ve verimli bir şekilde güncelleyin.
Proje dosyalarında değişiklik yapıldığında, oluşturucunun, değiştirilen dosyalara bir yama uygulayarak hızlı bir şekilde yeni bir katman oluşturması gerekir.
Belirli dosyalar değiştiyse ilgili bağımlı aşamayı yeniden oluşturmak gerekir.

Bugün koleksiyonerimizin elinde birçok başka olasılık var ama bunlar başlangıçtaki arzu ve dürtülerdi.

Genel olarak, iki kere düşünmeden kullandığımız programlama diliyle kendimizi silahlandırdık. (aşağıya bakınız) ve hayata geçirmek için yola çıktık kendi DSL'im! Hedefler doğrultusunda montaj sürecinin aşamalar halinde anlatılması ve bu aşamaların dosyalara bağımlılığının belirlenmesi amaçlandı. Ve onu tamamladım kendi koleksiyoncusu, DSL'i nihai hedefe, birleştirilmiş bir görüntüye dönüştürdü. Başlangıçta DSL Ruby'deydi ancak Golang'a geçiş — toplayıcımızın yapılandırması bir YAML dosyasında tanımlanmaya başlandı.

Ruby'de dapp için eski yapılandırma

YAML'de werf için mevcut yapılandırma

Kollektörün mekanizması da zamanla değişti. İlk başta, yapılandırmamızdan anında geçici bir Docker dosyası oluşturduk ve ardından montaj talimatlarını geçici kaplarda çalıştırmaya ve taahhüt etmeye başladık.

NB: Şu anda kendi config (YAML'de) ile çalışan ve Stapel toplayıcı olarak adlandırılan toplayıcımız oldukça güçlü bir araca dönüştü. Ayrıntılı açıklaması ayrı makaleleri hak eder ve temel ayrıntılar şurada bulunabilir: belgeleme.

Sorunun farkındalığı

Ancak bir hata yaptığımızı hemen fark ettik: Yeteneği eklemedik. standart Dockerfile aracılığıyla görüntüler oluşturun ve bunları aynı uçtan uca uygulama yönetimi altyapısına entegre edin (yani görüntüleri toplayın, dağıtın ve temizleyin). Kubernetes'te dağıtım için bir araç oluşturmak ve Dockerfile desteğini uygulamamak nasıl mümkün olabilir? Çoğu proje için görselleri tanımlamanın standart yolu nedir?

Bu soruyu cevaplamak yerine çözüm sunuyoruz. Zaten bir Docker dosyanız (veya bir dizi Docker dosyanız) varsa ve werf kullanmak istiyorsanız ne olur?

NB: Bu arada, neden werf kullanmak isteyesiniz ki? Ana özellikler aşağıdakilere inmektedir:

görüntü temizlemeyi de içeren tam uygulama yönetimi döngüsü;
tek bir yapılandırmadan aynı anda birden fazla görüntünün birleştirilmesini yönetme yeteneği;
Helm uyumlu grafikler için iyileştirilmiş dağıtım süreci.

Bunların daha kapsamlı bir listesini şu adreste bulabilirsiniz: proje sayfası.

Dolayısıyla, daha önce Dockerfile'ı yapılandırmamızda yeniden yazmayı teklif etmiş olsaydık, şimdi mutlu bir şekilde şöyle diyeceğiz: "Dockerfiles'ınızı biz oluşturalım!"

Nasıl kullanılır?

Bu özelliğin tam uygulaması sürümde yer aldı werf v1.0.3-beta.1. Genel prensip basittir: Kullanıcı, werf yapılandırmasında mevcut bir Docker dosyasının yolunu belirtir ve ardından komutu çalıştırır. werf build... işte bu kadar - werf görüntüyü bir araya getirecek. Soyut bir örneğe bakalım.

Bir sonrakini duyuralım Dockerfile proje kökünde:

FROM ubuntu:18.04
RUN echo Building ...

Ve duyuracağız werf.yamlbunu kullanan Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Tüm! Sol koşmak werf build:

Ek olarak aşağıdakileri beyan edebilirsiniz werf.yaml aynı anda farklı Docker dosyalarından birkaç görüntü oluşturmak için:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Son olarak, aşağıdaki gibi ek derleme parametrelerinin iletilmesini de destekler: --build-arg и --add-host - werf yapılandırması aracılığıyla. Dockerfile görüntü yapılandırmasının tam açıklaması şu adreste mevcuttur: dokümantasyon sayfası.

Nasıl çalışır?

Derleme işlemi sırasında Docker işlevlerindeki yerel katmanların standart önbelleği. Ancak önemli olan werf'in aynı zamanda Dockerfile yapılandırmasını altyapısına entegre eder. Bu ne anlama gelir?

Docker dosyasından oluşturulan her görüntü, adı verilen bir aşamadan oluşur. dockerfile (werf'te hangi aşamaların olduğu hakkında daha fazla bilgi edinebilirsiniz burada).
Sahne için dockerfile werf, Dockerfile yapılandırmasının içeriğine bağlı bir imza hesaplar. Dockerfile yapılandırması değiştiğinde aşama imzası da değişir dockerfile ve werf, yeni bir Dockerfile yapılandırmasıyla bu aşamanın yeniden oluşturulmasını başlatır. İmza değişmezse werf görüntüyü önbellekten alır (Werf'te imzaların kullanımına ilişkin daha fazla ayrıntı şurada açıklanmıştır: bu rapor).
Daha sonra toplanan görseller şu komutla yayınlanabilir: werf publish (ya werf build-and-publish) ve bunu Kubernetes'e dağıtım için kullanın. Docker Kayıt Defterinde yayınlanan görseller standart werf temizleme araçları kullanılarak temizlenecektir; Eski görseller (N günden eski), var olmayan Git şubeleriyle ilişkili görseller ve diğer politikalar otomatik olarak temizlenecektir.

Burada açıklanan noktalarla ilgili daha fazla ayrıntıyı belgelerde bulabilirsiniz:

Notlar ve önlemler

1. Harici URL ADD'de desteklenmiyor

Şu anda bir yönergede harici bir URL'nin kullanılması desteklenmemektedir ADD. Werf, belirtilen URL'deki kaynak değiştiğinde yeniden oluşturma işlemini başlatmayacaktır. Bu özelliği yakında eklemeyi planlıyoruz.

2. Resme .git ekleyemezsiniz

Genel olarak konuşursak, bir dizin ekleme .git resimde - çok kötü bir uygulama ve işte nedeni:

Eğer .git son görüntüde kalıyor, bu ilkeleri ihlal ediyor 12 faktörlü uygulama: Nihai görüntünün tek bir işleme bağlanması gerektiğinden, bunu yapmak mümkün olmamalıdır. git checkout keyfi taahhüt.
.git görüntünün boyutunu artırır (büyük dosyaların bir zamanlar eklenip daha sonra silinmesi nedeniyle depo büyük olabilir). Yalnızca belirli bir taahhütle ilişkilendirilen çalışma ağacının boyutu Git'teki işlem geçmişine bağlı olmayacaktır. Bu durumda ekleme ve çıkarma işlemi .git son görüntüden çalışmaz: görüntü yine de ekstra bir katman elde eder - Docker bu şekilde çalışır.
Docker, aynı taahhüt oluşturuluyor olsa bile farklı çalışma ağaçlarından gereksiz bir yeniden oluşturma başlatabilir. Örneğin GitLab, ayrı klonlanmış dizinler oluşturur. /home/gitlab-runner/builds/HASH/[0-N]/yourproject paralel montaj etkinleştirildiğinde. Ekstra yeniden birleştirme, dizinin .git aynı taahhüt oluşturulmuş olsa bile, aynı havuzun farklı klonlanmış sürümlerinde farklıdır.

Werf kullanılırken son noktanın da sonuçları vardır. Werf, bazı komutları çalıştırırken yerleşik önbelleğin mevcut olmasını gerektirir (örn. werf deploy). Bu komutlar çalıştırıldığında werf, belirtilen görüntüler için aşama imzalarını hesaplar. werf.yamlve derleme önbelleğinde olmaları gerekir - aksi takdirde komut çalışmaya devam edemeyecek. Aşama imzası içeriğe bağlıysa .git, ilgisiz dosyalardaki değişikliklere karşı kararsız bir önbellek elde ederiz ve werf böyle bir gözetimi affedemez (daha fazla ayrıntı için bkz. belgeleme).

Genel olarak, yalnızca belirli gerekli dosyaları ekleme talimatlar aracılığıyla ADD her durumda yazılının verimliliğini ve güvenilirliğini artırır Dockerfileve ayrıca bunun için toplanan önbelleğin kararlılığını da artırır DockerfileGit'teki alakasız değişikliklere.

sonuç

Belirli ihtiyaçlar için kendi oluşturucumuzu yazmaya yönelik ilk yolumuz zor, dürüst ve basitti: Standart Dockerfile'ın üzerinde koltuk değneği kullanmak yerine çözümümüzü özel sözdizimiyle yazdık. Bunun da avantajları vardı: Stapel koleksiyoncusu göreviyle mükemmel bir şekilde başa çıkıyor.

Ancak kendi oluşturucumuzu yazma sürecinde mevcut Dockerfiles desteğini gözden kaçırdık. Bu kusur artık düzeltildi ve gelecekte dağıtılmış montaj ve Kubernetes kullanan montaj (yani kaniko'da yapıldığı gibi Kubernetes içindeki koşucularda montaj) için özel Stapel oluşturucumuzla birlikte Dockerfile desteğini geliştirmeyi planlıyoruz.

Yani, birdenbire ortalıkta birkaç Docker dosyası varsa... Denemek Werf!

PS Konuyla ilgili belgelerin listesi

Blogumuzda da okuyun: “werf - Kubernetes'te CI / CD aracımız (genel bakış ve video raporu)'.

Kaynak: habr.com

Artık normal bir Dockerfile kullanarak Werf'te Docker görüntüleri oluşturabilirsiniz.