🤔 Как работает ingress controller, созданный с помощью bash

В этой статье вы узнаете, как работает контроллер Ingress в Kubernetes, создав его с нуля в bash.

Как работает эта штука, изображено на картинке.

Ingress controller можно рассматривать, как маршрутизатор, который перенаправляет трафик на нужные модули.

📖 Читать: ссылка

👉 DevOps Portal | #cтатья

CI/CD Workflow: упрощенный гайд от ByteByteGo (Alex Xu)

CI/CD — это методология, которая позволяет автоматизировать процесс разработки и доставки ПО в продакшн.

Будь вы разработчиком, специалистом по DevOps, тестировщиком или занимаетесь любой современной ролью в ИТ, CI/CD пайплайны стали неотъемлемой частью процесса разработки

👉 DevOps Portal

WatchYourLAN

Легковесный сетевой IP-сканер с веб-графическим интерфейсом.

Особенности:

⏩ Отправляет уведомления при обнаружении нового хоста
⏩ Отслеживает историю хостов онлайн/оффлайн
⏩ Сохраняет список всех хостов в сети
⏩ Отправляет данные в InfluxDB2 для создания панели мониторинга Grafana

⛓ Ссылка: GitHub

👉 DevOps Portal | #ресурсы

Kubernetes изнутри

Автор: Джей Вьяс, Крис Лав
Год: 2023

📂 Скачать книгу

👉 DevOps Portal | #книги

Bruno — опенсорсная IDE для изучения и тестирования API.

Это новый и инновационный API-клиент, призванный кардинально изменить существующий порядок, представленный Postman и аналогичными инструментами.

Bruno хранит коллекции в папке в ФС. Используется простой язык разметки текста Bru для сохранения информации о запросах API.

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

⛓ Ссылка: GitHub

👉 DevOps Portal | #ресурсы

😎 Хотите стать профи в отладке контейнеров? Держите обучающую серию статей от Ивана Величко, в котором сложный материал объясняется на простых иллюстрациях:

⏩ Docker: How To Debug Distroless And Slim Containers
⏩ Kubernetes Ephemeral Containers and kubectl debug Command (перевод на Habr)
⏩ Containers 101: attach vs. exec — what's the difference?
⏩ Why and How to Use containerd From Command Line
⏩ Docker: How To Extract Image Filesystem Without Running Any Containers
⏩ KiND — How I Wasted a Day Loading Local Docker Images

👉 DevOps Portal | #cтатья

Администрирование Astra Linux

Автор: Андреев Е.Д.
Год: 2024

📂 Скачать книгу

👉 DevOps Portal | #книги

Профилировщик памяти для Linux

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

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

⛓ Ссылка: GitHub

👉 DevOps Portal | #ресурсы

💡 CLI-игра с различными уровнями сложности, которая поможет освоить Git от базового уровня до профи

⛓ Ссылка: GitHub

👉 DevOps Portal | #ресурсы

Что означает 2>&1?

Это про стандартные потоки вывода. Они имеют файловые дескрипторы:

stdout — 1 (общий поток вывода)
stderr — 2 (поток с ошибками)

Получается (2>&1) = stderr > stdout — направляем поток с ошибками, в стандартный поток вывода. Ошибки будут выводиться на экран в терминале.

Логичным было бы сделать конструкцию: 2>1. Но увы, эта схема отработает другую логическую операцию. Поток с ошибками stderr будет писать все данные в файл, у которого название будет 1.

Для этого и требуется указать символ & (амперсанд) перед stdout. Это будет интерпретировано как файловый дескриптор, а не обычный файл.

А почему тогда не &2>&1 ?
Символ & интерпретируется как файловый дескриптор только в контексте перенаправления.

Операция command &2>&1 анализируется так: command & 2>&1 — команда command будет выполнятся в фоновом режиме. А затем начнет выполнятся команда 2 с перенаправлением на стандартный вывод stdout.

Есть альтернатива с оператором |&.

|& это сокращенный вариант от 2>&1 |

Пример:

script.sh |& tee -a /var/log/script.log

Все что script.sh выведет в потоки stdout и stderr, будет перенаправлено в файл script.log.

В официальной документации можно подробнее изучить эту штуку.

👉 DevOps Portal

Рассмотрим ситуацию, когда случайно/специально 😱 удалился исполняющийся bash скрипт.

Чтобы не попадать в такие ситуации, всегда храните исходники в git — это избыточно, но бекапы никто не отменял.

Скрипт удалён с диска, но продолжает работать в фоне, значит его можно как-нибудь восстановить.

Создадим подопытный скрипт: touch /tmp/script.sh:

#!/bin/bash
sleep 1000
exit

Делаем исполняемым chmod +x /tmp/script.sh и запускаем в фоне /tmp/script.sh &

Символ & может служить разделителем между командами command & command, две команды выполнятся параллельно.

Скрипт запустили, он крутится в фоне. Удалим сам файл:

rm -f /tmp/script.sh ключ -f удалит без лишних вопросов.

Восстанавливаем:

lsof -c 'script.sh'

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

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
script.sh 261899 root 255r REG 8,1 51 130773 /tmp/script.sh

Берем PID = 261899, берем FD = 255 и делаем так:

cat /proc/261899/fd/255

А вот и исходник скрипта:

File: /proc/261899/fd/255
#!/bin/bash
sleep 1000
exit

Вот полезная инфа, которая была использована в гайде:
man 5 proc # /proc/[pid]/fd/
man lsof

👉 DevOps Portal

💡 Права доступа к файлам: пользователям Linux на заметку

👉 DevOps Portal