Документ обсуждает практическое применение DevOps в одной компании, включая примеры реальных проектов и необходимость автоматизации процессов. Позиционируется использование Docker для контейнеризации и интеграции различных сервисов, а также акцентируется внимание на упрощении доступа к тестовым стендам и автоматизации тестов. Основные выводы касаются важности единых образов данных, workflow и интеграции различных технологий в DevOps-процессах.

1. ДЕВОПС — ЭТО НЕ ТОЛЬКО ДЛЯ
ПРОГРАММИСТОВ
ПРАКТИЧЕСКИЕ ПРИМЕРЫ ИЗ ЖИЗНИ ОДНОЙ КОМПАНИИ
Останин Василий
2017

2. Немного о себе
• Абак-пресс
• Группа DevOps

3. Исходные данные
• 3 проекта + crm
• 7 групп разработки
• 16 тестовых
• 18 тестировщиков

5. Ресурсы
• Много железа
• Дежурный инженер
• Нагрузка на админов
• Нужен менеджер для распределения тестовых (sic!)

6. Непонятные данные
• Версионирование кода в git
• Версионирование схемы данных в
миграциях
• Версионирование данных?
• Версионирование файлов?

7. Надо быстро
• Первый прототип разворачивался 4 часа
• Надо в пределах 30, нет 15, нет 10 минут

8. Хочется удобно
• Хотим красивые кнопочки
• Хотим задавать url
• Хотим ssh
• Хотим доступ в db
• Хотим в интернете
• Хотим межпроектную интеграцию

10. Велосипед
• Нам ничего не подходит
• Кнопочки
• ACL + quotas
• cluster
• Состояния
• Пространство для творчества

11. Path of exile
• Dockerfile
• docker-compose
• Teamcity + docker-compose
• Teamcity + kontena
• Велосипед

12. Пишем велосипед
• Берем за основу другой проект (samson)
• Выкидываем лишнее
• Добавляем нужное

13. Описываем стенд
• Набор Dockerfile
• Набор yml файлов
• Часть yml файлов – docker-compose файлы

14. велосипед.yml
services: services.yml
deploy_config: deploy_config.compose.tpl.yml
urls:
Mailhog: http://mail.<%= @stand.host %>/
data_container: 'data'
code_containers:
- app
tasks:
rebuild sphinx:
command: bundle exec rake sphinx:rebuild
container: app

15. services.yml
version: '2'
services:
data:
image: private-registry.local/data:latest
db:
build:
context: ./db
app:
build:
context: ../../
dockerfile: packages/base/Dockerfile.code
mail:
image: mailhog/mailhog

16. deploy_config.yml
version: '2'
services:
data:
mem_limit: 4m
db:
mem_limit: 1024m
extends:
file: services.yml
service: db
volumes_from:
- data
app:
mem_limit: 5000m
extends:
file: services.yml
service: app
env_file: .env
volumes_from:
- data
depends_on:
- data
- redis
- db
- sphinx
- mail

17. Написали
• Нарисовали красивые
кнопочки
• Уложились в 20 минут
• Версионируем всё

22. CLOSE ENOUGH.

23. Платформа автоматизации
• Экосистема
• Максимальная гибкость

24. СТЕНД
Как это сделано: автоматизация
App container Automated anything
network & exec
shared volumes
Велосипед

25. Автотесты
• Пишем автотесты
• Упаковываем в докер вместе с
браузером
• Запускаем рядом со стендом
• Рисуем красивые кнопочки, отчёты

26. Интеграционные тесты
• Пишем автотесты
• Упаковываем в докер вместе с эмулятором
• Запускаем рядом со стендом (API)
• Рисуем красивые кнопочки, отчёты

27. Отчеты
• Пишем скрипт для сбора отчета
• Упаковываем в докер
• Продолжать или догадались? :)

28. Казалось бы при чем тут
фронты?
<@insomnia> it only takes three commands to install Gentoo
<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount
/dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-
update && . /etc/profile && emerge sync && cd /usr/portage
&& scripts/bootsrap.sh && emerge system && emerge vim &&
vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/
linux && make menuconfig && make install modules_install
&& emerge gnome mozilla-firefox openoffice && emerge grub
&& cp /boot/grub/grub.conf.sample /boot/grub/grub.conf &&
vi /boot/grub/grub.conf && grub && init 6
<@insomnia> that's the first one
(c) http://www.bash.org/?464385 2005

29. Снижаем порог вхождения
• Выдаем всем желающим по тестовому стенду
• Ставим на тестовый стенд smb
• Запускаем проект в dev режиме, копируем внутрь .git
• Понимаем, что так могут работать не только фронты

30. Feature flag
• Каждая интеграция, автоматизация или опциональный
сервис - подключаемая фича
• У нас есть полная свобода их комбинирования

32. Комбинирование фич
• smb + acceptance tests + integration tests = paranoid
mode development
• smb + reports + integration tests = давайте найдем
последнюю версию API библиотеки, с которой всё
работает
• integration tests + межпроектная интеграция = давайте
проверим, будет ли наш обновленный API работать с
остальными проектами

33. F**K YEA.

34. Чем помочь разработчику?
• Единые и обновляющиеся образы с данными
• Infrastructure as a code

35. Дампы: как это сделано
Dump container
/data/pg
/data/webdav
/data/redis
Volumes:
Dumper container
1.docker inspect
2.cp $VOLUME /tmp/$VOLUME
3.echo “COPY $VOLUME /“ >> /tmp/Dockerfile
4.echo “VOLUME $VOLUME” >> /tmp/Dockerfile
5.docker build /tmp && docker push

36. Про людей совсем далеких
от кода
• Демо стенды
• Что еще?

37. Про технологии
• Не существует серебряной пули
• Стоит начинать с простого
• Не надо бояться менять технологии

38. Про команду
• Нельзя автоматизировать то, что ты не понимаешь
• Сложно автоматизировать то, что нельзя проверить

39. Итоги
• IaC везде где можно
• Workflow
• Платформа для автоматизации чего-либо
• Ресурсы

40. Ресурсы: откуда они взялись?
• Больше нет kvm и гостевых OS
• Удалены “лишние” данные
• Оптимизация конфигурации приложения
• Базовые образы

41. Про людские ресурсы
• Тестировщики работают
• Не нужен главный по стендам
• Не нужен дежурный инженер
• Ниже нагрузка на администраторов

42. Чего не хватает в этом
докладе
• Code
• Build
• Test
• Release?

43. Q&A
Василий Останин
@bazilio91
@bazilio91
bazilio91@gmail.com