🐳 Как устроен Docker: что происходит «под капотом»
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (
– Docker CLI (
– REST API — взаимодействие CLI и Daemon
👉 Пример:
3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг
При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
Daemon вызывает
7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (
8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
➡️ Подробнее
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (
dockerd) управляет контейнерами, образами, сетями – Docker CLI (
docker) — интерфейс пользователя – REST API — взаимодействие CLI и Daemon
👉 Пример:
docker run nginx → CLI отправляет запрос, Daemon находит образ, создаёт контейнер, запускает процесс.3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг
Dockerfile создаёт новый слой. При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
runc для запуска контейнера (соответствует OCI Runtime Spec). Daemon вызывает
runc, который через clone(), setns(), chroot() изолирует процесс.7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (
/var/lib/docker) или в реестре (Docker Hub, GitLab Container Registry).8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
-p, создать собственные сети, объединять контейнеры через docker network connect.В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
/proc виден). Для production стоит ограничивать права (например, --cap-drop).10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
runc для изоляции процесса7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍8🔥5👌1
💡 Docker Tip: ускоряем сборку с помощью BuildKit + Target Stage
Многие знают про
👉 Если у тебя много стадий (например, build + тесты + production), ты можешь не собирать всё каждый раз, а запускать только нужную стадию:
Пример:
📈 Что это даёт:
- ⚡️ Пропускаешь финальную сборку (например, оптимизацию прод-образа)
- 🔍 Быстро тестируешь только нужный слой (например, dev-stage)
- 💾 Экономишь кэш и ускоряешь сборку — собирается только то, что нужно
🔥 Включи BuildKit по умолчанию
Добавь в файл
Теперь
---
🎯 Бонус-совет: кэш зависимостей через RUN --mount=type=cache
Для Python:
Для npm:
✅ Это ускоряет повторные билды на десятки процентов 💨
👀 Итог:
Не просто строй Docker-образы — строй их умно. BuildKit + правильные таргеты + кэш → твой билд летает 🚀
Многие знают про
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 + правильные таргеты + кэш → твой билд летает 🚀
👍7❤3
А ты сможешь пройти тест на «Data Engineer»?
🔥 ПРОЙТИ ТЕСТ: https://vk.cc/cMqglw
Проверь себя - пройди тест и оцени свой уровень навыков, а также свою готовность к обучению на курсе — «Data Engineer» от Отус.
Про курс! Под руководством практикующих экспертов ты сможешь:
💚 освоить инструменты data-инженерии
💚 изучить на практике Apache Spark, Airflow и ClickHouse, 💚 создавать эффективные ETL-процессы и пайплайны обработки данных
🎁 Промокод на доп.скидку на курс DE_10 до 31 мая, позволяющий увеличить скидку до 20% со скидками мая.
Проверь себя - пройди тест и оцени свой уровень навыков, а также свою готовность к обучению на курсе — «Data Engineer» от Отус.
Про курс! Под руководством практикующих экспертов ты сможешь:
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576Please open Telegram to view this post
VIEW IN TELEGRAM
🚀 8 советов и приёмов Docker
1. 🔄 Включите VirtioFS для ускоренной работы с файлами на Mac
Если вы используете Docker на macOS, включите VirtioFS — это современный способ шаринга файлов между хостом и контейнером. Он быстрее традиционного osxfs. Это особенно заметно при работе с Node.js, Golang и другими языками с множеством файлов.
👉 Docker Desktop → Settings → Experimental Features → Enable VirtioFS
2. 🧪 Используйте Docker Scout для анализа уязвимостей
Docker Scout позволяет находить и устранять уязвимости в образах. Он интегрируется с Docker Desktop и CLI, позволяя видеть CVE прямо в терминале:
docker scout cves nginx:latest
3. 🌐Используйте Docker Dev Environments для совместной работы над проектами.
Создавайте и делитесь полностью настроенными dev-средами — вы можете заранее настроить окружение для разработки (dev-среду): установить все необходимые программы, зависимости, настройки и т.д.
Которые можно запускать в один клик — чтобы начать работу, новому разработчику достаточно просто нажать одну кнопку, и у него появится полностью рабочее окружение, как у остальных членов команды.
Отлично для онбординга новых разработчиков — это сильно ускоряет процесс подключения новых людей к проекту: им не надо тратить время на установку и настройку ПО, всё уже готово.
Всё основано на Docker Desktop и Compose — для работы используется программа Docker Desktop и инструмент Docker Compose (описывает, какие контейнеры запускать и как их настраивать).
Пример:
Ты можешь создать dev-среду с нужной версией Python, Node.js, базой данных и всеми зависимостями, сохранить её как dev environment и отправить ссылку коллеге. Он открывает её через Docker Desktop и сразу получает полностью готовую среду — без ручных установок.
4. ☁️ Ускорьте сборку образов с Docker Build Cloud
Docker Build Cloud теперь доступен всем. Это облачная сборка, которая сокращает время билда до 70%. Используйте её в больших проектах и CI/CD.
Ссылка: https://www.docker.com/products/docker-build-cloud/
5. 📦 Расширьте Docker Desktop с помощью Extensions
Можно добавлять расширения — например, для управления контейнерами, базами данных, или даже для генерации кода. Всё через интерфейс Docker Desktop. Можно создавать свои.
6. 🚦 Добавьте HEALTHCHECK в образы
Это поможет отслеживать работоспособность контейнера. Например:
7. 🧰 Используйте docker init для быстрого старта
Команда docker init автоматически создаёт Dockerfile и docker-compose.yml на основе вашего проекта. Быстро, просто, удобно.
8. 📊 Отслеживайте изменения с помощью docker scout compare
Сравнивайте два образа и смотрите, какие слои, пакеты и уязвимости изменились:
docker scout compare my-image:v1 my-image:v2
1. 🔄 Включите VirtioFS для ускоренной работы с файлами на Mac
Если вы используете Docker на macOS, включите VirtioFS — это современный способ шаринга файлов между хостом и контейнером. Он быстрее традиционного osxfs. Это особенно заметно при работе с Node.js, Golang и другими языками с множеством файлов.
👉 Docker Desktop → Settings → Experimental Features → Enable VirtioFS
2. 🧪 Используйте Docker Scout для анализа уязвимостей
Docker Scout позволяет находить и устранять уязвимости в образах. Он интегрируется с Docker Desktop и CLI, позволяя видеть CVE прямо в терминале:
docker scout cves nginx:latest
3. 🌐Используйте Docker Dev Environments для совместной работы над проектами.
Создавайте и делитесь полностью настроенными dev-средами — вы можете заранее настроить окружение для разработки (dev-среду): установить все необходимые программы, зависимости, настройки и т.д.
Которые можно запускать в один клик — чтобы начать работу, новому разработчику достаточно просто нажать одну кнопку, и у него появится полностью рабочее окружение, как у остальных членов команды.
Отлично для онбординга новых разработчиков — это сильно ускоряет процесс подключения новых людей к проекту: им не надо тратить время на установку и настройку ПО, всё уже готово.
Всё основано на Docker Desktop и Compose — для работы используется программа Docker Desktop и инструмент Docker Compose (описывает, какие контейнеры запускать и как их настраивать).
Пример:
Ты можешь создать dev-среду с нужной версией Python, Node.js, базой данных и всеми зависимостями, сохранить её как dev environment и отправить ссылку коллеге. Он открывает её через Docker Desktop и сразу получает полностью готовую среду — без ручных установок.
4. ☁️ Ускорьте сборку образов с Docker Build Cloud
Docker Build Cloud теперь доступен всем. Это облачная сборка, которая сокращает время билда до 70%. Используйте её в больших проектах и CI/CD.
Ссылка: https://www.docker.com/products/docker-build-cloud/
5. 📦 Расширьте Docker Desktop с помощью Extensions
Можно добавлять расширения — например, для управления контейнерами, базами данных, или даже для генерации кода. Всё через интерфейс Docker Desktop. Можно создавать свои.
6. 🚦 Добавьте HEALTHCHECK в образы
Это поможет отслеживать работоспособность контейнера. Например:
HEALTHCHECK CMD curl --fail http://localhost:3000/health || exit 17. 🧰 Используйте docker init для быстрого старта
Команда docker init автоматически создаёт Dockerfile и docker-compose.yml на основе вашего проекта. Быстро, просто, удобно.
docker init8. 📊 Отслеживайте изменения с помощью docker scout compare
Сравнивайте два образа и смотрите, какие слои, пакеты и уязвимости изменились:
docker scout compare my-image:v1 my-image:v2
Docker
Build Docker Images Faster | Docker Build Cloud
Docker Build Cloud helps developers build Docker images faster using the cloud while preserving existing workflows and freeing up local resources.
👍6👌1
Большой тест по Docker для новичков из 85 вопросов - https://qarocks.ru/test_post/big-docker-quiz/
Проходите и пишите у кого 85 из 85:)
P.S если найдете ошибки в ответах, присылайте попросим исправить)
Проходите и пишите у кого 85 из 85:)
P.S если найдете ошибки в ответах, присылайте попросим исправить)
🔥7❤5👌1
«Штурвал 2.10»: встречайте поддержку Yandex Cloud и настоящую мультитенантность
10 июня в 17:00 мск встречаемся на обзорном вебинаре по релизу Kubernetes-платформы «Штурвал 2.10». Ребята из «Лаборатории Числитель» расскажут про два самых интересных обновления:
▪️Поддержку провайдера Yandex Cloud — как управлять кластерами в этом облаке так же, как у себя в инфраструктуре.
▪️Появление тенантов — как централизованно управлять доступами на понятных для бизнеса абстракциях, например, таких как «департамент», «система» и «окружение».
Вебинар будет интересен DevOps-инженерам, разработчикам, сотрудникам служб эксплуатации, специалистам по информационной безопасности, руководителям и всем, кто заинтересован в контейнеризации.
✔️ Регистрация
10 июня в 17:00 мск встречаемся на обзорном вебинаре по релизу Kubernetes-платформы «Штурвал 2.10». Ребята из «Лаборатории Числитель» расскажут про два самых интересных обновления:
▪️Поддержку провайдера Yandex Cloud — как управлять кластерами в этом облаке так же, как у себя в инфраструктуре.
▪️Появление тенантов — как централизованно управлять доступами на понятных для бизнеса абстракциях, например, таких как «департамент», «система» и «окружение».
Вебинар будет интересен DevOps-инженерам, разработчикам, сотрудникам служб эксплуатации, специалистам по информационной безопасности, руководителям и всем, кто заинтересован в контейнеризации.
✔️ Регистрация
💩2🤔1🐳1
🐳 Задача для продвинутых DevOps-инженеров: «Странный Docker контейнер, который тормозит хост»
🧠 Уровень: Senior DevOps / SRE
🎯 Цель: Найти причину деградации хост-системы при работе контейнера, не убивая продакшен
📍 Ситуация:
Ты запускаешь относительно простой контейнер:
2. Выясняем, что контейнер запускает тысячи потоков (например,
3. Используем
4. Ставим лимиты:
- Через
- Или в
5. Добавляем в
📌 Вывод:
Контейнеры могут перегружать хост не по CPU/Memory, а по количеству потоков, сокетов, inode или I/O. Это не видно в
💬 Отличный сценарий для продвинутого собеса на DevOps / Platform-инженера.
🧠 Уровень: 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-инженера.
❤13
Расширенный_гайд_по_Docker_для_DevOps_специалистов_1_2.pdf
391.1 KB
• как устроен Docker изнутри
• как упаковать любое приложение в контейнер
• как запускать десятки сервисов одной командой
• как дебажить, оптимизировать и защищать контейнеры
• как не сойти с ума с volumes, networks и образами
Сохраняй и делись с коллегами, чтобы не потерять
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍7
🧠 DevOps-задача: "Обманчиво здоровый контейнер"
Условие:
У тебя настроен Docker-контейнер с приложением и прописан
В CI всё работает. В Kubernetes — контейнер вечно “healthy”, но:
- Метрики не собираются
- Ответы приложения не приходят
- От клиентов жалобы
- Никаких рестартов пода не происходит
При этом
Задача:
Найди источник проблемы, объясни, почему
Разбор:
🔍 Подвох №1: HEALTHCHECK в Docker — не работает в Kubernetes
- Kubernetes игнорирует
- Вместо этого использует
📌 Поэтому контейнер кажется "здоровым", но на самом деле Kube о нём ничего не знает
🛠 Решение:
В
Это активирует реальную проверку на уровне Kubernetes и позволит поду:
- перезапускаться при зависании (liveness)
- исключаться из сервисов (readiness)
🎯 Что проверяет задача:
• Понимание различий между Docker и Kubernetes health mechanisms
• Навык выявления "ложноположительных" статусов
• Умение читать реальные признаки деградации (метрики, жалобы, тайм-аут)
• Установка правильных probes — ключ к HA-системам
💡 В реальной жизни такие ошибки ведут к "здоровым", но абсолютно мертвым сервисам.
Условие:
У тебя настроен 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-системам
💡 В реальной жизни такие ошибки ведут к "здоровым", но абсолютно мертвым сервисам.
👍12👎3❤2
⚡️ Топ-3 полезных советов для Docker на сегодня:
1️⃣ Очищайте билд-кэш через
Вместо полной очистки кэша (
2️⃣ Добавьте в
✅ Это сократит размер контекста сборки на 50–90%, особенно в проектах с большим числом зависимостей или history-heavy репозиториями.
Меньше контекста → быстрее копирование → быстрее билд.
3️⃣ Чтобы увидеть Dockerfile любого образа с Docker Hub используйте:
1️⃣ Очищайте билд-кэш через
--no-cache-filter.Вместо полной очистки кэша (
docker builder prune) удаляйте только указанные слои:
docker builder prune --filter 'until=24h' --no-cache-filter alpine2️⃣ Добавьте в
.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}'👍12❤1
💡 Docker Tip: ускоряем сборку с помощью BuildKit + Target Stage
Многие знают про
👉 Если у тебя много стадий (например, build + тесты + production), ты можешь не собирать всё каждый раз, а запускать только нужную стадию:
Пример:
📈 Что это даёт:
- ⚡️ Пропускаешь финальную сборку (например, оптимизацию прод-образа)
- 🔍 Быстро тестируешь только нужный слой (например, dev-stage)
- 💾 Экономишь кэш и ускоряешь сборку — собирается только то, что нужно
🔥 Включи BuildKit по умолчанию
Добавь в файл
Теперь
---
🎯 Бонус-совет: кэш зависимостей через RUN --mount=type=cache
Для Python:
Для npm:
✅ Это ускоряет повторные билды на десятки процентов 💨
👀 Итог:
Не просто строй Docker-образы — строй их умно. BuildKit + правильные таргеты + кэш → твой билд летает 🚀
Многие знают про
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 + правильные таргеты + кэш → твой билд летает 🚀
👍5❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23😁7👍3❤1
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7😴2👍1