Linux Skill - Освой Linux c нуля до DevOps

🔥 Забудь про UptimeRobot: Свой мониторинг на коленке

printf "Hello\n"

Иногда разворачивать тяжелые комбайны мониторинга ради проверки пары узлов — это как стрелять из пушки по воробьям. Ты же знаешь силу командной строки: зачем тебе веб-интерфейс, если есть старый добрый Bash?

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

📌 Скрипт проверки доступности узла:

HNAME=news-15.net  # Пресловутый спамер.
# HNAME=$HOST        # Отладка: проверка локальной сети.
  count=2            # Отсылаются только два пинга.

if [[ `ping -c $count "$HNAME"` ]]
then
  echo ""$HNAME" все еще работает и рассылает спам."
else
  echo ""$HNAME" Кажется выключен. Жаль."
fi

Разбор полетов:
Переменная HNAME хранит адрес цели.
ping -c 2 отправляет ровно два пакета (чтобы не ждать вечно).
Конструкция if [[ ... ]] проверяет код возврата команды ping. Если 0 (успех) — узел жив.

💡 Почему это круто:

Ты не зависишь от стороннего софта.
Работает даже на встраиваемых системах и роутерах.
Легко добавить отправку уведомления на почту или в Telegram прямо в блок else.

#Linux #Bash #DevOps #Scripting #Monitoring

📉 Ubuntu весит 100МБ, а Alpine — 5МБ. Почувствуй разницу

Привет, $(whoami)! 👋

Твои Docker-образы занимают сотни мегабайт, а деплой длится вечность? Часто проблема в том, что ты используешь «тяжелые» базовые образы, в которых куча ненужного софта (6 разных оболочек, 3 пакетных менеджера и т.д.).

Для продакшена и микросервисов идеально подходит Alpine Linux. Это минималистичный дистрибутив, который весит всего около 5 МБ. Меньше размер — быстрее скачивание, меньше уязвимостей и выше скорость запуска.

📌 Пример минимального Dockerfile:

FROM alpine:latest
# copy all of the files in this project into the Docker image
RUN mkdir public-app/
ADD . public-app/
WORKDIR public-app

Что здесь происходит:
FROM alpine:latest — берем легкую базу.
Создаем папку и копируем туда проект.
Назначаем рабочую директорию.

💡 Совет:
Используй Alpine, когда тебе нужно запустить одно конкретное приложение или сервис. Если в образе нет лишних утилит, их не смогут использовать злоумышленники, что уменьшает поверхность атаки.

#Docker #DevOps #Alpine #Containers #Optimization

💥 IaC: Тестирование инфраструктуры — как внедрить инженерные практики и перестать бояться изменений

🔥 14 января в 20:00 мск — бесплатный открытый вебинар OTUS

Вы вносите изменения в Terraform/Ansible и молитесь, чтобы ничего не сломалось в проде? Пора перестать бояться: инфраструктура должна тестироваться так же жёстко, как продуктовый код.

На вебинаре разберём, как построить полноценную систему тестирования IaC и превратить изменения в инфраструктуре из лотереи в предсказуемый процесс.

📌 Что будет:
— Мифы и реальные боли: почему без тестов инфраструктура ломается в самый неподходящий момент
— Пирамида тестирования IaC
— Как встроить проверки в GitLab CI и сделать pipeline’ы предсказуемыми
— Практики выживания: стандарты, структура проектов, кодстайл, документация

🎯 После вебинара вы сможете:
— Автоматически проверять инфраструктурный код до применения
— Ловить регрессии и «магические» конфиги на этапе MR
— Внедрить тесты в текущие процессы без боли
— Снизить количество аварий и ночных звонков
— Поднять инженерную культуру команды до взрослого уровня

👉 Регистрация уже открыта https://otus.pw/SHSG/

Вебинар приурочен к старту курса «DevOps-инженер: практики и инструменты»: за 5 месяцев вы построите полностью протестированную, автоматизированную и отказоустойчивую инфраструктуру на реальном боевом стеке.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

💾 UUID или /dev/sda? Почему твой сервер не грузится

Привет, суперпользователь! 👋

Знакомая ситуация: подключил новый диск, перезагрузил сервер, а он «встал»? Скорее всего, имена устройств сместились (например, sda стал sdb), и система не нашла корневой раздел по старому пути,.

Чтобы спать спокойно, используй в /etc/fstab не имена устройств, а UUID (универсальный уникальный идентификатор). Он остается неизменным, даже если ты переставишь диски местами,.

📌 Как узнать UUID всех разделов?
Используй команду blkid (Block ID). Она покажет атрибуты всех блочных устройств.

# blkid
/dev/sdf2: UUID="b600fe63-d2e9-461c-a5cd-d3b373a5e1d2" TYPE="ext4"
/dev/sda1: UUID="17f12d53-c3d7-4ab3-943e-a0a72366c9fa" TYPE="ext4" PARTUUID="c9a5ebb0-01"
/dev/sda5: UUID="b600fe63-d2e9-461c-a5cd-d3b373a5e1d2" TYPE="swap" PARTUUID="c9a5ebb0-05"
/dev/sde1: UUID="4859-EFEA" TYPE="vfat"

Что мы видим:
UUID="..." — тот самый идентификатор, который нужно копировать в fstab.
TYPE="..." — тип файловой системы (ext4, swap, vfat).

💡 Лайфхак:
Если нужно узнать данные только для конкретного диска, просто укажи его имя: blkid /dev/sda1.

#Linux #SysAdmin #Storage #CLI #Fstab

🛡 Твой новый стандарт: Генерируем SSH Ed25519

С возвращением! 👋

Всё еще генерируешь ключи через rsa -b 4096? Это надежно, но ключи получаются длинными, а генерация — медленной. В современном мире стандартом де-факто становится Ed25519. Это алгоритм на эллиптических кривых: он безопаснее, быстрее и создает очень компактные ключи, которые удобно копировать.

Давай обновим твои доступы за одну минуту.

📌 Команда для генерации:

ssh-keygen -t ed25519 -C "admin@myserver"

Разбор флагов:
-t ed25519 — указываем тип ключа. Он обеспечивает превосходную безопасность и высокую производительность.
-C "комментарий" — метка (обычно email), чтобы ты не запутался в authorized_keys, когда ключей станет много.

💡 Что делать дальше?

1. Закинь ключ на сервер:
Используй утилиту ssh-copy-id, она сама разложит всё по полочкам:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Если ssh-copy-id нет под рукой, можно сделать это вручную (но это дольше):

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "cat >> ~/.ssh/authorized_keys"

2. Проверь права (на локальной машине):
Приватный ключ должен быть доступен только тебе (права 600), иначе SSH-клиент может отказаться работать или это создаст дыру в безопасности.

chmod 600 ~/.ssh/id_ed25519

Переходи на Ed25519 — это быстрее, короче и безопаснее. Сохрани шпаргалку, чтобы не гуглить флаги! 🔥

#SSH #Linux #Security #DevOps #CLI

🔥 Компактный IP: Смотрим сеть без боли в глазах

EHLO, коллега! 👋

Признайся, сколько раз ты вводил ip addr и тонул в потоке информации о MTU, qdisc и broadcast-адресах, пытаясь найти заветные цифры IP? 😵 Или по старой привычке ставил net-tools, чтобы вернуть любимый, но устаревший ifconfig,?

В современном пакете iproute2 есть скрытая жемчужина — флаг -br (brief), который превращает вывод в аккуратную таблицу. Больше не нужно писать длинные пайплайны с grep и awk.

📌 Команда для читаемого вывода:

ip -br a

Что она делает:
-br (brief) — включает режим краткого вывода.
a (addr) — показывает адреса.

Результат будет выглядеть примерно так:

lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.10/24 fe80::a00:27ff:fe0d:d90c/64

💡 Почему это круто:
1. Ты сразу видишь статус (UP/DOWN), имя интерфейса и IP.
2. Это работает «из коробки» в большинстве современных дистрибутивов (CentOS 8+, Ubuntu 18.04+ и др.).
3. Идеально для твоих скриптов и беглого просмотра состояния сети.

#Linux #Networking #CLI #SysAdmin #DevOps

💥 Фениксы и снежинки: как строить инфраструктуру, которая не ломается

🔥 25 декабря в 20:00 мск — бесплатный вебинар в OTUS

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

Разберём, как превратить хрупкую «снежинку» в инфраструктуру-феникс: полностью воспроизводимую, декларативную и самовосстанавливающуюся.

📌 Что будет:
— Как распознать «снежинку» и почему она смертельно опасна
— Принципы «феникса»: самовосстановление и предсказуемость
— Ключевые инструменты: Terraform, Ansible, GitOps — смерть ручным настройкам
— Процессы, которые спасают: код-ревью, тесты, автоматизация

🎯 После вебинара вы сможете:
— Мгновенно находить снежинки и уничтожать их
— Создавать окружения одной командой
— Сделать инфраструктуру независимой от людей
— Спать спокойно, даже если сгорит весь дата-центр

👉 Регистрация открыта: https://otus.pw/JloL/

Вебинар приурочен к старту курса «DevOps-инженер: практики и инструменты»: за 5 месяцев — полный боевой стек Docker → Kubernetes → Terraform → Ansible → CI/CD → мониторинг.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🏎️ Почему твой Linux грузится вечность? Находим и обезвреживаем

Эй, линуксоид! 👋

Знакома ситуация: отправил сервер в reboot, и можно идти варить кофе, потому что он поднимается мучительно долго? 😤 Часто виноват один-единственный «зависший» сервис, который тянет время всей системы.

В systemd есть встроенный инструмент-детектив, который покажет, кто именно крадет твои секунды.

📌 1. Оцениваем общий масштаб бедствия
Сначала посмотрим, сколько времени ушло на загрузку в целом (ядро + userspace).

$ systemd-analyze
Startup finished in 253ms (kernel) + 933ms (initrd) + 6.873s (userspace) = 8.060s

Это дает общее понимание: если userspace занимает слишком много времени, значит, проблема в службах.

📌 2. Ищем виновника (команда blame)
Эта команда выводит список всех запущенных юнитов, отсортированных по времени инициализации — от самых медленных к самым быстрым.

$ systemd-analyze blame
3.811s NetworkManager-wait-online.service
 806ms tuned.service
 680ms postfix.service
 490ms lvm2-monitor.service
 ...

В данном примере видно, что NetworkManager-wait-online.service задерживает запуск почти на 4 секунды.

📌 3. Анализируем критический путь
Иногда сервис запускается долго, но не тормозит остальных. Чтобы увидеть дерево зависимостей и понять, какой процесс реально блокирует финиш загрузки, используйте:

$ systemd-analyze critical-chain
graphical.target @9.663s
└─multi-user.target @9.661s
  └─snapd.seeded.service @9.062s +62ms
    └─basic.target @6.336s
      └─sockets.target @6.334s
        └─snapd.socket @6.316s +16ms
          └─sysinit.target @6.281s
            └─cloud-init.service @5.361s +905ms
              └─systemd-networkd-wait-online.service @3.498s +1.860s

Здесь видно, что systemd-networkd-wait-online.service является узким местом в цепочке,.

💡 Совет:
Если вы нашли «тормоза», которые вам не нужны (например, postfix на рабочей станции или ожидание сети там, где это не критично), их можно отключить (systemctl disable) или оптимизировать.

#Linux #Systemd #DevOps #SysAdmin #Performance