Sysops и Linux: администрирование, Ansible, изоляция

Шестой урок раздела. Под всеми абстракциями (Kubernetes, serverless, managed-базами) лежит Linux. Когда что-то ломается по-настоящему, чинить приходится на этом уровне: процессы, журналы, права, сеть. Этот урок про системное администрирование снизу вверх, про автоматизацию через Ansible, про устройство CI-раннеров и, главное, про лестницу изоляции контейнеров: что именно отделяет один контейнер от другого и почему это не настоящая виртуальная машина.

Идея: всё это файл, и всё это процесс

Две модели Unix, из которых выводится почти всё администрирование.

1. Всё это файл. Устройства, сокеты, информация о процессах в /proc, всё доступно через единый файловый интерфейс. Поэтому одни и те же утилиты (cat, grep, find) работают и с логами, и с состоянием системы.
2. Всё это процесс с правами. У каждого процесса есть владелец, окружение, открытые файлы и сигналы, которыми им управляют. SIGTERM просит завершиться по-хорошему, SIGKILL убивает насмерть.

Современным Linux дирижирует systemd: сервисы описываются unit-файлами, systemctl ими управляет, а логи читаются через journalctl. Первый рефлекс при разборе проблемы на сервере это journalctl -u <сервис> -f плюс инструменты исследования из прошлого раздела (rg, jq, awk) для разбора этих логов.

Ansible: идемпотентная настройка

Настраивать серверы руками не масштабируется и не воспроизводится. Ansible описывает желаемое состояние серверов в playbook и приводит их к нему по SSH, без агента на стороне сервера.

- hosts: web
  become: true
  tasks:
    - name: установить nginx
      apt: { name: nginx, state: present }
    - name: положить конфиг
      template: { src: nginx.conf.j2, dest: /etc/nginx/nginx.conf }
      notify: reload nginx
  handlers:
    - name: reload nginx
      service: { name: nginx, state: reloaded }

Ключевое свойство, ради которого всё затевается, это идемпотентность: повторный прогон ничего не меняет, если состояние уже правильное. Ansible перед каждым шагом сверяет факт и действует, только если есть расхождение. Поэтому playbook можно гонять сколько угодно: это не скрипт, который слепо выполняет команды, а описание состояния, как Terraform, но для содержимого сервера. handler (например reload) срабатывает только если что-то реально поменялось.

CI-раннеры изнутри

Полезно понимать, где именно исполняется твой CI, потому что от этого зависит безопасность. Раннер это машина или контейнер, который клонирует репозиторий и выполняет шаги. Два момента, на которых спотыкаются:

• Cache против artifacts: cache это ускорение (зависимости), его не жалко потерять; artifacts это результат, который надо сохранить или передать дальше.
• Безопасность untrusted PR: пайплайн на PR от чужого форка не должен иметь доступ к секретам, иначе любой пришлёт PR, ворующий токены. Современный подход к секретам в CI это OIDC: короткоживущий токен вместо вечного ключа, плюс принцип наименьших привилегий для каждого джоба.