Большой тест по Docker для новичков из 85 вопросов - https://qarocks.ru/test_post/big-docker-quiz/

Проходите и пишите у кого 85 из 85:)

P.S если найдете ошибки в ответах, присылайте попросим исправить)

«Штурвал 2.10»: встречайте поддержку Yandex Cloud и настоящую мультитенантность

10 июня в 17:00 мск встречаемся на обзорном вебинаре по релизу Kubernetes-платформы «Штурвал 2.10». Ребята из «Лаборатории Числитель» расскажут про два самых интересных обновления:

▪️Поддержку провайдера Yandex Cloud — как управлять кластерами в этом облаке так же, как у себя в инфраструктуре.

▪️Появление тенантов — как централизованно управлять доступами на понятных для бизнеса абстракциях, например, таких как «департамент», «система» и «окружение».

Вебинар будет интересен DevOps-инженерам, разработчикам, сотрудникам служб эксплуатации, специалистам по информационной безопасности, руководителям и всем, кто заинтересован в контейнеризации.

✔️ Регистрация

Docker for Developers

Автор: Richard Bullington-McGuire
Год издания: 2020

#docker #en

Скачать книгу

🐳 Задача для продвинутых DevOps-инженеров: «Странный Docker контейнер, который тормозит хост»

🧠 Уровень: Senior DevOps / SRE
🎯 Цель: Найти причину деградации хост-системы при работе контейнера, не убивая продакшен

📍 Ситуация:

Ты запускаешь относительно простой контейнер:

docker run --rm myapp:latest

Через несколько минут:
- Уровень load average на хосте резко подскакивает
- CPU не перегружен, но система начинает "подвисать"
- Контейнер *не* использует много CPU или памяти (по `docker stats`)
- top и iotop на хосте — ничего подозрительного
- Но хост "лагает", SSH подключается с задержками, htop еле прокручивается

📦 Контейнер собран из Dockerfile:

FROM ubuntu:22.04
COPY . /app
WORKDIR /app
CMD ["python3", "main.py"]

  🧩 Ваша задача:

1. Объяснить, как контейнер может вызывать *нагрузку на хост*, не показывая это в docker stats
2. Найти потенциальную причину такой деградации
3. Предложить способ отладки, не убивая контейнер
4. Предложить защиту от подобных сценариев на уровне docker run и docker-compose
5. Написать Dockerfile и docker run с ограничениями, чтобы контейнер больше так не вел себя

💡 Подсказка:
Некоторые контейнеры могут порождать *огромное количество процессов* или использовать слишком много I/O операций с tmpfs или сокетами, перегружая не CPU, а системные лимиты ядра.

🛠 Решение:

1. Проверяем количество процессов:

   ps -eLf | wc -l
   

2. Выясняем, что контейнер запускает тысячи потоков (например, while True: os.fork() или Thread() без лимита в main.py)

3. Используем strace`/`nsenter для анализа PID пространства:

   docker inspect <container_id> | grep Pid
   nsenter -t <pid> -a htop
   

4. Ставим лимиты:
- Через --pids-limit:

     docker run --pids-limit 100 --memory=256m --cpus="0.5" myapp:latest
     

- Или в docker-compose.yml:

     deploy:
       resources:
         limits:
           cpus: "0.5"
           memory: 256M
     

5. Добавляем в Dockerfile:

   ENV PYTHONUNBUFFERED=1
   

📌 Вывод:
Контейнеры могут перегружать хост не по CPU/Memory, а по количеству потоков, сокетов, inode или I/O. Это не видно в docker stats, но критично для стабильности. Решение — выставлять ограничения (ulimit, pids, memory) и проверять, что внутри контейнера не бесконечный форк/спам.

💬 Отличный сценарий для продвинутого собеса на DevOps / Platform-инженера.

🧠 DevOps-задача: "Обманчиво здоровый контейнер"

Условие:
У тебя настроен Docker-контейнер с приложением и прописан HEALTHCHECK в Dockerfile:

HEALTHCHECK CMD curl --fail http://localhost:8080/health || exit 1

В CI всё работает. В Kubernetes — контейнер вечно “healthy”, но:
- Метрики не собираются
- Ответы приложения не приходят
- От клиентов жалобы
- Никаких рестартов пода не происходит

При этом kubectl describe pod показывает статус: Ready: True, Containers: healthy

Задача:
Найди источник проблемы, объясни, почему HEALTHCHECK ничего не выявляет, и предложи реальное решение.

Разбор:

🔍 Подвох №1: HEALTHCHECK в Docker — не работает в Kubernetes

- Kubernetes игнорирует HEALTHCHECK, прописанный в Dockerfile
- Вместо этого использует livenessProbe и readinessProbe, заданные в манифесте YAML

📌 Поэтому контейнер кажется "здоровым", но на самом деле Kube о нём ничего не знает


🛠 Решение:

В deployment.yaml пропиши:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 2
  periodSeconds: 5

Это активирует реальную проверку на уровне Kubernetes и позволит поду:
- перезапускаться при зависании (liveness)
- исключаться из сервисов (readiness)

🎯 Что проверяет задача:

• Понимание различий между Docker и Kubernetes health mechanisms
• Навык выявления "ложноположительных" статусов
• Умение читать реальные признаки деградации (метрики, жалобы, тайм-аут)
• Установка правильных probes — ключ к HA-системам

💡 В реальной жизни такие ошибки ведут к "здоровым", но абсолютно мертвым сервисам.

⚡️ Топ-3 полезных советов для Docker на сегодня:

1️⃣ Очищайте билд-кэш через --no-cache-filter.
Вместо полной очистки кэша (docker builder prune) удаляйте только указанные слои:

docker builder prune --filter 'until=24h' --no-cache-filter alpine

2️⃣ Добавьте в .dockerignore следующие строки:

.git
node_modules
*.log
pycache/
*.tmp

✅ Это сократит размер контекста сборки на 50–90%, особенно в проектах с большим числом зависимостей или history-heavy репозиториями.

Меньше контекста → быстрее копирование → быстрее билд.

3️⃣ Чтобы увидеть Dockerfile любого образа с Docker Hub используйте:

docker history --no-trunc <image> | tac | awk -F' /bin/sh -c ' '{print $2}'

💡 Docker Tip: ускоряем сборку с помощью BuildKit + Target Stage

Многие знают про docker build, но редко используют BuildKit + multi-stage с опцией `--target` для локальной отладки.

👉 Если у тебя много стадий (например, build + тесты + production), ты можешь не собирать всё каждый раз, а запускать только нужную стадию:

Пример:

DOCKER_BUILDKIT=1 docker build --target dev-stage -t myapp:dev .

📈 Что это даёт:

- ⚡️ Пропускаешь финальную сборку (например, оптимизацию прод-образа)
- 🔍 Быстро тестируешь только нужный слой (например, dev-stage)
- 💾 Экономишь кэш и ускоряешь сборку — собирается только то, что нужно

🔥 Включи BuildKit по умолчанию

Добавь в файл ~/.docker/config.json:

{
  "features": {
    "buildkit": true
  }
}

Теперь docker build всегда использует BuildKit — он быстрее, лучше кэширует и умеет собирать слои параллельно.

---

🎯 Бонус-совет: кэш зависимостей через RUN --mount=type=cache

Для Python:

RUN --mount=type=cache,target=/root/.cache \
    pip install -r requirements.txt

Для npm:

RUN --mount=type=cache,target=/root/.npm \
    npm install

✅ Это ускоряет повторные билды на десятки процентов 💨

👀 Итог:
Не просто строй Docker-образы — строй их умно. BuildKit + правильные таргеты + кэш → твой билд летает 🚀

The Docker Book

Автор: James Turnbull
Год издания: 2019

#docker #en #книга

Скачать книгу

🔍 Dockle — линтер для проверки безопасности Docker-образов. Этот инструмент сканирует контейнеры на соответствие best practices и CIS Benchmark, выявляя потенциальные уязвимости. В отличие от Hadolint, Dockle проверяет уже собранные образы, включая структуру файлов, права доступа и наличие уязвимых зависимостей.

Проект поддерживает интеграцию с CI/CD и выводит результаты в JSON или SARIF-формате. Можно игнорировать определенные проверки через .dockleignore или гибко настраивать уровни критичности. Для запуска не нужны сложные зависимости — достаточно бинарного файла или Docker-образа.

🤖 GitHub

@Docker

🐳 Что если вам нужно запустить чужой (возможно небезопасный) код?

Представьте: вам прислали бинарник, Python-скрипт или npm-пакет, и его надо выполнить.
Вы не знаете, что внутри — а вдруг там rm -rf /, попытка выйти из контейнера, майнер или установка root-доступа?

🔥 Первый инстинкт: запустить в Docker. Кажется, контейнер спасёт?
⚠️ На самом деле — не всегда.


🛑 Docker ≠ песочница
Контейнеры по умолчанию не изолированы от ядра, сетей и сокетов хоста.
Даже простое docker run -it ubuntu запускает процесс с root-доступом внутри контейнера.

🛡 Что делать, если код небезопасен:

# Запуск без root-доступа
docker run --user 1000:1000 my-image

# Только для чтения
docker run --read-only my-image

# Удалить все cap-привилегии ядра
docker run --cap-drop=ALL my-image

# Использовать seccomp-профиль
docker run --security-opt seccomp=default.json my-image

# Отключить сеть
docker run --network=none my-image

Также стоит:
• Настроить AppArmor / SELinux
• Запретить монтирование Docker сокета
• Ограничить доступ к /proc, /sys

💡 Вывод:
Docker — это удобный инструмент упаковки, но не синоним безопасной изоляции.
Если запускаете сторонний или user-generated код (плагины, CI-скрипты, sandbox-сервисы) — относитесь к нему как к потенциально опасному.

Безопасность — это не "чеклист", а постоянная практика.

#Docker #Security #Sandbox #DevOps #Isolation

@Docker

🧹 Очистка данных в Docker: как освободить место и ускорить работу

Docker — мощный инструмент, но со временем он начинает засоряться контейнерами, образами, томами и сетями. Это тормозит систему и забивает диск.

Вот как быстро навести порядок:

▪️ Удалить остановленные контейнеры

docker container prune

▪️ Удалить неиспользуемые образы

docker image prune
docker image prune -a

▪️ Удалить неиспользуемые сети

docker network prune

▪️ Удалить неиспользуемые тома

docker volume prune

▪️ Комплексная очистка всего окружения

docker system prune
docker system prune -a

⚙️ Автоматизация очистки (раз в неделю через cron)

 0 * * 0 /usr/bin/docker system prune -f

📦 Для Docker Compose-проектов

docker-compose down --remove-orphans

✅ Регулярная очистка — залог стабильности и свободного пространства. Привычка, за которую ваша система скажет спасибо.

@Docker

🐳 Шпаргалка по командам Docker

docker exec -it test1 bash — Войти в контейнер контейнер test1.
docker container start test1 — Запустить контейнер test1
docker ps — показывает список запущенных контейнеров.

Некоторые из полезных флагов:
-a / --all — список всех контейнеров (по умолчанию показывает только запущенные);
-q / --quiet — перечислить только id контейнеров (полезно, когда вам нужны все контейнеры).

docker pull — большинство образов создаётся на основе базового образа из Docker Hub. Docker Hub содержит множество готовых образов, которые можно использовать вместо того, чтобы создавать и настраивать свой собственный. Чтобы скачать определённый образ или набор образов (репозиторий), используйте команду docker pull.
docker build — эта команда собирает образ Docker из Dockerfile и «контекста». Контекст сборки — это набор файлов, расположенных по определённому пути или URL. Используйте флаг -t, чтобы задать имя образа. Например, команда docker build -t my_container . соберёт образ, используя текущую директорию, на что указывает точка в конце.
docker run — запускает контейнер, на основе указанного образа. Эту команду можно дополнять другими, например, docker run my_image -it bash запустит контейнер, а затем запустит в нём bash.
docker logs — эта команда используется для просмотра логов указанного контейнера. Можно использовать флаг --follow, чтобы следить за логами работающей программы: docker logs --follow my_container.
docker volume ls — показывает список томов, которые являются предпочитаемым механизмом для сохранения данных, генерируемых и используемых контейнерами Docker.
docker rm — удаляет один и более контейнеров, например, docker rm my_container.
docker rmi — удаляет один и более образов, например, docker rmi my_image.
docker stop — останавливает один и более контейнеров. Команда docker stop my_container остановит один контейнер, а docker stop $(docker ps -a -q) — все запущенные. Более грубый способ — использовать docker kill my_container, который не пытается сначала аккуратно завершить процесс.
docker kill — принудительно убить контейнер.

Можно комбинировать эти команды. Например, для очистки всех контейнеров и образов:
docker kill $(docker ps -q) — Останавливаем все запущенные контейнеры .
docker rm $(docker ps -a -q) — Удаляем все остановленные контейнеры.
docker rmi $(docker images -q) — Удаляем все образы.

🔗 Сохраняй, чтобы не потерять!

#docker #cheatsheet #doc

🐳 Docker совет, который знают не все: кэширование между билдами с --mount=type=cache

Вместо того чтобы каждый раз переустанавливать зависимости, можно кэшировать директории прямо в Dockerfile — особенно удобно для pip, npm, apt и т.д.

📦 Пример — ускоряем установку Python-зависимостей:


RUN --mount=type=cache,target=/root/.cache/pip \
pip install -r requirements.txt


🔍 Что даёт:

- сохраняет кэш пакетов между сборками

- ускоряет билд в 2–5 раз

- уменьшает загрузку сети и слои образа

⚙️ Работает только при включённом Docker BuildKit (DOCKER_BUILDKIT=1)


📌 Маленький флаг — большой прирост скорости.

Docker Cookbook

Автор: Sébastien Goasguen
Год издания: 2015

#docker #en #книга

Скачать книгу

🐳 Большая шпаргалка по Docker

#cheatsheet #docker

Вопрос на собеседовании.

Каково назначение docker_host?

Он задает URL или путь к сокету unix, используемые для соединения с API Docker. Значение по умолчанию:

unix://var/run/docker.sock

Для подключения к удаленному серверу обычно используется TCP, например:

tcp://192.0.1.20:3230

#собеседование

☕️ Cup — минималистичный инструмент для отслеживания обновлений контейнеров. Этот легковесный проект (всего 5.4 МБ!) сканирует образы в различных реестрах — от Docker Hub до Gitea и показывает доступные обновления без риска нарваться на лимиты API.

Что особенно удобно — Cup работает даже на Raspberry Pi и предлагает как CLI, так и веб-интерфейс с JSON-выводом для интеграций. Правда, в отличие от аналогов, он не умеет автоматически запускать пайплайны — зато идеально подходит для тех, кто предпочитает простые и прозрачные инструменты.

🤖 GitHub