В первой части мы разобрали, как в Linux работает процесс разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Однако если бы каждый вызов требовал нового DNS-запроса, это было бы неэффективно и сильно нагружало как систему, так и сеть. Поэтому используется кэширование.

Кэширование DNS может быть везде — в glibc, в systemd-resolved, в браузерах и даже в приложениях на Go. Кэш помогает увеличить скорость работы, но создает дополнительные сложности при отладке. Например: вы меняете DNS-запись, но сервер продолжает ходить по старому IP-адресу. Или, Dig показывает правильный адрес, а curl всё равно подключается к устаревшему.

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

Привет, Хабр! Меня зовут Анатолий Кохан, я — DevOps-инженер в К2Тех.

Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.

Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.

Привет, Хабр!

Вы, наверно, привыкли к стандартным HTTP-ответам – 200, 301, 404, 500 и т. д. А тут подкрался новый статус 103 – Early Hints. Это небольшой пинок браузеру: сервер шлет код 103 с заголовками Link: rel=preload ещё до того, как сформировал основной HTML. Пока бэкенд думает над ответом, браузер параллельно начинает грузить критические ресурсы (CSS, JS, шрифты и т. д.). Звучит просто, но эффект на производительность и LCP может быть весьма значительным.

Привет! Меня зовут Андрей, я разработчик из команды контента в Банки.ру.

Как человек, который постоянно изучает новые технологии и читает тонны документации, я давно устал тратить часы на ручное конспектирование. Перепробовал кучу способов — от блокнотов до сложных систем управления знаниями, пока не наткнулся на идеальную связку Obsidian + Zotero.

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

Введение 

В предыдущей статье "Сам себе PKI: Теория на примере Let’s Encrypt" мы рассмотрели теорию и разобрали пример, как происходит установка HTTPS соединения между браузером и веб-сайтом при использовании сертификатов Let's Encrypt. В этой статье перейдем к практике и самостоятельно реализуем ту же самую схему: 

- Сначала вручную с помощью OpenSSL пройдем цепочку генерации и использования самоподписанных сертификатов в HTTPS сервере. 

- Далее развернем собственный удостоверяющий центр Smallstep и будем получать сертификаты, подписанные им.

Схема PKI остаётся той же, только изменяются компоненты:

- В качестве CA вместо Let's Encrypt, будет использоваться OpenSSL и CA Smallstep.

- В роли Web-сервера вместо Интернет веб-сайта, будет выступать простой HTTPS сервер, запущенный на Node.js.

Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.

Сегодня я разберу три популярных прокси, сравню их и расскажу: что, где и когда лучше применять. Под «популярными» я имею в виду те, с которыми работал сам и изучил их устройство «под капотом». Прокси существует гораздо больше, но о других говорить не буду — либо не копал глубоко, либо знаю слишком мало, чтобы включать их в разбор. Отдельно отмечу важность документации: если она запутана или неполна, приходится гадать, что и где настраивать, а это быстро отбивает желание работать с инструментом.

HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.

В первой части мы разобрали, как устроен Keycloak, какие у него сущности и зачем вообще нужен SSO в DevOps-инфраструктуре. Теперь — к делу. Во второй части переходим от теории к практике. Разворачиваем Keycloak в Kubernetes, настраиваем Terraform-провайдер, подключаем к нему Grafana, Argo CD и другие сервисы. Разбираемся, как выглядят реальные конфигурации клиентов, scopes и mappings, чтобы SSO действительно работал — с нужными токенами, ролями и группами.

Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени.

Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем.

Продолжение статьи об архитектурных паттернах для масштабируемости приложений.

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

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

Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.

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

Напомню, HAProxy (High Availability Proxy) — это высокопроизводительный, отказоустойчивый прокси-сервер и балансировщик нагрузки, способный работать как с HTTP(S), так и с TCP-трафиком. Это делает его идеальным решением не только для веб-приложений, но и для баз данных, почтовых систем, брокеров сообщений и других сервисов.

В этой статье я разберу последнюю доступную версию — 3.2.3, расскажу о ключевых изменениях, особенностях конфигурации и поделюсь приёмами, которые помогают выжать из HAProxy максимум.

Итак, чем же хорош HAProxy как балансировщик и что интересного появилось в новых версиях?

Kubernetes — мощный и одновременно сложный инструмент, работа с которым неизбежно порождает… инциденты. И на практике DNS виновата далеко не всегда. Иногда всё ломает слишком длинное имя деплоймента, протухший CA-сертификат или сбой сетевой карты, из-за которого TCP-пакеты просто отбрасываются. В статье вас ждут самые интересные и поучительные инженерные истории с Reddit.

Привет, Хабр! В современном мире сети растут крайне быстро, устройств становится всё больше, в связи с чем растёт и количество уязвимых мест. Ручной мониторинг открытых портов, сервисов и дыр в безопасности — схоже с поиском иглы в стоге сена, когда в кармане лежит магнит.

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

Привет, Хабр! На связи Александр Горьев, ведущий разработчик в Selectel. Сегодня в фокусе нашего внимания Redis — высокопроизводительное хранилище «ключ-значение», работающее в оперативной памяти. Скорость, простота и богатый набор структур сделали Redis очень популярным.

На старте Redis часто воспринимается как инструмент, который отлично работает «из коробки». Действительно, при небольшом объеме данных и малом числе клиентов он стабильно быстр даже с настройками по умолчанию. Однако с ростом нагрузки и усложнением архитектуры появляются проблемы. Ситуация усугубляется тем, что у каждого сценария свои требования к конфигурации и нет универсального набора параметров.

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

Привет!

Сегодня мы рассмотрим, как перезапустить полноценный ZooKeeper‑кластер в Kubernetes так, чтобы ни один из узлов не потерял кворум даже на микросекунду. Берём два проверенных инструмента — строгий PodDisruptionBudget с minAvailable: 100% и StatefulSet с updateStrategy.RollingUpdate.partition.

Привет, Хабр! Меня зовут Игорь Балюк, совсем недавно я работал платформенным инженером в Авито. В этой статье я рассказываю про Service Mesh и показываю, что это, скорее, не конечная точка, где можно найти «серебряную пулю» от всех проблем, а путь, который, возможно, никогда не закончится: придется постоянно куда-то бежать и что-то дорабатывать. В тексте я также разбираю, как работает Service Mesh в Авито. 

Переходите под кат, будет интересно!

В этой статье я расскажу о том, как я выстроил работу с терминалом в Linux под себя и какие инструменты использовал для этого.

https://jamanetwork.com/journals/jama/fullarticle/198947 Compensation for Energy Intake From Fast Food Among Overweight and Lean Adolescents

Взяли группу детей, дали возможность раз в день стрескать за 1 час столько бургеров и прочего, сколько сможешь. Причём для жизненности, ели люди на фуд-корте, а не в лаборатории. Затем во второй части исследования точно контролировали сколько дети потратили энергии за 2 следующих дня. Участники от 13 до 17 лет. Толстых 26, худых 28. Для пущей наглядности, фастфуд буквально "не кончался", чуть съедаешь бургер и выпиваешь колу - подтаскивают ещё и ещё.

При свободном поедании фастфуда, толстые зажрали за 1 час - 1860ккал, а худые только 1458. В итоге толстые хапали за 1 час 66.5 % суточной своей нормы калорий, а худые 57 %. Худые не ели больше толстых, они ели меньше, никакого чуда в том, что в итоге худые так и будут худыми.

Расскажу про то, как устроен мониторинг в OKD-кластерах, какие у него есть минусы и как мы их побороли, мигрируя основную функциональность на VictoriaMetrics Agent.