Экзамен

Git

1. Git. Индексирование. Сущность, команды, примеры использования

Сущность: Индексирование (staging) — это промежуточный этап в Git между рабочей директорией (working directory) и историей коммитов (repository). Индекс (staging area) представляет собой файл, в котором сохраняется информация о том, какие изменения пойдут в следующий коммит. Это позволяет логически разделять изменения: разработчик может изменить 10 файлов, но проиндексировать и закоммитить только 2 из них, оставив остальные для другого коммита.

Основные команды:

• git add <файл> — добавляет конкретный файл в индекс.
• git add . — индексирует все изменения в текущей директории и вложенных папках.
• git add -p (patch) — интерактивное индексирование: позволяет просмотреть изменения кусками (hunks) и выбрать, какие строки/блоки кода добавить в индекс, а какие пропустить.
• git rm --cached <файл> — удаляет файл из индекса, но оставляет его в рабочей директории (полезно, если случайно добавили файл, который должен быть в .gitignore).
• git restore --staged <файл> (в новых версиях Git) — убирает файл из индекса, аналог git reset HEAD <файл>.

Пример использования: Разработчик поправил баг в main.py (строки 10-15) и добавил новую фичу в том же файле (строки 50-60). С помощью git add -p main.py он выбирает только строки 10-15, делает коммит с сообщением “Fix bug”, а затем индексирует оставшуюся часть и делает второй коммит “Add feature”.

2. Git. Коммит. Сущность, команды, примеры использования

Сущность: Коммит (commit) — это зафиксированный снимок (snapshot) состояния проекта в определенный момент времени. Каждый коммит содержит:

1. Ссылку на снимок файловой системы (дерево).
2. Метаданные: имя автора, email, дата создания.
3. Сообщение коммита (commit message), описывающее изменения.
4. Ссылку на родительский коммит (или коммиты, если это слияние). Git идентифицирует коммиты с помощью криптографического хеша SHA-1 (40 символов). История в Git иммутабельна — изменения коммита по факту создают новый коммит с новым хешем.

Основные команды:

• git commit — открывает текстовый редактор по умолчанию для ввода многострочного сообщения коммита.
• git commit -m "Сообщение" — создает коммит с переданным коротким сообщением (инлайн).
• git commit -a -m "Сообщение" — флаг -a (all) автоматически индексирует все уже отслеживаемые файлы (измененные и удаленные), пропуская этап git add. Новые (untracked) файлы при этом не добавляются.
• git commit --amend — позволяет изменить последний коммит. Если в индекс добавлены новые изменения, они вольются в предыдущий коммит. Также позволяет изменить сообщение последнего коммита. Важно: меняет хеш коммита, нельзя использовать для коммитов, уже отправленных в общий удаленный репозиторий (без force push).

Пример использования: Вы сделали коммит git commit -m "Fix login button", но поняли, что забыли добавить один измененный файл стилей. Вы пишете git add styles.css, а затем git commit --amend --no-edit. Файл styles.css добавляется в предыдущий коммит без изменения его сообщения.

3. Git. Удалённые репозитории. Принцип работы и команды

Принцип работы: Git — распределенная система контроля версий (DVCS). Удаленный репозиторий (remote) — это версия проекта, хранящаяся в интернете или на сервере (например, GitHub, GitLab, Bitbucket). Он служит единой точкой синхронизации для работы команды. Локальный репозиторий содержит полную копию удаленного, что позволяет работать офлайн, а затем синхронизировать ветки и коммиты. Связь осуществляется по протоколам HTTPS или SSH.

Основные команды:

• git remote add <имя> <URL> — связывает локальный репозиторий с удаленным. Стандартное имя по умолчанию — origin.
• git remote -v — показывает список настроенных удаленных репозиториев и их URL для fetch (чтение) и push (запись).
• git fetch <remote> — скачивает новые коммиты, файлы и ветки из удаленного репозитория в локальный, но не сливает их с вашей текущей рабочей веткой (безопасная операция). Обновляет скрытые ветки, например origin/main.
• git pull <remote> <branch> — скачивает изменения (fetch) и сразу интегрирует (merge/rebase) их в текущую локальную ветку.
• git push <remote> <branch> — отправляет локальные коммиты на удаленный сервер. Флаг -u (set-upstream) устанавливает связь между локальной и удаленной веткой для последующих команд git push/pull без аргументов.
• git remote rm <имя> — удаляет привязку к удаленному репозиторию.

4. Git. Авторизация. SSH-ключ. Понятие, создание, принцип использования

Понятие: SSH (Secure Shell) ключ — это криптографический механизм авторизации на основе асимметричного шифрования, используемый для безопасного подключения к удаленным Git-репозиториям (GitHub, GitLab) без постоянного ввода логина и пароля (или токена). Состоит из двух частей:

1. Приватный ключ (например, id_ed25519) — хранится локально на компьютере разработчика в строгом секрете.
2. Публичный ключ (например, id_ed25519.pub) — передается на сервер Git-хостинга.

Принцип использования: Когда Git инициирует push или fetch по SSH (URL вида git@github.com:user/repo.git), сервер шифрует проверочное сообщение публичным ключом пользователя и отправляет локальной машине. Локальный SSH-клиент расшифровывает сообщение приватным ключом и отправляет обратно. Если ответы совпадают, авторизация успешна.

Создание и настройка:

1. Генерация ключа (рекомендуется алгоритм Ed25519 как более быстрый и надежный, чем RSA): ssh-keygen -t ed25519 -C "your_email@example.com"
2. При генерации можно задать passphrase (пароль на сам ключ) для дополнительной защиты.
3. Запуск ssh-agent (менеджера ключей) и добавление ключа в агента: eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
4. Вывод публичного ключа для копирования в настройки профиля на GitHub/GitLab: cat ~/.ssh/id_ed25519.pub

5. Git. Ветки. Принципы работы и основные команды

Принципы работы: Ветка (branch) в Git — это не физическая копия файлов (как в SVN), а легковесный подвижный указатель (pointer) на один конкретный коммит. При создании нового коммита указатель текущей ветки автоматически сдвигается вперед на этот новый коммит. Ветки позволяют вести параллельную, изолированную разработку (фичи, фиксы, эксперименты) не затрагивая основной стабильный код (обычно main или master).

Основные команды:

• git branch — выводит список всех локальных веток. Звездочкой * помечается текущая ветка.
• git branch <имя> — создает новую ветку, указывающую на текущий коммит, но не переключает на нее.
• git checkout <имя> или git switch <имя> — переключает рабочую директорию на указанную ветку (меняет указатель HEAD).
• git checkout -b <имя> или git switch -c <имя> — создает ветку и сразу переключается на нее.
• git branch -d <имя> — безопасно удаляет ветку (Git не даст удалить, если изменения не были слиты).
• git branch -D <имя> — принудительное удаление ветки (даже если есть неслитые изменения).
• git branch -m <старое_имя> <новое_имя> — переименование ветки.

6. Git. Слияние веток. Конфликты. Понятие и разрешение

Понятие: Конфликт слияния (Merge Conflict) возникает, когда Git не может автоматически объединить изменения при выполнении merge, rebase или cherry-pick. Это происходит в двух основных случаях:

1. В разных ветках были изменены одни и те же строки одного и того же файла.
2. В одной ветке файл был изменен, а в другой — удален. Git останавливает процесс слияния, помечает конфликтные файлы и просит пользователя разрешить их вручную.

Разрешение: При открытии конфликтного файла пользователь видит специальные маркеры Git:

<<<<<<< HEAD
Код из текущей ветки
=======
Код из вливаемой ветки
>>>>>>> branch_name

Разработчик должен отредактировать файл, оставив нужный код (или написав новый компромиссный вариант), и удалить маркеры <<<<<<<, =======, >>>>>>>.

После ручного разрешения конфликта в файлах:

1. Индексируем исправленные файлы: git add <разрешенный_файл>.
2. Завершаем слияние: git commit (Git автоматически сформирует сообщение о разрешении конфликта). Если конфликт слишком сложен и процесс нужно прервать: git merge --abort (возвращает репозиторий в состояние до попытки слияния).

7. Git. Слияние веток. Принципы и основные команды

Принципы: Слияние (merge) объединяет историю двух веток. Git использует два основных алгоритма слияния:

1. Fast-forward (перемотка): Если ветка, в которую мы сливаем (например, main), не имела новых коммитов с момента отделения вливаемой ветки (feature), Git просто сдвигает указатель main вперед. Дополнительный коммит слияния не создается. История остается линейной.
2. 3-way merge (трехстороннее слияние): Если обе ветки разошлись в развитии (имеют уникальные коммиты), Git ищет их общего предка (merge base). На основе общего предка и двух концов веток создается новый merge commit, который имеет двух родителей.

Основные команды:

• git merge <имя_ветки> — сливает указанную ветку в текущую.
• git merge --no-ff <имя_ветки> — запрещает fast-forward. Заставляет Git всегда создавать явный merge commit. Это полезно для сохранения информации о том, что существовала feature-ветка, даже если fast-forward был возможен.
• git merge --squash <имя_ветки> — берет все изменения из указанной ветки, объединяет их в один набор изменений и помещает в индекс текущей ветки, не создавая merge-коммита и не перенося историю коммитов. Позволяет сделать один аккуратный коммит в main.

8. Git. GitFlow и GitHub Flow. Структура и принцип работы

GitFlow: Сложная, строгая модель ветвления, подходящая для проектов с четкими циклами релизов (например, desktop-приложения, enterprise-системы). Структура веток:

• master / main — содержит только production-ready код. Каждый коммит — это релиз с тегом версии.
• develop — основная ветка разработки. Сюда сливаются все фичи.
• feature/<name> — ветки для новых функций. Отпочковываются от develop и вливаются обратно в develop.
• release/<version> — ветка для подготовки релиза. Отпочковывается от develop. Здесь только фиксятся баги. После готовности вливается и в master (с тегом), и обратно в develop.
• hotfix/<name> — экстренные исправления на проде. Отпочковываются от master, вливаются и в master, и в develop.

GitHub Flow: Легковесная модель, ориентированная на Agile и Continuous Integration / Continuous Deployment (CI/CD). Идеальна для веб-разработки, где релизы происходят несколько раз в день. Принцип работы:

1. Существует только одна долгоживущая ветка — main (всегда стабильна, всегда готова к деплою).
2. Для любой задачи (фича, баг) создается новая ветка от main.
3. Разработчик делает коммиты и пушит их на сервер.
4. Открывается Pull Request (PR) для обсуждения кода (Code Review).
5. После аппрува и прохождения тестов (CI), ветка вливается в main.
6. Код из main сразу деплоится на production.

9. Git. HEAD. Понятие и пример использования для перемещения на другой коммит

Понятие: HEAD — это специальный скрытый указатель в Git, который всегда указывает на текущий коммит, на основе которого развернута рабочая директория. В нормальном состоянии HEAD указывает не напрямую на коммит, а на локальную ветку (например, refs/heads/main), которая уже указывает на коммит.

Detached HEAD (оторванный HEAD): Если переключиться не на ветку, а напрямую на хеш коммита, тег или удаленную ветку (например, origin/main), HEAD отрывается от ветки и указывает напрямую на коммит. В этом состоянии можно экспериментировать, но новые коммиты “повиснут в воздухе” и могут быть удалены сборщиком мусора, если не создать для них новую ветку.

Пример использования (перемещение по истории):

• git checkout <hash> или git switch --detach <hash> — перемещает HEAD на конкретный коммит.
• Перемещение относительно текущего HEAD:
  • git checkout HEAD~1 (или HEAD^) — перемещает на 1 коммит назад (на родителя).
  • git checkout HEAD~3 — перемещает на 3 коммита назад по прямой линии предков.
• Использование в командах сброса: git reset --hard HEAD~2 (откатить текущую ветку и HEAD на 2 коммита назад, удалив изменения).

10. Git. Основные команды и их флаги. Push, pull, init, remote, clone

• git init — создает новый пустой локальный репозиторий (создает скрытую папку .git).
  • Флаг -b <имя>: Задает имя начальной ветки (например, git init -b main).
• git clone <url> — скачивает удаленный репозиторий, копирует всю историю, создает удаленные отслеживающие ветки и локальную рабочую ветку.
  • Флаг --depth 1: “Shallow clone”, скачивает только последний коммит, без истории (ускоряет клонирование больших репозиториев, полезно в CI/CD).
• git remote — управление ссылками на удаленные репозитории.
  • add <name> <url>: добавить удаленный репозиторий.
  • Флаг -v: выводит список привязанных репозиториев с URL-адресами.
• git pull — выполняет git fetch (скачивание изменений с сервера) с последующим git merge (слияние в локальную ветку).
  • Флаг --rebase: вместо слияния (merge) перебазирует (переносит) локальные коммиты поверх скачанных коммитов с сервера, сохраняя прямую линию истории.
• git push — отправляет локальные коммиты на удаленный сервер.
  • Флаг -u (--set-upstream): связывает локальную ветку с удаленной.
  • Флаг -f (--force): принудительно перезаписывает удаленную историю локальной (опасно для общих веток).

11. Git. Основные команды и их флаги. Stash, log, status, diff

• git stash — прячет (сохраняет во временное хранилище) незакоммиченные изменения из рабочей директории и индекса, очищая рабочую директорию.
  • git stash push -m "message": сохраняет stash с описанием.
  • git stash list: показывает список всех сохраненных stash.
  • git stash pop: применяет последний сохраненный stash и удаляет его из списка.
  • git stash apply: применяет stash, но оставляет его в списке.
• git log — выводит историю коммитов.
  • Флаг --oneline: компактный вывод (1 коммит = 1 строка: хеш и сообщение).
  • Флаг --graph: рисует ASCII-график ветвлений и слияний.
  • Флаг -n <число>: ограничивает вывод указанным числом последних коммитов.
• git status — показывает состояние рабочей директории и индекса (измененные, добавленные, неотслеживаемые файлы).
  • Флаг -s (--short): выводит статус в компактном виде (например, M для измененных, ?? для неотслеживаемых).
• git diff — показывает разницу в коде между коммитами, индексом и рабочей директорией.
  • Без флагов: показывает изменения в рабочей директории, которые еще не проиндексированы.
  • Флаг --staged (или --cached): показывает изменения, добавленные в индекс (то, что пойдет в коммит), по сравнению с последним коммитом.
  • git diff <hash1> <hash2>: разница между двумя коммитами.

12. Git. Основные команды и их флаги. Commit, add, reset, checkout, merge

• git add — добавляет файлы в индекс.
  • Флаг -p: интерактивное добавление по частям (hunks).
  • Флаг -u (--update): добавляет в индекс только изменения в уже отслеживаемых файлах (без новых untracked файлов).
• git commit — создает снимок индекса.
  • Флаг -m: передача сообщения коммита.
  • Флаг -a: автоматический add всех отслеживаемых файлов перед коммитом.
  • Флаг --amend: переписывает последний коммит.
• git reset — сбрасывает указатель HEAD на указанный коммит.
  • Флаг --soft: сдвигает HEAD, но оставляет все изменения из отмененных коммитов в индексе (staged). Полезно для squash’а коммитов.
  • Флаг --mixed (по умолчанию): сдвигает HEAD и очищает индекс, но оставляет файлы измененными в рабочей директории.
  • Флаг --hard: сдвигает HEAD и уничтожает все изменения в индексе и рабочей директории. Опасная операция.
• git checkout — перемещает HEAD или восстанавливает файлы.
  • Флаг -b: создать новую ветку и перейти на нее.
  • git checkout <file>: отменяет незакоммиченные изменения в файле, восстанавливая его из индекса.
• git merge — слияние веток.
  • Флаг --no-ff: принудительное создание merge commit.
  • Флаг --abort: отмена слияния при конфликте.

13. Git. Основные команды и их флаги. Checkout, rebase, branch, merge

• (Частично описаны выше, акцент на отличиях и новых командах)
• git checkout — (см. вопрос 12).
• git branch — управление ветками.
  • Флаг -a (--all): показывает и локальные, и удаленные ветки.
  • Флаг -m: переименование.
  • Флаг -d / -D: удаление (безопасное / принудительное).
• git merge — объединение историй путем создания нового объединяющего коммита (merge commit). История сохраняет параллельные линии.
• git rebase — перебазирование. В отличие от merge, rebase берет коммиты текущей ветки, “отрывает” их и по одному применяет поверх целевой ветки (меняя их хеши). История становится линейной и чистой.
  • Флаг -i (--interactive): мощный инструмент для перезаписи истории. Открывает редактор, где можно изменять порядок коммитов, объединять их (squash/fixup), изменять сообщения (reword) или удалять (drop).
  • Флаг --abort: отмена процесса перебазирования при конфликтах.
  • Флаг --continue: продолжение rebase после разрешения конфликта в конкретном коммите.

14. Git. История изменений. Просмотр, фильтрация и анализ

Просмотр и фильтрация (git log): Команда git log позволяет гибко фильтровать историю для поиска конкретных изменений.

• По автору: git log --author="Иван"
• По дате: git log --since="2023-01-01" --until="2023-12-31"
• По сообщению: git log --grep="Fix bug" (поиск по тексту коммит-месседжа).
• По коду: git log -S "function_name" (так называемый “pickaxe”, ищет коммиты, в которых добавилась или удалилась строка с указанным текстом).
• История конкретного файла: git log -- <путь_к_файлу>.

Анализ кода (git blame): Показывает, кто, когда и в каком коммите последним изменял каждую строку конкретного файла. Синтаксис: git blame <файл>. Можно ограничить строки: git blame -L 10,20 <файл>.

Поиск багов (git bisect): Мощнейший инструмент для поиска коммита, в котором была внесена ошибка, методом бинарного поиска.

1. git bisect start (запуск).
2. git bisect bad (текущий коммит помечен как сломанный).
3. git bisect good <hash> (указываем старый коммит, где бага точно не было). Git автоматически переключает HEAD на середину промежутка. Пользователь тестирует код и говорит git bisect good или git bisect bad. Процесс повторяется, логарифмически сужая область поиска, пока баг не будет найден.

15. Git. Отмена изменений. Команды reset, revert, checkout

В Git существует три принципиально разных подхода к отмене изменений:

4. git checkout / git restore (работа с рабочей директорией и файлами) Отменяет локальные незакоммиченные изменения в файлах. git checkout -- <файл> восстановит файл до состояния последнего коммита (или индекса). Изменения теряются навсегда.

5. git revert (безопасная отмена зафиксированных изменений) Создает новый коммит, который инвертирует (делает противоположными) изменения указанного коммита. Синтаксис: git revert <hash>. Это единственный безопасный способ отменить изменения, если коммит уже был отправлен (push) в общий удаленный репозиторий, так как история не переписывается, а добавляется новое исправление.

6. git reset (радикальное переписывание истории) Сдвигает указатель HEAD и текущую ветку назад по истории, “стирая” последние коммиты.

• git reset --hard HEAD~1 — полностью удалит последний коммит и все изменения в файлах.
• git reset --soft HEAD~1 — удалит коммит из истории, но оставит изменения в индексе (готовыми для нового коммита). Нельзя использовать reset для коммитов, с которыми уже работают другие разработчики.

16. Git. Игнорирование файлов. Файл .gitignore, синтаксис и примеры использования.

Сущность: Файл .gitignore указывает Git, какие неотслеживаемые (untracked) файлы и директории следует игнорировать (не показывать в git status и не индексировать при git add .). Обычно туда добавляют: бинарные файлы сборок, зависимости (node_modules), временные файлы IDE (.idea, .vscode), файлы с паролями и ключами (.env).

Синтаксис:

• Пустые строки игнорируются. Комментарии начинаются с #.
• Стандартные маски (globs): * (любое количество символов), ? (один символ).
• Обозначение директории: / на конце (например, build/ — игнорировать папку build).
• Расположение: /file.txt в начале шаблона указывает, что файл нужно игнорировать только в корне репозитория (а не src/file.txt).
• Глубокая вложенность: ** (например, src/**/*.log — все .log файлы в папке src и любых ее подпапках).
• Отрицание (исключение из игнора): ! (если файл игнорируется широкой маской, его можно вернуть).

Примеры:

# Игнорировать все файлы .log
*.log
 
# Но оставить track_me.log
!track_me.log
 
# Игнорировать папку node_modules в корне
/node_modules/
 
# Игнорировать любые файлы .class во всех папках
**/*.class

17. Git. Pull Request. Принцип работы

Принцип работы: Pull Request (PR) (в GitLab — Merge Request, MR) — это не команда Git, а механизм платформ хостинга кода (GitHub, Bitbucket, GitLab) для совместной работы, код-ревью и контроля качества перед слиянием веток.

Как это работает на практике:

1. Разработчик отводит локальную ветку (например, feature-auth) от main и делает в ней изменения.
2. Отправляет (push) ветку на удаленный сервер: git push origin feature-auth.
3. В веб-интерфейсе GitHub нажимает кнопку “Create Pull Request”, предлагая влить изменения из feature-auth в main.
4. Создается страница с разницей кода (diff). Разработчик описывает, что было сделано.
5. Code Review: Другие разработчики (ревьюеры) читают код, оставляют комментарии к конкретным строкам, просят исправить ошибки (Request Changes) или одобряют (Approve).
6. CI/CD: Автоматически запускаются пайплайны (линтеры, тесты, сборки). Платформа может заблокировать кнопку слияния, если тесты упали.
7. После аппрува и зеленых тестов PR сливается (Merge) в main (через merge commit, squash или rebase), а исходная ветка удаляется.

Docker

1. Docker. Понятие и принцип работы

Понятие: Docker — это платформа с открытым исходным кодом для разработки, доставки и запуска приложений с использованием виртуализации на уровне операционной системы, называемой контейнеризацией. Docker позволяет упаковать приложение со всем его окружением (библиотеками, зависимостями, конфигурационными файлами) в единый стандартизированный блок — контейнер.

Принцип работы: В отличие от аппаратной виртуализации (виртуальных машин, ВМ), где гипервизор эмулирует физическое железо и запускает полноценную гостевую ОС, Docker использует общее ядро хостовой операционной системы. Архитектура Docker (клиент-серверная):

1. Docker Daemon (dockerd): Фоновый процесс на хосте, который управляет объектами Docker (образами, контейнерами, сетями, томами).
2. Docker API: REST API, через которое программы взаимодействуют с демоном.
3. Docker CLI (docker): Командный интерфейс, через который пользователь отправляет команды демону.

На уровне ядра Linux изоляция достигается за счет:

• Namespaces (пространства имен): Изолируют ресурсы (процессы PID, сеть NET, точки монтирования MNT, пользователи USER). Контейнер видит только свое изолированное пространство.
• Cgroups (контрольные группы): Ограничивают использование физических ресурсов (CPU, оперативная память, дисковый ввод-вывод) для контейнера.

2. Docker. Образ. Понятие и основные команды

Понятие: Образ (Image) — это неизменяемый (read-only) шаблон, содержащий файловую систему, исходный код, библиотеки, зависимости, инструменты и инструкции, необходимые для запуска приложения. Образ является “чертежом” (классом в парадигме ООП), на основе которого создаются работающие контейнеры (объекты). Образы состоят из слоев.

Основные команды:

• docker pull <image>:<tag> — скачивает образ из удаленного реестра (по умолчанию Docker Hub). Например: docker pull ubuntu:20.04. Если тег не указан, скачивается latest.
• docker images (или docker image ls) — выводит список всех локально сохраненных образов, их теги, ID, дату создания и размер.
• docker rmi <image_id> (или docker image rm) — удаляет локальный образ. Нельзя удалить образ, если от него зависит существующий (даже остановленный) контейнер.
• docker build -t <name>:<tag> . — собирает новый образ на основе Dockerfile в текущей директории (.).
• docker push <image>:<tag> — отправляет локальный образ в удаленный реестр.

3. Docker. Контейнер. Понятие и основные команды

Понятие: Контейнер (Container) — это запущенный, выполняющийся экземпляр образа. Это изолированный процесс (или группа процессов) на хост-машине. Контейнер добавляет поверх неизменяемых слоев образа тонкий слой чтения-записи (Read-Write layer), в котором сохраняются все изменения, происходящие во время работы приложения.

Основные команды:

• docker run <image> — создает и запускает новый контейнер из указанного образа.
  • Флаг -d (detach): запускает контейнер в фоновом режиме.
  • Флаг --name <name>: задает удобочитаемое имя контейнеру.
  • Флаг --rm: автоматически удаляет контейнер после его остановки.
• docker ps — выводит список запущенных (активных) контейнеров.
• docker ps -a — выводит список вообще всех контейнеров, включая остановленные.
• docker stop <container> — корректно останавливает контейнер (отправляет SIGTERM, затем SIGKILL).
• docker start <container> — запускает ранее остановленный контейнер (с сохранением его R/W слоя).
• docker rm <container> — удаляет остановленный контейнер. (С флагом -f — принудительно убивает и удаляет работающий).
• docker logs <container> — выводит логи (stdout/stderr) контейнера (флаг -f — в реальном времени).

4. Dockerfile. Структура файла. Синтаксис

Структура: Dockerfile — это обычный текстовый файл без расширения, содержащий последовательность инструкций для автоматической сборки образа. Каждая инструкция (в большинстве случаев) создает новый слой в образе.

Основной синтаксис:

• FROM <image>:<tag> — базовая инструкция, с которой обязан начинаться любой Dockerfile. Указывает родительский образ (например, FROM python:3.9-slim).
• WORKDIR <path> — задает рабочую директорию внутри контейнера для всех последующих инструкций (RUN, CMD, ENTRYPOINT, COPY, ADD). Если директории нет, она создается.
• COPY <src> <dest> — копирует файлы или директории с хостовой машины (<src>) в файловую систему образа (<dest>). Рекомендуемый способ добавления кода.
• ADD <src> <dest> — аналог COPY, но умеет распаковывать локальные tar-архивы и скачивать файлы по URL.
• RUN <command> — выполняет команду оболочки во время сборки образа (например, RUN apt-get update && apt-get install -y git или RUN pip install -r requirements.txt). Создает новый слой.
• ENV <key>=<value> — задает переменные окружения, которые будут доступны и при сборке, и во время работы контейнера.
• EXPOSE <port> — документирует, какие порты контейнер прослушивает. Важно: инструкция не пробрасывает порты на хост автоматически, это лишь метаданные для разработчика.
• CMD ["executable", "param1"] — задает команду и аргументы по умолчанию, которые будут выполнены при запуске контейнера. Может быть переопределена.
• ENTRYPOINT ["executable", "param1"] — задает основной исполняемый файл контейнера, который сложно переопределить.

5. Docker. Сеть. Создание пользовательской сети

Сущность: По умолчанию Docker создает дефолтную сеть bridge. Контейнеры в этой сети могут общаться по IP-адресам, но не по именам. Для связи контейнеров по их именам (DNS resolution) необходимо создавать пользовательские сети (User-defined bridge networks). Внутри пользовательской сети встроенный DNS-сервер Docker автоматически разрешает имена контейнеров в их внутренние IP-адреса.

Создание и использование:

1. Создание сети: docker network create my_network (по умолчанию создается драйвер bridge).
2. Запуск контейнеров в созданной сети: docker run -d --name db --network my_network postgres docker run -d --name backend --network my_network my_app
3. Теперь приложение в контейнере backend может подключаться к базе данных просто по хосту db (а не по IP, который может меняться).
4. Просмотр сетей: docker network ls.
5. Подключение работающего контейнера к сети: docker network connect my_network my_container.

6. Docker. Сеть. Проброс портов

Понятие: Контейнер работает в изолированном сетевом пространстве. Приложение внутри контейнера (например, Nginx на порту 80) недоступно с хостовой машины или из интернета. Проброс портов (Port Mapping/Publishing) создает правило маршрутизации, по которому трафик, приходящий на определенный порт физической (хостовой) машины, перенаправляется на определенный порт внутри контейнера.

Синтаксис и использование: Проброс осуществляется флагом -p (или --publish) в команде docker run. Формат: -p <HOST_PORT>:<CONTAINER_PORT>

• docker run -p 8080:80 nginx — весь трафик на localhost:8080 будет перенаправлен внутрь контейнера Nginx на его внутренний порт 80.
• docker run -p 127.0.0.1:8080:80 nginx — проброс порта с привязкой только к локальному интерфейсу (сервис недоступен извне).
• docker run -P nginx — флаг -P (заглавная) пробрасывает все порты, указанные в инструкции EXPOSE Dockerfile, на случайные свободные порты хоста (в диапазоне 32768-60999).

7. Docker. Volume. Принцип работы. Разница между bind mount и volume

Контейнеры эфемерны: если контейнер удаляется, его Read-Write слой стирается, и все данные теряются. Для сохранения состояния (БД, загруженные файлы) используются механизмы монтирования.

Bind Mount (Привязка директории):

• Суть: Монтирует конкретную абсолютную директорию или файл с хостовой машины прямо в контейнер.
• Плюсы: Удобно для разработки (изменил код в IDE на хосте $\to$ изменения мгновенно отразились в контейнере без пересборки).
• Минусы: Полная зависимость от структуры файлов хост-ОС. Небезопасно (контейнер может менять системные файлы хоста).
• Синтаксис: docker run -v /host/path:/container/path nginx

Volume (Том):

• Суть: Docker создает и полностью управляет областью хранения на диске (в Linux обычно /var/lib/docker/volumes/). Пользователю не нужно знать физический путь.
• Плюсы: Абсолютная переносимость, не зависит от хост-ОС. Лучшая производительность. Томами легко управлять через Docker CLI (docker volume ls, docker volume prune). Тома можно безопасно расшаривать между несколькими контейнерами.
• Синтаксис:
  1. Создание: docker volume create my_data
  2. Использование: docker run -v my_data:/var/lib/postgresql/data postgres

8. Docker. Образ. Слои. Принцип работы

Принцип работы (Слоистая архитектура): Docker использует каскадную файловую систему (UnionFS / OverlayFS). Образ состоит из набора независимых файлов-слоев (layers).

• Каждый слой является результатом выполнения отдельной инструкции в Dockerfile (RUN, COPY, ADD). Инструкции вроде ENV или WORKDIR создают лишь метаданные.
• Слои неизменяемы (read-only). Если инструкция RUN rm file.txt удаляет файл, добавленный в предыдущем слое, файл физически не удаляется из нижнего слоя, он просто помечается как удаленный (whiteout) в верхнем слое. Поэтому важно чистить кэш в одной RUN-инструкции: RUN apt update && apt install ... && rm -rf /var/lib/apt/lists/*.
• Слои кэшируются. При пересборке образа Docker переиспользует готовые слои, пока не встретит измененную инструкцию (или измененный файл в COPY). Все последующие слои будут пересобраны с нуля.

Когда из образа запускается контейнер, Docker добавляет поверх стопки read-only слоев один тонкий слой чтения-записи. Все изменения файлов во время работы контейнера пишутся в этот слой по механизму Copy-on-Write (CoW): если нужно изменить файл из нижнего слоя, Docker сначала копирует его в верхний R/W слой, а затем модифицирует копию.

9. Docker. Образ. Хранение локально и удалённо. Основные команды

Локальное хранение: Локальные образы управляются демоном Docker и хранятся в защищенной системной директории (на Linux: /var/lib/docker/). Они состоят из слоев и манифестов.

• Команды: docker images (список), docker rmi <image> (удаление), docker image prune (удаление неиспользуемых “dangling” образов).

Удалённое хранение: Удаленные образы хранятся в Docker Registry (реестрах). Самый популярный публичный реестр — Docker Hub. Существуют приватные реестры (GitLab Container Registry, AWS ECR).

• Аутентификация: docker login (потребует логин и пароль/токен).
• Тегирование (подготовка к пушу): Имя образа должно содержать адрес реестра и имя пользователя. docker tag myapp:latest username/myapp:v1.0
• Отправка: docker push username/myapp:v1.0
• Скачивание: docker pull username/myapp:v1.0
• Выход из аккаунта: docker logout

10. Docker. Основные команды для управления контейнерами и образами

(Обобщающая шпаргалка) Управление образами:

• docker build -t name:tag . — собрать образ из Dockerfile.
• docker pull/push image:tag — скачать/отправить образ.
• docker images — список локальных образов.
• docker rmi <image_id> — удалить образ.

Управление контейнерами:

• docker run -d -p 80:80 --name web nginx — создать и запустить контейнер (фоном, с портами и именем).
• docker ps — список запущенных контейнеров (-a — всех).
• docker stop <id> / docker start <id> / docker restart <id> — управление жизненным циклом.
• docker rm <id> — удалить контейнер.

Инспекция и очистка:

• docker logs <id> — посмотреть логи приложения в контейнере.
• docker inspect <id> — получить полную информацию (JSON) об объекте (IP-адрес, слои, тома, переменные).
• docker system prune -a — радикальная очистка системы: удаляет все остановленные контейнеры, неиспользуемые сети, “повисшие” образы и кэш сборки.

11. Docker. Контейнер. Способы выполнения команд внутри контейнера

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

1. Исполнение команды при запуске (Первичный процесс): Команда передается аргументом в docker run и заменяет собой CMD из Dockerfile. Пример: docker run ubuntu ls -la (создаст контейнер, выведет список файлов, и контейнер сразу завершит работу, так как процесс ls отработал).

2. Исполнение команды в уже запущенном контейнере (docker exec): Позволяет “зайти” в работающий контейнер (создать в нем новый дочерний процесс, не прерывая основной). Синтаксис: docker exec <флаги> <имя_контейнера> <команда> Флаги:

• -i (interactive) — оставляет стандартный ввод (STDIN) открытым.
• -t (tty) — выделяет псевдотерминал для форматирования вывода (чтобы работали bash-оболочки). Пример (самый частый паттерн): docker exec -it my_db /bin/bash (или sh, ash в alpine). Это откроет командную оболочку внутри контейнера базы данных my_db. Для выхода из оболочки нужно ввести exit.

12. Docker. Контейнер. Разница между CMD, RUN и ENTRYPOINT

Эти три инструкции в Dockerfile выполняют команды, но на принципиально разных этапах и с разными целями:

RUN (Сборка): Выполняет команду во время создания образа (build time). Результат работы команды фиксируется в новом слое файловой системы образа. Использование: Установка пакетов (RUN apt install curl), создание директорий, загрузка зависимостей (RUN pip install). В одном Dockerfile может быть много RUN.

CMD (Запуск по умолчанию): Задает команду с аргументами, которая будет выполнена во время старта контейнера (run time). В Dockerfile может быть только одна инструкция CMD (если их несколько, сработает только последняя). Ключевая особенность: Команда CMD легко переопределяется пользователем из консоли: docker run my_image echo "Hello".

ENTRYPOINT (Жесткий запуск): Задает исполняемый файл или скрипт, который будет всегда выполняться при старте контейнера. Ключевая особенность: Его нельзя переопределить обычным аргументом в конце docker run (для этого нужен специальный флаг --entrypoint). Любые аргументы, переданные в docker run, или параметры из инструкции CMD, просто дописываются в конец к ENTRYPOINT. Пример связки: ENTRYPOINT ["python", "main.py"] CMD ["--help"] При запуске без флагов выполнится python main.py --help. При запуске docker run my_image --port 8080 выполнится python main.py --port 8080.

13. Docker. Разница между образом и контейнером. Практические примеры

Разница в теории (ООП аналогия):

• Образ (Image) — это класс. Это пассивный, неизменяемый (read-only) бинарный шаблон, лежащий на диске. Он описывает, как должна выглядеть файловая система и какой процесс запускать.
• Контейнер (Container) — это объект (экземпляр класса). Это активный, выполняющийся в оперативной памяти процесс. Контейнер добавляет поверх образа тонкий слой чтения-записи (R/W), позволяя приложению создавать временные файлы, писать логи и обрабатывать запросы.

Практический пример: У вас есть 1 образ базы данных postgres:15 размером 300 МБ. Вы можете запустить из этого одного образа 5 разных контейнеров: db_dev, db_test_1, db_test_2 и т.д. Docker не копирует 300 МБ пять раз. Все 5 контейнеров переиспользуют одни и те же неизменяемые слои образа postgres:15. Каждый из 5 контейнеров получает лишь свой маленький изолированный R/W слой для записи своих собственных уникальных таблиц и логов. Если остановить и удалить контейнер db_dev, его R/W слой уничтожится, но исходный образ postgres:15 и другие контейнеры останутся нетронутыми.

14. Docker. Переменные окружения. Передача и использование в контейнерах

Сущность: Переменные окружения (Environment Variables, ENV) — это механизм передачи конфигурации (порты, пароли, адреса других сервисов, режимы DEV/PROD) в приложение внутри контейнера без изменения исходного кода или пересборки образа. Это основа методологии “12-Factor App”.

Способы использования и передачи:

1. Внутри Dockerfile: Инструкция ENV DB_PORT=5432. Жестко зашивает значение по умолчанию в сам образ.
2. При запуске через CLI (Флаг -e): docker run -e "DB_PASS=secret" -e "MODE=PROD" my_app Переопределяет значения, заданные в образе.
3. Передача файла конфигурации (Флаг --env-file): Если переменных много, они записываются в файл .env в формате KEY=VALUE. docker run --env-file ./config.env my_app

Внутри приложения (например, на Python) эти значения читаются системными библиотеками: import os; password = os.getenv("DB_PASS").

15. Docker Compose. Принцип работы

Принцип работы: Docker Compose — это инструмент для описания и запуска многоконтейнерных Docker-приложений. В отличие от Docker CLI, где каждый контейнер нужно запускать длинной командой с множеством флагов, Compose использует декларативный подход. Вы описываете всю инфраструктуру (сервисы, базы данных, кэши, сети и тома) в одном конфигурационном файле (обычно docker-compose.yaml), а затем запускаете всю эту архитектуру одной командой. Compose автоматически управляет порядком запуска, связывает контейнеры в единую внутреннюю сеть и обеспечивает их взаимодействие.

16. Docker Compose. Основные команды

• docker compose up — создает и запускает сети, тома и все сервисы, описанные в конфигурационном файле. Флаг -d (detach) запускает их в фоновом режиме.
• docker compose down — останавливает и удаляет контейнеры, а также дефолтные сети, созданные командой up. (Флаг -v дополнительно удалит именованные тома).
• docker compose ps — показывает статус контейнеров, запущенных в рамках текущего проекта (директории).
• docker compose logs — выводит логи всех сервисов. Флаг -f (follow) позволяет смотреть логи в реальном времени. Можно указать имя конкретного сервиса: docker compose logs -f db.
• docker compose build — принудительно собирает или пересобирает образы (из инструкций build:), не запуская контейнеры.
• docker compose stop / start — просто останавливает/запускает контейнеры без их удаления и пересоздания.

17. Docker Compose. Синтаксис docker-compose.yaml. Обязательные и дополнительные директивы

Файл пишется на языке YAML (учитываются отступы пробелами). Обязательные директивы:

• services: — корневая директория, внутри которой описываются все контейнеры (сервисы) проекта. Имя, указанное внутри services, становится внутренним DNS-именем контейнера. Для каждого сервиса обязательно нужно указать либо image: (какой образ скачать), либо build: (из какой директории собрать образ).

Дополнительные директивы (корневые):

• version: '3.8' — (устарело в современных версиях Compose Spec, но часто встречается) указывает версию синтаксиса.
• networks: — описание пользовательских сетей для проекта.
• volumes: — регистрация именованных томов (named volumes), управляемых Docker, чтобы на них можно было ссылаться из сервисов.

Дополнительные директивы внутри сервиса: ports:, environment:, depends_on:, restart:, command:, volumes: (для маппинга путей).

18. Docker Compose. Сеть. Принцип взаимодействия контейнеров

Принцип взаимодействия: Когда вы запускаете docker compose up, инструмент автоматически создает новую виртуальную bridge-сеть специально для этого проекта (название сети обычно формируется как <имя_папки>_default). Все сервисы, описанные в файле, автоматически подключаются к этой сети. Внутри этой сети работает встроенный DNS-сервер Docker. Он позволяет контейнерам общаться друг с другом не по динамическим IP-адресам, а напрямую по именам сервисов, указанным в YAML-файле. Например, бэкенд может подключиться к БД, используя хост db или postgres (имя сервиса), и Docker сам разрешит это имя во внутренний IP-адрес. Пробрасывать порты (директива ports) для общения контейнеров внутри одной сети не нужно, все их внутренние порты по умолчанию открыты друг для друга.

19. Docker Compose. Healthcheck. Назначение и аргументы

Назначение: Механизм Healthcheck позволяет Docker понять, не просто жив ли процесс контейнера (PID 1), а реально ли приложение готово обрабатывать запросы (например, запустился ли веб-сервер, инициализировалась ли БД). Это критически важно при маршрутизации трафика и определении порядка запуска (в связке с depends_on).

Аргументы (синтаксис в YAML):

• test: — команда, которая будет выполняться внутри контейнера для проверки. Если код возврата 0 — health (здоров), 1 — unhealthy. (Пример: test: ["CMD", "curl", "-f", "http://localhost"] или test: curl -f http://localhost || exit 1).
• interval: — как часто проводить проверку (например, 30s).
• timeout: — сколько ждать завершения команды проверки (например, 10s).
• retries: — количество неудачных попыток подряд, после которых контейнер помечается как unhealthy (например, 3).
• start_period: — время на инициализацию приложения, в течение которого ошибки healthcheck игнорируются (например, 40s).

20. Docker Compose. Depends_on. Назначение и аргументы

Назначение: Директива depends_on контролирует порядок запуска (и остановки) сервисов. Гарантирует, что сервис A не начнет стартовать, пока не будут запущены (или не станут “здоровыми”) сервисы B и C, от которых он зависит.

Аргументы (Форматы):

1. Короткий (простой список): depends_on: - db. Compose просто запустит сервис db раньше текущего сервиса, но не будет ждать готовности самой БД (ждет только успешного старта контейнера).
2. Длинный (с условиями):

depends_on:
  db:
    condition: service_healthy # Ждать успешного прохождения healthcheck сервиса db
  redis:
    condition: service_started # Ждать только факта старта (аналог короткого формата)

21. Docker Compose. Replicas. Назначение, аргументы и диапазон портов

Назначение: replicas позволяет запустить несколько идентичных экземпляров (контейнеров) одного и того же сервиса для масштабирования (балансировки нагрузки) или отказоустойчивости.

Аргументы: В современных версиях Compose (deploy конфигурация):

deploy:
  mode: replicated
  replicas: 3 # Запустит 3 инстанса сервиса

Диапазон портов: Если у масштабируемого сервиса жестко проброшен порт на хост (например, ports: - "8080:80"), то запуск более одной реплики вызовет ошибку “port is already allocated” (конфликт портов на хосте). Чтобы этого избежать, задается диапазон портов: ports: - "8080-8085:80". Docker автоматически выдаст каждой новой реплике первый свободный порт из диапазона на хосте (8080 для первой, 8081 для второй и т.д.).

22. Docker Compose. Restart. Назначение и аргументы

Назначение: Политика перезапуска (restart policy) указывает демону Docker, что делать, если процесс внутри контейнера завершился (упал из-за ошибки, завершился штатно или был убит ООМ-киллером).

Аргументы:

• no (по умолчанию) — контейнер не будет перезапущен ни при каких условиях.
• always — всегда перезапускать контейнер при остановке (даже после ручного docker stop, он запустится снова при старте демона Docker).
• on-failure — перезапускать только если процесс завершился с ненулевым кодом ошибки (упал с ошибкой). Можно ограничить число попыток: restart: on-failure:5.
• unless-stopped — аналогично always, но если контейнер был остановлен вручную (docker stop), он не запустится автоматически после рестарта демона Docker.

23. Docker Compose. Переменные окружения. Способы задания

Способы задания:

1. Директива environment: (словарь или массив внутри сервиса). Жестко задает значения в YAML-файле.

   environment:
     - POSTGRES_USER=admin

2. Директива env_file:. Ссылка на внешний текстовый файл (обычно .env), в котором хранятся ключи и значения (безопасный способ, так как .env добавляется в .gitignore).

   env_file:
     - .env

3. Интерполяция из оболочки хоста. Можно использовать значения из окружения той машины, где запускается Compose, подставляя их в YAML через синтаксис ${VAR} или ${VAR:-default_value}. Пример: image: nginx:${NGINX_VERSION:-latest}.

24. Docker Compose. Build. Использование Dockerfile внутри compose

Использование: Директива build указывает Compose собрать образ из исходного кода вместо скачивания готового из реестра (image).

Синтаксис: 4. Короткий: build: ./backend (указывает контекст сборки — папку, где лежит стандартный Dockerfile). 5. Расширенный:

build:
  context: ./backend      # Директория с файлами (контекст)
  dockerfile: Dockerfile.dev # Имя нестандартного Dockerfile
  args:                   # Переменные сборки (ARG внутри Dockerfile)
    - BUILD_ENV=dev

Если указаны обе директивы image и build, Compose соберет образ по инструкциям build и присвоит собранному образу имя и тег, указанные в image.

25. Docker Compose. Ports. Проброс портов и диапазоны

Суть: Директива ports: пробрасывает порты из изолированной сети контейнера на физические порты хостовой машины (Publishing). Формат: "ВНЕШНИЙ_ПОРТ:ВНУТРЕННИЙ_ПОРТ".

Синтаксис и диапазоны:

• "8080:80" — весь трафик с порта 8080 хоста идет на 80 порт контейнера (доступно всем интерфейсам, включая интернет, если хост белый).
• "127.0.0.1:8080:80" — биндинг только к localhost (безопасно, доступно только с самой хост-машины).
• "8000-8010:80" — диапазон внешних портов (полезно при replicas).

(Важное отличие: существует директива expose:, которая просто открывает порты во внутреннюю сеть Compose без проброса их наружу на хост-ОС. Это нужно исключительно для документации, так как внутри своей сети контейнеры и так видят все порты друг друга).

26. Docker Compose. Volumes. Подключение и управление томами

Способы подключения:

1. Bind Mounts (Привязка к хосту): Монтирование конкретной директории с жесткого диска хоста в контейнер. Прописывается прямо в сервисе. Формат HOST_PATH:CONTAINER_PATH.

   volumes:
     - ./src:/app/src

2. Named Volumes (Именованные тома): Управляются самим Docker (абстрагированы от файловой системы хоста). Обязательно требуют регистрации в корневом разделе volumes: всего файла docker-compose.

   services:
     db:
       volumes:
         - pg_data:/var/lib/postgresql/data
   volumes:
     pg_data: # Объявление тома на уровне проекта

27. Docker Compose. Networks. Пользовательские сети и их настройка

Если стандартной сети (одной на весь docker-compose.yaml) недостаточно (например, нужно отделить фронтенд от базы данных по соображениям безопасности), можно создавать пользовательские сети.

Настройка:

1. Объявляются в корневом разделе networks: с возможностью указания драйвера (по умолчанию bridge).
2. Каждый сервис подключается к нужным сетям через директиву networks: на уровне сервиса.

services:
  frontend:
    networks:
      - frontend_net
  backend:
    networks:
      - frontend_net
      - backend_net
networks:
  frontend_net:
  backend_net:

Также можно подключить Compose-проект к сети, созданной ранее вручную, указав флаг external: true в корневом разделе networks.

28. Docker Compose. Именование сервисов и DNS внутри сети

Принцип работы: Имя, указанное в блоке services: (например, redis: или web:), автоматически становится DNS-записью во внутренней сети Docker. Встроенный в Docker DNS-сервер (разрешающий адреса на 127.0.0.11) перехватывает запросы контейнеров. Если сервис api делает HTTP-запрос по адресу http://db:5432, Docker DNS возвращает динамический внутренний IP-адрес контейнера, который в данный момент работает как сервис db. Это позволяет контейнерам общаться друг с другом динамически, игнорируя смену IP-адресов при перезапусках контейнеров. Имя контейнера (container_name) также регистрируется в DNS как алиас.

CI/CD

1. CI/CD. Понятие и зачем нужен CI/CD в разработке

Понятие:

• CI (Continuous Integration / Непрерывная интеграция): Практика разработки, при которой код регулярно (несколько раз в день) сливается в общий репозиторий. Каждое слияние автоматически запускает сборку и прогон тестов для немедленного выявления конфликтов и ошибок.
• CD (Continuous Delivery/Deployment / Непрерывная доставка/развертывание): Автоматизация процесса доставки проверенного кода в стейджинг (Delivery) или напрямую на рабочие сервера/в продакшен (Deployment) без ручного вмешательства.

Зачем нужен:

1. Качество кода: Ошибки выявляются мгновенно, до того как они попадут к клиенту (за счет тестов и линтеров).
2. Скорость Time-to-Market: Автоматизация рутинных задач (сборка, загрузка на сервер) сокращает время релиза с дней до минут.
3. Снижение человеческого фактора: Процесс деплоя задокументирован в коде (Pipeline as Code), исключает “забыл выполнить команду”.
4. Меньший размер конфликтов: Частые мелкие интеграции снижают вероятность появления огромных “мердж-конфликтов” (Merge Hell).

2. CI/CD. Основные этапы pipeline и их назначение

Pipeline (конвейер) — это автоматизированная последовательность шагов, через которые проходит код. Основные этапы:

1. Checkout (Клонирование): Система CI (например, runner) скачивает свежий исходный код из Git-репозитория.
2. Build (Сборка): Компиляция кода (для компилируемых языков типа Java/Go), сборка фронтенда (Webpack/Vite), создание Docker-образа приложения.
3. Test (Тестирование): Автоматический запуск модульных (Unit), интеграционных и E2E тестов. Проверка покрытия кода.
4. Lint / SAST (Анализ качества): Проверка кода на соответствие стандартам форматирования (PEP8, ESLint) и статический анализ на наличие уязвимостей безопасности.
5. Publish / Push (Публикация): Отправка артефактов сборки (например, собранного Docker-образа) в удаленный реестр (Docker Hub, Nexus).
6. Deploy (Развертывание): Автоматическое применение новых артефактов на целевом окружении (перезапуск контейнеров на сервере, деплой в Kubernetes).

3. CI/CD. Git Hooks. Понятие и принцип работы

Понятие: Git Hooks (хуки) — это пользовательские скрипты, которые Git автоматически исполняет до или после важных событий в репозитории (коммит, слияние, пуш). Они лежат в скрытой директории .git/hooks/.

Принцип работы: Хуки позволяют перехватить действие пользователя. Например, при выполнении git commit, Git сначала ищет и запускает исполняемый скрипт с именем pre-commit.

• Если скрипт завершается с кодом 0 (успех), процесс коммита продолжается.
• Если скрипт завершается с кодом, отличным от 0 (ошибка), Git прерывает действие, и коммит не создается. Это первый (локальный) рубеж CI, позволяющий отсеивать плохой код до того, как он покинет компьютер разработчика.

4. CI/CD. Git Hooks. Виды hooks и их назначение

Глобально хуки делятся на клиентские (выполняются на машине разработчика) и серверные (выполняются на сервере, куда делается пуш).

Основные клиентские хуки:

• pre-commit — запускается до ввода сообщения коммита. Используется для проверки кода (запуск линтеров, статического анализа, проверок на забытые console.log или секретные ключи).
• commit-msg — запускается после ввода сообщения коммита. Проверяет само сообщение на соответствие правилам (например, Conventional Commits: должно начинаться с feat: или fix:).
• pre-push — запускается перед отправкой коммитов на удаленный сервер. Идеальное место для прогона тяжелых тестов, которые слишком долго гонять на каждом локальном коммите.
• post-merge — выполняется после успешного слияния (pull). Может использоваться для автоматической установки новых зависимостей (например, запуск npm install, если обновился package.json).

5. CI/CD. Git Hooks. Автоматический запуск тестов

Автоматический запуск тестов локально через Git Hooks предотвращает отправку неработающего кода в общий репозиторий. Обычно тесты вешают на хук pre-push.

• Причина выбора pre-push: Тесты (особенно интеграционные) могут выполняться долго (минуты). Если повесить их на pre-commit, разработчик будет страдать при каждой локальной фиксации изменений. На pre-push тесты прогоняются только перед отправкой пакета коммитов на сервер.
• Как работает: В скрипте .git/hooks/pre-push прописывается вызов тест-раннера (например, pytest или npm test). Если тесты падают (exit code 1), пуш блокируется, и серверный код остается в безопасности.

6. CI/CD. Использование линтеров в pre-commit hooks

Суть: Линтеры — это программы для статического анализа кода, выявляющие стилистические ошибки и антипаттерны (ESLint, flake8, Pylint, Black). Встраивание линтера в хук pre-commit гарантирует, что в истории коммитов проекта не окажется “грязного” или не отформатированного кода.

Как применяется: Настроить нативные bash-скрипты в .git/hooks неудобно для командной работы (они не коммитятся в историю). Поэтому обычно используют фреймворки (например, Python-утилиту pre-commit или Node.js-пакет Husky). Они позволяют декларативно в YAML/JSON файле указать список линтеров, которые должны автоматически скачиваться и запускаться только для измененных файлов при попытке сделать коммит. Если линтер находит ошибку (или переформатирует файл), коммит прерывается.

7. CI/CD. GitHub Actions. Что такое workflow и как он запускается

Что такое workflow: Workflow (рабочий процесс) в GitHub Actions — это настраиваемый автоматизированный процесс, состоящий из одной или нескольких задач (jobs). Он описывается в виде YAML-файла и должен строго лежать в репозитории по пути .github/workflows/*.yml.

Как запускается: Workflow запускается в ответ на конкретные триггеры (события) (блок on: в YAML), происходящие в репозитории (например: кто-то запушил код, создал Pull Request, создал Release). При наступлении события GitHub автоматически выделяет виртуальную машину (Runner), скачивает код и пошагово выполняет инструкции, описанные в файле.

8. CI/CD. GitHub Actions. Основные компоненты: job, step, action (обзор)

Архитектура GitHub Actions иерархична: Workflow -> Job -> Step -> Action.

• Job (Задача): Группа шагов (steps), которые выполняются на одной виртуальной машине (Runner’е). У workflow может быть несколько Job’ов, по умолчанию они выполняются параллельно (например, сборка под Linux и под Windows одновременно). Можно настроить зависимости между Job’ами через директиву needs.
• Step (Шаг): Индивидуальная задача внутри Job. Шаги выполняются строго последовательно в рамках одного Runner’а и шарят общую файловую систему. Шаг может быть либо консольной командой (run: make build), либо вызовом готового Action.
• Action (Действие): Готовый, переиспользуемый блок кода (компонент), написанный сообществом или GitHub. Вызывается ключевым словом uses. Избавляет от написания сложных bash-скриптов. (Например, uses: actions/checkout@v3 — экшен, который делает git clone репозитория на runner; actions/setup-python@v4 — экшен установки нужной версии Python).

9. CI/CD. GitHub Actions. Триггеры запуска (push, pull_request, schedule)

Триггеры прописываются в блоке on: и определяют, когда именно запустится workflow.

• push: Срабатывает при отправке коммитов (git push) на сервер GitHub. Можно отфильтровать запуск только для конкретных веток или файлов:

  on:
    push:
      branches: [ "main", "release/*" ]
      paths: [ "src/**" ] # Игнорировать изменения в README.md

• pull_request: Срабатывает при создании, обновлении или открытии PR. Обычно используется для запуска тестов и линтеров, чтобы проверить предлагаемый код до его слияния в основную ветку.

  on:
    pull_request:
      branches: [ "main" ] # Запускать, если PR направлен в ветку main

• schedule: Позволяет запускать пайплайн по расписанию (как cron в Linux). Полезно для ночных сборок, периодической генерации отчетов или бэкапов.

  on:
    schedule:
      - cron: '0 2 * * *' # Запуск каждый день в 02:00