Задумка хорошая, но это костыль. Вместо ограничения по количеству хранимых джобов, которое есть в самой спеке, например, вы тащите сторонний инструмент или обмазываетесь скриптами.
С ручным созданием манифестов при наличии хелма вообще не ясно - это системная проблема, которую вы вообще не решаете, подпирая тем же костылем.
Короче, инструмент вроде интересный - для тех, у кого проблемы с освоением основного тулсета.
GitOps по умолчанию менее устойчив а распиздяйству, вот и всё. В чистое вон, "полный контекст в пулл реквесте", "тщательно анализируют"... Ну то классический случай столкновения хорошей идеи с реальным миром. В реальности будут пуши в ветку напрямую, десятки коммитов с комментариями "1" или "test", аппрув МР будет по принципу "вроде норм" - и не потому, что все такие плохие, а потому, что лучшие практики - это хорошо, но в беклоге ещё 100500 задач, которые нужны вчера, и надо быстро работу работать, а не (допишите сами).
Плюс один очевидный минус лично для меня - не прямая связь между " внесли изменения" и "всё упало". Если при запуске джобы в дженкинсе ты чётко видишь результат действий и джобы, то в деплое через гит, например, может стоять таймаут полчаса, за который ещё десяток коммитов будет (если команда большая или работа интенсивная). И сиди разбирайся потом, после чего именно развертывание легло. Ну и отдельные алерты на такие падения нужны, именно по этой причине.
Плюс не раскрыта тема гитопса в применении к созданию инфраструктуры, там вообще граблей миллион.
> Кубконфиг кладется в /root/.kube/config и контекст докер билда не захватывает эту папку. Или вы чтото другое имели в виду? Другое, да. Я про конфиг который web.config, его лучше монтировать как файл из configmap куба. Ну а в идеале перейти на конфигурацию из env-переменных, но это выходит за рамки этого проекта и обсуждения)
> В случае с * придется делать отдельный поддомен. А из за этого как минимум Cloudflare не будет генерировать сертификат. Но в целом тоже рабочий вариант конечно, как-то давно использовал такое
Ну тут такое, серты можно генерить другими способами. Но да, тут аргумент принимается. Просто впервые вижу использование edns для такого масштаба, удивился.
> В статье ведь был был не сложный проект как пример, схема в целом рабочая и для большего числа приложений
"В целом рабочая" - это достаточно большой класс схем с костылями и усложнениями разного масштаба. KISS - наше всё. А то посмотришь, как предыдущие девопсы в компании напилили после таких гайдов - и рыдать хочется. Мой фаворит - это докер, внутри которого puppet, который запускает ansible, который дёргает helm, который после себя вызывает kustomize, после чего ямлы идут в кластер и там изменяются с помощью мутатора в кластере. Тоже схема-то "в целом рабочая")
Вьетнамские флешбеки. Собирал когда-то такую штуку вдвоём с отцом, как раз на 8 диодов сторону. Исплевался. Проблема в том, что конструкция дюже хрупкая с неремонтопригодная: если вылетит диод внутри, надо разбирать и собирать обратно половину Куба, то есть делать под 400 паек. Так что заголовок не врет - и правда для сильных духом.
Что я только что прочитал? SMS - резервный способ оповещения! То есть если интернет есть - лучше слать через какой-то tg, а если его нет (о чем, в целом, и надо быью послать оповещение) - то и смс не уйдут. Так что коллега выше прав полностью.
Таки да. И чем меньше там контроля и понимания работы ГАП, тем более лезет трэшак и синдром "яскозал". Как сказал один мой знакомый девопёс (правда, не из МТС, но из другого крупняка), который разрабатывает "универсальную платформу для пайплайнов" - "Ты же знаешь, нашу систему приятней разрабатывать, чем использовать". Для меня это теперь исчерпывающее определение всего "крутого интеграторства", что сделано в больших ИТ и псевдо-ИТ корпорациях.
Что подробней? Про авторитарное управление? Про навязывание своих решений под соусом "всё, что вы бы не внедрили сами - хрень, наше лучше!"? Про синдром бога? Нет, нельзя, пардоньте.
Скажем так, стиль управления у них и инженерные практики такие, что в принципе ломают инженеров. Таких будет крайне тяжко учить думать самим, если нанять.
Так-то да, нативные языки лучше. Но надо учитывать такую вещь, как "отраслевой стандарт". Если вы готовы на несколько месяцев дольше искать человека в случае необходимости замены или расширения команды - то никаких проблем. Job security разными методами достигается.
И этот конфиг мы внезапно скармливаем линзе, которая запускается в винде.Она будет добросовестно пытаться выполнить эти инструкции по получению доступа, но command такая недоступна - её физически нет в PowerShell. Отсюда и ошибка. Как только мы устанавливаем в винду awscli и копируем файл с профилями входа - Lens получает возможность получить токен и успешно соединяется с кластером.
Это лично проверено на AWS, GCP и YC. Никакой магии, хотя да - не самая очевидная в мире вещь.
Ну так ещё раз - линза стартует в винде, там по умолчанию сторонние тулы типа awscli или tsh недоступны или не настроены. После синхронизации энвов конфиг можно хоть с Марса подключать. Пройденный этап)
Проблемы с линзой начинаются, если авторизация в класстер идёт через сторонние тулы типа awscli. Со всем остальным она коннектится сразу после установки.
А ещё конфиги можно указать напрямую из WSL путем прописывания в путь ссылки на скрытую шару - \\wsl$\...
Ну т.е. проблемы выглядят максимально надуманными, чисто чтобы был инфоповод. "Запоминать IP адреса" никто не пытается уже лет так 10, все используют DNS с разными вариациями балансировки, от самого DNS до какого-нить haproxy.
Простите, я правильно понимаю, что эти восторженные несколько страниц текста - это просто описание паттера проектирования архитектуры инфры с использованием "фасада", где вместо стандартного и скучного service был использован (не описанный никак) механизм какого-то другого CNI?
Нифига себе, вы уже аж три этажа себе отжали?) Молодцы.
Задумка хорошая, но это костыль. Вместо ограничения по количеству хранимых джобов, которое есть в самой спеке, например, вы тащите сторонний инструмент или обмазываетесь скриптами.
С ручным созданием манифестов при наличии хелма вообще не ясно - это системная проблема, которую вы вообще не решаете, подпирая тем же костылем.
Короче, инструмент вроде интересный - для тех, у кого проблемы с освоением основного тулсета.
DevOps возник как ответ на уход в облако? Серьёзно?
Ух ёпт, helm консервативным назвали...
GitOps по умолчанию менее устойчив а распиздяйству, вот и всё. В чистое вон, "полный контекст в пулл реквесте", "тщательно анализируют"... Ну то классический случай столкновения хорошей идеи с реальным миром. В реальности будут пуши в ветку напрямую, десятки коммитов с комментариями "1" или "test", аппрув МР будет по принципу "вроде норм" - и не потому, что все такие плохие, а потому, что лучшие практики - это хорошо, но в беклоге ещё 100500 задач, которые нужны вчера, и надо быстро работу работать, а не (допишите сами).
Плюс один очевидный минус лично для меня - не прямая связь между " внесли изменения" и "всё упало". Если при запуске джобы в дженкинсе ты чётко видишь результат действий и джобы, то в деплое через гит, например, может стоять таймаут полчаса, за который ещё десяток коммитов будет (если команда большая или работа интенсивная). И сиди разбирайся потом, после чего именно развертывание легло. Ну и отдельные алерты на такие падения нужны, именно по этой причине.
Плюс не раскрыта тема гитопса в применении к созданию инфраструктуры, там вообще граблей миллион.
> Кубконфиг кладется в /root/.kube/config и контекст докер билда не захватывает эту папку. Или вы чтото другое имели в виду?
Другое, да. Я про конфиг который web.config, его лучше монтировать как файл из configmap куба. Ну а в идеале перейти на конфигурацию из env-переменных, но это выходит за рамки этого проекта и обсуждения)
> В случае с * придется делать отдельный поддомен. А из за этого как минимум Cloudflare не будет генерировать сертификат. Но в целом тоже рабочий вариант конечно, как-то давно использовал такое
Ну тут такое, серты можно генерить другими способами. Но да, тут аргумент принимается. Просто впервые вижу использование edns для такого масштаба, удивился.
> В статье ведь был был не сложный проект как пример, схема в целом рабочая и для большего числа приложений
"В целом рабочая" - это достаточно большой класс схем с костылями и усложнениями разного масштаба. KISS - наше всё. А то посмотришь, как предыдущие девопсы в компании напилили после таких гайдов - и рыдать хочется. Мой фаворит - это докер, внутри которого puppet, который запускает ansible, который дёргает helm, который после себя вызывает kustomize, после чего ямлы идут в кластер и там изменяются с помощью мутатора в кластере. Тоже схема-то "в целом рабочая")
А смысл здесь от ансиболи? Шаблонизировать можно хелмом, тем более что конфиг в кубе можно и нужно передавать извне, а не запекать в докере.
Более того, external dns не нужен, для такого масштаба проекта проще сделать запись со * с dns.
Пока выглядит как переусложненное решение тестового задания на девопса, которое можно было сделать гораздо проще и правильнее.
Вьетнамские флешбеки. Собирал когда-то такую штуку вдвоём с отцом, как раз на 8 диодов сторону. Исплевался. Проблема в том, что конструкция дюже хрупкая с неремонтопригодная: если вылетит диод внутри, надо разбирать и собирать обратно половину Куба, то есть делать под 400 паек. Так что заголовок не врет - и правда для сильных духом.
Что я только что прочитал? SMS - резервный способ оповещения! То есть если интернет есть - лучше слать через какой-то tg, а если его нет (о чем, в целом, и надо быью послать оповещение) - то и смс не уйдут. Так что коллега выше прав полностью.
Таки да. И чем меньше там контроля и понимания работы ГАП, тем более лезет трэшак и синдром "яскозал". Как сказал один мой знакомый девопёс (правда, не из МТС, но из другого крупняка), который разрабатывает "универсальную платформу для пайплайнов" - "Ты же знаешь, нашу систему приятней разрабатывать, чем использовать". Для меня это теперь исчерпывающее определение всего "крутого интеграторства", что сделано в больших ИТ и псевдо-ИТ корпорациях.
Что подробней? Про авторитарное управление? Про навязывание своих решений под соусом "всё, что вы бы не внедрили сами - хрень, наше лучше!"? Про синдром бога? Нет, нельзя, пардоньте.
Скажем так, стиль управления у них и инженерные практики такие, что в принципе ломают инженеров. Таких будет крайне тяжко учить думать самим, если нанять.
Так-то да, нативные языки лучше. Но надо учитывать такую вещь, как "отраслевой стандарт". Если вы готовы на несколько месяцев дольше искать человека в случае необходимости замены или расширения команды - то никаких проблем. Job security разными методами достигается.
Очень интересно (нет). Пожалуйста, больше никогда не делайте на хабре подобный кликбейт.
Ожидал тут увидеть хотя бы упоминание про Эадор, но его внезапно нет. Странно.
Не затруднит)
В линухе обычно уже установлены тулы типа awscli и настроены аккаунты. И это отражено в конфиге доступа к куберу. Например, так:
И этот конфиг мы внезапно скармливаем линзе, которая запускается в винде.Она будет добросовестно пытаться выполнить эти инструкции по получению доступа, но command такая недоступна - её физически нет в PowerShell. Отсюда и ошибка. Как только мы устанавливаем в винду awscli и копируем файл с профилями входа - Lens получает возможность получить токен и успешно соединяется с кластером.
Это лично проверено на AWS, GCP и YC. Никакой магии, хотя да - не самая очевидная в мире вещь.
Ну так ещё раз - линза стартует в винде, там по умолчанию сторонние тулы типа awscli или tsh недоступны или не настроены. После синхронизации энвов конфиг можно хоть с Марса подключать. Пройденный этап)
Проблемы с линзой начинаются, если авторизация в класстер идёт через сторонние тулы типа awscli. Со всем остальным она коннектится сразу после установки.
А ещё конфиги можно указать напрямую из WSL путем прописывания в путь ссылки на скрытую шару - \\wsl$\...
Простите, а зачем использовать Terraform для установки чего-то в K8S? Helm уже отменили? Что за мода использовать инструменты не по назначению?
Ну т.е. проблемы выглядят максимально надуманными, чисто чтобы был инфоповод. "Запоминать IP адреса" никто не пытается уже лет так 10, все используют DNS с разными вариациями балансировки, от самого DNS до какого-нить haproxy.
Простите, я правильно понимаю, что эти восторженные несколько страниц текста - это просто описание паттера проектирования архитектуры инфры с использованием "фасада", где вместо стандартного и скучного service был использован (не описанный никак) механизм какого-то другого CNI?
"Миллениалы изобрели погреб".жпг