Путь Junior DevOps: от администрирования Linux до автоматизации 2025

Комплексный курс по матрице компетенций Rebrain, охватывающий системное администрирование, контейнеризацию, IaC и CI/CD. Программа сфокусирована на практических навыках настройки инфраструктуры и подготовке к техническому интервью.

1. Архитектура Linux и продвинутая работа в терминале

Архитектура Linux и продвинутая работа в терминале

Представьте, что вы нажимаете кнопку включения сервера. Через доли секунды процессор начинает исполнять первые инструкции, а еще через мгновение операционная система берет под контроль гигабайты памяти и десятки ядер. Для обычного пользователя это магия, для системного администратора — штатный процесс, а для DevOps-инженера — фундамент, на котором строятся отказоустойчивые кластеры. Если вы не понимаете, как ядро взаимодействует с «железом» и почему процесс в Linux не может просто так «залезть» в память соседа, вы не сможете эффективно отлаживать контейнеры в Docker или настраивать пайплайны в CI/CD.

Иерархия уровней: от кремния до пользователя

Архитектуру Linux принято представлять в виде слоеного пирога. В самом низу находится аппаратное обеспечение (Hardware), а на самом верху — пользовательские приложения. Между ними располагается ядро (Kernel) и системные библиотеки.

Ключевое различие, которое отделяет Linux от примитивных систем, — это разделение адресного пространства на Kernel Space (пространство ядра) и User Space (пространство пользователя).

  • Kernel Space. Здесь живет ядро. Оно имеет неограниченный доступ к памяти и оборудованию. Если в коде ядра происходит критическая ошибка, вся система «падает» в Kernel Panic. Ядро отвечает за управление процессами, памятью, драйверами устройств и сетевым стеком.
  • User Space. Здесь работают все ваши программы: веб-сервер Nginx, база данных PostgreSQL, оболочка Bash и даже Docker-демон. Процессы в User Space изолированы друг от друга и не имеют прямого доступа к оборудованию.
  • Чтобы программа из User Space могла, например, записать файл на диск или отправить пакет в сеть, она должна «попросить» об этом ядро. Этот запрос называется System Call (системный вызов).

    > Системный вызов — это единственный легальный способ для программы выйти за пределы своей «песочницы» и взаимодействовать с внешним миром через ядро.

    Когда вы вводите команду ls, происходит следующее: оболочка (shell) делает системный вызов fork() для создания нового процесса, затем execve() для запуска кода ls, а сама программа ls делает десятки вызовов openat() и getdents64() для чтения содержимого директории. Понимание этого механизма критично для отладки: если приложение «тормозит», DevOps-инженер использует инструмент strace, чтобы увидеть, на каких системных вызовах оно застревает.

    Ядро Linux: монолит с модульным характером

    Ядро Linux называют монолитным. Это означает, что все основные компоненты (планировщик задач, файловые системы, драйверы) работают в одном адресном пространстве. Однако оно обладает важным свойством — модульностью. Вам не нужно пересобирать всё ядро, чтобы добавить поддержку новой сетевой карты или файловой системы.

    Модули ядра (LKM — Loadable Kernel Modules) можно загружать и выгружать «на лету». Это экономит память и делает систему гибкой. Например, если вы подключаете USB-накопитель, ядро автоматически подгружает модуль usb_storage.

    Для управления модулями используются следующие инструменты:

  • lsmod: выводит список всех загруженных в данный момент модулей.
  • modinfo <имя_модуля>: показывает информацию о модуле (автор, лицензия, параметры).
  • insmod / rmmod: низкоуровневые команды для вставки и удаления модуля (используются редко).
  • modprobe: «умная» команда, которая учитывает зависимости. Если модулю для работы нужен модуль , modprobe загрузит оба.
  • В контексте DevOps модульность важна при работе с Docker и Kubernetes. Например, для работы сетевых плагинов (CNI) часто требуется модуль br_netfilter. Если он не загружен, контейнеры не смогут «общаться» друг с другом через мосты, и ваша задача как инженера — уметь проверить это через lsmod и настроить автозагрузку через файлы в /etc/modules-load.d/.

    Файловая иерархия и стандарт FHS

    В Linux «всё есть файл». Это не просто красивая фраза, а фундаментальная концепция. Жесткий диск — это файл в /dev/sda, оперативная память — файл (условно), текущие настройки ядра — файлы в /proc.

    Чтобы в системе не царил хаос, существует стандарт FHS (Filesystem Hierarchy Standard). Основные точки, которые вы должны знать наизусть:

    | Директория | Назначение | | :--- | :--- | | /bin, /sbin | Основные исполняемые файлы (ls, cp, ip, fdisk). sbin — для системного администрирования. | | /etc | Конфигурационные файлы всей системы. Здесь лежат настройки Nginx, SSH, сетевых интерфейсов. | | /var | Переменные данные: логи (/var/log), базы данных, кэши. | | /home | Домашние директории пользователей. | | /root | Домашняя директория суперпользователя. | | /tmp | Временные файлы (очищаются при загрузке или по расписанию). | | /proc, /sys | Виртуальные файловые системы. Через них можно смотреть состояние ядра и менять его параметры. |

    Особое внимание уделим /proc. Это не данные на диске, это «окно» в память ядра. Например, файл /proc/cpuinfo расскажет всё о процессоре, а в директории /proc/[PID]/ можно найти информацию о конкретном запущенном процессе с идентификатором PID. Если вы хотите узнать, какие лимиты установлены для процесса базы данных, вы заглянете в /proc/1234/limits.

    Жизненный цикл процесса и сигналы

    Процесс — это экземпляр запущенной программы. У каждого процесса есть свой уникальный номер — PID (Process ID). Иерархия процессов начинается с systemd (или init), который всегда имеет . Все остальные процессы являются его «детьми» или «внуками».

    Состояния процесса:

  • R (Running/Runnable): процесс либо выполняется прямо сейчас, либо ждет своей очереди на процессоре.
  • S (Interruptible Sleep): процесс ждет какого-то события (например, ввода от пользователя или ответа от сети). Большинство процессов в системе находятся именно в этом состоянии.
  • D (Uninterruptible Sleep): «глубокий сон». Обычно возникает при ожидании ввода-вывода (I/O) от диска. Процесс в этом состоянии нельзя убить даже командой kill -9.
  • Z (Zombie): процесс завершился, но его родитель еще не прочитал код выхода. «Зомби» не потребляют ресурсов (кроме записи в таблице процессов), но их большое количество — признак плохой работы софта.
  • Для управления процессами мы используем сигналы. Сигнал — это короткое уведомление, посылаемое процессу.

  • SIGTERM (15): просьба завершиться красиво. Процесс должен закрыть файлы, сохранить данные и выйти. Это сигнал по умолчанию для команды kill.
  • SIGKILL (9): немедленное уничтожение процесса ядром. Процесс не может проигнорировать этот сигнал.
  • SIGHUP (1): исторически — «обрыв связи с терминалом», сейчас часто используется для того, чтобы заставить сервис перечитать конфигурационные файлы без полной перезагрузки.
  • Продвинутая работа в Bash: конвейеры и перенаправления

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

    Перенаправление потоков

    У каждого процесса есть три стандартных потока:
  • stdin (0) — стандартный ввод (клавиатура).
  • stdout (1) — стандартный вывод (экран).
  • stderr (2) — стандартный поток ошибок.
  • Примеры манипуляций:

  • ls > files.txt: направить вывод ls в файл (перезаписать).
  • ls >> files.txt: дописать вывод в конец файла.
  • command 2> error.log: сохранить только ошибки.
  • command > output.log 2>&1: направить и обычный вывод, и ошибки в один файл.
  • Конвейеры (Pipes)

    Символ | позволяет передать stdout одной команды на stdin другой. Это основа философии Unix: «Пишите программы, которые делают одну вещь и делают её хорошо. Пишите программы, которые работают вместе».

    Рассмотрим задачу: найти 5 самых тяжелых лог-файлов в /var/log.

    Разбор:

  • du -ah: оценивает размер файлов в человекочитаемом виде.
  • sort -rh: сортирует строки как числа (-n не сработает с суффиксами G/M, поэтому используем -h) в обратном порядке (-r).
  • head -n 5: оставляет только первые 5 строк.
  • Текстовые процессоры: grep, sed, awk

    DevOps-инженер постоянно работает с текстом: конфиги, логи, выводы команд. Умение пользоваться «святой троицей» текстовой обработки экономит часы работы.

    Grep: поиск по шаблону

    Самый простой инструмент. Позволяет фильтровать строки.
  • grep "ERROR" app.log: найти все строки с ошибками.
  • grep -v "DEBUG": исключить строки с DEBUG.
  • grep -r "127.0.0.1" /etc/: рекурсивный поиск IP во всех файлах в директории.
  • grep -E "[0-9]{1,3}\.": поиск с использованием расширенных регулярных выражений (например, поиск IP-адресов).
  • Sed: потоковый редактор

    Используется для замены текста «на лету».
  • sed 's/localhost/127.0.0.1/g' config.conf: заменить все вхождения localhost на IP и вывести результат в терминал.
  • sed -i 's/old/new/g' file.txt: флаг -i (in-place) вносит изменения прямо в файл. Это опасно, поэтому лучше сначала тестировать без него.
  • sed -n '5,10p' file.txt: напечатать только строки с 5 по 10.
  • Awk: мощный обработчик колонок

    Awk воспринимает строку как набор полей (колонок). По умолчанию разделитель — пробел или табуляция.
  • awk '{print 3}' file.txt: напечатать первую и третью колонку.
  • last | awk '{print 3 > 1000) print 3) больше 1000.
  • Переменные окружения и настройки Shell

    Когда вы вводите python, система не ищет этот файл по всему диску. Она заглядывает в переменную окружения $PATH.

    Переменные окружения (Environment Variables) — это глобальные настройки, доступные процессам.

  • PATH: список директорий, где лежат исполняемые файлы.
  • HOME: путь к домашней директории текущего пользователя.
  • USER: имя текущего пользователя.
  • LANG: настройки локали и кодировки.
  • Для DevOps критически важно понимать разницу между локальными переменными оболочки и переменными окружения.

    Если вы запускаете скрипт деплоя, которому нужен API-ключ, вы должны сделать export API_KEY=..., иначе скрипт его не увидит.

    Для автоматизации настройки терминала используются файлы инициализации:

  • ~/.bashrc: выполняется для каждой новой интерактивной оболочки. Здесь удобно прописывать алиасы (псевдонимы команд).
  • ~/.bash_profile или ~/.profile: выполняется один раз при входе в систему (login shell).
  • Пример полезного алиаса в .bashrc: alias ll='ls -alFh' — теперь команда ll будет выводить подробный список файлов с размерами в мегабайтах.

    Управление фоновыми задачами и мультиплексоры

    Иногда процесс выполняется долго (например, бэкап базы данных), и вам не хочется держать терминал открытым.

  • Символ &: запуск в фоне. cp -r /large_dir /backup &.
  • Ctrl+Z: приостановить текущий процесс и перевести его в фон (состояние Stopped).
  • bg: запустить приостановленный процесс в фоновом режиме.
  • fg: вернуть фоновый процесс на передний план.
  • jobs: список текущих фоновых задач в данной сессии.
  • Однако, если вы закроете SSH-сессию, все запущенные в ней процессы получат сигнал SIGHUP и завершатся. Чтобы этого избежать, используют nohup или, что гораздо профессиональнее, терминальные мультиплексоры.

    Tmux — стандарт индустрии. Он позволяет создавать сессии, внутри которых можно открывать множество окон и панелей. Главное преимущество: если связь с сервером прервется, сессия в tmux продолжит жить. Вы сможете подключиться снова и увидеть всё в том же состоянии.

  • tmux new -s my_session: создать сессию.
  • Ctrl+b, затем d: отсоединиться (detach).
  • tmux attach -t my_session: вернуться в сессию.
  • Диагностика системы: первые шаги при «пожаре»

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

  • Load Average (LA). Смотрим через команду top или uptime. Это среднее количество процессов, которые находятся в состоянии Running или Uninterruptible Sleep.
  • > Если LA за последние 1, 5 и 15 минут значительно превышает количество ядер процессора — система перегружена.
  • CPU Usage. В top или htop смотрим на процент использования. Важен параметр wa (I/O Wait) — если он высокий, значит, процессор простаивает, ожидая медленный диск.
  • Memory. Команда free -h. Не пугайтесь, если в колонке free мало места. Linux использует свободную память под кэш диска (buff/cache). Настоящий дефицит памяти виден, когда растет использование Swap (подкачки на диске).
  • Disk I/O. Команда iostat -xz 1 (из пакета sysstat). Показывает утилизацию дисков. Если %util близок к 100, диск — узкое место.
  • Network. Команда ss -tunlp. Показывает, какие порты открыты и какие процессы их слушают. Флаги: -t (TCP), -u (UDP), -n (числовые адреса), -l (listening), -p (process).
  • Практический кейс: поиск причины сбоя

    Представьте: веб-приложение выдает 500 ошибку. Вы заходите по SSH.

  • Проверяете статус сервиса: systemctl status nginx. Видите, что он запущен.
  • Смотрите логи: tail -f /var/log/nginx/error.log. Видите ошибку "Permission denied" при попытке записи в /var/www/html/cache.
  • Проверяете права: ls -ld /var/www/html/cache. Видите, что владельцем является root, а Nginx работает от пользователя www-data.
  • Исправляете: chown -R www-data:www-data /var/www/html/cache.
  • Этот простой пример показывает, как знание иерархии ФС, процессов и базовых команд позволяет локализовать проблему за пару минут.

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

    2. Управление пользователями, правами доступа и файловыми системами

    Управление пользователями, правами доступа и файловыми системами

    Представьте ситуацию: вы настроили веб-сервер, база данных запущена, но приложение выдает ошибку "Permission Denied" при попытке записать лог. Или, что еще хуже, злоумышленник, получивший доступ к непривилегированному сервису, внезапно обнаруживает, что может читать файлы в домашней директории администратора. В мире DevOps безопасность и стабильность системы начинаются не с брандмауэров, а с понимания того, как Linux разграничивает права доступа и как устроены механизмы хранения данных.

    Идентификация в Linux: UID, GID и файлы-источники

    В Linux всё, что делает система, делается от имени какого-то пользователя. Однако ядро не оперирует именами вроде root или devops_user. Для него существуют только числа — идентификаторы.

    Пользователи (UID) и Группы (GID)

    Каждый пользователь имеет уникальный UID (User ID). По традиции:

  • UID 0: Всегда принадлежит суперпользователю root. Это аккаунт с неограниченными правами, способный обойти любые проверки доступа на уровне ядра.
  • UID 1–999: Системные пользователи. Они нужны для работы сервисов (например, nginx, postgres, systemd-resolve). У них обычно нет пароля и возможности интерактивного входа.
  • UID 1000+: Обычные пользователи.
  • Группы (GID) позволяют объединять пользователей для коллективного доступа к ресурсам. Например, всех разработчиков можно добавить в группу developers, чтобы они могли редактировать файлы в определенной директории проекта.

    Критически важные файлы конфигурации

    Вся информация о пользователях хранится в текстовых файлах в директории /etc. DevOps-инженеру важно знать их структуру, так как автоматизация (например, через Ansible) часто взаимодействует с ними напрямую.

  • /etc/passwd: Содержит основную информацию. Формат строки:
  • username:x:UID:GID:comment:home_dir:shell Символ x во втором поле означает, что пароль зашифрован и хранится в другом файле.
  • /etc/shadow: Хранит хэши паролей и параметры их истечения. Доступ к этому файлу имеет только root.
  • /etc/group: Список групп и их участников.
  • Интересный нюанс: если вы удалите строку пользователя из /etc/passwd, но оставите его файлы на диске, система будет показывать владельца этих файлов как числовой UID. Это часто встречается при миграции данных между серверами, где UID пользователей не совпадают.

    Классическая модель прав доступа (UGO)

    Права доступа в Linux строятся на трех базовых операциях: чтение (read), запись (write) и выполнение (xecute). Эти права назначаются трем категориям субъектов:

  • user (владелец файла);
  • group (группа-владелец);
  • others (все остальные).
  • Битовая маска и числовое представление

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

  • r = 4
  • w = 2
  • x = 1
  • Суммируя их, мы получаем комбинации. Например, (полные права), а (чтение и выполнение).

    | Права | Число | Описание | | :--- | :--- | :--- | | rwx | 7 | Полный доступ | | rw- | 6 | Чтение и запись (обычно для конфигов) | | r-x | 5 | Чтение и запуск (для скриптов и директорий) | | r-- | 4 | Только чтение |

    Пример команды: chmod 644 config.yaml устанавливает права rw-r--r--. Это стандарт для конфигурационных файлов: владелец может править, остальные — только читать.

    Особенности прав для директорий

    Права на директории интерпретируются иначе, чем на файлы:

  • r (read): Позволяет просмотреть список файлов в директории (команда ls).
  • w (write): Позволяет создавать, удалять и переименовывать файлы внутри директории. Внимание: если у пользователя есть право w на директорию, он может удалить файл внутри неё, даже если у него нет прав на сам файл.
  • x (execute): Позволяет "войти" в директорию (команда cd) и обращаться к объектам внутри неё. Без бита x вы не сможете прочитать файл внутри, даже зная его точное имя и имея права r на сам файл.
  • Специальные биты: SUID, SGID и Sticky Bit

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

    SUID (Set User ID)

    Когда на исполняемом файле установлен SUID, он запускается с правами владельца файла, а не того, кто его запустил. Классический пример — утилита /usr/bin/passwd. Обычный пользователь должен иметь возможность сменить свой пароль, что требует записи в /etc/shadow. Но доступа к этому файлу у него нет. Благодаря SUID-биту, программа passwd запускается от имени root и успешно обновляет хэш. Обозначение: s вместо x в секции владельца (-rwsr-xr-x).

    SGID (Set Group ID)

  • Для файлов: аналогично SUID, процесс запускается с правами группы-владельца.
  • Для директорий: это критически важно в DevOps при организации общих папок. Любой файл, созданный в директории с SGID, автоматически наследует группу-владельца этой директории, а не основную группу пользователя.
  • Sticky Bit (Липкий бит)

    Используется для директорий, в которые могут писать многие (например, /tmp). Он гарантирует, что удалить или переименовать файл может только его владелец или root. Без этого бита любой пользователь мог бы удалить чужие временные файлы. Обозначение: t в конце строки прав (drwxrwxrwt).

    Списки контроля доступа (ACL)

    Классическая модель "Владелец-Группа-Остальные" слишком ограничена. Что если нужно дать право на чтение файла трем конкретным пользователям и двум разным группам? Здесь на помощь приходят ACL (Access Control Lists).

    Работа с ACL осуществляется командами getfacl и setfacl. Пример предоставления доступа пользователю ivan к лог-файлу: setfacl -m u:ivan:rw /var/log/app.log

    Теперь, если мы посмотрим на права через ls -l, мы увидим плюс в конце: -rw-rw-r--+. Это сигнал, что для файла настроены расширенные правила. В современной инфраструктуре ACL часто используются для тонкой настройки прав веб-серверов к файлам кэша или загрузок.

    Файловые системы: от диска до VFS

    В Linux "всё есть файл". Но чтобы эти "файлы" где-то жили, нам нужна файловая система (ФС). DevOps-инженеру важно понимать разницу между типами ФС, чтобы правильно выбирать их для баз данных, высоконагруженных очередей или контейнеров.

    Структура хранения: Иноды (Inodes)

    Каждый файл в Linux описывается структурой, называемой inode (индексный дескриптор). Инода содержит метаданные: размер, права, временные метки, ссылки на блоки данных на диске. Важно: имя файла не хранится в иноде. Имя — это просто запись в директории, которая связывает строку текста с номером иноды.

    Это объясняет два феномена:

  • Hard Links (Жесткие ссылки): Несколько имен указывают на одну и ту же иноду. Файл удалится с диска только тогда, когда счетчик ссылок в иноде станет равным нулю.
  • Исчерпание инод: Вы можете столкнуться с ошибкой "No space left on device", хотя команда df -h показывает свободные гигабайты. Это происходит, если на диске создано огромное количество мелких файлов (например, сессии PHP или мелкие кэши), и свободные иноды закончились. Проверить это можно командой df -i.
  • Основные типы файловых систем

  • Ext4: Стандарт де-факто для большинства дистрибутивов. Журналируемая, надежная, проверенная временем. Хороший выбор по умолчанию.
  • XFS: Отлично справляется с очень большими файлами и параллельными операциями ввода-вывода. Часто используется для баз данных и хранилищ медиа-контента.
  • Btrfs / ZFS: Файловые системы нового поколения с поддержкой снимков (snapshots), сжатия на лету и RAID на уровне ФС. В DevOps они ценны возможностью мгновенно откатить состояние системы.
  • OverlayFS: Фундамент Docker. Позволяет накладывать одну ФС на другую, объединяя их содержимое. Это позволяет держать базовый образ контейнера неизменным (read-only), записывая изменения в отдельный верхний слой.
  • Управление дисковым пространством и LVM

    В облачной инфраструктуре требования к объему дисков меняются динамически. Прямая работа с разделами диска (/dev/sda1, /dev/sda2) неудобна, так как их сложно расширять. Для решения этой проблемы используется LVM (Logical Volume Manager).

    LVM вводит три уровня абстракции:

  • PV (Physical Volume): Физические диски или разделы (например, /dev/sdb).
  • VG (Volume Group): Пул ресурсов, объединяющий несколько PV.
  • LV (Logical Volume): "Виртуальный" раздел, который нарезается из VG и на котором создается файловая система.
  • Если место на логическом томе закончилось, процедура в DevOps-стиле выглядит так:

  • Добавить новый диск в систему.
  • Инициализировать его как PV: pvcreate /dev/sdc.
  • Расширить существующую группу: vgextend my_vg /dev/sdc.
  • Увеличить логический том: lvextend -L +10G /dev/my_vg/my_lv.
  • Расширить файловую систему онлайн (без остановки сервиса): resize2fs /dev/my_vg/my_lv.
  • Монтирование и /etc/fstab

    Чтобы файловая система стала доступна, её нужно "примонтировать" в дерево директорий. Команда: mount /dev/mapper/my_vg-my_lv /mnt/data

    Чтобы монтирование сохранялось после перезагрузки, запись вносится в /etc/fstab. Современный стандарт — использовать UUID (Universally Unique Identifier) диска вместо имени устройства, так как имена вроде /dev/sdb могут измениться при переключении кабелей или в облачной среде.

    Пример строки в fstab: UUID=550e8400-e29b-41d4-a716-446655440000 /var/lib/docker ext4 defaults,noatime 0 2 Параметр noatime часто рекомендуется для DevOps-задач, так как он отключает обновление времени последнего доступа к файлу, что снижает нагрузку на диск при чтении.

    Дисковые квоты и ограничения

    В многопользовательских системах или на shared-хостингах важно, чтобы один сервис не "съел" всё место, забив диск логами или временными файлами.

  • User Quotas: Ограничивают место для конкретного пользователя.
  • Project Quotas (в XFS): Позволяют ограничивать размер конкретной директории, независимо от того, кто туда пишет. Это крайне полезно для изоляции данных приложений.
  • Практические сценарии и траблшутинг

    Кейс 1: "Призрак" удаленного файла

    Вы удалили огромный лог-файл командой rm, но df -h все еще показывает, что диск забит на 100%. Причина: Файл открыт каким-то процессом (например, Nginx). В Linux файл окончательно удаляется только тогда, когда закрыт последний дескриптор. Решение: Найти процесс через lsof | grep deleted и перезапустить его или очистить файл через перенаправление: > /path/to/file.

    Кейс 2: Ошибка "Read-only file system"

    Файловая система внезапно перешла в режим "только чтение". Причина: Обычно это защитная реакция ядра на ошибки ввода-вывода (I/O errors), сигнализирующая о деградации диска или проблемах с файловой системой. Диагностика: Проверить dmesg | tail. Для исправления может потребоваться fsck на отмонтированной системе.

    Кейс 3: Проблема с umask

    Вы создаете файл, и у него права 640, а вы ожидали 644. Причина: Значение umask (user mask). Это шаблон, который "вычитает" права при создании новых объектов. Если umask равен 027, то новые файлы будут иметь права . Настройка umask в профиле пользователя — важный шаг в обеспечении безопасности инфраструктуры.

    Понимание того, как Linux управляет пользователями и данными, отделяет системного администратора от DevOps-инженера. В автоматизации через Terraform или Ansible вы постоянно будете сталкиваться с необходимостью прокинуть правильный UID внутрь контейнера или настроить автоматическое расширение LVM-томов в облаке. Эти базовые знания — фундамент, на котором строится надежность распределенных систем.

    3. Сетевые технологии в Linux для DevOps-инженера

    Сетевые технологии в Linux для DevOps-инженера

    Представьте ситуацию: вы развернули приложение в Docker-контейнере, база данных запущена на соседнем сервере, а балансировщик нагрузки упорно выдает 502 Bad Gateway. Пинги идут, порты открыты, но пакеты словно исчезают в «черной дыре» виртуальных интерфейсов. Для Junior DevOps-инженера умение не просто прописать IP-адрес, а понимать путь пакета от сетевой карты до сокета приложения — это барьер, отделяющий «копипастера конфигов» от специалиста, способного траблшутить инфраструктуру в критических условиях. В Linux сеть — это не магия, а строго детерминированный конвейер обработки данных в ядре.

    Сетевой стек Linux и модель OSI через призму практики

    Хотя классическая семиуровневая модель OSI изучается в вузах, в повседневной работе DevOps-инженера фокус смещен на стек TCP/IP. Однако понимание уровней (Layers) критически важно для диагностики. Если у вас «отвалился» L2 (канальный уровень), бесполезно настраивать маршрутизацию на L3.

    Физический и канальный уровни (L1–L2)

    На этом этапе Linux взаимодействует с сетевым интерфейсом (NIC). Для системы неважно, физическая это карта или виртуальный мост (bridge) в Docker. Ключевой идентификатор здесь — MAC-адрес. В Linux мы видим эти интерфейсы через команду ip link.

    Особое внимание стоит уделить понятию MTU (Maximum Transmission Unit). По умолчанию это 1500 байт. Если пакет вместе с заголовками превышает этот размер, начинается фрагментация, которая резко снижает производительность. В облачных сетях (например, при использовании VXLAN или других туннелей) MTU часто приходится уменьшать до 1450 или ниже, чтобы оставить место для инкапсуляции.

    Сетевой уровень (L3): IP и маршрутизация

    Здесь пакеты получают IP-адреса и решают, куда идти дальше. В Linux за это отвечает таблица маршрутизации. Важно понимать разницу между «публичным» IP и «серым» (RFC 1918). DevOps-инженер постоянно сталкивается с пересечением подсетей в VPN-туннелях или Docker-сетях.

    Транспортный уровень (L4): TCP vs UDP

    Это уровень портов. TCP гарантирует доставку и порядок, UDP — скорость. Большинство проблем с «зависшими» соединениями связаны с параметрами TCP, такими как Keepalive или Time Out. На этом уровне работает балансировка нагрузки (L4 Load Balancing), которая просто перенаправляет пакеты на основе IP и порта, не заглядывая внутрь данных.

    Анатомия сетевого интерфейса и управление через iproute2

    Забудьте про ifconfig. Этот инструмент считается устаревшим (deprecated) уже более десяти лет. Современный стандарт — пакет iproute2. Его главная команда ip — это швейцарский нож, работающий напрямую с объектами ядра через протокол netlink.

    Работа с адресами и ссылками

    Команда ip addr show (или кратко ip a) показывает не только IP, но и состояние интерфейса. Обратите внимание на флаги:
  • UP: интерфейс включен на программном уровне.
  • LOWER_UP: есть физический сигнал (линк).
  • LOOPBACK: интерфейс lo, необходимый для локальных соединений внутри хоста.
  • Если вы видите UP, но не видите LOWER_UP, проблема в кабеле, патч-панели или настройках виртуального свитча в гипервизоре.

    Таблица маршрутизации и Default Gateway

    Маршрутизация в Linux определяет, через какой интерфейс отправить пакет. Проверить это можно командой ip route. Типичный вывод содержит строку вида: default via 192.168.1.1 dev eth0 proto dhcp metric 100

    Это означает, что любой трафик, для которого нет специфического маршрута, уйдет на шлюз 192.168.1.1 через устройство eth0. В сложных инфраструктурах (например, при наличии нескольких провайдеров или VPN) используется Policy Based Routing (PBR), где маршрут выбирается не только по адресу назначения, но и по адресу источника или метке пакета.

    Разрешение имен: DNS от /etc/hosts до systemd-resolved

    DNS — самая частая причина сбоев в распределенных системах. В Linux процесс разрешения имен (resolution) проходит через библиотеку glibc и настраивается в файле /etc/nsswitch.conf.

  • Файл /etc/hosts: Статический список соответствий. Имеет приоритет по умолчанию. Полезен для локальных тестов, но опасен в продакшене из-за сложности синхронизации.
  • Файл /etc/resolv.conf: Здесь указаны IP-адреса DNS-серверов.
  • systemd-resolved: Современный демон, который кэширует запросы. Если вы видите в resolv.conf адрес 127.0.0.53, значит, работает именно он.
  • Для отладки DNS забудьте про nslookup. Используйте dig. Она показывает полную цепочку ответов, включая TTL (Time To Live) записи и флаги авторитетности. Например: dig @8.8.8.8 google.com — запрос напрямую к серверу Google, минуя локальный кэш.

    Межсетевой экран и фильтрация: Netfilter и iptables

    Netfilter — это подсистема ядра Linux, которая позволяет перехватывать и манипулировать сетевыми пакетами. iptables (и его современный преемник nftables) — это интерфейс управления этими правилами.

    Таблицы и цепочки

    В iptables пакет проходит через цепочки (chains), сгруппированные в таблицы:
  • Filter: основная таблица для блокировки/разрешения трафика (INPUT, OUTPUT, FORWARD).
  • NAT: изменение адресов (PREROUTING, POSTROUTING).
  • Mangle: изменение заголовков пакетов (например, TTL или TOS).
  • Для DevOps-инженера критически важно понимать цепочку FORWARD. Именно через нее проходит трафик Docker-контейнеров, если они обращаются к внешней сети или друг к другу через мост. Если в sysctl параметр net.ipv4.ip_forward установлен в , никакая маршрутизация между контейнерами работать не будет.

    Механизм NAT (Network Address Translation)

    NAT — это то, что позволяет тысячам контейнеров с «серыми» IP выходить в интернет через один публичный адрес хоста.
  • SNAT (Source NAT): замена адреса источника. Используется при выходе вовне. Частный случай — Masquerade, когда адрес источника подменяется на динамический IP интерфейса.
  • DNAT (Destination NAT): замена адреса назначения. Так работает проброс портов (Port Forwarding). Когда вы делаете docker run -p 8080:80, Docker создает правило DNAT в таблице NAT, перенаправляющее трафик с порта 8080 хоста на порт 80 внутри контейнера.
  • Виртуализация сети: Bridge, VETH и Tun/Tap

    В мире DevOps мы редко работаем с «чистым» железом. Сеть в Linux сегодня — это конструктор из виртуальных сущностей.

    Linux Bridge

    Это программный аналог сетевого свитча. Он объединяет несколько интерфейсов в одну L2-сеть. Docker по умолчанию создает мост docker0. Все контейнеры, подключенные к нему, могут общаться друг с другом по MAC-адресам, как если бы они были воткнуты в один физический коммутатор.

    VETH-пары (Virtual Ethernet)

    Это «виртуальный патч-корд». VETH всегда создаются парой: пакет, вошедший в один конец, мгновенно выходит из другого. Один конец пары помещается внутрь сетевого пространства имен (Network Namespace) контейнера, а другой — «втыкается» в мост docker0 на хосте. Это база изоляции сети в контейнеризации.

    TUN/TAP интерфейсы

  • TAP работает на L2 (Ethernet кадры).
  • TUN работает на L3 (IP пакеты).
  • Используются преимущественно для создания VPN (OpenVPN, WireGuard). Программа-клиент читает пакеты из TUN-устройства, шифрует их и отправляет через обычную сеть.

    Диагностика и мониторинг сетевых соединений

    Когда «ничего не работает», DevOps-инженер использует триаду инструментов: ss, tcpdump и mtr.

    Утилита ss (Socket Statistics)

    Пришла на смену netstat. Позволяет увидеть, какие порты открыты и в каком состоянии находятся соединения. Пример: ss -tunlp
  • -t: TCP
  • -u: UDP
  • -n: показывать цифры вместо имен сервисов
  • -l: только слушающие сокеты
  • -p: показать процесс (PID), который занял порт
  • Состояние SYN-RECV в выводе ss может сигнализировать о SYN-flood атаке или проблемах с трехсторонним рукопожатием (handshake).

    tcpdump: «рентген» для трафика

    Если пакеты уходят, но ответа нет, нужно смотреть в «сырой» трафик. tcpdump позволяет перехватывать пакеты на конкретном интерфейсе. Пример: tcpdump -i eth0 port 80 -vvv -nn Это покажет всё содержимое HTTP-пакетов (без шифрования). Для анализа HTTPS-трафика tcpdump поможет подтвердить сам факт установления TLS-сессии.

    mtr (My Traceroute)

    Комбинирует ping и traceroute. Она незаменима, когда нужно понять, на каком узле в интернете или внутренней сети провайдера начинаются потери пакетов. В отличие от обычного traceroute, mtr собирает статистику в реальном времени, позволяя увидеть плавающие задержки (jitter).

    Тонкая настройка сетевого стека через sysctl

    Ядро Linux имеет сотни параметров, влияющих на сеть, доступных через /proc/sys/net/ или утилиту sysctl. Для высоконагруженных систем (Highload) стандартные значения часто оказываются слишком консервативными.

    Очереди и буферы

    Когда сервер получает тысячи запросов в секунду, сетевая карта может не успевать передавать их ядру, а ядро — приложению.
  • net.core.netdev_max_backlog: размер очереди пакетов, ожидающих обработки ядром.
  • net.ipv4.tcp_max_syn_backlog: количество «полуоткрытых» соединений. Если очередь заполнится, новые пользователи не смогут подключиться.
  • Борьба с нехваткой портов (Ephemeral Ports)

    При активной работе прокси-серверов (например, Nginx к Upstream) могут закончиться свободные порты для исходящих соединений.
  • net.ipv4.ip_local_port_range: диапазон портов (обычно 32768–60999). Его можно расширить.
  • net.ipv4.tcp_tw_reuse: позволяет повторно использовать сокеты, находящиеся в состоянии TIME_WAIT.
  • Практический кейс: Отладка связи между контейнерами

    Рассмотрим типичную задачу. У нас есть контейнер с приложением и контейнер с базой данных. Приложение пишет: Connection refused.

  • Проверка L3: Пингуем IP базы из контейнера приложения. Если пинг идет — уровень IP работает.
  • Проверка L4: Используем nc -zv <IP_базы> 5432. Если Connection refused, значит, порт закрыт.
  • Проверка слушателя: Заходим на хост (или в контейнер базы) и проверяем ss -tunlp | grep 5432. Если база слушает только на 127.0.0.1, она не примет соединения извне. Нужно менять listen_addresses на * или конкретный внутренний IP.
  • Проверка Firewall: Смотрим iptables -L -n -v. Docker активно манипулирует правилами, и иногда ручные настройки или сторонние утилиты (типа ufw или firewalld) могут блокировать цепочку DOCKER-USER.
  • Современные тренды: eBPF и Service Mesh

    Мир не стоит на месте, и классические iptables при огромном количестве правил начинают тормозить (так как это линейный список). На смену приходят технологии:

  • eBPF (Extended Berkeley Packet Filter): позволяет запускать небольшие программы внутри ядра прямо в момент прохождения пакета. Это основа для сверхбыстрых сетевых плагинов в Kubernetes (Cilium).
  • Service Mesh (Istio, Linkerd): переносит логику управления трафиком (ретранваи, тайм-ауты, шифрование) с уровня ядра на уровень Sidecar-контейнеров, работающих на L7 (прикладном уровне).
  • Для Junior DevOps важно понимать, что за всеми этими сложными абстракциями всё равно лежат базовые принципы: IP-адреса, маршруты, таблицы NAT и дескрипторы сокетов. Освоив фундамент Linux-сети, вы сможете разобраться в любой облачной технологии, так как они лишь масштабируют эти базовые кирпичики.

    Завершая погружение в сети, помните: любая сетевая проблема в Linux — это либо отсутствие маршрута, либо запрещающее правило в Firewall, либо отсутствие процесса, слушающего сокет. Системный подход к диагностике (снизу вверх по модели OSI) позволяет найти причину сбоя за считанные минуты, не гадая на конфигурационных файлах.