В NGINX появилась встроенная поддержка ACME — теперь HTTPS настраивается без Certbot и лишних утилит

NGINX получил встроенную поддержку ACME, позволяющую автоматически выпускать и обновлять HTTPS-сертификаты без сторонних утилит

Читать: «В NGINX появилась встроенная поддержка ACME — теперь HTTPS настраивается без Certbot и лишних утилит»

#ru

@devo_pes | Другие наши каналы

«Нам нужен Kubernetes 2.0»: инженер предложил переосмысление всей платформы

Инженер предложил Kubernetes 2.0: меньше YAML, новый пакетный менеджер, IPv6 по умолчанию и модульное хранилище вместо etcd

Читать: ««Нам нужен Kubernetes 2.0»: инженер предложил переосмысление всей платформы»

#ru

@devo_pes | Другие наши каналы

n8n: установка, настройка и интеграция с Python, Node.JS и PHP

Подробный туториал по установке и настройки n8n. Примеры интеграции с Python, Node.JS и PHP и взаимодействия с LLM Mistral AI.

Читать: «n8n: установка, настройка и интеграция с Python, Node.JS и PHP»

#ru

@devo_pes | Другие наши каналы

werf как альтернатива Kaniko для сборки образов в Kubernetes в вашей системе CI

Публичный репозиторий Kaniko перевели в архив — теперь он доступен только для чтения. Изучили подобные инструменты и выбрали больше, чем просто альтернативу. Рассказываем, чем уникальна утилита werf и почему её стоит попробовать.

Читать: «werf как альтернатива Kaniko для сборки образов в Kubernetes в вашей системе CI»

#ru

@devo_pes | Другие наши каналы

«SQL хорош для данных, но плох для логики» — почему все больше разработчиков выносят бизнес-логику из базы

SQL отлично справляется с данными, но неудобен для бизнес-логики: разработчики выносят её в код ради гибкости, скорости и независимости

Читать: ««SQL хорош для данных, но плох для логики» — почему все больше разработчиков выносят бизнес-логику из базы»

#ru

@devo_pes | Другие наши каналы

Что сейчас происходит в сфере антифрода

К 2026 году мошенники тоже освоили генеративный ИИ. Вместо физических подделок они синтезируют изображения на основе утекших данных пользователей, заваливая банки тысячами фальшивых документов разного качества, авось прокатит. И в ряде случаев действительно прокатывает, потому что системы защиты тоже несовершенны.

Рынок пытается справиться с этими бедами: у нас на сайте вышел емкий разбор современных трендов антифрода. В статье разбирают, как эволюционировали подделки документов, из-за чего тормозится разработка средств защиты, а также какие модели считаются одними из самых прогрессивных.

Если хотите чек-лист антифрода 2026, вам сюда: https://tprg.ru/NCku

Как ML помогает тестировать то, что нельзя предсказать вручную?

В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML.

В статье подробное описание архитектуры решения:
— пайплайн из Great Expectations, Evidently AI, DVC и Airflow;
— три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML;
— а еще швейцарский сыр.

Как он там оказался, читайте в статье.

Реддитор проанализировал 1.6 миллиона Git-событий и показал, как бесконтрольное использование ИИ в разработке ломает привычные процессы и замедляет поставку продукта.

Основные выводы:
— ИИ увеличивает общий объем написанного кода примерно на 55%.
— Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ.
— Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1.
— Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги.

Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨.

Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой.

Один из комментаторов поделился рабочим решением:
— Сделать CI-пайплайн первым и главным ревьюером.
— Внедрить property-based тесты и мутационное тестирование на критичных участках.
— Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений.

Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания.

Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/

Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198

Оказывается, людей всё ещё просят инвертировать бинарные деревья на доске при найме на позиции DevOps или Platform Engineer. Видимо, мы в 2026 должны уметь поисковики с нуля писать. Хотя куда показательнее попросить написать скрипт для парсинга логов или сортировки тысяч файлов в S3 по бакетам.

Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг:

— Базовые принципы CAMS
— Метрики DORA вроде Deployment Frequency и Change Failure Rate
— Понимание подкапотной магии Ansible, Jenkins и Helm
— Практичные паттерны: GitOps, Policy-as-code, стратегии релизов

И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.

Тут снова всплыла та самая статья про исход из облаков от создателя Ruby on Rails. Если не читали, основная мысль сводится к тому, что для компаний среднего размера со стабильным ростом аренда чужих серверов обходится неоправданно дорого.

По логике Дэвида облако незаменимо только в двух случаях:

— либо ты делаешь стартап с нулевой базой и тебе критически важна скорость запуска без возни с инфраструктурой;
— либо у тебя случаются дикие непредсказуемые скачки нагрузки, как у них было на старте HEY с наплывом сотен тысяч пользователей.

В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров.

Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.

Вообще этот нудный пост о старой статье был ради подводки к ещё более старому мему

Линуксоид с гигантским стажем решил волевым усилием поломать свои привычки и заменить coreutils на фэнси тулзы. В комментарии набежали холиварить про надёжность vs эргономичность, но сначала вот пять замен, которые коллективно сочли достойными:

cat → bat ибо встроенная подсветка синтаксиса, нумерация строк и адекватный пейджинг;
ls → eza, потому что позволь себе уже полюбить цветовое кодирование и иконки;
find → fd за интуитивный синтаксис и быструю выдачу;
grep → ripgrep опять же из-за скорости;
top → btop для комплексного мониторинга ресурсов, хоть btop и перегружен визуально.

Дальше на ночь пятничная сказка про холивар.

Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими, а ресурсов не хватало ни на что лишнее. Синтаксис классического find до сих пор вызывает нервный тик, а чтение логов через cat без подсветки пора признать формой легкого мазохизма. Современный подход предлагает инструменты, которые написаны преимущественно на Rust и делают ровно то же самое, но с человеческим лицом. А ещё они работают быстрее и прямо из коробки понимают правила .gitignore.

В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?

Пожалуй, единственное здравое правило, которое можно вынести из этого противостояния: как только дело доходит до автоматизации и bash-скриптов, надо возвращаться к POSIX-совместимым конструкциям и классическим coreutils, иначе автоматизация сломается на первой же машине.