Слёрм DevOps: от Git до SRE с всички спирки

От 4 до 6 септември в Санкт Петербург, в конференционната зала Selectel ще се проведе тридневно Slurm DevOps.

Създавахме програмата с мисълта, че теоретичните трудове по DevOps, както и ръководствата за инструментите, всеки може да прочете самостоятелно. Интересни са само опитът и практиката: обяснение как трябва и не трябва да се прави, и разказ как ние го правим.

Във всяка компания, всеки администратор или разработчик има свой собствен ниво на DevOps. Някои неправилно използват Git, докато други внедряват SRE. Курсът е организиран така, че всеки да намери нещо актуално, което може да внедри тук и сега.

Започваме с Git, после преминаваме през разработката на приложение, взаимодействието между кода и инфраструктурата, изграждане на CI/CD, описваме инфраструктурата като код (IaC), тестваме полученото решение, настройваме мониторинг, събираме и изучаваме логове, и в крайна сметка стигаме до SRE: превръщаме надеждността в измерима и управляемая история.

Git

Сега Git не използва само онзи, който вчера е купил първия си лаптоп. Това е тривиален и широко приложим инструмент, и все пак често срещаме неправилната му употреба: от принудително пушване в master, до копиране на файлове от Git на сървъра чрез Ctrl-C, Ctrl-V.

Разказваме как не трябва да се прави, как трябва да се прави, как го правят в Southbridge.
Преминаваме през практиката: основи на Git, работа в екип.

Тема №1: Основи на работа с Git

• Основни команди git init, commit, add, diff, log, status, pull, push
• Git flow, клонове и тагове, стратегии за сливане
• Работа с няколко remote repo

Тема №2: Работа в екип с Git

• GitHub flow
• Fork, remote, pull request
• Конфликти, релизи, отново за Gitflow и други flow в контекста на екипите

Материалът е организиран така, че администратори и разработчици да могат незабавно да внедрят всички практики в работата си.

От гледна точка на DevOps правилната работа с Git организира и автоматизира процесите на разработка и администриране, изключва редица повтарящи се проблеми, повишава производителността.

DevOps разработчик

Гледаме на DevOps през очите на разработчика: стартираме локално околна среда, пишем приложение, настройваме мониторинга и логването, тестваме локално, организираме съхранение на променливи/тайни и service discovery, разглеждаме трасировката (opentracing).

Тема №3: Работа с приложението от гледна точка на разработката

• Настройка на локалната среда: практически съвети
• Пишем микросервис на Python (включая тестове)
• Приложение на docker-compose в разработката

Тема №4: Взаимодействие между кода и инфраструктурата

• Практика работа с конфигурации

След края разработчиците ще видят как кодът трябва да изпраща логове, как да го тестват и как по-нататък да го отстраняват. Администраторите ще разберат нуждите на разработчиците: какви грешки в кода се появяват, как да организират тестването за разработчиците, как да тестват проекта сами.

На този етап се решава главната задача на DevOps: установява се взаимопонимание и съвместна работа между девовете и опсовете. Това е ключова стъпка към прехода от прехвърляне на задачи към отговорно взаимодействие.

В резултат на това се увеличава скоростта и качеството на работата.

CI/CD

Съвременната автоматизация предполага CI/CD. Ще започнем с това, че ще разгледаме ръчна автоматизация: makefiles, git hooks, скриптове. Ще анализираме кога тези инструменти все още са актуални, а кога не бива да се използват.

След това ще се запознаем с най-добрите практики на съвременния CI на примера на GitLab.

Тема №5: CI/CD: Въведение в автоматизацията

• Въведение в автоматизацията
• Инструменти (bash, make, gradle)
• Използване на git-hooks за автоматизиране на процесите
• Фабрични конвейерни линии за сглобяване и тяхното приложение в ИТ
• Пример за изграждане на "общ" пайплайн
• Съвременен софтуер за CI/CD: Drone CI, BitBucket Pipelines, Travis и др.

Тема №6: CI/CD: Работа с GitLab

• GitLab CI — обща информация
• GitLab Runner, техните типове и приложение
• GitLab CI, особености на настройката, най-добри практики
• Етапи на GitLab CI
• Променливи в GitLab CI
• Сглобяване, тестване, разгръщане
• Контрол и ограничения при изпълнението: only, when
• Работа с артефакти
• Шаблони в .gitlab-ci.yml, повторно използване на действия на различни места в пайплайна
• Включване — секции
• Централизирано управление на gitlab-ci.yml (един файл и автоматични push в останалите репозитории)

Съвместната работа между администраторите и разработчиците достига ново ниво: администраторът пише CI шаблона, а разработчиците го променят, изграждайки своя CI независимо от администратора.

Снижава се зависимостта на разработчиците от администраторите, намалява се количеството ръчна работа, изчезва проблемът с "единственият човек, който знае как да работи с make файла". Разгръщанията се извършват надеждно и бързо.

IaC

Темата Infrastructure as Code, разгледана от администратора на облака Selectel Алексей Степаненко, ще покаже как бързо и автоматизирано да разгръщате и скалирате сървъри, как автоматично да опаковате изображения, както и как да използвате конфигурационни шаблони, за да получите настройки на машините веднага.

Човекът, създал хиляди IaC решения, ще разкаже как да се прави правилно и какво да не се прави.

Решението на облака Selectel с минимални корекции е подходящо за облаците на Google и Amazon.

Служителят на Southbridge Николай Месропян, с примера на Ansible ще покаже как без прекъсване да разгръщате работещо приложение и да проверите неговата работоспособност.

Когато ръчно коригирате инфраструктурата (настройвате сървъри, инсталирате библиотеки и пакети при необходимост), при опит да възстановите копия на средата, трябва да си спомните и възпроизведете всичките си действия. Тази задача лесно отнема 3-5 дни. Работата с инфраструктура като с код гарантира, че имате актуално описание на средата, което може да бъде разгръщано за минути.

Николай ще разкаже как да пишете плейбуци, какви грешки могат да възникнат, защо понякога плейбуците работят бавно или не както се очаква. Това е опит от много години работа с IaC в Southbridge.

Тема №7: Infrastructure as Code

• IaC: подход за управление на инфраструктурата като код
• Облачни доставчици като доставчици на инфраструктура
• Инструменти за инициализация на системи, изграждане на образи (packer)
• IaC на примера на Terraform
• Съхранение на конфигурации, съвместна работа, автоматизация на приложения
• Практика на създаване на Ansible плейбуци
• Идемпотентност, декларативност
• IaC на примера на Ansible
• Database as a Code / Отказоустойчивост PostgreSQL

Инфраструктурата придобива декларативност и идемпотентност.
Администраторът учи как да управлява сложна инфраструктура: бързо създаване на нови среди, поддържане на единство на всички среди, виждане на история на промените, което е критично, когато по проекта работят няколко екипа.
Разработчикът може да изучава инфраструктурата, самостоятелно да разгръща среди.

Бонус на раздела — създаване и настройка на отказоустойчив кластер от бази данни PostgreSQL. Ще предоставим готов плейбук, който използваме в Southbridge, вие ще разгръщате кластера на учебен стенд и ще можете да използвате това решение във ваша компания.

Тестване на инфраструктурата и мониторинг

Автоматизацията позволява разпространение на грешката веднага на хиляда сървъра. При всяка промяна е необходимо тестване. От друга страна, ръчното тестване отнема толкова много време, че отменя предимствата на автоматизацията.

Да покажем на практика как да пишем тестове на роли. В резултат ще можете да пишете тестове за вашата компания. Вече не е нужно да запомняте направените настройки, описвате ги в тестовете и автоматично проверявате, че всички предишни решения и решенията за икономии са на място.

След това ще научим как автоматично да добавяме всички нови сървъри в мониторинга. Ще разгледаме отделно мониторинга на инфраструктурата и приложението. Ще покажем лоши и добри практики.

Тема №8: Тестване на инфраструктурата

• Тестване и непрерывна интеграция с Molecule и Gitlab CI
• Приложение на Vagrant

Тема №9: Мониторинг на инфраструктурата с Prometheus

• Защо е нужен мониторинг
• Видове мониторинг
• Уведомления в системата за мониторинг
• Как да изградим здрава система за мониторинг
• Човешки читими уведомления за всички
• Health Check: на какво да обърнете внимание
• Автоматизация на основа на данни от мониторинга

Неправилно работещият мониторинг е отсъствие на мониторинг. На бизнеса не му пука дали главната страница на онлайн магазина е достъпна, ако формата за плащане издава грешка.

В настройването на мониторинга и отстраняването на проблеми разработчиците и администраторите участват наравно. По принцип традиционно задачите за мониторинг лежат на администраторите. Нашият курс ще покаже на разработчиците каква роля играят в създаването на ефективен мониторинг. Администраторите ще получат най-добрите практики на Southbridge. В резултат на това количеството загуби, предизвикани от сривове и забавяния на сайта или приложението, бързо ще намалее.

Бонус раздела: автоматизация на основа на мониторинга. Например, мониторингът съобщава, че е постъпила натовареност на сайта, и скалируемостта на уеб сървърите стартира автоматично.

Логиране

Основната грешка в работата с логовете е, че администраторите и разработчиците ги гледат директно на сървърите. Ако имате повече от един сървър, това е бавно. Това е несигурно: разработчикът влиза на сървър, където не бива да бъде.

DevOps изисква централизирано събиране, обработка и аналитика на логовете.

Тема №10: Логиране на приложението с ELK

• Основни приложения и възможности на elastic (търсене, хранилище, особености на мащабиране, гъвкавост на настройките)
• Преглед на kibana (основни възможности, език на запитванията, управление на таблата, създаване на графики)
• Преглед на продукти на база elastic и тяхното приложение
• Събираме метрики в APM (трасировка на приложения)
• Допълнително: Преглед на новия продукт - SIEM

Внедряването на този подход ще направи логовете прост и разбираем инструмент за анализ, настройка и управление на приложения и инфраструктура.

SRE

И стигаме до темата, която Southbridge едва разглежда и поради която други лектори искат да останат до последния ден на Слёрма. Радваме се, че Иван Круглов от Booking.com се съгласи да я прочете.

Проектът живее в реалния свят, където надеждността никога не е абсолютна, а всяко решение струва пари.

Какво е SLA в контекста на сложен проект? Например, как да оценим, че сайтът е достъпен, но изображенията се зареждат със закъснение. Какви са метриките на SLA, откъде да ги вземем, как да ги измерим?

Как да установим SLA? Как да ги спазваме?

Тема №11: SRE
Определение на SLA, SLO, Error Budget и други страшни термини от света на SRE
SRE: Практика на мониторинг на SLI и SLO
SRE: Практика на прилагане на Error Budget
SRE: Управление на прекъсвания и оперативна натовареност (apigateway, service mesh, circuit breakers)
Бизнесът иска SRE. Поне на най-простото ниво: да вземе резервен сървър или да възстанови от бекъп? Една база данни или клъстер? Да настрои защита от DDoS предварително или само в момента на атака?

Директорът няма да се задоволи с обяснението, че "сайтът работи", когато клиентът му се обажда и съобщава, че формата за поръчка не се отваря.

Затова е важно DevOps инженерът поне повърхностно да разбира SRE, за да може адекватно да общува с бизнеса за неговите нужди.

Резюме

През времето Слёрма DevOps администраторите и разработчиците ще се научат:
— правилно да работят с Git;
— да организират локална разработка;
— да настроят (администратори) и използват (разработчици) CI/CD;
— да работят с инфраструктура като код;
— да тестват инфраструктурата;
— да мониторят инфраструктурата и приложението;
— да настроят логването;
— да разбират и в идеалния случай — да използват SRE.

За внимателните читатели — с промокод habrapost получавате 15% отстъпка.

По всички точки подготвяме практика и инструменти. Така че всеки участник след завръщането от Слёрма ще може да изведе своята компания на следващото ниво на DevOps.

За бизнеса това означава намаляване на разходите за администриране и разработка, намаляване на времето на неизправности, повишаване на надеждността, по-бързо доставяне на функционалности и отстраняване на бъгове.

Източник: habr.com