Între 4-6 septembrie, la Sankt Petersburg, în sala de conferințe Selectel, va avea loc un eveniment de trei zile. .
Am construit programul având în vedere că lucrările teoretice despre DevOps, la fel ca manualele pentru instrumente, pot fi citite de fiecare în mod individual. Este interesant doar experiența și practica: explicații despre ceea ce trebuie și ce nu trebuie făcut, și povestiri despre cum procedăm noi.
Fiecare companie, fiecare administrator sau dezvoltator are propriul nivel de DevOps. Unii folosesc greșit Git, alții implementează SRE. Cursul este organizat astfel încât fiecare să găsească ceva relevant, pe care să-l poată implementa aici și acum.
Începem cu Git, apoi ne uităm la dezvoltarea aplicației, interacțiunea între cod și infrastructură, construim CI/CD, descriem infrastructura ca și cod (IaC), testăm soluția obținută, configurăm monitorizarea, colectăm și studiem logurile, și în final ajungem la SRE: transformăm fiabilitatea într-o poveste măsurabilă și gestionabilă.
Git
Acum, doar cei care au cumpărat ieri primul laptop nu folosesc Git. Este un instrument trivial și omniprezent, și totuși întâlnim adesea utilizarea sa greșită: începând cu forțarea push-ului în master, și terminând cu copierea fișierelor din Git pe server prin Ctrl-C, Ctrl-V.
Explicăm cum nu trebuie să facem, cum trebuie să facem, cum se procedează în Southbridge.
Parcurgem o practică: fundamentele Git-ului, munca în echipă.
Tema nr. 1: Fundamentele lucrului cu Git
- Comenzile de bază git init, commit, add, diff, log, status, pull, push
- Git flow, ramuri și etichete, strategii de merge
- Lucrul cu mai multe repo-uri remote
Tema Nr. 2: Lucrul în echipă cu Git
- Fluxul GitHub
- Fork, remote, pull request
- Conflicte, lansări, încă o dată despre Gitflow și alte fluxuri aplicabile echipelor
Materialul este organizat astfel încât administratorii și dezvoltatorii să poată implementa imediat toate practicile în muncă.
Din perspectiva DevOps, utilizarea corectă a Git-ului ordonează și automatizează procesele de dezvoltare și administrare, eliminând o serie de probleme repetitive și sporind productivitatea muncii.
Dezvoltator DevOps
Privim DevOps din perspectiva dezvoltatorului: pornim un mediu local, scriem o aplicație, configurăm monitorizarea și logarea sa, o testăm local, organizăm stocarea variabilelor/secreților și descoperirea serviciilor, urmărim tracing-ul (opentracing).
Tema nr. 3: Lucrul cu aplicația din perspectiva dezvoltării
- Configurarea mediu local: recomandări practice
- Scriem un microserviciu în Python (inclusiv teste)
- Utilizarea docker-compose în dezvoltare
Tema №4: Interacțiunea dintre cod și infrastructură
- Practică de lucru cu configurații
În urma acestui curs, dezvoltatorii vor observa cum să trimită jurnalele, cum să le testeze și cum să le debugeze ulterior. Administratorii vor înțelege nevoile dezvoltatorilor: ce erori pot apărea în cod, cum să organizeze testările pentru dezvoltatori și cum să testeze proiectul ei înșiși.
În această etapă se rezolvă principala sarcină a DevOps: se construiește o înțelegere reciprocă și o colaborare eficientă între dezvoltatori și administratori. Aceasta este o etapă cheie în trecerea de la o regie a sarcinilor la o interacțiune responsabilă.
Ca rezultat, se îmbunătățesc viteza și calitatea muncii.
CI/CD
Automatizarea modernă implică CI/CD. Vom începe prin a analiza automatizarea manuală: makefiles, git hooks, scripturi. Vom analiza când aceste instrumente sunt încă relevante și când nu ar trebui utilizate.
Apoi, vom analiza cele mai bune practici moderne de CI prin intermediul Gitlab.
Tema №5: CI/CD introducere în automatizare
- Introducere în automatizare
- Instrumente (bash, make, gradle)
- Utilizarea git-hooks pentru automatizarea proceselor
- Linii de producție ale fabricii și aplicația lor în IT
- Exemplu de construire a unui 'pipeline' comun
- Software modern pentru CI/CD: Drone CI, BitBucket Pipelines, Travis etc.
Tema №6: CI/CD: Lucrul cu Gitlab
- Gitlab CI - generalități
- Gitlab Runner, tipurile și aplicația lor
- Gitlab CI, caracteristici de configurare, cele mai bune practici
- Etapele Gitlab CI
- Variabilele Gitlab CI
- Compilare, testare, implementare
- Controlul și limitările execuției: only, when
- Lucrul cu artefactele
- Șabloane în .gitlab-ci.yml, reutilizarea acțiunilor pe diferite secțiuni ale pipeline-ului
- Include - secțiuni
- Gestionare centralizată a gitlab-ci.yml (un singur fișier și push-uri automate în celelalte repozitorii)
Colaborarea între administratori și dezvoltatori ajunge la un nou nivel: administratorul scrie șablonul CI, iar dezvoltatorii îl modifică, construind propriul CI independent de administrator.
Reducerea dependenței dezvoltatorilor de administratori, scăderea muncii manuale și eliminarea problemei 'singurei persoane care știe cum să lucreze cu makefile-ul'. Lansările se realizează în mod fiabil și rapid.
IaC
Tema Infrastructure as Code, folosind Terraform, va fi prezentată de către administratorul de cloud Selectel, Alexei Stepanenko. El va arăta cum să desfășori și să scalezi servere rapid și automatizat, cum să împachetezi imagini automat și cum să folosești șabloanele de configurare pentru a obține mașini configurate imediat.
O persoană care a realizat mii de soluții IaC va vorbi despre cum să faci corect și cum să nu faci.
Soluția pentru cloud-ul Selectel cu modificări minime se potrivește pentru cloud-urile Google și Amazon.
Colaboratorul de la Southbridge, Nikolai Mesropyan, va arăta cum să desfășori o aplicație funcțională fără downtime, folosind Ansible, și cum să verifici funcționarea acesteia.
Dacă modifici infrastructura manual (configurând serverele, instalând biblioteci și pachete după necesitate), la încercarea de a ridica o copie a mediului, va trebui să îți amintești și să reproduci toate acțiunile tale. Această sarcină poate dura ușor între 3 și 5 zile. Lucrând cu infrastructura ca și cu codul, te asiguri că ai o descriere actualizată a mediului, care poate fi desfășurată în câteva minute.
Nikolai va vorbi despre cum să scrii playbook-uri, ce greșeli sunt frecvente, de ce uneori playbook-urile funcționează lent sau nu cum te așteptai. Aceasta este experiența acumulată în mai mulți ani de utilizare a IaC la Southbridge.
Tema nr. 7: Infrastructure as Code
- IaC: abordarea infrastructurii ca pe un cod
- Furnizorii de cloud ca furnizori de infrastructură
- Instrumente de inițializare a sistemelor, construirea imaginilor (packer)
- IaC folosind Terraform
- Stocarea configurațiilor, colaborarea, automatizarea aplicațiilor
- Practică în crearea playbook-urilor Ansible
- Idempotentă, declarație
- IaC folosind Ansible
- Database as a Code / Redundanță PostgreSQL
Infrastructura capătă caracteristica de declarație și idempotentă.
Administratorul învață să gestioneze o infrastructură complexă: să creeze rapid noi medii, să mențină unitatea tuturor mediilor, să vizualizeze istoria modificărilor, lucru critic atunci când mai multe echipe lucrează la un proiect.
Dezvoltatorul poate învăța infrastructura, desfășurându-și singur mediile.
Bonusul secțiunii — crearea și configurarea unui cluster de baze de date PostgreSQL cu redundanță. Vom oferi un playbook gata făcut, pe care îl folosim la Southbridge, iar tu vei desfășura cluster-ul pe un mediu de învățare și vei putea folosi această soluție în compania ta.
Testarea infrastructurii și monitorizarea
Automatizarea permite să distribui o eroare pe o mie de servere imediat. La fiecare modificare este necesar un test. Pe de altă parte, testarea manuală durează atât de mult timp încât anulează avantajele automatizării.
Vă vom arăta în practică cum să scrieți teste de rol. Ca rezultat, veți putea scrie teste pentru compania dumneavoastră. Nu mai este nevoie să rețineți setările efectuate, le descrieți în teste și verificați automat dacă toate soluțiile și improvizațiile anterioare sunt intacte.
Apoi vom învăța cum să adăugăm automat toate serverele noi în monitorizare. Vom analiza separat monitorizarea infrastructurii și a aplicațiilor. Vă vom prezenta practici proaste și bune.
Tema nr. 8: Testarea infrastructurii
- Testarea și integrarea continuă cu Molecule și Gitlab CI
- Utilizarea Vagrant
Tema nr. 9: Monitorizarea infrastructurii cu Prometheus
- De ce este necesară monitorizarea
- Tipuri de monitorizare
- Notificări în sistemul de monitorizare
- Cum să construiești un sistem de monitorizare sănătos
- Notificări ușor de citit pentru toți
- Health Check: la ce ar trebui să fiți atenți
- Automatizarea pe baza datelor din monitorizare
O monitorizare care nu funcționează corect este echivalentă cu lipsa monitorizării. Afacerilor nu le pasă că pagina principală a magazinului online este accesibilă, dacă formularul de plată dă o eroare.
În setările de monitorizare și soluționarea problemelor, dezvoltatorii și administratorii participă în mod egal. De obicei, sarcinile de monitorizare sunt în sarcina administratorilor. Cursul nostru va arăta dezvoltatorilor rolul pe care îl joacă în crearea unei monitorizări eficiente. Administratorii vor obține cele mai bune practici de la Southbridge. Ca urmare, numărul pierderilor cauzate de defecțiuni și întârzieri ale site-ului sau aplicației va scădea rapid.
Bonusul secțiunii: automatizarea pe baza monitorizării. De exemplu, monitorizarea raportează că a apărut o sarcină pe site, iar scalarea serverelor web se activează automat.
Logare
Principală greșeală în gestionarea logurilor este că administratorii și dezvoltatorii le vizualizează direct pe servere. Dacă aveți mai mult de un server, aceasta durează mult. Este nesigur: dezvoltatorul accede la server pe care nu ar trebui să fie.
DevOps necesită colectarea, procesarea și analiza centralizată a logurilor.
Tema nr. 10: Logarea aplicației cu ELK
- Aplicații și funcționalități principale ale elastic (căutare, stocare, caracteristici de scalare, flexibilitate de configurare)
- Prezentare generală a Kibana (funcționalități principale, limbaj de interogare, gestionarea tablourilor de bord, crearea de grafice)
- Prezentare generală a produselor bazate pe elastic și utilizarea acestora
- Colectăm metrici în APM (trasee ale aplicațiilor)
- În plus: Prezentare generală a noului produs — SIEM
Implementarea acestei abordări va transforma jurnalele într-un instrument simplu și clar pentru analizarea, configurarea și ajustarea aplicației și infrastructurii.
SRE
Și ajungem la subiectul la care Southbridge se uită cu atenție, iar alte prezentatoare doresc să rămână până în ultima zi a Slyrma. Suntem bucuroși că Ivan Kruglov de la Booking.com a acceptat să îl prezinte.
Proiectul trăiește în lumea reală, unde fiabilitatea nu este niciodată absolută, iar fiecare decizie costă bani.
Ce este SLA în contextul unui proiect complex? Să spunem, cum evaluăm că site-ul este accesibil, dar imaginile se încarcă cu întârziere. Care sunt metricile SLA, de unde le obținem, cum le obținem?
Cum se stabilește SLA? Cum se respectă?
Tema nr. 11: SRE
Definirea SLA, SLO, Error Budget și altele termeni înfricoșători din lumea SRE
SRE: Practica monitorizării SLI și SLO
SRE: Practica aplicării Error Budget
SRE: Gestionarea întreruperilor și a sarcinilor operaționale (apigateway, service mesh, circuit breakers)
Afacerile doresc SRE. Cel puțin la cel mai simplu nivel: să ia un server de rezervă sau să îl ridice din backup? O bază de date sau un cluster? Să instaleze protecție împotriva DDoS preventiv sau doar în momentul atacului?
Directorul nu va fi mulțumit să audă că „site-ul funcționează”, când clientul sună și raportează că formularul de comandă nu se deschide.
De aceea, este important ca inginerul DevOps să înțeleagă cel puțin superficial SRE pentru a putea discuta adecvat cu afacerea despre nevoile acesteia.
Rezultatul
În timpul administratorii și dezvoltatorii vor învăța:
— să lucreze corect cu Git;
— să organizeze dezvoltarea locală;
— să configureze (administratorii) și să folosească (dezvoltatorii) CI/CD;
— să lucreze cu infrastructura ca și cum ar fi cod;
— să testeze infrastructura;
— să monitorizeze infrastructura și aplicația;
— să configureze logarea;
— să înțeleagă, iar ideal — să folosească SRE.
Pentru cititorii atenți — cu codul promoțional habrapost obțineți o reducere de 15%.
Pentru toate aspectele, pregătim practică și instrumente. Așadar, fiecare participant la întoarcerea din Slurm va putea să ducă compania sa la următorul nivel DevOps.
Pentru afaceri, acest lucru înseamnă reducerea costurilor de administrare și dezvoltare, reducerea timpului de nefuncționare, creșterea fiabilității, livrarea mai rapidă a funcțiilor și repararea erorilor.
Sursa: habr.com
