Использование контейнеров Docker в качестве среды разработки с Visual Studio Code
Получение, создание и настройка среды разработки на основе контейнеров на основе контейнеров на основе контейнера в Visual Studio Code.
Цели обучения
По завершении этого модуля вы сможете:
- Установите расширение контейнеров разработки Visual Studio Code.
- Загрузите и подключитесь к проекту в контейнере Docker.
- Доступ к портам в контейнере с локального компьютера.
- Настройте параметры при работе с контейнером.
- Добавьте программное обеспечение в среду контейнера.
Предварительные требования
- Базовые общие сведения о разработке программного обеспечения, например, что означает выполнение кода или установка нового языка
- Docker и базовые знания Docker (знакомство с понятием образов, контейнеров и реестров)
- Git и базовые знания о GitHub, т. е. о том, что такое репозиторий
Подсистема Docker в Windows
Подсистема и клиент Docker не входят в состав Windows, потому их нужно устанавливать и настраивать отдельно. Кроме того, подсистема Docker может принимать множество пользовательских конфигураций. Например, можно настроить то, как управляющая программа принимает входящие запросы, сетевые параметры по умолчанию и параметры ведения журнала и отладки. В ОС Windows эти конфигурации можно указать в файле конфигурации или с помощью диспетчера служб Windows. В этом документе объясняется установка и настройка подсистемы Docker; также представлены примеры некоторых часто используемых конфигураций.
Установка Docker
Для работы с контейнерами Windows требуется Docker. Docker состоит из подсистемы Docker (dockerd.exe) и клиента Docker (docker.exe). Самый простой способ установить все необходимые компоненты изложен в кратком руководстве, которое поможет настроить и запустить первый контейнер.
Сведения об установке с помощью сценария см. в разделе Использование сценария для установки Docker EE.
Прежде чем использовать Docker, необходимо установить образы контейнеров. Дополнительные сведения см. в документации по образам контейнеров.
Настройка Docker с помощью файла конфигурации
Предпочтительным способом настройки подсистемы Docker в Windows является использование файла конфигурации. Путь к файлу конфигурации — C:\ProgramData\Docker\config\daemon.json. Если этот файл еще не существует, его можно создать.
Не все доступные параметры конфигурации Docker применяются к Docker в Windows. В примере ниже показаны параметры конфигурации, которые применяются. Дополнительные сведения о конфигурации подсистемы Docker см. в статье Docker daemon configuration file (Файл конфигурации управляющей программы Docker).
< "authorization-plugins": [], "dns": [], "dns-opts": [], "dns-search": [], "exec-opts": [], "storage-driver": "", "storage-opts": [], "labels": [], "log-driver": "", "mtu": 0, "pidfile": "", "data-root": "", "cluster-store": "", "cluster-advertise": "", "debug": true, "hosts": [], "log-level": "", "tlsverify": true, "tlscacert": "", "tlscert": "", "tlskey": "", "group": "", "default-ulimits": <>, "bridge": "", "fixed-cidr": "", "raw-logs": false, "registry-mirrors": [], "insecure-registries": [], "disable-legacy-registry": false > Достаточно только внести необходимые изменения в файл конфигурации. Например, в этом случае подсистема Docker настраивается на прием входящих подключений через порт 2375. В других параметрах конфигурации будут использоваться значения по умолчанию.
Аналогично в примере ниже настраивается хранение образов и контейнеров по альтернативному пути в управляющей программе Docker. Если оно не указано, по умолчанию используется значение c:\programdata\docker .
В примере ниже управляющая программа Docker настраивается на прием только защищенных подключений через порт 2376.
Настройка Docker в службе Docker
Подсистему Docker можно также настроить, изменив службу Docker командой sc config . При использовании этого способа флаги подсистемы Docker задаются непосредственно в службе Docker. Выполните указанную ниже команду в командной строке (cmd.exe, не PowerShell).
sc config docker binpath= "\"C:\Program Files\docker\dockerd.exe\" --run-service -H tcp://0.0.0.0:2375" Не нужно выполнять эту команду в том случае, если файл daemon.json уже содержит запись «hosts»: [«tcp://0.0.0.0:2375»] .
Распространенные конфигурации
В следующих примерах файла конфигурации представлены распространенные конфигурации Docker. Их можно объединить в один файл конфигурации.
Создание сети по умолчанию
Чтобы настроить подсистему Docker таким образом, чтобы не была создана сеть NAT по умолчанию, используйте следующую конфигурацию.
Дополнительные сведения см. в статье Управление сетями Docker.
Задание группы безопасности для Docker
После входа в систему на узле Docker и запуска команд Docker эти команды выполняются через именованный канал. По умолчанию только члены группы «Администраторы» могут получить доступ к подсистеме Docker через именованный канал. Чтобы указать группу безопасности, имеющую такой доступ, используйте флаг group .
Конфигурация прокси-сервера
Чтобы задать данные о прокси-сервере для docker search и docker pull , создайте переменную среды Windows с именем HTTP_PROXY или HTTPS_PROXY и значением, содержащим данные о прокси-сервере. Это можно сделать в PowerShell, используя команду следующего вида:
[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://username:password@proxy:port/", [EnvironmentVariableTarget]::Machine) После задания переменной перезапустите службу Docker.
Restart-Service docker Дополнительные сведения см. в разделе Windows Configuration File (Файл конфигурации Windows) на сайте Docker.com.
Удаление Docker
В этом разделе описывается, как удалить Docker и выполнить полную очистку компонентов системы Docker в Windows 10 или Windows Server 2016.
Все команды в этих инструкциях необходимо выполнять из сеанса PowerShell с повышенными привилегиями.
Подготовка системы к удалению Docker
Перед удалением Docker убедитесь, что в системе не запущены контейнеры.
Выполните следующие командлеты, чтобы найти работающие контейнеры:
# Leave swarm mode (this will automatically stop and remove services and overlay networks) docker swarm leave --force # Stop all running containers docker ps --quiet | ForEach-Object
Кроме того, перед удалением Docker рекомендуется удалить все контейнеры, образы контейнеров, сети и тома из системы. Это можно сделать, выполнив следующий командлет:
docker system prune --volumes --all Удаление Docker
Затем необходимо начать собственно удаление Docker.
Удаление Docker в Windows 10
- На компьютере с Windows 10 перейдите в раздел Параметры>Приложения.
- В разделе Программы и компоненты найдите Docker для Windows
- Последовательно выберите Docker для Windows>Удалить.
Удаление Docker в Windows Server 2016
В сеансе PowerShell с повышенными привилегиями используйте командлеты Uninstall-Package и Uninstall-Module, чтобы удалить модуль Docker и соответствующий ему поставщик Управление пакетами из системы, как показано в следующем примере:
Uninstall-Package -Name docker -ProviderName DockerMsftProvider Uninstall-Module -Name DockerMsftProvider Вы можете найти поставщик пакетов, который использовался для установки Docker с помощью команды PS C:\> Get-PackageProvider -Name *Docker*
Очистка данных и системных компонентов Docker
После удаления Docker необходимо удалить сети Docker по умолчанию, чтобы их конфигурация не оставалась в системе после того, как Docker будет удален. Это можно сделать, выполнив следующий командлет:
Get-HNSNetwork | Remove-HNSNetwork Удалите сети по умолчанию Docker в Windows Server 2016.
Get-ContainerNetwork | Remove-ContainerNetwork Выполните следующий командлет, чтобы удалить программные данные Docker из системы:
Remove-Item "C:\ProgramData\Docker" -Recurse Можно также удалить необязательные компоненты Windows, связанные с Docker и контейнерами в Windows.
К ним относится компонент «Контейнеры», который автоматически включается в любом экземпляре Windows 10 или Windows Server 2016 при установке Docker. Это также может быть компонент «Hyper-V», который автоматически включается в Windows 10 при установке Docker, однако в Windows Server 2016 он включается вручную.
Компонент Hyper-V является общим компонентом виртуализации, который обеспечивает гораздо большую функциональность, чем при использовании одних только контейнеров. Прежде чем отключить Hyper-V, убедитесь, что в системе нет других виртуальных компонентов, которые зависят от Hyper-V.
Удаление компонентов Windows 10
- Выберите последовательно Панель управления>Программы>Программы и компоненты>Включение или отключение компонентов Windows.
- Найдите имя компонента, который требуется отключить — в данном случае это Контейнеры и (необязательно) Hyper-V.
- Снимите флажок рядом с именем компонента, который нужно отключить.
- Нажмите кнопку ОК.
Удаление компонентов Windows Server 2016
В сеансе PowerShell с повышенными привилегиями выполните следующие командлеты, чтобы отключить компоненты Контейнеры и (необязательно) Hyper-V.
Remove-WindowsFeature Containers Remove-WindowsFeature Hyper-V Перезагрузка системы
Чтобы завершить удаление компонентов и очистить систему, выполните следующий командлет из сеанса PowerShell с повышенными привилегиями для перезагрузки системы:
Restart-Computer -Force docker Узнать имя и/или ID контейнера (+ docker-compose)
Используя основную команду докера можно глянуть запущенные процессы:
docker ps
Или все когда-либо запускавшиеся:
docker ps -a
docker-compose Имена контейнеров
Перейдите в папку с манифестом docker-compose.yml и выполните команду:
Продвинутая работа с Docker — Docker-compose
Docker-compose — это надстройка над докером, приложение написанное на Python, которое позволяет запускать множество контейнеров одновременно и маршрутизировать потоки данных между ними. Для каждого проекта (кластера контейнеров) Docker создаёт свою сеть, где контейнеры могут обращаться друг к другу по именам, которые мы укажем в docker-compose.yml. Все настройки запуска кластера контейнеров находятся в этом же файле, который располагается в корневой директории проекта. Docker-compose.yml мало чем похож на знакомые нам уже docker-файлы. В отличие от них, docker-compose.yml записан не в декларативном ini-стиле как docker-файлы, а в древовидном YAML. Если вы ещё не знакомы с YAML — рекомендуем потратить 10-15 минут и ознакомиться с нашим кратким мануалом по YAML. С ним всё нижеизложенное станет куда более понятным.
Создаем проект для запуска в Docker-compose
Наш проект состоит из двух связанных контейнеров: Nginx и php. Структура нашего проекта выглядит так:
- www — каталог содержит index.html, index.php, подкаталог phpinfo. Эти файлы нужны для корректной работы Nginx и php-fpm. www также скопировано в каталоги nginx и php, из которых будут собираться контейнеры;
- nginx — директория содержит конфигурационный файл nginx custom.conf, Dockerfile, по которому будет собираться nginx-контейнер и подкаталог www (копию корневого www), который будет скопирован в контейнер для проверки работоспособности и подменен в будущем;
- php — директория содержит Dockerfile по которому будет собираться php-контейнер и аналогичный подкаталог www.
Такая структура проекта продиктована логикой сборки проекта. Сначала собираются образы Nginx и php из docker-файлов, расположенных в одноименных директориях, затем запускаются контейнеры в соответствии с инструкциями в Docker-compose.yml
Dockerfile Nginx
FROM nginx:mainline-alpine #Берем родительский образ Nginx
EXPOSE 80 # Открываем 80 порт
COPY custom.conf /etc/nginx/conf.d #Подменяем конфиг Nginx conf.d в контейнере на custom.conf
COPY ./www /var/www #Копируем содержимое www в /var/www
CMD [«nginx», «-g», «daemon off;»] #Запускаем Nginx как процесс.
Dockerfile php
FROM php:7.4-fpm #Берем родительский образ php:7.4-fpm
EXPOSE 9000 #Открываем 9000 порт
WORKDIR /var/www/ # Устанавливаем рабочим каталогом контейнера /var/www/
COPY ./www/ /var/www/ #Копируем содержимое хостового каталога www в директорию var/www/
CMD [«php-fpm»] #Выполняем команду php-fpm
В Docker-файле Nginx есть два ключевых момента для нашего проекта, которые нужно разобрать:
- инструкция COPY custom.conf /etc/nginx/conf.d копирует custom.conf из локальной папки nginx и подменяет им conf.d в контейнере Nginx. Без него Nginx не отработает.
- инструкция CMD с параметром [«nginx», «-g», «daemon off;»] запускает Nginx как процесс, а не как демон.
Кстати, в составлении Docker-файлов есть свои best practice. О некоторых из них, вы можете узнать из нашего небольшого мануала по оптимизации сборки Docker-образов.
Теперь, чтобы были понятны наши следующие действия нужно обратиться к настройкам Nginx, тому самому конфигурационному файлу custom.conf, которым мы подменяли стандартный conf.d, находящийся в Nginx-контейнере.
Внутри custom.conf выглядит так:
server < listen 80;
server_name 5.101.77.54;
root /var/www;
index index.html index.php;
location ~ \.php$ try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass php:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
>
>
Нас интересуют следующие параметры:
- server_name — имя сервера, к которому мы обращаемся. В нашем случае, это IP-адрес нашей VPS.
- root — корневая папка, в которой Nginx будет искать файлы для исполнения. Мы её будем подменять в дальнейшем через docker-compose.yml для визуализации процесса разработки.
- fastcgi_pass php:9000 — проброс запроса на отдачу динамического контента в контейнер php на порт 9000.
Со структурой проекта, docker-файлами и настройками Nginx разобрались. Переходим к ключевому — разбираемся с docker-compose.yml.
docker-compose.yml — центр управления полётами
Docker-compose файл описывает процесс загрузки и настройки контейнеров. Разберём Docker-compose.yml, который мы подготовили для нашего проекта. Код нашего файла выглядит так:
version: «2.3» #Задаем версию docker-compose.yml
services: #Задаем контейнеры
nginx: #Задаем название первого контейнера — nginx и настраиваем его
build: ./nginx #Указываем откуда будет вестись сборка
ports: # Указываем какие порты нужно пробросить наружу
— «80:80»
volumes: #Подключаем рабочий каталог с кодом проекта
— ./www:/var/www
depends_on: #Устанавливаем последовательность загрузки контейнеров
php: # php-контейнер запуститься раньше Nginx
condition: service_healthy #Устанавливаем условия при котором запуститься контейнер nginx
php: #Задаем название первого контейнера — php и настраиваем его
build: ./php #Указываем откуда будет вестись сборка
volumes: #Подключаем тот же рабочий каталог с кодом проекта
— ./www:/var/www
healthcheck: #Проверка работы приложения внутри контейнера
test: [«CMD»,»php-fpm»,»-t»] #Команда теста, которую мы хотим выполнить
interval: 3s #Интервал попыток запуска теста
timeout: 5s #Отложенность запуска команды
retries: 5 #Количество повторений
start_period: 1s #Через сколько стартовать тест после запуска контейнера
Наш Docker-compose.yml невелик, однако он может быть огромным и иметь сложную структуру из разных типов организации данных: строк, списков, словарей. По началу даже в не очень сложном Docker-compose.yml можно наделать ошибок, которые на глаз не видны, поэтому перед запуском сборки проекта — проверьте код, каким-нибудь YAML-валидатором, например, yamllint.
В начале файла мы задали инструкцию version со значением 2.3 — это сделано специально, так как разные версии Docker-compose.yml содержат разный набор инструкций. Так в версии 3 нет инструкции healthcheck, а она критически важна для нас в этом проекте.
Инструкция healthcheck (блок php-контейнера) позволяет нам проверить работоспособность приложения в контейнере, указав с помощью другой инструкции test команду для тестирования. Смежные инструкции interval, timeout, retries, start_period устанавливают временные условия выполнения инструкции test.
Следующая логически связанная с healthcheck инструкция — depends_on (блок nginx-контейнера) — контроль порядка запуска. Логика работы depends_on такова: пока успешно не закончатся все действия указанные в блоке condition над контейнером заданным выше строчкой, контейнер, в котором расположена инструкция depends_on не запустится.
В нашем случае пока успешно не выполнится тест php-контейнера, Nginx-контейнер не запустится. Это сделано для правильной очередности загрузки инфраструктурных элементов нашего проекта.
depends_on: #Устанавливаем последовательность загрузки контейнеров
php: # php-контейнер запуститься раньше Nginx
condition: service_healthy #Устанавливаем условия при котором запуститься контейнер nginx
Скажем еще несколько слов об инструкциях build и volumes:
- build — указывает на директорию из которой будет собран контейнер, в ней должен быть dockerfile;
- volumes — прокидывает локальную папку в контейнер. В нашем случае все изменения внесенные в файлы директории www будут автоматически доступны в контейнерах по пути /var/www.
Обратимся к логической блок-схеме для полного понимания процесса сборки и запуска нашего проекта, а потом перейдём непосредственно к сборке проекта.
Схема взаимодействия структурных элементов проекта и их свойств
Теперь, когда мы понимаем внутренние взаимосвязи внутри проекта — настало время его собрать. Для запуска контейнеров через docker-compose используются следующие команды:
- docker-compose build — собрать проект
- docker-compose up -d — запустить проект
- docker-compose down — остановить проект
- docker-compose logs -f [service name] — посмотреть логи сервиса
- docker-compose ps — вывести список контейнеров
- docker-compose exec [service name] [command» — выполнить команду в контейнере
- docker-compose images — список образов
Находясь в корневом каталоге проекта вызовем команду docker-compose up -d. Вот какие действия будут выполнены docker-compose: 1) Сборка образа php; 2) Сборка образа Nginx; 3) Запуск контейнера php; 4) Тест php; 5) Запуск контейнера Nginx. Проверим, запустились контейнеры командой docker ps. В ответ команда вернет сообщение следующего вида:
Если запустились не все контейнеры — введите docker ps -a и docker logs . Вывод будет содержать коды и наименования ошибок. В нашем случае оба контейнера запустились и работают на нужных портах.
Проверим работу Nginx и php с помощью команды curl:
curl -I http://5.101.77.54/ 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2
curl -I http://5.101.77.54/phpinfo/ 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2
В обоих случаях curl нам вернул код ответа 200. Это значит, что Nginx нашёл нужную страницу и отдал ее нам.
На этом сборка и тестирование проекта завершена, можно подводить итоги.
Что получается в итоге
Docker-compose — это система сборки, запуска и управления множеством контейнеров. Docker-compose не входит в единый пакет поставки Docker и устанавливается отдельно. Для сборки кластера контейнеров используется docker-compose.yml.
Docker-compose.yml — конфигурационный файл в YAML-формате, описывающий логику запуска и взаимодействия контейнеров между собой и внешним миром. В сущности инструкции заложенные в docker-compose.yml по логике работы идентичны ключам команды docker run.
На первое место при работе с Docker-compose выходит структура проекта. Она должна следовать правилам работы Docker-контейнеров — в одном контейнере должен быть только один процесс. Хорошей практикой является составление процессной карты взаимодействия элементов вашего проекта между собой и её перенос на логику работы Docker-compose.
В статье мы показали базовые возможности и основные взаимодействия с docker-compose, которых вполне будет достаточно для самостоятельной практики и экспериментов. Лучше всего для этого использовать заранее подготовленные виртуальные серверы.
Если материал этой статьи вам показался непонятным — рекомендуем ознакомиться с предыдущими нашими публикациями, они помогут заполнить возможные пробелы по теории контейнеризации и по работе Docker в частности.
Введение в Docker
Разбираемся в том, что такое Docker, из каких компонентов состоит и какие технологии контейнеризации использует.
История контейнеризации
Краткая история контейнеризации и разбор конкретных технологий: chroot, jail, namespaces и cgroups.