4-6 сентября в Санкт-Петербурге, в конференц-зале Selectel пройдет трехдневный Слёрм DevOps.
Мы строили программу, исходя из мысли, что теоретические труды по DevOps, как и мануалы к инструментам, каждый может прочитать самостоятельно. Интересны только опыт и практика: объяснение, как делать надо и не надо, и рассказ, как делаем мы.
В каждой компании, у каждого администратора или разработчика свой уровень DevOps. Одни неправильно используют Git, другие внедряют SRE. Курс организован так, чтобы каждый нашел что-то актуальное, что можно внедрить здесь и сейчас.
Мы начинаем с 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
Инфраструктура приобретает декларативность и идемпотентность.
Администратор учится управлять сложной инфраструктурой: быстро создавать новые окружения, поддерживать единство всех окружений, видеть историю изменений, что критично, когда над проектом работает несколько команд.
Разработчик может изучать инфраструктуру, самостоятельно разворачивать себе окружения.
Бонус раздела — создание и настройка отказоустойчивого кластера баз данных PostgreSQL. Мы дадим готовый плейбук, который используем в Southbridge, вы развернете кластер на учебном стенде и сможете использовать это решение у себя в компании.
Тестирование инфраструктуры и мониторинг
Автоматизация позволяет раскатать ошибку сразу на тысячу серверов. При каждом изменении необходимо тестирование. С другой стороны, ручное тестирование занимает так много времени, что сводит на нет преимущества автоматизации.
Покажем на практике, как писать тестирование ролей. В результате вы сможете писать тесты для своей компании. Больше не надо запоминать сделанные настройки, описываете их в тестах и автоматически проверяете, что все прошлые решения и костыли на месте.
Затем научимся автоматически добавлять в мониторинг все новые серверы. Рассмотрим отдельно мониторинг инфраструктуры и приложения. Покажем плохие и хорошие практики.
Тема №8: Тестирование инфраструктуры
- Тестирование и непрерывная интеграция с Molecule и Gitlab CI
- Применение Vagrant
Тема №9: Мониторинг инфраструктуры c 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 brackers)
Бизнес хочет SRE. Хотя бы на простейшем уровне: брать резервный сервер или поднимать из бэкапа? Одна база данных или кластер? Устанавливать защиту от DDoS превентивно или только в момент атаки?
Директора не устроит рассказ о том, что «сайт работает», когда ему звонит клиент и сообщает, что форма заказа не открывается.
Поэтому DevOps-инженеру важно хотя бы поверхностно понимать SRE, чтобы адекватно говорить с бизнесом о его потребностях.
Итог
За время Слёрма DevOps администраторы и разработчики научатся:
— правильно работать с Git;
— организовывать локальную разработку;
— настраивать (администраторы) и использовать (разработчики) CI/CD;
— работать с инфраструктурой как с кодом;
— тестировать инфраструктуру;
— мониторить инфраструктуру и приложение;
— настраивать логирование;
— понимать, а в идеале — использовать SRE.
Для внимательных читателей — по промокоду habrapost скидка 15%.
По всем пунктам мы готовим практику и инструментарий. Так что каждый участник по возвращении со Слёрма сможет вывести свою компанию на следующий уровень DevOps.
Для бизнеса это означает удешевление администрирования и разработки, уменьшение даунтайма, рост надежности, более быструю доставку фич и устранение багов.
Автор: aSkobin
