W dniach 4-6 września w Petersburgu, w sali konferencyjnej Selectel, odbyło się trzydniowe wydarzenie .
Program zbudowaliśmy w oparciu o założenie, że prace teoretyczne z zakresu DevOps, niczym podręczniki do narzędzi, każdy może przeczytać samodzielnie. Tylko doświadczenie i praktyka są interesujące: wyjaśnienie, jak to zrobić, a czego nie robić, oraz opowieść o tym, jak to robimy.
Każda firma, każdy administrator czy programista ma swój własny poziom DevOps. Niektórzy ludzie używają Gita niepoprawnie, inni implementują SRE. Kurs jest tak zorganizowany, aby każdy znalazł coś istotnego, co można wdrożyć tu i teraz.
Zaczynamy od Git, następnie przyglądamy się rozwojowi aplikacji, interakcji pomiędzy kodem a infrastrukturą, budujemy CI/CD, opisujemy infrastrukturę jako kod (IaC), testujemy powstałe rozwiązanie, konfigurujemy monitorowanie, zbieramy i badamy logi, a na koniec dochodzimy do SRE: przekształcanie niezawodności w wymierną i łatwą do zarządzania historię.
git
W dzisiejszych czasach jedynymi osobami, które nie korzystają z Gita, są ci, którzy wczoraj kupili swój pierwszy laptop. Jest to narzędzie trywialne i wszechobecne, a mimo to często spotykamy się z jego niewłaściwym użyciem: od wymuszenia push do mastera, po kopiowanie plików z Gita na serwer za pomocą Ctrl-C, Ctrl-V.
Mówimy Ci, jak nie powinieneś tego robić, jak powinieneś to robić, tak jak robią to w Southbridge.
Robimy praktykę: podstawy Gity, praca zespołowa.
Temat nr 1: Podstawy Gita
- Podstawowe polecenia git init, commit, add, diff, log, status, pull, push
- Przepływ Git, gałęzie i tagi, strategie scalania
- Praca z wieloma zdalnymi repo
Temat nr 2: Praca zespołowa z Git
- Przepływ GitHuba
- Widelec, zdalny, żądanie ściągnięcia
- Konflikty, wydania, jeszcze raz o Gitflow i innych przepływach w odniesieniu do zespołów
Materiał jest zorganizowany w taki sposób, aby administratorzy i programiści mogli od razu wdrożyć wszystkie praktyki w swojej pracy.
Z punktu widzenia DevOps właściwa praca z Gitem usprawnia i automatyzuje procesy deweloperskie i administracyjne, eliminuje szereg powtarzających się problemów i zwiększa produktywność.
Programista DevOps
Na DevOps patrzymy oczami programisty: uruchamiamy środowisko lokalne, piszemy aplikację, konfigurujemy jej monitorowanie i logowanie, testujemy lokalnie, organizujemy przechowywanie zmiennych/sekretów i odkrywanie usług, obserwujemy opentracing.
Temat #3: Praca z aplikacją z punktu widzenia deweloperskiego
- Konfigurowanie środowiska lokalnego: praktyczne zalecenia
- Napisanie mikroserwisu w Pythonie (w tym testy)
- Używanie funkcji docker-compose w rozwoju
Temat #4: Interakcja pomiędzy kodem a infrastrukturą
- Poćwicz pracę z konfiguracjami
Dzięki temu programiści zobaczą, jak kod powinien wysyłać logi, jak go testować i jak będzie debugowany w przyszłości. Administratorzy zrozumieją potrzeby programistów: jakie błędy znajdują się w kodzie, jak zorganizować testy dla programistów, jak sami przetestować projekt.
Na tym etapie zostaje rozwiązane główne zadanie DevOps: budowane jest wzajemne zrozumienie i wspólna praca pomiędzy DevOps i Ops. Jest to kluczowy krok w przejściu od podziału zadań do odpowiedzialnej współpracy.
W rezultacie wzrasta szybkość i jakość pracy.
CI / CD
Nowoczesna automatyzacja obejmuje CI/CD. Zaczniemy od przyjrzenia się ręcznej automatyzacji: pliki makefile, githooks, skrypty. Przyjrzyjmy się, kiedy narzędzia te są nadal aktualne, a kiedy nie należy ich używać.
Następnie przyjrzyjmy się najlepszym praktykom współczesnego CI na przykładzie Gitlaba.
Temat nr 5: Wprowadzenie CI/CD do automatyzacji
- Wprowadzenie do automatyzacji
- Narzędzia (bash, make, gradle)
- Używanie haków git do automatyzacji procesów
- Fabryczne linie montażowe i ich zastosowanie w IT
- Przykład budowy „ogólnego” rurociągu
- Nowoczesne oprogramowanie dla CI/CD: Drone CI, BitBucket Pipelines, Travis itp.
Temat nr 6: CI/CD: Praca z Gitlabem
- Gitlab CI – ogólnie
- Gitlab Runner, ich rodzaje i zastosowania
- Gitlab CI, funkcje konfiguracyjne, najlepsze praktyki
- Etapy Gitlab CI
- Zmienne CI Gitlaba
- Buduj, testuj, wdrażaj
- Kontrola wykonania i ograniczenia: tylko, kiedy
- Praca z artefaktami
- Szablony w .gitlab-ci.yml, ponowne wykorzystanie akcji w różnych częściach potoku
- Uwzględnij - sekcje
- Scentralizowane zarządzanie gitlab-ci.yml (jeden plik i automatyczne przesyłanie do innych repozytoriów)
Współpraca administratorów i programistów osiąga nowy poziom: administrator pisze szablon CI, a programiści go edytują, budując swój CI niezależnie od administratora.
Zmniejsza się zależność programistów od administratorów, zmniejsza się ilość pracy ręcznej i znika problem „jedynej osoby, która wie, jak pracować z plikiem make”. Rollouty przebiegają solidnie i szybko.
IaC
Temat Infrastruktura jako kod, na przykładzie Terraform, omówi administrator chmury Selectel Aleksiej Stepanenko. Pokaże Ci, jak szybko i automatycznie wdrażać i skalować serwery, jak automatycznie pakować obrazy i jak korzystać z szablonów konfiguracji, aby od razu skonfigurować maszyny.
Osoba, która stworzyła tysiące rozwiązań IaC, podpowie Ci, jak to zrobić dobrze, a czego nie.
Rozwiązanie chmurowe Selectel jest odpowiednie dla chmur Google i Amazon po minimalnych modyfikacjach.
Pracownik Southbridge Nikolai Mesropyan na przykładzie Ansible pokaże, jak wdrożyć działającą aplikację bez przestojów i sprawdzi jej wydajność.
Jeśli ręcznie edytujesz infrastrukturę (konfigurujesz serwery, instalujesz biblioteki i pakiety według potrzeb), próbując utworzyć kopię środowiska, będziesz musiał zapamiętać i odtworzyć wszystkie swoje działania. To zadanie z łatwością zajmuje 3-5 dni. Praca z infrastrukturą w postaci kodu gwarantuje, że masz aktualny opis środowiska, który można wdrożyć w ciągu kilku minut.
Nikolay powie Ci, jak pisać podręczniki, jakie błędy się zdarzają i dlaczego czasami podręczniki działają wolno lub nie zgodnie z oczekiwaniami. To doświadczenie zdobyte na przestrzeni wielu lat stosowania IaC w Southbridge.
Temat #7: Infrastruktura jako kod
- IaC: Podejście do infrastruktury jako do kodu
- Dostawcy chmury jako dostawcy infrastruktury
- Narzędzia do inicjalizacji systemu, budowania obrazu (paker)
- IaC na przykładzie Terraform
- Przechowywanie konfiguracji, współpraca, automatyzacja aplikacji
- Praktyka tworzenia podręczników Ansible
- Idempotencja, deklaratywność
- IaC na przykładzie Ansible
- Baza danych jako odporność na błędy kodu / PostgreSQL
Infrastruktura staje się deklaratywna i idempotentna.
Administrator uczy się zarządzać złożoną infrastrukturą: szybko tworzyć nowe środowiska, utrzymywać jedność wszystkich środowisk, przeglądać historię zmian, co jest krytyczne, gdy nad projektem pracuje kilka zespołów.
Deweloper może badać infrastrukturę i samodzielnie rozwijać własne środowisko.
Bonus sekcji: tworzenie i konfiguracja klastra awaryjnego baz danych PostgreSQL. Dostarczymy gotowy playbook, z którego korzystamy w Southbridge, Ty wdrożysz klaster na stanowisku szkoleniowym i będziesz mógł korzystać z tego rozwiązania w swojej firmie.
Testowanie i monitorowanie infrastruktury
Automatyzacja pozwala na wdrożenie błędu na tysiąc serwerów jednocześnie. Każda zmiana wymaga testowania. Z drugiej strony testowanie ręczne zajmuje tyle czasu, że neguje korzyści płynące z automatyzacji.
Pokażemy Ci w praktyce jak napisać testy roli. Dzięki temu będziesz mógł pisać testy dla swojej firmy. Nie musisz już pamiętać dokonanych ustawień, opisujesz je w testach i automatycznie sprawdzasz, czy wszystkie dotychczasowe rozwiązania i kule są na swoim miejscu.
Następnie nauczymy się jak automatycznie dodawać wszystkie nowe serwery do monitoringu. Przyjrzyjmy się osobno monitorowaniu infrastruktury i aplikacji. Pokażemy złe i dobre praktyki.
Temat #8: Testowanie infrastruktury
- Testowanie i ciągła integracja z Molecule i Gitlab CI
- Korzystanie z Vagranta
Temat #9: Monitorowanie infrastruktury za pomocą Prometheusa
- Dlaczego monitorowanie jest potrzebne
- Rodzaje monitoringu
- Powiadomienia w systemie monitoringu
- Jak zbudować zdrowy system monitorowania
- Powiadomienia czytelne dla człowieka, dla każdego
- Health Check: na co powinieneś zwrócić uwagę
- Automatyzacja oparta na danych monitoringowych
Monitoring, który nie działa prawidłowo, nie jest monitorowaniem. Firmom nie zależy na tym, aby strona główna sklepu internetowego była dostępna, jeśli formularz płatności wyświetla błąd.
Programiści i administratorzy uczestniczą w równym stopniu w konfigurowaniu problemów związanych z monitorowaniem i rozwiązywaniem problemów. Co więcej, tradycyjnie zadania monitorowania spadają na administratorów. Nasz kurs pokaże programistom rolę, jaką odgrywają w tworzeniu skutecznego monitoringu. Administratorzy otrzymają najlepsze praktyki Southbridge. Dzięki temu liczba strat spowodowanych awariami i spowolnieniami serwisu czy aplikacji szybko będzie spadać.
Bonus sekcji: automatyzacja oparta na monitoringu. Na przykład monitoring raportuje, że na stronę przybył ładunek, a skalowanie serwera WWW rozpoczyna się automatycznie.
Logowanie
Głównym błędem podczas pracy z logami jest to, że administratorzy i programiści przeglądają je bezpośrednio na serwerach. Jeśli masz więcej niż jeden serwer, zajmuje to dużo czasu. To nie jest bezpieczne: programista loguje się na serwer, na którym nie powinien.
DevOps wymaga scentralizowanego gromadzenia, przetwarzania i analizy logów.
Temat #10: Logowanie aplikacji za pomocą ELK
- Podstawowe zastosowania i możliwości Elastic (wyszukiwanie, przechowywanie, funkcje skalowania, elastyczność dostosowywania)
- Przegląd kibany (główne funkcje, język zapytań, zarządzanie dashboardem, tworzenie wykresów)
- Przegląd wyrobów na bazie elastycznych i ich zastosowań
- Zbieranie metryk w APM (śledzenie aplikacji)
- Dodatkowo: Recenzja nowego produktu – SIEM
Wprowadzenie takiego podejścia sprawi, że logi staną się prostym i zrozumiałym narzędziem do analizy, konfiguracji i debugowania aplikacji oraz infrastruktury.
SRE
I dochodzimy do tematu, który właśnie rzuca się w oczy Southbridge i dla którego inni prelegenci chcą zostać na ostatni dzień Slurm. Cieszymy się, że Ivan Kruglov z Booking.com zgodził się go przeczytać.
Projekt żyje w realnym świecie, gdzie niezawodność nigdy nie jest absolutna, a każda decyzja kosztuje.
Czym jest SLA w odniesieniu do złożonego projektu? Powiedzmy, jak ocenić, czy witryna jest dostępna, ale obrazy ładują się z opóźnieniem. Jakie są wskaźniki SLA, gdzie je stosować, jak je stosować?
Jak ustawić SLA? Jak im się oprzeć?
Temat nr 11: SRE
Definicja SLA, SLO, Error Budget i innych przerażających terminów ze świata SRE
SRE: Praktyki monitorowania SLI i SLO
SRE: Praktyka stosowania budżetu błędów
SRE: Zarządzanie przerwaniami i obciążeniem operacyjnym (droga kolejowa, sieć serwisowa, wyłączniki automatyczne)
Firmy chcą SRE. Przynajmniej na najprostszym poziomie: czy powinienem wziąć serwer zapasowy, czy wyjąć go z kopii zapasowej? Pojedyncza baza danych czy klaster? Czy należy instalować ochronę DDoS proaktywnie, czy tylko w momencie ataku?
Dyrektora nie zadowoli informacja, że „strona działa”, gdy klient do niego zadzwoni i zgłosi, że formularz zamówienia się nie otwiera.
Dlatego ważne jest, aby inżynier DevOps przynajmniej powierzchownie rozumiał SRE, aby odpowiednio rozmawiać z biznesem o jego potrzebach.
Łączny
W trakcie administratorzy i programiści dowiedzą się:
— działa poprawnie z Gitem;
— organizować rozwój lokalny;
— konfigurować (administratorzy) i używać (programiści) CI/CD;
— pracować z infrastrukturą jak z kodem;
— przetestować infrastrukturę;
— monitorować infrastrukturę i aplikacje;
— skonfiguruj logowanie;
— zrozumieć i najlepiej używać SRE.
Dla uważnych czytelników skorzystaj z kodu promocyjnego habrapost, aby uzyskać 15% zniżki.
Przygotowujemy praktykę i narzędzia do wszystkich punktów. Tak, aby każdy uczestnik po powrocie ze Slum mógł przenieść swoją firmę na kolejny poziom DevOps.
Dla biznesu oznacza to tańszą administrację i rozwój, krótsze przestoje, zwiększoną niezawodność, szybsze dostarczanie funkcji i eliminację błędów.
Źródło: www.habr.com
