4-6 sentyabr tarixlərində Sankt-Peterburqda, Selectel konfrans zalında, üç günlük .
Biz proqramı DevOps-da alətlər üçün təlimatlar kimi nəzəri işlərin hər kəs tərəfindən təkbaşına oxuna biləcəyi ideyası əsasında qurmuşuq. Yalnız təcrübə və təcrübə maraqlıdır: bunu necə etmək və nəyi etməmək barədə izahat və bunu necə etdiyimiz haqqında hekayə.
Hər bir şirkət, hər bir idarəçi və ya tərtibatçının öz DevOps səviyyəsi var. Bəzi insanlar Git-dən səhv istifadə edir, digərləri isə SRE-ni tətbiq edir. Kurs elə təşkil olunub ki, hər kəs burada və indi həyata keçirilə biləcək uyğun bir şey tapsın.
Biz Git ilə başlayırıq, sonra proqramların hazırlanmasına, kod və infrastruktur arasında qarşılıqlı əlaqəyə baxırıq, CI/CD qururuq, infrastrukturu kod (IaC) kimi təsvir edirik, nəticədə həlli sınaqdan keçiririk, monitorinq qururuq, jurnalları toplayıb öyrənirik və sonda biz gəlirik. SRE-ə: etibarlılığı ölçülə bilən və idarə oluna bilən hekayəyə çevirmək.
get
İndiki vaxtda Git-dən istifadə etməyən yeganə insanlar dünən ilk noutbuklarını alanlardır. Bu, mənasız və hər yerdə istifadə olunan bir vasitədir, lakin biz tez-tez onun sui-istifadəsini görürük: master-a təkan verməkdən tutmuş Ctrl-C, Ctrl-V vasitəsilə faylları Git-dən serverə köçürməyə qədər.
Biz sizə Southbridge-də etdikləri kimi nə etməməli olduğunuzu, necə etməli olduğunuzu söyləyirik.
Təcrübə edirik: Gitanın əsasları, komanda işi.
Mövzu №1: Git əsasları
- Əsas əmrlər git init, commit, add, diff, log, status, pull, push
- Git axını, filiallar və etiketlər, birləşmə strategiyaları
- Çoxlu uzaq repo ilə işləmək
Mövzu №2: Git ilə komanda işi
- GitHub axını
- Çəngəl, uzaqdan, çəkmə tələbi
- Münaqişələr, buraxılışlar, bir daha Gitflow və komandalarla əlaqəli digər axınlar haqqında
Material elə təşkil olunub ki, idarəçilər və tərtibatçılar öz işlərində bütün təcrübələri dərhal həyata keçirə bilsinlər.
DevOps nöqteyi-nəzərindən Git ilə düzgün işləmək inkişaf və idarəetmə proseslərini asanlaşdırır və avtomatlaşdırır, bir sıra təkrarlanan problemləri aradan qaldırır və məhsuldarlığı artırır.
DevOps tərtibatçısı
Biz DevOps-a bir tərtibatçı gözü ilə baxırıq: biz yerli mühiti işə salırıq, proqram yazırıq, onun monitorinqini və qeydini qururuq, onu yerli olaraq sınaqdan keçiririk, dəyişənlərin/sirlərin saxlanmasını və xidmət kəşfini təşkil edirik, açıq izləyirik.
Mövzu №3: İnkişaf nöqteyi-nəzərindən proqramla işləmək
- Yerli mühitin qurulması: praktik tövsiyələr
- Python-da mikroservis yazmaq (testlər daxil olmaqla)
- İnkişafda docker-compose-dən istifadə
Mövzu №4: Kod və infrastruktur arasında qarşılıqlı əlaqə
- Konfiqurasiyalarla işləməyi məşq edin
Nəticədə tərtibatçılar kodun jurnalları necə göndərməli olduğunu, onu necə sınaqdan keçirəcəyini və gələcəkdə onun necə düzəldiləcəyini görəcəklər. İnzibatçılar tərtibatçıların ehtiyaclarını başa düşəcəklər: kodda hansı səhvlər var, tərtibatçılar üçün testləri necə təşkil etmək, layihəni özləri necə sınaqdan keçirmək.
Bu mərhələdə DevOps-un əsas vəzifəsi həll olunur: Devs və Ops arasında qarşılıqlı anlaşma və birgə iş qurulur. Bu, tapşırıqların paylaşılmasından məsuliyyətli əməkdaşlığa keçmək üçün əsas addımdır.
Nəticədə işin sürəti və keyfiyyəti yüksəlir.
CI / CD
Müasir avtomatlaşdırma CI/CD-ni əhatə edir. Biz əl ilə avtomatlaşdırmaya baxaraq başlayacağıq: makefiles, githooks, scripts. Bu vasitələrin nə vaxt hələ də aktual olduğunu və nə vaxt istifadə edilməməsi lazım olduğuna baxaq.
Sonra nümunə olaraq Gitlab-dan istifadə edərək müasir CI-nin ən yaxşı təcrübələrinə baxaq.
Mövzu №5: Avtomatlaşdırmaya CI/CD girişi
- Avtomatlaşdırmaya giriş
- Alətlər (bash, make, gradle)
- Prosesləri avtomatlaşdırmaq üçün git qarmaqlarından istifadə
- Zavod konveyerinin montaj xətləri və onların İT-də tətbiqi
- "Ümumi" boru kəmərinin qurulması nümunəsi
- Müasir CI/CD proqram təminatı: Drone CI, BitBucket Pipelines, Travis və s.
Mövzu №6: CI/CD: Gitlab ilə işləmək
- Gitlab CI - ümumi
- Gitlab Runner, onların növləri və istifadəsi
- Gitlab CI, fərdiləşdirmə xüsusiyyətləri, ən yaxşı təcrübələr
- Gitlab CI addımları
- Gitlab CI Dəyişənləri
- Qurmaq, sınaqdan keçirmək, yerləşdirmək
- İcra nəzarəti və məhdudiyyətlər: yalnız, nə vaxt
- Artefaktlarla işləmək
- .gitlab-ci.yml daxilində şablonlar, boru kəmərinin müxtəlif hissələrində hərəkətləri təkrar istifadə edir
- Daxil et - bölmələr
- gitlab-ci.yml-in mərkəzləşdirilmiş idarə edilməsi (bir fayl və digər depolara avtomatik itələmə)
İnzibatçılar və tərtibatçılar arasında əməkdaşlıq yeni səviyyəyə çatır: administrator CI şablonunu yazır və tərtibatçılar inzibatçıdan asılı olmayaraq öz CI-lərini qururlar.
Tərtibatçıların administratorlardan asılılığı azalır, əl işinin həcmi azalır və “make faylı ilə işləməyi bilən yeganə insan” problemi aradan qalxır. Yayılmalar etibarlı və tez baş verir.
IaC
Nümunə olaraq Terraform-dan istifadə edən Kod kimi İnfrastruktur mövzusu Selectel bulud administratoru Aleksey Stepanenko tərəfindən müzakirə olunacaq. O, sizə serverləri necə tez və avtomatik yerləşdirməyi və miqyasını, şəkilləri avtomatik paketləşdirməyi və konfiqurasiya edilmiş maşınları dərhal əldə etmək üçün konfiqurasiya şablonlarından necə istifadə etməyi göstərəcək.
Minlərlə IaC həlli hazırlamış bir şəxs sizə bunu necə düzgün və nə etməməli olduğunuzu söyləyəcək.
Selectel bulud həlli minimal dəyişikliklərlə Google və Amazon buludları üçün uyğundur.
Southbridge işçisi Nikolay Mesropyan, Ansible-dan nümunə olaraq istifadə edərək, işlək tətbiqetməni fasiləsiz yerləşdirməyi və onun işini yoxlamağı göstərəcək.
Əgər siz infrastrukturu əl ilə redaktə etsəniz (serverləri quraşdırın, kitabxanaları və paketləri lazım olduqda quraşdırın), mühitin surətini qaldırmağa çalışdığınız zaman bütün hərəkətlərinizi yadda saxlamalı və təkrar etməli olacaqsınız. Bu iş asanlıqla 3-5 gün çəkir. İnfrastrukturla kod kimi işləmək ətraf mühitinizin bir neçə dəqiqə ərzində tətbiq oluna bilən ən müasir təsvirinə malik olmanızı təmin edir.
Nikolay sizə oyun kitablarını necə yazacağınızı, hansı səhvlərin baş verdiyini və niyə bəzən oyun kitablarının gözlənildiyi kimi yavaş işlədiyini və ya işləmədiyini söyləyəcək. Bu, Southbridge-də uzun illər IaC-dən istifadə təcrübəsidir.
Mövzu №7: İnfrastruktur Kodeks kimi
- IaC: infrastruktura kod kimi yanaşın
- İnfrastruktur təminatçıları kimi bulud provayderləri
- Sistemin işə salınması alətləri, təsvirin qurulması (paker)
- Terraform nümunəsində IaC
- Konfiqurasiyanın saxlanması, əməkdaşlıq, tətbiqin avtomatlaşdırılması
- Ansible oyun kitablarının yaradılması təcrübəsi
- Qüsursuzluq, deklarativ
- Ansible nümunəsində IaC
- Kod kimi verilənlər bazası / PostgreSQL səhvlərə dözümlülük
İnfrastruktur deklarativ və idempotent olur.
Administrator mürəkkəb infrastrukturu idarə etməyi öyrənir: tez yeni mühitlər yaradın, bütün mühitlərin vəhdətini qoruyun, dəyişikliklərin tarixinə baxın, bu, bir neçə komanda layihə üzərində işləyərkən vacibdir.
Tərtibatçı infrastrukturu öyrənə və müstəqil olaraq öz mühitini inkişaf etdirə bilər.
Bölmə bonusu: PostgreSQL verilənlər bazalarının əvəzetmə klasterinin yaradılması və konfiqurasiyası. Biz Southbridge-də istifadə etdiyimiz hazır dərs kitabı təqdim edəcəyik, siz təlim stendində klaster yerləşdirəcəksiniz və bu həlli şirkətinizdə istifadə edə bilərsiniz.
İnfrastrukturun sınaqdan keçirilməsi və monitorinqi
Avtomatlaşdırma sizə eyni anda min serverə xətanı yaymağa imkan verir. Hər bir dəyişiklik sınaq tələb edir. Digər tərəfdən, əllə sınaq o qədər vaxt aparır ki, avtomatlaşdırmanın faydalarını inkar edir.
Biz sizə rol testini necə yazacağınızı praktikada göstərəcəyik. Nəticədə siz şirkətiniz üçün testlər yaza biləcəksiniz. Artıq etdiyiniz parametrləri xatırlamağa ehtiyac yoxdur; siz onları testlərdə təsvir edirsiniz və bütün əvvəlki həllərin və qoltuqaltıların yerində olub-olmadığını avtomatik yoxlayırsınız.
Sonra monitorinqə bütün yeni serverləri avtomatik əlavə etməyi öyrənəcəyik. İnfrastruktur və tətbiq monitorinqinə ayrıca baxaq. Pis və yaxşı təcrübələr göstərəcəyik.
Mövzu №8: İnfrastruktur Testi
- Molecule və Gitlab CI ilə sınaq və davamlı inteqrasiya
- Vaqrant tətbiqi
Mövzu №9: Prometheus ilə infrastrukturun monitorinqi
- Nə üçün monitorinq lazımdır
- Monitorinq növləri
- Monitorinq sistemində bildirişlər
- Sağlam monitorinq sistemini necə qurmaq olar
- Hər kəs üçün insan tərəfindən oxuna bilən bildirişlər
- Sağlamlıq yoxlanışı: nələrə diqqət etməli
- Monitorinq məlumatlarına əsaslanan avtomatlaşdırma
Düzgün işləməyən monitorinq heç bir monitorinq deyil. Ödəniş formasında səhv olarsa, müəssisələr onlayn mağazanın əsas səhifəsinin əlçatan olmasına əhəmiyyət vermirlər.
Tərtibatçılar və idarəçilər monitorinqin qurulmasında və problemlərin aradan qaldırılmasında bərabər şəkildə iştirak edirlər. Üstəlik, ənənəvi olaraq, monitorinq vəzifələri idarəçilərin üzərinə düşür. Kursumuz tərtibatçılara effektiv monitorinqin yaradılmasında oynadıqları rolu göstərəcək. Administratorlar Southbridge ən yaxşı təcrübələrini alacaqlar. Nəticə etibarı ilə vebsayt və ya proqramın uğursuzluqları və yavaşlamaları nəticəsində yaranan itkilərin sayı sürətlə azalacaq.
Bölmə bonusu: monitorinq əsasında avtomatlaşdırma. Məsələn, monitorinq sayta yük gəldiyini bildirir və veb server miqyası avtomatik olaraq başlayır.
Giriş
Qeydlərlə işləyərkən əsas səhv idarəçilərin və tərtibatçıların onlara birbaşa serverlərdə baxmasıdır. Birdən çox serveriniz varsa, bu çox vaxt aparır. Bu təhlükəsiz deyil: tərtibatçı olmamalı olduğu serverə daxil olur.
DevOps logların mərkəzləşdirilmiş toplanması, işlənməsi və analitikasını tələb edir.
Mövzu №10: ELK ilə proqramların qeydiyyatı
- Elastikin əsas tətbiqləri və imkanları (axtarış, saxlama, miqyaslama xüsusiyyətləri, fərdiləşdirmə çevikliyi)
- Kibana icmalı (əsas xüsusiyyətlər, sorğu dili, tablosunun idarə edilməsi, diaqramın yaradılması)
- Elastik əsaslı məhsulların və onların tətbiqlərinin nəzərdən keçirilməsi
- APM-də ölçülərin toplanması (tətbiq izləmə)
- Əlavə olaraq: Yeni Məhsul Baxışı - SIEM
Bu yanaşmanın tətbiqi logları proqram və infrastrukturun təhlili, konfiqurasiyası və sazlanması üçün sadə və başa düşülən alətə çevirəcək.
SRE
Və biz Southbridge-in yalnız diqqətini çəkdiyi və digər natiqlərin Slurm-un son günündə qalmaq istədikləri mövzuya çatırıq. Booking.com-dan İvan Kruqlovun onu oxumağa razı olmasına şadıq.
Layihə etibarlılığın heç vaxt mütləq olmadığı və hər qərarın pula başa gəldiyi real dünyada yaşayır.
Mürəkkəb layihə ilə bağlı SLA nədir? Deyək ki, saytın əlçatan olduğunu, lakin şəkillərin gecikmə ilə yükləndiyini necə qiymətləndirmək olar. SLA ölçüləri nədir, onları hara götürməli, necə götürməli?
SLA-nı necə təyin etmək olar? Onlara necə dözmək olar?
Mövzu №11: SRE
SRE dünyasından SLA, SLO, Error Budget və digər qorxulu terminlərin tərifi
SRE: SLI və SLO Monitorinq Təcrübələri
SRE: Səhv Büdcəsindən istifadə təcrübəsi
SRE: Fasilə və əməliyyat yükünün idarə edilməsi (apigateway, xidmət şəbəkəsi, elektrik açarları)
Müəssisələr SRE istəyirlər. Ən azı ən sadə səviyyədə: ehtiyat server götürməliyəm, yoxsa onu ehtiyat nüsxədən qaldırmalıyam? Vahid verilənlər bazası və ya klaster? DDoS müdafiəsini aktiv şəkildə quraşdırmalısınız, yoxsa yalnız hücum zamanı?
Müştəri ona zəng edib sifariş formasının açılmadığını bildirəndə “sayt işləyir” hekayəsi rejissoru qane etməyəcək.
Buna görə də, DevOps mühəndisinin bizneslə ehtiyacları barədə adekvat danışmaq üçün SRE-ni heç olmasa səthi şəkildə başa düşməsi vacibdir.
Ümumi
Vaxt keçdikcə idarəçilər və tərtibatçılar öyrənəcəklər:
— Git ilə düzgün işləmək;
— yerli inkişafı təşkil etmək;
— CI/CD-ni konfiqurasiya etmək (inzibatçılar) və istifadə etmək (inzibatçılar);
— kodla olduğu kimi infrastrukturla işləmək;
— infrastrukturun sınaqdan keçirilməsi;
— infrastrukturun və tətbiqin monitorinqi;
— girişi konfiqurasiya etmək;
— anlayın və ideal olaraq SRE-dən istifadə edin.
Diqqətli oxucular üçün 15% endirim üçün habrapost promosyon kodundan istifadə edin.
Bütün nöqtələr üçün təcrübə və alətlər hazırlayırıq. Beləliklə, hər bir iştirakçı Slurm-dan qayıtdıqdan sonra öz şirkətlərini DevOps-un növbəti səviyyəsinə keçirə biləcəklər.
Biznes üçün bu, daha ucuz idarəetmə və inkişaf, azaldılmış dayanma müddəti, artan etibarlılıq, funksiyaların daha sürətli çatdırılması və səhvlərin aradan qaldırılması deməkdir.
Mənbə: www.habr.com
