Библиотека девопса | DevOps, SRE, Sysadmin

🛠 Переключение namespace в kubectl одной командой Если вы работаете с Kubernetes, то наверняка устали дописывать -n my-namespace к каждой команде. Это раздражает, отнимает время и рано или поздно приводит к ошибке — забыли флаг, команда ушла в default, получили не тот результат. Проблема решается одной строкой:

kubectl config set-context --current --namespace=<namespace>

Эта команда меняет namespace по умолчанию в текущем контексте вашего kubeconfig. После выполнения все последующие вызовы kubectl будут работать с указанным namespace без дополнительных флагов. Допустим, вы работаете с namespace staging:

kubectl config set-context --current --namespace=staging

Теперь kubectl get pods покажет поды именно из staging. Не нужно писать kubectl get pods -n staging каждый раз. Как проверить текущий namespace Убедиться, какой namespace сейчас выставлен, можно так:

kubectl config view --minify --output 'jsonpath={..namespace}'

Если команда ничего не вернула, значит, используется default. Что важно понимать Настройка сохраняется в файле ~/.kube/config и действует не только на текущую сессию терминала. Она будет активна до тех пор, пока вы не переключитесь на другой namespace или не смените контекст. Для тех, кто переключает namespace часто, есть утилита kubens из пакета kubectx. Она делает то же самое, но короче:

kubens staging

Мелочь, но экономит десятки лишних символов в день. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🧑‍💻 su и sudo — в чём разница и когда что использовать su и sudo дают доступ к привилегиям суперпользователя, но работают по-разному. Что делает su su (substitute user) переключает текущую сессию на другого пользователя. По умолчанию — на root. При вызове команда запрашивает пароль того пользователя, на которого вы переключаетесь. После ввода пароля root вы получаете полноценную root-сессию. Все последующие команды выполняются от имени суперпользователя до тех пор, пока вы не выйдете через exit. Если нужно переключиться с загрузкой окружения целевого пользователя, используйте форму с дефисом:

su -

Это загрузит переменные окружения, $HOME, $PATH и профиль root так, как если бы вы залогинились напрямую. Что делает sudo sudo (superuser do) выполняет одну конкретную команду с повышенными привилегиями. Пароль запрашивается ваш собственный, а не пароль root.

sudo apt update

Команда отработает от имени root, после чего вы вернётесь в свою обычную сессию. Никакого переключения пользователя не происходит. Список пользователей, которым разрешено использовать sudo, и допустимые для них команды задаются в файле /etc/sudoers. Редактировать его нужно только через visudo, чтобы избежать синтаксических ошибок, которые могут заблокировать доступ. Ключевые отличия su требует знать пароль root. sudo требует только ваш пароль и запись в sudoers. Это принципиальная разница с точки зрения безопасности. Раздавать пароль root нескольким администраторам — плохая практика. С sudo каждый работает под своей учёткой, а все действия логируются с привязкой к конкретному пользователю. su открывает постоянную root-сессию. Забыли выйти — любая случайная команда выполнится с максимальными правами. sudo работает точечно, на одну команду, что снижает риск случайного повреждения системы. Когда что использовать sudo подходит для большинства задач администрирования. Обновить пакеты, перезапустить сервис, отредактировать конфиг — всё это удобнее и безопаснее делать через sudo. su оправдан, когда нужно выполнить серию команд от root подряд, и переключение в полноценную root-сессию экономит время. Но даже в этом случае можно заменить его на:

sudo -i

Эта команда открывает интерактивную root-сессию через механизм sudo, без необходимости знать пароль root. В современных дистрибутивах sudo стал стандартом. Ubuntu, например, по умолчанию вообще отключает вход под root и предлагает использовать только sudo. Это безопаснее, прозрачнее для аудита и не требует распространения root-пароля. Используйте su только если точно понимаете, зачем вам полная root-сессия. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

😎 Знакомьтесь с экспертом Proglib.academy: AI-архитектор Андрей Носов Андрей — один из ключевых спикеров нашего курса AgentOps. Он выстраивает архитектуру, которая выживает в суровом проде и активно делится своим опытом. За что его ценит IT-комьюнити: 🟣 Топ-спикер AI Conf 2026

Его доклад про мифы семантического поиска и провалы Naive RAG стал одним из самых рейтинговых на конференции.

🟣 Эксперт по GraphRAG и Knowledge Graphs

Андрей внедряет инженерный подход в сложные системы, заменяя «слепую веру» в эмбеддинги строгой логикой графов.

🟣 Автор «14 кругов ада для RAG»

Разработал уникальный набор из 14 unit-тестов, на которых ломается стандартный векторный поиск (от слепоты к отрицаниям до конфликта версий).

🟣 Спикер Saint HighLoad

Регулярно выступает на крупнейших хайлоад-площадках, разбирая архитектуру отказоустойчивых ИИ-сервисов.

Андрей упаковал свои наработки в Google Colab, где можно пощупать 14 сценариев ошибок RAG и их решения: 🔗 Забрать Colab-ноутбук На курсе Андрей отвечает за самые «мясные» блоки: RAG, оркестрацию агентов и их промышленную эксплуатацию. Узнать больше о программе и обучении у Андрея: 👉 Курс о том, как внедрять AI-логику в бэкенд и сохранять стабильность сервиса Так, продолжаем знакомить вас с командой? 👍 — Да, ждем новых лиц 🔥 — Пойду тестить Colab Носова

🔒 Блокировка неиспользуемых модулей ядра Linux одним скриптом ModuleJail — это shell-скрипт без зависимостей, демонов и initramfs-изменений. Он читает список загруженных модулей из /proc/modules, сравнивает его с полным деревом модулей в /lib/modules/, и для всего, что не используется, генерирует файл /etc/modprobe.d/modulejail-blacklist.conf с директивами install <mod> /bin/true. Есть встроенный базовый набор модулей, которые никогда не попадут в блокировку: файловые системы, контроллеры хранилищ, сетевые драйверы. Плюс можно задать свой whitelist. Зачем это нужно именно сейчас Автор проекта исходит из того, что AI-инструменты для поиска уязвимостей скоро начнут массово находить скрытые баги в модулях ядра. Это хорошо в долгосрочной перспективе, но в краткосрочной означает поток CVE, за которыми сложно успевать. Если модуль заблокирован и не загружается, очередная уязвимость в нём вас просто не касается. Как запустить Безопасный способ — скачать, проверить, запустить:

curl -fsSL https://raw.githubusercontent.com/jnuyens/modulejail/v1.1.4/modulejail -o /tmp/modulejail
less /tmp/modulejail
sudo sh /tmp/modulejail

Для Debian/Ubuntu и RHEL/Fedora/Rocky есть готовые пакеты:

# Debian / Ubuntu
curl -fsSLO https://github.com/jnuyens/modulejail/releases/download/v1.1.4/modulejail_1.1.4_all.deb
sudo dpkg -i modulejail_1.1.4_all.deb

# RHEL / Fedora / Rocky
curl -fsSLO https://github.com/jnuyens/modulejail/releases/download/v1.1.4/modulejail-1.1.4-1.noarch.rpm
sudo rpm -i modulejail-1.1.4-1.noarch.rpm

Профили Скрипт поддерживает три профиля через флаг -p:

sudo sh modulejail -p conservative
sudo sh modulejail -p minimal
sudo sh modulejail -p desktop

conservative (по умолчанию) подходит для серверов и виртуалок. desktop сохраняет WiFi, Bluetooth, аудио и видео. minimal оставляет только ядро файловых систем и самое необходимое. Модель безопасности Принцип простой. Всё, что загружено в момент запуска скрипта, считается нужным и сохраняется. Всё остальное блокируется. Поэтому запускать ModuleJail нужно на стабильной системе, когда все сервисы подняты, все драйверы загружены, все файловые системы смонтированы. Откат тоже простой:

sudo rm /etc/modprobe.d/modulejail-blacklist.conf
sudo reboot

Или, если нужно вернуть конкретный модуль без ребута:

sudo modprobe <имя_модуля>

Что ещё полезно знать Скрипт идемпотентен. Два запуска подряд на неизменённой системе дают побайтово идентичный результат. В заголовке файла генерируется sha256-отпечаток, рассчитанный по входным данным, а не по времени запуска. Это удобно для флотового управления через Ansible или другие CM-инструменты. Работает на Ubuntu, Debian, Rocky, Arch, Alpine и openSUSE. Из зависимостей нужны только awk, comm, find и sha256sum, которые есть в любом базовом Linux, включая busybox. ➡️ GitHub-репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

📎 Ловим drift в Terraform автоматически Кто-то поправил инфраструктуру руками через консоль. Terraform об этом ничего не знает. При следующем terraform apply начинаются конфликты, откаты и разбор полётов. Это называется drift. Состояние инфраструктуры разошлось с тем, что описано в коде. Terraform сам по себе drift не отслеживает. Но у него есть инструмент, который помогает это делать. Как обнаружить drift У terraform plan есть флаг -detailed-exitcode. Он возвращает разные коды выхода в зависимости от результата.

terraform plan -detailed-exitcode

Код 0 означает, что изменений нет. Код 1 говорит об ошибке. А вот код 2 сигнализирует, что план нашёл расхождения между стейтом и реальной инфраструктурой. Именно код 2 и есть индикатор drift. Проверять это вручную каждый раз неудобно. Гораздо надёжнее встроить проверку в CI. Например, в GitHub Actions это можно сделать так:

name: Drift Detection
on:
  schedule:
    - cron: '0 9 * * 1'

jobs:
  detect-drift:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -detailed-exitcode
        continue-on-error: true
        id: plan
      - run: echo "Drift detected!"
        if: steps.plan.outcome == 'failure' && steps.plan.outputs.exitcode == '2'

Этот воркфлоу запускается раз в неделю по понедельникам. Если plan вернул код 2, значит, кто-то менял инфру в обход Terraform. Аналогичную логику можно настроить и в Jenkins через проверку $? после выполнения команды. Drift неизбежен в командах, где инфраструктурой занимается больше одного человека. Регулярная автоматическая проверка через CI помогает поймать расхождения до того, как они превратятся в проблему на проде. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

📰 Топ 5 новостей недели — Debian 13.5 Обновлено больше сотни пакетов: закрыты CVE в apache2, openssh, systemd, sudo, glibc, nginx, curl, python3.13 — NWinfo v1.6.3 — Leaf 1.21.0 — Что будет в Podman 6 — nginx 1.31.0 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #дайджест_недели

👨‍💻 Terraform 1.15 — динамические источники модулей, deprecation переменных и другие обновления Вышел Terraform 1.15. В этом релизе появились переменные в источниках модулей, механизм deprecation для переменных и output, функция convert для явного приведения типов и нативная поддержка Windows ARM64. Разберём основные изменения. Динамические источники модулей Раньше source в блоке module принимал только статическую строку. Теперь можно использовать переменные. Для этого добавлен новый атрибут const у переменных. Он принимает true или false и указывает, что значение доступно уже на этапе terraform init:

variable "folder" {
  type  = string
  const = true
}

После этого переменную можно подставлять в source:

module "zoo" {
  source = "./${var.folder}"
}

Важный момент — const нельзя сочетать с sensitive или ephemeral. Если вы сошлётесь на что-то кроме const-переменной, Terraform выдаст ошибку при init. Deprecation переменных и output Авторы модулей теперь могут помечать переменные и output как устаревшие через атрибут deprecated. При обращении к такому элементу Terraform покажет предупреждение на этапе валидации.

variable "bad" {
  deprecated = "Please use 'good' instead, this variable will be removed"
}

output "old" {
  value      = "some_value"
  deprecated = "Please use 'new' instead, this output will be removed"
}

Логика работает на нескольких уровнях. Если кто-то передаёт значение в deprecated-переменную через CLI или переменные окружения, будет warning. Если модуль ссылается на deprecated output дочернего модуля внутри своего deprecated output, предупреждение не сработает. Но если deprecated output стоит на корневом уровне, это уже ошибка. Такой подход позволяет авторам модулей плавно выводить старые интерфейсы из обращения. Inline-приведение типов через convert Новая функция convert решает давнюю проблему с неявным приведением типов. Terraform обычно сам определяет типы, но в ряде случаев это работает некорректно. Например, {} интерпретируется как пустой object без атрибутов, а не как пустой map. Аналогично [] — это пустой tuple, а не list. convert позволяет явно указать нужный тип и создавать корректные нулевые значения для сложных коллекций. Это особенно полезно в условных выражениях, где ветки возвращают данные разных типов. Прочие изменения Terraform 1.15 теперь собирается под Windows ARM64. Это актуально для владельцев Surface Pro, Windows Dev Kit 2023, а также для тех, кто запускает Windows-виртуалки на Mac M1/M2 через Parallels. S3-бэкенд получил поддержку аутентификации через aws login (AWS CLI v2.32.0+). Это значит, что можно использовать credentials из консоли AWS без долгоживущих access-ключей. У output-блоков появились type constraints — явные ограничения типа, аналогичные тем, что давно есть у input-переменных:

output "string" {
  type  = string
  value = var.some_string
}

В Terraform Test теперь разрешены функции внутри mock-блоков. Можно генерировать тестовые данные через uuid() или format(), что упрощает мокирование ресурсов с конкретными форматами ID. Для Stacks добавлены validation-блоки в переменных с атрибутами condition и error_message. Это помогает ловить ошибки конфигурации на раннем этапе. Обнова за обновой выходит каждый день. Мы отбираем только самое важное для вас в нашей рассылке. 👉 Подпишитесь 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пятничный_деплой

🛠 Продолжаем копать Kubernetes v1.36 В Kubernetes v1.36 поле .spec.externalIPs у Service официально помечено как deprecated. Удаление запланировано на v1.43. Если вы используете externalIPs в своих манифестах, пора планировать миграцию. В чём проблема Поле externalIPs появилось как способ направить внешний трафик на кластерные поды без облачного балансировщика. Идея простая: указываете IP, и kube-proxy создаёт правила iptables для маршрутизации трафика. Проблема в том, что API не проверяет, кому принадлежит указанный IP. Любой пользователь с правами на создание или редактирование Service может указать произвольный внешний адрес. kube-proxy послушно создаст NAT-правила, и трафик, предназначенный для этого IP, уйдёт в под атакующего. Это классическая атака «человек посередине». В мультитенантных кластерах, где у тенантов есть права на управление сервисами в своём неймспейсе, один скомпрометированный тенант может перехватывать трафик всего кластера. Уязвимость описана в CVE-2020-8554 ещё в декабре 2020 года. Вот пример вредоносного сервиса, который перехватывает трафик к внешнему IP:

apiVersion: v1
kind: Service
metadata:
  name: mitm-externalip
spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
  selector:
    app: echoserver
  type: ClusterIP
  externalIPs:
    - 104.16.185.241

После создания такого сервиса весь трафик с нод кластера к 104.16.185.241:80 будет перенаправлен на под echoserver. Без каких-либо предупреждений. Почему так долго тянули Проект Kubernetes рекомендовал отключать externalIPs ещё с версии 1.21, когда появился admission controller DenyServiceExternalIPs. Но SIG Network посчитала, что блокировка по умолчанию стала бы слишком серьёзным breaking change. Спустя пять лет подход изменился. В v1.36 добавлен feature gate AllowServiceExternalIPs (по умолчанию true). Процесс удаления разбит на этапы: В v1.36 kube-proxy получает возможность не создавать правила для externalIPs через feature gate. Использование поля генерирует deprecation warning. В последующих релизах feature gate будет по умолчанию переключён на false, а затем поле будет полностью удалено. Финальное удаление запланировано на v1.43. Что делать Проверьте свои манифесты на наличие externalIPs:

kubectl get svc -A -o json | jq '.items[] | select(.spec.externalIPs != null) | {name: .metadata.name, ns: .metadata.namespace, ips: .spec.externalIPs}'

Варианты замены зависят от сценария. Для облачных кластеров подойдут Service типа LoadBalancer. Для bare-metal окружений стоит посмотреть в сторону MetalLB или другого контроллера внешних балансировщиков. Для HTTP-трафика есть реализации Gateway API. Если вы уже используете Cilium в режиме замены kube-proxy, уязвимость CVE-2020-8554 вас не затрагивала, но миграция с externalIPs всё равно нужна, потому что само поле из API исчезнет. Шесть лет жизни с известной MITM-уязвимостью подходят к концу. Поле externalIPs получило статус deprecated в v1.36 и будет удалено в v1.43. Времени достаточно, но аудит манифестов лучше провести сейчас, пока это ещё предупреждения, а не ошибки. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

❓ Где хранятся тома Docker в Linux по умолчанию Вы создали volume командой docker volume create mydata. Куда на диске он попал? 💡 Подсказка: путь начинается с /var, а Docker хранит там не только тома, но и образы, контейнеры и сети. ➡️ Ответ 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой

⭐️ Три команды для быстрой диагностики Linux Когда подключаетесь к новому серверу или разбираетесь с чужой виртуалкой, первое, что нужно понять — что вообще за машина перед вами. Вот три команды, которые дают полную картину за секунды. Информация о системе hostnamectl выводит сводку по ОС, ядру, архитектуре и типу виртуализации.

hostnamectl

Пример вывода:

Static hostname: linux-server
 Operating System: Ubuntu 24.04 LTS
 Kernel: Linux 6.8.0
 Architecture: x86-64
 Virtualization: oracle

Здесь сразу видно, на какой ОС работает сервер, какая версия ядра установлена, какая архитектура используется и запущена ли система внутри виртуальной машины. Одна команда вместо четырёх. Информация о процессоре lscpu показывает всё, что касается CPU.

lscpu

Пример вывода:

Architecture:        x86_64
CPU(s):              8
Model name:          Intel(R) Core(TM) i7
Thread(s) per core:  2
Core(s) per socket:  4

Обратите внимание на разницу между полями. CPU(s) — это общее число логических процессоров. Core(s) per socket — физические ядра. Thread(s) per core — количество потоков на ядро, то есть показатель гиперпоточности. Команда полезна, когда проверяете характеристики сервера, ищете причину просадки производительности или хотите убедиться, что виртуалке выделено столько ресурсов, сколько заявлено. Информация о дисках и разделах lsblk выводит структуру блочных устройств.

lsblk

Пример вывода:

NAME   SIZE TYPE MOUNTPOINT
sda    100G disk
├─sda1  1G part /boot
├─sda2 50G part /
└─sda3 49G part /home

Команда показывает диски, разделы, их размеры и точки монтирования. Если путаете эти понятия, вот простое правило. Диск — это физическое или виртуальное устройство хранения целиком. Раздел — логическая часть внутри диска. В примере sda — это диск на 100 ГБ, а sda1, sda2, sda3 — три раздела внутри него. Итого Три команды, которые стоит запомнить: hostnamectl — что за система lscpu — что за процессор lsblk — что за диски Этого достаточно, чтобы за полминуты понять, с какой машиной вы работаете. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🔄 nginx 1.31.0: шесть CVE и встроенный forward proxy Вышел nginx 1.31.0. Закрыто шесть уязвимостей, некоторые из них позволяли выполнить произвольный код или раскрыть содержимое памяти рабочего процесса. Помимо фиксов, появилась долгожданная фича — поддержка HTTP CONNECT, то есть nginx теперь умеет работать как forward proxy. Что исправлено CVE-2026-42926 — инъекция данных в проксируемый запрос при использовании proxy_set_body с HTTP/2-бэкендом. CVE-2026-42945 — переполнение буфера в ngx_http_rewrite_module. Специально сформированный запрос мог привести к выполнению произвольного кода. Одна из самых серьёзных уязвимостей в этом релизе. CVE-2026-42946 — чтение за границами буфера в ngx_http_scgi_module и ngx_http_uwsgi_module. Атакующий мог вызвать раскрытие памяти рабочего процесса или его падение через специально сформированный ответ. CVE-2026-42934 — аналогичная проблема с чтением за границами буфера, но уже в ngx_http_charset_module при декодировании UTF-8 через директиву charset_map. CVE-2026-40460 — спуфинг адреса клиента в HTTP/3. При миграции соединения новые QUIC-стримы получали новый адрес клиента до его валидации. CVE-2026-40701 — use-after-free при обработке DNS-ответов, если использовалась директива ssl_ocsp. Могло привести к повреждению памяти или падению рабочего процесса. Что нового Главное нововведение — модуль ngx_http_tunnel_module. Nginx теперь умеет обрабатывать HTTP CONNECT-запросы и работать как forward proxy. Модуль поддерживает аутентификацию через auth_basic, satisfy и auth_delay. Также добавлена директива least_time внутри блока upstream. Она выбирает бэкенд с наименьшим временем ответа. Раньше эта функциональность была доступна только в NGINX Plus. В stream-модуле появилась директива proxy_ssl_alpn для указания ALPN-протокола при проксировании с TLS. Изменения в поведении nginx теперь отклоняет HTTP/2 и HTTP/3 запросы с заголовками Connection, Proxy-Connection, Keep-Alive, Transfer-Encoding, Upgrade, а также TE с любым значением кроме trailers. Это соответствует спецификации, но если у вас есть клиенты, которые отправляют такие заголовки через HTTP/2, после обновления они получат ошибку. Модуль ngx_http_dav_module теперь отклоняет COPY/MOVE, если источник и назначение совпадают или находятся в отношении «родитель-ребёнок». Уровень логирования ошибок SSL «invalid alert» и «record layer failure» понижен с crit до info. Обновление Учитывая количество и критичность закрытых уязвимостей, обновляться стоит как можно скорее. Особенно если вы используете proxy_set_body, модуль rewrite, SCGI/uWSGI-бэкенды или HTTP/3. ➡️ Полный список изменений 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🔒 Спрятать VM от интернета и не потерять к ней доступ Если вы запускаете что-то с публичным IP, вашу машину уже сканируют. Боты, брутфорс, стук по портам. Стандартная реакция — начать закручивать файрвол на работающей VM. Но именно так люди теряют доступ к собственным серверам. Есть подход лучше. Называется «Private First». Суть в том, чтобы VM вообще не имела публичного адреса с момента создания. Нет адреса — нет поверхности атаки. А доступ к машине и выход в интернет настраиваются отдельными, контролируемыми каналами. Что понадобится VM без внешнего IP (например, e2-medium, Ubuntu 24.04 LTS), Cloud NAT с Cloud Router, Identity-Aware Proxy (IAP) для SSH и Tailscale для доступа к веб-интерфейсу. Всё это укладывается в бесплатный кредит GCP на $300. Cloud NAT — выход в интернет без входа VM без публичного IP не может сама ходить в интернет. Ни apt update, ни docker pull работать не будут. Cloud NAT решает это. Он даёт машине исходящий трафик через Cloud Router, но входящих соединений извне не пропускает. VM видит интернет, интернет не видит VM. IAP — SSH без открытого порта Вместо того чтобы открывать порт 22 для всего мира, вы открываете его только для диапазона 35.235.240.0/20. Это адреса IAP-туннеля Google. Каждая SSH-сессия проходит аутентификацию через Google Identity ещё до того, как первый пакет долетит до VM. Подключение выглядит так:

gcloud compute ssh --tunnel-through-iap <instance-name>

Если вы отрежете этот диапазон в файрволе, потеряете доступ к машине. Это главная ошибка, которую стоит запомнить. Tailscale — доступ к веб-интерфейсу Допустим, на VM крутится n8n, Metabase или любой другой сервис с веб-панелью. Выставлять её в интернет не нужно. Ставите Tailscale на VM и на свой ноутбук. Получаете приватную mesh-сеть поверх WireGuard. Дашборд доступен по адресу вроде http://<tailscale-ip>:5678 с любого вашего устройства. Без SSL-сертификатов, без reverse proxy, без публичного DNS. Два нюанса с Docker Если вы запускаете n8n в Docker, учтите два момента. Контейнер может падать при старте из-за прав на директорию ~/.n8n. Внутренний пользователь n8n ожидает владельца 1000:1000. Фиксится одной командой:

sudo chown -R 1000:1000 ~/.n8n

По умолчанию n8n выставляет N8N_SECURE_COOKIE=true и принимает сессионные куки только по HTTPS. Через Tailscale вы ходите по HTTP на приватный IP, поэтому логин будет молча ломаться. Выставьте N8N_SECURE_COOKIE=false в переменных окружения Docker. На приватной VPN-сети это безопасно. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

📎 Что будет в Podman 6 Podman 6.0 это мажорный релиз с ломающими изменениями. Убраны устаревшие компоненты, переработана конфигурация, обновлён сетевой стек. Если вы используете Podman в продакшене или на локальной машине, стоит знать, что изменится и к чему готовиться. Удаление устаревших компонентов Всё, что было deprecated в пятой ветке, в шестой удалено окончательно. slirp4netns больше нет. Начиная с Podman 5.0 для rootless-сетей по умолчанию использовался Pasta. Теперь это единственный вариант, slirp4netns вырезан из кода вместе с флагом --network-cmd-path. CgroupsV1 больше не поддерживается. Весь связанный код и тесты удалены. Если у вас система на cgroups v1, Podman 6 работать не будет. BoltDB тоже убран. SQLite стал дефолтным бэкендом ещё в Podman 4.8. В 5.7 добавили предупреждение, в 6.0 поддержку BoltDB убрали полностью. Если вы не мигрировали базу, после обновления состояние контейнеров окажется недоступным. Перед обновлением до Podman 6 рекомендуется сначала обновиться до 5.8 и перезагрузиться. Это запустит автоматическую миграцию с BoltDB на SQLite. Переработка конфигурации Одно из заметных изменений. Файлы конфигурации containers.conf и storage.conf переделывают с нуля. Проблема была в том, что удалённые клиенты на Windows и macOS использовали те же конфиги, что и серверная часть. Это приводило к путанице и ошибкам. Новый подход разделяет конфигурацию на клиентскую и серверную части. Логика парсинга containers.conf и storage.conf унифицируется. Если вы работаете с Podman через удалённый клиент, возможно, придётся обновить свои конфиги. Изменения в сетевом стеке Netavark, сетевой бэкенд Podman, тоже получил обновления. Поддержка iptables убрана. Остаётся только nftables. Это затронет тех, кто вручную настраивал iptables для контейнеров. Логика создания сетей перенесена внутрь Netavark, а внутренние структуры данных изменены, чтобы сохранять порядок подключённых сетей для контейнеров. Новый conmon Ведётся работа над новой версией conmon. Подробностей пока мало, но обещают улучшения в производительности и пользовательском опыте. Как проверить готовность к обновлению Убедитесь, что ваша система использует cgroups v2. Проверить можно так:

stat -fc %T /sys/fs/cgroup/

Если в ответе cgroup2fs, всё в порядке. Проверьте, на каком бэкенде работает ваша база Podman:

podman info --format '{{.Host.DatabaseBackend}}'

Если ответ sqlite, миграция не нужна. Если boltdb, обновитесь сначала до Podman 5.8 и перезагрузитесь. Убедитесь, что для rootless-сетей используется Pasta, а не slirp4netns:

podman info --format '{{.Host.Pasta.Executable}}'

Podman 6.0 убирает всё устаревшее и приводит кодовую базу к единому стандарту. Миграция для большинства пользователей должна пройти гладко, потому что Pasta, nftables и SQLite уже были дефолтами. Но если вы работаете на нестандартных конфигурациях с iptables, BoltDB или cgroups v1, нужно подготовиться заранее. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🔄 Leaf 1.21.0 leaf — терминальный превьювер Markdown на Rust. Показывает .md файлы прямо в консоли с подсветкой синтаксиса, таблицами, оглавлением и навигацией. По ощущениям ближе к GUI, чем к обычному cat. В версии 1.21.0 два заметных обновления.   Флаг --inline для вывода в stdout   Раньше leaf работал только в интерактивном режиме — открывал TUI и ждал ввода. Теперь можно рендерить Markdown и сразу печатать результат в stdout без запуска интерфейса.   Это полезно, когда нужно встроить leaf в пайплайн или скрипт. Например, отрендерить файл и сохранить результат:

leaf --inline README.md > rendered.txt

  Или прокинуть через пайп:

cat CHANGELOG.md | leaf --inline

Обновиться:

leaf --update

➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

Talanto.work - сайт для всех, кто ищет работу в IT. Мы спарсили за вас все возможные телеграм каналы и сайты с вакансиями исключительно из сферы IT. Вам не нужно следить за тем, когда выходит вакансия и где, всё это уже сделано за вас. Просто настройте фильтры у нас на сайте и получайте уведомления в телегу, как только вакансия вышла. Например: все вакансии DevOps На talanto.work собрано 28.000+ вакансий из разных .ru и иностранных сайтов: разработка, QA, аналитика, DevOps, продакт, дизайн, менеджмент и другие IT/Digital-направления. Более 1700 вакансий за последний месяц из телеграм каналов. Что еще есть на сайте: 🟠 Фильтры для нормального поиска Можно искать по стеку, грейду, зарплате, стране, формату работы, релокации и типу занятости. 🟠 Разбор резюме Загружаете CV и получаете конкретные рекомендации: что улучшить, какие навыки добавить, где слабая структура и что может мешать пройти ATS. 🟠Проверка соответствия вакансии и резюме Рядом с вакансией всегда есть кнопочка узнать соответствие, насколько ваш профиль ей подходит. Сервис покажет процент совпадения, сильные стороны и пробелы в резюме 🟠Сопроводительное письмо за 10 секунд Вставляете вакансию и получаете персональное письмо под конкретную компанию и роль, а не шаблон “прошу рассмотреть мою кандидатуру”. 🟠Уведомления в Telegram Задаёте фильтры один раз и бот присылает новые подходящие вакансии прямо в Telegram. Поиск работы в IT сейчас и так сложный. Мы хотим, чтобы вы тратили меньше времени на листание сайтов и больше на точные отклики туда, где у вас реально есть шанс. ✈️ 28.000+ вакансий 🟢Бот с уведомлениями о ваших вакансиях: @TalantoWorkBot 🟢Написать сопровод 🟢Разобрать резюме 🟢Проверить соответствие резюме вакансиям Реклама. Киренкина Марина Дмитриевна, ИНН 345702417736. Erid 2Vtzqx28ab1

📣 Топ-вакансий для девопсов за неделю Выбирайте любую из трёх вакансий, все на удалёнку: • DevOps Engineer Middle • DevOps Архитектор • DevOps-инженер (on-call) ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs 🐸Библиотека devops'a #вакансия_недели

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пятничный_деплой

🧑‍💻 5 базовых команд девопса ➡️ Команда wc -l считает строки в файле или в пайпе. Одна из тех вещей, которые используешь каждый день. Логи, CSV, исходники, конфиги. Везде, где нужно быстро понять объём:

$ wc -l server.log
4821 server.log

Набирать wc -l несложно, но можно сделать ещё проще. Создаём алиас lc (line count) и добавляем в конфиг шелла:

# Добавьте в ~/.bashrc или ~/.zshrc, затем: source ~/.bashrc
alias lc='wc -l'

Теперь вместо wc -l пишем просто lc:

$ lc server.log
4821 server.log

Работает и с пайпами:

$ cat access.log | grep "500" | lc
37

37 пятисотых ошибок. Быстро и понятно. ➡️ du -sh * — сколько весит каждая папка Когда заканчивается место на диске, первым делом хочется понять, кто его съел. du -sh * покажет размер каждого элемента в текущей директории в человекочитаемом формате:

$ du -sh *
1.2G    node_modules
4.0K    README.md
256M    dist
12K     src

node_modules на первом месте. Как обычно. Если нужно отсортировать по размеру, добавляем sort:

$ du -sh * | sort -rh
1.2G    node_modules
256M    dist
12K     src
4.0K    README.md

Флаг -r сортирует по убыванию, -h понимает суффиксы K, M, G. ➡️ xargs — передать результат одной команды как аргументы другой xargs берёт строки из stdin и подставляет их как аргументы. Например, найти все .log файлы и удалить их:

$ find /tmp -name "*.log" | xargs rm

Если в именах файлов есть пробелы, безопаснее использовать разделитель через null:

$ find /tmp -name "*.log" -print0 | xargs -0 rm

Ещё полезный приём. Посчитать общее количество строк во всех Python файлах проекта:

$ find . -name "*.py" | xargs wc -l

➡️ column -t — превратить текст в ровную таблицу Вывод многих команд выглядит как каша из слов, разделённых пробелами. column -t выравнивает столбцы и делает вывод читаемым:

$ cat data.txt
name age city
alice 30 berlin
bob 25 munich

$ column -t data.txt
name   age  city
alice  30   berlin
bob    25   munich

Хорошо работает с CSV, если указать разделитель:

$ column -t -s',' users.csv

➡️ watch — повторять команду каждые N секунд watch запускает любую команду с заданным интервалом и обновляет вывод в терминале. По умолчанию интервал 2 секунды:

$ watch df -h

Эта команда будет каждые 2 секунды показывать состояние дисков. Удобно, когда ждёте, пока освободится место, или следите за каким-то процессом. Можно изменить интервал через -n:

$ watch -n 5 kubectl get pods

Каждые 5 секунд обновляет статус подов. Проще, чем жать стрелку вверх и Enter раз за разом. Все эти команды работают в любом Linux и macOS из коробки. Ничего ставить не нужно. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🔥 Знакомьтесь с экспертом Proglib.academy: Эмиль Сатаев Эмиль — эксперт с 8-летним опытом в разработке, который специализируется на внедрении LLM и агентных подходов в реальные коммерческие сервисы. Он точно знает, как проектировать архитектуру так, чтобы ИИ-функции работали стабильно в связке с внешними системами. 🏃‍♀️ Уже 14 мая Эмиль проведет открытый вебинар! Обсудим самую «больную» тему: «Почему AI-продукты на базе LLM ломаются и как сделать, чтобы работало». 🗓 Когда: 14 мая в 19:00 (Мск) Почему Эмиля стоит послушать: 🟣 8+ лет в разработке (Backend и Frontend)

Прошел путь от фулстека до Backend Platform Developer в SMIT.Studio.

🟣 Международный исследовательский опыт

Работал исследователем в Институте ИИ НИУ ВШЭ и в Национальном университете Сингапура (NUS).

🟣 Преподаватель-практик

Ведет семинары в НИУ ВШЭ, в том числе по проектированию и разработке агентских систем.

🟣 Мастер интеграции AI в Backend

Его главная суперсила — умение правильно встраивать LLM через API, выстраивать workflow и агентную логику в сложных распределенных системах.

🔗 Зарегистрироваться на вебинар