Gec olsun, güc olsun. Yaxud tətbiq şəkilləri yaratmaq üçün adi Dockerfiles dəstəyinə malik olmamaqla az qala ciddi səhvə yol vermişik.
haqqında danışacağıq — İstənilən CI/CD sistemi ilə inteqrasiya edən və bütün tətbiqin həyat dövrünün idarə edilməsini təmin edən GitOps yardım proqramı:
- şəkilləri toplamaq və dərc etmək,
- Kubernetes-də tətbiqləri yerləşdirmək,
- xüsusi siyasətlərdən istifadə edərək istifadə olunmamış şəkilləri silin.
Layihənin fəlsəfəsi DevOps mühəndislərinə tətbiqlər üzərində nəzarət imkanı verən aşağı səviyyəli alətləri vahid vahid sistemdə toplamaqdan ibarətdir. Mümkünsə, mövcud yardım proqramlarından (Helm və Docker kimi) istifadə edilməlidir. Problemin həlli yoxdursa, bunun üçün lazım olan hər şeyi yarada və dəstəkləyə bilərik.
Fon: öz şəkil kollektorunuz
Werf-də şəkil toplayıcı ilə belə oldu: adi Dockerfile bizim üçün kifayət deyildi. Layihənin tarixinə qısa nəzər salsanız, bu problem artıq werf-in ilk versiyalarında ortaya çıxdı (sonra hələ də ).
Docker şəkillərində tətbiqlər yaratmaq üçün alət yaratarkən biz tez başa düşdük ki, Dockerfile bəzi çox xüsusi tapşırıqlar üçün bizim üçün uyğun deyil:
- Aşağıdakı standart sxemə uyğun olaraq tipik kiçik veb proqramların qurulması ehtiyacı:
- sistem miqyasında tətbiq asılılıqlarını quraşdırın,
- proqram asılılığı kitabxanaları paketini quraşdırın,
- aktivləri toplamaq,
- və ən əsası, şəkildəki kodu tez və effektiv şəkildə yeniləyin.
- Layihə fayllarına dəyişikliklər edildikdə, qurucu dəyişdirilmiş fayllara yamaq tətbiq etməklə tez bir zamanda yeni təbəqə yaratmalıdır.
- Müəyyən fayllar dəyişibsə, müvafiq asılı mərhələni yenidən qurmaq lazımdır.
Bu gün kollektorumuzun bir çox başqa imkanları var, lakin bunlar ilkin istəklər və çağırışlar idi.
Ümumiyyətlə, iki dəfə düşünmədən istifadə etdiyimiz proqramlaşdırma dili ilə silahlandıq (aşağıya bax) və həyata keçirmək üçün yola çıxdı öz DSL! Məqsədlərə uyğun olaraq, montaj prosesini mərhələlərlə təsvir etmək və bu mərhələlərin fayllardan asılılıqlarını müəyyən etmək nəzərdə tutulmuşdur. Və onu tamamladı öz kolleksiyaçısı, DSL-ni son məqsədə çevirən - yığılmış bir görüntü. Əvvəlcə DSL Ruby-də idi, lakin olduğu kimi — kollektorumuzun konfiqurasiyası YAML faylında təsvir olunmağa başladı.
Ruby-də dapp üçün köhnə konfiqurasiya
YAML-də werf üçün cari konfiqurasiya
Zamanla kollektorun mexanizmi də dəyişdi. Əvvəlcə biz konfiqurasiyamızdan tez bir zamanda müvəqqəti Dockerfile yaratdıq, sonra isə müvəqqəti konteynerlərdə montaj təlimatlarını işə salmağa və öhdəliyi yerinə yetirməyə başladıq.
NB: Hazırda öz konfiqurasiyası ilə işləyən (YAML-də) və Stapel kollektoru adlanan kollektorumuz artıq kifayət qədər güclü alətə çevrilmişdir. Onun ətraflı təsviri ayrı məqalələrə layiqdir və əsas təfərrüatları burada tapa bilərsiniz .
Problem haqqında məlumatlılıq
Ancaq bir səhv etdiyimizi dərhal deyil, anladıq: bacarığı əlavə etmədik standart Dockerfile vasitəsilə şəkillər yaradın və onları eyni uçdan-uca tətbiq idarəetmə infrastrukturuna inteqrasiya edin (məsələn, şəkilləri toplayın, yerləşdirin və təmizləyin). Kubernetes-də yerləşdirmə üçün bir alət hazırlamaq və Dockerfile dəstəyini həyata keçirməmək necə mümkün ola bilər, yəni. Əksər layihələr üçün şəkilləri təsvir etmək üçün standart üsul?
Bu suala cavab vermək əvəzinə, bir həll təklif edirik. Əgər sizdə artıq Dockerfile (və ya bir sıra Dockerfiles) varsa və werf-dən istifadə etmək istəyirsinizsə nə etməli?
NB: Yeri gəlmişkən, niyə werf-dən istifadə etmək istərdiniz? Əsas xüsusiyyətlər aşağıdakılara aiddir:
- təsvirin təmizlənməsi daxil olmaqla tam proqram idarəetmə dövrü;
- bir konfiqurasiyadan eyni anda bir neçə təsvirin yığılmasını idarə etmək imkanı;
- Helm uyğun diaqramlar üçün təkmilləşdirilmiş yerləşdirmə prosesi.
Onların daha tam siyahısını burada tapa bilərsiniz .
Beləliklə, əgər əvvəllər biz konfiqurasiyamızda Dockerfile-ni yenidən yazmağı təklif edərdiksə, indi məmnuniyyətlə deyəcəyik: "Qoy werf öz Dockerfilesinizi qursun!"
Necə istifadə etmək olar?
Bu xüsusiyyətin tam tətbiqi buraxılışda ortaya çıxdı . Ümumi prinsip sadədir: istifadəçi werf konfiqurasiyasında mövcud Dockerfile yolunu müəyyən edir və sonra əmri icra edir. werf build... və budur - werf təsviri yığacaq. Mücərrəd bir nümunəyə baxaq.
Növbətini elan edək Dockerfile layihə kökündə:
FROM ubuntu:18.04
RUN echo Building ...
Və elan edəcəyik werf.yamlbundan istifadə edən Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Hamısı! Sol qaçmaq werf build:
Bundan əlavə, aşağıdakıları elan edə bilərsiniz werf.yaml eyni anda müxtəlif Docker fayllarından bir neçə şəkil yaratmaq üçün:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Nəhayət, o, həmçinin əlavə qurma parametrlərinin keçməsini dəstəkləyir, məsələn --build-arg и --add-host - werf konfiqurasiyası vasitəsilə. Dockerfile şəkil konfiqurasiyasının tam təsviri burada mövcuddur .
Necə işləyir?
Quraşdırma prosesi zamanı Docker-də yerli təbəqələrin standart keşi işləyir. Ancaq vacib olan odur ki, o da var Dockerfile konfiqurasiyasını öz infrastrukturuna inteqrasiya edir. Bu nə deməkdir?
- Dockerfile-dən qurulan hər bir şəkil adlı bir mərhələdən ibarətdir
dockerfile(werf-də hansı mərhələlər olduğu haqqında daha çox oxuya bilərsiniz ). - Səhnə üçün
dockerfilewerf Dockerfile konfiqurasiyasının məzmunundan asılı olan imza hesablayır. Dockerfile konfiqurasiyası dəyişdikdə mərhələ imzası dəyişirdockerfilevə werf yeni Dockerfile konfiqurasiyası ilə bu mərhələnin yenidən qurulmasına başlayır. İmza dəyişməzsə, o zaman werf şəkli keşdən götürür (werf-də imzaların istifadəsi haqqında daha ətraflı məlumat burada təsvir edilmişdir ). - Sonra, toplanmış şəkillər komanda ilə dərc edilə bilər
werf publish(Və yawerf build-and-publish) və onu Kubernetes-ə yerləşdirmək üçün istifadə edin. Docker Registry-də dərc edilmiş şəkillər standart werf təmizləmə alətlərindən istifadə etməklə təmizlənəcək, yəni. Köhnə şəkillər (N gündən köhnə), mövcud olmayan Git filialları ilə əlaqəli şəkillər və digər siyasətlər avtomatik olaraq təmizlənəcək.
Burada təsvir olunan məqamlar haqqında ətraflı məlumatı sənədlərdə tapa bilərsiniz:
- ;
- ;
- .
Qeydlər və ehtiyat tədbirləri
1. Xarici URL ADD-də dəstəklənmir
Hazırda direktivdə xarici URL istifadə etmək dəstəklənmir ADD. Göstərilən URL-də resurs dəyişdikdə Werf yenidən qurmağa başlamayacaq. Bu funksiyanı tezliklə əlavə etməyi planlaşdırırıq.
2. Şəkilə .git əlavə edə bilməzsiniz
Ümumiyyətlə, bir kataloq əlavə etmək .git Şəkildə - pis bir pis təcrübə və bunun səbəbi:
- Əgər
.gitson imicdə qalır, bu, prinsipləri pozur : Son şəkil tək bir öhdəliyə bağlanmalı olduğundan, bunu etmək mümkün olmamalıdırgit checkoutixtiyari öhdəlik. -
.gitşəklin ölçüsünü artırır (bir dəfə ona böyük faylların əlavə edildiyi və sonra silindiyinə görə depo böyük ola bilər). Yalnız müəyyən bir öhdəlik ilə əlaqəli iş ağacının ölçüsü Git-dəki əməliyyatların tarixindən asılı olmayacaq. Bu vəziyyətdə əlavə və sonrakı çıxarılması.gitson görüntüdən işləməyəcək: şəkil hələ də əlavə təbəqə əldə edəcək - Docker belə işləyir. - Docker lazımsız yenidənqurmaya başlaya bilər, hətta eyni öhdəliyin tikildiyi halda, lakin müxtəlif iş ağaclarından. Məsələn, GitLab ayrı-ayrı klonlanmış qovluqlar yaradır
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectparalel montaj aktiv olduqda. Əlavə yenidən montaj kataloq olması ilə əlaqədar olacaq.giteyni öhdəliyin qurulduğu halda belə, eyni deponun müxtəlif klonlanmış versiyalarında fərqlidir.
Sonuncu nöqtə də werf istifadə edərkən nəticələrə malikdir. Werf bəzi əmrləri yerinə yetirərkən qurulmuş önbelleğin mövcud olmasını tələb edir (məsələn. werf deploy). Bu əmrlər işə salındıqda, werf göstərilən şəkillər üçün mərhələ imzalarını hesablayır werf.yaml, və onlar montaj keşində olmalıdır - əks halda əmr işləməyə davam edə bilməyəcək. Səhnə imzası məzmundan asılıdırsa .git, onda biz əlaqəsiz fayllardakı dəyişikliklərə qarşı qeyri-sabit bir keş alırıq və werf belə bir nəzarəti bağışlaya bilməyəcək (ətraflı məlumat üçün bax. ).
Ümumiyyətlə, yalnız müəyyən zəruri faylların əlavə edilməsi təlimatlar vasitəsilə ADD istənilən halda yazının səmərəliliyini və etibarlılığını artırır Dockerfile, həm də bunun üçün toplanmış önbelleğin sabitliyini yaxşılaşdırır Dockerfile, Git-də əhəmiyyətsiz dəyişikliklərə.
Ümumi
Xüsusi ehtiyaclar üçün öz qurucusumuzu yazmaq üçün ilkin yolumuz çətin, dürüst və sadə idi: standart Dockerfile üzərində qoltuqaltılardan istifadə etmək əvəzinə, həllimizi xüsusi sintaksislə yazdıq. Bunun da öz üstünlükləri var idi: Stapel kollektoru öz vəzifəsinin öhdəsindən mükəmməl gəlir.
Bununla belə, öz qurucumuzu yazarkən mövcud Dockerfiles dəstəyini gözdən qaçırdıq. Bu qüsur indi aradan qaldırıldı və gələcəkdə biz paylanmış quruluşlar və Kubernetes-dən istifadə edən konstruksiyalar (yəni, kanikoda olduğu kimi Kubernetes daxilindəki qaçışçılar üzərində qurulur) üçün xüsusi Stapel qurucusumuzla birlikdə Dockerfile dəstəyini inkişaf etdirməyi planlaşdırırıq.
Beləliklə, birdən ətrafınızda bir neçə Docker faylı varsa... cəhd edin !
PS Mövzu ilə bağlı sənədlərin siyahısı
- ;
- ;
- ;
- ;
- ;
- ;
- .
Bloqumuzda da oxuyun: ".
Mənbə: www.habr.com