Привет, Хабр!
Я Никита Дубина, руководитель команды автоматизации Департамента больших данных РСХБ. В этой статье расскажу о том, что такое теневые ИТ, почему они возникают в крупных организациях, особенно в банках, какие риски несут и как при правильном подходе могут стать источником новых идей. Делюсь опытом борьбы с ними.
Привет! Я Саша Абакумов, DevOps-инженер в KTS.
Нашей команде часто приходится поднимать инфраструктуру под ML-проекты. Со временем число ML-инженеров и разработчиков на таких проектах росло, и логиниться в каждый по отдельности становилось все больнее. Чтобы упростить коллегам жизнь, мы интегрировали Single Sign-On (SSO) в стек одного из наших проектов, состоящий из JupyterHub, Airflow и MLflow.
SSO позволяет единообразно аутентифицироваться во всех инструментах под одной учетной записью. Помимо очевидного удобства, нам это также дало возможность централизованно управлять доступом и внедрить RBAC — сопоставление ролей в инструментах с группами или ролями в IdP.
В качестве инструмента для реализации SSO я использовал OIDC-провайдер Keycloak, наверняка многим хорошо знакомый. Ниже я расскажу о том, как с его помощью настроить SSO для JupyterHub, MLflow и Airflow (все компоненты разворачиваются с помощью Helm-чартов).
Hypersphere OS делает ставку на другое: на простую и разнесённую по логическим функциональным слоям структуру, где системные компоненты, библиотеки, окружения и AI-модели работают как части одного набора инструментов и в согласии между собой.
Я — Алексей Веснин, системный архитектор, создатель HyperSphere — децентрализованной экосистемы для безопасного и цензуроустойчивого пространства. В IT с начала 90-х. Занимаюсь системным администрированием с уклоном в сети, безопасность и построение информационных систем, которые управляли собой сами и преподавал собственный курс в ЦКО «Специалист» при МГТУ им. Баумана и в других местах.
В этой статье, по мотивам выступления на DevOps Conf, расскажу, что мне пришлось переизобрести, чтобы сборка нового типа заработала, почему старые подходы не справились, и как выглядит дистрибутив, который не мешает сам себе.
Привет, Хабр! Сегодня расскажу вам сагу о том, как мы искали дешёвые AI-мощности для своего проекта и чуть не сошли с ума. Спойлер: спас нас Китай, но эта помощь стоила нам седых волос и нескольких лет жизни. Делюсь опытом, чтобы вы прошли этот путь быстрее.
Как защитить свои данные и психику в сети
Отложи на минуту телефон. Взгляни на экран. Там — твои переписки с близкими, банковские уведомления, личные фото, история поисковых запросов. Вся твоя жизнь в цифровом срезе. 30 ноября, в Международный день защиты информации, самое время спросить: а что, если этот срез может увидеть кто-то чужой?
Внимание, внимание, внимание!
Вышли экстренные патчи безопасности в релизах Axiom JDK 25.0.1, 21.0.9, 17.0.17, 11.0.29 и 8u472. Мы устранили четыре критические уязвимости в OpenJFX, уровень опасности которых — высокий и средний.
Если вы используете JavaFX, весьма популярный в России инструмент для создания графических интерфейсов, обновляйтесь, чтобы ваши приложения не стали любимым местом хакеров.
Kubernetes — это фундамент современных микросервисных архитектур, оркеструющий миллионы контейнеров по всему миру. Но что происходит, когда одному сервису нужно «поговорить» с другим? Как они находят друг друга в динамической среде, где поды постоянно создаются и уничтожаются?
Управление сервисами в Kubernetes — это мост между изолированными контейнерами, обеспечивающий надежную коммуникацию в условиях постоянных изменений. В этой статье мы разберем ключевые абстракции для управления сетевым взаимодействием в Kubernetes на примере миникуба (minikube).
Эта инструкция представляет собой полное руководство по развертыванию отказоустойчивого кластера HashiCorp Vault в Kubernetes и настройке двухуровневой Public Key Infrastructure (PKI). Корневой сертификат и промежуточный CA создаются через OpenSSL, но промежуточный импортируется и настраивается в Vault для повседневного выпуска сертификатов. Инфраструктура интегрируется с cert-manager для автоматического управления жизненным циклом TLS-сертификатов.
«Администраторы делятся на три категории — тех, кто еще не делает бекапы, тех, кто уже делает, и тех, кто уже проверяет бекапы.»
Когда речь заходит о необходимости защиты данных сервисов и приложений, на ум в первую очередь приходит резервное копирование и репликация. Наличие копии вселяет ложное чувство уверенности: «у нас есть копия = мы в безопасности».
Здесь кроется ловушка: резервное копирование позволяет восстановиться после сбоев, которые легко распознать, например, от физических отказов — выхода из строя диска, случайного удаления тома, сбоя узла.
Всем привет! Я Игорь Голиков, ведущий разработчик ГК “Юзтех”. В данной статье хочу рассказать о метриках памяти в VMware vCenter, в том числе как получить скрытые метрики.
Статья может быть полезна SRE/DevOps и администраторам VMware vCenter, заинтересованным в получении «гостевых метрик» виртуальных машин, тем, кто хочет обосновать снижение выделенной виртуальным машинам памяти и сократить расходы без риска для производительности.
На одном из наших проектов возникла необходимость отслеживать использование памяти в гостевой ОС на виртуальных машинах под управлением VMware vCetner и формировать рекомендации по увеличению/уменьшению памяти выделенной виртуальной машине (rightsizing). Стандартные метрики памяти, доступные через vSphere Web Services API, не позволяют оценить объём памяти, используемой гостевой ОС.
Метрика (производительности) — это количественный показатель, который отражает состояние или поведение системы во времени (CPU, память, диск, сеть и т.д.).
Задача: найти метрику, показывающую объем памяти, потребляемой гостевой ОС и процессами в Linux системах с установленными Guest Tools.
Требования к метрике:
Почему kubectl delete pvc не всегда приводит к удалению тома? В статье — детальный разбор механизма финализаторов, роль PVC Protection Controller, типичные причины зависаний и безопасные способы диагностики и восстановления.
Ранее уже писал статью о поднятии AWX-Ansible но тот способ уже не работает так как в DEV образе слишком много изменений и с стабильной версии повторно не удалось развернуть (хотя полностью DEV версия прекрасно работает).
Helm 4 принёс пользователям единственное значимое изменение — внедрение Server-Side Apply вместо 3-Way Merge. Это решает проблемы с некорректными обновлениями ресурсов, но многих возможностей Helm по-прежнему не достаёт.
Nelm — наша современная альтернатива Helm 4 — ушёл вперёд по фичам, исправлениям и улучшениям. В статье смотрим на новые возможности обоих проектов, детально разбираем их отличия и объясняем, что ждёт Nelm дальше.
Сегодня мы построим масштабируемую, отказоустойчивую систему, которая будет расти вместе с вашей инфраструктурой и не сломается в самый неподходящий момент.
Вместо 3 часов дебага падающего Prometheus вы смотрите дашборд, который показывает 99.9% uptime вашего мониторинга.
Это реальность с правильно настроенным стеком на основе VictoriaMetrics.
Привет, Хабр! В этой статье поговорим о том, как принципы GitOps можно применить к разработке конфигураций 1С:Предприятия.
Перед каждой презентацией одна и та же история: собираешь инфраструктуру вручную, молишься богам DevOps и придумываешь отговорки на случай внезапных багов. С DevSecOps особенно весело: мало установить сам продукт, нужен целый зоопарк из GitLab, Kubernetes, сканеров безопасности и систем управления уязвимостями.
Поэтому мы собрали DevSecOps-песочницу, которая разворачивается одной кнопкой: подождал 15 минут — готово. Всё крутится на одной виртуальной машине с K3s, управляется через Terraform и Cloud-init, а главное — воспроизводится с гарантированным результатом.
Расскажу, как устроено это решение, с какими проблемами столкнулись и почему без автоматизации инфраструктуры сегодня никуда.
Над проектом работала команда из К2 Кибербезопасность: я, Максим Гусев, инженер по защите ИТ-инфраструктуры, и мои коллеги — Максим Виноградов и Александр Лысенко.
Два года я исправно заносил деньги хостерам. Сначала это были копейки за пару vps, потом захотелось управляемую базу данных, потом s3 для бекапов, и вот я уже смотрю на счет в 40 долларов ежемесячно за проекты, которыми пользуюсь я и полтора моих друга.
В какой-то момент жаба победила. Я посмотрел на полку, где пылился списанный корпоративный ноутбук с мертвой батареей, и решил: пора.
Если вы думаете, что это история про успешный успех и экономию - вы ошибаетесь. Это история про боль, перегрев и Docker на bare metal, но я ни о чем не жалею.
Вводные данные были так себе.
Ноутбук 2015 года. Core i5, 8 ГБ памяти, ssd на 256. Экран разбит, клавиатура залита кофе еще прошлым владельцем.
Главный плюс ноутбука в качестве домашнего сервера - встроенный ups. Батарея держала минут 15, но этого хватало, чтобы пережить мигание света в подъезде и корректно погасить базу, если электричество отрубили надолго.
Я накатил туда ubuntu server, кинул ноутбук под шкаф в прихожей и подключил витую пару. Сразу совет: не используйте wifi для сервера, даже если роутер стоит в метре. Пакеты будут теряться, а вы будете терять нервы при дебаге, почему ssh отваливается каждые полчаса.
В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию.
В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.
Привет, Хабр! 5 лет не виделись. Эта статья о том, как сэкономить на инфраструктуре тяжелых вычислений в пет-проекте или стартапе ранней стадии. Вопрос рассмотрен через призму эволюции локального пет-проекта в стартап.
Боль: Аренда GPU-сервера стоит дорого ($300–$1000/мес), а простаивает он 90% времени. Serverless GPU решения часто имеют ограничения по времени выполнения или окружению, в которые видеорендеринг не влезает.
Решение: Самописная оркестрация "Одноразовых Воркеров" (Disposable Workers). Основной бекенд (Node.js) через API облака поднимает VPS с GPU только на момент рендера задачи и уничтожает его сразу после завершения.
Стек: Node.js (Orchestrator & Worker main process), Redis (State Machine), Python (Worker components), DigitalOcean API, FFmpeg, LLM провайдеры.
Экономика: Расходы снизились с $1100/мес (постоянный сервер) до ~$130/мес (оплата поминутно только за время рендера).
Казалось бы, облака давно разобрали по косточкам. Уже даже финдирам понятно, что и как там устроено. Но стоит только кому-то запустить новую платформу или свернуть проект, как начинается: а почему не в паблике? А почему не в приватке? А оно нам вообще надо? И пошло-поехало. Хотя на деле-то выбор часто донельзя очевиден, если знать пару нюансов.
