Пользователь
Docker — не магия, а грамотное применение механизмов Linux. Разбираем инструмент, который пугает своей сложностью не меньше блокчейна. Показываем на пальцах как работают: Namespaces, Cgroups, OverlayFS – основные компоненты любого контейнера, и как стандарт OCI объединяет их в единую экосистему. Об этом и не только в статье.
Привет, постоянные и не очень читатели!
Были времена, когда админы дурели от этой прикормки 10 Гбит/c канала, а теперь такая пропускная способность — норма для роутера в прихожей (не у всех, но всё же).
В ЦОДах же и 100 Гбит/c уже давно никого не удивят — у гиперскейлеров (Amazon, Microsoft, Google, Alibaba, экстремистская и запрещённая в России Meta) это дефолт, в энтерпрайзе и бизнесе разных размеров — активно внедряют.
Компании уровня cloud-scale (те, что строят сервисы облачного уровня: Netflix, Spotify, Salesforce, Zoom) и гиперскейлеры уже переходят на 200 Гбит/c и тестируют 400/800 Гбит/c, ну а поскольку 200 мало чем отличается по стоимости инфраструктуры от 400, то некоторые сразу перескакивают, ведь легаси кабельное хозяйство (LC, MPO-12) всё равно не потянет эти апгрейды, надо всё перелопачивать на MPO-16, MPO-32 или новые форматы (QSFP-DD, OSFP).
В общем, накопилось у меня пару идей, как собрать всё это в едином материале: обсудить, где шайба будет через время; подумать, а надо ли оно (апгрейд) вообще — и в довесок затронуть денежные вопросы: всякие CAPEX, TCO/ROI, ₽/(Гбит/c), ($/Gbps) и прочее экономическое непотребство.
Присаживаемся, ложимся или в какой там позе вы читаете — и начинаем.
Как защитить Kubernetes, если злоумышленник попытается выбраться из контейнера на хост? Рафаэль Натали предлагает многоуровневый подход: настройка Security Context, отказ от лишних прав, запуск контейнеров без root-доступа, а также усиление защиты с помощью AppArmor и seccomp.
После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].
Проблема заключается в том, что есть огромный разрыв между тем, как совещания воспринимают менеджеры и разработчики.
В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:
«Когда работаешь в режиме творца, совещания — это катастрофа. Единственное совещание может поломать день, разделив его на две части, в каждой из которых невозможно сделать ничего достаточно сложного».
Эта проблема не решилась с появлением ИИ-помощников в кодинге; напротив, она усугубилась, потому что менеджеры теперь считают, что разработчики могут быть продуктивными в меньших временных интервалах.
За последние два года мы изучили сотни команд разработчиков, чтобы разобраться, чем отличаются лучшие из них. В этой статье мы поделимся их стратегиями и расскажем о действиях, которые вы можете предпринять уже сегодня.
Не секрет, что в последние годы различные компании достаточно часто принимают решение о миграции работающей информационной системы с Firebird на PostgreSQL.
Типичная ситуация выглядит так:
Проект работает несколько лет. Заказчик «верит», что проблема не в проекте, а в СУБД. Firebird — «плохая» СУБД.
Наш кейс: в приложении есть русский (наш нативный) и английский языки. Надо быстро и просто добавлять другие (по запросам от клиентов). В файлах с переводами был хаос: дублирование строк, конкатенация вместо плейсхолдеров, разный порядок строк в файлах переводов для ru/en, висячие пробелы и многое другое.
Я решил написать вспомогательный инструмент, который помог решить все эти проблемы. Сейчас мы добавляем новый язык буквально за 40 минут и 2$. Все получилось настолько хорошо, что решил причесать и выложить в open-source
Главная фишка: перевод на новые языки делается сразу с 2х языков (в нашем случае с ru и en) что на практике делает его супер-качественным
Наверняка вы все работаете с Kubernetes, публикуете сервисы наружу через Ingress-контроллер. Уверен, что большинство из вас использует ingress-nginx. Создаете манифест, деплоите его в k8s, но не всегда получаете именно тот результат, который хотели бы. Или же все работает, но спустя какое-то время что-то идет не так.
В этой серии статей, созданной по мотивам выступления на DevOpsConf’25, мы подробно разберемся как работает сам ingress-nginx контроллер и почему это не совсем классический nginx. Погрузимся в дебри LUA-кода чтобы понять, как реализована балансировка. А также затронем тему сниппетов, как их включить если они вам очень нужны, и почему этого делать не стоит.
Меня зовут Алексей Колосков, я Lead DevOps из Hilbert Team. Больше 15 лет я в IT: за это время админил, разрабатывал, развивал on-premise инфраструктуру, инфраструктуру в облаках и даже курсы по DevOps, Security и DataTech в Yandex Cloud. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.
Привет, Хабр! Меня зовут Анатолий Кохан, я — DevOps-инженер в К2Тех.
Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.
Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.
Привет! Наверное, у каждого рано или поздно возникает вопрос: как упорядочить хаос с купленными (да, мы же против пиратства?) книгами в форматах PDF, DJVU и других, так чтобы:
- получить к ним доступ как с мобильного устройства, так и с любимого ПК или Mac;
- сохранять прогресс чтения между устройствами;
- не терять книги в куче папок.
Хочу поделиться решением, которое помогло мне организовать библиотеку.
Данных в современных приложениях становится все больше, прямо как снежный ком. И рано или поздно многие системы начинают задыхаться – база данных не справляется. Когда старые добрые методы вроде подкрутки запросов, добавления индексов или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета), на помощь приходит горизонтальное масштабирование.
Привет, Хабр!
В этой статье рассмотрим, почему безобидная строчка await fetch() неожиданно превращается в тормоз, где именно она зарывает драгоценные миллисекунды — и что можно сделать с этим.
Привет, Хабр!
В этой статье разберём важнейший механизм защиты от перегрузок и DoS-атак в NGINX — лимиты.
Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь).
На досуге я преподаю в университете дисциплину «Хранение и обработка больших объемов данных» и за все время у меня накопилось много полезной информации. Непростительно хранить такой клад у себя в столе, поэтому я подготовил для читателей Хабра ультимативный гайд по оптимизации или хорошему такому, грамотному проектированию баз данных с расчетом на масштабирование.
Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста).
Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.
Согласны? Узнали? Тогда поехали!
Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.
Вы думали, что путь от Senior Developer до Tech Lead — это всего лишь прибавка к зарплате и новый пункт в резюме? Увы. Техлид - это не только про разработку, но и про управление командой в штормовые времена, сохранение продукта в моменты кризиса, а еще про самодисциплину и менеджмент.
От вас будет зависеть не только качество кода, но и весь проект.
Как стать техлидом, наладить процессы, прокачать свои софты и установить контакт между разработкой и бизнесом я расскажу в этой статье
Сегодня затронем такую неожиданную тему как работу с брокером сообщений Nats на PHP. Как оказалось, есть очень мало статей на эту тему, так что попробуем с этим разобраться и реализовать базовую работу с очередью.
По мотивам статьи: Не пиши простой код и старого манифеста
Эта статья о других, о тех кто случайно просто пишет код, или кому случайно пришлось писать код раньше. Или о тех, кто случайно код не пишет, но очень хочет.
Просто пиши код, пока остальные на митинге спорят, в какую борду переместить эту таску. Потому что ни одна Jira не напишет багфикс.
Просто пиши код, это не сделает тебя супербогатым, но на хлеб с колбасой хватит, зато совесть будет в порядке, и прод живым.
Просто пиши код, даже если это говнокод, он будет работать. Работающий говнокод гораздо лучше десятка тасок в жире.
Просто пиши код, потому что ты проводишь на работе большую часть своей жизни. Факапы бывают всегда, но если твой код работает - это еще не факап.
Просто пиши код, потому что вместо инвестиций в инженеров компания вкладывалась в настолки и ворклайф баланс — теперь у нас в офисе есть чемпион по "Evolution", но инженеры не знают как пользоваться профайлером.
Просто пиши код, потому что когда ты говорил «давайте учиться и курсы», они говорили «давайте наймем еще людей». В итоге теперь у нас у каждого третьего бонус за рефку, но профайлером пользоваться так никто и не научился.
Простопиши код, потому что когда ты пытался разделить архитектуру на слои и модули, тебе отвечали: «Это всё теоретизация, у нас бизнес и фичи». А теперь этот бизнес держится на толпе джунов и пачке jsonов.
Просто пиши код, потому что Хабр завален «Как я продаю на маркетах когтеточки» и «Как я уволился ради душевного баланса», а вот статью про memory fences или perf counters — хрен найдёшь.
В моих предыдущих статьях (1, 2) я подробно рассматривал, как работает React.memo, а также делился более эффективными подходами к оптимизации производительности с помощью компоновки. Однако для глубокого понимания работы React необходимо разобраться в основном механизме, лежащем в основе всех этих оптимизаций – алгоритме согласования (reconciliation).
Согласование – это процесс, в результате которого React приводит DOM в соответствие с деревом компонентов. Именно этот механизм позволяет реализовать декларативный подход к программированию на React: вы формулируете свои намерения, а React самостоятельно определяет, как выполнить эти намерения наилучшим образом и с наименьшими затратами.
Разработка отказоустойчивых систем представляет собой важнейшую компетенцию для инженеров, занятых созданием распределённых и масштабируемых приложений. Под отказоустойчивостью понимается способность системы сохранять работоспособность в условиях сбоев отдельных компонентов или недоступности внешних сервисов. В данной статье рассматриваются практики обеспечения устойчивости на уровне программного кода, в частности в контексте серверных приложений, реализованных на языках Python и Java.
Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.