DevOps *

OpenRC + AUR + Wine с DXVK/VKD3D + модульный TUI-установщик. Всё это — QuasarLinux, основанный на Artix, но независимый от него.

В Ситидрайве Kubernetes обновляют регулярно — инфраструктура большая, и актуальность версий критически важна. После апгрейда до версии 1.29.15 один из GPU-узлов внезапно «забыл» о своей видеокарте, и нам пришлось срочно искать решение. В этой статье я расскажу, в чём была причина бага и как Time-Slicing помог повысить утилизацию GPU. Статья будет полезна всем, кто работает с GPU в Kubernetes и хочет избежать подобных сюрпризов в продакшене.

В нашей практике DevOps мы столкнулись с задачей оптимизации Kubernetes-кластера в AWS, включая перевод нагрузки на ARM64-инстансы с процессорами Graviton и эффективное использование spot-инстансов. Благодаря Amazon EKS и Karpenter нам удалось ускорить ввод новых узлов до всего 40 секунд и успевать переносить нагрузку при отборе узлов со стороны AWS. При этом мы сохранили привычный набор инструментов Deckhouse для мониторинга и управления — статья подробно рассказывает о нашем опыте и решениях.

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в MТС Web Services. Кроме своей основной деятельности в роли инженера, я провожу собеседования и всегда задаю вопросы кандидатам о том, как они видят пользу, которую их роль приносит бизнесу, как могут оценить свою деятельность, какой у них метод ведения работы. Как многие, я читаю профильные чаты, тематические ресурсы. И... кажется, в ИТ‑сообществе до сих пор бытует мнение, что DevOps и SRE — это следующие этапы развития системного администратора.

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

Ситуацию можно сравнить с подбором стоматолога по навыку работы специалиста с бормашиной. В такой клинике у вас высокий шанс попасть как к ювелиру, так и к мастеру маникюра.

За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.

Вы наверняка знаете, Kubernetes просто повсюду. От разработчиков, тестировщиков, DevOps-инженеров и системных аналитиков ожидают умения работать с этим инструментом. Даже продакт-менеджеры иногда интересуются, что это такое.

Если вы только начинаете знакомство с Kubernetes и хотите понять, с чего начать, эта статья для вас. Разберем, какие задачи он решает, какие у него основные объекты и как можно управлять кластером без сложных команд в терминале. Подробнее читайте внутри.

Мнение после десяти лет в производственных окопах от Джастина Кормака, бывшего CTO Docker.

Несколько лет назад я провёл немало времени, отвечая на вопросы Федеральной торговой комиссии (FTC) по поводу покупки VMware компанией Broadcom. Их интересовало, можно ли считать контейнеры конкурентами виртуальных машин - они пытались разобраться в конкурентной среде вокруг VMware.

Это напомнило мне первые пять лет работы в Docker, когда все только и делали, что сравнивали контейнеры с виртуальными машинами. Контейнеры - это просто “облегчённые” виртуалки? Или это небезопасная ерунда, от которой все скоро откажутся и вернутся к старым добрым VM?

Зачем вообще использовать gMSA в контейнерах?

Group Managed Service Accounts (gMSA) решает проблему хранения и обновления сервисных паролей: пароль хранится только в AD и регулярно обновляется автоматически. Использование gMSA позволяет не менять уже настроенные ACL и роли на файловых шарах и SQL-серверах - приложения продолжают работать с прежними правами через корпоративные Kerberos/SPN-механизмы. Такая интеграция обеспечивает прозрачный и контролируемый переход классических приложений в контейнерную инфраструктуру Kubernetes.

Посмотрим как это работает на примере простого кроссплатформенного dotnet-приложения.

Бывают сбои, которые не исчезают после устранения причины: система залипает, полезная пропускная способность почти нулевая, а петли обратной связи удерживают отказ. В статье формализуем это как метастабильные отказы, разберем цикл «стабильное → уязвимое → метастабильное», характерные метрики и «скрытую ёмкость». Обсудим практики сохранения полезной пропускной способности под перегрузкой: бюджет повторов, приоритеты и отбрасывание запросов, обслуживание «последних первыми», грамотное управление очередями и автомат защиты.

Привет! Меня зовут Александр Беседин. Раньше я был сетевым инженером в аэропорту, немного кодил на iOS, создавал простые CMS-сайты, а потом стал техлидом в Wildberries по направлению CI/CD. В этой статье рассказываю, какие проблемы возникали у нас с докер-сборками, как мы их решали и что получилось в итоге. Всё, чтобы вы могли посмотреть на наш опыт и применить его в своих проектах!

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

Меня зовут Павел Зимин. Я системный инженер в команде Professional Services Cloud SaaS VK Cloud. В этой статье я расскажу, что такое сервисная сеть и зачем она нужна, а также покажу алгоритм настройки подключения к объектному хранилищу через сервисную сеть на примере Object Storage от VK Cloud.

Ещё пару лет назад на одной из офлайн-встреч мы решили: как только появится возможность, проведём корпоратив в горах. Хотели подниматься на вершины, встречать рассветы в палатках и ловить падающие звёзды где-то над Кавказом. Возможность всё не наступала — проекты, релизы, клиенты, ставка… — но мечта жила. И вот в начале сентября Олег и Никита, наши руководители клиентского сервиса и продаж, просто взяли билеты на Камчатку, собрались в поход и ушли на неделю по Толбачинскому массиву. Без лишних слов, без анонсов. А потом — прислали фото: флаг Monq 9 на фоне вулкана, облака под ногами и подпись «Мы готовы». Подняв этот флаг они даже опередили команду разработки 😀

Мы долго ждали этого релиза и наконец-то мы готовы представить Monq 9.0, новую версию all-in-one платформы наблюдаемости (observability), ИТ-мониторинга и low-code/no-code автоматизации с AIOps функционалом на борту. Monq эволюционировал из событийного «зонтичного» мониторинга, который собирает данные из других систем, в “observability-зонтик”, который с большой производительностью умеет собирать любые данные сам. В этой статье расскажем, что нового появилось в версии 9.0, как устроена платформа и главное – зачем всё это нужно DevOps-инженерам, архитекторам и тимлидам. Поехали!

Основной метрикой разработки является time-to-market. На него все молятся как на священную корову: считают дни до релиза, выстраивают CI/CD, внедряют DevOps. А вот про то, как быстро можно начать экономить на инфраструктуре после того, как заметили перерасход, почему-то никто не думает. Будто так и надо. Хотя спустить облачный бюджет можно едва ли не быстрее, чем в кафе на Патриках. Стало быть, если time-to-market для облаков не существует, его надо придумать.

Мы собрали открытые книги и статьи ведущих экспертов по кибербезопасности, а также руководства для желающих погрузиться в DevSecOps. Материалы из подборки расскажут, какие ИБ-практики можно называть самыми неэффективными и с чего начать защиту облачных решений. И напомним, что у нас есть открытый курс по основам DevOps-подхода, Kubernetes и современных облачных решений.

В предыдущей статье рассмотрены основы сборки RPM пакета и автоматизации процесса.

Данная публикация завершает цикл. Продемонстрировав практическую реализацию готового решения, включая:

Разработку Web сервиса.

Регистрацию сервиса в качестве системной службы с автозагрузкой (systemd) при установке пакета.

Внедрение централизованного логирования через journald.

В результате создана полнофункциональная заготовка для быстрого развертывания сервисов с последующей публикацией их в RPM пакет.

В начале лета я опубликовал статью Маленькая утилита для контроля квот в Yandex Cloud и планировал добавить помимо контроля за квотами еще и подсчет стоимости добавляемых ресурсов.

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

runo — ассистент для репозиториев, который позволяет забыть о проблемах с настройкой локальной среды разработки и переключаться между репозиториями быстро и безболезненно. Больше не надо запоминать что, где и как можно/нужно запускать и что перед этим требуется сделать — обо всём позаботится ассистент.

Десять лет в бюджетных организациях из них три года работы с ГОЗ показали: сложность не в законах, а в инструментах. Собрал консалтинговую платформу с нуля на React 18 + TypeScript + Vite. Полный CI/CD через GitHub Actions, мониторинг на Sentry, Lighthouse > 90. Делюсь стеком, архитектурой и выводами — как в одиночку запустить production-ready продукт в сложной B2G-нише.

Как защитить Kubernetes, если злоумышленник попытается выбраться из контейнера на хост? Рафаэль Натали предлагает многоуровневый подход: настройка Security Context, отказ от лишних прав, запуск контейнеров без root-доступа, а также усиление защиты с помощью AppArmor и seccomp.

Собираю собственный NAS сервер для хранения данных, обретения независимости от западных сервисов, а также ведения своих документов. В последние годы зависимость от облачных сервисов стала проблемой: компании в любой момент могут изменить условия использования или вовсе закрыть сервис (как это произошло с Notion например). Кроме того, платные подписки на хранилища и сервисы накапливаются, а контроль над своими данными теряется.

Подробный разбор сборки и настройки домашнего NAS: выбор SAS-дисков и контроллера, настройка ZFS-пула, установка TrueNAS SCALE, организация резервного копирования в S3 и запуск Docker-сервисов (Immich, Affine, Keycloak, Actual Budget). Небольшой гайд для тех, кто хочет построить своё хранилище и цифровую инфраструктуру под полным контролем.