DevOps *

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

Любой «более простой» инструмент DevOps — это просто Kubernetes в темных очках.

Я — Саша Краснов, СТО «Штурвала». Недавно я наткнулся на волшебную статью о Kubernetes, и просто не смог справиться с желанием перевести ее. Мой собственный опыт знакомства с Kubernetes был другим, но путь был похожим: от отрицания и «зачем же так сложно» до восторга от элегантных решений в отдельных контроллерах. Даже архаичные винтажные части, вроде API группы “”, встречающиеся тут и там, больше не раздражают, а вызывают любопытство археолога. Кубер — он сложный, но это не просто так.

Представьте: вы пишете "перезапусти продакшн-сервер" в Telegram, и система не просто понимает запрос — она знает, какой именно у вас сервер, что на нём запущено, кто будет затронут простоем, и предлагает конкретный план действий. Без панелей управления, без SSH, без поиска в документации.

Это не шизофреническая фантазия. Это ICNLI (Infrastructure Contextual Natural Language Interface) — открытый стандарт, который мы разработали и уже внедрили в production на десятки серверов.

Дома у меня лежали несколько старых Android-устройств. Они работают, но давно не используются и просто лежат без дела.

Я стал думать, как их можно использовать. Хотелось чего-то простого и полезного: показывать информацию и иногда вводить данные. Ничего сложного, просто что-то, что реально будет использоваться. Так появилась идея превратить их в дашборды.

Потом я понял, что для этого нужна веб-часть и мобильное приложение. Сделал веб-приложение на Analog и Android-клиент на Ionic Framework. В разработке активно помогал AI-ассистент из Qoder — он сильно ускорял работу и решал много задач сам.

Проект пока ещё в процессе, но я решил написать о нём пост. Возможно, кому-то пригодятся мои наработки.

Проник в банк не через вайфай и не через фишинг — а просто пристроился к аудиторам с улицы. Никто не спросил имени. Никто не проверил. А через час уже сидел у них в сети с рабочим пропуском. Как это случилось — и почему «следовать инструкции» не спасло — в новой статье.

Привет, Хабр! Вы когда-нибудь обновляли ноду Kubernetes-кластера и замечали, как несколько ваших подов сразу пропали в процессе? Не самое приятное ощущение, верно?

Запускаете плановое обновление, kubectl drain начинает выгонять поды с ноды, и вдруг сервис теряет половину реплик. Клиенты начинают получать ошибки. Что пошло не так? Вы забыли про PodDisruptionBudget.

Они работали в коллекторской сфере. Привыкли к угрозам, обману и агрессии. Но когда к ним пришли с благодарностью — дали дорогу. Эта статья — про то, как взломать «непробиваемую» компанию через её самого главного человека. И почему технические защиты тут почти не при чём.

Мы проверили, способен ли ИИ участвовать в реальной инфраструктурной операции повышенного риска — обновлении Kubernetes-кластера сразу через несколько minor-версий.

Речь не про «сгенерировать YAML» или «написать Helm-чарт», а про полноценную операцию:

Это Docker-шаблон для Python + Poetry, рассчитанный на реальную работу, а не учебные примеры: воспроизводимое окружение, удобный dev-workflow, отдельные сборки под прод, dev, Jupyter и AI-инструменты.

Автор использует его в основном для DS/ML-задач, где важнее скорость и предсказуемость, чем экономия пары мегабайт образа. Шаблон обкатан в бою, экономит время и легко кастомизируется под свои нужды.

👉 Репозиторий на GitHub:
https://github.com/jamm1985/vim-python-docker-template

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

Docker помогает изолировать окружение, но сам по себе он не решает Python-специфичные задачи. Его нужно правильно наполнить: учесть работу Poetry, кеширование зависимостей, структуру проекта и базовые практики, которые одинаково хорошо работают и в разработке, и в продакшене. Именно такой шаблон мы и будем собирать дальше.

В этой статье мы шаг за шагом соберём базовый Docker-шаблон для Python с Poetry, который удобно использовать и для разработки, и для прода. В основе будет минимальное и воспроизводимое окружение, а всё остальное - Vim как IDE, Jupyter, AI-инструменты вроде Codex или Gemini - вынесено в отдельные образы и слои, которые можно подключать по мере необходимости. Начнём с самого главного - разберём Dockerfile и поймём, как собрать прочную и расширяемую базу для Python-проекта.

Вам когда-нибудь нужно было зайти в BIOS или UEFI, чтобы сменить порядок загрузки, включить виртуализацию или проверить оборудование? Многие пользователи знают лишь один способ — в первые секунды после включения компьютера нажать Del, F2 или другую «волшебную» клавишу. Но что делать, если клавиатура не работает, используется удалённое подключение, или вы просто не успеваете нажать нужную кнопку из-за быстрой загрузки системы?

Оказывается, на современных операционных системах можно программно перезагрузиться прямо в интерфейс прошивки, используя лишь командную строку или терминал. В этой статье мы рассмотрим, как это сделать в Windows, Linux и выясним, какие возможности есть в macOS.

Мне довольно часто приходится работать с только что созданными VPS — будь то развёртывание нового проекта, подготовка тестового окружения или эксперименты с инфраструктурой. Практически каждый такой сервер после создания находится в «сыром» состоянии и требует базовой первичной настройки.

Как правило, эта настройка включает:

Ivory теперь поддерживает LDAP и OIDC/SSO наряду с базовой аутентификацией, что значительно упрощает интеграцию с существующей инфраструктурой идентификации. Для каждого провайдера предусмотрены возможности тестирования подключения, а пользователям можно настроить несколько вариантов входа.

Добавлена полная система разрешений для контроля доступа к определенным кластерам, запросам и настройкам. Новый интерфейс управления разрешениями позволяет администраторам предоставлять и отзывать доступ, а пользователи могут запрашивать необходимые им разрешения. Это делает Ivory подходящим для больших команд с разными уровнями доступа.

3 часа ночи. Звонок от незнакомого номера. «Пользователи не могут залогиниться, п****ц».

Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?

Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает — никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. «Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли». Ещё 20 минут — поиск Сани, доступы только у него.

Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.

Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.

В статье я рассказываю, как из набора команд (free, df, ip, ps, uptime) собрать CLI‑утилиту на Bash, добавить аргументы, цветовую индикацию и упаковать всё в AUR как пакет system-monitor

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

Задумывались ли вы о том, зачем компьютерам нужна оперативная память (ОП, RAM), когда у них уже есть дисковое хранилище (диск)? Ответ кроется в скорости доступа. Хотя диск является постоянным, он намного медленнее, чем ОП. ОП жертвует изменчивостью ради скорости - данные исчезают при выключении питания, но время доступа гораздо меньше. Как следствие, центральный процессор (ЦП, CPU) имеет доступ только к ОП, а не к диску.

ЦП имеют встроенные регистры, которые еще быстрее, чем ОП. Тогда зачем нам вообще ОП? Затем, что количество и размер регистров ограничены. Представьте функцию, которой нужно работать с тысячью переменных - все они не поместятся в регистры. Что если нам нужно хранить большие структуры данных, такие как массивы или объекты? У регистров нет емкости (capacity). Вот где в игру вступает ОП - она предоставляет пространство, необходимое для обработки больших и сложных данных.

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

Всем привет!

В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.

В этой части продолжим разбираться с параметрами и особенностями конфигурации: триггеры, job’ы, артефакты и многое другое.

Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

Каждый второй заказчик приходит с запросом «нам нужен AI‑агент». На вопрос «а что именно он должен делать?» обычно следует пауза и что‑то вроде «ну, чтобы как ChatGPT, но наш, и чтобы работал».

Окей.

Проблема в том, что между «чат‑ботом с GPT» и «AI‑агентом» — пропасть размером примерно в полгода разработки и массу седых волос. И нет, дело не в том, что агент — это какая‑то магия. Дело в том, что это инженерная система со своей архитектурой, компонентами и подводными камнями.

Эта статья — попытка разложить по полочкам, из чего состоит AI‑агент. Без маркетингового булшита про «революцию в бизнесе» и «цифровую трансформацию». Просто архитектура, компоненты, код, грабли.

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

В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете.