Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)
1 like1,333 views
Доклад Кирилла Вечера освещает эволюцию управления программными системами, акцентируя внимание на переходе от традиционного DevOps к более свободным и автоматизированным подходам, таким как использование Docker и Kubernetes. Обсуждаются проблемы управления сложными системами с множеством зависимостей и необходимость интеграции макро- и микроуровней управления. Прогнозируется, что в будущем разрабатываемые системы станут более автономными, с постепенно исчезающей ролью DevOps специалистов.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)
- 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. Самоорганизация
- 24. Можно подумать, что внутри...
- 25. На самом деле
- 26. Эволюция управления системами Распределенной системой, макроуровень Сервисным приложением, микроуровень Docker Kubernetes
- 27. Микроуровень, приложение-сервис Часто обновляется Много зависимостей (компонентов) Программы, библиотеки, данные Версии зависимостей Интеграция компонентов Настройки Интерфейс на макроуровень
- 28. Docker для управления микроуровнем Простой способ заготовки (provisioning) Dockerfile: shell, deb/rpm, chef/puppet/salt Быстрый способ обновления: слои Интерфейс на макроуровень: руками Интеграция компонентов Микросервисы: отдельные контейнеры, руками
- 29. Начинающийся проект Старт с чистого листа Своего кода — 0 Выбрали окружение Пишем код, встраиваемся в окружение Оборудования мало, сервисов мало Пользователей мало Можем лежать, можем глючить Подойдет Dockerfile с shell-командами
- 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
- 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 Автоматическая сборка Зависимости Изоляция Воспроизводимость Не трогает то, что работает Версии, подпроекты
- 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
- 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