DevOps — шпаргалка

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

---

DevOps — шпаргалка для работы с Git, Docker, Kubernetes и CI/CD

Git — 12 команд

clone, push, ветки и слияние — в справочнике Git (раздел 4.13).

Ниже — 18 команд Docker, 9 практик Dockerfile, Kubernetes и типовой CI/CD-контур на хосте.

Play ITЗагрузка интерактивного демо…

---

18 команд Docker — карманный набор

docker run запускает контейнер из готового образа. docker build собирает свой образ из Dockerfile. Остальные команды закрывают типовой цикл — скачать и опубликовать образ, управлять контейнером, посмотреть логи, скопировать файлы и освободить место на диске.

Схема Docker Engine

Клиент передаёт команды демону на хосте; образы хранятся локально, реестр — для pull и push.

Таблица потоков для build, pull, run, push — в главе Docker.

Справочник в энциклопедии

Флаги, Dockerfile, Compose, сети и тома — в Справочнике по Docker.

Девять практик сборки образа — в этой же шпаргалке.

Практика на Docker Desktop — в Первых шагах.

Образы и реестр

Команда	Что делает	Пример
docker build	Собирает образ из Dockerfile в текущем каталоге	docker build -t myapp:latest .
docker pull	Скачивает образ из реестра (Docker Hub и др.)	docker pull ubuntu:22.04
docker push	Публикует локальный образ в реестр	docker push myuser/myapp:latest
docker images	Показывает все образы на машине	docker images
docker rmi	Удаляет образ по имени или ID	docker rmi myapp:old
docker save / docker load	Сохраняет образ в tar-архив и загружает обратно без registry	docker save -o image.tar myapp:1.0 · docker load -i image.tar

Разбор:

• build — единственный способ получить кастомный образ из исходников; -t задаёт имя и тег, . — контекст сборки.
• pull / push — обмен с registry; перед push обычно нужен docker login и тег с префиксом registry.
• images — быстрая проверка, что образ скачался или собрался; колонка SIZE помогает найти "тяжёлые" слои.
• rmi — освобождает место; образ нельзя удалить, пока на нём висит контейнер (даже остановленный).
• save / load — офлайн-перенос или бэкап образа там, где нет доступа к registry.

---

Контейнеры — запуск и жизненный цикл

Команда	Что делает	Пример
docker run	Создаёт и запускает контейнер из образа	docker run -d -p 8080:80 --name web nginx
docker ps	Список работающих контейнеров (-a — все, включая остановленные)	docker ps
docker stop	Корректно останавливает контейнер (SIGTERM, затем SIGKILL)	docker stop web
docker start	Запускает ранее остановленный контейнер с теми же настройками	docker start web
docker restart	Перезапускает работающий контейнер	docker restart web
docker kill	Немедленно прерывает процесс (SIGKILL по умолчанию)	docker kill web
docker rm	Удаляет остановленный контейнер	docker rm web

Разбор:

• run — главная команда для первого старта; -d — фон, -p — проброс порта, --name — удобное имя для остальных команд.
• ps — "кто сейчас работает"; с -a видны упавшие контейнеры и код выхода в колонке STATUS.
• stop / start / restart — управление существующим контейнером без пересоздания; для нового образа нужен новый run.
• kill — когда stop не помогает; для штатного завершения предпочтительнее stop.
• rm — убирает метаданные контейнера; данные в именованных томах при этом сохраняются.

---

Отладка и обмен файлами

Команда	Что делает	Пример
docker exec	Выполняет команду внутри работающего контейнера	docker exec -it web sh
docker logs	Показывает stdout/stderr контейнера	docker logs -f web
docker inspect	Подробная конфигурация контейнера или образа (JSON)	docker inspect web
docker cp	Копирует файлы между хостом и контейнером	docker cp ./config.yml web:/app/config.yml

Разбор:

• exec -it — интерактивная оболочка для ручной проверки; не пересоздаёт контейнер и не меняет образ.
• logs -f — потоковый вывод, как tail -f; первая команда при "контейнер Up, но сервис молчит".
• inspect — env, mounts, сеть, лимиты; с -f '{{…}}' удобно в скриптах.
• cp — работает и на остановленном контейнере; путь внутри указывается как имя:/путь.

---

Очистка диска

Команда	Что делает	Пример
docker system prune	Удаляет остановленные контейнеры, неиспользуемые сети и "висячие" образы	docker system prune

Разбор:

• Без флагов команда спрашивает подтверждение; -f — без вопросов.
• prune -a агрессивнее — снимает все образы без привязки к работающим контейнерам.
• prune --volumes затрагивает неиспользуемые тома — проверьте данные перед запуском.
• Работающие контейнеры и образы, от которых они зависят, команда не трогает.

Осторожно с prune в проде

На CI-раннере и ноутбуке docker system prune освобождает гигабайты.

На сервере с общим кэшем сборок сначала смотрите docker system df.

---

9 практик Dockerfile — карманный чеклист

Команды docker build и docker run закрывают эксплуатацию; качество образа задаётся Dockerfile и контекстом сборки. Ниже — девять привычек, которые стоит держать под рукой вместе с 18 командами. Развёрнутые примеры для Node.js, Python и Go — в статье Dockerfile; десять готовых Dockerfile с построчным разбором для лабораторных — галерея Lab; выбор базового образа в реестре — в Docker Hub и реестрах.

№	Практика	Зачем	Минимальный пример
1	Официальные образы	Поддержка upstream, регулярные патчи, меньше риска подмены	FROM node:20-alpine (Docker Library / OFFICIAL в Hub)
2	Фиксированная версия	Тег latest меняется без предупреждения и ломает воспроизводимость сборки	FROM node:20.11.1-alpine3.19
3	Multi-stage	В финальный образ попадает только артефакт, без компилятора и dev-зависимостей	см. блок ниже
4	.dockerignore	Меньше контекст → быстрее build; в слои не уезжают node_modules, .env, логи	node_modules, .git, *.log
5	Непривилегированный пользователь	При компрометации контейнера процесс без root на хосте	RUN useradd -m app · USER app
6	Переменные окружения	Один Dockerfile для dev/stage/prod; пути и режимы без хардкода	ENV APP_HOME=/app · WORKDIR $APP_HOME
7	Порядок под кэш	Слой, который меняется реже, идёт выше; иначе каждый COPY сбрасывает RUN ниже	сначала requirements.txt + pip install, потом COPY . .
8	LABEL	Владелец, версия, описание — в docker inspect и registry	LABEL maintainer="team@example.com" · version="1.0"
9	Сканирование образа	CVE в базовом слое и зависимостях до выката	docker scout cves myapp:1.0 или Trivy в CI

Официальный образ и pinned-тег

# Хорошо для старта — официальный образ с понятным тегом
FROM node:20-alpine

# Для CI и продакшена — полная фиксация версии базового слоя
FROM node:20.11.1-alpine3.19

Разбор:

• Образы Docker Library (nginx, python, node, eclipse-temurin) помечены Official в Hub и в выводе docker search.
• Мажорный тег (20-alpine) обновляется патчами; для релизного контура указывайте patch-версию или digest (@sha256:…) — см. теги и digest.

Multi-stage и .dockerignore

Код ITЗагрузка примера кода…

Файл .dockerignore в корне контекста (рядом с Dockerfile):

.git
node_modules
npm-debug.log
__pycache__
.env
dist
coverage

Разбор:

• Стадия build держит SDK; в runtime остаётся только бинарник — образ на порядки меньше.
• COPY --from=build переносит артефакт без исходников и toolchain.
• .dockerignore действует на контекст docker build . — демон не получает перечисленные пути, сборка ускоряется, секреты из .env не попадают в историю слоёв.

Порядок слоёв, ENV и USER

Код ITЗагрузка примера кода…

Разбор:

• ENV + WORKDIR — один раз задали корень приложения; в CI можно переопределить через --build-arg или runtime -e.
• apt-get до COPY jar — при правке только приложения кэш пакетного менеджера сохраняется.
• USER после установки пакетов: системные RUN часто требуют root, процесс приложения — нет.
• LABEL помогает в audit и при фильтрации образов в registry.

Сканирование перед push

docker build -t myapp:1.4.2 .
docker scout cves myapp:1.4.2
# или в CI: trivy image --severity HIGH,CRITICAL myapp:1.4.2

Разбор:

• Сканер смотрит ОС-базу и установленные пакеты; критичные CVE в базовом FROM лечатся обновлением тега, а не только кодом приложения.
• В CI/CD-конвейере (см. раздел "Разбор CI/CD-конвейера" ниже) сканирование ставят после build и до push в registry.
• Подробнее про секреты, rootless и политики — безопасность в справочнике Docker и ИБ.

Связка с 18 командами

docker build применяет все девять практик; docker images покажет размер после multi-stage; docker push — только после скана и фиксированного тега.

Опасные флаги run — в Опасных скриптах.

---

Полный цикл — от кода до запуска

Ниже представлена структурированная информация в виде таблицы, которая поможет вам понять основные этапы настройки и управления контейнерами, репозиториями, сборкой приложений и оркестрацией.

Этап	Описание	Команды и примеры
Обновление системы	Обновление пакетов на хосте.	см. блок "Подготовка хоста"
Установка Git	Клонирование репозиториев.	см. блок "Подготовка хоста"
Установка Docker	Engine + Compose plugin.	см. блок "Docker"
Клонирование репозитория	Исходники проекта.	git clone, cd — в блоке "Подготовка хоста"
Сборка образа	Dockerfile или Compose.	см. блок "Docker"
Запуск контейнера	Порты, сеть, имя.	см. блок "Docker"
Мониторинг контейнеров	Состояние и логи.	см. блок "Docker"
Управление Kubernetes	Кластер и манифесты.	см. блок "Kubernetes"
CI/CD процесс	Сборка → push → deploy.	см. блок "CI/CD"

Подготовка хоста

sudo apt update && sudo apt upgrade -y
sudo apt install -y git
git --version
git clone <url> && cd <repo>

Разбор:

• sudo apt update — обновляет индекс пакетов APT из репозиториев; без этого install может не видеть свежие версии.
• sudo apt upgrade -y — устанавливает обновления уже установленных пакетов; -y подтверждает запросы автоматически.
• && — вторая команда выполняется только если первая завершилась с кодом 0.
• sudo apt install -y git — ставит Git для клонирования и работы с репозиториями на хосте.
• git --version — проверка, что бинарь в PATH и установка прошла успешно.
• git clone <url> && cd <repo> — клонирует удалённый репозиторий и переходит в каталог проекта (<url> и <repo> — плейсхолдеры под ваши значения). Остальные команды Git на каждый день — 12 команд.

Docker

sudo apt install -y docker-ce docker-compose-plugin
sudo usermod -aG docker $USER && newgrp docker
docker build -t myapp:1.0 .
docker compose up --build -d
docker run -d -p 8080:8080 --name web myapp:1.0
docker network create app-net
docker network connect app-net web
docker ps
docker logs -f web

Разбор:

• docker-ce — community edition Engine (демон + клиент); docker-compose-plugin — встроенная подкоманда docker compose.
• usermod -aG docker $USER — добавляет текущего пользователя в группу docker, чтобы не писать sudo перед каждой командой; newgrp docker применяет группу в текущей сессии без перелогина.
• docker build -t myapp:1.0 . — сборка образа из Dockerfile в текущем каталоге; -t задаёт имя и тег myapp:1.0.
• docker compose up --build -d — поднимает стек из compose-файла, пересобирает образы при необходимости, -d — в фоне. Готовые compose.yaml с разбором — Docker Compose — готовые стеки; шаблоны Dockerfile для build: . — галерея Lab.
• docker run -d -p 8080:8080 --name web myapp:1.0 — контейнер web в фоне, порт 8080 хоста → 8080 внутри контейнера.
• docker network create app-net — пользовательская bridge-сеть для DNS по имени контейнера.
• docker network connect app-net web — подключает уже запущенный контейнер web к сети app-net.
• docker ps — список запущенных контейнеров (статус, порты, имена).
• docker logs -f web — потоковый вывод логов контейнера web (stdout/stderr).

Kubernetes

kubectl apply -f deploy.yaml
kubectl get pods
kubectl describe pod <pod-name>

Разбор:

• kubectl apply -f deploy.yaml — декларативно применяет манифесты (Deployment, Service и др.) к кластеру; создаёт или обновляет ресурсы.
• kubectl get pods — краткий список подов — имя, готовность, статус, рестарты, возраст.
• kubectl describe pod <pod-name> — детали пода — события, причины Pending/CrashLoopBackOff, лимиты, тома, образы (<pod-name> — имя из вывода get pods).
• Этапы от записи в etcd до Running и очистки при удалении — жизненный цикл Pod.

CI/CD

docker build -t myregistry/myapp:latest .
docker push myregistry/myapp:latest
kubectl apply -f deployment.yaml

Разбор:

• docker build -t myregistry/myapp:latest . — собирает образ и помечает полным именем registry (myregistry — хост или namespace в Hub/ECR).
• docker push myregistry/myapp:latest — публикует слои в registry; после push кластер и другие хосты могут сделать pull.
• kubectl apply -f deployment.yaml — выкатывает Deployment (обычно с образом из registry); Kubernetes подтянет образ при создании подов.
• Три шага — минимальный CI/CD-контур: артефакт → хранилище → оркестратор.

Таблица задаёт этапы; команды — в блоках выше.

При ошибках смотрите логи и describe:

docker logs -f <container>
kubectl describe pod <pod-name>

Разбор:

• docker logs -f <container> — логи контейнера в реальном времени; <container> — имя или ID из docker ps.
• kubectl describe pod <pod-name> — события планировщика, ошибки pull образа, probe, OOM — главный инструмент, когда под не в Running.
• Пара команд покрывает два уровня: одиночный Docker на хосте и Kubernetes в кластере.

Перед docker build пройдите 9 практик Dockerfile — .dockerignore, pinned-тег, multi-stage и порядок слоёв уменьшают контекст и размер образа.

---

Шпаргалка по типичным задачам эксплуатации

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

---

Docker — быстрые действия

docker ps -a
docker inspect <container>
docker exec -it <container> sh
docker stats
docker image ls
docker image prune -f

Разбор:

• docker ps -a — все контейнеры, включая остановленные; видно, кто упал и с каким кодом выхода.
• docker inspect <container> — JSON с конфигурацией — env, mounts, сеть, лимиты, Cmd/Entrypoint.
• docker exec -it <container> sh — интерактивная оболочка внутри работающего контейнера для ручной проверки файлов и процессов.
• docker stats — live CPU/RAM/сеть по контейнерам без внешнего мониторинга.
• docker image ls — локальный список образов (REPOSITORY, TAG, SIZE).
• docker image prune -f — удаляет "висячие" образы без тега; -f без подтверждения; осторожно с кэшем сборок.

---

Kubernetes — базовая диагностика

kubectl get pods -A
kubectl get deploy,svc,ingress -A
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --tail=200
kubectl logs <pod-name> -n <namespace> --previous
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Разбор:

• kubectl get pods -A — поды во всех namespace; -A = --all-namespaces.
• kubectl get deploy,svc,ingress -A — сводка деплойментов, сервисов и Ingress по кластеру.
• kubectl describe pod ... -n <namespace> — диагностика конкретного пода в нужном namespace.
• kubectl logs ... --tail=200 — последние 200 строк логов текущего контейнера.
• kubectl logs ... --previous — логи упавшего контейнера до рестарта (при CrashLoopBackOff).
• kubectl get events ... --sort-by=.metadata.creationTimestamp — хронология событий namespace (scheduling, FailedMount, BackOff).

---

Разбор CI/CD-конвейера по шагам

Полная карта этапов (от задачи в трекере до метрик на проде) и таблица инструментов по фазам CI и CD — в жизненном цикле пайплайна CI/CD. Ниже — практический срез для контейнерного сервиса.

Строка "сборка → push → deploy" полезна как опора, но в реальном проекте шаги обычно выглядят подробнее:

1. Проверка кода
   • линтеры и тесты;
   • сканирование зависимостей и SAST.
2. Сборка артефакта
   • Docker-образ с фиксированным тегом (app:1.4.2 и SHA);
   • 9 практик Dockerfile — pinned FROM, multi-stage, .dockerignore.
3. Публикация
   • push в registry;
   • сканирование образа на CVE перед или сразу после push;
   • публикация SBOM и подписи образа.
4. Развёртывание
   • обновление манифестов/чарта;
   • rollout в staging, затем в production.
5. Проверка результата
   • smoke-тесты;
   • проверка метрик, ошибок и rollback при деградации.

Пример командного каркаса:

docker build -t registry.example.com/myapp:1.4.2 .
docker push registry.example.com/myapp:1.4.2
helm upgrade --install myapp ./chart -f values-prod.yaml
kubectl rollout status deployment/myapp -n production

Разбор:

• registry.example.com/myapp:1.4.2 — полное имя образа с фиксированным релизным тегом 1.4.2 (не latest).
• docker push — публикует образ в корпоративный registry перед деплоем.
• helm upgrade --install myapp ./chart -f values-prod.yaml — устанавливает или обновляет релиз Helm myapp из чарта ./chart с prod-значениями из файла.
• kubectl rollout status deployment/myapp -n production — ждёт успешного завершения rolling update Deployment в namespace production.
• Блок связывает сборку образа, публикацию и выкладку через Helm с проверкой rollout.

---

Мини-чек-лист безопасности для контейнеров и кластера

• Соблюдайте 9 практик Dockerfile — pinned-тег, .dockerignore, non-root, сканирование образа.
• Используйте образы с фиксированными тегами и регулярным обновлением базового слоя.
• Запускайте приложение от непривилегированного пользователя (runAsNonRoot в Kubernetes, USER в Dockerfile).
• Убирайте секреты из репозитория, передавайте через Secrets и внешние хранилища.
• Ограничивайте сетевой доступ через NetworkPolicy.
• Включайте аудит логов и алерты на аномальные события.

Погружение по угрозам, рискам и OWASP находится в статье Информационная безопасность.

---

Как использовать эту шпаргалку вместе с соседними материалами

• Для точечных команд Docker — 18 команд; для Dockerfile — 9 практик.
• Для понимания архитектуры оркестрации читайте Docker Swarm и Kubernetes.
• Для практики на локальной машине переходите в Первые шаги.
• Для production-подходов и Helm-сценариев используйте Реализация Kubernetes.
• Для точечных команд и полей манифестов держите рядом Справочник по Kubernetes.

В таком режиме статья работает как рабочий конспект, а не просто список команд.

---

Какую команду запускать в каком случае

Ситуация	Команда	Что получите
Контейнер запущен, но сервис недоступен	docker logs -f <container>	Причину ошибки приложения
Нужны переменные и параметры контейнера	docker inspect <container>	Полную конфигурацию запуска
Поды в Kubernetes не стартуют	kubectl describe pod <pod-name> -n <namespace>	События планирования и ошибки запуска
Под перезапускается циклически	kubectl logs <pod-name> -n <namespace> --previous	Логи предыдущего падения
Нужна картина по кластеру	kubectl get deploy,svc,ingress -A	Сводное состояние ресурсов
Проверка rollout после релиза	kubectl rollout status deployment/<name> -n <namespace>	Статус завершения выкладки

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

---

Короткий рабочий цикл DevOps-инженера

Типичный ежедневный цикл выглядит так:

1. Проверить состояние деплоймента и алерты.
2. Разобрать ошибки по логам и событиям.
3. Подготовить исправление в коде или конфигурации.
4. Выполнить сборку и публикацию образа.
5. Запустить controlled rollout и проверить результат.
6. Зафиксировать изменения и наблюдения в runbook.

Если держать этот цикл дисциплинированно, инфраструктура остаётся предсказуемой даже при частых релизах.

---