Хабрахабр

Слёрм DevOps: от Git до SRE со всеми остановками

4-6 сентября в Санкт-Петербурге, в конференц-зале Selectel пройдет трехдневный Слёрм DevOps.

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

Одни неправильно используют Git, другие внедряют SRE. В каждой компании, у каждого администратора или разработчика свой уровень DevOps. Курс организован так, чтобы каждый нашел что-то актуальное, что можно внедрить здесь и сейчас.

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

Git

Это тривиальный и повсеместный инструмент, и тем не менее мы часто встречаем его неправильное использование: начиная от форс пуша в мастер, и заканчивая копированием файлов из Гита на сервер через Ctrl-C, Ctrl-V. Сейчас Гитом не пользуется только тот, кто вчера купил первый ноутбук.

Рассказываем, как делать не нужно, как делать нужно, как делают в Southbridge.
Проходим практику: основы Гита, командную работу.

Тема №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 глазами разработчика: запускаем локальное окружение, пишем приложение, настраиваем его мониторинг и логирование, локально тестируем его, организуем хранение переменных/секретов и service discovery, смотрим трейсинг (opentracing).

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

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

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

  • Практика работы с конфигами

Администраторы поймут нужды разработчиков: какие ошибки в коде бывают, как организовать разработчикам тестирование, как самому тестировать проект. По итогам разработчики увидят, как код должен отправлять логи, как его тестировать, как его в дальнейшем будут отлаживать.

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

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

CI/CD

Мы начнем с того, что посмотрим на ручную автоматизацию: мейкфайлы, гитхуки, скрипты. Современная автоматизация подразумевает CI/CD. Разберем, когда эти инструменты еще актуальны, а когда их не стоит использовать.

Затем посмотрим на лучшие практики современного 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 независимо от администратора.

Выкатки происходят надежно и быстро. Снижается зависимость разработчиков от администраторов, уменьшается количество ручной работы, исчезает проблема «единственного человека, который знает, как работать с мейк-файлом».

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

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

Мы дадим готовый плейбук, который используем в Southbridge, вы развернете кластер на учебном стенде и сможете использовать это решение у себя в компании. Бонус раздела — создание и настройка отказоустойчивого кластера баз данных PostgreSQL.

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

При каждом изменении необходимо тестирование. Автоматизация позволяет раскатать ошибку сразу на тысячу серверов. С другой стороны, ручное тестирование занимает так много времени, что сводит на нет преимущества автоматизации.

В результате вы сможете писать тесты для своей компании. Покажем на практике, как писать тестирование ролей. Больше не надо запоминать сделанные настройки, описываете их в тестах и автоматически проверяете, что все прошлые решения и костыли на месте.

Рассмотрим отдельно мониторинг инфраструктуры и приложения. Затем научимся автоматически добавлять в мониторинг все новые серверы. Покажем плохие и хорошие практики.

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

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

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

  • Зачем нужен мониторинг
  • Типы мониторинга
  • Уведомления в системе мониторинга
  • Как построить здоровую систему мониторинга
  • Человекочитаемые уведомления, для всех
  • Health Check: на что стоит обратить внимание
  • Автоматизация на основание данных от мониторинга

Бизнесу все равно, что главная страница интернет-магазина доступна, если форма оплаты выдает ошибку. Неправильно работающий мониторинг — это отсутствие мониторинга.

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

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

Логирование

Если у вас больше одного сервера, это долго. Основная ошибка в работе с логами — администраторы и разработчики смотрят их прямо на серверах. Это несекьюрно: разработчик заходит на сервер, где быть не должен.

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

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

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

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

SRE

Мы рады, что читать ее согласился Иван Круглов из Booking.com. И мы доходим до темы, к которой Southbridge только присматривается и ради которой другие спикеры хотят остаться на последний день Слёрма.

Проект живет в реальном мире, где надежность никогда не бывает абсолютной, и каждое решение стоит денег.

Скажем, как оценивать, что сайт доступен, но картинки грузятся с задержкой. Что такое 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, чтобы адекватно говорить с бизнесом о его потребностях.

Итог

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

Для внимательных читателей — по промокоду habrapost скидка 15%.

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

Для бизнеса это означает удешевление администрирования и разработки, уменьшение даунтайма, рост надежности, более быструю доставку фич и устранение багов.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть