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

1. Как devops исчерпывает себя,
и что будет дальше
Кирилл Вечера
Следующее поколение моделей
управления программными
системами
51

2. Кирилл Вечера
Руководитель проекта jetware.org
Автоматизация управления программными систем
Сборка, конфигурация, тестирование, деплой, обновление
Ранее
Системное программирование: Solaris, FreeBSD, Linux
Администрирование серверов и сетей: Unix, OSPF, BGP
Разработка интернет-сервисов: C, Perl, Java, Python, Ruby

3. В докладе
Эволюция управления информационными
системами
Какие сейчас есть средства и какие появляются
Как мы этому способствуем
Почему девопс становится ненужным

4. Большая
100 — 100 000 серверов
Сложная
10 — 100 приложений
10 — 1000 связей
100 — 10 000 библиотек и программ
Растущая
0.1 — 100 обновлений в день
Современная система
Проблема
Управлять
Обновлять
Диагностировать
Оптимизировать
Чинить

5. Способы организации систем
Централизованная
система
Распределенная
жестко связанная
система
Распределенная
свободно связанная
система

6. Монолитная система
Фиксированная конфигурация
Все в одном экземпляре
Сервисы
Связи
Потеря сервиса или связи
нарушает работу всей системы
Мощность ограничена

7. Распределенная система
Связанные компоненты
Компонент
Один сервис или несколько разных
сервисов вместе
Сервисы
Один или несколько экземпляров
сервиса
Макроуровень
Микроуровень

8. Макроуровень
Типы компонентов —
сервисы
Топология — связи между
компонентами

9. Микроуровень
Внутреннее устройство
компонента
Программы, библиотеки,
настройки, данные
Связи между внутренними
сервисами
Компонент внутри —
монолитная подсистема

10. Распределенная жестко связанная система
Все предопределено
Связи между сервисами
Привязка к оборудованию
Добавление/удаление компонентов
Реакция на аварию
Управление
Централизованное
Связи планирует и назначает
администратор

11. Распределенная свободно связанная система
Все может меняться
Связи между сервисами
Привязка к оборудованию
Добавление/удаление
компонентов или связей
Управление
Постоянное
Автоматическое
Централизованное

12. Эволюция управления системами
1. Руки
2. Скрипты
3. Инструменты
Одинаково — и монолитные системы, и жестко
связанные распределенные системы

13. Дальше?
Переход на свободно связанные системы
Управление системой расслаивается
Нужно средство управления на макроуровне
Нужно средство управления на микроуровне

14. Свободно связанная система
Минимальные требования
Автоматическое управление
Привязка к оборудованию
Добавление/удаление
компонентов
Изменение связей

15. Минимальные требования к компоненту
Переносимость
Тиражируемость
Интерфейс
Изоляция от соседей
Абстракция от оборудования
Данные хранить отдельно
Связь для других сервисов

16. AWS сделали привычными
Разделение на сервисы
Неизменные образы виртуальных машин
Хранение данных отдельно
Несколько экземпляров сервиса

17. Docker
Среда для PaaS
Инструмент разработчика
Средство запуска сервиса

18. Docker-контейнер как компонент системы
Легковесная замена виртуальной машины
Изоляция приложений и зависимостей
Интерфейс — сеть и данные
Стимулирует использовать immutable image
Dockerfile
Быстрая сборка и тиражируемость
Выполнены все требования к компоненту
свободно связанной системы

19. Эволюция управления распределенными
системами – на макроуровне
1. Руки
2. Скрипты
3. Инструменты
4. Оркестрация
5. Самоорганизация

20. Управление распределенными системами
4. Оркестрация Процесс
Проектирование
Планирование
Тестирование
Воплощение
Арсенал
Kubernetes, Marathon, Docker Swarm
mode

21. Эволюция управления компонентами –
микроуровень, монолитная система
1. Руки
2. Скрипты
3. Инструменты
4. ???
5. Самоорганизация

22. Эволюция управления системами
Макроуровень
Оркестрация
Микроуровень
Docker ???

23. Сервис в Docker-контейнере

24. Можно подумать, что внутри...

25. На самом деле

26. Эволюция управления системами
Распределенной системой, макроуровень
Сервисным приложением, микроуровень
Docker
Kubernetes

27. Микроуровень, приложение-сервис
Часто обновляется
Много зависимостей (компонентов)
Программы, библиотеки, данные
Версии зависимостей
Интеграция компонентов
Настройки
Интерфейс на макроуровень

28. Docker для управления микроуровнем
Простой способ заготовки (provisioning)
Dockerfile: shell, deb/rpm, chef/puppet/salt
Быстрый способ обновления: слои
Интерфейс на макроуровень: руками
Интеграция компонентов
Микросервисы: отдельные контейнеры, руками

29. Начинающийся проект
Старт с чистого листа
Своего кода — 0
Выбрали окружение
Пишем код, встраиваемся в окружение
Оборудования мало, сервисов мало
Пользователей мало
Можем лежать, можем глючить
Подойдет Dockerfile с shell-командами

30. Начинающийся проект
Переусложнение
Docker
IaC
Оркестрация
Devops
Достаточны
rsync или git pull

31. Работающий проект
Много
своего кода
разработчиков и команд
чужих компонентов
настроек
оборудования
Разнообразно
Долгая история
Разные компоненты
И создаются в разное время
Постоянно обновляется
Нельзя
Лежать
Глючить

32. Проблемы
Несовместимость версий
баги и изменения API в новых версиях
баги и уязвимости в старых версиях
Человеческие ошибки
при обновлении
внутренних настроек
в информации для оркестрации

33. Беспечный ездок
Разработчик программ для корпоративных
клиентов
Непрерывное тестирование и сборка приложений

34. Беспечный ездок
Профиль работы
Кастомные программные решения
Business intelligence
Несколько сотен проектов
Общие компоненты
Кастомизация для заказчика
Влиты несколько компаний

35. Беспечный ездок
Основной софт
Oracle, SAP Hana, PostgreSQL, MySQL
Java, C++, Python, JavaScript, PHP
Еще
R, Excel, ImageMagick, по мелочи другого
ОС
RHEL/Oracle Linux + свои патчи для JRE, libc, OMP и другого
Windows (уменьшается)

36. Беспечный ездок
Поставка клиенту
SaaS
Виртуальные машины
.exe + jar
RPM-пакеты

37. Беспечный ездок
Было
Cистема
X build серверов
Разные ОС
Управление
Скрипты — make, shell, python
Jenkins
Puppet

38. Беспечный ездок
Проблемы
Плохое тестирование
Долго ждать результат редко тестируется→
Несовпадение тестового и рабочего окружения
Ошибки при работе софта у заказчика
Часто ломался процесс сборки
Много ручного труда

39. Беспечный ездок
Что нужно
Хорошо контролируемая среда
SaaS, Виртуальные машины
Качественная сборка и тестирование
Воспроизводимая сборка
Быстрая сборка
Минимальное ручное вмешательство
Похожее на Maven и Gradle

40. Беспечный ездок
Варианты
Juju Charms
Nix

41. Nix пакеты
Описание пакета
Имена пакетов-зависимостей
Правила сборки
Собранный пакет - чистая функция от
Правил сборки
Собранных зависимостей
Исходного кода
Конфигурационных значений

42. Nix
Все состоит из пакетов
Каждый пакет
Отдельный каталог
Read-only
Собирается по зависимостям
или устанавливается уже собранное из репозитория

43. Nix – пользовательское окружение
Точка объединения нескольких nix-пакетов
Каждое окружение — в отдельном read-only каталоге
Каждая комбинация пакетов — отдельное окружение
Установка или удаление пакета
Создание нового окружение копированием текущего
Добавление или удаление пакета
Переключение текущего окружения на новое (замена симлинка)

44. Nix – пользовательское окружение
Структура окружения повторяет FHS
Есть bin, etc, lib, include, share, libexec
Нет var - ведь read-only
Симлинки из окружения на файлы в пакетах

45. Nix: пользовательское окружение
~/.nix-profile
/nix/store/0123-user-env
bin
share man man8
mysqld
mysqld.8.gz
php
/nix/store/4567-mysql-5.5.50 bin mysqld
share man man8 mysqld.8.gz
share man man8 mysqld.8.gz
/nix/store/89ab-php-5.6.1 bin php

46. Беспечный ездок
Сейчас
Оборудование (SaaS & CI)
~ 180 машин у себя (поровну SaaS & CI)
< 200 машин в AWS (в основном CI)
500 — 2000 контейнеров
Управление
Nix + Docker + Kubernetes
Jenkins
Puppet

47. Беспечный ездок
Проблемы Nix
Нет версий
Пересборка всех потребителей при изменении зависимости
Долго ждать результата — бывает до 2 часов

48. Nix: пересборка при изменении аргументов
mysql: libc openssl
0123-libc 4567-openssl → 89ab-mysql
Пропатчили libc → cdef-libc
cdef-libc 4567-openssl → 3210-mysql

49. Беспечный ездок
Что искать
Имеет плюсы Nix
Автоматическая сборка
Зависимости
Изоляция
Воспроизводимость
Не трогает то, что работает
Версии, подпроекты

50. Беспечный ездок
Варианты
Habitat
Snappy
Gentoo
Jetware

51. Jetware vs Nix, что общего
Состоит из пакетов
Read-only
С версиями
С вариантами сборки
Пакеты с зависимостями
Автоматическое подключение
Автоматическая сборка
Конфигурационные переменные пакетов

52. Jetware vs Nix, чем отличается
Чем отличается
Пакеты — не чистые функции
Зависимости — пакеты, версии, условия версий, роли
Самоинтеграция пакетов
Пакеты инкапсулированы
экспортируют в окружение и другие пакеты минимум
Окружение хранит контекст
настройки, данные

53. Jetware: Рабочее окружения
Точка подключения пакетов
Хранение настроек и данных пакетов
Отвязано от операционной системы
работает непосредственно в любой ОС
libc — пакет

54. Jetware: Рабочее окружение
Пакеты — снаружи
Пакеты — неймспейсы
Все хранится в пакетах
Каталог пакета — read-only
Данные и конфигурация
— внутри
bin
lib
var log
etc
tmp run
libc
Конфигурация
окружения

55. Jetware: Экспорт в рабочее окружение
Неизменяемые данные
Только минимум
bin, lib
Симлинками
bin
lib
var log
etc
tmp run
libc

56. Jetware: Экспорт в рабочее окружение
Изменяемые данные
Копируются в окружение
Отдельные секции
Свой собственный FHS
bin
lib
var log
etc
tmp run
libc

57. Взаимодействие пакетов
Экспорт данных в другие пакеты
Отношение, данные, соглашение или API
Пример: пакеты экспортируют свои C-headers пакету cc
Значения переменных других пакетов
Пример: пакет mongodb_tuning указывает mongodb.port=22333

58. Роли пакетов
Пакет имеет роль
Идентификация пакета
Для файлов
Для связей пакетов
Для экспорта данных
Для переменных
Роль - класс
percona-mysqld
mariadb-mysqld
myrocks
mysqld
mysqld

59. Абстрактная роль
Общий аспект разных ролей
Частично реализованный интерфейс
Один API для разных ролей
Реализация для присутствующей роли
Одно отношение пакета для всех
реализаций
www
bitrix
apache
nginx
lighttpd

60. Беспечный ездок
Демонстрационная установка Jetware
Сборка по зависимостям и версиям
Собственных подпроектов
Компоненты третьих сторон (JRE, libc и другие библиотеки)
Репозитории testing staging→
Сборка и настройка Docker-контейнера
40 — 500 пакетов
1.5 — 20 секунд

61. Беспечный ездок
Ожидается
Оборудование (SaaS & CI)
~ 120 машин у себя (на CI - 30)
< ? машин в AWS
Управление
Jetware + Docker + Kubernetes
Jenkins
Puppet

62. Эволюция управления системами
Макроуровень
Оркестрация
Микроуровень
Самосборка

63. Что будет дальше?
Слияние управления на макроуровне и
микроуровне
~ 1 — 3 года

64. Жизненный цикл сервиса
Dev (разработчик)
Исходный код + библиотеки
Компиляция, сборка
Интеграция с зависимостями
Тестирование
Экспорт в образ
Разворачивание
Переключение нагрузки
???
Оркестрация

65. Нужна ли ОС программе?
Программе нужны
Ядро для выполнения syscall
Файловая система
Рабочее окружение
Библиотеки и исполняемые файлы
Другие данные-ресурсы
Окружение операционной системы — не нужно

66. Должна ли программа встраиваться в ОС?
Для обращения к программе нужно
Знать, где она находится
Передавать ей входные данные
Получить от нее выходные
Программа может быть где угодно — ОС не нужна

67. Тесная связь ОС и приложений
Историческое наследие
Влияние дистрибутивов Linux

68. Автономная программа
Программа
Не привязана к ОС
Описывает требования к рабочему окружению
Зависимости на пакеты и версии
Зависимости на ресурсы и сервисы

69. Рабочее окружение как процесс
Адресное пространство процесса
Каталог с рабочим окружением
Сегменты кода
read-only в каталогах пакета
Сегменты данных
в изменяемых каталогах рабочего окружения
Динамическая линковка библиотек
Подключение к нему всех пакетов-зависимостей

70. Пакет как shared библиотека
Библиотека
Файлы .so и .a
ELF сегменты кода и данных
Dynamic linking секции
Пакет
Read-only каталог
Файлы в каталоге
Зависимости пакета

71. Тогда что такое автономная программа?
Имя с версией
Зависимости для работы
Интерфейс
Какие ресурсы требует
Какие ресурсы предоставляет
Сценарий сборки (опционально)
Исходники
Зависимости для сборки

72. Управление на макроуровне
Объект диспетчеризации
Приложение: имя и версия
Запуск программы
Сборка пакета или получение из репозитория
Создание рабочего окружения
Деплой и запуск сервиса
Помещение данных интерфейса в service discovery

73. Эволюция управления системами
Макроуровень и микроуровень интегрируются

74. Роботы вытесняют девопсов
Разрабочики и администраторы возвращаются к
более интеллектуальному труду

75. Ну а потом?
Еще несколько лет и
Пятая ступень эволюции - самоорганизация

76. Как devops исчерпывает себя,
и что будет дальше
Кирилл Вечера
http://jetware.org
Skype: kirill.vechera
cv-c@jetware.org