systemd: как писать юниты с элегантной перезагрузкой

Разработка системы с элегантным завершением работы может оказаться той ещё пляской с бубном. В идеальном мире каждый сервис управлялся бы юнитом systemd. ExecStart запускала бы процесс, обрабатывающий SIGTERM, а ExecStop оповещало бы процесс и осуществляло блокировку, которая бы корректно завершала процесс и его ресурсы.

Однако многие программы завершаются некорректно, а то и вовсе сбивают все настройки при закрытии. В этой статье мы рассмотрим поведение systemd при завершении работы и методы написания юнитов systemd для выборочной очистки (custom cleanup) перед закрытием.

👉 https://www.psdn.io/posts/systemd-shutdown-unit/

👉 DevOps Portal

Наткнулся на интересную штуковину — Linux Command Library

Это просто находка для всех, кто шарит за Linux

Огромная библиотека команд Linux, насчитывающая более 6000 страниц, причём всё раскидано по категориям, чтобы не путаться

И всё это работает офлайн, без интернета и трекинга.

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

👉 DevOps Portal

Автоматизируй всё с Ansible!

Ansible — это мощный инструмент, который упрощает управление конфигурацией, развертывание приложений и оркестрацию задач.

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

🔛https://agralrst.medium.com/automate-everything-with-ansible-aac7eb4d5cf9

👉 DevOps Portal

Что будете делать если у команды chmod убрали права на исполнение?

🔹 Используем утилиту setfacl. По умолчанию её может не быть в системе.

setfacl -m u::rwx,g::rx,o::x /usr/bin/chmod

🔹 Можно запустить утилиту chmod, передав её явно динамическому компоновщику. В контексте данной заметки считайте компоновщик интерпретатором для программы chmod. В разных дистрибутивах он может иметь разное название и расположение. Пример для Debian 11:

/usr/lib64/ld-linux-x86-64.so.2 /usr/bin/chmod +x /usr/bin/chmod**

🔹 Можно скопировать права с любого исполняемого файла и записать содержимое утилиты chmod в этот файл. Получается рабочая копия chmod. Создаём пустой файл с правами утилиты ls.

cp --attributes-only /usr/bin/ls ./new_chmod

Копируем содержимое утилиты chmod в созданный файл:

cat /usr/bin/chmod > ./new_chmod

Можно использовать:

/new_chmod +x /usr/bin/chmod

🔹 Почти то же самое что и предыдущий вариант только проще:

install -m 755 /usr/bin/chmod ./new_chmod

или так:

rsync --chmod=ugo+x /usr/bin/chmod ./new_chmod

🔹 Если умеете программировать, то, пример с Python:

python -c "import os;os.chmod('/usr/bin/chmod', 0755)"

👉 DevOps Portal

Визуализация процесса работы с Docker 👇

Давайте разберем основные термины с помощью аналогии:

🔹Dockerfile
— Представьте Dockerfile как рецепт или набор инструкций.

Вы начинаете с создания Dockerfile, который перечисляет все «ингредиенты» (программное обеспечение и конфигурации), необходимые для работы вашего приложения.

🔹Docker Image
— Используя Dockerfile как рецепт, вы «готовите» или «собираете» Docker Image.

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

🔹Docker Container
— После создания Docker Image вы можете «подать его на стол», создав Docker Container.

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

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

👉 DevOps Portal

Как скрыть процессы в Linux от других пользователей.

Если запустить pstree, ps, htop можно увидеть процессы не только свои, но также системные и пользовательские. В левой колонке будут имена пользователей.

Чтобы скрыть свои процессы от других пользователей, нужно перемонтировать /proc с опцией hidepid.

Работает только с пользователями, рут будет по-прежнему в курсе запущенных процессов

Параметр hidepid определяет какую информацию о процессах мы ограничим для пользователей, которые не являются владельцами этих процессов.

Параметры которые можно задать:

hidepid=0 - Включена по умолчанию, все видят всё, полный доступ к /proc/PID/.

hidepid=1 - Разрешает обращаться к информации только о своих процессов. Часть файлов в каталоге /proc/PID/ защищена.

hidepid=2 - Это тот же самый hidepid=1 + всё в /proc/PID будет невидимо для других пользователей.

Запускаем от рута:

mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

Теперь снова запускаем от обычного пользователя htop и наблюдаем, что выборка процессов пропала, и осталось +- 2, bash и htop.

Естественно после ребута сервера, все это пропадет. Чтобы этого не произошло — монтируем /proc в fstab.

Вставляем в /etc/fstab

proc /proc proc defaults,nosuid, nodev, noexec,relatime,hidepid=2 0 0

Встречаются приложения которые могут отвалиться. Для этого нужно зафиксить маунт с опцией gid=VALUE.

Значением gid параметра может быть имя группы в системе, членам которой доступ к процессам будет разрешён. И затем маунтить /proc таким образом:

proc /proc proc defaults, hidepid=2, gid=devopsport 0 0

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

👉 DevOps Portal

Walk — это инструмент на Go, который позволяет рекурсивно обходить директории и выполнять команды для каждого найденного файла или папки.

Ключевые особенности:
🔹 Простая команда для выполнения скриптов или операций над файлами.
🔹 Гибкость и высокая скорость работы.
🔹 Подходит для автоматизации задач, связанных с обработкой файлов.

👉 Репозиторий: https://github.com/antonmedv/walk

👉 DevOps Portal

👩‍💻 Основы сетевого взаимодействия Pod'ов

— Основы Pod Networking

🔹 Уникальный IP для каждого Pod: Каждый Pod получает уникальный IP-адрес, действующий во всем кластере.

🔹 Общая сеть для контейнеров Pod: Контейнеры внутри одного Pod'а делят одно сетевое пространство (например, виртуальная "сетевая комната"). Они общаются через localhost и используют общий IP и порты.

— Взаимодействие внутри кластера

🔹 Прямой трафик между Pod'ами:

1. Pod'ы могут общаться напрямую, даже если они находятся на разных узлах. Для этого не нужны прокси или NAT.

2. Исключение: Pod'ы на Windows, использующие host-сеть, не поддерживают это правило.

🔹 Node-агенты могут взаимодействовать с Pod'ами: Такие инструменты, как kubelet (агент узла), могут общаться со всеми Pod'ами на своем узле.

— Сервисы: стабильный доступ к Pod'ам

🔹 API Service: Предоставляет стабильный IP/имя хоста для группы Pod'ов (например, backend-серверов).

Пример: Frontend веб-приложения может подключаться к backend-сервису, не беспокоясь об изменении IP-адресов отдельных Pod'ов.

🔹 EndpointSlices: Kubernetes автоматически обновляет их для отслеживания активных Pod'ов, обслуживающих сервис.

— Маршрутизация трафика и прокси

🔹 Service Proxy: Направляет трафик к нужным Pod'ам.

— По умолчанию: kube-proxy (встроенный прокси Kubernetes).
— Альтернативы: Некоторые сетевые плагины заменяют kube-proxy своими прокси (например, Cilium).

— Внешний доступ к сервисам

🔹 Gateway API/Ingress:

1. Ingress: Устаревший способ предоставления внешнего доступа к сервисам (например, через HTTP-маршруты).

2. Gateway API: Современный и гибкий метод управления внешним трафиком (поддерживает сложную маршрутизацию и многокомандные настройки).

🔹 Тип LoadBalancer: Самый простой способ предоставить внешний доступ к сервису (работает с облачными провайдерами, такими как AWS или GCP).

— Сетевая безопасность (NetworkPolicy)

🔹 Контроль трафика: Определяет правила, например: "Только Pod'ы frontend могут взаимодействовать с Pod'ом базы данных."

🔹 Не всегда поддерживается: Зависит от сетевого плагина (например, Calico поддерживает NetworkPolicy, а простые плагины могут не поддерживать).

— Без ручной настройки сети

🔹 Автоматическое подключение: В отличие от старых систем (например, Docker links), Kubernetes автоматически управляет сетями.

🔹 Pod'ы как виртуальные машины: Подходите к Pod'ам как к отдельным серверам — не нужно вручную сопоставлять порты или управлять подключениями.

— Как Kubernetes реализует сети

🔹 Kubernetes задает правила: Указывает, что должно быть сделано (например, Pod'ы должны общаться напрямую).

🔹 Внешние инструменты выполняют работу:

1. Container Runtime Interface (CRI): Настраивает сетевые пространства Pod'ов (общие для контейнеров внутри Pod'а).
2. CNI-плагины: Управляют реальной сетью Pod'ов (например, Calico, Flannel).
3. Сервисные прокси: Обрабатывают маршрутизацию трафика (например, kube-proxy или прокси плагинов).

— Ключевые моменты для понимания

🔹Сеть Pod'ов vs. Host-сеть:

1. Сеть Pod'ов: Режим по умолчанию (Pod'ы получают уникальные IP).

2. Host-сеть: Pod'ы используют IP узла (редко используется, например, для инструментов мониторинга сети).

🔹 Устаревшие vs. современные инструменты:

1. Ранее требовалась ручная привязка портов (например, docker run -p 80:80).

2. Kubernetes автоматизирует этот процесс — ручная работа не требуется.

🔹 Примеры Gateway API:

1. Облачные: AWS Gateway API Controller, Google Cloud Gateway.

2. Универсальные: Istio, NGINX Gateway.

👉 DevOps Portal

Atuin

Это инструмент для улучшения истории командной строки, заменяющий стандартную историю оболочки.

Он сохраняет команды в зашифрованной базе данных, синхронизирует историю между устройствами и позволяет легко искать и фильтровать команды. Atuin поддерживает bash, zsh и fish, обеспечивая удобство работы с историей в терминале.

👉 https://github.com/atuinsh/atuin

👉 DevOps Portal

DevOps Roadmap 2025

Этот дорожный план поможет вам освоить ключевые навыки и технологии, необходимые для того, чтобы стать успешным инженером DevOps в 2025

👉 DevOps Portal

⚙️ Руководство по сетевому программированию в Linux — LinuxNetworkProgramming

Полный учебник, охватывающий всё:
✅ Основы сетевого программирования в Linux
✅ Работа с сокетами
✅ Создание HTTP/TCP-клиентов
✅ Использование неблокирующих сокетов
✅ Безопасная коммуникация с libcurl и OpenSSL

👉 GitHub: LinuxNetworkProgramming

👉 DevOps Portal

💡🐧 Быстрый совет по Linux

Команда ls — отличный инструмент командной строки для вывода списка файлов и каталогов в Linux.

Однако lsd — это еще более современная альтернатива ls. Она добавляет значки, цветной вывод и делает представление информации более удобным и наглядным.

$ lsd -lah

Если команда lsd не установлена в вашей системе по умолчанию, обратитесь к документации вашей системы для инструкций по установке.

👉 DevOps Portal

Введите в вашем терминале эту команду:

watch -d -n 1 sensors

Это отображает данные о температуре CPU, GPU, Wi-Fi, NVMe SSD и HDD в реальном времени.

Подробнее: https://cyberciti.biz/faq/howto-linux-get-sensors-information/

👉 DevOps Portal

Dockerfile: рекомендации и ошибки

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

🔹Последующие сборки не смогут повторно использовать кэш.
🔹Кэшированные файлы увеличат размер финального образа.

...но что если я скажу вам, что:

🔹Разные запуски команды docker build могут повторно использовать кэш менеджера пакетов.
🔹Кэшированные файлы не попадут в финальный образ.
🔹Кэш будет работать, даже если один из вышеуказанных слоев изменится.

И все, что для этого нужно, это использовать инструкцию RUN --mount=type=cache. Вот пример для сборки образа с Python 👆

👉 DevOps Portal

💻 Ошибки Kubernetes: подробный список (часть 1)

Ошибки Pod/контейнера

🔹CrashLoopBackOff

— Причина: Контейнер продолжает падать из-за ошибок в приложении.
— Первый шаг: Проверьте логи с помощью kubectl logs <pod> и отладьте приложение.

🔹ImagePullBackOff

— Причина: Kubernetes не может загрузить образ контейнера из реестра.
— Первый шаг: Проверьте название образа, учетные данные (если образ приватный) и убедитесь, что реестр доступен.

🔹ErrImagePull

— Причина: Kubernetes не удалось загрузить образ контейнера.
— Первый шаг: Убедитесь, что образ существует в реестре и его имя написано правильно.

🔹OOMKilled

— Причина: Контейнер превысил лимит памяти.
— Первый шаг: Увеличьте лимит памяти в спецификации pod или оптимизируйте приложение.

🔹ContainerCreating в течение длительного времени

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

🔹Неудачная проверка Readiness/Liveness

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

Ошибки планирования Pod

🔹0/1 узлов доступны: 1 Недостаточно CPU

— Причина: Узлы кластера не имеют требуемых ресурсов CPU.
— Первый шаг: Масштабируйте кластер или отрегулируйте запросы ресурсов для pod.

🔹0/1 узлов доступны: Нет совпадений для селектора узла

— Причина: Селекторы узлов в спецификации pod не совпадают с метками узлов.
— Первый шаг: Обновите метки узлов или измените селектор узла в pod.

🔹0/1 узлов доступны: Правила Pod Affinity/Anti-affinity

— Причина: Правила размещения pod препятствуют планированию.
— Первый шаг: Проверьте и отрегулируйте правила affinity/anti-affinity в спецификации pod.

Ошибки с постоянным хранилищем

🔹VolumeMountConflict

— Причина: Несколько pod пытаются смонтировать том в режиме ReadWriteOnce.
— Первый шаг: Отрегулируйте режимы доступа к томам или конфигурацию хранилища.

🔹PersistentVolumeClaim в состоянии Pending

— Причина: Нет подходящего PersistentVolume.
—Первый шаг: Проверьте конфигурацию PV и убедитесь, что она соответствует требованиям PVC.

🔹Неудачное прикрепление тома

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

Ошибки RBAC и аутентификации

🔹Forbidden: Пользователь <user> не может просматривать ресурс <resource>

— Причина: У пользователя или сервисного аккаунта нет необходимых прав.
— Первый шаг: Создайте или обновите RoleBinding/ClusterRoleBinding.

🔹Unauthorized

— Причина: Неверный или просроченный kubeconfig.
— Первый шаг: Обновите токены, убедитесь в наличии правильных сертификатов или повторно войдите в кластер.

🔹Secret не найден

— Причина: Секрет, указанный в спецификации pod, не существует.
— Первый шаг: Создайте секрет или обновите pod, чтобы использовать существующий секрет.

Ошибки в управляющей плоскости и узлах рабочих

🔹etcdserver: запрос истек по времени

— Причина: Кластер etcd не работает должным образом или перегружен.
— Первый шаг: Проверьте логи и метрики etcd и убедитесь в правильном распределении ресурсов.

🔹Evicted

— Причина: Давление на ресурсы узла (например, недостаточно диска, памяти или CPU).
— Первый шаг: Освободите ресурсы или масштабируйте кластер.

🔹Узел испытывает давление на диск

— Причина: Недостаточно места на диске узла.
— Первый шаг: Очистите неиспользуемые образы или логи и мониторьте использование диска.

🔹Узел испытывает давление на память

— Причина: Слишком высокое использование памяти.
— Первый шаг: Определите процессы, потребляющие много памяти (top или htop), и оптимизируйте их или остановите. Рассмотрите возможность добавления памяти в узел.

🔹Узел испытывает давление по PID

— Причина: Достигнут максимальный лимит процессов (PIDs).
— Первый шаг: Увеличьте лимит PID в /etc/systemd/system.conf. Проверьте "блуждающие" процессы и оптимизируйте использование ресурсов.

(часть 2)

🔹NodeNotReady

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

🔹Node Ready, NetworkUnavailable

— Причина: Сетевой плагин (CNI) не работает должным образом.
— Первый шаг: Проверьте логи плагина CNI (например, Calico, Flannel, Weave). Проверьте настройки сети и перезапустите pod плагина CNI.

🔹Не удается подключиться к серверу: x509: сертификат подписан неизвестным удостоверяющим центром

— Причина: Несоответствие сертификата сервера Kubernetes API и клиента.
— Первый шаг: Обновите файл ~/.kube/config или пересоздайте сертификат сервера API с действительным CA.

🔹Подключение к серверу <URL> отклонено

— Причина: Сервер API Kubernetes не работает или неправильно настроен.
— Первый шаг: Проверьте логи сервера API и убедитесь, что сервер работает на правильном порту.

Ошибки kubelet

🔹kubelet не работает должным образом

— Причина: Kubelet не может связаться с сервером API или неправильно настроен.
— Первый шаг: Проверьте логи kubelet (journalctl -u kubelet). Убедитесь, что конфигурация kubelet (/var/lib/kubelet/config.yaml) правильная.

🔹kubelet: не удалось запустить контейнер

— Причина: Проблемы с контейнерным окружением (например, Docker, containerd, CRI-O).
— Первый шаг: Проверьте логи контейнерного окружения (например, journalctl -u docker). Убедитесь, что окружение установлено и работает корректно.

🔹kubelet: не удалось смонтировать том

— Причина: Проблемы с постоянным томом или монтированием тома (например, хранилище недоступно, ошибка прав).
— Первый шаг: Проверьте, что хранилище доступно. Убедитесь в правильных правах доступа и настройках тома в спецификации pod.

🔹kubelet: узел не зарегистрирован

— Причина: Kubelet не может зарегистрировать узел в сервере API.
— Первый шаг: Проверьте логи kubelet и убедитесь, что токен kubeadm join действителен. Убедитесь, что узел может подключиться к управляющей плоскости по сети.

Ошибки контейнерного окружения

🔹ContainerRuntime не работает

— Причина: Контейнерное окружение (например, Docker, containerd) не работает или вышло из строя.
— Первый шаг: Перезапустите контейнерное окружение (systemctl restart docker или containerd). Проверьте логи на наличие ошибок.

🔹docker: не удалось загрузить образ

— Причина: Рабочий узел не может загрузить контейнерный образ из реестра.
— Первый шаг: Убедитесь, что у рабочего узла есть доступ в интернет (или к приватному реестру). Проверьте учетные данные для приватных образов.

Ошибки плагина CNI (сети)

🔹Pod застрял в ContainerCreating

— Причина: Pod не может подключиться к сети из-за проблемы с плагином CNI.
— Первый шаг: Проверьте логи плагина CNI в /var/log или с помощью kubectl logs. Убедитесь, что плагин CNI установлен и работает.

🔹Не удалось создать Pod SandBox

— Причина: Узел не смог создать пространство имен сети для pod.
— Первый шаг: Проверьте конфигурацию плагина CNI в /etc/cni/net.d/. Убедитесь, что выделение IP-адресов работает корректно.

🔹NetworkUnavailable

— Причина: Демон CNI (например, Calico, Flannel) не работает.
— Первый шаг: Перезапустите демоны CNI. Проверьте логи на наличие ошибок конкретного сетевого плагина.

👉 DevOps Portal

DevOps
MLOps
CloudOps
AlOps
DataOps
ITOps
RevOpS
FinOps
HROps
LegalOps
SysOps
BizOps
DevSecOps
ClickOps
LLMOps
ChatOps
NoOps

👉 DevOps Portal

Быстрый совет по Linux 🐧

Если вы хотите удалить пустые директории, команда find может упростить задачу:

$ find . -type d -empty -exec rmdir -v {} +

Опция -type d ищет директории, -empty выбирает пустые, а -exec rmdir {} выполняет команду rmdir, чтобы удалить их.

Команда rmdir гарантирует, что директория пуста, прежде чем удалить её.

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

$ find . -type d -empty -delete

👉 DevOps Portal

💻 Совет по устранению неполадок в Kubernetes: Устранение проблем с сетью.

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

Лично я предпочитаю использовать инструмент "Netshoot", основанный на Docker-образе. В нем есть большинство необходимых инструментов (ping, curl, dig, nmap, netcat и т. д.), и его можно запустить как временный под. Он будет работать, пока вы им пользуетесь, а как только вы выйдете из пода, тот сразу же будет удален.

Команда для его запуска:
❯ kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot --namespace=<namespace> -- /bin/bash

👉 DevOps Portal

Kubernetes 101: назначение Pod'ов на узлы

В статье подробно рассматриваются механизмы назначения Pod'ов на узлы в Kubernetes.

Автор объясняет такие инструменты, как nodeSelector, nodeAffinity и taints/tolerations, которые позволяют контролировать, где именно будут запускаться ваши Pod'ы

👉 Ссылка на статью

👉 DevOps Portal