Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями...
Только что я релизнул cli-stashv0.2.9. Теперь можно редактировать сохраненную команду.
cli-stash - tui-тулза для добавления терминальных команд в избранное, с возможностью переноса из истории
Кейсы использования такие:
Вы хотите параметр заменить на какое то ключевое слово. Например, я хочу в избранное добавить команду dig для определения NS серверов, которые отдает нам 1.1.1.1. Я не хочу видеть захаркорженные значения. И чтобы было красиво меняю их просто на ключевые слова. Это дает больше эстетического удовольствия при использовании команды - не более. Ну и в будущем я подвезу автосинк с шарингом на команду, так что может быть полезно.
Да просто надо поменять команду - почему бы не дать такую возможность =)
Пример редактирования
Кстати, тут вопрошали сколько 🌟 наберет тулза в github - пока всего 37. Ну а что это за инструмент и чем он может быть полезен можно подробнее прочитать в предыдущем посте.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".
Пример использования cli-stash
Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.
Что умеет:
Сохраняет ваши команды в избранном
Возможность добавить из истории шелла
Нечеткий поиск
Сортировка по частоте использования
И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.
# Установка в Linux
go install github.com/itcaat/cli-stash@latest
# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/
В macOS поставить изян brew install itcaat/tap/cli-stash
Исходники и инструкция по использованию есть на github.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Сегодня хочу поднять тему, которую редко обсуждают отдельно, но без неё Docker просто не работал бы так стабильно и предсказуемо - манифесты образов.
Периодически в разные частях документации или статьях про Docker вы будете встречать "манифесты". Обычно это звучит как что-то второстепенное: мол, есть какая-то мета-информация, по которой Docker собирает образ из слоёв.
Но на деле это одна из ключевых деталей, которая отвечает за то, что контейнеры:
воспроизводимы
одинаковые на разных машинах
и не превращаются в "ну у меня работало".
Я попытаюсь все описать максимально просто.
Docker Manifest - это JSON-документ, который описывает образ. Можно представить его как схему или инструкцию, по которой Docker понимает:
какие слои относятся к образу
какие контрольные суммы должны быть у каждого слоя
в каком порядке их нужно использовать
для какой ОС и архитектуры этот образ подходит
И важный момент: когда ты делаешь docker pull, Docker сначала получает манифест, а уже потом начинает скачивать слои.
Как посмотреть манифест самому: docker manifest inspect nginx:latest.
Тут можно заметить, что один тег (nginx:latest) может ссылаться сразу на несколько вариантов образа - например под amd64 и arm64. Это как раз история про multi-arch. Иногда под словом manifest имеют в виду не сам образ, а manifest list (index). Это как меню: Docker смотрит на твою платформу и выбирает подходящий вариант (amd64/arm64).
Каждый слой Docker-образа имеет SHA256-хеш, который вычисляется из его содержимого.
Логика максимально простая:
поменялся файл
поменялось содержимое
поменялся хеш
значит получился другой слой
По сути это очень похоже на философию Git: всё завязано на содержимое, а не на "имя файла".
Docker Registry использует Content Addressable Storage - то есть хранит и раздаёт данные не по названию, а по их хешам.
Что происходит при push / pull?
Если упростить до понятной схемы, то процесс примерно такой:
клиент сначала отправляет/получает манифест
registry проверяет хеши и наличие слоёв
передаются только те слои, которых ещё нет
каждый слой проверяется по SHA256
То есть никакой лишней передачи данных и никаких "примерно совпало".
Комбинация манифестов и хешей даёт сразу несколько сильных преимуществ:
Безопасность - слой нельзя незаметно подменить
Экономия места - одинаковые слои не хранятся по сто раз
Целостность - скачанное гарантированно равно загруженному
Версионирование - образ это конкретная комбинация слоёв, а не “что-то похожее”
Именно поэтому условный nginx:latest на dev и на prod - это реально один и тот же образ, а не "почти такой же, но чуть другой". Ладно, давайте будем более дотошными. На самом деле нет - использовать latest плохая практика. За время пока образ приехал,- там уже могут быть разные образы.
Как минимум используйте конкретный тег, а еще лучше даже sha256 docker pull nginx@sha256:...
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Сегодня будет для самых маленьких про вещь, которая пугает не только новичков, а вообще всех, кто хоть раз попадал в настоящий “железный” контур без интернета.
Речь про vi...😱
Как выйти из vi? Никак. Это не редактор, это пожизненный контракт.
Я открыл vi один раз в 2009 году. С тех пор у меня один и тот же терминал, потому что я всё ещё пытаюсь выйти.
Если ты случайно запустил vi на проде — проще выкинуть сервер, чем найти правильную комбинацию клавиш.
Это тот самый редактор, который в обычной жизни можно спокойно не трогать годами… А потом ты оказываешься в air-gap, где:
нет vscode
нет nano
нет mc
иногда даже less нет и кажется, что у тебя есть только vi и судьба
И вот ты открываешь конфиг… и мозг такой: эээээ мы не умеем, всё, до свидания.
Давай разберёмся, как перестать бояться vi и научиться выживать с ним спокойно.
Почему vi вызывает ступор? Потому что он не работает как обычные редакторы. Ты нажимаешь клавиши - а текст не печатается. Пытаешься выйти - не выходит. И где-то рядом уже открывается вкладка “как выйти из vi”, но интернет… в другой реальности.
Главное, что нужно понять - в vi есть несколько режимов:
Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.
Insert mode - это режим, где можно реально редактировать и вводить текст.
Command mode (через :) - cохранение, выход, всякие служебные команды и тд
Минимальный набор клавиш, чтобы выжить:
Войти в редактирование -> i, a, o
Вернуться обратно в команды -> Esc
Сохранить файл -> :w
Выйти -> :q
Сохранить и выйти -> :wq
Выйти без сохранения -> :q!
Полезные команды, которые реально пригодятся:
удалить строку -> dd
вставить строку ниже -> o
отменить действие -> u
повторить последнее действие -> .
поиск: / и дальше текст который ищем
Пример: быстро поправить конфиг и уйти живым
vi /etc/hostname
Дальше всё по шагам:
нажми i и внеси правки
нажми Esc
введи :wq
готово - конфиг сохранён, ты победил
А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Иногда самые полезные вещи - это вовсе не большие системы и не новые фреймворки, а маленькие утилиты, которые внезапно делают жизнь проще. На днях вспомнил про одну такую находку и решил поделиться.
Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.
Она вставляет визуальные разделители прямо в поток вывода и отлично работает в реальном времени. Без магии, без лишних настроек - просто аккуратно отделяет "было" от "стало".
В итоге это неожиданно удобно:
при отладке,
при сопровождении сервисов,
при поиске изменений в логах после конкретных действий.
Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Чем дольше я работаю с инфраструктурой, тем чаще ловлю себя на мысли: главный навык здесь - не конкретный инструмент и даже не стек, а способность заставить что-то работать в самых странных условиях.
Ответ неожиданно нашёлся в одном месте - canitrundoom.org. Это не сайт и не галерея, а настоящий музей инженерного безумия, где люди снова и снова доказывают, что если есть процессор и немного упрямства, то DOOM запустится.
В коллекции устройства, которые точно не проходили ревью на "игровую платформу": - офисная техника, - измерительное оборудование, - городские экраны, - железо, побывавшее в космосе
Смотришь на всё это и вдруг понимаешь: пределы возможностей куда дальше, чем кажется. Если DOOM смог заработать там, где для этого не было ни интерфейсов, ни смысла - то уж доставить очередной говнокод в прод - вообще же плевое дело.
Очень рекомендую заглянуть и дать мозгу немного свободы.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.
В отчете вы получите:
Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP
Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров
Дисковое пространство - занятое место, inodes, SMART статус
Тест скорости дисков - скорость записи/чтения (100MB тест)
Сетевые интерфейсы - статус, ошибки, активные соединения
Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета
Пример запуска (можно без sudo - но там не будет всех показателей):
curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
sudo ./linux-diag-script.sh
# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash
Бонусом в скрипте встроена возможность получать Telegram уведомления и сам отчет при обнаружении проблем. Для этого надо создать бота и добавить в выполнение скрипта в cron.
Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.
# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1
Актуальная версия скрипты доступна на GitHub Gist. Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.
Пишите что еще можно добавить - я добавлю.
---
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Если тебе надо быстро потыкать что-то из Linux / контейнеров / сетей / namespaces / cgroups, но при этом не хочется поднимать VM, ставить Docker, ковырять окружение, то iximiuz labs playgrounds - это прям топ штука.
Это набор готовых интерактивных лаб, где ты заходишь в браузере и просто:
запускаешь контейнеры
смотришь namespace’ы
играешься с сетью
Причём самое классное, что там не “прочитай статью”, а прям сценарий + терминал + что делать. То есть зашёл → запустил → увидел результат → понял, как оно работает.
---
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Сегодня хочу показать вам инструменты, которые входят в мой личный топ полезных утилит для работы с множеством серверов. Их главная суперсила - параллельное выполнение задач.
Давайте я просто покажу примеры использования с кратким описанием и все сами поймете.
pdsh - инструмент, который позволяет выполнять команды на множестве хостов параллельно.
# Проверим uptime на хостах начиная с 1 по 5, исключив 3
$ pdsh -w node[1-5] -x node3 uptime
# Перезагрузим все хосты, кроме node3 и node7
$ pdsh -w node[1-10] -x node3,node7 'sudo reboot'
Если вы достаточно организованы, чтобы вести список хостов - можно даже использовать файл с заранее определенными хостами
Так тебе же ничего не мешает использовать для этих целей Ansible! Например, так:
ansible -i 'node1,node2,node3' all -m shell -a 'uptime'
И будете совершенно правы - ничего не мешает, но это же круто знать о существовании альтернативных инструментов инструментов, тем более ansible может и не оказаться под рукой.
# Залить скрипт мониторинга на все хосты
pscp -h all_hosts.txt monitor_script.sh /usr/local/bin/
prsync - параллельное копирование через rsync
# Обновить статические файлы только если они изменились
prsync -h cdn_nodes.txt -a "-avz" static/ /var/www/static/
pslurp - собрать файлы с серверов на локальную тачку
# Собрать логи со всех серверов в отдельные папки
pslurp -h servers.txt -l user -L ./collected_logs /var/log/app/error.log app_error.log
Эти инструменты не заменят полноценные системы управления конфигурациями вроде Ansible или chef, но для быстрых задач, срочных исправлений или массового сбора информации - они незаменимы.
---
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
