DevOps и Linux: вопросы на собеседовании

Образ (image) — неизменяемый шаблон: файловая система приложения и метаданные (команда запуска, переменные, порты). Контейнер — запущенный экземпляр образа с собственным тонким слоем для записи. Аналогия: образ — класс, контейнер — объект.

Слои. Каждая инструкция Dockerfile, меняющая файловую систему (RUN, COPY, ADD), создаёт слой. Слои неизменяемы, кешируются и переиспользуются между образами. Контейнер добавляет сверху слой для записи; при удалении контейнера он пропадает.

Как это влияет на Dockerfile:

FROM node:24-slim
WORKDIR /app
COPY package*.json ./          # сначала только зависимости
RUN npm ci --omit=dev          # слой кешируется, пока зависимости не менялись
COPY . .                       # код меняется часто — копируем последним
USER node                      # не запускаем от root
CMD ["node", "server.js"]

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

Ещё практики: минимальный базовый образ (slim, alpine, distroless), многоступенчатая сборка — компилятор в первой стадии, в финальный образ только артефакт; .dockerignore; никаких секретов в образе — они остаются в слоях навсегда, даже если удалить файл следующей инструкцией.

Контейнер не виртуальная машина: он использует ядро хоста и изолируется механизмами ядра Linux — namespaces (что процесс видит) и cgroups (сколько ресурсов может потребить).

Контейнер эфемерен — всё, что записано в его файловую систему, пропадёт при пересоздании. Для постоянных данных:

• тома (volumes) — управляются Docker, хранятся в его области. Правильный выбор для баз данных;
• bind mount — директория хоста монтируется в контейнер. Удобно для разработки и конфигов;
• tmpfs — в памяти, для временных данных.

Сети. Контейнеры в одной пользовательской сети обращаются друг к другу по имени сервиса — встроенный DNS Docker. Порт наружу публикуется явно (-p 8080:80), и публиковать стоит только то, что действительно должно быть доступно извне — базу данных наружу не открывают.

Docker Compose описывает многоконтейнерное приложение в одном YAML-файле:

services:
  app:
    build: .
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:17
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "app"]
volumes:
  pgdata:

docker compose up -d поднимает всё одной командой. depends_on без healthcheck гарантирует только порядок запуска, а не готовность — частая причина «приложение не может подключиться к базе при старте».

Compose хорош для разработки и небольших продакшен-инсталляций на одном сервере; для кластера — Kubernetes.

Kubernetes — оркестратор контейнеров: вы описываете желаемое состояние, а контроллеры постоянно приводят к нему реальное.

• Pod — минимальная единица развёртывания: один или несколько контейнеров с общей сетью и томами. Pod эфемерен — его могут пересоздать на другом узле с другим IP. Вручную поды почти не создают.
• ReplicaSet — поддерживает заданное число одинаковых подов.
• Deployment — управляет ReplicaSet и обеспечивает плавное обновление (rolling update) и откат. Основной способ запускать stateless-приложения.
• StatefulSet — для приложений с состоянием (базы данных): стабильные имена и собственные тома у каждого пода.
• Service — постоянный адрес и балансировка для группы подов, выбранных по меткам. Типы: ClusterIP (внутри кластера), NodePort, LoadBalancer.
• Ingress — маршрутизация HTTP(S) снаружи в сервисы по домену и пути, TLS. Работает через Ingress-контроллер (nginx, Traefik).
• ConfigMap и Secret — конфигурация и секреты отдельно от образа.

Пробы, о которых спросят обязательно:

• liveness — жив ли контейнер; при провале его перезапустят;
• readiness — готов ли принимать трафик; при провале под исключается из Service;
• startup — для долгого старта.

Задавайте requests и limits по процессору и памяти: без них планировщик не может правильно размещать поды, а один процесс способен съесть ресурсы всего узла.

Просмотр процессов: ps aux, top или htop, pgrep nginx, pstree. У процесса есть PID, родитель (PPID), владелец, состояние.

Сигналы — асинхронные уведомления процессу:

• SIGTERM (15) — вежливая просьба завершиться. Отправляется kill по умолчанию. Процесс может перехватить сигнал и корректно завершить работу: дообработать запросы, закрыть соединения, сохранить данные.
• SIGKILL (9) — немедленное уничтожение ядром. Перехватить нельзя, очистка не выполняется: возможны незавершённые записи, «зависшие» блокировки, повреждённые временные файлы. Используется, только если процесс не реагирует на SIGTERM.
• SIGINT (2) — Ctrl+C в терминале.
• SIGHUP (1) — многие демоны перечитывают конфигурацию (nginx -s reload работает похожим образом).

Правильный порядок: SIGTERM → подождать → SIGKILL. Так делают Docker (docker stop ждёт 10 секунд) и Kubernetes (terminationGracePeriodSeconds). Поэтому приложение должно обрабатывать SIGTERM — иначе при каждом деплое обрываются запросы.

Зомби-процесс — завершился, но родитель не прочитал его код возврата. Ресурсов почти не занимает, но засоряет таблицу процессов. Лечится исправлением родителя. Отсюда проблема PID 1 в контейнерах: процесс с PID 1 должен собирать зомби и пробрасывать сигналы — для этого используют tini или флаг docker run --init.

systemd — менеджер служб: systemctl status|start|restart|enable nginx, логи — journalctl -u nginx -f.

У каждого файла есть владелец, группа и права для трёх категорий: владелец (u), группа (g), остальные (o). Права: r — чтение (4), w — запись (2), x — выполнение (1).

chmod 755 script.sh → rwxr-xr-x:

• владелец: 4+2+1 = 7 — всё;
• группа: 4+1 = 5 — чтение и выполнение;
• остальные: 5 — чтение и выполнение.

Типичные значения: 644 для файлов (rw-r--r--), 755 для каталогов и скриптов, 600 для приватных ключей и файлов с секретами (SSH откажется работать с ключом, у которого права шире).

Для каталогов права означают другое: r — посмотреть список файлов, w — создавать и удалять файлы внутри, x — войти в каталог и обращаться к файлам.

Команды: ls -l — посмотреть; chmod u+x file — символьная запись; chown user:group file — сменить владельца; umask — права по умолчанию для новых файлов.

Особые биты: SUID — файл выполняется с правами владельца (так работает passwd, и это классический вектор повышения привилегий); sticky bit на /tmp — удалить файл может только его владелец.

Принцип наименьших привилегий: сервисы запускаются от отдельных пользователей без прав root, chmod 777 «чтобы заработало» — признак проблемы, а не решение.