Интересная статейка, спасибо! По результату, кажется трудозатраты многократно превзошли результат. Я так понял, место на диске можно увеличивать практически бесконечно, были бы деньги. А стоимость сотрудника куда выше, чем гигабайты для хранилища.
Мне известны случаи, когда, по слухам на рынке, один очень крупный известный российский антивирусный вендор организовывал DDoS-атаки на потенциальных клиентов, чтобы потом «героически» предложить свою помощь в защите.
Звучит не очень правдиво, хотя бы по причине существенных рисков потерять репутацию и существующих клиентов.
Мне вот интересно, сколько необходимо проделать работы от базовой станции до местного маршрутизатора или дата центра. Ведь одно дело - обрабатывать огромное кол-во трафика от клиентов, и другое - доставить его куда надо, либо получить. Не перекладывается ли бутылочное горлышко, а результат примерно тот же?
Спасибо, интересная статья и решение поставленных задач. Особенно полезны дальнейшие планы, так как это именно то, что хотелось бы посоветовать. Я про 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, залили через ГУЙ артефакты и готово. Другое дело, что надо думать и о среднесрочной перспективе с автоматизациями. Тут-то Кубер и может быть одним из инструментов. Особенно, если взять облако и не тратить силы на поддержку.
Я что-то упустил в статье или вот этот пункт в середине текста вы пробовали плохо:
? Ведь именно это и предлагается в конце статьи как более ювелюрное решение.
Пока список изменений скудный. Ждём официальный релиз, может чего интересное занесут.
Интересная статейка, спасибо! По результату, кажется трудозатраты многократно превзошли результат. Я так понял, место на диске можно увеличивать практически бесконечно, были бы деньги. А стоимость сотрудника куда выше, чем гигабайты для хранилища.
Звучит не очень правдиво, хотя бы по причине существенных рисков потерять репутацию и существующих клиентов.
Мне вот интересно, сколько необходимо проделать работы от базовой станции до местного маршрутизатора или дата центра. Ведь одно дело - обрабатывать огромное кол-во трафика от клиентов, и другое - доставить его куда надо, либо получить. Не перекладывается ли бутылочное горлышко, а результат примерно тот же?
Спасибо, интересная статья и решение поставленных задач. Особенно полезны дальнейшие планы, так как это именно то, что хотелось бы посоветовать. Я про 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'ы позволяют обрабатывать данные в процессе перекачки в/из хранилища. Именно для этого такие мощности.