Тут лучше смотреть видос, там более подробно. Раньше мы использовали простейший shell скрипт, который проходится envsubst'ом по yaml-шаблонам. Потом стали использовать helm. Потом сделали поддержку helm в dapp.
Кстати, а как персистентность и базы разруливаете? В качестве распределенного файлового хранилища что используете, nfs (как на слайде)?
ceph, вроде я об этом в докладе рассказывал.
Базы живут у вас где, внутри kubernetes (в одном экземпляре, с маппингом на хостовую файловую систему, часть нод помечены как соделжащие базы), или же во внешнем окружении есть отдельный кластер или просто отдельная машина.
minikube — это да, но интересуют нюансы, например, как монтируются локальные директории, чтобы они были доступны в подах (при этом, желательно не плодить разны конфигурации кластера для дева и прода )? Возможно используется helm для работы поддержания 1 конфигурации в разных контурах?
Пока не придумали. Работаем над этим. Есть пачка вариантов, как делаем сейчас, но все они не нравятся:
Так-как у нас есть шеф-рецепты (dapp поддерживает), собирать одними и теми же шеф рецептами и docker-образы для прода и Vagrant'ы. Проблемы: очень долго, сложно писать универсальные рецепты.
Запускать докер контейнеры (dapp run) в Vagrant ИЛИ использовать minikube.
Можно собирать образ при каждом Ctrl-S. Проблемы: долго.
Монтировать или подключаться по SSH. Проблемы: описание правил монтирования/подключения
Разворачивать в кластере Kubernetes отдельное окружение для разработки (например давать туда доступ разработчикам, например по SSH). Проблемы: описание правил.
В целом все идет к тому, что мы будем работать над:
Ускорением сборки и деплоя. Если сократим время сборки нового образа и деплоя в minikube до 5 секунд, уже будет вполне реально передеплоивать приложение при каждом Ctrl-S.
Автомагией в dapp, которая будет понимать какие исходники куда добавлены (мы знаем это и так) и сама генерить маунты.
идеально и без проблем контейнеризуются — stateless приложения,
можно контейнеризовать, но надо смотреть плюсы минусы в каждом конкретном случае:
statefull приложения, потеря данных в которых не критична (автозаполняемые кеши, например)
statefull приложения, которые сами умеют кластер с автовосстановлением данных И там не планируется хранить очень много данных (чтобы скорость восстановления узла не была слишком большой),
statefull приложения, которые могут комфортно существовать на сетевых дисках (ebs, rds и пр.) — для которых 1000 IOPS достаточно.
с трудом и с привлечением большой магии можно запихать в контейнеры большие statefull приложения (например посредством решений такого класса: https://habrahabr.ru/company/flant/blog/326414/).
Самое важное! Положить в образ можно любой бинарник, в этом нет никакой проблемы. Запускать в Docker можно ЛЮБОЕ приложение, если речь идет об одном хосте — с этим тоже нет никакой проблемы. Однако, на одном хосте все можно и без Docker запустить, какая разница? Самое интересное и самое вкусное начинается, как только дело доходит до продакшена, которому требуются отказоустойчивость и горизонтальное масштабирование — и вот тут встает вопрос не о том, как что-то запихать в контейнер, а о том как сделать orchestration, self-healing, service discovery.
Таким образом, на сайте у нас имеется ввиду, что в общем случае мы не рекомендуем передавать под управление statefull-сервисы в Kubernetes и считаем, что технологии еще не дозрели.
Если чуть-чуть влезть в детали, например по MySQL, то по нашему мнению его можно передать под управление Kubernetes в следующих случаях:
хватает ebs/rds (хватает iops'ов) — просто один узел c MySQL и никаких проблем,
допустимо использовать Percona XtraDB Cluster И данных не слишком много (инфраструктура позволяет поднимать ноду в разумное время).
Если в контейнерах только стейтлесс приложения, там нечего бекапить. Зачем бекапить то, что перекатывается с нуля за секунды? Реджистри мы обычно используем файловы, бекапится он просто как директория с кучей файлов.
Если же в контнейнерах данные, нужно бекапить сами данные. Мы для этого используем Bacula (точнее Bareos) с кучей обвязок, но тут нет однозначного ответа. Любой инструмент, который вы уже сейчас используете, скорей всего может быть адаптирован.
Выше писал, в коментах. Миграции по-определению должны быть обратно совместимы, хотя бы в рамках одной версии. Это фундоментальное ограничение, пока не слышал никаких альтернатив.
И еще момент. Если вдруг у вас миграции блокируют базу, то тут надо менять что-то в базе или в миграциях. В миграциях можно попробовать такие инструменты как pt-online-schema-change, но лучше подумать о том, как бы уменьшить базу.
Ну и есть еще схема с Blue Green Deployment, с остановкой слейва и накатом миграции только на нем, с SQL based репликацией. Но вживую я не видел.
Да, вопрос с миграциями в базе очень важный. Решение есть, но серебрянной пули — нет. Нужно следовать одному простому правилу — миграции должны быть всегда обратносовместимы.
Катим новую версию, в ней миграции, эти миграции не должны ломать старую версию. Соответственнок катим сначала миграции, которые пусть и выполняются долго, но все продолжает работать, так как старый код с ними совместим. А уже как миграции прошли — катим новый код.
Следование этому правилу дополнительно дает возможность отката на предыдущую версию без отката базы. Это важный бонус, чтобы можно было быстро откатиться.
Какие это правило накладывает ограничения? С первого взгляда можно только добавлять колонки и только с необязательным значением. Если менять типы колонок, то только совместимо. Ну и добавлять новый таблицы безбоязненно. По началу выглядит пугающе, мол как так — мы не можем переименовать или удалить колонку. Но фактически, это надо делать редко. И это всегда можно сделать в два релиза (сначала выкатываем код, который больше не использует не нужную колонку/таблицу, а в следующем релизе — удаляем колонку/таблицу).
Ну и чтобы совсем торт был, нужно перед выкатом на стейджинг гнать базу с прода, выкатывать версию с прода, нагонять миграции и прогонять максимально расширенный смок тесты, чтобы получить какое-то формальное подтверждение, что миграции совместимы. Ну и обязательно все это автоматизировать. Вот как-то так.
Если вкратце — то сочетание graceful shutdown, встроенного в nginx, и правильно подобранного таймаута. Если это обычная статика (js, css, картинки) и обычные клиенты, то таймаут в 10 секунд норм. Если превалируют медленные клиенты (мобилки, хот споты) или большие объемы (видео блобы и пр.) — таймаут можно увеличивать. Подбирать таймаут по перцентиль 99 response time в Nginx (он как раз и включает время до последнего отданного байта).
Ну и важный момент, что Docker по умолчанию шлет SIGTERM при остановке контейнера, а Nginx'у нужно послать SIGQUIT. Как этого добиться — очень сильно зависит (используете ли какой-то супервизор, или сразу запускаете Nginx, используете голый Docker, или с какой-то оркестрацией).
Так, так и должно быть. Старые реплики остаются, но они нулевого размера. Посмотрите видос полностью, там рассказывается о том зачем и почему так.
Тут лучше смотреть видос, там более подробно. Раньше мы использовали простейший shell скрипт, который проходится envsubst'ом по yaml-шаблонам. Потом стали использовать helm. Потом сделали поддержку helm в dapp.
Это не совсем так. Мы от ceph используем в основном rbd, там нормальный multi master.
ceph, вроде я об этом в докладе рассказывал.
Все перечисленные варианты. Очень ждем https://github.com/kubernetes/features/issues/121 .
Пока не придумали. Работаем над этим. Есть пачка вариантов, как делаем сейчас, но все они не нравятся:
В целом все идет к тому, что мы будем работать над:
У нашего сборщика есть специальный флаг, --dev, ну и пачка других опция для удобной отладки.
Удивительно, но по состоянию на данный момент все наши инсталляции или на bare metal, или поверх KVM/libvirt. Основной инструмент kubeadm.
Смысл в том, что:
Самое важное! Положить в образ можно любой бинарник, в этом нет никакой проблемы. Запускать в Docker можно ЛЮБОЕ приложение, если речь идет об одном хосте — с этим тоже нет никакой проблемы. Однако, на одном хосте все можно и без Docker запустить, какая разница? Самое интересное и самое вкусное начинается, как только дело доходит до продакшена, которому требуются отказоустойчивость и горизонтальное масштабирование — и вот тут встает вопрос не о том, как что-то запихать в контейнер, а о том как сделать orchestration, self-healing, service discovery.
Таким образом, на сайте у нас имеется ввиду, что в общем случае мы не рекомендуем передавать под управление statefull-сервисы в Kubernetes и считаем, что технологии еще не дозрели.
Если чуть-чуть влезть в детали, например по MySQL, то по нашему мнению его можно передать под управление Kubernetes в следующих случаях:
В целом да, все так, и тут появляемся такие мы, продавая shared-команду DevOps'ов небольшим компаниям.
Если в контейнерах только стейтлесс приложения, там нечего бекапить. Зачем бекапить то, что перекатывается с нуля за секунды? Реджистри мы обычно используем файловы, бекапится он просто как директория с кучей файлов.
Если же в контнейнерах данные, нужно бекапить сами данные. Мы для этого используем Bacula (точнее Bareos) с кучей обвязок, но тут нет однозначного ответа. Любой инструмент, который вы уже сейчас используете, скорей всего может быть адаптирован.
Федеративный ). https://kubernetes.io/docs/concepts/cluster-administration/federation/
М? О чем речь?
У нас в планах поддержка Ansible, будем пробовать успеть до июля.
Нет, но теперь видели. Спасибо, клево!
Выше писал, в коментах. Миграции по-определению должны быть обратно совместимы, хотя бы в рамках одной версии. Это фундоментальное ограничение, пока не слышал никаких альтернатив.
И еще момент. Если вдруг у вас миграции блокируют базу, то тут надо менять что-то в базе или в миграциях. В миграциях можно попробовать такие инструменты как pt-online-schema-change, но лучше подумать о том, как бы уменьшить базу.
Ну и есть еще схема с Blue Green Deployment, с остановкой слейва и накатом миграции только на нем, с SQL based репликацией. Но вживую я не видел.
Да, вопрос с миграциями в базе очень важный. Решение есть, но серебрянной пули — нет. Нужно следовать одному простому правилу — миграции должны быть всегда обратносовместимы.
Катим новую версию, в ней миграции, эти миграции не должны ломать старую версию. Соответственнок катим сначала миграции, которые пусть и выполняются долго, но все продолжает работать, так как старый код с ними совместим. А уже как миграции прошли — катим новый код.
Следование этому правилу дополнительно дает возможность отката на предыдущую версию без отката базы. Это важный бонус, чтобы можно было быстро откатиться.
Какие это правило накладывает ограничения? С первого взгляда можно только добавлять колонки и только с необязательным значением. Если менять типы колонок, то только совместимо. Ну и добавлять новый таблицы безбоязненно. По началу выглядит пугающе, мол как так — мы не можем переименовать или удалить колонку. Но фактически, это надо делать редко. И это всегда можно сделать в два релиза (сначала выкатываем код, который больше не использует не нужную колонку/таблицу, а в следующем релизе — удаляем колонку/таблицу).
Ну и чтобы совсем торт был, нужно перед выкатом на стейджинг гнать базу с прода, выкатывать версию с прода, нагонять миграции и прогонять максимально расширенный смок тесты, чтобы получить какое-то формальное подтверждение, что миграции совместимы. Ну и обязательно все это автоматизировать. Вот как-то так.
Если вкратце — то сочетание graceful shutdown, встроенного в nginx, и правильно подобранного таймаута. Если это обычная статика (js, css, картинки) и обычные клиенты, то таймаут в 10 секунд норм. Если превалируют медленные клиенты (мобилки, хот споты) или большие объемы (видео блобы и пр.) — таймаут можно увеличивать. Подбирать таймаут по перцентиль 99 response time в Nginx (он как раз и включает время до последнего отданного байта).
Ну и важный момент, что Docker по умолчанию шлет SIGTERM при остановке контейнера, а Nginx'у нужно послать SIGQUIT. Как этого добиться — очень сильно зависит (используете ли какой-то супервизор, или сразу запускаете Nginx, используете голый Docker, или с какой-то оркестрацией).