werf - Kubernetes-də CI / CD üçün alətimiz (baxış və video hesabat)

Mayın 27-də festival çərçivəsində keçirilən DevOpsConf 2019 konfransının əsas zalında RIT++ 2019, "Daimi Çatdırılma" bölməsinin bir hissəsi olaraq "werf - Kubernetes-də CI/CD üçün alətimiz" hesabatı verildi. Bunlardan danışır Kubernetes-ə yerləşdirərkən hər kəsin qarşılaşdığı problemlər və çətinliklər, həmçinin dərhal nəzərə çarpmayan nüanslar haqqında. Mümkün həlləri təhlil edərək, bunun Açıq Mənbə alətində necə həyata keçirildiyini göstəririk werf.

Təqdimatdan bəri kommunal proqramımız (əvvəllər dapp kimi tanınır) tarixi bir mərhələyə çatmışdır. GitHub-da 1000 ulduz — ümid edirik ki, onun artan istifadəçilər icması bir çox DevOps mühəndislərinin həyatını asanlaşdıracaq.

Beləliklə, tanış edək məruzə ilə video (~47 dəqiqə, məqalədən daha çox məlumatlandırıcı) və ondan mətn şəklində əsas çıxarış. Get!

Kubernetes-ə kod çatdırılır

Söhbət artıq werf haqqında deyil, Kubernetes-də CI/CD haqqında olacaq, bu da proqramımızın Docker konteynerlərində qablaşdırıldığını nəzərdə tutur. (Mən bu barədə danışdım 2016 hesabat), və K8-lər onu istehsalda işə salmaq üçün istifadə olunacaq (bu barədə ətraflı 2017 il).

Kubernetesdə çatdırılma necə görünür?

• Kodu və onun qurulması üçün təlimatları olan bir Git deposu var. Tətbiq Docker şəklinə quraşdırılıb və Docker Registry-də dərc olunub.
• Eyni repozitoriyada tətbiqin necə yerləşdirilməsi və işə salınması ilə bağlı təlimatlar da var. Yerləşdirmə mərhələsində bu təlimatlar reyestrdən istədiyiniz şəkli alan və işə salan Kubernetes-ə göndərilir.
• Üstəlik, adətən testlər var. Bunlardan bəziləri şəkil dərc edərkən edilə bilər. Siz həmçinin (eyni təlimatlara əməl etməklə) proqramın bir nüsxəsini (ayrıca K8s ad məkanında və ya ayrıca klasterdə) yerləşdirə və orada testlər keçirə bilərsiniz.
• Nəhayət, sizə Git-dən hadisələri qəbul edən (və ya düymə klikləri) və bütün təyin olunmuş mərhələləri çağıran CI sisteminə ehtiyacınız var: qurmaq, dərc etmək, yerləşdirmək, sınaqdan keçirmək.

Burada bir neçə vacib qeyd var:

1. Çünki bizim dəyişməz infrastrukturumuz var (dəyişməz infrastruktur), bütün mərhələlərdə istifadə olunan tətbiq şəkli (səhnələşdirmə, istehsal və s.), biri olmalıdır. Bu barədə daha ətraflı və misallarla danışdım. burada.
2. Çünki biz kod yanaşması olaraq infrastrukturu izləyirik (IaC), proqram kodu, onun yığılması və işə salınması üçün təlimatlar olmalıdır tam bir depoda. Bu barədə ətraflı məlumat üçün baxın eyni hesabat.
3. Çatdırılma zənciri (çatdırılma) biz bunu adətən belə görürük: proqram yığılıb, sınaqdan keçirilib, buraxılıb (buraxılış mərhələsi) və budur - çatdırılma baş verdi. Ancaq əslində, istifadəçi təqdim etdiyiniz şeyi alır, heç bir sonra istehsalata təhvil verəndə və o ora gedə biləndə və bu istehsal işlədi. Beləliklə, çatdırılma zəncirinin bitdiyinə inanıram yalnız əməliyyat mərhələsində (qaçış), və ya daha doğrusu, kodun istehsaldan çıxarıldığı anda (onu yenisi ilə əvəz etməklə).

Kubernetesdə yuxarıda göstərilən çatdırılma sxeminə qayıdaq: o, təkcə bizim tərəfimizdən deyil, sözün əsl mənasında bu problemlə məşğul olan hər kəs tərəfindən icad edilmişdir. Əslində, bu model indi GitOps adlanır (termin və onun arxasında duran fikirlər haqqında daha çox oxuya bilərsiniz burada). Sxemin mərhələlərinə nəzər salaq.

Quraşdırma mərhələsi

Deyəsən, 2019-cu ildə hər kəs Dockerfiles yazmağı və işlətməyi bildiyi zaman Docker şəkillərinin yaradılması haqqında danışa bilərsiniz. docker build?.. Diqqət yetirmək istədiyim nüanslar bunlardır:

1. Şəkil çəkisi vacibdir, ona görə də istifadə edin çoxmərhələliŞəkildə yalnız əməliyyat üçün həqiqətən zəruri olan tətbiqi tərk etmək.
2. Qatların sayı zəncirlərini birləşdirərək minimuma endirmək lazımdır RUN-mənasına görə əmrlər.
3. Bununla belə, bu problemlər əlavə edir sazlama, çünki montaj qəzaya uğradıqda, problemə səbəb olan zəncirdən düzgün əmri tapmalısınız.
4. Montaj sürəti vacibdir, çünki biz dəyişiklikləri tez bir zamanda yaymaq və nəticələri görmək istəyirik. Məsələn, hər dəfə proqram quranda dil kitabxanalarında asılılıqları yenidən qurmaq istəmirsiniz.
5. Tez-tez sizə lazım olan bir Git deposundan çoxlu şəkillər, bir sıra Dockerfiles (və ya bir faylda adlandırılmış mərhələlər) və onların ardıcıl montajı ilə Bash skripti ilə həll edilə bilər.

Bu, hər kəsin üzləşdiyi aysberqin görünən hissəsi idi. Ancaq başqa problemlər var, xüsusən:

1. Tez-tez montaj mərhələsində bizə bir şey lazımdır montaj (məsələn, üçüncü tərəf kataloqunda apt kimi bir əmrin nəticəsini keş edin).
2. Biz istəyirik Yoxdur shell-də yazmaq əvəzinə.
3. Biz istəyirik Docker olmadan qurun (bizim konteynerləri işlədə biləcəyimiz Kubernetes klasterimiz olduğu halda, bunun üçün hər şeyi konfiqurasiya etməmiz lazım olan əlavə virtual maşın niyə lazımdır?).
4. Paralel montaj, müxtəlif yollarla başa düşülə bilən: Dockerfile-dən fərqli əmrlər (əgər çox mərhələli istifadə olunursa), eyni deponun bir neçə öhdəliyi, bir neçə Dockerfile.
5. Paylanmış montaj: Biz "efemer" olan şeyləri podlarda toplamaq istəyirik, çünki onların önbelleği yox olur, yəni ayrı bir yerdə saxlanılmalıdır.
6. Nəhayət, arzuların zirvəsini adlandırdım avtomatik sehrli: Anbara getmək, bəzi əmrləri daxil etmək və necə və nəyi düzgün etmək lazım olduğunu başa düşərək yığılmış hazır bir şəkil əldə etmək ideal olardı. Ancaq şəxsən mən əmin deyiləm ki, bütün nüansları bu şəkildə proqnozlaşdırmaq olar.

Və burada layihələr:

• moby/buildkit — bütün bu problemləri həll etməyə çalışan Docker Inc-dən inşaatçı (artıq Docker-in cari versiyalarına inteqrasiya olunub);
• kaniko — Docker olmadan qurmağa imkan verən Google-dan inşaatçı;
• Buildpacks.io — CNCF-nin avtomatik sehr etmək cəhdi və xüsusən də təbəqələr üçün rebase ilə maraqlı bir həll;
• və bir sıra digər kommunal xidmətlər, məsələn qurmaq, orijinal alətlər/img...

...və görün onların GitHub-da nə qədər ulduzu var. Yəni bir tərəfdən docker build mövcuddur və bir şey edə bilər, amma reallıqda məsələ tam həll olunmur - buna sübut alternativ kollektorların paralel inkişafıdır, hər biri problemlərin müəyyən hissəsini həll edir.

werf-də montaj

Beləliklə, biz var werf (əvvəllər məşhurdur dapp kimi) — Uzun illərdir hazırladığımız Flant şirkətindən açıq mənbə proqramı. Hamısı 5 il əvvəl Dockerfiles-in yığılmasını optimallaşdıran Bash skriptləri ilə başladı və son 3 il ərzində tam hüquqlu inkişaf öz Git deposu olan bir layihə çərçivəsində həyata keçirildi. (əvvəlcə Ruby-də, sonra yenidən yazılmışdır getmək və eyni zamanda adı dəyişdirildi). werf-də hansı montaj məsələləri həll olunur?

Mavi rənglə çalınan problemlər artıq həyata keçirilib, paralel qurma eyni host daxilində aparılıb və sarı rənglə vurğulanan məsələlərin yayın sonunadək başa çatdırılması planlaşdırılır.

Reyestrdə dərc olunma mərhələsi (nəşr et)

Zəng etdik docker push... - reyestrə şəkil yükləmək nə çətin ola bilər? Və sonra sual yaranır: "Şəklin üzərinə hansı etiketi qoymalıyam?" Bizdə olan səbəbdən yaranır Gitflow (və ya digər Git strategiyası) və Kubernetes və sənaye Kubernetes-də baş verənlərin Git-də baş verənlərdən sonra olmasını təmin etməyə çalışır. Axı Git bizim yeganə həqiqət mənbəyimizdir.

Bunun nə çətinliyi var? Təkrarlanma qabiliyyətini təmin edin: təbiətdə dəyişməz olan Git-də bir öhdəlikdən (dəyişməz), eyni saxlanmalı olan Docker şəklinə.

Bizim üçün də vacibdir mənşəyi müəyyən etmək, çünki biz Kubernetes-də işləyən tətbiqin hansı öhdəliyindən qurulduğunu başa düşmək istəyirik (sonra fərqlər və oxşar şeylər edə bilərik).

Etiketləmə Strategiyaları

Birincisi sadədir git tag. kimi etiketlənmiş bir şəkil ilə bir reyestrimiz var 1.0. Kubernetes bu şəklin yükləndiyi səhnə və istehsala malikdir. Git-də biz öhdəliklər götürürük və bir nöqtədə etiketləyirik 2.0. Biz onu anbardan verilən təlimatlara uyğun olaraq toplayırıq və etiketlə reyestrdə yerləşdiririk 2.0. Biz onu səhnəyə və hər şey qaydasındadırsa, istehsala təqdim edirik.

Bu yanaşma ilə bağlı problem ondadır ki, biz əvvəlcə etiketi qoyduq və yalnız sonra onu sınaqdan keçirdik və yaydıq. Niyə? Birincisi, bu, sadəcə olaraq məntiqsizdir: proqram təminatının hələ sınaqdan keçirmədiyimiz bir versiyasını veririk (başqa cür edə bilmərik, çünki yoxlamaq üçün etiket qoymalıyıq). İkincisi, bu yol Gitflow ilə uyğun gəlmir.

İkinci seçim - git commit + tag. Usta filialın etiketi var 1.0; bunun üçün reyestrdə - istehsala yerləşdirilən bir şəkil. Bundan əlavə, Kubernetes klasterində ilkin baxış və səhnə konturları var. Sonra Gitflow-u izləyirik: inkişaf üçün əsas filialda (develop) biz identifikatorla nəticələnən yeni funksiyalar edirik #c1. Biz onu toplayırıq və bu identifikatordan istifadə edərək reyestrdə dərc edirik (#c1). Eyni identifikatorla biz önizləmə üçün təqdim edirik. Biz öhdəliklərlə də eyni şeyi edirik #c2 и #c3.

Kifayət qədər xüsusiyyətlərin olduğunu başa düşdükdə hər şeyi sabitləşdirməyə başlayırıq. Git-də filial yaradın release_1.1 (əsas üzərində #c3 haqqında develop). Bu buraxılışı toplamağa ehtiyac yoxdur, çünki... bu əvvəlki addımda edildi. Buna görə də, biz onu sadəcə olaraq səhnəyə çıxara bilərik. Daxil olan səhvləri düzəldirik #c4 və eyni şəkildə səhnələşdirməyə keçin. Eyni zamanda, inkişaf da davam edir develop, dəyişikliklərin vaxtaşırı götürüldüyü yer release_1.1. Müəyyən bir nöqtədə, tərtib edilmiş və səhnələşdirməyə yüklənmiş bir öhdəlik alırıq, bundan məmnunuq (#c25).

Sonra buraxma budağını (sürətlə irəliləyərək) birləşdiririk (release_1.1) ustadda. Bu öhdəliyə yeni versiya ilə etiket qoyduq (1.1). Lakin bu şəkil artıq reyestrdə toplanıb, ona görə də onu bir daha toplamamaq üçün sadəcə olaraq mövcud şəklə ikinci teq əlavə edirik (indi onun reyestrdə etiketləri var) #c25 и 1.1). Bundan sonra onu istehsala yayırıq.

Səhnəyə yalnız bir şəklin yüklənməsinin bir çatışmazlığı var (#c25) və istehsalda bir növ fərqlidir (1.1), lakin biz bilirik ki, “fiziki” bunlar reyestrdən eyni görüntüdür.

Əsl çatışmazlıq odur ki, birləşmə öhdəliyi üçün dəstək yoxdur, siz sürətli irəliləməlisiniz.

Biz daha da irəli gedə və hiylə edə bilərik... Gəlin sadə Dockerfile nümunəsinə baxaq:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Ondan aşağıdakı prinsipə uyğun bir fayl quraq:

• İstifadə olunan şəkillərin identifikatorlarından SHA256 (ruby:2.3 и nginx:alpine), onların məzmununun yoxlama cəmidir;
• bütün komandalar (RUN, CMD və s.);
• Əlavə edilmiş fayllardan SHA256.

... və belə bir fayldan yoxlama məbləğini (yenidən SHA256) götürün. Bu imza Docker təsvirinin məzmununu müəyyən edən hər şey.

Diaqrama qayıdaq və öhdəlik yerinə belə imzalardan istifadə edəcəyik, yəni. şəkilləri imza ilə etiketləyin.

İndi, məsələn, buraxılışdan masterə dəyişiklikləri birləşdirmək lazım olduqda, biz real birləşmə öhdəliyi edə bilərik: onun fərqli identifikatoru olacaq, lakin eyni imza. Eyni identifikatorla biz təsviri istehsala yayacağıq.

Dezavantaj ondan ibarətdir ki, indi hansı növ öhdəliklərin istehsala sövq edildiyini müəyyən etmək mümkün olmayacaq - yoxlama məbləğləri yalnız bir istiqamətdə işləyir. Bu problem metadata ilə əlavə bir təbəqə ilə həll olunur - daha sonra sizə daha ətraflı məlumat verəcəyəm.

werf-də etiketləmə

werf-də biz daha da irəli getdik və bir maşında saxlanmayan bir keş ilə paylanmış quruluş etməyə hazırlaşırıq... Beləliklə, biz iki növ Docker təsviri qururuq, biz onları adlandırırıq. mərhələ и təsvir.

werf Git repozitoriyası quruluşun müxtəlif mərhələlərini təsvir edən xüsusi təlimatları saxlayır (quraşdırmadan əvvəl, qurmaq, Quraşdırmadan əvvəl, quraşdırma). Birinci mərhələ şəklini ilk addımların yoxlama məbləği kimi müəyyən edilmiş imza ilə toplayırıq. Sonra mənbə kodunu əlavə edirik, yeni səhnə təsviri üçün onun yoxlama məbləğini hesablayırıq... Bu əməliyyatlar bütün mərhələlər üçün təkrarlanır, nəticədə səhnə təsvirləri toplusunu alırıq. Sonra mənşəyi haqqında metadata ehtiva edən son təsviri edirik. Və biz bu şəkli müxtəlif yollarla etiketləyirik (təfsilatlar sonra).

Tutaq ki, bundan sonra yalnız proqram kodunun dəyişdirildiyi yeni bir öhdəlik görünür. Nə olacaq? Kod dəyişiklikləri üçün yamaq yaradılacaq və yeni səhnə şəkli hazırlanacaq. Onun imzası köhnə səhnə şəklinin və yeni yamağın yoxlama cəmi kimi müəyyən ediləcək. Bu şəkildən yeni yekun görüntü formalaşacaq. Oxşar davranış digər mərhələlərdəki dəyişikliklərlə də baş verəcəkdir.

Beləliklə, səhnə şəkilləri paylanmış şəkildə saxlanıla bilən bir keşdir və ondan artıq yaradılmış şəkillər Docker Registry-ə yüklənir.

Reyestrinin təmizlənməsi

Silinmiş etiketlərdən sonra asılı qalan təbəqələrin silinməsindən danışmırıq - bu, Docker Registry-nin özünün standart xüsusiyyətidir. Çoxlu Docker teqlərinin yığıldığı bir vəziyyətdən danışırıq və başa düşürük ki, onlardan bəzilərinə artıq ehtiyacımız yoxdur, lakin onlar yer tutur (və/yaxud biz bunun üçün ödəyirik).

Təmizləmə strategiyaları hansılardır?

1. Sadəcə heç nə edə bilməzsən təmizləməyin. Bəzən əlavə yer üçün bir az pul ödəmək nəhəng etiketlər dolaşıqlığını açmaqdan daha asandır. Ancaq bu yalnız müəyyən bir nöqtəyə qədər işləyir.
2. Tam sıfırlama. Bütün şəkilləri silsəniz və yalnız CI sistemində mövcud olanları yenidən qursanız, problem yarana bilər. Konteyner istehsalda yenidən işə salınarsa, onun üçün yeni bir şəkil yüklənəcək - hələ heç kim tərəfindən sınaqdan keçirilməmiş bir şəkil. Bu, dəyişməz infrastruktur ideyasını öldürür.
3. Mavi yaşıl. Bir reyestr daşmağa başladı - şəkilləri digərinə yükləyirik. Əvvəlki üsulla eyni problem: daşmağa başlayan reyestri hansı anda təmizləyə bilərsiniz?
4. Zamanla. 1 aydan köhnə bütün şəkillər silinsin? Amma bir aydır ki, yenilənməmiş xidmət mütləq olacaq...
5. Əllə artıq nəyin silinə biləcəyini müəyyənləşdirin.

İki həqiqətən uyğun variant var: təmizləməyin və ya mavi-yaşılın birləşməsi + əl ilə. Sonuncu vəziyyətdə, aşağıdakılardan danışırıq: reyestri təmizləməyin vaxtının gəldiyini başa düşdükdə, yenisini yaradırsınız və məsələn, bir ay ərzində bütün yeni şəkilləri ona əlavə edirsiniz. Bir aydan sonra Kubernetesdəki hansı podların hələ də köhnə reyestrdən istifadə etdiyinə baxın və onları da yeni reyestrə köçürün.

Nəyə gəldik werf? Biz toplayırıq:

1. Git rəhbəri: bütün teqlər, bütün filiallar - şəkillərdə Git-də qeyd olunan hər şeyə ehtiyacımız olduğunu fərz etsək (və əgər yoxsa, onu Git-in özündə silməliyik);
2. hazırda Kubernetes-ə vurulan bütün podlar;
3. köhnə ReplicaSets (bu yaxınlarda buraxılmış) və biz həmçinin Helm buraxılışlarını skan etməyi və oradakı ən son şəkilləri seçməyi planlaşdırırıq.

... və bu dəstdən ağ siyahı yaradın - silməyəcəyimiz şəkillərin siyahısı. Qalan hər şeyi təmizləyirik, bundan sonra yetim səhnə şəkillərini tapıb onları da silirik.

Yerləşdirmə mərhələsi

Etibarlı deklarativlik

Yerləşdirmədə diqqəti cəlb etmək istədiyim ilk məqam, bəyan edilmiş şəkildə yenilənmiş resurs konfiqurasiyasının yayılmasıdır. Kubernetes resurslarını təsvir edən orijinal YAML sənədi həmişə çoxluqda işləyən nəticədən çox fərqlidir. Çünki Kubernetes konfiqurasiyaya əlavə edir:

1. identifikatorlar;
2. xidmət məlumatları;
3. bir çox standart dəyərlər;
4. cari statusu olan bölmə;
5. qəbul webhook hissəsi kimi edilən dəyişikliklər;
6. müxtəlif nəzarətçilərin (və planlaşdırıcının) işinin nəticəsi.

Beləliklə, yeni resurs konfiqurasiyası görünəndə (yeni), biz sadəcə onunla cari, "canlı" konfiqurasiyanı götürüb üzərinə yaza bilmərik (yaşamaq). Bunu etmək üçün müqayisə etməli olacağıq yeni son tətbiq olunan konfiqurasiya ilə (son müraciət) və üzərinə yuvarlayın yaşamaq yamaq aldı.

Bu yanaşma adlanır 2 tərəfli birləşmə. Məsələn, Helm-də istifadə olunur.

da var 3 tərəfli birləşmə, bununla fərqlənir:

• müqayisə edir son müraciət и yeni, silinənlərə baxırıq;
• müqayisə edir yeni и yaşamaq, nəyin əlavə edildiyinə və ya dəyişdirilməsinə baxırıq;
• cəmlənmiş yamaq tətbiq olunur yaşamaq.

Biz Helm ilə 1000+ proqram yerləşdiririk, ona görə də biz əslində 2 tərəfli birləşmə ilə yaşayırıq. Bununla belə, Helmin normal işləməsinə kömək edən yamaqlarımızla həll etdiyimiz bir sıra problemlər var.

Həqiqi buraxılış statusu

CI sistemimiz növbəti hadisə əsasında Kubernetes üçün yeni konfiqurasiya yaratdıqdan sonra onu istifadəyə ötürür. (müraciət etmək) klasterə - Helm və ya istifadə edərək kubectl apply. Bundan sonra, Kubernetes API-nin CI sisteminə və onun istifadəçisinə təsdiqlə cavab verdiyi artıq təsvir edilmiş N-yollu birləşmə baş verir.

Bununla belə, böyük bir problem var: nəhayət uğurlu tətbiq uğurlu yayım demək deyil. Kubernetes hansı dəyişikliklərin tətbiq edilməli olduğunu başa düşsə və tətbiq etsə, nəticənin nə olacağını hələ də bilmirik. Məsələn, ön hissədə podların yenilənməsi və yenidən işə salınması uğurlu ola bilər, lakin arxa hissədə deyil və biz işləyən tətbiq şəkillərinin müxtəlif versiyalarını əldə edəcəyik.

Hər şeyi düzgün etmək üçün bu sxem əlavə bir keçid tələb edir - Kubernetes API-dən status məlumatını alacaq və onu real vəziyyətin sonrakı təhlili üçün ötürəcək xüsusi bir izləyici. Go-da Açıq Mənbəli kitabxana yaratdıq - kubok (onun elanına baxın burada), bu problemi həll edən və werf-də qurulmuşdur.

Bu izləyicinin werf səviyyəsində davranışı Deployments və ya StatefulSets üzərində yerləşdirilən annotasiyalardan istifadə etməklə konfiqurasiya edilir. Əsas annotasiya - fail-mode - aşağıdakı mənaları başa düşür:

• IgnoreAndContinueDeployProcess — biz bu komponentin yayılması problemlərinə məhəl qoymuruq və yerləşdirməni davam etdiririk;
• FailWholeDeployProcessImmediately — bu komponentdəki xəta yerləşdirmə prosesini dayandırır;
• HopeUntilEndOfDeployProcess — ümid edirik ki, bu komponent yerləşdirmənin sonuna qədər işləyəcək.

Məsələn, resursların və annotasiya dəyərlərinin bu birləşməsi fail-mode:

İlk dəfə yerləşdirdiyimiz zaman verilənlər bazası (MongoDB) hələ hazır olmaya bilər - Yerləşdirmələr uğursuz olacaq. Ancaq onun başlaması üçün anı gözləyə bilərsiniz və yerləşdirmə hələ də baş tutacaq.

Werf-də kubedog üçün daha iki annotasiya var:

• failures-allowed-per-replica — hər bir replika üçün icazə verilən düşmələrin sayı;
• show-logs-until — werf-in (stdout-da) bütün yayılmış podlardan qeydləri göstərdiyi anı tənzimləyir. Defoltdur PodIsReady (qabağa trafik gəlməyə başlayanda istəmədiyimiz mesajlara məhəl qoymamaq üçün), lakin dəyərlər də etibarlıdır: ControllerIsReady и EndOfDeploy.

Yerləşdirmədən başqa nə istəyirik?

Yuxarıda təsvir olunan iki məqama əlavə olaraq, istərdik:

• görmək loglar - və yalnız zəruri olanlar, bir sıra hər şey deyil;
• track tərəqqi, çünki iş bir neçə dəqiqə "səssizcə" asılırsa, orada nə baş verdiyini anlamaq vacibdir;
• var avtomatik geri qaytarma bir şey səhv olarsa (və buna görə də yerləşdirmənin real vəziyyətini bilmək çox vacibdir). Yayım atomik olmalıdır: ya sona qədər keçir, ya da hər şey əvvəlki vəziyyətinə qayıdır.

Nəticələri

Bir şirkət olaraq, çatdırılmanın müxtəlif mərhələlərində (qurmaq, dərc etmək, yerləşdirmək) bütün təsvir olunan nüansları həyata keçirmək üçün bir CI sistemi və köməkçi proqram kifayətdir. werf.

Nəticə yerinə:

Werf-in köməyi ilə biz DevOps mühəndisləri üçün çoxlu sayda problemlərin həllində yaxşı irəliləyiş əldə etdik və daha geniş ictimaiyyət heç olmasa bu yardım proqramını fəaliyyətdə sınasa, şad olarıq. Birlikdə yaxşı nəticə əldə etmək daha asan olacaq.

Videolar və slaydlar

Tamaşadan video (~47 dəqiqə):

Hesabat təqdimatı:

PS

Bloqumuzda Kubernetes haqqında digər hesabatlar:

• «Kubernetes-də avtomatik miqyaslama və resursların idarə edilməsi» (Dmitri Stolyarov; 27 aprel 2019-cu il “Tətil” haqqında);
• «Kubernetləri genişləndirmək və tamamlamaq» (Andrey Polovov; 8 aprel 2019-cu il Saint HighLoad++-da);
• «Verilənlər bazaları və Kubernetes» (Dmitri Stolyarov; 8 noyabr 2018-ci il HighLoad++ ilə);
• «Monitorinq və Kubernetes» (Dmitri Stolyarov; 28 may 2018-ci il, RootConf-da);
• «Kubernetes və GitLab ilə CI/CD ən yaxşı təcrübələri» (Dmitri Stolyarov; 7 noyabr 2017-ci il HighLoad++ ilə);
• «Kiçik layihələrdə Kubernetes ilə təcrübəmiz» (Dmitri Stolyarov; 6 iyun 2017-ci ildə RootConf-da).

Mənbə: www.habr.com