Pe 4-6 septembrie la Sankt Petersburg, în sala de conferințe Selectel, o perioadă de trei zile .
Am construit programul pe baza ideii că lucrările teoretice pe DevOps, cum ar fi manualele pentru instrumente, pot fi citite de toată lumea pe cont propriu. Doar experiența și practica sunt interesante: o explicație despre cum să facem și ce să nu facem și o poveste despre cum o facem.
Fiecare companie, fiecare administrator sau dezvoltator are propriul nivel de DevOps. Unii oameni folosesc Git incorect, alții implementează SRE. Cursul este organizat astfel încât toată lumea să găsească ceva relevant care poate fi implementat aici și acum.
Începem cu Git, apoi ne uităm la dezvoltarea aplicațiilor, interacțiunea dintre cod și infrastructură, construim CI/CD, descriem infrastructura ca cod (IaC), testăm soluția rezultată, setăm monitorizarea, colectăm și studiem jurnalele și, în final, ajungem către SRE: transformarea fiabilității într-o poveste măsurabilă și gestionabilă.
merge
În prezent, singurii oameni care nu folosesc Git sunt cei care și-au cumpărat primul laptop ieri. Acesta este un instrument trivial și omniprezent și, totuși, vedem adesea utilizarea greșită a acestuia: de la forțarea unui push către master, la copierea fișierelor de pe Git pe server prin Ctrl-C, Ctrl-V.
Vă spunem ce nu ar trebui să faceți, cum ar trebui să faceți, așa cum fac ei în Southbridge.
Facem practică: elementele de bază ale Gita, lucrul în echipă.
Subiectul #1: Bazele Git
- Comenzi de bază git init, commit, add, diff, log, status, pull, push
- Flux Git, ramuri și etichete, strategii de îmbinare
- Lucrul cu mai multe depozite la distanță
Subiectul #2: Lucrul în echipă cu Git
- Fluxul GitHub
- Furcă, telecomandă, cerere de tragere
- Conflicte, lansări, încă o dată despre Gitflow și alte fluxuri în relație cu echipe
Materialul este organizat astfel încât administratorii și dezvoltatorii să poată implementa imediat toate practicile în munca lor.
Din punct de vedere DevOps, lucrul corespunzător cu Git eficientizează și automatizează procesele de dezvoltare și administrare, elimină o serie de probleme recurente și crește productivitatea.
Dezvoltator DevOps
Privim DevOps prin ochii unui dezvoltator: lansăm un mediu local, scriem o aplicație, setăm monitorizarea și logging-ul acesteia, o testăm local, organizăm stocarea variabilelor/secretelor și descoperirea serviciilor, urmărim opentracing.
Subiectul #3: Lucrul cu aplicația din punct de vedere al dezvoltării
- Amenajarea mediului local: recomandări practice
- Scrierea unui microserviciu în Python (inclusiv teste)
- Utilizarea docker-compose în dezvoltare
Subiectul #4: Interacțiunea dintre cod și infrastructură
- Exersați lucrul cu configurațiile
Ca rezultat, dezvoltatorii vor vedea cum ar trebui să trimită codul jurnale, cum să-l testeze și cum va fi depanat în viitor. Administratorii vor înțelege nevoile dezvoltatorilor: ce erori există în cod, cum să organizeze testarea pentru dezvoltatori, cum să testeze singuri proiectul.
În această etapă, sarcina principală a DevOps este rezolvată: se construiește înțelegerea reciprocă și munca comună între Devs și Ops. Acesta este un pas cheie în trecerea de la partajarea sarcinilor la colaborarea responsabilă.
Ca urmare, viteza și calitatea muncii crește.
CI / CD
Automatizarea modernă implică CI/CD. Vom începe prin a ne uita la automatizarea manuală: makefiles, githooks, scripturi. Să vedem când aceste instrumente sunt încă relevante și când nu ar trebui folosite.
Apoi, să ne uităm la cele mai bune practici ale CI modern folosind Gitlab ca exemplu.
Subiectul #5: Introducere CI/CD în automatizare
- Introducere în automatizare
- Instrumente (bash, make, gradle)
- Utilizarea git-hooks pentru a automatiza procesele
- Liniile de asamblare din fabrică și aplicarea lor în IT
- Un exemplu de construire a unei conducte „generale”.
- Software modern pentru CI/CD: Drone CI, BitBucket Pipelines, Travis etc.
Subiectul #6: CI/CD: Lucrul cu Gitlab
- Gitlab CI - general
- Gitlab Runner, tipurile și aplicațiile acestora
- Gitlab CI, caracteristici de configurare, bune practici
- Etape Gitlab CI
- Variabile Gitlab CI
- Construiți, testați, implementați
- Controlul execuției și restricții: numai, când
- Lucrul cu artefacte
- Șabloane în interiorul .gitlab-ci.yml, reutilizand acțiuni în diferite părți ale conductei
- Include - secțiuni
- Gestionarea centralizată a gitlab-ci.yml (un fișier și împingere automată în alte depozite)
Colaborarea dintre administratori și dezvoltatori atinge un nou nivel: administratorul scrie un șablon CI, iar dezvoltatorii îl editează, construindu-și CI independent de administrator.
Dependența dezvoltatorilor de administratori este redusă, cantitatea de muncă manuală este redusă și problema „singurei persoane care știe să lucreze cu un fișier make” dispare. Lansările au loc în mod fiabil și rapid.
IaC
Subiectul infrastructurii ca cod, folosind Terraform ca exemplu, va fi discutat de administratorul de cloud Selectel Alexey Stepanenko. El vă va arăta cum să implementați și să scalați rapid și automat serverele, cum să împachetați automat imaginile și cum să utilizați șabloanele de configurare pentru a obține mașinile configurate imediat.
O persoană care a realizat mii de soluții IaC vă va spune cum să faceți bine și ce să nu faceți.
Soluția de cloud Selectel este potrivită pentru norii Google și Amazon cu modificări minime.
Angajatul Southbridge Nikolai Mesropyan, folosind Ansible ca exemplu, va arăta cum să implementați o aplicație funcțională fără timp de nefuncționare și să-i verifice performanța.
Dacă editați manual infrastructura (configurați servere, instalați biblioteci și pachete după cum este necesar), atunci când încercați să ridicați o copie a mediului, va trebui să vă amintiți și să reproduceți toate acțiunile dvs. Această sarcină durează cu ușurință 3-5 zile. Lucrul cu infrastructura ca cod vă asigură că aveți o descriere actualizată a mediului dvs. care poate fi implementată în câteva minute.
Nikolay vă va spune cum să scrieți cărți de joc, ce greșeli se întâmplă și de ce uneori cărțile de joc funcționează lent sau nu așa cum vă așteptați. Aceasta este experiența de mulți ani de utilizare a IaC la Southbridge.
Subiectul #7: Infrastructura ca cod
- IaC: Abordarea infrastructurii ca cod
- Furnizorii de cloud ca furnizori de infrastructură
- Instrumente de inițializare a sistemului, construirea imaginii (ambalare)
- IaC folosind Terraform ca exemplu
- Stocarea configurațiilor, colaborarea, automatizarea aplicațiilor
- Practică de creare a unor manuale Ansible
- Idempotenta, declarativitatea
- IaC folosind Ansible ca exemplu
- Baza de date ca cod / toleranță la erori PostgreSQL
Infrastructura devine declarativă și idempotentă.
Administratorul învață să gestioneze infrastructura complexă: să creeze rapid noi medii, să mențină unitatea tuturor mediilor, să vadă istoricul schimbărilor, ceea ce este critic atunci când mai multe echipe lucrează la un proiect.
Dezvoltatorul poate studia infrastructura și își poate dezvolta în mod independent propriul mediu.
Bonus de secțiune: crearea și configurarea unui cluster de failover de baze de date PostgreSQL. Vă vom oferi un manual gata făcut pe care îl folosim la Southbridge, veți implementa un cluster pe un stand de antrenament și puteți utiliza această soluție în compania dumneavoastră.
Testarea și monitorizarea infrastructurii
Automatizarea vă permite să lansați o eroare la o mie de servere simultan. Fiecare modificare necesită testare. Pe de altă parte, testarea manuală necesită atât de mult timp încât anulează beneficiile automatizării.
Vă vom arăta în practică cum să scrieți teste de rol. Drept urmare, veți putea scrie teste pentru compania dvs. Nu mai trebuie să vă amintiți setările pe care le-ați făcut; le descrieți în teste și verificați automat dacă toate soluțiile și cârjele anterioare sunt la locul lor.
Apoi vom învăța cum să adăugăm automat toate serverele noi la monitorizare. Să ne uităm separat la monitorizarea infrastructurii și a aplicațiilor. Vom arăta practici bune și rele.
Subiectul #8: Testarea infrastructurii
- Testare și integrare continuă cu Molecule și Gitlab CI
- Folosind Vagrant
Subiectul #9: Monitorizarea infrastructurii cu Prometheus
- De ce este nevoie de monitorizare
- Tipuri de monitorizare
- Notificări în sistemul de monitorizare
- Cum să construiți un sistem de monitorizare sănătos
- Notificări care pot fi citite de om, pentru toată lumea
- Verificarea sănătății: la ce ar trebui să fii atent
- Automatizare bazată pe date de monitorizare
Monitorizarea care nu funcționează corect nu este o monitorizare. Întreprinderilor nu le pasă că pagina principală a unui magazin online este accesibilă dacă formularul de plată dă o eroare.
Dezvoltatorii și administratorii participă în mod egal la configurarea problemelor de monitorizare și depanare. Mai mult, în mod tradițional, sarcinile de monitorizare revin administratorilor. Cursul nostru va arăta dezvoltatorilor rolul pe care îl joacă în crearea unei monitorizări eficiente. Administratorii vor primi cele mai bune practici Southbridge. Ca urmare, numărul de pierderi cauzate de eșecurile și încetinirile unui site web sau a unei aplicații va scădea rapid.
Bonus de secțiune: automatizare bazată pe monitorizare. De exemplu, monitorizarea raportează că o încărcare a ajuns pe site și scalarea serverului web începe automat.
Logare
Principala greșeală atunci când lucrați cu jurnalele este că administratorii și dezvoltatorii le privesc direct pe servere. Dacă aveți mai multe servere, acest lucru durează mult. Acest lucru nu este sigur: dezvoltatorul se conectează la un server unde nu ar trebui să fie.
DevOps necesită colectarea, procesarea și analiza centralizată a jurnalelor.
Subiectul #10: Înregistrarea unei aplicații cu ELK
- Aplicații și capabilități de bază ale elasticului (căutare, stocare, caracteristici de scalare, flexibilitate de personalizare)
- Prezentare generală a kibana (funcții principale, limbajul de interogare, managementul tabloului de bord, crearea diagramelor)
- Revizuirea produselor pe bază de elastic și a aplicațiilor acestora
- Colectarea valorilor în APM (urmărirea aplicației)
- În plus: revizuire produs nou - SIEM
Introducerea acestei abordări va face din jurnalele un instrument simplu și ușor de înțeles pentru analiza, configurarea și depanarea aplicației și a infrastructurii.
EOA
Și ajungem la subiectul pe care Southbridge tocmai își atrage atenția și pentru care alți vorbitori doresc să rămână în ultima zi de Slurm. Ne bucurăm că Ivan Kruglov de la Booking.com a fost de acord să-l citească.
Proiectul trăiește în lumea reală, unde fiabilitatea nu este niciodată absolută și fiecare decizie costă bani.
Ce este SLA în raport cu un proiect complex? Să spunem cum să evaluăm că site-ul este accesibil, dar imaginile sunt încărcate cu întârziere. Care sunt valorile SLA, unde să le luăm, cum să le luăm?
Cum se setează SLA? Cum să le reziste?
Subiectul #11: SRE
Definiția SLA, SLO, Bug Bug și alți termeni înfricoșători din lumea SRE
SRE: Practici de monitorizare SLI și SLO
SRE: Practică de utilizare a Bugetului de eroare
SRE: Managementul întreruperii și al sarcinii operaționale (apigateway, rețea de service, întrerupătoare)
Afacerile vor SRE. Cel puțin la cel mai simplu nivel: ar trebui să iau un server de rezervă sau să-l ridic dintr-un backup? Baza de date unică sau cluster? Ar trebui să instalați protecția DDoS în mod proactiv sau numai în momentul atacului?
Regizorul nu va fi mulțumit de povestea că „site-ul funcționează” atunci când un client îl sună și îi anunță că formularul de comandă nu se deschide.
Prin urmare, este important ca un inginer DevOps să înțeleagă cel puțin superficial SRE pentru a vorbi în mod adecvat cu afacerea despre nevoile acesteia.
Total
Pe parcursul administratorii și dezvoltatorii vor învăța:
— să lucreze corect cu Git;
— organizarea dezvoltării locale;
— configurați (administratori) și utilizați (dezvoltatori) CI/CD;
— lucrați cu infrastructura ca și cu codul;
— testarea infrastructurii;
— monitorizarea infrastructurii și a aplicațiilor;
— configurați înregistrarea în jurnal;
— înțelegeți și, în mod ideal, utilizați SRE.
Pentru cititorii atenți, folosește codul promoțional habrapost pentru o reducere de 15%.
Pregătim practică și instrumente pentru toate punctele. Pentru ca fiecare participant, la întoarcerea din Slurm, să-și poată duce compania la următorul nivel de DevOps.
Pentru afaceri, aceasta înseamnă administrare și dezvoltare mai ieftine, timpi de nefuncționare redusi, fiabilitate sporită, livrare mai rapidă a funcțiilor și eliminarea erorilor.
Sursa: www.habr.com
