Голое железо и root-доступ, ВМ со снапшотами по расписанию, Kubernetes с GitOps в проде или всё сразу. В фановом тесте от команды Deckhouse из таких ответов складывается один из 10 типов инфраструктуры.

Укротитель давно научился жить с ВМ и Kubernetes рядом, но устал от двух центров управления. Соковыжималка запускает базы и ML прямо на железе, чтобы гипервизор не съедал производительность. Антиквар не трогает систему, которая работает с нулевых. А Повелителю облаков уютно до первого кругленького счёта.

Грузчик и Коллекционер выпадают реже всех. Если достался один из них, ссылкой на результат точно стоит поделиться с командой.

→ Пройти тест и узнать свой тип

actionlint: найти ошибку в workflow до запуска GitHub Actions

В синтаксически корректном YAML может быть неверное имя параметра action или обращение к отсутствующему полю матрицы. actionlint находит такие ошибки статическим анализом. В примере проекта он замечает неизвестный input node_version и обращение к matrix.platform, которого нет в матрице.

После установки запустите в репозитории:

actionlint

Утилита сама найдёт workflow и выведет диагностику с файлом, строкой и проблемным выражением. Для проверки shell- и Python-фрагментов есть интеграции с ShellCheck и pyflakes, если они доступны в окружении. Успешная проверка не гарантирует, что workflow выполнится: доступность сервисов и результат реального запуска она не проверяет.

gping: сравнить задержку до двух хостов на одном графике

Чтобы сопоставить ping до двух адресов, передайте оба хоста одной команде gping:

gping google.com facebook.com

У каждого адреса появится своя линия. На графике видно, когда задержка выросла и совпали ли всплески у разных хостов. Флаг -b задаёт, сколько секунд истории помещается на экране. По умолчанию это 30 секунд. Адреса в примере можно заменить своими.

Обычный режим измеряет ping, поэтому по нему нельзя судить о времени ответа HTTP или скорости скачивания. Утилита также умеет измерять длительность команд через --cmd, но это отдельный режим. В ролике показана демонстрация из репозитория, её числа не описывают вашу сеть.

csvlens: отфильтровать CSV прямо в терминале

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

csvlens Pokemon.csv

Нажмите / и введите Flying, чтобы подсветить совпадения. Для фильтра строк нажмите & и введите Bug. Это разные действия: поиск сохраняет всю таблицу, а фильтр скрывает неподходящие строки. Клавиша * задаёт фильтр столбцов. Выражения в этих режимах — регулярные.

Если файл разделён табуляцией, используйте -t. Для автоматического определения разделителя есть -d auto. csvlens работает как просмотрщик и не изменяет исходный CSV. Файл в команде замените своим.

Ouch: посмотреть дерево архива до распаковки

Чтобы узнать, лежат ли файлы внутри одной папки или сразу в корне архива, его необязательно распаковывать. У Ouch для этого есть подкоманда list:

ouch list source-code.zip --tree

Она показывает вложенные каталоги и файлы деревом. Так можно заранее проверить структуру и выбрать каталог для будущей распаковки. В команде подставьте имя своего архива. Если важны размеры, добавьте --show-size: это несжатый размер каждого файла, а не его вклад в размер архива.

Формат определяется по расширению. Для RAR поддержаны чтение, просмотр списка и распаковка, но создавать RAR утилита не умеет. На карточке — сокращённый пример дерева из документации, а не результат проверки вашего файла.

Pueue: поставить длительные команды в очередь

В Pueue команды выполняет фоновый процесс pueued, а клиент добавляет задания и показывает их состояние. Поэтому выполнение не привязано к открытому терминалу клиента. По умолчанию очередь запускает одно задание за раз.

После установки запустите daemon и добавьте безопасное пробное задание из руководства:

pueued -d
pueue add sleep 60
pueue status

В таблице появится задача и её статус. Вывод задания можно посмотреть через pueue log. Для реальной команды сначала проверьте, что она делает и как переданы аргументы.

Без запущенного daemon очередь не работает. Сохранение её состояния также не означает, что прерванный процесс продолжится с той же инструкции после перезагрузки. Ролик показывает работу клиента из демонстрации проекта.

grpcurl: узнать, какие сервисы предоставляет gRPC-сервер

Если на сервере включена reflection, grpcurl может получить описание API и перечислить сервисы без локальных файлов схемы. Для работающего сервера с TLS и reflection команда выглядит так:

grpcurl localhost:8787 list

Адрес здесь взят из документации, его нужно заменить адресом своего сервера. Если после адреса и list указать имя сервиса, утилита перечислит его методы. Это помогает разобраться с незнакомым API до вызова конкретного метода.

Для локального сервера без TLS нужен -plaintext. Этот флаг полностью отключает TLS, а не только проверку сертификата. Если reflection недоступна, передайте .proto через -import-path и -proto либо готовый набор дескрипторов через -protoset. С локальной схемой list перечисляет определённые в ней сервисы без подключения к серверу.

procs: дерево родительских и дочерних процессов

Если у процессов похожие команды, дерево помогает увидеть связи между ними. У procs есть режим дерева:

procs --tree

Он сортирует процессы по зависимостям и рисует ветви слева от строк. Так видно родительский процесс и его потомков. Для обновления вывода можно добавить --watch. Если передать текстовый аргумент, procs по умолчанию ищет его в полях USER и Command, а числовой аргумент — среди PID.

Набор видимых данных зависит от прав и конфигурации. Скриншоты проекта сделаны с config/large.toml, поэтому чистая установка может показывать другие столбцы. Linux и Windows поддержаны, а macOS и FreeBSD в документации отмечены как экспериментальные. На карточке — схема связей без реальных PID.

Posting 3 beta: оставить в JSON-ответе нужных пользователей

В терминальном HTTP-клиенте Posting 3 можно искать текст в ответе, просматривать JSON как дерево и фильтровать его через JSONPath. Запросы сохраняются локально в YAML. В демонстрации проекта сначала ищут поле role, затем оставляют пользователей с ролью admin:

$.users[?@.role=="admin"]

Выражение рассчитано на показанную структуру: массив users, в объектах которого есть поле role. В результате остаётся подходящий объект, а не просто подсвечивается строка. Для другого ответа путь и условие нужно изменить. JSONPath здесь не следует смешивать с синтаксисом jq.

Posting 3 пока находится в beta. Ролик показывает именно эту ветку клиента. Значения времени и размера ответа в нём относятся к демонстрационному запросу, а не к замеру производительности.

Trippy: посмотреть ответы узлов по пути к серверу

Trippy совмещает traceroute и ping: показывает узлы маршрута и обновляет статистику ответов каждого из них. В документации для запуска приведена команда:

sudo trip example.com

Подставьте свой адрес. Повышенные права обычно нужны для raw sockets. В таблице можно сопоставить отправленные и полученные пробы, задержку и долю ответов по узлам. На ролике из репозитория также видно, как меняются данные при выборе другого узла и цели. Это демонстрация версии 0.12.0.

Строка No response или 100% в Loss% у промежуточного узла сама по себе не доказывает потерю прикладного трафика. Следующие узлы могут отвечать. Для диагностики сопоставьте несколько строк маршрута.

Taplo: проверка TOML по синтаксису и схеме

Taplo проверяет синтаксис TOML и такие ошибки, как повторное определение ключа. Для файла проекта запустите:

taplo check foo.toml

Имя файла замените своим. Без схемы Taplo проверяет сам документ, но не знает, какие ключи разрешены конкретным приложением. Синтаксически корректный файл всё ещё может содержать неверную настройку.

Для проверки требований к структуре подключите подходящую JSON Schema Draft 4 через --schema. В документации адрес схемы дан как пример, поэтому нужен реальный адрес схемы вашего формата. Отдельно можно настроить каталог схем через --schema-catalog. Такую проверку можно запускать перед коммитом конфигурации.

Lazydocker: выбрать контейнер и открыть его логи

Когда нужно сопоставить состояние нескольких контейнеров с их логами, Lazydocker показывает это в одном терминальном интерфейсе. После установки и настройки доступа к Docker daemon запустите:

lazydocker

Выберите сервис слева: справа появятся его логи, состояние и другие доступные панели. Переключайтесь между сервисами, чтобы посмотреть логи нужного контейнера. Текущий README указывает требование Docker 29.0.0 или новее. Docker Compose нужен только для соответствующих сценариев.

Интерфейс позволяет также перезапускать и удалять контейнеры, выполнять очистку. Учитывайте это при выборе действий в меню. На скриншоте — старый пример интерфейса из репозитория, показанные в нём версии образов не являются рекомендацией для установки.

gron: найти путь к полю в незнакомом JSON

Когда значение спрятано глубоко в ответе API, gron помогает найти его обычным текстовым поиском. Режим --json превращает документ в поток строк с путями и значениями. В примере проекта ищут поле likes:

gron --json testdata/two.json | grep likes

Так видно, к какой ветви относятся совпадения. Чтобы собрать найденную часть обратно в JSON, в документации используют тот же режим при обратном преобразовании:

gron --json testdata/two.json | grep likes | gron --json --ungron

Путь к файлу замените своим. Учитывайте, что grep сопоставляет текст: он может найти совпадение и в имени, и в значении. Для сложных преобразований нужна проверка структуры результата. Карточка показывает последовательность команд, без имитации запуска.

Dive: почему удаление файла не уменьшило образ

Удаление файла в новом слое Docker-образа не убирает его из предыдущего слоя. В Dive можно проследить, где файл появился, менялся или был удалён. Откройте свой существующий образ:

dive <your-image-tag>

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

Dive помогает найти, где место может тратиться впустую, но сам не уменьшает образ. Его image efficiency — экспериментальная оценка, а не обещание достижимой экономии. В README инструмент отмечен как beta quality, поэтому выводы стоит проверять по составу слоёв, а не по одному проценту.

chezmoi: проверить изменения dotfiles перед применением

chezmoi хранит исходное состояние конфигурации отдельно от файлов в домашнем каталоге. Команда edit меняет управляемую копию. Изменения в домашнем каталоге нужно применять отдельно, поэтому их можно сначала просмотреть.

Если chezmoi уже установлен и инициализирован, а нужные файлы добавлены под управление, выполните:

chezmoi diff
chezmoi -n -v apply

Первая команда покажет различия, вторая подробно выведет действия без записи. Флаг -n включает dry run, -v — подробный вывод. Если изменений нет, diff может быть пустым.

Обычный apply без -n уже меняет файлы. Переходите к нему после просмотра изменений. По умолчанию исходное состояние хранится в ~/.local/share/chezmoi. На карточке — исходное состояние и команды проверки.

Проверить JSON-запрос до отправки с xh

В xh есть режим --offline: клиент собирает HTTP-запрос и выводит его в терминал, не обращаясь к серверу. Удобно, когда нужно сначала проверить типы полей в JSON и заголовки.

xh --ignore-stdin --offline POST https://example.com/users name=anna age:=24

--ignore-stdin отключает чтение тела из stdin. С name=anna в JSON попадёт строка, с age:=24 — число. Оператор == задаёт параметр query string, двоеточие — заголовок. В выводе можно проверить, куда попало каждое значение.

После проверки уберите --offline и укажите свой тестовый адрес. В этом режиме вы проверяете только состав запроса. Ответ сервера и правила валидации API он не покажет. Синтаксис похож на HTTPie, однако xh поддерживает не все его возможности и не имеет системы плагинов.

Cosign: подпись образа нужно связать с ожидаемым автором

Проверяя скачанный контейнерный образ через Cosign, заранее задайте, чью подпись вы готовы принять. В keyless-сценарии документация требует проверить и личность подписанта, и OIDC-провайдера.

За личность отвечает --certificate-identity, за провайдера — --certificate-oidc-issuer. Проверяйте оба значения: просто найти подпись у образа недостаточно, если вам нужен артефакт конкретного проекта. Ожидаемые значения берите из доверенного процесса выпуска, а не из самого непроверенного файла.

По умолчанию Cosign также сверяет digest образа с digest в подписанных данных. Это связывает подпись с конкретным содержимым. Успешная проверка подтверждает эти условия, но не подтверждает отсутствие уязвимостей в образе.

sccache и промахи кэша из-за пути к проекту

Два CI-задания собирают один код, но checkout лежит в разных абсолютных каталогах. Для sccache это существенная разница: по умолчанию абсолютные пути должны совпадать, чтобы использовать сохранённый результат компиляции.

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

Это настройка для повторных сборок с разными корнями checkout. Она не делает любую компиляцию кэшируемой: например, у Rust не кэшируются инкрементальные сборки и crates, вызывающие системный линкер. Проверяйте попадания и промахи по статистике sccache.

Найти тяжёлый каталог с gdu и запретить удаление

Если нужно разобраться, что занимает место в проекте, gdu покажет размеры каталогов и файлов. Для первичного осмотра можно сразу отключить удаление и получить текстовый отчёт по текущему каталогу:

gdu -n --no-delete .

Флаг -n выбирает неинтерактивный режим, --no-delete запрещает удаление. В интерактивном интерфейсе без этого ограничения есть клавиши удаления и очистки каталога, поэтому режим осмотра стоит выбрать заранее.

По умолчанию gdu считает занятое место на диске. Видимый размер содержимого файла можно посмотреть отдельно с -a. Эти величины могут различаться. Прежде чем очищать самый большой каталог, проверьте, какие данные в нём лежат.

Версии Rust для сборки и запуска nextest

cargo-nextest — отдельный запускатель тестов Cargo. Перед добавлением в CI проверьте, собираете ли вы сам nextest из исходников или используете готовую утилиту: в README для этих случаев указаны разные требования.

Минимальная версия Rust для сборки nextest — 1.91. Для запуска указан Rust 1.41, но авторы отдельно оговаривают, что столь старые версии не тестируют. Они ожидают совместимость с версиями Rust, выпущенными за последний год. Старый номер в таблице не стоит читать как гарантию для давно замороженного CI-образа.

В репозитории также есть библиотеки runner, metadata и filtering. Если вам нужен именно инструмент запуска тестов, ориентируйтесь на пакет cargo-nextest. Подробный выбор тестов и режимов вынесен в руководство проекта.