Docker для Windows: установка, использование и разработка

Установка Docker Desktop и настройка WSL 2/Hyper-V

Docker на Windows чаще всего используют через Docker Desktop — приложение, которое устанавливает Docker Engine и предоставляет удобные настройки, интеграцию с WSL 2, управление ресурсами и сетевыми параметрами.

В этой статье вы:

поймёте разницу между бэкендами WSL 2 и Hyper-V

подготовите Windows к установке Docker Desktop

установите Docker Desktop

настроите WSL 2 или Hyper-V (в зависимости от вашей редакции Windows и требований)

проверите работоспособность Docker

Что такое Docker Desktop на Windows и какие есть варианты запуска

На Windows Docker Desktop может работать с двумя основными бэкендами виртуализации:

WSL 2 (рекомендуемый вариант для большинства разработчиков)

Hyper-V (часто используется в корпоративной среде и на некоторых конфигурациях)

!Сравнение архитектуры Docker Desktop с WSL 2 и Hyper-V

WSL 2

WSL 2 — это подсистема Windows для запуска Linux, использующая лёгкую виртуализацию. Docker Desktop умеет размещать Docker Engine внутри WSL 2 и подключаться к нему.

Плюсы:

удобная работа с Linux-инструментами прямо в Windows

как правило, более комфортный опыт разработки

простая интеграция с дистрибутивом Linux

Hyper-V

Hyper-V — гипервизор Windows. Docker Desktop может запускать Linux VM под Hyper-V и использовать её как основу для Docker Engine.

Плюсы:

стандартный путь в средах, где WSL 2 ограничен политиками

иногда проще для унифицированных корпоративных образов Windows

Требования перед установкой

Перед установкой проверьте следующие условия.

Аппаратная виртуализация

Нужна включённая виртуализация (Intel VT-x или AMD-V) в BIOS/UEFI.

Признаки проблем:

Docker Desktop сообщает, что виртуализация недоступна

WSL 2 не запускается или не устанавливается

Поддерживаемые версии Windows

Рекомендовано использовать актуальные Windows 10/11.

Официальная документация Docker Desktop для Windows:

Install Docker Desktop on Windows

Выбор: WSL 2 или Hyper-V

Ниже практическая таблица выбора.

| Критерий | WSL 2 | Hyper-V | |---|---|---| | Подходит большинству разработчиков | Да | Иногда | | Нужен отдельный Linux-дистрибутив (Ubuntu и т. п.) | Да | Нет (VM управляется Docker Desktop) | | Удобство работы с Linux-CLI | Высокое | Среднее | | Часто используется в корпоративных политиках | Иногда | Часто |

Рекомендация:

если вы разрабатываете и можете использовать WSL 2 — выбирайте WSL 2

если у вас корпоративные ограничения или требуется Hyper-V — используйте Hyper-V

Установка Docker Desktop

Шаги установки

Откройте официальную страницу установки.

Скачайте установщик Docker Desktop.

Запустите установщик от имени пользователя с правами установки.

На этапе выбора бэкенда отметьте вариант:

- Use WSL 2 instead of Hyper-V (если планируете WSL 2) - или используйте Hyper-V (если требуется)

Завершите установку и перезагрузите компьютер, если установщик попросит.

Документация:

Install Docker Desktop on Windows

Настройка WSL 2

Этот раздел нужен, если вы выбираете WSL 2.

Установка WSL

Самый простой способ — установить WSL командой.

Откройте PowerShell от имени администратора.

Выполните команду:

Перезагрузите компьютер, если потребуется.

Официальная документация:

Install WSL

Проверка версии WSL и установка WSL 2 по умолчанию

Проверьте, какие дистрибутивы установлены и какие версии WSL они используют:

Чтобы сделать WSL 2 вариантом по умолчанию для новых дистрибутивов:

Справка по базовым командам WSL:

Basic commands for WSL

Установка дистрибутива Linux

Если wsl --install не установил дистрибутив автоматически или вы хотите другой:

Установите, например, Ubuntu из Microsoft Store.

Запустите Ubuntu из меню Пуск.

Дождитесь первичной настройки и создайте пользователя Linux.

Включение интеграции WSL в Docker Desktop

Откройте Docker Desktop:

Перейдите в Settings.

Откройте Resources → WSL Integration.

Включите интеграцию для нужного дистрибутива (например, Ubuntu).

После этого Docker Desktop сможет использовать WSL 2 окружение.

Важное про файлы и производительность

Практическое правило:

для лучшей производительности держите код внутри файловой системы Linux (например, в ~/projects внутри Ubuntu)

доступ к файлам на диске Windows (например, C:\) из Linux возможен, но при некоторых сценариях разработки может быть медленнее

Настройка Hyper-V

Этот раздел нужен, если вы выбираете Hyper-V или ваш компьютер/политики не позволяют WSL 2.

Включение Hyper-V

Включить Hyper-V можно через компоненты Windows.

Откройте Включение или отключение компонентов Windows.

Включите:

- Hyper-V - при необходимости также Windows Hypervisor Platform

Перезагрузите компьютер.

Официальная документация Microsoft:

Hyper-V virtualization

Включение Hyper-V в Docker Desktop

Откройте Docker Desktop.

Перейдите в Settings.

В разделе выбора бэкенда убедитесь, что используется Hyper-V.

Примечание: конкретные названия переключателей могут немного меняться между версиями Docker Desktop, поэтому ориентируйтесь на логику выбора бэкенда (WSL 2 или Hyper-V).

Настройка ресурсов Docker Desktop

Docker Desktop использует ресурсы вашего компьютера. На слабых машинах имеет смысл ограничить потребление.

В Docker Desktop в Settings часто настраивают:

лимиты CPU

лимиты RAM

размер диска для образов и контейнеров

Рекомендации:

если у вас 16 ГБ RAM, часто комфортно выделить Docker 4–8 ГБ под типовую разработку

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

Проверка установки

Проверка версии Docker

В PowerShell или Windows Terminal выполните:

Тестовый запуск контейнера

Запустите официальный тестовый образ:

Ожидаемый результат:

Docker скачает образ (если он ещё не скачан)

контейнер выведет сообщение о том, что установка работает

контейнер завершится, а благодаря --rm будет удалён автоматически

Типичные проблемы и быстрые решения

Docker Desktop не стартует из-за виртуализации

Проверьте, включена ли виртуализация в BIOS/UEFI.

Убедитесь, что включены нужные компоненты Windows (WSL 2 или Hyper-V).

Перезагрузите компьютер после изменения компонентов.

WSL-дистрибутив не виден в интеграции Docker Desktop

Убедитесь, что дистрибутив установлен и запускается.

Выполните wsl -l -v и проверьте, что версия дистрибутива — 2.

В Docker Desktop включите интеграцию в Resources → WSL Integration.

Конфликт с корпоративными политиками

Если в компании запрещён WSL 2 или требуются определённые настройки, используйте Hyper-V и уточните требования у администраторов. В некоторых организациях настройки виртуализации и гипервизора централизованно управляются.

Итоги

Теперь у вас установлен Docker Desktop, выбран и настроен бэкенд виртуализации (WSL 2 или Hyper-V), а также выполнена проверка через запуск hello-world. В следующих материалах курса логично переходить к базовым операциям Docker: образы, контейнеры, тома, сети и работа с Dockerfile на Windows.

Базовые команды: образы, контейнеры и реестр

После установки Docker Desktop и настройки WSL 2 или Hyper-V (из предыдущей статьи) следующий шаг — научиться управлять образами, контейнерами и понимать, как работает реестр (registry), откуда образы скачиваются и куда публикуются.

В этой статье вы разберёте:

что такое образ и контейнер и чем они отличаются

как скачивать, запускать и удалять контейнеры

как смотреть логи и заходить внутрь контейнера

что такое реестр (Docker Hub и другие) и как работать с pull/push

!Как связаны реестр, образ и контейнер и какими командами вы переходите между ними

Термины: образ, контейнер, реестр

Образ (image)

Образ — это шаблон, из которого создаются контейнеры. Внутри образа обычно есть:

файловая система (например, Linux-дистрибутив и установленные пакеты)

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

Образы обычно версионируют тегами (tags), например nginx:latest или python:3.12.

Контейнер (container)

Контейнер — это запущенный (или остановленный) экземпляр образа.

Практическая аналогия:

образ — как установочный ISO или шаблон

контейнер — как запущенная программа, созданная по этому шаблону

Контейнеры изолированы, но используют ядро ОС хоста (на Windows через виртуализацию Docker Desktop).

Реестр (registry)

Реестр — это сервер-хранилище образов.

Самый известный публичный реестр — Docker Hub.

официальный сайт: Docker Hub

документация по реестрам: Docker Registry overview

Также бывают частные реестры (например, в компании), и облачные (например, GHCR у GitHub).

Проверка, что Docker работает

В Windows Terminal или PowerShell:

Проверка, что вы можете запускать контейнеры:

Если это работает, можно переходить к базовым командам.

Как читать имена образов: repository:tag

В Docker имя образа часто выглядит так:

nginx:latest

redis:7

Где:

nginx — имя репозитория образа (repository)

latest или 7 — тег (tag)

Если тег не указан, Docker по умолчанию использует latest, то есть nginx эквивалентен nginx:latest.

Важно: latest — это просто тег, а не гарантия «самой новой и лучшей версии».

Команды для образов

Поиск образов (Docker Hub)

Искать образы можно на сайте Docker Hub, но есть и команда:

Она показывает найденные репозитории и базовую информацию.

Скачивание образа: docker pull

Скачать образ локально:

Docker скачает слои образа и сохранит их на диске (в хранилище Docker Desktop).

Документация:

docker pull

Просмотр локальных образов: docker images

Посмотреть, какие образы уже есть:

Или более современный вариант:

Документация:

docker images

Удаление образа: docker rmi

Удалить образ по имени или ID:

Если у вас есть контейнеры, которые используют этот образ, Docker может не дать удалить образ, пока вы не удалите контейнеры.

Документация:

docker rmi

Команды для контейнеров

Запуск контейнера: docker run

docker run делает сразу несколько вещей:

при необходимости скачивает образ (как pull)

создаёт контейнер

запускает контейнер

Пример: запустим Nginx и пробросим порт 8080 на ваш компьютер.

Расшифровка ключей:

--name web — задаёт имя контейнера (удобно для управления)

-p 8080:80 — пробрасывает порт: с вашего ПК 8080 на порт контейнера 80

Теперь в браузере можно открыть http://localhost:8080.

Полезные варианты запуска:

Документация:

docker run

Список контейнеров: docker ps

Показать только запущенные:

Показать все (включая остановленные):

Документация:

docker ps

Остановка и запуск: docker stop, docker start

Остановить контейнер:

Запустить остановленный контейнер снова:

Документация:

docker stop

docker start

Удаление контейнера: docker rm

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

Удалить контейнер принудительно (даже если запущен):

Документация:

docker rm

Логи контейнера: docker logs

Посмотреть логи:

Смотреть логи в режиме «следить»:

Документация:

docker logs

Выполнить команду внутри контейнера: docker exec

Частая задача — зайти внутрь контейнера и выполнить команду.

Например, откроем shell в контейнере Nginx (обычно это sh):

Расшифровка:

-i — интерактивный режим

-t — выделить псевдотерминал (удобно для shell)

Выйти можно командой exit.

Документация:

docker exec

Информация о контейнере: docker inspect

Если нужно увидеть подробную конфигурацию (IP, проброшенные порты, переменные окружения и т. п.):

Команда возвращает большой JSON. В реальной работе её часто используют для диагностики.

Документация:

docker inspect

Реестр и публикация образов

Docker Hub и авторизация: docker login

Чтобы публиковать образы в Docker Hub, нужен аккаунт.

Войти:

Docker попросит логин и пароль (или токен). Для повышения безопасности часто используют access token.

Документация:

docker login

Теги для публикации: docker tag

Чтобы отправить образ в Docker Hub, имя образа должно быть в формате:

ваш_логин/имя_репозитория:тег

Допустим, у вас есть локальный образ myapp:1.0. Добавим тег для Docker Hub:

Документация:

docker tag

Отправка образа в реестр: docker push

Отправить образ в Docker Hub:

Документация:

docker push

Как понимать pull и push в повседневной работе

Типовой цикл в команде:

разработчик или CI публикует образ в реестр (push)

другие разработчики или серверы скачивают и запускают его (pull + run)

Это одна из причин, почему Docker удобен: одинаковый образ можно запускать на разных машинах.

Практический мини-сценарий: скачать, запустить, проверить, убрать

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

Скачать образ:

Запустить контейнер в фоне:

Убедиться, что контейнер работает:

Посмотреть логи:

Остановить и удалить контейнер:

При необходимости удалить образ:

Особенности Docker на Windows, которые важно помнить

В большинстве сценариев Docker Desktop на Windows запускает Linux-контейнеры (внутри WSL 2 или VM Hyper-V), даже если команды вы вводите из PowerShell.

Пути к файлам и работа с файловой системой могут отличаться, особенно когда вы начнёте монтировать папки в контейнер (это будет отдельной темой в следующих материалах курса).

Если вы используете WSL 2, часто удобнее выполнять Docker-команды прямо из Linux-дистрибутива (Ubuntu в WSL), но это не обязательно: Docker CLI работает и в PowerShell.

Итоги

Вы освоили базовую модель Docker:

реестр хранит образы

образы скачиваются локально и служат шаблоном

контейнеры запускаются из образов и выполняют вашу задачу

Вы знаете основные команды управления:

для образов: pull, images, rmi, tag, push

для контейнеров: run, ps, stop, start, rm, logs, exec, inspect

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

Тома, файловая система Windows и проброс портов

После того как вы научились работать с образами и контейнерами (pull, run, ps, logs, exec) из предыдущей статьи, возникает практический вопрос: как сохранять данные между перезапусками контейнеров и как удобно разрабатывать, редактируя файлы на Windows так, чтобы контейнер их сразу видел.

В этой статье вы разберёте:

зачем нужны тома и почему данные контейнера нельзя хранить “просто внутри контейнера”

разницу между volume и bind mount

особенности путей и производительности файловой системы на Windows с Docker Desktop и WSL 2

как работает проброс портов (-p) и как правильно “открывать” сервисы контейнера на localhost

!Иллюстрация двух ключевых потоков: файлы (тома/монтирование) и сеть (проброс портов)

Почему данные “в контейнере” не считаются сохранёнными

Контейнер создаётся из образа и поверх него получает свой пишущий слой. Если контейнер удалить (docker rm), этот слой исчезает.

Это удобно для одноразовых задач, но неудобно для:

баз данных (PostgreSQL, MySQL, Redis)

очередей и хранилищ

разработки (когда код и артефакты должны жить вне контейнера)

Чтобы данные переживали пересоздание контейнеров, Docker использует механизмы монтирования:

volume (управляемый Docker том)

bind mount (примонтированная папка с вашей машины)

Официальная документация:

Docker storage overview

Docker volumes

Docker bind mounts

Volume и bind mount: что выбрать

Короткое сравнение

| Критерий | Volume | Bind mount | |---|---|---| | Кто управляет размещением данных | Docker | Вы (путь на хосте) | | Удобно для баз данных | Да | Иногда | | Удобно для разработки (код на хосте) | Иногда | Да | | Переносимость между машинами | Выше | Ниже (зависит от путей) | | Риск “сломать” права/структуру данных вручную | Ниже | Выше |

Практическое правило:

для данных сервисов (БД, кэши) чаще выбирайте volume

для исходников проекта чаще выбирайте bind mount

Docker volumes на практике

Посмотреть, создать и удалить volume

Список томов:

Создать том:

Посмотреть детали (вернётся JSON):

Удалить том (если он не используется контейнерами):

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

> docker volume prune удаляет только тома, которые не используются ни одним контейнером. Это полезно для очистки диска, но в реальной работе используйте осторожно.

Пример: PostgreSQL с volume

Запустим PostgreSQL так, чтобы данные переживали удаление контейнера.

Создайте том:

Запустите контейнер и примонтируйте том в стандартный путь данных PostgreSQL:

Проверьте, что контейнер жив:

Теперь вы можете удалить контейнер, пересоздать его с тем же -v pgdata:/var/lib/postgresql/data, и данные останутся.

Bind mount: монтируем папку проекта в контейнер

Bind mount подключает реальную папку с вашей машины внутрь контейнера.

Типовой сценарий: локальная папка с кодом → контейнер с интерпретатором/сервером → вы редактируете файлы в IDE на Windows, а контейнер сразу видит изменения.

Два синтаксиса: -v и --mount

Оба варианта работают, но --mount обычно понятнее.

Пример через --mount:

Где:

source или левая часть в -v — путь на хосте (Windows или WSL)

target или правая часть в -v — путь внутри контейнера (обычно Linux-путь)

-w /app — рабочая директория (аналог cd /app перед запуском команды)

Документация:

docker run

Важные особенности путей и файловой системы на Windows

Docker Desktop чаще всего запускает Linux-контейнеры, поэтому путь внутри контейнера почти всегда будет Linux-формата (/app, /var/lib/...). А вот путь на хосте зависит от того, откуда вы запускаете команду.

Если вы запускаете Docker-команды из PowerShell

Чаще всего используют:

{PWD}",target=/app alpine:3.20 ls -la /app

bash docker run --rm -it --mount type=bind,source="{PWD}\site",target=/usr/share/nginx/html \ nginx:latest `

Откройте в браузере http://localhost:8080.

Измените index.html на Windows и обновите страницу: изменения должны примениться без пересборки образа.

Итоги

Теперь вы умеете:

объяснить, почему данные внутри контейнера не переживают его удаление

различать volume и bind mount и выбирать подходящий вариант

монтировать папки проекта в контейнер с учётом особенностей путей Windows и WSL 2

публиковать порты контейнера на хост с помощью -p и диагностировать типовые проблемы

Следующий логичный шаг в курсе — перейти от использования готовых образов к созданию своих: писать Dockerfile`, собирать образы и повторяемо запускать приложения в Docker на Windows.

Сети Docker и взаимодействие контейнеров в Windows

Docker редко используют для запуска одного контейнера. Типичный сценарий разработки — несколько сервисов: веб-приложение, база данных, кеш, воркер. Чтобы они работали как единое целое, нужно понимать сеть Docker: как контейнеры находят друг друга, какие порты доступны “наружу”, и какие особенности есть у Docker Desktop на Windows (WSL 2/Hyper-V).

В предыдущих статьях вы научились:

устанавливать Docker Desktop и выбирать WSL 2 или Hyper-V

запускать контейнеры и управлять образами

использовать тома и пробрасывать порты на localhost

Теперь добавим сетевую часть: взаимодействие контейнеров между собой.

!Общая картина: контейнеры общаются внутри сети Docker, а доступ с Windows идёт через опубликованные порты

Базовые понятия: что такое сеть Docker

Docker создаёт виртуальные сети и подключает к ним контейнеры. У контейнера появляются:

сетевой интерфейс внутри выбранной сети

IP-адрес внутри этой сети

(в большинстве случаев) возможность обращаться к другим контейнерам по имени

Важно различать два типа трафика:

внутренний трафик между контейнерами внутри Docker-сети

доступ с хоста (Windows) к контейнеру через публикацию портов (-p)

Официальные материалы:

Docker networking overview

docker network (CLI)

Какие типы сетей встречаются чаще всего

На Docker Desktop под Windows обычно используются те же типы сетей, что и на Linux.

| Тип сети | Когда используют | Что важно понимать | |---|---|---| | bridge (по умолчанию) | Простые запуски docker run | Контейнеры могут общаться, но лучше создавать user-defined сеть для DNS по имени | | user-defined bridge | Почти всегда для нескольких сервисов | Контейнеры легко находят друг друга по имени, удобнее управлять изоляцией | | host | Специальные сценарии производительности/сетевой диагностики | На Docker Desktop (Linux-контейнеры) поведение может отличаться от “чистого Linux” | | none | Максимальная изоляция | Контейнер без сети (почти всегда редкость) |

Для разработки связки “web + db” базовый выбор — user-defined bridge network.

Почему user-defined bridge лучше, чем сеть по умолчанию

У Docker есть дефолтная сеть bridge, но для проекта из нескольких контейнеров обычно создают отдельную сеть, потому что:

контейнеры в user-defined сети стабильно резолвят друг друга по имени через встроенный DNS Docker

проще управлять изоляцией: сервисы в одной сети видят друг друга, в разных — не видят

проще мигрировать к Docker Compose (там сети создаются автоматически)

Практика: создаём сеть и подключаем контейнеры

Шаг 1. Создать сеть

В PowerShell или Windows Terminal:

Проверить:

Посмотреть детали:

Шаг 2. Запустить базу данных в сети

Запустим PostgreSQL и подключим его к сети app-net. Порт наружу публиковать не обязательно, если к БД будет обращаться только другой контейнер.

Если том pgdata ещё не создан, Docker создаст его автоматически (вы уже проходили тома в прошлой статье).

Шаг 3. Запустить “клиента” в той же сети и обратиться к db по имени

Проверим, что имя db резолвится внутри сети.

Вариант через временный контейнер с psql (внутри образа postgres он есть):

--network app-net подключает контейнер к сети

-h db означает “подключиться к хосту с именем db”

имя db — это имя контейнера, которое Docker DNS отдаёт внутри сети

> Если вы видите запрос пароля и можете подключиться — сеть и DNS работают.

Внутренние порты и опубликованные порты: ключевая разница

Контейнер может “слушать” порт внутри Docker-сети, но это не означает, что порт доступен с Windows.

Внутри Docker-сети контейнеры обращаются друг к другу напрямую (например, db:5432).

С Windows вы попадаете в контейнер обычно только через публикацию порта -p (например, localhost:8080).

Пример: опубликуем веб-сервис наружу, а БД оставим внутренней.

Теперь:

браузер на Windows открывает http://localhost:8080

контейнер web при необходимости может ходить к db:5432 (если в нём есть клиент и вы его настроили)

Документация по публикации портов:

Publishing ports

Как контейнеру обратиться к сервису на Windows

Иногда нужно обратное: контейнеру нужен доступ к сервису, запущенному на Windows (например, локальный API, прокси, отладочный сервер).

В Docker Desktop для этого обычно используют специальное имя:

host.docker.internal — “хост” (ваша Windows-машина) с точки зрения контейнера

Пример (внутри контейнера проверяем доступ к порту 3000 на Windows):

Если на Windows действительно что-то слушает localhost:3000, контейнер сможет обратиться к этому сервису через host.docker.internal:3000.

Документация Docker Desktop по сетевым особенностям:

Docker Desktop networking features

Особенности Docker-сети на Windows (WSL 2 и Hyper-V)

Когда вы запускаете Linux-контейнеры в Docker Desktop, они фактически работают внутри окружения виртуализации:

в режиме WSL 2 — внутри WSL 2 (лёгкая VM)

в режиме Hyper-V — внутри VM Hyper-V

Практические следствия:

localhost на Windows обычно работает для опубликованных портов, потому что Docker Desktop настраивает проброс.

прямой доступ к внутренним IP контейнеров с Windows обычно не нужен и часто не является стабильной точкой интеграции.

правильная модель: снаружи ходим на localhost:порт_хоста, внутри ходим по имени контейнера service:порт.

Диагностика: как понять, кто в какой сети и какие порты открыты

Посмотреть сети

Посмотреть, к каким сетям подключён контейнер

Ищите секцию NetworkSettings (JSON большой, но там видно сети и IP).

Посмотреть опубликованные порты

Или точечно:

Документация:

docker inspect

docker port

Типовые ошибки и как их исправлять

Ошибка: “в контейнере не находится имя другого контейнера”

Частые причины:

Контейнеры в разных сетях.

Используете дефолтный bridge и ожидаете поведения как в user-defined сети.

Решение:

Создайте сеть docker network create app-net.

Перезапустите контейнеры с --network app-net.

Ошибка: “приложение в контейнере не доступно с Windows”

Причина:

вы не опубликовали порт.

Решение:

запускайте с -p, например -p 8080:80.

Ошибка: “порт занят”

Причина:

на Windows уже кто-то слушает выбранный порт.

Решение:

выбрать другой порт хоста, например -p 8081:80, или освободить порт.

Практический сценарий: изолируем БД, публикуем только веб

Цель: сделать типовую “микроархитектуру” разработки.

Создайте сеть:

Запустите БД без -p:

Запустите веб и опубликуйте порт:

Проверьте, что извне доступен только веб:

в браузере откройте http://localhost:8080

к db с Windows вы не подключитесь по localhost:5432, потому что порт не публиковали

Эта модель часто используется по умолчанию: наружу открывают только то, что действительно нужно.

Итоги

Вы научились строить сетевую модель проекта на Docker Desktop под Windows:

различать внутренние соединения контейнеров и внешний доступ через -p

создавать user-defined bridge сеть и подключать к ней контейнеры

использовать DNS по имени контейнера (например, db) внутри сети

подключаться из контейнера к сервисам Windows через host.docker.internal

диагностировать сети и порты командами docker network ls, docker network inspect, docker port, docker inspect

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

Docker Compose и практический проект на Windows

Docker Compose решает типичную проблему, которая появляется сразу после изучения отдельных команд docker run: как повторяемо и удобно запускать несколько связанных контейнеров (web, база данных, кеш) одной командой, с сетями, томами и переменными окружения.

В предыдущих статьях курса вы уже разобрали:

как установить Docker Desktop и выбрать WSL 2 или Hyper-V

как управлять образами и контейнерами

как работают тома, bind mount и проброс портов

как контейнеры общаются через Docker-сети и почему удобно обращаться по имени сервиса

Теперь вы соберёте эти знания в единый сценарий разработки на Windows с помощью Docker Compose.

!Общая архитектура проекта Compose: внешний доступ через опубликованные порты и внутреннее взаимодействие по именам сервисов

Что такое Docker Compose и зачем он нужен

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

Compose особенно полезен, когда:

вам нужно поднять несколько контейнеров одной командой

важно зафиксировать настройки запуска (порты, переменные, тома, сети) в файле и делиться ими в команде

вы хотите, чтобы окружение разработки было воспроизводимым на разных Windows-машинах

Ключевая идея Compose:

вы декларативно описываете желаемую конфигурацию в YAML

команда docker compose up приводит систему к этому состоянию

Официальные ссылки:

Docker Compose overview

Compose file reference

docker compose CLI reference

Docker Compose на Windows: что нужно знать заранее

Где находится Compose

В актуальных версиях Docker Desktop Compose уже установлен и доступен как подкоманда Docker CLI:

docker compose ...

Проверьте версию:

Откуда запускать Compose: PowerShell или WSL

Оба варианта рабочие, но важно помнить про пути и производительность:

Если проект лежит в файловой системе WSL 2 (например, ~/projects/...), обычно быстрее запускать Compose из WSL.

Если проект лежит на диске Windows (например, C:\Users\...), удобнее запускать из PowerShell, но некоторые сценарии с большим количеством мелких файлов могут быть медленнее.

Практическое правило из предыдущих статей:

для активной разработки (Node.js, Python, сборщики) часто лучше хранить проект внутри WSL 2

Про окончания строк (CRLF/LF)

На Windows иногда встречается проблема, когда скрипт внутри Linux-контейнера не запускается из-за окончаний строк CRLF.

Чтобы уменьшить риск:

старайтесь хранить скрипты в репозитории с LF

при необходимости настройте Git под ваш проект (это командная политика, её лучше согласовать в команде)

Структура compose.yaml: основные блоки

Compose-файл описывает сервисы и связанные сущности (тома, сети, конфиги).

Минимальный каркас:

Чаще всего вы будете использовать:

services — список сервисов (контейнеров)

image или build — откуда берётся образ

ports — публикация портов наружу (как -p)

environment и env_file — переменные окружения

volumes — тома и bind mount

depends_on — порядок старта (но не полноценная гарантия готовности приложения)

networks — явные сети (часто можно использовать сеть по умолчанию)

Практический проект: web + PostgreSQL + Adminer

Цель проекта:

поднять веб-сервис, который подключается к PostgreSQL по имени db

хранить данные БД в Docker volume

открыть web наружу на localhost:8000

открыть Adminer (веб-интерфейс к БД) наружу на localhost:8080

Структура папок

Создайте папку проекта, например compose-demo, и структуру:

Код приложения (Python)

Файл web/requirements.txt:

Файл web/app.py:

Почему так:

приложение слушает 0.0.0.0, чтобы быть доступным из сети контейнера

имя хоста БД по умолчанию db совпадает с именем сервиса в Compose

Dockerfile для web

Файл web/Dockerfile:

Compose-файл

Файл compose.yaml в корне проекта:

Что здесь важно:

Сеть

1. Compose автоматически создаёт сеть проекта. 2. Все сервисы в одном Compose-файле по умолчанию попадают в одну сеть. 3. Поэтому web может обращаться к db по имени db.

Данные PostgreSQL

1. том pgdata хранит данные БД вне контейнера 2. при пересоздании контейнера db данные сохраняются

Порты

1. web публикует 8000:8000, и вы обращаетесь с Windows на http://localhost:8000 2. adminer публикует 8080:8080, и вы открываете http://localhost:8080 3. db не публикует порт наружу, он доступен только внутри Docker-сети

Готовность БД

1. healthcheck проверяет готовность PostgreSQL 2. depends_on с condition: service_healthy просит Compose подождать, пока db станет здоровым

Справка:

Compose services reference

Healthcheck in Compose

Запуск проекта на Windows

Из папки compose-demo выполните:

Проверить статус:

Посмотреть логи:

Проверка в браузере:

http://localhost:8000 должен вернуть JSON со статусом и временем из БД

http://localhost:8080 откроет Adminer

Подключение через Adminer:

System: PostgreSQL

Server: db

Username: postgres

Password: secret

Database: app

Ежедневные команды Compose (шпаргалка)

| Задача | Команда | |---|---| | Поднять сервисы в фоне | docker compose up -d | | Пересобрать и поднять | docker compose up -d --build | | Показать контейнеры проекта | docker compose ps | | Логи всех сервисов | docker compose logs -f | | Остановить (без удаления) | docker compose stop | | Запустить остановленные | docker compose start | | Остановить и удалить контейнеры и сеть | docker compose down | | Удалить ещё и тома (осторожно) | docker compose down -v | | Выполнить команду в сервисе | docker compose exec web sh |

Документация:

docker compose up

docker compose down

docker compose exec

Переменные окружения и файл .env

Чтобы не хранить секреты и параметры прямо в YAML, Compose поддерживает файл .env в каталоге проекта.

Пример .env:

И использование в compose.yaml:

Зачем это нужно:

один и тот же compose.yaml можно использовать на разных машинах

можно менять параметры без правки YAML

Справка:

Environment variables in Compose

Bind mount для разработки: быстрые правки кода без пересборки

В текущем виде web собирается из Dockerfile, и изменения в web/app.py потребуют пересборки (--build). Для разработки часто делают bind mount исходников.

Пример подхода (вариант для обучения, не обязательный для всех проектов):

Что здесь важно на Windows:

путь ./web:/app работает и в PowerShell, и в WSL, но производительность зависит от того, где лежит проект

если проект на диске Windows, большое количество операций с мелкими файлами может быть медленнее, чем внутри WSL 2

Связь с предыдущей статьёй про тома:

это тот же самый bind mount, только описанный декларативно в Compose

Типичные проблемы на Windows и диагностика

Порты заняты

Симптом:

Bind for 0.0.0.0:8000 failed: port is already allocated

Решение:

поменять порт хоста в ports, например "8001:8000"

остановить приложение на Windows, которое заняло порт

Приложение внутри контейнера не видит БД

Проверьте:

что сервисы в одном Compose-проекте

что в приложении указан DB_HOST=db, а не localhost

Локальная проверка сети изнутри:

Внутри контейнера можно проверить резолвинг имени:

Нужно подключиться контейнером к сервису на Windows

Если вам нужно, чтобы контейнер обратился к сервису, запущенному на Windows, используйте имя:

host.docker.internal

Это связывает текущую статью с предыдущей по сетям Docker.

Документация:

Docker Desktop networking features

Итоги

Вы научились применять Docker Compose на Windows как практический инструмент разработки:

описывать несколько сервисов в compose.yaml

поднимать проект командой docker compose up и управлять им как единым целым

связывать сервисы по именам (например, db) внутри сети Compose

хранить данные БД в volume и публиковать наружу только нужные порты

использовать .env и переменные окружения для параметризации

После этого шага ваш Docker-навык становится проектным: вы не просто запускаете отдельные контейнеры, а собираете воспроизводимые окружения разработки на Windows.