Slurm Devops: От Git К Sre Со Всеми Остановками

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



Slurm DevOps: от Git к SRE со всеми остановками

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

Интересен только опыт и практика: объяснение, как делать и чего не делать, и рассказ о том, как мы это делаем.

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

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



Гит

Сегодня единственные люди, которые не используют Git, — это те, кто вчера купил свой первый ноутбук.

Это тривиальный и вездесущий инструмент, но мы часто видим его неправильное использование: от принудительной отправки на мастер-сервер до копирования файлов из Git на сервер через Ctrl-C, Ctrl-V. Мы рассказываем вам, как не следует этого делать, как следует это делать, как это делают в Саутбридже.

Занимаемся практикой: основы Гиты, работа в команде.

Тема №1: Основы Git

  • Основные команды git init, commit, add, diff, log, status, pull, push
  • Git-поток, ветки и теги, стратегии слияния
  • Работа с несколькими удаленными репозиториями
Тема №2: Командная работа с Git
  • Последовательность действий на GitHub
  • Форк, удаленный доступ, запрос на включение
  • Конфликты, релизы, еще раз о Gitflow и других потоках применительно к командам
Материал организован таким образом, чтобы администраторы и разработчики могли сразу внедрить все приемы в свою работу.

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



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

Смотрим на DevOps глазами разработчика: запускаем локальную среду, пишем приложение, настраиваем его мониторинг и логирование, тестируем локально, организуем хранение переменных/секретов и обнаружение сервисов, смотрим opentracing. Тема №3: Работа с приложением с точки зрения разработки
  • Настройка локальной среды: практические рекомендации
  • Написание микросервиса на Python (включая тесты)
  • Использование docker-compose в разработке
Тема №4: Взаимодействие кода и инфраструктуры.

  • Практика работы с конфигами
В результате разработчики увидят, как код должен отправлять логи, как его тестировать и как он будет отлаживаться в будущем.

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

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

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



CI/CD

Современная автоматизация предполагает CI/CD. Начнем с рассмотрения ручной автоматизации: make-файлов, githooks, скриптов.

Давайте разберемся, когда эти инструменты еще актуальны, а когда их не следует использовать.

Тогда давайте рассмотрим лучшие практики современной CI на примере Gitlab. Тема №5: Введение в CI/CD в автоматизацию.

  • Введение в автоматизацию
  • Инструменты (bash, make, gradle)
  • Использование git-хуков для автоматизации процессов
  • Заводские сборочные линии и их применение в ИТ
  • Пример построения «общего» конвейера
  • Современное ПО для CI/CD: Drone CI, BitBucket Pipelines, Travis и др.

Тема №6: CI/CD: работа с Gitlab
  • Gitlab CI — общее
  • Gitlab Runner, их виды и приложения
  • Gitlab CI, особенности настройки, лучшие практики
  • ЭШаги Gitlab CI
  • Переменные Gitlab CI
  • Сборка, тестирование, развертывание
  • Контроль исполнения и ограничения: только, когда
  • Работа с артефактами
  • Шаблоны внутри .

    gitlab-ci.yml, повторное использование действий в разных частях конвейера.

  • Включить - разделы
  • Централизованное управление gitlab-ci.yml (один файл и автоматическая отправка в другие репозитории)
Взаимодействие администраторов и разработчиков выходит на новый уровень: администратор пишет шаблон CI, а разработчики его редактируют, строя свой CI независимо от администратора.

Уменьшается зависимость разработчиков от администраторов, сокращается объем ручной работы и исчезает проблема «единственного человека, умеющего работать с make-файлом».

Внедрение происходит надежно и быстро.



IaC

Тему «Инфраструктура как код» на примере Terraform расскажет администратор облака Selectel Алексей Степаненко.

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

Человек, сделавший тысячи IaC-решений, расскажет, как делать правильно, а чего не надо.

Облачное решение Selectel подходит для облаков Google и Amazon с минимальными доработками.

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

Если вы редактируете инфраструктуру вручную (настраиваете серверы, устанавливаете библиотеки и пакеты по мере необходимости), то при попытке поднять копию среды вам придется запоминать и воспроизводить все свои действия.

Эта задача легко занимает 3-5 дней.

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

Николай расскажет, как писать плейбуки, какие ошибки случаются и почему иногда плейбуки работают медленно или не так, как ожидалось.

Это опыт многих лет использования IaC в Southbridge. Тема №7: Инфраструктура как код

  • IaC: подход к инфраструктуре как к коду
  • Поставщики облачных услуг как поставщики инфраструктуры
  • Инструменты инициализации системы, сборка образов (упаковщик)
  • IaC на примере Terraform
  • Хранение конфигурации, совместная работа, автоматизация приложений
  • Практика создания плейбуков Ansible
  • Идемпотентность, декларативность
  • IaC на примере Ansible
  • База данных как код / отказоустойчивость PostgreSQL
Инфраструктура становится декларативной и идемпотентной.

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

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



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

Автоматизация позволяет развернуть ошибку сразу на тысячу серверов.

Каждое изменение требует тестирования.

С другой стороны, ручное тестирование занимает так много времени, что сводит на нет преимущества автоматизации.

Мы на практике покажем вам, как писать ролевое тестирование.

В результате вы сможете писать тесты для своей компании.

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

Дальше мы научимся автоматически добавлять в мониторинг все новые сервера.

Давайте рассмотрим мониторинг инфраструктуры и приложений отдельно.

Мы покажем плохие и хорошие практики.

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

  • Тестирование и непрерывная интеграция с Molecule и Gitlab CI
  • Использование бродяги
Тема №9: Мониторинг инфраструктуры с помощью Prometheus
  • Зачем нужен мониторинг?
  • Виды мониторинга
  • Уведомления в системе мониторинга
  • Как построить работоспособную систему мониторинга
  • Удобочитаемые уведомления для всех
  • Проверка здоровья: на что следует обратить внимание
  • Автоматизация на основе данных мониторинга
Мониторинг, который не работает должным образом, не является мониторингом.

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

Разработчики и администраторы в равной степени участвуют в настройке мониторинга и устранении неполадок.

Более того, традиционно задачи мониторинга ложатся на администраторов.

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

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

Бонус раздела: автоматизация на основе мониторинга.

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



Ведение журнала

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

Если у вас более одного сервера, это займет много времени.

Это небезопасно: разработчик заходит на сервер там, где ему быть не должно.

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

Тема № 10: Журналирование приложений с помощью ELK

  • Основные приложения и возможности Elastic (поиск, хранение, функции масштабирования, гибкость настройки)
  • Обзор кибаны (основные функции, язык запросов, управление информационной панелью, создание диаграмм)
  • Обзор продуктов на основе эластичных материалов и их применения
  • Сбор метрик в APM (трассировка приложений)
  • Дополнительно: Обзор нового продукта — SIEM
Внедрение такого подхода сделает логи простым и понятным инструментом анализа, настройки и отладки приложения и инфраструктуры.



СРЕ

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

Мы рады, что Иван Круглов из Booking.com согласился его прочитать.

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

Что такое SLA применительно к сложному проекту? Допустим, как оценить, что сайт доступен, но изображения загружаются с задержкой.

Какие метрики SLA, где их брать, как брать? Как установить SLA? Как им противостоять? Тема № 11: СР? Определение SLA, SLO, Error Budget и других страшных терминов из мира SRE SRE: методы мониторинга SLI и SLO SRE: Практика использования бюджета ошибок SRE: управление прерываниями и операционной нагрузкой (apigateway, service mesh, автоматические выключатели) Бизнес хочет SRE. Хотя бы на самом простом уровне: брать бэкап сервера или поднимать из бэкапа? Одна база данных или кластер? Стоит ли устанавливать защиту от DDoS заранее или только во время атаки? Директора не устроит рассказ о том, что «сайт работает», когда ему звонит клиент и сообщает, что форма заказа не открывается.

Поэтому DevOps-инженеру важно хотя бы поверхностно разбираться в SRE, чтобы адекватно говорить с бизнесом о его потребностях.



Нижняя граница

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

Готовим практику и инструменты по всем пунктам.

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

Теги: #Системное администрирование #Администрирование серверов #DevOps #мероприятие #обучение #slurm

Вместе с данным постом часто просматривают: