Комментарии 18
Мне кажется, пригодилось бы объяснение того, в каких случаях этот подход применим. Лично у меня без этого рецепты, как сделать контейнер из виртуалки вызывают только вопрос "Зачем?". Контейнеры же и так есть :)
У нас приоритет — запуск приложения в GKE. Но не всегда GKE подойдет, особенно в случаях если:
Вам не подойдет GKE, если ваше приложение соответствует любому из этих пунктов:
— Приложение не может быть докеризовано
— Приложению необходимо очень много ресурсов CPU и RAM
— Приложение не может быть портировано или запущено в GKE по какой-то причине
— Это база данных (тут мы предпочитаем использовать бд как сервис, но не всегда это прокатывает)
Кроме того, мы разворачиваем различные инфраструктурные сервисы в Immutable манере:
— Artifactory (мы не можем запустить его в кубах, потому что от него зависят кубы — с него пулятся docker образы)
— Gitlab (мы не можем запустить его в кубах, потому что официальный helm чарт не поддерживал работу Gitlab Pages)
— Sentry (у них поставка приложения происходит через docker-compose, очень много компонентов, clickhouse, redis, БД и тд, и нам показалось проще запустить это на виртуалке)
— Aptly (если не ошибаюсь, с докером тоже не вышло)
Но Immutable отлично подойдет для Stateless приложений. Хотя для нас интереснее Stateful, потому что все сервисы выше как раз имеют State и БД. А Stateless запускать в Immutable сам бог велел — только сделай образ и конфигуратор)
Artifactory (мы не можем запустить его в кубах, потому что от него зависят кубы — с него пулятся docker образы)
Можете. Просто разворачивается +1 кластер со служебными компонентами (вроде артифактори, Gitlab etc)
По каждому из сервисов есть что сказать.
Aptly (если не ошибаюсь, с докером тоже не вышло)
А нужен ли аптли, если есть артифактори ?
Но я не вкурсе насколько она рабочая. Никогда не пользовался.
Поясните свой вопрос. Есть два подхода. Первый kubevirt и virtual kubelet и второй — Рантайм kata containers и containerd-firecracker
Совершенно очевидное применение правила, что "задача без state лучше, чем задача со state".
Вся вот эта красота работает ровно до того момента, пока не появляется база данных. Вы не можете иметь "иммутабельную инфраструктуру" для СУБД, потому что если вы пересоздадите СУБД, она будет ровно такая же, как была, но без данных. (А где мои фоточки...?).
state на самом деле на одной базе данных не сходится. Стейты бывают разные. Сервера под объектным хранилищем, хоть и могут быть заменены, имеют state. Даже кеширующие сервера имеют state, потому что если вы тихонько дропните высоконагруженный кеширующий сервер, то вы получите высоконагруженное приложение с 90ым персентилем 500ых.
Короче, это очень вкусная неполная идея. Где можно — надо применять. К сожалению, применять можно не всюду. По объективным причинам.
ЗЫ Я не понял наезда на KVM. Совершенно так же, как в публичных облаках, можно развернуть иммутабельные виртуалки на kvm, благо современные методы оркестрации особо их не различают.
Но мы именно запускаем в Immutable Stateful сервисы, как с БД, так и с локальными стораджами. И вот это как раз самое интересное — как это реализовать в данной концепции. Если это локальный диск и приложение в единственном экземпляре, то есть варианты:
— выключить приложение, сделать снапшот диска, создать новый диск из снапшота, подключить его к новой виртуалке
— выключить старую виртуалку, подключить к новой виртуалке data диск
Конечно, все это через автоматизацию.
Что касается БД, я не зря оговорился про облако. Мы используем GCP CloudSQL — это managed MySQL, PostgreSQL и т.д. — то есть база вынесена наружу от приложения. И точно так же, как с data диском, мы можем клонировать CloudSQL инстанс с данными, поднимать для нее read реплику и промоутить в мастер и тд.
Мы не хотим каждый раз, когда мы хотим обновить Gitlab или Artifactory, поднимать базу и всю нужную инфру руками, чтобы протестировать обновление. Здесь нам помогает Immutable — мы можем получить копию прода в любой момент.
P.S. Подход подойдет и не только для инфра сервисов, но и для продуктов команд (приложений). Правда, там релизы чаще, и от даунтайма надо избавляться — здесь поможет лоад балансер, трансформация разработки и тд.
Вынесение state на volume не работает, потому что если вы потрогаете приложение, то не факт, что volume это переживёт. Почему? Потому что не все базы данных обещают прочитать формат на другой версии. Надо делать апгрейд по регламенту производителя.
Использование managed SQL — это перекладывание сложной проблемы на других. Проблема-то остаётся. Кто-то там за меня подумает про стейт, а я буду ковыряться с милыми stateless-проблемами.
Но все же это большой прогресс по сравнению с «традиционным» подходом — тут мы хотя бы отделяем state от приложения и ОС и не приходится потом этот state искать, когда он тонким слоем размазан по всей файловой системе.
При том, что бывают интересные выкрутасы, обычно системная часть себя ведёт более-менее одинаково и хорошо.
А, во, ещё контр-пример. Если у вас есть железо (хаха, я знаю, что ни у кого железа нет, баз данных нет, и вообще, лямбда и вперёд), то вы не можете иметь иммутабельную одинаковую систему на разном железе.
Ещё есть настройки сети. Разные маки, разные IP — это всё даёт чуть-чуть разные конфиги.
Понятно, что если перекладывать все сложные вещи на кого-то другого, то можно писать hello world в идеальной среде, но IRL — всё это не даёт возможности квадратно-гнездовым образом заменять всё.
Вообще, как ценная идея в дизайне — да, безусловно, но только в тех местах, где она уместна.
Перекладывание проблемы на других? А я и не спорю и отвечу: ДА. Мы используем и Kubernetes как сервис, потому что это нас избавляет от большой мороки с железным кубером, хотя администрирования даже облачного кубера добавляет уйму работы. И это круто, потому что освобождает время для имплементации новых фичей, совершенствование инфры, внедрение новых технологий — а не постоянная поддержка инфры с невозможностью развиваться.
Что касается баз данных у нас была такая идея:
1. поднять клон базы данных прода — он консистентный
2. сделать снапшот данных прода и поднять новую виртуалку с новой версией приложения (старую не трогаем)
3. настроить и запустить приложение, приложение выполнит свои миграции на клоне бд и процедуру апгрейда локальных данных и тд
4. протестировать новый стейдж
5. если все ок, повторить первые 4 пункта еще раз, но выключив перед этим прод приложение (чтобы данные не обновлялись)
Например, GCP умеет делать снапшоты дисков (и они даже консистентны, ну по крайней мере мы ни разу не натыкались, что они не были)
Я тут про то, что если, например, кластер etcd. Снепшот одной ноды не имеет смысла — за время снэпшота остальные ноды убегут вперед, а если текущая подвиснет — просто временно выкинут ее из кластера. Впрочем, immutability решает кучу других проблем, так что остается время подумать, как правильно делать бэкап с кластерных прложений.
И спасибо за статью. Все-таки Хабр еще торт )
Не рассматривали вариантов добавить в свою реализацию Immutable Infrastructure еще и Immutable OS: Flatcar Linux или Fedore CoreOS?
Можно избавиться от слоя готовки образов, а этап provision описать как конфиг для ОС(ignition) с изолированным запуском любого софта в виде контейнера. Процесс обновления в этих ОС так же реализован путем «перезагрузил и получил новый релиз». Если что-то пошло не так, 1-ой командой и перезагрузкой можно откатиться.
Не получится. Если тянуть что-то тяжелое на этапе запуска — идея с flatcar терпит крах. Получается нужно запекать максимально большое количество софта и настроек в образ, чтобы стартанули и минимальное время до готовности к работе и нет зависимости от внешней сети.
Касательно flatcar — рассматриваем его в качестве базы для кубернетеса, если ноды по сети грузятся. Тогда все красиво получается. Нода загружается, сразу в актуальную версию флеткара, джойнится к кластеру и уже после этого на неё заезжают полезные нагрузки
Неа, не рассматривали, но я посмотрю в сторону этих тулз. Спасибо за наводку)
Что такое Immutable Infrastructure