Спасибо, что написали эту статью! Очень благодарен!
Очень душевно и интересно написано! Одна из лучших статей, которые читал за последнее время!
Удачи в проектах!
Возьму на себя смелость дать совет — почитайте про риск менеджмент и money менеджмент. Я бы не пытался сделать проект, если видно, что на него точно не хватит денег, а еще бывают и исключительные ситуации (извержение, карантин — отличные примеры!).
Не заглядывал сюда, простите.
kops всегда отстает по поддерживаемым версиям на одну-две версии. Но для нас это ок, мы всегда с помощью него переходим, потому что нам не нужны «только что вышедшие верси» :troll:
Зашел только чтобы поругать за «желтушность» заголовка. Давайте хабр не будет превращаться в стандартные желтые издания, которые привлекают аудиторию не значимым контекстом, а заманчивым заголовком.
«И вы не поверите, что мы увидели»
«Когда он открыл дверь, он не поверил своим глазам»
«Чтобы никогда не иметь проблем с потенцией надо всего лишь купить ...»
Тьфу, расстроился.
Под сквозным конфигурированием я имею ввиду именно возможность настраивать отдельные параметры в транзитивных зависимостях.
И да, мы пришли к такому же выводу — надо все устанавливать независимо, и самостоятельно проверять установленные зависимости.
Degasolv — посмотрю, спасибо!
1. Я рассказывал этот доклад еще до того момента, когда на MacOS был докер нормальный
2. Я сейчас не использую minikube совсем, мне он кажется не очень удобным. Поэтому я не большой знаток.
3. Если я не ошибаюсь, когда вы устанавливаете minikube, у вас используется один из гипервизоров, установленных на машине (VirtualBox, xhyve, VMWare Fusion), и не использует дефолтный докер. Т.е. у вас будет два разных докера на машине :)
Но я не эксперт в этом, могу и ошибаться
Все так!
Сперва, конечно, надо заручиться поддержкой бизнеса, но это достаточно легко аргументировать, потому что Error Budget вводится ради стабильности :)
Но мы считаем не проценты «хороших релизов», а просто считаем SLA в наших бизнес метриках (простейшее решение для API: кол-во 5xx / общее кол-во запросов). Все плохие релизы сильно снижают этот SLA.
Далее, мы выбираем, ниже какого SLA мы не разрешаем опускаться, и с помощью метода «пристального взгляда» вычисляем, на каких уровнях мы перестаем разрешать релизить новые фичи.
Лично у нас пока не сложилось до конца понимание, как сделать правильно, все до сих пор в стадии становления.
Сложно дать «сферический ответ в вакууме», все сильно зависит от многих условий:
— где вы запускаетесь (железо/облака)
— подойдет ли вам попробовать GKE или аналоги
— что значит «пощупала»? Какие-то сервисы для staging попускала?
— какая цена ошибки? Возможен ли простой в несколько часов, пока инженеры пытаются восстановить сломанную во время «щупания» систему?
— насколько много инженеров понимают инфраструктуру k8s, чтобы сделать правильный выбор конфигурационных параметров?
— насколько много долгоживущих монолитов с внутренним стейтом, которые довольно сложно перетащить на k8s?
— если запускать часть сервисов в k8s рядом с работающей системой, насколько критично возрастание latency?
И таких вопросов еще много, я просто написал самое очевидное.
Если хочется потрогать, что это вообще такое — запустите где-нибудь k8s, это сейчас реально делается в пару кликов: kubernetes.io/docs/setup/pick-right-solution
Самое сложное — что придется менять привычки разработчиков (пресловутый docker-way)
О, за Dragonfly отдельное спасибо! Мы делали подобную тулзу, но не довели ее до OpenSource, а тут уже готовое.
Да, докладу почти год уже, поэтому много что устарело (показатель активного развития k8s)
Про Helm и все окружение вокруг (Skaffold) я на РИТ++ делал доклад. rootconf.ru/moscow-rit/2018/abstracts/3539
Видео пока нет, но слайды доступны.
Проблем у Helm много, когда проекты сильно взаимосвязаны, и есть транзитивные зависимости. Их сложно конфигурировать, тестировать (да и разрабатывать).
Это один из самых частых вопросов, который мне задают.
У меня примерно следующее мнение:
— Если работаешь в одиночку, используй k8s, который кто-то другой поддерживает (GKE)
— Если нельзя иметь внешний k8s — обязательно нужно иметь команду, которая умеет его настраивать и отлаживать. Это необходимо, чтобы минимизировать время простоя когда что-то «пойдет не так».
— Если бизнес не требователен к SLA — можно и самому в одиночку настраивать и разбираться.
Очень душевно и интересно написано! Одна из лучших статей, которые читал за последнее время!
Удачи в проектах!
Возьму на себя смелость дать совет — почитайте про риск менеджмент и money менеджмент. Я бы не пытался сделать проект, если видно, что на него точно не хватит денег, а еще бывают и исключительные ситуации (извержение, карантин — отличные примеры!).
kops всегда отстает по поддерживаемым версиям на одну-две версии. Но для нас это ок, мы всегда с помощью него переходим, потому что нам не нужны «только что вышедшие верси» :troll:
«И вы не поверите, что мы увидели»
«Когда он открыл дверь, он не поверил своим глазам»
«Чтобы никогда не иметь проблем с потенцией надо всего лишь купить ...»
Тьфу, расстроился.
И да, мы пришли к такому же выводу — надо все устанавливать независимо, и самостоятельно проверять установленные зависимости.
Degasolv — посмотрю, спасибо!
2. Я сейчас не использую minikube совсем, мне он кажется не очень удобным. Поэтому я не большой знаток.
3. Если я не ошибаюсь, когда вы устанавливаете minikube, у вас используется один из гипервизоров, установленных на машине (VirtualBox, xhyve, VMWare Fusion), и не использует дефолтный докер. Т.е. у вас будет два разных докера на машине :)
Но я не эксперт в этом, могу и ошибаться
Сперва, конечно, надо заручиться поддержкой бизнеса, но это достаточно легко аргументировать, потому что Error Budget вводится ради стабильности :)
Но мы считаем не проценты «хороших релизов», а просто считаем SLA в наших бизнес метриках (простейшее решение для API: кол-во 5xx / общее кол-во запросов). Все плохие релизы сильно снижают этот SLA.
Далее, мы выбираем, ниже какого SLA мы не разрешаем опускаться, и с помощью метода «пристального взгляда» вычисляем, на каких уровнях мы перестаем разрешать релизить новые фичи.
Лично у нас пока не сложилось до конца понимание, как сделать правильно, все до сих пор в стадии становления.
— где вы запускаетесь (железо/облака)
— подойдет ли вам попробовать GKE или аналоги
— что значит «пощупала»? Какие-то сервисы для staging попускала?
— какая цена ошибки? Возможен ли простой в несколько часов, пока инженеры пытаются восстановить сломанную во время «щупания» систему?
— насколько много инженеров понимают инфраструктуру k8s, чтобы сделать правильный выбор конфигурационных параметров?
— насколько много долгоживущих монолитов с внутренним стейтом, которые довольно сложно перетащить на k8s?
— если запускать часть сервисов в k8s рядом с работающей системой, насколько критично возрастание latency?
И таких вопросов еще много, я просто написал самое очевидное.
Если хочется потрогать, что это вообще такое — запустите где-нибудь k8s, это сейчас реально делается в пару кликов:
kubernetes.io/docs/setup/pick-right-solution
Самое сложное — что придется менять привычки разработчиков (пресловутый docker-way)
Да, докладу почти год уже, поэтому много что устарело (показатель активного развития k8s)
Про Helm и все окружение вокруг (Skaffold) я на РИТ++ делал доклад.
rootconf.ru/moscow-rit/2018/abstracts/3539
Видео пока нет, но слайды доступны.
Проблем у Helm много, когда проекты сильно взаимосвязаны, и есть транзитивные зависимости. Их сложно конфигурировать, тестировать (да и разрабатывать).
У меня примерно следующее мнение:
— Если работаешь в одиночку, используй k8s, который кто-то другой поддерживает (GKE)
— Если нельзя иметь внешний k8s — обязательно нужно иметь команду, которая умеет его настраивать и отлаживать. Это необходимо, чтобы минимизировать время простоя когда что-то «пойдет не так».
— Если бизнес не требователен к SLA — можно и самому в одиночку настраивать и разбираться.
UPD: я — автор доклада.
Да, у докера есть минусы, но большинство перечисленного — это просто перегретая параноя :)