РИТ++ 2017
Зал Сан-Паулу, 5 июня, 15:00
Тезисы:
http://ritfest.ru/2017/abstracts/2653.html
Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.
7. Суровая реальность
Монолит надо разрабатывать:
● Поддерживать старый код
● Разрабатывать новые фичи
Монолит надо тестировать:
● Тестировать новые фичи
● Интегрировать с микросервисами
11. Что не нравится?
Vagrant-окружения слишком хрупкие
Vagrant/Chef-конфигурации сильно отличаются от продакшена
Разные решения для dev- и test-сред
Тесты используют общие хранилища данных
Общие базы/сфинксы etc
18. Kubernetes — это перебор!
У нас же всего одно приложение на одном локальном сервере!
Зачем оркестрация? Мы просто хотим писать код!
19.
20. Kubernetes — это перебор!
Раздаёт IP-адреса контейнерам автоматически
kube-dns для service discovery
Ingress controller для HTTP-роутинга
Readiness probe
Heapster для мониторинга отдельных компонентов
31. Как быть с большими базами?
1. Никак — ходить в продакшен
32. Как быть с большими базами?
1. Никак — ходить в продакшен
2. Никак — поднимать пустой сервер без данных
33. Как быть с большими базами?
1. Никак — ходить в продакшен
2. Никак — поднимать пустой сервер без данных
3. Поднимать сервер без данных и накатывать тестовые данные
34. Как быть с большими базами?
1. Никак — ходить в продакшен
2. Никак — поднимать пустой сервер без данных
3. Поднимать сервер без данных и накатывать тестовые данные
4. Семплировать часть боевых данных
35. Как быть с большими базами?
1. Никак — ходить в продакшен
2. Никак — поднимать пустой сервер без данных
3. Поднимать сервер без данных и накатывать тестовые данные
4. Семплировать часть боевых данных
5. Сделать пул серверов на снапшотах файловых систем (ZFS, etc)
36. Docker commit
Не всегда образ можно собрать с помощью docker build
Например, если нужно сделать образ SphinxSearch из базы данных,
запущенной в соседнем контейнере
46. Сборка кода: когда docker build не хватает
Для сборки и запуска приложений — разный набор софта
47. Сборка кода: когда docker build не хватает
Для сборки и запуска приложений — разный набор софта
Внешние зависимости (например, собрать словарь из базы данных)
68. $ helm upgrade --install --wait release-name ./
$ echo $?
1
Readiness probe = Smoke test
Helm Kubernetes
Pod
Container
Container
Container
...
Pod Container
69. Helm: проблемы
Молодой, быстро развивающийся
Нет фидбэка в процессе установки*
go/template внутри yaml**
* https://github.com/kubernetes/helm/pull/2386
** https://github.com/ksonnet/ksonnet-lib
74. “Хочу тестовую среду, у которой будет своя база, локально поднятые
сервисы A и B, а за сервисом C пусть ходит в staging”
Условные зависимости
75. “Хочу тестовую среду, у которой будет своя база, локально поднятые
сервисы A и B, а за сервисом C пусть ходит в staging”
“Мне нужно разрабатывать новый сервис D локально и интегрировать его с
монолитом. Остальные зависимости можно вообще не поднимать”
Условные зависимости
83. vboxfs:
● Медленное чтение
● Нет поддержки смены прав внутри дерева
● inotify не работает
kubectl:
● Слишком fine-grained
● “kubectl exec” — это вам не терминал
Developer Experience: проблемы
84. Скрипт для автоматизации рутины: логи, ssh, etc
CLI-дашборд, показывающий самое важное
lsyncd вместо vboxfs
Облако вместо VirtualBox
Draft?
Developer Experience: решение
86. Что получилось?
Docker + Kubernetes + Helm (+ VirtualBox + Minikube)
Переиспользование образов при разработке и тестировании
“Legacy в коробочке”, поднимаемое одной командой локально или в кластере