Спасибо, интересная статья и решение поставленных задач. Особенно полезны дальнейшие планы, так как это именно то, что хотелось бы посоветовать. Я про Pulumi как единое решение для IaC, а также замена TailScale на self-hosted решение.
Да, и кажется это самый распространённый вариант решения данной проблемы. Тут можно отметить, что с не давних пор можно импортировать ресурс не только с помощью CLI, но и из кода. Но это всё равно выглядит как костыль, провиженинг бакета для стейта было бы оптимально создавать в рамках того же стека, иначе бакет может изначально быть создан с неравильными параметрами, например шифрованием, который требует пересоздание бакета. А пересоздание с тем же именем может быть невозможно из-за временного лага, который есть на стороне провайдера облачной инфраструктуры (в AliCloud с таким сталкивался).
Немного удивлён разнообразию в статье. Сперва азы, скажем так, для домохозяйки, а потом погрузились в IPS и обучение сотрудников.
Я бы добавил, что заниматься безопасностью надо аккуратно, чтобы не закончилось всё потерей доступа ко всем сервисам / учёткам, если завтра в автобусе забудешь телефон с ноутбуком, то есть основное хранилище и второй фактор исчезнут, а резервные копии зашифрованы и к ним доступ не получить / не расшифровать.
У пользователя может быть активная сессия где-то в забытой вкладке терминала, ей и можно воспользоваться. Выдуманная ситуация перестаёт быть столь выдуманной, пару раз я встречался с исчерпанием PIDов, правда это было достаточно давно.
Боюсь, при отсутствии свободных процессов, логирование может отвалиться и полноценную диагностику провести не будет возможности. А причиной может быть, как упомянуто выше, малварь или иная зараза из вне. Значит надо обращаться к безопасникам и уже с ними решать проблему.
Как всё странно, хакер в долгую проходил интервью, устроился, дождался рабочий ноут и, внимание, топорно стал атаковать сеть работодателя. Звучит очень странно, поработал бы хоть пару месяцев, ознакомился бы с сетью получше, попробовал бы менее вызывающие варианты атак, прежде чем расчехлять набор юного хакера.
В зависимости от должности этот хакер мог бы выведать куда больше ценной информации либо о работодателе, либо о клиентах.
Хотелось бы в этой статье раскрыть тему курицы и яйца. Вы говорите как важно и полезно хранить state в бакете и даже создаёте такой букет, но где же хранится state данного TF стэка? Локально? В другом бакете?
Интересно, насколько сильно такой подход увеличивает нагрузку в ситуации с большим кол-вом запущенных процессов, ведь поиск свободного числа случайным образом не оптимален. В прошлом сталкивался с ситуациями, когда приложение упиралось в ограничение PID'ов, приходилось повышать лимит.
Сейчас глянул, на домашнем ноутбуке лимит по-умолчанию соответствует максимуму, то есть 4194304.
Да, действительно, в личных целях снова можно использоваться, НО при этом отключена поддержка расширений: https://k8slens.dev/pricing . Это как Firefox использовать без расширений, можно, но зачем? Сегодня попробовал упомянутый headlamp, вполне годное приложение и шустрое, что приятно удивило.
Пошёл искать, что за зверь такой - Python-Terrascript, а он не развивается уже несколько лет. Так себе инструмент для сравнения. Да и в целом проблема не такая большая, как описывается в статье. Да, в некоторых случаях приходится писать некрасивый код и костылять для Terraform, но в целом описание инфраструктуры достаточно наглядное и понятное.
Поясните тем, кто не в теме, в чём цель создания данного двигателя? Эволюционное улучшение существующего или замена в связи с ограничениями поставок компонентов?
Хотелось бы почитать больше аргументов за и против, иначе всё действительно скатывается в простой посыл - с чем команда умеет работать, такие инструменты и надо выбирать. И дело не только в Кубере, команда может банально не уметь в контейнеры. Накатили jBoss application server, залили через ГУЙ артефакты и готово. Другое дело, что надо думать и о среднесрочной перспективе с автоматизациями. Тут-то Кубер и может быть одним из инструментов. Особенно, если взять облако и не тратить силы на поддержку.
То же самое и с кубом. Сейчас подавляющее большинство Go, Java и еще что там разработчиков приходит на собеседования со знанием контейнеров, докера, кубера, пониманием CI/CD и прочего. Это тот уровень абстракции, на котором работает сегодняшний программист (ну скажем, 80% программистов). Завтрашний работает на уровне примитивов Istio и Knative, послезавтрашний - на основе примитивов девелопера в рамках ролевой модели Dapr.
Смею не согласиться со знаниями сегодняшних программистов. Очень многие до сих пор пилят не контейнеризованные приложения. А из тех, кто пилят под контейнеры, мало понимают в них. Люди хорошо секут в конкретном языке программирования + выучили несколько команд как собрать контейнер и залить в репозиторий. А в худшем случае и их не знают, так как сборкой занимается CI/CD.
Я тут хочу подчеркнуть, что говорю не про senior developer'ов, а про обычных разрабов, которые занимаются разработкой как ремеслом, а после рабочего дня занимаются не программированием.
Докер и кубер создали общую абстракцию, за которую убрано очень много инфраструктурных нюансов - ОС, диск, сеть, логирование и скейлинг, перезапуск умерших сервисов и так далее. Это приводит к тому, что отдельному разработчику не нужно париться над этими задачами и выдумывать велосипеды/использовать зоопарк библиотек для их решения. То есть область, в которой работает разработчик, сужается до фактически написания бизнес-логики, остальное улетает за абстракции.
Нечто схожее можно сказать и про JVM. Да, перезапуска умерших сервисов в ней нет, но это далеко не всегда задача разработчика. Есть опсы, которые оборачивают сервис и виртуалку мониторингом и скриптами по обслуживанию. Так что тут в целом для разработчика меняется шило на мыло.
Такие решения как раз позволяют иметь меньше "свистелок" в проекте. Условный Dapr абстрагирует pub/sub и key-value за единый интерфейс. Нужно асинхронно слать эвент - берешь dapr pub/sub api, нужно закешировать данные - берешь dapr kv api. Решение требует минут вместо часов и дней, как было раньше, и въехать в код приложения быстрее и проще. А что там за имплементация pub/sub и key-value уже будет самый опытный инженер в команде думать, исходя из требований проекта.
Здесь не стану спорить, я пока не разбирался с этими решениями. Правда, говоря про докрутки над Кубером, скажем тот же Istio, то всерьёз приходится задумываться над усложнением общей инфраструктуры. Ведь должны быть спецы, которые смогут обновить уже не только Кубер, который выходит раз в квартал, но ещё и Istio. В этих проектах периодически меняется синтаксис, поэтому необходимо следить за всем этим делом. Да, мы опять говорим по 2-3 спецов, которые будут помогать команде, но нагрузка на них всё растёт и растёт.
Знаний, которые нужно держать в голове архитектору/техлиду, всегда было много, просто одни устаревают, а другие появляются. От этого никуда не уйти.
Не спорю, этим ребятам надо идти в ногу со временем, ковырятся в новомодных технологиях и уметь донести их до руководства и исполнителей. Жаль, 24-х часов в сутках не всегда хватает для всех этих хотелок, а также всего того, что происходит вне ИТ мира.
Знаний же в головах начинающих инженеров нужно даже меньше, чем раньше - уметь писать на своем ЯП, понимать особенности работы в контейнере (стейтлесс, грейсфул шатдаун, параллельная работа нескольких реплик), ну и неизменные вещи вроде ACID транзакций и лучших практик программирования.
Возможно мне попадались неправильные начинающие разработчики и даже консультанты, поскольку не все знали, что существует telnet, которым можно проверить доступность удалённого сервиса. Да что там telnet, просто сам факт такой проверки. В итоге всё, что выходит за рамки написания кода афишируется как блокер, флажок в джире и лапки к верху. Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Так-то оно так, вот только те самые дорогущие программисты всё меньше понимают, как эта балалайка работает. В итоге на вхождение человека в проект тратятся месяцы. Точнее не так, никто месяцы не тратит, новичок долбит вопросами лида, ведь самому в этом не разобраться. И я не про бизнес логику конкретного приложения/сервиса, а про архитектуру и как всё накручено. У каждого проекта свой набор свистелок, которые обеспечивают mesh и прочит хотелки.
Я понимаю, что все эти хотелки не из пальца высосаны, но то количество знаний, что необходимо держать в голове с трудом туда помещается.
Судя по предложенной архитектуре будущих приложений, дополнительные затраты на то, чтобы приложение крутилось в Кубере, увеличится ещё больше и скоро достигнет 50%. Облачные провайдеры будут рады такому раскладу. Да и обычные продавцы железа тоже.
Про javadoc глупость какая-то написана. Я хоть и не разработчик, но не так давно надо было править старый монолит и именно благодаря javadoc удалось легко найти необходимый метод и исправить.
Также допущение о доступности исходного кода звучит странно. А если исходники не доступны, то как смотреть на javadoc? Его достаточно легко экспортировать и отдать вместе с продуктом. Опять же, когда над кодом может работать множество людей, javadoc хоть как-то организует разработчиков одинакого документировать код.
С тех пор, как Adrian Cantrill ушёл из Linux Academy и их купили ACG, не могу порекоммендовать их курс. По курсу Адриана получил Solutions Architect Professional, по курсу ACG получил SysOps Associate, девелопера не получилось сдать, так как Pearson Vue заглючил в день сдачи.
По тестам могу порекоммендовать Job Bonso, его тесты есть как на Udemy, так и на его сайте: tutorialsdojo.com. На Udemy сайт получше, тесты не сбиваются, если решаешь один тест в течении двух дней. Но автор получает меньше гонорар за свои труды.
Что касается подготовки в целом, то конечно надо учить материалы, работать руками, читать whitepaper'ы, если такие есть. И гонять тесты, без них никак.
Спасибо, интересная статья и решение поставленных задач. Особенно полезны дальнейшие планы, так как это именно то, что хотелось бы посоветовать. Я про Pulumi как единое решение для IaC, а также замена TailScale на self-hosted решение.
Да, и кажется это самый распространённый вариант решения данной проблемы. Тут можно отметить, что с не давних пор можно импортировать ресурс не только с помощью CLI, но и из кода. Но это всё равно выглядит как костыль, провиженинг бакета для стейта было бы оптимально создавать в рамках того же стека, иначе бакет может изначально быть создан с неравильными параметрами, например шифрованием, который требует пересоздание бакета. А пересоздание с тем же именем может быть невозможно из-за временного лага, который есть на стороне провайдера облачной инфраструктуры (в AliCloud с таким сталкивался).
Немного удивлён разнообразию в статье. Сперва азы, скажем так, для домохозяйки, а потом погрузились в IPS и обучение сотрудников.
Я бы добавил, что заниматься безопасностью надо аккуратно, чтобы не закончилось всё потерей доступа ко всем сервисам / учёткам, если завтра в автобусе забудешь телефон с ноутбуком, то есть основное хранилище и второй фактор исчезнут, а резервные копии зашифрованы и к ним доступ не получить / не расшифровать.
У пользователя может быть активная сессия где-то в забытой вкладке терминала, ей и можно воспользоваться. Выдуманная ситуация перестаёт быть столь выдуманной, пару раз я встречался с исчерпанием PIDов, правда это было достаточно давно.
Боюсь, при отсутствии свободных процессов, логирование может отвалиться и полноценную диагностику провести не будет возможности. А причиной может быть, как упомянуто выше, малварь или иная зараза из вне. Значит надо обращаться к безопасникам и уже с ними решать проблему.
Как всё странно, хакер в долгую проходил интервью, устроился, дождался рабочий ноут и, внимание, топорно стал атаковать сеть работодателя. Звучит очень странно, поработал бы хоть пару месяцев, ознакомился бы с сетью получше, попробовал бы менее вызывающие варианты атак, прежде чем расчехлять набор юного хакера.
В зависимости от должности этот хакер мог бы выведать куда больше ценной информации либо о работодателе, либо о клиентах.
Хотелось бы в этой статье раскрыть тему курицы и яйца. Вы говорите как важно и полезно хранить state в бакете и даже создаёте такой букет, но где же хранится state данного TF стэка? Локально? В другом бакете?
Интересно, насколько сильно такой подход увеличивает нагрузку в ситуации с большим кол-вом запущенных процессов, ведь поиск свободного числа случайным образом не оптимален. В прошлом сталкивался с ситуациями, когда приложение упиралось в ограничение PID'ов, приходилось повышать лимит.
Сейчас глянул, на домашнем ноутбуке лимит по-умолчанию соответствует максимуму, то есть 4194304.
Да, действительно, в личных целях снова можно использоваться, НО при этом отключена поддержка расширений: https://k8slens.dev/pricing . Это как Firefox использовать без расширений, можно, но зачем? Сегодня попробовал упомянутый headlamp, вполне годное приложение и шустрое, что приятно удивило.
Надо попробовать headlamp, а то за LENS стали денежку просить. Тут как-никак проект, поддерживаемый CNCF.
Пошёл искать, что за зверь такой - Python-Terrascript, а он не развивается уже несколько лет. Так себе инструмент для сравнения.
Да и в целом проблема не такая большая, как описывается в статье. Да, в некоторых случаях приходится писать некрасивый код и костылять для Terraform, но в целом описание инфраструктуры достаточно наглядное и понятное.
Спасибо, теперь всё понятно!
Поясните тем, кто не в теме, в чём цель создания данного двигателя? Эволюционное улучшение существующего или замена в связи с ограничениями поставок компонентов?
Хотелось бы почитать больше аргументов за и против, иначе всё действительно скатывается в простой посыл - с чем команда умеет работать, такие инструменты и надо выбирать. И дело не только в Кубере, команда может банально не уметь в контейнеры. Накатили jBoss application server, залили через ГУЙ артефакты и готово. Другое дело, что надо думать и о среднесрочной перспективе с автоматизациями. Тут-то Кубер и может быть одним из инструментов. Особенно, если взять облако и не тратить силы на поддержку.
SnowBall'ы позволяют обрабатывать данные в процессе перекачки в/из хранилища. Именно для этого такие мощности.
Смею не согласиться со знаниями сегодняшних программистов. Очень многие до сих пор пилят не контейнеризованные приложения. А из тех, кто пилят под контейнеры, мало понимают в них. Люди хорошо секут в конкретном языке программирования + выучили несколько команд как собрать контейнер и залить в репозиторий. А в худшем случае и их не знают, так как сборкой занимается CI/CD.
Я тут хочу подчеркнуть, что говорю не про senior developer'ов, а про обычных разрабов, которые занимаются разработкой как ремеслом, а после рабочего дня занимаются не программированием.
Нечто схожее можно сказать и про JVM. Да, перезапуска умерших сервисов в ней нет, но это далеко не всегда задача разработчика. Есть опсы, которые оборачивают сервис и виртуалку мониторингом и скриптами по обслуживанию. Так что тут в целом для разработчика меняется шило на мыло.
Здесь не стану спорить, я пока не разбирался с этими решениями. Правда, говоря про докрутки над Кубером, скажем тот же Istio, то всерьёз приходится задумываться над усложнением общей инфраструктуры. Ведь должны быть спецы, которые смогут обновить уже не только Кубер, который выходит раз в квартал, но ещё и Istio. В этих проектах периодически меняется синтаксис, поэтому необходимо следить за всем этим делом. Да, мы опять говорим по 2-3 спецов, которые будут помогать команде, но нагрузка на них всё растёт и растёт.
Не спорю, этим ребятам надо идти в ногу со временем, ковырятся в новомодных технологиях и уметь донести их до руководства и исполнителей. Жаль, 24-х часов в сутках не всегда хватает для всех этих хотелок, а также всего того, что происходит вне ИТ мира.
Возможно мне попадались неправильные начинающие разработчики и даже консультанты, поскольку не все знали, что существует telnet, которым можно проверить доступность удалённого сервиса. Да что там telnet, просто сам факт такой проверки. В итоге всё, что выходит за рамки написания кода афишируется как блокер, флажок в джире и лапки к верху. Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Так-то оно так, вот только те самые дорогущие программисты всё меньше понимают, как эта балалайка работает. В итоге на вхождение человека в проект тратятся месяцы. Точнее не так, никто месяцы не тратит, новичок долбит вопросами лида, ведь самому в этом не разобраться. И я не про бизнес логику конкретного приложения/сервиса, а про архитектуру и как всё накручено. У каждого проекта свой набор свистелок, которые обеспечивают mesh и прочит хотелки.
Я понимаю, что все эти хотелки не из пальца высосаны, но то количество знаний, что необходимо держать в голове с трудом туда помещается.
Судя по предложенной архитектуре будущих приложений, дополнительные затраты на то, чтобы приложение крутилось в Кубере, увеличится ещё больше и скоро достигнет 50%. Облачные провайдеры будут рады такому раскладу. Да и обычные продавцы железа тоже.
Также допущение о доступности исходного кода звучит странно. А если исходники не доступны, то как смотреть на javadoc? Его достаточно легко экспортировать и отдать вместе с продуктом. Опять же, когда над кодом может работать множество людей, javadoc хоть как-то организует разработчиков одинакого документировать код.
По тестам могу порекоммендовать Job Bonso, его тесты есть как на Udemy, так и на его сайте: tutorialsdojo.com. На Udemy сайт получше, тесты не сбиваются, если решаешь один тест в течении двух дней. Но автор получает меньше гонорар за свои труды.
Что касается подготовки в целом, то конечно надо учить материалы, работать руками, читать whitepaper'ы, если такие есть. И гонять тесты, без них никак.