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

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

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

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

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

Git

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CI/CD

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

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

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

• Въведение в автоматизацията
• Инструменти (bash, make, gradle)
• Използване на git-hooks за автоматизация на процеси
• Фабрични конвейерни линии за сглобяване и тяхното приложение в IT
• Пример за изграждане на „общ“ пайплайн
• Съвременен софтуер за 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, повторно използване на действия на различни места в пайплайна
• Include — секции
• Централизирано управление на gitlab-ci.yml (един файл и автоматични push в останалите хранилища)

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

Намалява зависимостта на разработчиците от администраторите, намалява се количеството ръчна работа, изчезва проблемът с „единствения човек, който знае как да работи с make файл“. Деплойментите се осъществяват надеждно и бързо.

IaC

Темата Infrastructure as Code на примера на Terraform ще бъде представена от облачния администратор на 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 само се ориентира и за която другите лектори искат да останат до последния ден на Slurm. Радваме се, че я прие да прочете Иван Круглов от Booking.com.

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

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

Как да зададем SLA? Как да ги спазваме?

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

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

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

Резюме

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

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

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

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

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