Как devops исчерпывает себя,и что будет дальше

Кирилл Вечера

Следующее поколение моделей управления программными системами

51

Кирилл Вечера

Руководитель проекта jetware.orgАвтоматизация управления программными системСборка, конфигурация, тестирование, деплой, обновление

РанееСистемное программирование: Solaris, FreeBSD, Linux

Администрирование серверов и сетей: Unix, OSPF, BGP

Разработка интернет-сервисов: C, Perl, Java, Python, Ruby

В докладе

Эволюция управления информационными системами

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

Большая100 — 100 000 серверов

Сложная10 — 100 приложений

10 — 1000 связей

100 — 10 000 библиотек и программ

Растущая0.1 — 100 обновлений в день

Современная система

ПроблемаУправлять

Обновлять

Диагностировать

Оптимизировать

Чинить

Способы организации систем

Монолитнаясистема

Распределеннаяжестко связаннаясистема

Распределеннаясвободно связаннаясистема

Монолитная система

Фиксированная конфигурация

Все в одном экземпляреСервисы

Связи

Потеря сервиса или связинарушает работу всей системыМощность ограничена

Распределенная система

Связанные компонентыКомпонентОдин сервис или несколько разных сервисов вместе

СервисыОдин или несколько экземпляров сервиса

МакроуровеньМикроуровень

Макроуровень

Типы компонентов — сервисы

Топология — связи между компонентами

Микроуровень

Внутреннее устройство компонентаПрограммы, библиотеки, настройки, данные

Связи между внутренними сервисами

Компонент внутри — монолитная подсистема

Распределенная жестко связанная система

Все предопределеноСвязи между сервисами

Привязка к оборудованию

Добавление/удаление компонентов

Реакция на аварию

УправлениеЦентрализованное

Связи планирует и назначает администратор

Распределенная свободно связанная система

Все может менятьсяСвязи между сервисами

Привязка к оборудованию

Добавление/удаление компонентов или связей

УправлениеПостоянное

Автоматическое

Централизованное

Эволюция управления системами

1. Руки

2. Скрипты

3. Инструменты

Одинаково — и монолитные системы, и жестко связанные распределенные системы

После инструментов IaC

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

Нужно средство управления на микроуровне

Свободно связанная система

Минимальные требованияАвтоматическое управлениеПривязка к оборудованию

Добавление/удаление компонентов

Изменение связей

Минимальные требования к компоненту

Переносимость

Тиражируемость

Интерфейс

Изоляция от соседей

Абстракция от оборудования

Данные хранить отдельно

Связь для других сервисов

AWS сделали привычными

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

Docker

Среда для PaaS

Инструмент разработчика

Средство запуска сервиса

Docker-контейнер как компонент системы

Легковесная замена виртуальной машиныИзоляция приложений и зависимостей

Интерфейс — сеть и данныеСтимулирует использовать immutable image

DockerfileБыстрая сборка и тиражируемость

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

Эволюция управления распределенными системами – на макроуровне

1. Руки

2. Скрипты

3. Инструменты

4. Оркестрация

5. Самоорганизация

Управление распределенными системами

4. Оркестрация ПроцессПроектирование

Планирование

Тестирование

Воплощение

АрсеналKubernetes, Marathon, Docker Swarm mode

Эволюция управления компонентами – микроуровень, монолитная система

1. Руки

2. Скрипты

3. Инструменты

4. ???

5. Самоорганизация

Эволюция управления системами

МакроуровеньОркестрация

МикроуровеньDocker ???

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

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

На самом деле

Эволюция управления системами

Распределенной системой, макроуровеньСервисным приложением, микроуровень

Docker

Kubernetes

Микроуровень, приложение-сервис

Часто обновляетсяМного зависимостей (компонентов)Программы, библиотеки, данные

Версии зависимостейИнтеграция компонентовНастройкиИнтерфейс на макроуровень

Docker для управления микроуровнем

Простой способ заготовки (provisioning)Dockerfile: shell, deb/rpm, chef/puppet/salt

Быстрый способ обновления: слоиИнтерфейс на макроуровень: рукамиИнтеграция компонентовМикросервисы: отдельные контейнеры, руками

Начинающийся проект

Старт с чистого листаСвоего кода — 0

Выбрали окружение

Пишем код, встраиваемся в окружение

Оборудования мало, сервисов мало

Пользователей малоМожем лежать, можем глючить

Подойдет Dockerfile с shell-командами

Начинающийся проект

ПереусложнениеDocker

IaC

Оркестрация

Devops

Достаточныrsync или git pull

Работающий проект

Многосвоего кода

разработчиков и команд

чужих компонентов

настроек

оборудования

РазнообразноДолгая история

Разные компонентыИ создаются в разное время

Постоянно обновляется

НельзяЛежать

Глючить

Проблемы

Несовместимость версийбаги и изменения API в новых версиях

баги и уязвимости в старых версиях

Человеческие ошибкипри обновлении

внутренних настроек

в информации для оркестрации

Беспечный ездок

Разработчик программ для корпоративных клиентов

Непрерывное тестирование и сборка приложений

Беспечный ездок

Профиль работыКастомные программные решения

Business intelligence

Несколько сотен проектовОбщие компоненты

Кастомизация для заказчика

Влиты несколько компаний

Беспечный ездок

Основной софтOracle, SAP Hana, PostgreSQL, MySQL

Java, C++, Python, JavaScript, PHP

ЕщеR, Excel, ImageMagick, по мелочи другого

ОСRHEL/Oracle Linux + свои патчи для JRE, libc, OMP и другого

Windows (уменьшается)

Беспечный ездок

Поставка клиентуSaaS

Виртуальные машины

.exe + jar

RPM-пакеты

Беспечный ездок

БылоCистемаX build серверов

Разные ОС

УправлениеСкрипты — make, shell, python

Jenkins

Puppet

Беспечный ездок

ПроблемыПлохое тестированиеДолго ждать результат редко тестируется→

Несовпадение тестового и рабочего окруженияОшибки при работе софта у заказчика

Часто ломался процесс сборки

Много ручного труда

Беспечный ездок

Что нужноХорошо контролируемая средаSaaS, Виртуальные машины

Качественная сборка и тестированиеВоспроизводимая сборка

Быстрая сборка

Минимальное ручное вмешательство

Похожее на Maven и Gradle

Беспечный ездок

ВариантыJuju Charms

Nix

Nix пакеты

Описание пакетаИмена пакетов-зависимостей

Правила сборки

Собранный пакет - чистая функция отПравил сборки

Собранных зависимостей

Исходного кода

Конфигурационных значений

Nix

Все состоит из пакетовКаждый пакетОтдельный каталог

Read-only

Собирается по зависимостямили устанавливается уже собранное из репозитория

Nix – пользовательское окружение

Точка объединения нескольких nix-пакетов

Каждое окружение — в отдельном read-only каталоге

Каждая комбинация пакетов — отдельное окружение

Установка или удаление пакетаСоздание нового окружение копированием текущего

Добавление или удаление пакета

Переключение текущего окружения на новое (замена симлинка)

Nix – пользовательское окружение

Структура окружения повторяет FHSЕсть bin, etc, lib, include, share, libexec

Нет var - ведь read-only

Симлинки из окружения на файлы в пакетах

Nix: пользовательское окружение

~/.nix-profile

/nix/store/0123-user-envbin

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

Беспечный ездок

СейчасОборудование (SaaS & CI)~ 180 машин у себя (поровну SaaS & CI)

< 200 машин в AWS (в основном CI)

500 — 2000 контейнеров

УправлениеNix + Docker + Kubernetes

Jenkins

Puppet

Беспечный ездок

Проблемы NixНет версий

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

Nix: пересборка при изменении аргументов

mysql: libc openssl

0123-libc 4567-openssl → 89ab-mysql

Пропатчили libc → cdef-libc

cdef-libc 4567-openssl → 3210-mysql

Беспечный ездок

Что искатьИмеет плюсы NixАвтоматическая сборка

Зависимости

Изоляция

Воспроизводимость

Не трогает то, что работаетВерсии, подпроекты

Беспечный ездок

ВариантыHabitat

Snappy

Gentoo

Jetware

Jetware vs Nix, что общего

Состоит из пакетовRead-only

С версиями

С вариантами сборки

Пакеты с зависимостямиАвтоматическое подключение

Автоматическая сборка

Конфигурационные переменные пакетов

Jetware vs Nix, чем отличается

Чем отличаетсяПакеты — не чистые функции

Зависимости — пакеты, версии, условия версий, роли

Самоинтеграция пакетов

Пакеты инкапсулированыэкспортируют в окружение и другие пакеты минимум

Окружение хранит контекстнастройки, данные

Jetware: Рабочее окружения

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

Jetware: Рабочее окружение

Пакеты — снаружиПакеты — неймспейсыВсе хранится в пакетахКаталог пакета — read-only

Данные и конфигурация — внутри

bin

lib

var log

etc

tmp run

libc

Конфигурация окружения

Jetware: Экспорт в рабочее окружение

Неизменяемые данныеТолько минимум

bin, lib

Симлинками bin

lib

var log

etc

tmp run

libc

Jetware: Экспорт в рабочее окружение

Изменяемые данныеКопируются в окружение

Отдельные секции

Свой собственный FHS bin

lib

var log

etc

tmp run

libc

Взаимодействие пакетов

Экспорт данных в другие пакетыОтношение, данные, соглашение или APIПример: пакеты экспортируют свои C-headers пакету cc

Значения переменных других пакетовПример: пакет mongodb_tuning указывает mongodb.port=22333

Роли пакетов

Пакет имеет рольИдентификация пакетаДля файлов

Для связей пакетов

Для экспорта данных

Для переменных

Роль - класс

percona-mysqld

mariadb-mysqld

myrocks

mysqld

mysqld

Абстрактная роль

Общий аспект разных ролей

Частично реализованный интерфейсОдин API для разных ролей

Реализация для присутствующей роли

Одно отношение пакета для всех реализаций

www

bitrixapache

nginx

lighttpd

Беспечный ездок

Демонстрационная установка JetwareСборка по зависимостям и версиямСобственных подпроектов

Компоненты третьих сторон (JRE, libc и другие библиотеки)

Репозитории testing staging→

Сборка и настройка Docker-контейнера40 — 500 пакетов

1.5 — 20 секунд

Беспечный ездок

ОжидаетсяОборудование (SaaS & CI)~ 120 машин у себя (на CI - 30)

< ? машин в AWS

УправлениеJetware + Docker + Kubernetes

Jenkins

Puppet

Эволюция управления системами

МакроуровеньОркестрация

МикроуровеньСамосборка

Что будет дальше?

Слияние управления на макроуровне и микроуровне~ 1 — 3 года

Жизненный цикл сервиса

Dev (разработчик)

Исходный код + библиотеки

Компиляция, сборка

Интеграция с зависимостями

Тестирование

Экспорт в образ

Разворачивание

Переключение нагрузки

???

Оркестрация

Нужна ли ОС программе?

Программе нужныЯдро для выполнения syscall

Файловая система

Рабочее окружениеБиблиотеки и исполняемые файлы

Другие данные-ресурсы

Окружение операционной системы — не нужно

Должна ли программа встраиваться в ОС?

Для обращения к программе нужноЗнать, где она находится

Передавать ей входные данные

Получить от нее выходные

Программа может быть где угодно — ОС не нужна

Тесная связь ОС и приложений

Историческое наследиеВлияние дистрибутивов Linux

Автономная программа

ПрограммаНе привязана к ОС

Описывает требования к рабочему окружениюЗависимости на пакеты и версии

Зависимости на ресурсы и сервисы

Рабочее окружение как процесс

Адресное пространство процессаКаталог с рабочим окружением

Сегменты кодаread-only в каталогах пакета

Сегменты данныхв изменяемых каталогах рабочего окружения

Динамическая линковка библиотекПодключение к нему всех пакетов-зависимостей

Пакет как shared библиотека

БиблиотекаФайлы .so и .aELF сегменты кода и данныхDynamic linking секции

ПакетRead-only каталогФайлы в каталогеЗависимости пакета

Тогда что такое автономная программа?

Имя с версиейЗависимости для работыИнтерфейсКакие ресурсы требует

Какие ресурсы предоставляет

Сценарий сборки (опционально)Исходники

Зависимости для сборки

Управление на макроуровне

Объект диспетчеризацииПриложение: имя и версия

Запуск программыСборка пакета или получение из репозитория

Создание рабочего окружения

Деплой и запуск сервиса

Помещение данных интерфейса в service discovery

Эволюция управления системами

Макроуровень и микроуровень интегрируются

Роботы вытесняют девопсов

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

Ну а потом?

Еще несколько лет и

Пятая ступень эволюции - самоорганизация

Как devops исчерпывает себя,и что будет дальше

Кирилл ВечераJetware

http://jetware.org