Утилита ncdu: эффективный инструмент для борьбы с переполнением дискового пространства

Перво-наперво что мы делаем при инцидентах с серверами, это проверяем свободное место на диске. Зачастую проблема именно в этом, к примеру диск переполнился жирным лог файлом или наплодилось куча мусора в /tmp папке, а может быть система резервного копирования вышла из-под контроля.

Для того чтобы не заморачиваться с командами du и find, есть прекрасная утилита, которая называется ncdu.

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

# cd /
# ncdu

После запуска строится удобное дерево в процентном соотношении занятого дискового пространства, удобная навигация, ну а самое главное есть возможность прямо из нее удалять жирные файлы (нажать на файле или каталоге букву d).

Утилита мастхев, которая ежедневно экономит нам кучу времени и нервов. Рекомендуем.

установка элементарная

ubuntu: apt install ncdu
osx: brew install ncdu
centos: yum install ncdu

tags: #utils
—
🟢 Подпишись: @bashdays

mytop — это отличная обертка для мониторинга mysql, я применяю её довольно часто, чтобы в реальном времени отследить какие запросы нагружают базу и откуда растут ноги.

Конечно можно законектится в сам mysql и выполнить SHOW FULL PROCESSLIST, но mytop делает это автоматически, регулярно запрашивая PROCESSLIST и STATUS.

По умолчанию информация о длинных запросах для удобства обрезается. Чтобы посмотреть полный запрос к базе, необходимо нажать букву f и ввести ID потока (треда).

Утилиту нужно сконфигурировать через конфиг файл /root/.mytop. Минимальный конфиг .mytop выглядит так:

user=db_user
pass=superpassword
delay=5
db=db_base

Через конфиг .mytop так же возможно сконфигурировать работу утилиты с удалёнными серверами, достаточно указать ip адрес сервера и порт на котором у вас крутится mysql. Но я обычно ставлю ее на тот же сервер где у нас крутится база.

Устанавливается обычным apt install mytop, а для других дистрибутивов и операционных систем с помощью brew/yum/pacman

mytop достаточно хороший инструмент для отладки, берите на вооружение

tags: #utils
—
🟢 Подпишись: @bashdays

pstree — незаменимый инструмент в работе, утилита визуально выводит компактное дерево всех запущенных процессов. Можно сказать что это аналог команды ps, но на стероидах и самое главное для людей.

Утилита имеет множество ключей для запуска, но я использую ее в стандартном режиме. Этого вполне достаточно, чтобы за несколько секунд понять что у меня запущено, а что нет.

pstree стакает идентичные ветви, помещая их в квадратные скобки и добавляет к ним целое число, это число является количеством ветвей процесса.

Редко, но иногда требуется отключить объединение ветвей, для этого можно использовать ключ -c

pstree -c

Ну и конечно же с помощью ключа -p, можно вывести список PID’ов и PGI’ов и потом их жёстко закилить.

pstree -p

Есть еще крутая фишка, это ключ -a, с помощью него можно получить параметры конфигурации запущенных приложений. То есть допустим запущен у меня какой-то prometheus экспортер и мне надо знать с какими параметрами он запущен, выполняем:

pstree -a

и получаем:

nginx_exporter -nginx.scrape-uri http://localhost/nginx_status

Сказка, а не утилита! Лично для меня проще запустить pstree и не приседать вокруг ps со всеми его ключами и наворотами, грепая и страдая. Глянул на дерево визуально и понял, что php, nginx, mysql запущены, значит проблему надо искать в другом месте.

pstree входит в пакет psmisc, установка стандартная apt install psmisc, для остальных дистрибутивов аналогично yum/pacman/другое, но в osx без проблем поставилась через brew install pstree, короче тут индивидуальный подход.

если вкатит, можешь запустить pstree --help и глянуть на что она еще способна, там и подсветка и танцы под гитару и жаркие африканские женщины 💃

tags: #utils
—
🟢 Подпишись: @bashdays

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

Установка стандартная: apt/yum/brew install nethogs но если ты упоротый админ, можешь из исходников собрать и ядро пропатчить 🔨

Я использую nethogs довольно редко, но метко. В последний раз была ситуация, когда ко мне пришел Selectel и попросил разобраться почему мы начали превышать полосу пропускания и наш канал несколько дней забит на 200%.

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

Так же у nethogs есть различные ключи для запуска, но я ими никогда не пользуюсь, всё и так понятно без всяких надстроек и тюнинга.

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

Что можно выделить по параметрам запуска

1. Выставляем время обновления в секундах (по умолчанию 1 секунда)

nethogs –d 5

2. Посмотреть сколько процесс передает в мегабайтах, а не его скорость (0 = KB/s, 1 = total KB, 2 = total B, 3 = total MB)

nethogs –v 3

но можно этого добиться и без параметров, после запуска nethogs, нужно нажать букву m и отображение поменяется, удобно

3. Так же возможно мониторить отдельные интерфейсы

nethogs eth0
nethogs wlan0

4. Ну и как вишенка, в nethogs есть режим трассировки, запускается с ключом -t

nethogs -t

Кстати если перевести nethogs на русский язык, то дословно получается что программа называется: «сетевая свинья» ну или «сетевой боров/кабан». Название безусловно интересное, я не знаю что ты будешь делать с этой информацией, просто живи с ней ))

tags: #utils
—
🟢 Подпишись: @bashdays

Мало кто знает об этой фишке в journalctl, ща расскажу…

Короче допустим у тебя есть какой-то микросервис или скрипт, который пишет в системный журнал какие-то события или ошибки. К примеру у меня есть bash скрипт, который запускается по крону каждую минуту:

if [[ "$THREADS" -ge "500" ]]; then
   logger "MYSQL THREADS OVERLOAD:" $THREADS
fi

Суть скрипта заключается в том, чтобы мониторить число тредов в mysql, если тредов больше 500, то в системный журнал пишется фраза «MYSQL THREADS OVERLOAD»

Далее у меня есть еще один bash скрипт, так же запускается раз в минуту:

TH=$(journalctl -S -180s | grep -c 'MYSQL THREADS OVERLOAD’)

if [[ "$TH" -ge "3" ]]; then
 systemctl reboot mysql
fi

Этот скрипт читает системный журнал и проверяет, если за три минуты в журнале проскочила трижды (либо больше) фраза «MYSQL THREADS OVERLOAD», то запускается полезная нагрузка, в данном примере у меня ребутится mysql.

Этот способ можно адаптировать под любые задачи и сделать быстрый мониторинг с оповещением в слак/телеграм.

Костыльно? ОЧЕНЬ! Я даже не представляю сколько сейчас людей перевернулось в гробу. 🤣

Но когда под рукой нет поднятой связки prometheus + grafana + alertmanager, а заказчик требует сделать быстро и срочно, пойдёт и такое решение. Главное чтобы все были довольны.

Кстати я как-то встречал у клиента подобный самописный мониторинг, он нарочно отказался от всех этих модных штук в пользу — чем проще система, тем меньше отказов. Доля правды в этом есть, ну как говорится — каждому свой костыль и велосипед.

tags: #bash
—
🟢 Подпишись: @bashdays

Будем расширять границы контента. Ща покажу магию, знать это мастхэв. Мотай на ус, если не индус знал, пригодится.

У нас в компании достаточно банальная инфраструктура, в которую входит балансировщик и несколько нод на которых крутится nodejs приложение с 3000м портом, короче говоря апиха.

bashdays-b1:443
  -> bashdays-w1:3000
  -> bashdays-w2:3000
  -> bashdays-w3:3000
  -> bashdays-w4:3000

К примеру от клиентов идут POST запросы к апихе, запросы попадают на сервер b1, затем nginx распределяет запросы по нодам w1-w4 и отдает в ответ json. Примитивная балансировка нагрузки, но достаточно стабильная.

В какой-то момент мне необходимо добавить еще одну ноду с новой версией nodejs приложения.

Назовем её bashdays-w5. Эта нода не должна обслуживать клиентов, но должна отдавать данные тестировщикам, чтобы те могли потыкать и протестировать в условиях продакшена. Ну а ты как думал? Тестируем на проде, можем себе позволить ))) 🎉

Городим в nginx на b1 такой велосипед:

map $http_x_backend $backend {
    bashdays-w5 192.168.0.5:3000; # w5
    default backend;
}

upstream backend {
  server 192.168.0.1:3000; # w1
  server 192.168.0.2:3000; # w2
  server 192.168.0.3:3000; # w3
  server 192.168.0.4:3000; # w4
}

location / {
  add_header X-Upstream $upstream_addr;
  proxy_pass http://$backend;
}

Объясняю что происходит, клиенты идут на b1 и попадают по умолчанию в upstream backend, где прописаны ноды w1-w4.

Тестировщики подставляют заголовок X-Backend: bashdays-w5 в своих запросах и попадают на w5. То есть для обычных пользователей ничего не изменилось, но QA теперь с помощью заголовка X-Backend: bashdays-w5 могут попасть на новую ноду и затыкать ее хоть до усрачки.

В location есть директива add_header X-Upstream, она выведет в ответе nginx на какую ноду ты попал, удобно для дебага.

В раздел map можно добавить еще кучу нод, которые не будут участвовать в обслуживании клиентов, но ты в любой момент сможешь на них попасть с помощью заголовка.

Если у тебя не апиха, а веб приложение, можешь воспользоваться плагином ModHeader, есть для фокса и хрома. В нём можно легко подставить все необходимые заголовки и попасть в жопу пальцем туда куда тебе нужно, или не нужно.

Конфигурация nginx это как стихи писать, есть какие-то базовые слова и правила, но в большинстве случаев 90% функционала вообще не используется. Потому что, документацию никто не читает и люди делают так, как научились или подсмотрели на stackoverflow. Вот такие пироги.

tags: #nginx
—
🟢 Подпишись: @bashdays

Сегодня я снова научу тебя плохому хорошему. Про prometheus я думаю все знают. Но не все знают, что на bash можно за несколько минут написать собственный экспортер метрик. Дада, ты не ослышался — не обязательно быть golang сеньором, чтобы делать крутые и полезные штуки. Погнали чо!

У prometheus есть основной экспортер node_exporter, который собирает 100500 метрик с хоста. Ставится отдельно и элементарно. Гугол тебе подскажет. У меня он установлен везде где хоть что-то напоминает linux. Короче бест-практик.

Эт я к чему. У node_exporter есть прекрасный ключик --collector.textfile.directory. Из коробки он не прописан в systemd, поэтому нужно самостоятельно прописать руками в файле /etc/systemd/system/node_exporter.service (у тебя может называться по другому).

ExecStart=/usr/local/bin/node_exporter --collector.textfile.directory /tmp/textfile_collector

Суть такая, указываем ему директорию, которая будет регулярно опрашиваться на наличие .prom файлов. Соответственно эти .prom файлы мы будем генерировать с помощью bash скрипта, который засунем в крон. Файл представляет собой текстовый документ в определенном формате.

А далее все нужные нам метрики попадут автоматом в prometheus, а там глядишь и в grafana красиво всё станет.

Лепота! 🫥

Покажу на примере моего скрипта, который забирает количество оставшихся писем в квоте по API с почтового сервиса smtp и передает напрямую в prometheus.

#!/bin/bash

MAINDIR=/tmp/text_collector
METRICS=smtp.prom

rm $MAINDIR/$METRICS

count=$(curl -s -X GET "https://api.smtp/v1/user" -H "accept: application/json" -H "Authorization: superapipassword» | jq '.quota')

echo "smtp_quota{service=\"smtp_exporter\"} "$count >> $MAINDIR/$METRICS

Кидаем его в крон */1 * * * * и на выходе получаем в папке /tmp/text_collector файл smtp.prom в котором будет нечто подобное:

smtp_quota{service="smtp_exporter"} 26818

И это всё! Готовый экспортер на коленке за несколько минут! Все данные по квоте теперь лежат в параметре smtp_quota. А дальше выводим графики, ставим алерты, балдеем.

С помощью curl и jq можно парсить вообще всё что угодно и запихивать в prometheus, пусть страдает, он для этого и был создан! Ну а больше инфы по ключикам node_exporter можешь получить тут, может чего еще интересного откопаешь и с нами поделишься.

tags: #bash #monitoring
—
🟢 Подпишись: @bashdays

Сегодня мы будем делать с вами свой nginx plus (тот который платный), а именно реализуем плюшку «Active health checks».

Это когда у тебя к примеру 10 апстримов и если один из них дохнет, то какой-нибудь богатый клиент получит 502 ошибку, обозлится и ничего не купит. А должен автоматически попасть на другой, более живой апстрим и потратить денежку.

Само собой будем применять инновационные технологии и немного возьмем из фреймворка «гавно и палки». Ну а как ты хотел? Бест практик! На халяву и уксус сладкий, как говорится. Короче все элементарно. Погнали.

Ставим ванильный nginx и делаем так:

upstream backend {
    server unix:/var/run/haproxy/backend.sock;
}

location / {
  proxy_pass http://backend;
}

Ставим рядом haproxy, и конфигурируем блоки frontend и backend таким образом:

defaults
  retries 3
  timeout check 5s
  
frontend bashdays-backend
  bind /var/run/haproxy/backend.sock user nginx mode 600
  mode tcp
  default_backend bashdays-backend
  option tcplog

backend bashdays-backend
  balance roundrobin
  option tcplog
  server bashdays-w1 192.168.0.1:80 check
  server bashdays-w2 192.168.0.2:80 check
  server bashdays-w3 192.168.0.3:80 check
  server bashdays-w4 192.168.0.4:80 check

Что это за хрень, щас объясню. Смотри. Клиент идет на хуй корень / и попадает в nginx апстрим backend, а апстрим сконфигурирован на сокет backend.sock от haproxy.

Далее запрос клиента пролетает по сокету, как фанера над загнивающим парижем и попадает в блок haproxy «backend» где у меня описаны все бэкенд-сервера (w1, w2, w3, w4).

Если по какой-то причине к примеру сервер w2 отдаст концы, haproxy это задетектит (timeout check 5s) и закинет запрос клиента на рабочий инстанс, тем самым клиент получит статус 200. А 200 == заебись хорошо! 🗒

Ну а потом когда w2 очухается, то haproxy снова заберет его в свои сети и будет использовать на всю катушку, как провинившуюся падшую женщину.

Вот так это и работает. Вот так вот и живем. Балансировка нагрузки + roundrobin + active health checks

У haproxy еще есть встроенный визуальный мониторинг, но об этом я расскажу тебе в одной из следующих статей.

tags: #nginx
—
🟢 Подпишись: @bashdays

С пятницей коллеги! Сегодня на повестке у нас еще одна полезная тулза.

PV «pipe viewer», держу пари многие даже и не подозревали что такое существует.

Что же она делает? Давай на пальцах, когда ты запускаешь из консоли дампиться базу или выполняешь копирование какого нибудь большого файла, ничего не остается кроме как красноглазить и ждать конца операции. На экране нет никакой полезной информации.

Ну дак вот, встроив в свой pipe эту утилиту у тебя появится информативный progress bar который в реальном времени будет показывать cкорость обработки данных.

[===>xxxxxxxx] 20%

Пошли тыкать:

pv /var/log/php/php-fpm.log | gzip > php-fpm.gz

33MiB 0:00:03 [ 114MiB/s] [==========> ] 32% ETA 0:00:06

Наглядно видно, что через пайп за 3 секунды прошло 33Мб — это 32% от всего объема, операция займет еще 6 секунд. Заебись! Хорошо! 😏

PV это вовсе не cat, её возможности намного шире, тут уже зависит на сколько ты будешь оригинален в своих скриптах и велосипедах.

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

Из клёвых ключей, есть:

-l строчный режим, pv может ограничивать скорость и просто в байтах
-L 100 – необходимое ограничение

Допустим у тебя есть база данных, которая не толерантна к большому объёму INSERT-ов и UPDATE-ов. Но у тебя также есть большой дамп с кучей таких операций.

Как безопасно импортировать дамп в базу и не убить её нахуй? А вот так:

# скорость ограничена 100 тысячами строк в секунду
pv -L 100k -l dump.sql | mysql -u root -p

# скорость ограничена 100 строками в секунду
pv -L 100 -l dump.sql | mysql -u root -p

Ну и на закусочку, баянище:

pv /dev/urandom > /dev/null
23MB 0:00:05 [ 12,9MB/s] [...<=>..........]

Не болей и береги себя. Всем хороших предстоящих выходных. Тут еще столько всего неизвестного и полезного ожидает тебя, мама не горюй )))

Увидимся в понедельник! 💛

tags: #utils
—
🟢 Подпишись: @bashdays

Ну что ж, надеюсь ты успел отдохнуть и готов к новым приключениям. Сегодня мы с тобой реализуем собственный конфиг-агент. Естественно применим самые наилучшие практики, естественно на bash. Поехали.

Что такое конфиг-агент? Это такой механизм, который держит конфиги на сервере в актуальном состоянии. К примеру какой-нибудь мудень плохой человек с бодуна накосорезил и грохнул важный nginx файл с апстримами, а вернуть как было не может, нет знаний, нет головы, нет бекапов, нет будущего.

Ты спросишь? А какого хуя? Как так получилось? А вот так, порой у тестировщиков есть root на тестовые машины, чтобы они не дергали девопсов, а могли сами зайти на свой сервер и подебажить проект. Но дебаг может затронуть nginx, php и т.п. конфиги. Лезут же куда не попадя, все хотят быть крутыми девопс инженерами.

В этом случае нас спасет конфиг-агент, который автоматически придет через минуту, заберет эталонные конфиги из git, всё красиво восстановит и передернет на Билли Айлиш.

Ясно дело можно через ansible и puppet все это провернуть, но слишком избыточно, это то же самое, что поднять kubernetes и крутить в нем личный бложек на wordpress, ну такое…

Не унывай, выход есть! Это можно реализовать за несколько минут и потом снова пару недель пинать хуи воздух. Главное на планировании спринта сказать — я оцениваю эту задачу в 14 дней. 😘

Как я раньше и сказал, есть некий git репозиторий где хранятся все эталонные конфиги. Все изменения в конфигах производятся через этот репозиторий.

На примере покажу как мониторить nginx конфиги и сделать простенький агент. Дальше уж сам свой велосипед под свои реалии запилишь.

Практика (упрощаю до минимума, чтобы ты понял смысл)

Закидываем файл /usr/local/sbin/config-agent.sh делаем ему chmod +x (чтобы он был исполняемым) и ставим его в крон */1 * * * *

#!/bin/bash

DIR=/tmp/nginx-configs

if [ ! -d "$DIR" ];
then
git clone git@git.bashdays.ru:dev/nginx-configs.git /tmp/nginx-configs
fi

cd /tmp/nginx-configs && git pull --quiet
RSYNC=$(rsync -aizh /tmp/nginx-configs/ /etc/nginx)

if [ $? -eq 0 ]; then
if [ -n "${RSYNC}" ]; then
systemctl reload nginx
fi
else
exit 0
fi

Давай смотреть что тут происходит:

1. Создаем отдельную папку если ее нет в /tmp
2. Клонируем в нее эталонные конфиги с git репозитория
3. Переходим в папку и забираем последние изменения
4. С помощью rsync, синкаем эталон в папку /etc/nginx
5. Если файлы заменились в /etc/nginx то делаем reload

Всё!

Знак $? используется для поиска возвращаемого значения последней выполненной команды.

Теперь у нас есть полный контроль от кривых рук. Ну а чтобы изменить какой-то конфиг, нужно заморочиться и сделать это через git репу со всеми вытекающими кодревью и т.п.

Как говорится - на bash’ке моей горшок, а в кармане пирожок!

Всем хорошего понедельника коллеги!

tags: #bash
—
🟢 Подпишись: @bashdays

Солнце палит, а мы пашем, вот такая доля наша.

Хелло май диа френдз. Сегодня попиздим поговорим про логирование и cron.

Но поговорим не про системное логирование процесса crond, а про более развернутое. Развернем наизнанку, кровь кишки, как ты любишь...

К примеру у тебя есть консольное приложение, после запуска которого, на экран выводится какой-либо результат.

Всё хорошо когда запустил ручками и посмотрел. Словил ВАУ эффект! Но если повесить эту задачу на cron, то в системном журнале ты увидишь лишь дату и время запуска.

Jul 11 00:00:01 bashdays CRON[123456]: (user) CMD (/var/www/htdocs/bin/console export:users)

Пожалуй очень информативно, правда? Ну запустился, а что произошло внутри, хуй пёс его знает.

Щас исправим и получим красивое. Достаточно в конец команды добавить:

>> /var/log/cronlogs/www-console.log

тип того:

* */1 * * * php /var/www/htdocs/bin/console export:users >> /var/log/cronlogs/www-console.log

Теперь весь выхлоп с команды console export:users будет аккуратненько логироваться в файл www-console.log. По итогу в файле получаем красоту:

Папку только не забудь создать в /var/log, а то оно дурное и не додумается само.

[2023-07-11 10:04:20] service.stats.INFO: Processing users
[2023-07-11 10:04:20] service.stats.INFO: Updating local stats
[2023-07-11 10:04:20] service.stats.INFO: Updating count users
[2023-07-11 10:04:26] service.stats.INFO: Updating total stats
[2023-07-11 10:04:26] service.stats.INFO: Export Success

По желанию грепаем нужное нам, ну и всегда остаемся в курсе событий, зная что же происходит под капотом. Кстати отлично помогает при дебаге. То что кроновская задача выполнилась, еще ни о чем не говорит, внутри может быть злобный эксепшен 😡

Да и не забываем накинуть logrotate, чтобы место на диске не сжирало бигдатой, а лучше сразу перенаправляй это дело в какой-нибудь агрегатор логов типа ELK или LOKI.

Бонусом лови конфиг для logrotate, чтоб в гугле не лопатить:

/var/log/cronlogs/www-console.log {
   su root root
   daily
   missingok
   rotate 14
   compress
   notifempty
   sharedscripts
}

Есть ли другие способы мониторинга для подобных ситуаций? Конечно есть! Но способ который я описал выше, используется практически всеми. По крайней мере я на него натыкаюсь постоянно у ребят в различных компаниях.

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

О других способах я обязательно напишу отдельный пост, пусть это будет интригой, ну а может ты сам загуглишь и нам потом расскажешь.

В общем адью, албибэк, увидимся! 😎

tags: #linux
—
🟢 Подпишись: @bashdays

А давай заколхозим настоящую базу данных на bash!

Дада, ты не ослышался, начиная с bash 4.0 можно и такое провернуть. Дай нам палку и гвоздь, а мы сделаем из этого кофеварку, мыж с тобой настоящие инженеры-программисты, фак ее!

Летсгоу! Есть у меня огромный txt файл со словами, отсортированный по алфавиту. Нет, не словарь для брутфорса 🍸

Если на него натравить sed, то скорость извлечения нужного слова из файла — ну совсем никакая, сидишь как баран ждешь, пока этот сыщик Коломбо, что-то откроет-отроет. Но в век высокий технологий, скорость как-никак в приоритете.

SED – это потоковый редактор текста (от stream editor), c помощью которого можно выполнять с файлами множество операций вроде поиска и замены, вставки или удаления. При этом чаще всего он используется именно для поиска и замены.

Давай разгонять этого ленивца «Блиц, скорость без границ»

Каков план:

1. Отсортировать содержимое txt файла по алфавиту
2. Проиндексировать данные

Так как файл у меня содержит слова (не цифры и т.п.), то индексами я сделаю диапазоны строк начинающихся на определенную букву.

sort -o data.txt data.txt

Эта команда отсортирует содержимое файла data.txt по алфавиту и перезапишет его в нужном мне формате.

Пишем код

Проверяем первый аргумент переданный в скрипт. Если передать что-то кроме букв, то экзитим:

[[ $1 =~ ^[a-z]+$ ]] || exit

Берем первую букву из первого аргумента и присваиваем её переменной.

INDEX=${1:0:1}

Инициализируем переменную SEARCH значением первого аргумента, чтобы нам было удобнее в будущем. Это будет искомым словом по нашей базе.

SEARCH=$1

Далее объявляем переменную DATA. В которой будет указываться путь до нашего файла. Который мы заранее отсортировали по алфавиту.

DATA=data.txt

Объявляем и инициализируем hash ассоциативный массив. Будет работать начиная с bash 4.0, это важно.

declare -A HASH=(['a']=1,1001 ['b']=1002,2002 ['c']=2003,3003

)

Тут я сократил, ниже скрипт полностью.

Здесь можешь ручками заполнить этот хэш, а можешь еще один скрипт написать, чтобы автоматом заполнился. Но проще ручками, чтобы не ебстись тратить время.

Что блять это за хуйня конструкция? Ну смотри, берем индекс ['a']. В файле data.txt слова начинающиеся c 'а' и идут с первой строки до 1001, далее начинаются слова на букву 'b' строки 1002-2002, ну и так далее.

Короче выявляем короткие диапазоны, по которым будем осуществлять дальнейший поиск. Зачем тебе лопатить весь файл, если можно пройтись по нужному диапазону.

Далее отдаём утилите «sed» диапазон строк и само искомое слово. В данном примере я делаю два вызова через пайп (pipe), но можно извернуться и обойтись одним.

sed -n "${HASH[$INDEX]}p" | sed -n "/^${SEARCH}$/{p;q}"

Весь скрипт будет выглядеть так:

#!/bin/sh

[[ $1 =~ ^[a-z]+$ ]] || exit

INDEX=${1:0:1}
SEARCH=$1
DATA=path

declare -A HASH=(
['a']=1,1001        ['b']=1002,2002       ['c']=2003,3003
['d']=3004,4004     ['e']=4005,5005       ['f']=5006,6006
['g']=6007,7007     ['h']=7008,8008       ['i']=8009,9009
['j']=9010,10010    ['k']=10011,11011     ['l']=11012,12012
['m']=12013,13013   ['n']=13014,14014     ['o']=14015,15015
['p']=15016,16016   ['q']=16017,17017     ['r']=17018,18018
['s']=18019,19019   ['t']=19020,20020     ['u']=20021,21021
['v']=21022,22022   ['w']=22023,23023     ['x']=23024,24024
['y']=24025,25025   ['z']=25026,26026 )

sed -n "${HASH[$INDEX]}p" "$DATA" | sed -n "/^${SEARCH}$/{p;q}"

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

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

Надеюсь коллеги вам было интересно, продолжим завтра!

Show must go on ☺️

tags: #linux #bash
—
🟢 Подпишись: @bashdays

День сегодня такой длинный, жаркий (+37)... Надеюсь у тебя дела обстоят с этим попроще.

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

Давай напишем генератор псевдослучайных чисел. Пригодится для создания всяких секретиков и айдишников в твоих bash скриптах.

Опа, опа и готово! А ты думал? 😊

echo $(tr -dc 0-9A-Za-z < /dev/urandom | head -c 16)

На выходе получаем нечто подобное из 16ти символов:

IioP0zmnPTBOuHqI
xhqohdWb0r94w7di
yMVEHwU0DCTYaGCq
KbLwMB7Iqb28Ud4T

Ты в праве поменять 0-9A-Za-z и оставить к примеру только цифры 0-9, ну и соотвественно указать длину получаемой строки -c 16.

Короче, запрашиваем у устройства /dev/urandom данные (16 случайных символов), скармливаем их tr, приводим в должный вид и получаем ожидаемый результат. Красота!

Ну и кому интересно, маленько теории по tr и urandom

Команда tr (translate) используется в Linux в основном для преобразования и удаления символов. Она часто находит применение в скриптах обработки текста. Ее можно использовать для преобразования верхнего регистра в нижний, сжатия повторяющихся символов и удаления символов.

Устройство /dev/urandom это генератор псевдослучайных чисел. Псевдослучайность urandom зависит от системы. Во многих случаях random и urandom генерируют символы по одному и тому же алгоритму.

Чтение данных устройства /dev/urandom возвратит столько байтов, сколько было запрошено.

Ну и по ключам tr которые использовались.

-c - удалить все символы, кроме тех, что в первом наборе
-d - удалить символы из первого набора

Чтобы это ни значило, это работает. Просто используй 😊!

tags: #linux #bash
—
🟢 Подпишись: @bashdays

Ну вот и пятница на носу. Хотя какая разница какой день недели, если ты работаешь 24/7. Чем займёмся сегодня? Давай чём-нибудь простым и интересным.

Порой необходимо определить количество ядер на сервере. Понятно, ты можешь вызвать top/htop и визуально глянуть цифру.

Но мыж с тобой не пальцем деланные, нам надо всё по уму, как тру программисты. Чтобы можно было это в скрипт засунуть и далее плясать от полученного результата. 💃

Для подсчета количества ядер, есть несколько способов:

1. grep -wc '^processor' /proc/cpuinfo
2. getconf _NPROCESSORS_ONLN
3. nproc --all

Это не единственные способы заполучить желаемое, но самые релевантные. Кстати getconf актуален и для макаводов (osx).

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

К примеру заскейлил ты тачку в Selectel, через их веб панельку, но nginx продолжает работать на старом конфиге. После этого очень желательно сразу переопределить в nginx.conf параметр worker_processes.

Если Nginx выполняет работу нагружающую процессор (например SSL или gzipping), то оптимально установить эту директиву в значение, равное количеству ядер процессора.

Также, директива worker_processes, умноженная на worker_connections из секции event, даст максимально возможное количество клиентов.

Конечно же справедливо всё это ансиблом (ansible) или террой (terraform) раскатать, но это дополнительный геморрой, который никому не нужен. По крайней мере, когда это нужно было еще вчера и нет возможности писать лапшу из плейбуков.

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

Прототип без ифов, так, для наглядности:

#!/bin/bash

CPU_CORES=$(grep -wc '^processor' /proc/cpuinfo)

sed -i "s/worker_processes.*/worker_processes $CPU_CORES;/" /etc/nginx/nginx.conf

systemctl reload nginx

Бери на вооружение, пригодится. 😮‍💨

Ну а я желаю тебе хороших предстоящих выходных и береги себя! Мож чо на выходные еще закину интересного почитать.

tags: #linux #nginx
—
🟢 Подпишись: @bashdays

И снова понедельник и снова на работу. Привет, коллеги. Надеюсь все живы, здоровы.

Сегодня начнем потихоньку тыкать полезную утилиту strace. Многим она кажется пиздец очень страшной, но на самом деле всё обстоит иначе. Если научишься с ней правильно работать и понимать, сможешь отдебажить любую ошибку и сразу станешь тимлидом, а может быть и техническим директором. 😈

strace — это утилита, отслеживающая системные вызовы, которые представляют собой механизм трансляции, обеспечивающий интерфейс между процессом и операционной системой/ядром

Ну а если по русски: это полезный инструмент диагностики и отладки.

Начнем с простого. Для экспериментов нам понадобится файл HUY.txt, давай создадим его командой:

echo '12345' > HUY.txt

Опыты проводим над утилитой sed. Исследовать будем команду:

sed -i.tmp 's/1/2/' HUY.txt

Ключ -i означает редактирование файла на месте, принимает необязательный суффикс tmp. Если суффикс задан, то будет создана копия файла с предыдущим содержанием.

Команда s/// это команда замены, одного на другое. То есть в примере мы меняем (1) на (2) в файле HUY.txt

Погнали изучать кишки

strace -ye '/^open',read,write,rename,close sed -i.tmp 's/1/2/' HUY.txt

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

Посмотрим вывод с момента открытия файла HUY.txt

1. openat(AT_FDCWD, "HUY.txt", O_RDONLY)   = 3</tmp/HUY.txt>
2. openat(AT_FDCWD, "./sedvKFsXv", O_RDWR|O_CREAT|O_EXCL, 0600) = 4 </tmp/sedvKFsXv>
3. read(3</tmp/HUY.txt>, "12345\n", 4096)  = 6
4. read(3</tmp/HUY.txt>, "", 4096)         = 0
5. close(3</tmp/HUY.txt>)                  = 0
6. write(4</tmp/sedvKFsXv>, "22345\n", 6)  = 6
7. close(4</tmp/sedvKFsXv>)                = 0
8. rename("HUY.txt", "HUY.txt.tmp")        = 0
9. rename("./sedvKFsXv", "HUY.txt")        = 0
10. close(1</dev/pts/0>)                   = 0

Теперь разберем построчно, что же произошло:

1. Открывается файл HUY.txt
2. Открывается временный файл sedvKFsXv
3. Из файла HUY.txt читаются 6 байт 12345\n
4. Пробует прочитать еще раз HUY.txt, вернулось 0 байт, найден конец строки
5. Закрывается файл HUY.txt
6. Записывается 6 байт 22345\n во временный файл sedvKFsXv
7. Закрывается временный файл sedvKFsXv
8. Переименовывается файл HUY.txt в HUY.txt.tmp
9. Переименовывается временный файл sedvKFsXv в HUY.txt
10. Что-то там где-то опять закрывается

Если подытожить, получилось такое:

- Считывается исходный файл HUY.txt
- Во временный файл sedvKFsXv записывается обработанный текст
- Исходный файл HUY.txt становится резервной копией HUY.txt.tmp
- Временный файл sedvKFsXv становится текущим хуем HUY.txt

Что нам дал этот эксперимент?

А дал он нам то, что всё работает. И теперь у нас есть понимание как это работает.

Допустим столкнулся ты с проблемой, что sed не смог что-то записать и ты не понимаешь почему. Запускаешь strace и смотришь почему:

write(4</tmp/sedvKFsXv>, "strace: exec: Permission denied\n", 6)  = 6

Опа, а прав на запись в папку /tmp нет, возможно какой-то лось дырявый запретил туда запись. Отдебажили, фиксим: выставляем 3 топора (chmod 777) на папку /tmp и радуемся какие мы молодцы.

Этот способ отладки ты можешь применить не только для sed, но и для своих скриптов, программ, сервисов и т.п. Как нибудь в будущем поэкспериментируем с php и Битриксом 🤡

Как-то так. Ничего же сложного? Ну вот и я про тоже. Главное не бояться и знать куда смотреть. Ну а я покажу куда смотреть и проведу тебя протоптанными дорожками.

Ладно, пойду пельмени жарить, всем хорошего понедельника! 💗

tags: #debug
—
🟢 Подпишись: @bashdays

Как говорит «Камень в лесу» — сегодня ничего не произошло.

Иногда хочется побыть таким камнем, но не сегодня. Сегодня у нас «Необычные способы узнать дату и время»

Ты скажешь есть же команда date, верно, есть и такая. Но мы же с тобой не пальцем деланные, нам надо посложнее, по геморойнее 😢

Есть несколько способов узнать из консоли текущую дату и время. К примеру ты можешь сделать это через утилиту stat.

stat -c'%z' /proc/self/stat

Временные метки [atime, mtime, ctime] будут равны времени создания [inode] для этого «файла». В данном случае это время обращения к данному файлу. Вообще proc сама по себе интересная штука. Почти для каждого файла есть свой набор функций для стандартных операций [read, write, open и т.п.].

Нихуя Ничего не понял? Забей, просто знай что команда stat выведет тебе текущую дату и время.

2023-07-18 11:42:22.592640126 +0000

А еще получить желаемое можно с помощью утилиты «ps»

ps --no-headers -o lstart -C ps

Время и дата равны времени запуска процесса ps

Tue Jul 18 11:44:07 2023

Следом идет команда «printf»

printf '%(%c)T\n'

Это встроенная команда в оболочку Bash. Выводится дата и время в соответствии с установленной локалью.

Tue Jul 18 11:44:53 2023

А еще можно так:

( T='\t' ; echo ${T@P} )          
( T='\T' ; echo ${T@P} )
( T='\@' ; echo ${T@P} )
( T='\A' ; echo ${T@P} )
( T='\D{%X%t%x}'; echo ${T@P} )

${parameter@P} начиная с версии bash 4.4

16:16:22
04:16:26
04:16 PM
16:16
16:16:39 07/18/23

Ну и фаталити на закусочку, выведем unixtime тремя разными способами. Эквивалентно команде: date '+%s'



printf '%s\n' "$EPOCHREALTIME" 
printf '%s\n' "$EPOCHSECONDS"
printf '%(%s)T\n'

1689686418.954954
1689686418
1689686418

Вообще редко такое может пригодиться, но пару раз на собесах какие-то упоротые техдиры задавали подобный вопрос. Не знаю откуда они такое берут, но факт остается фактом.

Разнообразь свои скрипты такими замысловатыми конструкциями и ни один девопс (кроме тебя естественно) нихрена не поймёт. Создашь басфактор и будешь самым незаменимым в коллективе 😠 пам пам пам

Всем добра котики!

tags: #bash #linux
—
🟢 Подпишись: @bashdays

Есть такая поговорка «Взял bosch и ебошь», но у нас, у айтишников эта поговорка звучит немного иначе «Взял bash и ебашь». Из песни слов не выбросишь 🍴

Команда history, это не просто вывод истории команд, которые ты или кто-то набирал в консоли. Это великолепный инструмент, с помощью которого можно воссоздать к примеру всю картину настройки сервера. Либо отдебажить момент когда всё работало, а сегодня перестало, по причине какого нибудь отбитого админа, который решил тонко оптимизировать linux ядро.

В общем — history, это как спасательный круг. Давай сегодня затюним её на удобство.

Чего же не хватает из коробки? А не хватает временны́х маркеров, то есть даты и времени, когда была выполнена та или иная команда. Это легко решаемо. Для оболочки bash это делается так:

export HISTTIMEFORMAT="%d/%m/%y %T "

И вывод будет примерно таким:

  369  20/07/23 15:46:54 flask run
  370  20/07/23 15:46:54 /usr/bin/python3
  371  20/07/23 15:46:54 python --version
  372  20/07/23 15:46:54 python3 --version
  373  20/07/23 15:46:54 ps ax|grep python
  374  20/07/23 15:46:54 sudo kill -9 30049
  375  20/07/23 15:46:54 brew install pyenv

Либо можешь прописать это в ~/.bashrc чтобы export выполнялся автоматически:

echo "export HISTTIMEFORMAT=\"%d/%m/%y %T \"" >> ~/.bashrc

Прекрасно, теперь намного нагляднее. Идем дальше. Давай перекрасим временные маркеры в синий цвет, чтобы более лаконично выглядело.

export MY_BASH_BLUE="\033[0;34m"
export MY_BASH_NOCOLOR="\033[0m"
export HISTTIMEFORMAT=`echo -e ${MY_BASH_BLUE}[%F %T $MY_BASH_NOCOLOR `

Эти экспорты можешь так же закинуть в ~/.bashrc и затем выполнить команду source ~/.bashrc чтобы не перезагружать сессию и применить настройки в моменте.

Окей, но как же быть с оболочкой zsh? Сейчас и в ней сделаем нечто подобное.

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

history -E

вывод будет таким:

 9481  9.5.2023 16:04  export FLASK_RUN_PORT=8888
 9482  9.5.2023 16:04  export FLASK_APP=index.py
 9483  9.5.2023 16:04  flask run
 9484  9.5.2023 16:08  export TGS_API_KEY=12345
 9485  9.5.2023 16:08  flask run

Уже более менее информативно, а если так:

history -i

опа-опа-опапа:

 9481  2023-05-09 16:04  export FLASK_RUN_PORT=8888
 9482  2023-05-09 16:04  export FLASK_APP=index.py
 9483  2023-05-09 16:04  flask run
 9484  2023-05-09 16:08  export TGS_API_KEY=12345
 9485  2023-05-09 16:08  flask run

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

man zshoptions
man zshbuiltins

Ну а чтобы каждый раз не вводить ключи, сделай нужный тебе alias в ~/.zshrc



alias history="history -i"

А еще есть такая утилита как «fc», я думаю большинство про нее вообще ничего не слышали.

fc — unix-утилита, служащая для редактирования списка ранее введенных команд, а также их выполнения.

Вот тебе команда на основе fc, которая выведет историю, сразу же с временными маркерами:

fc -li 100

Больше уж и сказать нечего, основное разобрали, внедряй. Еще есть и другие оболочки типа fish, но так как я ими не пользуюсь ежедневно, то и рассказывать вам про них сегодня не буду.

А завтра снова пятница, неделя прям в трубу вылетела. Давайте, увидимся. 🐱

tags: #bash #linux
—
🟢 Подпишись: @bashdays

В консоли существует неочевидный способ очень удобно вводить многострочные команды либо накидывать скрипты. Ща покажу на котиках.

Для этого вызывается текстовый редактор указанный у тебя по умолчанию в переменной $EDITOR. Ты снова скажешь — да блять блин! Это надо еще и редактор запускать?

Да, запускать надо, но для этого из коробки есть охуенный отличный нативный хоткей CTRL+x+e (а в osx кнопка CTRL со значком ^).

Как нажать CTRL+x+e и не сломать пальцы? Сначала зажимаешь и удерживаешь CTRL, следом жмешь x и не отпуская CTRL жмешь e.

📺 Тырым-Пырым и перед тобой уже твой любимый vim/mcedit/nano/другойshit

Если получил ошибку: External editor requested but $VISUAL or $EDITOR not set. Не расстраивайся, выполни эти команды и у тебя все заработает. Вместо nano подставь своё.

EDITOR=$(which nano)
export EDITOR=$EDITOR

Либо на постоянку добавь в ~/.bashrc или ~/.zshrc и не забудь перечитать эти файлы: source ~/.bashrc && source ~/.zshrc

which — команда используется для определения местоположения данного исполняемого файла, который выполняется при вводе имени исполняемого файла (команды) в строке терминала. Команда ищет исполняемый файл, указанный в качестве аргумента, в каталогах, перечисленных в переменной среды PATH.

Есть еще команда select-editor, но не везде присутствует, она сразу список всех редакторов выведет в читабельном виде, тебе останется лишь выбрать циферку. Редактор установится глобально в системе без правки .bashrc/zshrc.

Так, ушли от темы, короче вызвал ты свой любимый редактор и не сломал пальцы. А дальше? А дальше накидываешь в нем скрипт или команды, которые тебе нужно выполнить в оболочке bash/zsh.

Размеренно, удобно, с подсветкой синтаксиса и хоткеев, а если у тебя прокаченный vim, так вообще полноценная IDE получается.

Накидал? Сохраняешь! Сохраняется по умолчанию во временную папку: /tmp/bash-fc.GpOzlI

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

Я частенько пользуюсь этим способом, когда мне нужно к примеру выполнить на сервере 100 команд подряд, просто копипастю копипасту, вызываю CTRL+x+e, вставляю туда свою портянку, сохраняю и иду в кроватку принимать горизонтальные процедуры.

А еще если ввел какую-то длинную команду в консоли и хочешь ее сохранить отдельным скриптом, жмешь хоткей ctrl+x+e и вуаля, открывается редактор и в нем уже вставлена эта команда. Сохраняешь в папке ~/Downloads и забываешь про этот файл навсегда.

Почему не ansible? Хм, можешь и плейбуки написать. Хозяин барин. Но у нас тут про комфортную работу в консоли. Про ansible тоже посты будут, но попозже.

Практично, удобно, всё работает из коробки. А мы с тобой такое любим. Вот такие пироги! Ну и с пятницей друзья, всем хороших предстоящих выходных, берегите себя.

PS: Кстати выйти из vi/vim можно командой :q! Это тебе бонус на всякий случай 👋

tags: #bash #linux
—
🟢 Подпишись: @bashdays

Порой мне кажется, что в выходные я устаю больше, чем за всю рабочую неделю. Но это скорее психологическая усталость, так как выпадаешь из рабочего ритма/потока и потом сложно обратно запрыгивать. Ладно, у нас тут не кружок психологии. 😳

Сегодня на повестке у нас с тобой OOM Killer.

Out of Memory Killer (OOM Killer) – это механизм ядра Linux, который освобождает оперативную память при ее исчерпании за счет принудительного завершения некоторых запущенных процессов.

Погнали разбираться это работает и как его можно обуздать.

Когда оперативная память в ос linux заканчивается, происходят забавные вещи, ядро вызывает «кракена» OOM Killer. В свою очередь «кракен» прогоняет процесс по определенным правилам и убивает его.

Бытует ошибочное мнение, что OOM Killer берет самый жирный процесс и киляет его. Это не так. Создатели этого механизма знатно упоролись.

OOM Killer использует достаточно сложный анализ и присваивает каждому процессу очки негодности (badness). При исчерпании памяти, будет убит именно самый негодный процесс. Некий естественный отбор. Процесс убивается сигналом SIGKILL и не предоставляет приложению корректно завершиться. Вызывается функция out_of_memory, а далее select_bad_process.

После убийства, в системном журнале появится строчка:

Out of Memory: Killed process 2256 (mysql) score 907 or sacrifice child

А это уже не шутки. Если к тебе стал приходить OOM Killer, значит в какой-то момент на сервере, что-то пошло по пизде не так и нужно разобраться.

Очки негодности могут принимать значение от -1000 до +1000. Соответственно чем выше это значение, тем вероятнее, что процесс будет убит. А процесс со значением -1000 будет по логике — бессмертным.

Посмотреть репутацию процесса, можно командой:

cat /proc/<PID>/oom_score

Где PID это идентификатор процесса, узнать можешь командой ps ax|grep postfix

В результатах ты увидишь число, к примеру: 826, это и есть очки негодности.

Если интересно как начисляются очки негодности, я вынес это в отдельный пост в телеграф, чтобы не валить тебя скучной теорией. Почитать можешь тут:

✅ Как вычисляются очки негодности?

TL;DR Если подытожить, то OOM Killer убьет самый «жирный» процесс, который наименее активен в системе и имеет самое короткое время жизни.

Как обуздать OOM Killer? 🔪

Можно вообще его отключить! Но по понятным причинам, это все равно что отключить жизненно важный орган у человека. Какое-то время он еще проживет, но потом обязательно сдохнет в kernel panic.

Отключается командой:

sudo echo 1 > /proc/sys/vm/panic_on_oom

По умолчанию 0 (то есть включено). Я ни разу не встречал, чтобы кто-то отключил этот функционал, но достаточно много раз сталкивался с забиваем костылей в сами процессы.

Можно повысить или понизить репутацию для процесса, добавив в файл oom_adj значение от -17 до +15. Для повышения репутации выполняем команду:

sudo echo -6 > /proc/<PID>/oom_adj

Не забываем подставить в PID, идентификатор нужного процесса.

Для отключения OOM Killer для определенного процесса, выставляем репутацию -17. Теперь этот процесс в «домике» и его никакая собака не посмеет тронуть.

sudo echo -17 > /proc/<PID>/oom_adj

Но если ты рестартанешь процесс, у него изменится PID. А репутация, которую ты ему уже накрутил, может примениться к совсем другому процессу таким же PID.

Также можно динамически определять PID процесса и менять ему репутацию. Закинуть это в крон и прыгать от счастья:

pgrep -f "/usr/sbin/sshd" | while read PID; do echo -17 > /proc/$PID/oom_adj; done

Но правильнее задать очки в самом systemd, в юните для сервиса, этот параметр:

[Service]
OOMScoreAdjust=-500

Собственно это база. По опыту скажу так — если к тебе пришел OOM Killer, сервак можно смело перезагружать. Нихрена там уже не работает, несмотря на всякие очки и коэффициенты. Перезагрузиться будет намного эффективнее, чем пытаться поднять что-то. Поднял, а потом уже по горячим следам и логам, дебаж.

Поздравляю, ты только что прокачался еще на один уровень. Хорошего тебе понедельника, да и лёгкой рабочей недели! Увидимся! 🐾

tags: #linux
—
🟢 Подпишись: @bashdays

День прошел, число сменилось нихуя ничего не изменилось. Привет, коллеги!

Как-то года 3 назад мы настолько устали каждую неделю ремонтировать маунтшары через glusterfs, что было принято решение выкинуть его нахуй и пойти в сторону упрощения. Много что попробовали, но остановились на sshfs.

GlusterFS — это распределённая, параллельная, линейно масштабируемая файловая система с возможностью защиты от сбоев. НУ-НУ 😠

SSHFS — это клиентская программа для Linux, используемая для удаленного управления файлами по протоколу SSH таким образом, как будто они находятся на локальном компьютере.

По вводным: у нас есть baremetal сервер с огромными HDD дисками на овер 500 терабайт. На диске хранится статика, которую отдаем через nginx. Задача: подключать этот диск в облачную инфраструктуру к различным нодам. Условия: чтобы работало и не воняло. 🤒

Тут все достаточно просто. Даем команду на нужной нам ноде и шара монтируется в папку /mnt/storage:

sshfs -o compression=no,allow_other,reconnect storage@bashdayz.ru:/storage /mnt/storage

compression - не использовать компрессию
allow_other - разрешить доступ к шаре
reconnect - нативный реконект если шара отвалилась

Из плюсов: на baremetal сервере не надо устанавливать никакой дополнительный софт, все работает по протоколу ssh.

Но есть нюансы. Допустим если ноду перезагрузить, то всё отвалится. Либо придут сетевые ножницы и оно тоже отвалится.

Запихать в fstab не вариант. Так как на этапе маунта еще нет сети и загрузка сервера просто остановится в попытках примонтировать шару. А ключик reconnect работает как ему захочется, даже если выставить таймауты проверок.

Решение простое, создаем три юнита в systemd.

✅ Первый юнит (АААААРРРРРР!!!!! В пост не влазиет, да и форматирование тут убогое, публикую в телеграфе)

After=network.target - запускать маунт только после того, как на хосте поднимется сеть
What=storage@bashdayz.ru:/storage - что монтируем
Where=/mnt/storage - куда монтируем

Важно! Файл юнита должен называться в соответствии с путем куда монтируем. Узнать имя можно командой:

systemd-escape -p /mnt/storage

Первый юнит сохраняем сюда: /etc/systemd/system/mnt-storage.mount

Теперь нужно сделать юнит проверки, если шара отвалилась. Для начала создаем юнит с таймером:

✅ Второй юнит

After=mnt-storage.mount - обеспечит запуск таймера после загрузки сервера, но только после того, как маунт юнит будет запущен, то есть после того, как удалённая ФС смонтируется.
Unit=mnt-storage.service - какой юнит будем запускать при срабатывании таймера. О нём чуть ниже.
OnCalendar=*-*-* *:*:00 - это означает каждую минуту.

Юнит-файл таймера можно называть как угодно. Но чтобы было понятнее, будем называть также, как и маунт-юнит. Итак, сохраняем в /etc/systemd/system/mnt-storage.timer

Теперь нужно создать юнит, который будет заниматься проверкой маунта и его перезапуском при необходимости:

✅ Третий юнит

Здесь всё просто. Bash строка в ExecStart это bash’евый однострочник, проверяющий наличие маркерного файла mount.yes, при отсутствии которого будет перезапущен маунт-юнит. В более новой версии systemd можно было бы это всё сделать иначе, но зато такой вариант более универсален.

Cохраняем в /etc/systemd/system/mnt-storage.service

Релодим и активируем

systemctl daemon-reload
systemctl enable mnt-storage.mount
systemctl enable mnt-storage.timer

Третий юнит mnt-storage.service при загрузке сервера активировать не нужно, поскольку этот юнит вызывается таймером mnt-storage.timer. Он будет всегда Active: inactive (dead), это нормально.

Ну и в финале запускаем таймер:

systemctl start mnt-storage.timer

Вот и все! Наша шара успешно взята под контроль, подключена. А в случае отвала по любым причинам, она сама перемонтируется без лишних вопросов. Ну и после перезагрузки ноды, тоже все поднимется из коробки.

Способ рабочий, полет стабильный более трёх лет. Можешь приспособить к своим каким-то изобретениям и использовать уже юниты, а не закроненные bash скрипты. А шары монтировать через sshfs, а не через вонючий, разваливающийся gluster. Фак еее! 🐄

tags: #linux
—
🟢 Подпишись: @bashdays

Доброе утро, наливай кофея и погнали. Щас расскажу, как мы сэкономили кучу денег на тестовой инфраструктуре.

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

Для каждого тестировщика свой отдельный стенд. Чтобы QA между собой не попиздились дрались и не ныли. Каждый стенд включает в себя 5 инстансов: балансировщик, база, фронтэнд, бекэнд, микросервисы. Считаем 5x5=25 серверов. Чето дохуя много. 😐

Все сервера развернуты в Selectel. По итогу в месяц набегает приличная сумма. По бюджету прям заметно кусается.

Думали мы, думали и придумали.

Будем автоматически отключать всю эту ферму на ночь, в выходные и праздники. Но столкнулись с проблемой, что даже выключенные машины — тарифицируются как включенные. Сука. Ладно.... В Selectel так нельзя, а где можно? А можно в Yandex Cloud!

Перетащили полностью тестовую ферму в YC. Накидали бота для slack/mattermost, который будет управлять кнопками включения/выключения. И реализовали такой концепт:

Концепт:

1. Бот взаимодействует с API Yandex Cloud.
2. С 18:00-08:00 реализовано автоматическое отключение фермы.
3. Автоматически отключаем ферму в выходные и праздничные дни (бот взаимодействует с производственным календарем).
4. Если тестировщик желает поработать вне рабочее время, он пишет боту команду и бот включает ему нужные сервера.
5. Если тестировщик забыл выключить сервер, бот проверит, что нет активности (берет метрики с prometheus) и всё погасит.

Есть еще всякие нюансы, но это основной алгоритм. Да. В YC тарифицируются HDD/IP/четотамеще даже если всё погасить, но это копейки.

По итогу если мы раньше платили 500к рублей в месяц только за тестовую инфраструктуру. Сейчас все это дело обходится в 100к, а порой и еще меньше. К примеру если тестировщик ушел в отпуск, то его сервер 2-3-4 недели будет выключен, а мы накопили себе на пивко.

Жалоб со стороны QA отдела не наблюдаем, значит решение рабочее. А сэкономленный бюджет можно смело пустить в дело: пропить либо выписать квартальные премии.

Сегодня закину еще один пост про костыли, правда после нативной интеграции, чото там про ЦОД и сети, от партнера залетит, не обессудьте. Ловите мясного пацана 👍

Спасибо коллеги за внимание, увидимся чуть попозже!

tags: #рабочиебудни
—
🟢 Подпишись: @bashdays