ИИ действительно использовался, но не в том варианте, который вы предполагаете. И точно не бесплатный — возможности бесплатных моделей для подобных задач довольно ограничены.
Сам текст я писал вручную. После этого использовал ИИ как редактор, чтобы он помог исправить грамматические и пунктуационные ошибки, улучшить стилистику, разбить текст на более читаемые абзацы и привести оформление к единому виду. Это примерно то же самое, как использовать LanguageTool или Grammarly, только с более широкими возможностями.
Если где-то осталось кривое форматирование или ошибки в таблице, то это мой недосмотр, а не результат слепого копирования, так как через ИИ я прогонял не всю статью, а подозрительные для меня участки текста. За замечание спасибо.
За ограничение параллельности отдельный плюс. Часто в таких утилитах всё запускают без особых ограничений, создают кучу горутин, сначала кажется, что так быстрее, а потом начинаются таймауты и лишняя нагрузка на систему и сеть. Тут подход аккуратнее что параллельность есть, но она под контролем. Для сетевого сканера это важная деталь, потому что скорость сама по себе не решает, если утилита начинает душить сеть или саму машину.
После вашего комментария специально копнул глубже, перепроверил актуальные возможности Dockerfile/BuildKit и подкорректировал статью: переписал блок про ADD, добавил пояснение про heredoc и отдельно отметил multi-platform сборки с нативной build-стадией и кросс-компиляцией. Спасибо — это как раз тот случай, когда комментарий не просто уточняет деталь, а реально усиливает материал.
Да, согласен. BuildKit без рут прав - хороший вариант для сборки образов в CI/CD, особенно если хочется уйти от привилегированного Docker-in-Docker, а podman/buildah по каким-то причинам не подходят.
Там есть конечно свои нюансы с раннером, кешем, правами, сторедж и сетью, но как отдельный рабочий вариант безопасной сборки образов без рут доступа, это вполне уместно.
Спасибо за комментарий, он в какой-то мере даже дополнил статью.
С IDE это кстати частая история. И восклицательный знак там далеко не всегда значит что под лежит. Часто это бывает когда что-то в статусе не идеально, например, был рестарт, Ready=False, старый warning event какой-нибудь, отвалилась проба, один контейнер из нескольких не готов или сама IDE чуть закешировала стейт.
Часто бывает, что под снаружи живой, и приложение отвечает, но Кубер уже оставил жёлтый флажок, мол тут был флап, рестарт или проба ругалась, и IDE просто подсвечивает этот шум как проблему.
Я бы проверил под через get и describe, и если в Ready, Restart Count, Last State и Events всё чисто, то скорее всего, это просто шум или IDE закешировала старый статус.
О, тогда describe ещё полезнее. Когда часть едет через Helm, часть через Terraform, легко получить два источника правды: в values одно, в tf state другое, а в Pod прилетело третье, ещё и после вебхуков, инжекторов и платформенных дефолтных настроек.
Я бы в таком раскладе смотрел describe как проверку реальности перед тем, как лезть глубже: какой образ реально запущен, какие метки и аннотации навесились, под каким service account всё стартует, какие переменные окружения, тома, пробы и кто владелец пода.
Events, это как быстрый вход в отладку, а верхняя часть describe помогает понять сразу: мы чиним реальную проблему или расхождение между Helm, Terraform и тем, что в итоге собрал наш кластер.
Вот да, прям в точку. Я как раз сейчас с этим столкнулся и не понимал, почему так сложно раскачать статью на старте. Не понимал почему у двух одинаково хороших статей, такая разная статистика.
ИИ действительно использовался, но не в том варианте, который вы предполагаете. И точно не бесплатный — возможности бесплатных моделей для подобных задач довольно ограничены.
Сам текст я писал вручную. После этого использовал ИИ как редактор, чтобы он помог исправить грамматические и пунктуационные ошибки, улучшить стилистику, разбить текст на более читаемые абзацы и привести оформление к единому виду. Это примерно то же самое, как использовать LanguageTool или Grammarly, только с более широкими возможностями.
Если где-то осталось кривое форматирование или ошибки в таблице, то это мой недосмотр, а не результат слепого копирования, так как через ИИ я прогонял не всю статью, а подозрительные для меня участки текста. За замечание спасибо.
За ограничение параллельности отдельный плюс. Часто в таких утилитах всё запускают без особых ограничений, создают кучу горутин, сначала кажется, что так быстрее, а потом начинаются таймауты и лишняя нагрузка на систему и сеть. Тут подход аккуратнее что параллельность есть, но она под контролем. Для сетевого сканера это важная деталь, потому что скорость сама по себе не решает, если утилита начинает душить сеть или саму машину.
После вашего комментария специально копнул глубже, перепроверил актуальные возможности Dockerfile/BuildKit и подкорректировал статью: переписал блок про ADD, добавил пояснение про heredoc и отдельно отметил multi-platform сборки с нативной build-стадией и кросс-компиляцией. Спасибо — это как раз тот случай, когда комментарий не просто уточняет деталь, а реально усиливает материал.
Спасибо что подметили, сейчас же добавлю)
Да, согласен. BuildKit без рут прав - хороший вариант для сборки образов в CI/CD, особенно если хочется уйти от привилегированного Docker-in-Docker, а podman/buildah по каким-то причинам не подходят.
Там есть конечно свои нюансы с раннером, кешем, правами, сторедж и сетью, но как отдельный рабочий вариант безопасной сборки образов без рут доступа, это вполне уместно.
Спасибо за комментарий, он в какой-то мере даже дополнил статью.
Спасибо!
С IDE это кстати частая история. И восклицательный знак там далеко не всегда значит что под лежит. Часто это бывает когда что-то в статусе не идеально, например, был рестарт, Ready=False, старый warning event какой-нибудь, отвалилась проба, один контейнер из нескольких не готов или сама IDE чуть закешировала стейт.
Часто бывает, что под снаружи живой, и приложение отвечает, но Кубер уже оставил жёлтый флажок, мол тут был флап, рестарт или проба ругалась, и IDE просто подсвечивает этот шум как проблему.
Я бы проверил под через get и describe, и если в Ready, Restart Count, Last State и Events всё чисто, то скорее всего, это просто шум или IDE закешировала старый статус.
О, тогда
describeещё полезнее. Когда часть едет через Helm, часть через Terraform, легко получить два источника правды: в values одно, в tf state другое, а в Pod прилетело третье, ещё и после вебхуков, инжекторов и платформенных дефолтных настроек.Я бы в таком раскладе смотрел
describeкак проверку реальности перед тем, как лезть глубже: какой образ реально запущен, какие метки и аннотации навесились, под каким service account всё стартует, какие переменные окружения, тома, пробы и кто владелец пода.Events, это как быстрый вход в отладку, а верхняя часть
describeпомогает понять сразу: мы чиним реальную проблему или расхождение между Helm, Terraform и тем, что в итоге собрал наш кластер.Вот да, прям в точку. Я как раз сейчас с этим столкнулся и не понимал, почему так сложно раскачать статью на старте. Не понимал почему у двух одинаково хороших статей, такая разная статистика.