Bash Days | Linux | DevOps

О бедном ТЗ замолвите слово

🔤🔤🔤🔤🔤🔤🔤

Без внятного ТЗ — Результат ХЗ.

При любой задаче всегда необходимо составить ТЗ.

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

Изначально у вас есть ограничение — бюджет.

Далее вы выделяете те характеристики которые вам необходимы.

При этом часть характеристик будут друг другу противопостовляться.

Ноутбук с 17 дюймовым экраном практически не может быть легче чем ноутбук с 12 дюймовым экраном.

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

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

При проекте:

🔤 Все рисуем и документируем (чтобы было потом понятно куда и что ставить)

🔤 Схема сети (чем лучше проработана схема — тем проще потом будет создавать защиту на сетевом уровне)

🔤Какие требования ты предъявляешь к проекту (ОТП, сертификаты, хранилище образов и конфигураций, dns, ntp, proxy для управления трафиком, где будет точки управления (mgmt segment) и как ты все это будешь защищать.)

🔤 Далее подбираются решения по каждому вопросу, описанному выше.

🔤 Проверяется во сколько обойдется данный проект (бюджетирование)

🔤 Описывается общая политика кому и что позволено в данном проекте.

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

После подробного описания (в документации) можно начинать вообще что-то делать 😲

Поэтому прежде чем задавать вопросы на форуме/чате сначала напишите:

🤩 Что хотите получить.

🤩 Приложите логи где ошибка.

🤩 При сетевых вопросах — хотя бы схему от руки как минимум как вы хотите чтобы это работало.

🛠 #рабочиебудни #workflow
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Bash, Devops и Linux это конечно замечательно…

Хотел тебе сегодня про «Симулятор айтишника» рассказать, но по РФ законам такой контент оказывается запрещен. Облом.

Приведу лишь цитату из описания:

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

Если гуглить умеешь, сам найдешь всё необходимое. Дерзай. SIMS на максималках.

🛠 #linux #games #debug
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Чтоб тебе такого интересного рассказать… а давайка я научу тебя весьма полезной теме. Сегодня будем резать аппетиты.

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

Создаем синтетику

#!/bin/bash

while :; do :; done

Чмодим и запускаем. По итогу твой проц начинает хуярить как не в себя, выжирая на 100500% все свободные ресурсы. Хуита!
ㅤ
Давай это исправим и разрешим скрипту хуячить лишь на 50%.

Для начала проверяем, сможем ли мы это сделать

mount | grep cgroup2
cat /sys/fs/cgroup/cgroup.controllers

Если получил выхлоп, то в большинстве случаев у тебя всё получится.

Создадим клетку «bashdays.slice»:

sudo su
cd /sys/fs/cgroup
mkdir bashdays.slice
echo "+cpu +memory +io" > cgroup.subtree_control
cd bashdays.slice
echo $$ > cgroup.procs

echo "50000 100000" > cpu.max

Здесь мы включаем нужные контроллеры для дочерних директорий, запихиваем туда текущий shell и в последней строчке выставляем 50% для CPU.

Снова запускаем первый скрипт-пожиратель и наблюдаем как проц перестал хуярить как не в себя и ограничен теперь половинкой (50%). Отличная работа!

Что такое cgroups — это такая комната наказаний в ядре Linux. Ты создаёшь группу процессов, ядро начинает следить за их CPU, памятью, диском, IO и карать, если они жрут больше положенного.

Аналогично можно сделать и с RAM и с IO.

echo $((512*1024*1024)) > memory.max

Создаем еще одну синтетику:

#!/bin/bash
blocks=()
while true; do
    blocks+=("$(head -c 104857600 </dev/zero | tr '\0' 'A')")
    echo "Allocated ${#blocks[@]}00 MB"
    sleep 1
done

Жрём память пачками по 100 МБ. Сначала увидишь замедление (reclaim), потом — пиздец! Нас выкинет локальный OOM, но только внутри cgroup, а не всей системы.

Посмотреть статистику в реальном времени:

cat memory.current
cat memory.events

Ну и давай посмотрим IO (тормозим винт и превращаем его в флешку USB1.1). Цель — мы хотим, чтобы процесс читал с диска не быстрее 10 МБ/с:

Узнаем major:minor:

lsblk --output NAME,MAJ:MIN

Допустим, диск — 8:0 (типичное для /dev/sda).

echo "8:0 rbps=10485760" > io.max

И запускаем:

#!/bin/bash

dd if=/dev/sda of=/dev/null bs=1M

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

Кстати это отличные способы заподлостроения либо как вариант подойдут для технических собеседований.

Например, говоришь кандидату — найди почему тормозит винт, либо — объясни почему скрипт жрет 50% процессора, а не 100%. Сразу вычислишь бродяг вайтишных, им даже ГПТ не поможет.

Короче такие вот приколы! Изучай!

🛠 #linux #cgroup #debug
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

В Proxmox 9.1 завезли OCI. В предыдущем посте про обновление с 8ки на 9ку я это уже упоминал, поэтому повторяться не буду.

➡️ Как я обновлял Proxmox и остался жив

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

Тут важное замечание — тебе не нужно устанавливать руками docker демона в LXC и только затем запускать контейнер. OCI все сделает само. Это не какой-то встроенный docker или k8s. Всё так или иначе работает под управлением LXC.

К примеру возьмем заезженный образ nginx, который валяется в dockerhub:

nginx:latest

Заходим в Proxmox и идем в раздел с шаблонами, там будет кнопка Pull from OCI Registry.

➡️ ЧИТАТЬ ПРОДОЛЖЕНИЕ


🛠 #proxmox #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

А у нас сегодня на повестке интересная «темка» — Автоматическая очистка tmp-файлов даже после SIGTERM.
ㅤ

Как говорится — Волков бояться, в лесу не ебаться!

Пишем подопытный скрипт:

#!/usr/bin/env bash
set -e

temp=$(mktemp)
echo "Создал файл: $temp"

false

echo "Удаляю файл"
rm -f "$temp"

Чмодим, запускаем, ага скрипт упал на false, но успел создать временный файл в папке /tmp == /tmp/tmp.oWQ0HiYxSV. И он не удалился. Скрипт вернул статус == 1;

Код выходы проверить так:

echo "код: $?"

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

Снова изобретать велосипед? Неа! Всё это работает из коробки.

#!/usr/bin/env bash
set -e

temp=$(mktemp)
echo "Создал файл: $temp"

trap 'echo "Удаляю $temp"; rm -f "$temp"' EXIT

false

В этом случае скрипт также вернет код 1, но временный файл будет удалён при любом раскладе.

Нихуя непонятно, но очень интересно.

Смотри — trap вызывает rm ПРИ ВЫХОДЕ ИЗ СКРИПТА. И похуй с каким статусом был завершен скрипт. Временный файл будет гарантированно удалён.

Давай подключим strace:

strace -e trace=process,signal bash -c '
  tmp=$(mktemp)
  trap "rm -f $tmp" EXIT
  echo "tmp=$tmp"
'

В выхлопе видим:

openat(AT_FDCWD, "/tmp/tmp.Dn2qG3uK9V", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
rt_sigaction(SIGINT, {sa_handler=0x...}, NULL, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x...}, NULL, 8) = 0
unlink("/tmp/tmp.Dn2qG3uK9V") = 0
exit_group(0) = ?

openat(... O_EXCL) — это mktemp, создающий файл атомарно
rt_sigaction() — Bash ставит ловушки для сигналов
unlink() — это и есть выполнение trap
exit_group(0) = ? — завершает процесс

То есть Bash вызывает rm/unlink() ДО выхода из процесса.

Почему trap срабатывает?

Если скрипт упал или получил сигнал kill -TERM <pid>, то на уровне Bash:

— в обработчике сигнала вызывается registered trap
— затем Bash падает/выходит
— trap УЖЕ успел выполнить команду очистки

trap выполняется ДО того, как процесс отдаст SIGTERM ядру, если только ловушка для этого сигнала была установлена.

Да банально при выполнении скрипта ты нажал CTRL+C, скрипт остановился, НО временные файлы сразу подчистились.

➡️ Про exit codes (коды выхода) писал тут.
➡️ Про сигналы писал ранее тут и тут и тут и тут.

Вот такие пироги!

С пятницей и хороших тебе предстоящих выходных!

🛠 #bash #debug #strace
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Docker Privileged VS Non-privileged

Как говорится — «Нам нужно досье на этого мисье»

Давай сразу к примерам:

➡️ Non-privileged

Ты ребёнок, тебя посадили в песочницу, дали совок и формочки, сказали — слышь еблан, играть можно только здесь!

Ты можешь:

— лепить куличики и кренделя
— копать ямки и могилки для жуков
— сыпать песочек в глаза другим детям
— строить свой маленький мир

Ты не можешь:

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

Ты работаешь строго в пределах песочницы. Безопасно, предсказуемо, контролируемо, изолировано. Ты бездушный non-privileged контейнер.

➡️ Privileged

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

Всё это происходит, когда ты запускаешь:

docker run --privileged

Твой контейнер может:

— управлять сетевыми интерфейсами хоста
— лезть в /dev
— монтировать что угодно куда угодно
— работать как полноценная виртуалка
— запускать systemd, модифицировать ядро, iptables, модули и т.п

То есть, это уже не ребёнок в песочнице, а ребёнок со швейцарским армейским ножом, запертый в серверной.

➡️ Non-privileged (обычный контейнер)

- Ограниченный доступ к Linux capabilities
- Нет доступа к аппаратным устройствам
- Нет прав на управление сетью хоста
- Запуск отдельных процессов, а не мини-ОС
- Работает в namespace'ах и cgroup'ах изоляции

Используется для:

- веб-сервисов
- приложений
- баз данных
- CI/CD runner’ов (если привилегия не нужна)
- всего, что «из коробки» работает в Docker

➡️ Privileged (контейнер-всевластия)

- Доступ ко всем Linux capabilities
- Может лезть в /dev, работать с устройствами
- Может менять сетевые интерфейсы хоста
- Может работать как виртуалка
- Может запускать systemd
- Может cломать или убить сеть, firewall и модули ядра

Используется для:

- контейнеров, которым нужны реальные устройства
- low-level инструментов: tcpdump, wireshark, iptables
- Docker-in-Docker в особых сценариях
- Kubernetes kubelet / CNI плагины
- экспериментов, когда нужно «полный root над всем»

Что выбрать?

Мой алгоритм:

Задача не требует низкоуровневых операций?
⚪ всегда non-privileged.

Нужно одно конкретное действие (например NET_ADMIN)?
⚪ --cap-add вместо privileged.

Нужен доступ к устройству?
⚪--device вместо полного доступа.

Ничего из этого не помогает?
⚪ тогда уже --privileged.

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

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

На днях продолжим…

🛠 #linuxfactory #linux #docker
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Как я обновил Proxmox и остался жив

Здрасти, приехали. Сегодня будем обновлять proxmox 8 на 9.1 Оно в принципе и необязательно, но очень хотелось потыкать новую фичу с OCI.

OCI это способ запускать контейнеры из Docker-образов. То есть proxmox теперь умеет скачивать Docker-образы (OCI-images) и превращать их в LXC-контейнеры.

А нахуя? Чтобы проще запускать приложения, которые уже существуют в виде Docker-образов. Теперь в LXC не нужно поднимать отдельно докер демон, все работает из коробки.

Ладно, отвлеклись. Про OCI отдельно распишу. Сегодня обновляем всю эту трихомудию до нужной версии.

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

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

По классике сюда всё не влезло, поэтому гоу в блог читать продолжение 👇

🅰️🅰️🅰️🅰️🅰️🅰️🅰️🅰️
➡️ https://two.su/4ui2c
🅰️🅰️🅰️🅰️🅰️🅰️🅰️🅰️

🛠 #proxmox #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

А вот это нам надо!

TUI админка для Proxmox. И да, ее можно поставить себе локально и цепануть к ней все твои Proxmox кластера, которые находятся где-то в сети.
ㅤ
Называется всё это добро — pvetui

Работает под всеми операционками, так как реализован на GO.

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

Ты скажешь — дак сделай алиасы для айпишников и цепляйся к нужным виртуалкам. Справедливо, но мне лень. Тем более виртуалки у меня постоянно создаются, удаляеются и я ебал каждый раз алиасы делать.

Установка и запуск:

go install github.com/devnullvoid/pvetui/cmd/pvetui@latest
/home/user/go/bin/pvetui

Под другие ОС:

yay -S pvetui-bin
yay -S pvetui-git
brew install --cask devnullvoid/pvetui/pvetui
scoop bucket add pvetui https://github.com/devnullvoid/scoop-pvetui
scoop install pvetui

# либо из исходников
git clone https://github.com/devnullvoid/pvetui.git
cd pvetui
make install

При первом запуске утилита попросит сконфигурировать её. Жмем пару раз Enter, открывается редактор конфига, заполняем необходимые поля.

Я заполнил URL, логин и пароль от панели Proxmox. Чтобы оно не орало, нужно стереть данные в полях API, тогда оно даст сохранить конфигурационный файл.

Но опять же если у тебя API ключ, делаешь под своё конфигурацию.

Инициализация, закончена, видим сообщение:

✅ Configuration is ready!
🔄 Please re-run 'pvetui' to start the application with your new configuration.
🚪 Exiting.

Запускаем морду и смотрим что получилось.

/home/user/go/bin/pvetui

Эту штуку можно повесить на alias либо прописать в PATH, чтобы полные пути до бинарника каждый раз не писать.

А получилось у нас прям заебись. Теперь я нажимаю ALT+2 и попадаю в список всех своих виртуальных машин. Стрелочками выбираю нужную мне машину и нажимаю букву «m», открывается менюшка.

В менюшке можно сразу провалиться в машину по SSH, что мне и нужно. Но это еще не всё, там и ребуты и миграции, даже VNC есть (нужен xdg). Короче базовый минимум поадминить присутствует.

Да, если нажать «ESC» то откроется еще одна глобальная менюшка для конфигурации самой утилиты, выбор профилей, управление плагинами и т.п.

Короче явки-ссылки я тебе дал, дальше сам смотри, всё там гибко конфигурируется и настраивается. И тем более TUI интерфейсы сейчас прям в трендах.

Хорошей тебе рабочей недели! Не болей!

🛠 #selfhosting #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Надоел и приелся VirtualBox/VMWare? Хочется новенького?

Да легко, опять же эта новая херабора как-то мимо многих прошла, включая меня. Нет это не LXC, vagrant и даже не docker.

Дело пахнет писюнами…

Короче, это — Multipass от Canonical. И да, полностью бесплатная и с мордой.
ㅤ
Выдумать ничего не буду, лови нативку с сайта:

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

Работает под Linux, Wiundows, Mac

Что же это за зверь?

Multipass использует доступный гипервизор в зависимости от платформы:

- Linux — KVM
- macOS — HyperKit или QEMU
- Windows — Hyper-V или VirtualBox (в новых версиях QEMU)

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

Чё прикольно, для него есть Terraform провайдер, ну прям не инструмент, а золото.

terraform {
  required_providers {
    multipass = {
      source  = "larstobi/multipass"
      version = "~> 1.4.2"
    }
  }
}

Работает элементарно, если через морду — выбираешь дистрибутив, накручиваешь ползунки и жмешь Launch, через 40 секунд у тебя готовая виртуалка.

Ну либо headless (через командную):

Основные команды:

multipass launch --name foo
multipass exec foo -- lsb_release -a
multipass list
multipass stop foo bar
multipass start foo
multipass delete bar
multipass purge
multipass find
multipass launch -n bar --cloud-init cloud-config.yaml
multipass help

Из дистрибутивов только Ubuntu, но этого достаточно чтобы что-то протестировать либо погонять. Ребята в LF активно этим инструментом пользуются и создают тестовые кубер-кластера, ну и ансибл оттачивают.

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

В общем рекомендую, инструмент зачетный, никакой ёбли как VBox и VMWare.

🛠 #devops #vm #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Разбираемся с options и inputs в gitlab
ㅤ
Частенько ребята с LF стали приходить с такой проблемой:

stages:
  - deploy
variables:
  ENVIRONMENT:
    description: "Deployment environment"
    value: "N/A"
    options:
      - "N/A"
      - "STAGE"
      - "PRODUCTION"
deploy:
  stage: deploy
  script:
    - echo "Выбрано окружение:" "${ENVIRONMENT}"
  rules:
    - when: manual

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

НО — этот список перестал появляться. Причем избрано, у кого-то есть, у кого-то хуй с маслом.

Ошибок синтаксиса в ямликах нет, каких-то разумных сообщений и наводок от гитлаба тоже нет. Чё делать?

➡️ Решение

Идем: Settings → CI/CD → Variables и кликаем в радио-батон — Developer.

Всё! Теперь выпадающие списки вновь начинают работать.

А еще людей смущает новая штука inputs, которая совсем недавно появилась. Работает она с 17й версии.

spec:
  inputs:
    environment:
      description: "Куда деплоим?"
      type: string
      default: "N/A"
      options:
        - "N/A"
        - "STAGE"
        - "PRODUCTION"
---
stages:
  - deploy

deploy:
  stage: deploy
  rules:
    - when: manual
  script:
    - echo "Выбрано окружение: $[[ inputs.environment ]]"

Оно будет пиздеть во внутреннем редакторе - Incorrect type. Expected "string | array".yaml-schema, но будет работать если запустить пайплайн.

Ошибка возникает, потому, что Pipeline Editor использует старый YAML-валидатор. Так что, не обращай внимание на этот пиздёж.

А зачем нам этот input ведь с options и так всё работает?

Ну хотя бы из-за типизированных параметров:

type: string | number | boolean | array

То есть:

- можно сделать чекбокс (boolean)
- можно сделать список (array)
- можно сделать ограничение по диапазону (number)
- можно сделать строгие варианты (options)
- можно сделать regex-валидацию

А обычный variables такого не умеют.

GitLab постепенно превращает CI в настоящий «Pipeline as Functions».

Например, в проекте А:

spec:
  inputs:
    env:
      type: string
      options: [stage, prod]
---
deploy-job:
  script: deploy_to $[[ inputs.env ]]

И проекте B можно вызвать:

deploy:
  trigger:
    project: A
    inputs:
      env: prod

Это как вызов функции с аргументом.

Что еще:

- Inputs работают даже при trigger-пайплайнах
- Inputs могут быть required
- Inputs отображаются отдельно и аккуратно в UI
- Inputs часть нового стандарта GitLab CI Components

Короче одни плюсы. Но есть большое НООООО!

Это пиздец усложняет процесс разработки и отладку пайплайна.

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

Пока тебе хватает обычных options используй их. Не лезь в это ООП, оно пока рано и избыточно, особенно если ты новичок.

Изучай!

Как говорится — и не такие метели в ебало летели!

🛠 #devops #cicd #linuxfactory
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Load Average на пальцах

Все про него знают, но не все понимают.
ㅤ
Давай рассмотрим такие цифры:

0.30  1.20  0.80

1. За последнюю 1 минуту средняя очередь = 0.30
2. за 5 минут = 1.20
3. за 15 минут = 0.80

Сразу куча вопросов, а что такое «очередь»?

«очередь» == количество задач, которые хотят работать прямо сейчас, но процессоров не хватает, чтобы заняться всеми сразу.

➡️ Главное правило

Сравниваем Load Average с количеством ядер.

- У тебя 4 ядра → нормальная нагрузка = до 4.0
- У тебя 1 ядро → нормальная нагрузка = до 1.0
- У тебя 8 ядер → нормальная нагрузка = до 8.0

🟢 Всё в порядке:

- LA ≤ количество ядер → CPU успевает всё делать, очередей нет.

🟡 Чёт уже не то, подгрузилось:

- LA ≈ количество ядер × 1–2 → процессы начинают стоять в очереди, но система пока еще жива.

🔴 Жопа:

- LA сильно > количества ядер → процессы стоят в очереди, всё тормозит.

➡️ Теперь на котиках

Ты стоишь в магазине:

- 1 касса, 1 человек в очереди → заебись
- 1 касса, 10 человек в очереди → жопа
- 4 кассы, 6 человек → пока норм

CPU = кассы, Load Average == очередь.

LA это не про загрузку CPU в процентах — это просто «очередь».

➡️ Как задебажить

Берем top, htop или подобное и смотрим столбец %CPU, если один процесс жрёт 100% на однопроцессорной системе — он пидарас и забил ядро. Если процесс жрёт 300% на 4-ядерной — он занял 3 ядра.

Смотрим самых прожорливых пидарасов:

ps aux --sort=-%cpu | head

Если ничего не нашел, то смотрим в сторону:

- I/O wait — медленный диск / много дисковых операций
- много процессов, но каждый почти ничего не ест (fork storm)
- сеть или блокировки

Капля в море, но это базовый чеклист на ситуацию, когда сервер ушел в «полку».

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

🛠 #linix #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Продолжаем ковырять angie, на этот раз посмотрим на Status Page, которая отображает всю статистику по веб-серверу. Выглядит прям хорошо.
ㅤ
Устанавливаем пакет:

sudo apt install angie-console-light

В папке /usr/share/angie-console-light/html появляется статика.

Добавляем локейшен:

location /console/ {
    auto_redirect on;

    alias /usr/share/angie-console-light/html/;
    index index.html;

    location /console/api/ {
        api /status/;
    }
}

Теперь открываем в браузере и видим красивую мордочку. Демо мордочки можешь посмотреть здесь.

Да, не забываем включить Basic Auth чтобы хитрожопые не подглядывали.

У меня на паре пет проектов эта морда включена (графана избыточна), чисто посмотреть статусы раз в сутки, которые возвращают 500ку. Если оно горит красным, значит что-то где-то пошло по пизде.

Подробнее читай в официальной документации.

🛠 #angie #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Туалетная бумага по cron’у
ㅤ
Я короче каждый месяц заказываю на WB туалетную бумагу, сразу беру 32 рулона. В чатике ссылки как-то скидывал на этот товар.

И в сентябре меня эта рутина — заебала! Основная проблема — я забываю вовремя пополнять запасы. И после всех туалетных процедур приходится сидеть и ждать несколько часов пока мой бэкенд подсохнет и остатки артефактов сами отвалятся.

Решено было накидать Bash скрипт, который каждый месяц будет заказывать на WB радость для моей жопы.

Открытой API у WB нет, но реверс-инженерию никто не отменял. Открываем в браузере режим разработчика, натыкиваем нужные действия на сайте и потом смотрим вкладку Network. Выбираем нужные запросы и рожаем скрипт.

Концепт скрипта:

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

2. Скрипт принимает единственный параметр $1, это ссылка на товар WB, мало ли бумага моя закончится и придется другого поставщика искать.

3. Дальше curl подгружает кукисы из файла, и делает несколько запросов к сайту, добавляет бумагу в корзину и оформляет заказ.

Пример добавления в корзину:

RESPONSE=$(curl -s "https://cart-storage-api.wildberries.ru/api/basket/sync?ts=$TS&device_id=$DEVICE_ID" \
  -X POST \
  -H 'content-type: application/json' \
  -H 'origin: https://www.wildberries.ru' \
  -b "$COOKIES_FILE" \
  --data-raw "$JSON_PAYLOAD"
)

Все параметры прилетают из $JSON_PAYLOAD, параметр автоматически заполняются нужными данными на основе переданного урла в $1, да, активно используется jq.

Говнокод конечно лютый получился, но работает. А это главное в нашем деле!

4. Ну и всё, в телегу мне приходит уведомление, что заказ оформлен, бабло спишут по факту. Ну и пишут примерное число доставки.

5. Как только товар пришел в пункт выдачи, получаю уведомление в телегу. Аналогично curl запросом проверяется статус в личном кабинете.

6. Закидываем скрипт в крон и забываем про эту рутину.

59 23 25 * * /usr/local/sbin/shit_paper.sh https://wb.ru/296/detail.aspx

Вот и вся наука. Теперь когда я возвращаюсь из гаража, захожу по пути в пункт выдачи и забираю свои 32 рулона. Удобно? Да охуенно!

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

Еще бы научить чтобы чайник сам в себя воду наливал, было бы вообще ништяк.

Давай, увидимся! Хороших тебе предстоящих выходных и береги себя!

🛠 #bash #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Вопрос с LF, думаю всем полезно будет.
ㅤ
Пишу пайплайн, есть такая конструкция:

platform=$(uname -m)
docker run --platform linux/arm64

Я бы хотел, чтобы параметр --platform linux/arm64 подставлял в том случае, если архитектура платформы == arm64, в других случаях этот параметр подставлять не нужно.

Делаю так, но получается какая-то хуйня:

platform=$(uname -m)
docker run ${platform/arm64/--platform linux/arm64}

Короче смотри. Задачку можно решить несколькими способами.

Способ 1. Заточен под Bash:

platform=$(uname -m)
docker run $([[ $platform = arm64 ]] && echo "--platform linux/arm64")

Этот способ не сработает, если код запустится в /bin/sh, потому что оно не POSIX. Тут уже смотри под чем все это будет запускаться.

Тут можешь почитать чем отличаются [[ ]] от []
А тут что такое POSIX

Способ 2. Универсальный:

platform=$(uname -m)
docker run $( [ "$platform" = "arm64" ] && echo "--platform linux/arm64" )

На 100 % POSIX-совместим. По функционалу эти способы идентичны.

Ну и по итогу имеем:

[[ ... ]] — это расширенная bash-версия, безопаснее и гибче (поддержка pattern, безопасность кавычек при пробелах и пустых строках, поддежка логики с &&)

[ ... ] — POSIX-совместимая, более строгая и требующая аккуратности с кавычками.

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

🛠 #bash #pipeline
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog