4-6 września w Sankt Petersburgu, w sali konferencyjnej Selectel, odbędzie się trzydniowy .
Układając program, myśleliśmy, że teoretyczne prace nad DevOps, podobnie jak podręczniki do narzędzi, każdy może przeczytać samodzielnie. Interesują nas jedynie doświadczenie i praktyka: wyjaśnienie, jak coś robić, a jak nie, oraz opowieść o tym, jak my to robimy.
W każdej firmie, u każdego administratora czy programisty, poziom DevOps jest inny. Niektórzy używają Gita niewłaściwie, inni wdrażają SRE. Kurs jest zorganizowany w taki sposób, aby każdy mógł znaleźć coś aktualnego, co można wdrożyć od razu.
Zaczynamy od Gita, potem omawiamy rozwój aplikacji, interakcję kodu i infrastruktury, budujemy CI/CD, opisujemy infrastrukturę jako kod (IaC), testujemy powstałe rozwiązanie, konfigurujemy monitoring, zbieramy i analizujemy logi, a na końcu zajmujemy się SRE: przekształcamy niezawodność w mierzalną i zarządzaną historię.
Gitem
Obecnie z Gita nie korzysta tylko ten, kto wczoraj kupił swój pierwszy laptop. To trywialne i powszechne narzędzie, jednak wciąż często spotykamy jego niewłaściwe użycie: począwszy od wymuszonego pushu do mastera, a skończywszy na kopiowaniu plików z Gita na serwer przez Ctrl-C, Ctrl-V.
Opowiadamy o tym, jak nie należy robić oraz jak należy robić, jak robią w Southbridge.
Przechodzimy do praktyki: podstawy Gita, praca zespołowa.
Temat nr 1: Podstawy pracy z Gitem
- Podstawowe komendy git init, commit, add, diff, log, status, pull, push
- Git flow, gałęzie i tagi, strategie scalania
- Praca z wieloma zdalnymi repozytoriami
Temat nr 2: Praca zespołowa z Gitem
- GitHub flow
- Fork, remote, pull request
- Konflikty, wydania, jeszcze raz o Gitflow i innych flow w kontekście zespołów
Materiał jest zorganizowany w taki sposób, aby administratorzy i programiści mogli natychmiast wdrażać wszystkie praktyki w pracy.
Z perspektywy DevOps prawidłowa praca z Gitem porządkuje i automatyzuje procesy rozwoju i administracji, eliminuje szereg powtarzających się problemów, a także zwiększa wydajność pracy.
DevOps dla programisty
Patrzymy na DevOps oczami programisty: uruchamiamy lokalne środowisko, piszemy aplikację, konfigurujemy jej monitoring i logowanie, testujemy ją lokalnie, organizujemy przechowywanie zmiennych/sekretów i odkrywanie usług, przyglądamy się śledzeniu (opentracing).
Temat nr 3: Praca z aplikacją z perspektywy rozwoju
- Konfiguracja lokalnego środowiska: praktyczne wskazówki
- Tworzymy mikroserwis w Pythonie (w tym testy)
- Zastosowanie docker-compose w rozwoju
Temat nr 4: Interakcja kodu i infrastruktury
- Praktyka pracy z konfiguracjami
Na koniec programiści zobaczą, jak kod powinien wysyłać logi, jak go testować oraz jak będzie dalej debugowany. Administratorzy zrozumieją potrzeby programistów: jakie błędy w kodzie występują, jak zorganizować testowanie dla programistów oraz jak samodzielnie testować projekt.
Na tym etapie rozwiązana zostanie główna kwestia DevOps: następuje budowanie wzajemnego zrozumienia i współpracy między programistami a operatorami. To kluczowy krok w przejściu od przerzucania zadań do odpowiedzialnej współpracy.
W rezultacie zwiększa się szybkość i jakość pracy.
CI/CD
Nowoczesna automatyzacja zakłada CI/CD. Zaczniemy od ręcznej automatyzacji: makefile, git hooks, skrypty. Zbadamy, kiedy te narzędzia są nadal aktualne, a kiedy nie powinny być używane.
Następnie przyjrzymy się najlepszym praktykom nowoczesnego CI na przykładzie GitLab.
Temat nr 5: CI/CD: wprowadzenie do automatyzacji
- Wprowadzenie do automatyzacji
- Narzędzia (bash, make, gradle)
- Zastosowanie git-hooks do automatyzacji procesów
- Fabryczne linie produkcyjne i ich zastosowanie w IT
- Przykład budowy 'wspólnego' pipeline'u
- Nowoczesne oprogramowanie do CI/CD: Drone CI, BitBucket Pipelines, Travis itd.
Temat nr 6: CI/CD: Praca z GitLab
- GitLab CI — ogólnie
- GitLab Runner, ich typy i zastosowanie
- GitLab CI, szczegóły konfiguracji, najlepsze praktyki
- Etapy GitLab CI
- Zmienne GitLab CI
- Budowanie, testowanie, wdrażanie
- Kontrola i ograniczenia wykonania: only, when
- Praca z artefaktami
- Szablony w .gitlab-ci.yml, ponowne wykorzystanie działań w różnych częściach pipeline'u
- Include — sekcje
- Centralne zarządzanie gitlab-ci.yml (jeden plik i automatyczne push do pozostałych repozytoriów)
Współpraca administratorów i programistów wchodzi na nowy poziom: administrator pisze szablon CI, a programiści go modyfikują, budując swój CI niezależnie od administratora.
Zostaje zmniejszona zależność programistów od administratorów, ogranicza się ilość pracy ręcznej, znika problem „jednej osoby, która wie, jak pracować z makefilem”. Wdrażanie odbywa się niezawodnie i szybko.
IaC
Temat Infrastructure as Code na przykładzie Terraform zaprezentuje administrator chmury Selectel, Alexey Stepanenko. Pokaże, jak szybko i automatycznie uruchomić i skalować serwery, jak automatycznie pakować obrazy oraz jak korzystać z szablonów konfiguracji, aby od razu otrzymać skonfigurowane maszyny.
Człowiek, który stworzył tysiące rozwiązań IaC, opowie, jak to robić prawidłowo i jak nie powinno się tego robić.
Rozwiązanie dla chmury Selectel z minimalnymi zmianami pasuje do chmur Google i Amazon.
Pracownik Southbridge, Nikolay Mesropyan, na przykładzie Ansible pokaże, jak bez przerw w działaniu uruchomić działającą aplikację i sprawdzić jej funkcjonalność.
Jeśli ręcznie zmieniasz infrastrukturę (konfigurujesz serwery, instalujesz biblioteki, pakiety w razie potrzeby), przy próbie uruchomienia kopii środowiska musisz przypomnieć sobie i odtworzyć wszystkie swoje działania. Zadanie to zajmuje łatwo 3-5 dni. Praca z infrastrukturą jako kodem gwarantuje, że masz aktualny opis środowiska, które można uruchomić w ciągu kilku minut.
Nikolay opowie, jak pisać playbooki, jakie błędy się zdarzają, dlaczego czasami playbooki działają wolno lub nie tak, jak oczekiwano. Jest to doświadczenie wielu lat korzystania z IaC w Southbridge.
Temat nr 7: Infrastructure as Code
- IaC: podejście do infrastruktury jak do kodu
- Dostawcy chmur jako dostawcy infrastruktury
- Narzędzia do inicjalizacji systemów, budowa obrazów (packer)
- IaC na przykładzie Terraform
- Przechowywanie konfiguracji, współpraca, automatyzacja aplikacji
- Praktyka tworzenia playbooków Ansible
- Idempotencja, deklaratywność
- IaC na przykładzie Ansible
- Database as a Code / Odporność na awarie PostgreSQL
Infrastruktura zyskuje deklaratywność i idempotencję.
Administrator uczy się zarządzać złożoną infrastrukturą: szybko tworzyć nowe środowiska, utrzymywać jedność wszystkich środowisk, śledzić historię zmian, co jest kluczowe, gdy nad projektem pracuje kilka zespołów.
Programista może poznawać infrastrukturę i samodzielnie uruchamiać środowiska.
Bonus rozdziału — tworzenie i konfiguracja odpornego klastra baz danych PostgreSQL. Podamy gotowy playbook, który używamy w Southbridge; uruchomisz klaster na środowisku szkoleniowym i będziesz mógł wykorzystać to rozwiązanie w swojej firmie.
Testowanie infrastruktury i monitorowanie
Automatyzacja pozwala na wdrożenie błędu na tysiąc serwerów jednocześnie. Przy każdej zmianie niezbędne jest testowanie. Z drugiej strony, ręczne testowanie zajmuje tak dużo czasu, że niweczy zalety automatyzacji.
Pokażemy w praktyce, jak pisać testy ról. W rezultacie będziesz mógł pisać testy dla swojej firmy. Nie musisz już zapamiętywać wprowadzonych ustawień, opisujesz je w testach i automatycznie sprawdzasz, że wszystkie wcześniejsze rozwiązania i obejścia działają.
Następnie nauczymy się automatycznie dodawać wszystkie nowe serwery do monitorowania. Oddzielnie rozważymy monitorowanie infrastruktury i aplikacji. Pokażemy złe i dobre praktyki.
Temat nr 8: Testowanie infrastruktury
- Testowanie i ciągła integracja z Molecule i Gitlab CI
- Zastosowanie Vagrant
Temat nr 9: Monitorowanie infrastruktury z Prometheus
- Dlaczego potrzebujemy monitorowania
- Typy monitorowania
- Powiadomienia w systemie monitorowania
- Jak zbudować zdrowy system monitorowania
- Ludzkie powiadomienia, dla wszystkich
- Health Check: na co warto zwrócić uwagę
- Automatyzacja na podstawie danych z monitorowania
Nieprawidłowo działające monitorowanie — to brak monitorowania. Biznesowi jest obojętne, że główna strona sklepu internetowego jest dostępna, jeśli formularz płatności generuje błąd.
W konfiguracji monitorowania i rozwiązywaniu problemów programiści i administratorzy biorą udział na równi. Tradycyjnie zadania monitorowania spoczywają na administratorach. Nasz kurs pokaże programistom, jaką rolę odgrywają w tworzeniu skutecznego monitorowania. Administratorzy uzyskają najlepsze praktyki Southbridge. W rezultacie straty spowodowane awariami i opóźnieniami stron lub aplikacji szybko się zmniejszą.
Bonus sekcji: automatyzacja na podstawie monitorowania. Na przykład, monitorowanie informuje, że na stronę wzrasta obciążenie i automatycznie uruchamiane jest skalowanie serwerów WWW.
Rejestrowanie
Główny błąd w pracy z logami — administratorzy i programiści przeglądają je bezpośrednio na serwerach. Jeśli masz więcej niż jeden serwer, to trwa długo. To niebezpieczne: programista wchodzi na serwer, gdzie nie powinien być.
DevOps wymaga centralizacji zbierania, przetwarzania i analizy logów.
Temat nr 10: Logowanie aplikacji z ELK
- Główne zastosowania i możliwości elastic (wyszukiwarka, przechowywanie, cechy skalowalności, elastyczność konfiguracji)
- Przegląd kibany (główne funkcje, język zapytań, zarządzanie pulpitami nawigacyjnymi, tworzenie wykresów)
- Przegląd produktów opartych na elastic i ich zastosowanie
- Zbieranie metryk w APM (śledzenie aplikacji)
- Dodatkowo: Przegląd nowego produktu — SIEM
Wdrożenie tego podejścia uczyni logi prostym i zrozumiałym narzędziem do analizy, konfiguracji i ustawienia aplikacji oraz infrastruktury.
SRE
I dochodzimy do tematu, którym Southbridge tylko się interesuje i dla którego inni prelegenci chcą zostać na ostatni dzień Slurm. Cieszymy się, że zgodził się go przedstawić Ivan Kruglov z Booking.com.
Projekt żyje w rzeczywistym świecie, gdzie niezawodność nigdy nie jest absolutna, a każde rozwiązanie kosztuje.
Czym jest SLA w kontekście złożonego projektu? Jak ocenić, że strona jest dostępna, ale obrazy ładują się z opóźnieniem. Jakie są metryki SLA, gdzie je zbierać i jak je zbierać?
Jak ustalić SLA? Jak ich przestrzegać?
Temat nr 11: SRE
Definicja SLA, SLO, Error Budget i inne trudne terminy ze świata SRE
SRE: Praktyka monitorowania SLI i SLO
SRE: Praktyka zastosowania Error Budget
SRE: Zarządzanie przerwami i obciążeniem operacyjnym (apigateway, service mesh, circuit breakers)
Biznes chce SRE. Przynajmniej na najprostszej skali: wziąć serwer zapasowy czy przywrócić z kopii zapasowej? Jedna baza danych czy klaster? Zainstalować ochronę przed DDoS prewencyjnie czy tylko w momencie ataku?
Dyrektor nie zadowoli się opowieściami, że „strona działa”, gdy dzwoni klient i mówi, że formularz zamówienia się nie otwiera.
Dlatego dla inżyniera DevOps ważne jest, aby przynajmniej powierzchownie zrozumieć SRE, aby adekwatnie rozmawiać z biznesem o jego potrzebach.
Podsumowanie
Przez czas administratorzy i deweloperzy nauczą się:
— prawidłowo pracować z Gitem;
— organizować lokalny rozwój;
— konfigurować (administratorzy) i używać (deweloperzy) CI/CD;
— pracować z infrastrukturą jako kodem;
— testować infrastrukturę;
— monitorować infrastrukturę i aplikację;
— konfigurować logowanie;
— rozumieć, a w idealnym przypadku — używać SRE.
Dla uważnych czytelników — przy użyciu kodu promocyjnego habrapost zniżka 15%.
Przygotowujemy praktykę i narzędzia we wszystkich punktach. Tak więc każdy uczestnik, wracając z Słërm, będzie mógł wynieść swoją firmę na wyższy poziom DevOps.
Dla biznesu oznacza to tańsze zarządzanie i rozwój, zmniejszenie przestojów, wzrost niezawodności, szybsze dostarczanie funkcji oraz eliminację błędów.
Źródło: habr.com
