как развернуть приложение в docker
Учимся разворачивать микросервисы. Часть 1. Spring Boot и Docker
В этой статье я хочу рассказать о своем опыте создания учебной среды для экспериментов с микросервисами. При изучении каждого нового инструмента мне всегда хотелось его попробовать не только на локальной машине, но и в более реалистичных условиях. Поэтому я решил создать упрощенное микросервисное приложение, которое впоследствии можно будет «обвешивать» всякими интересными технологиями. Основное требование к проекту — его максимальная функциональная приближенность к реальной системе.
Изначально я разбил создание проекта на несколько шагов:
Создать два сервиса — ‘бекенд’ (backend) и ‘шлюз’ (gateway), упаковать их в docker-образы и настроить их совместную работу
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Ключевые слова: Helm 3, chart deployment
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Каждому шагу я планирую посвятить отдельную статью.
Направленность этого цикла статей заключается не в том, как написать микросервисы, а как заставить их работать в единой системе. Хоть все эти вещи обычно лежат за пределами ответственности разработчика, думаю, что все равно полезно быть знакомым с ними хотя бы на 20% (которые, как известно, дают 80% результата). Некоторые безусловно важные темы, такие как обеспечение безопасности, будут оставлены за скобками этого проекта, так как автор в этом мало что понимает система создается исключительно для личного пользования. Я буду рад любым мнениям и конструктивной критике.
Создание микросервисов
Сервисы были написаны на Java 11 с использованием Spring Boot. Межсервисное взаимодействие организовано с использованием REST. Проект будет включать в себя минимальное количество тестов (чтобы потом было, что тестировать в Jenkins). Исходный код сервисов доступен на GitHub: бекенд и шлюз.
Чтобы иметь возможность проверить состояние каждого из сервисов, в их зависимости был добавлен Spring Actuator. Он создаст эндпойнт /actuator/health и будет возвращать 200 статус, если сервис готов принимать траффик, или 504 в случае проблем. В данном случае это довольно фиктивная проверка, так как сервисы очень просты, и при каком-то форсмажоре они скорее станут полностью недоступны, чем сохранят частичную работоспособность. Но в реальных системах Actuator может помочь диагностировать проблему до того, как об нее начнут биться пользователи. Например, при возникновении проблем с доступом к БД, мы сможем автоматически на это среагировать, прекратив обрабатывать запросы сломанным экземпляром сервиса.
Сервис Backend
Сервис бекенда будет просто считать и отдавать количество принятых запросов.
Тест на контроллер:
Сервис Gateway
Шлюз будет переадресовывать запрос сервису бекенда, дополняя его следующей информацией:
Как работать с Docker: упаковка Spring Boot приложения в контейнер
Немного разбираемся с теорией и проверяем на практике.
Эта статья посвящена основам Docker и раскрывает азы работы с контейнерами. Мы изучим базовые определения и самые необходимые команды и даже разработаем и развернём простейшее Java-приложение.
Что такое Docker
Docker — инструмент, предназначенный для быстрой разработки, доставки и развёртывания приложений. Он позволяет упаковать приложение вместе со всеми его зависимостями в так называемый контейнер, а затем запустить его в любой среде.
Идея контейнеризации состоит в том, что на одной машине может разворачиваться множество таких контейнеров с приложениями. Для каждого из них в операционной системе выделяется изолированная область — осуществляется виртуализация на уровне ОС.
Важный момент: все контейнеры запускаются одинаковым способом вне зависимости от того, что находится внутри. Это напоминает контейнеры для морских перевозок — с виду они одинаковы, но внутри могут храниться совершенно разные грузы.
Разрабатывает приложения на Java, воспитывает двух котов: Котлин и Монго.
Основные понятия
Образ — некий шаблон, на основе которого создаются контейнеры. Содержит всё необходимое для запуска приложения. Сюда относятся код, системные утилиты, библиотеки, настройки и так далее. Образ можно представить в виде набора слоёв, которые накладываются друг на друга. Каждый последующий добавляет, изменяет или удаляет файлы предыдущего слоя.
DockerfIle — текстовый файл с набором инструкций по созданию образа, каждая из которых добавляет к образу новый слой.
Контейнер — конкретный экземпляр приложения, созданный на основе образа. Причём из одного образа можно создать сколько угодно контейнеров. Технически контейнер создаётся путём добавления к образу нового слоя, содержащего результаты работы приложения.
Реестр — хранилище образов (как GitHub для кода приложений). Образы можно скачивать из реестра и создавать на их основе контейнеры. Также в реестр можно загружать новые или изменённые образы для дальнейшего использования.
Пример использования
Давайте разработаем простое Spring Boot приложение, создадим на его основе образ и развернём контейнер на локальной машине. Это делается в три простых шага:
Как развернуть Java+MySQL (Docker) за полчаса и не уронить сервер
В качестве среды исполнения Java-приложений обычно используются серверы, у которых минимум 2 Гб оперативной памяти (не считая выделенной под ОС). Рассмотрим вариант запуска Java-приложения с базой данных MySQL на VDS-сервере «Danny» от Timeweb (1 Гб ОЗУ) без получения хорошо известной каждому «джависту» ошибки «Out of memory». Весь процесс от регистрации до запуска работающего Java-приложения с базой данных займет не более 15 минут!
Первым делом создаем VDS.
Выбираем конфигурацию ПО сервера – в нашем случае ОС Ubuntu (можно любую другую из предложенных) и «Docker».
Выбираем конфигурацию сервера «Danny» (2.8 ГГц CPU, 1Гб ОЗУ, 10Гб дискового пространства), которая является на момент написания статьи самым бюджетным вариантом.
Итак, мы создали сервер с установленным ПО «Docker».
Теперь нам необходима среда исполнения для нашего Java-приложения. Думали, дальше будет «оченьмноготекста» по установке и настройке Apache Tomcat? Нет. Думаю, на просторах интернета предостаточно материалов на данную тему, поэтому, чтобы не тратить время на полную установку Apache Tomcat, мы используем spring boot с embedded tomcat.
Далее нам необходима установленная версия Java для запуска приложения. Но мы, все по тем же причинам в духе «у меня нет времени, клиенты ждут работающий сайт еще до того как придумали Java как можно скорее», не будем устанавливать Java. Мы создадим docker-образ с нашим Java-приложением на основе docker-образа с уже установленной Java Runtime Environment 11 (JRE-11). Также такой подход делает наше приложение максимально портативным и хорошо масштабируемым.
Создаем простейший Dockerfile:
В данном файле описаны:
Копирование в docker-образ нашего приложения demo-1.0.war.
Установка рабочей директории «/usr/app».
Публикация порта 8080.
Команда, которая выполнится при запуске docker-контейнера.
Собираем docker-образ с помощью команды docker build и публикуем в своем репозитории.
Для разворачивания БД MySQL будем использовать официальный docker-образ «mysql:8.0.21».
Таким образом, у нас имеется:
Docker-образ нашего Java-приложения.
Docker-образ MySQL БД.
Теперь заходим удаленно (например, через Putty) на созданный VDS. С помощью команды docker pull загружаем docker-образы:
Вместо username необходимо написать свой docker-аккаунт.
Теперь запускаем docker-контейнеры (предварительно заменив some_name_mysql/some_password_mysql/some_name_java/username на свои значения):
Проверяем (IP-адрес берем из панели управления сервером):
Ура! Работает! Но где же «java.lang.OutOfMemoryError: Java heap space»?
Приведу скриншот показателей загрузки, полученных командой htop:
Для большей практической ценности показатели взяты с сервера, на котором установлено функционирующее боевое приложение (достаточно небольшое, но все же активно используемое). Как видите, суммарное потребление оперативной памяти превышает 1Гб, хотя на старте приложения это значение было
800Мб. Повышение потребления ОЗУ в ходе эксплуатации произошло в связи с созданием множества необходимых объектов и постоянным хранением их в памяти в целях оптимизации. Все это приводило к достижению лимита heap size и ошибке «Out of memory». Решение, как вы видите, состоит в подключении swap-пространства. Для этого выполните набор следующих команд:
Подведем итог. Мы получили работающее Java-приложение с базой данных MySQL на сервере Danny менее чем за 30 минут! И никаких непредвиденных «OutOfMemory».
Стоит добавить, что самое лучшее решение с точки зрения оптимизации – повышение конфигурации сервера до «Scarlett», на котором и дискового пространства в 3 раза больше (30Гб), и ОЗУ в 2 раза больше (2Гб), чего должно хватить для большинства небольших проектов.
Но с целью апробации услуг VDS, предоставляемых компанией Timeweb, временное решение, описанное в данной статье, более чем актуально даже для владельцев крупных enterprise-приложений (при необходимости можно увеличить размер swap-файла).
Рабочий процесс разработки для приложений Docker
Жизненный цикл разработки приложений начинается на компьютере разработчика, где разработчик локально программирует приложение на предпочитаемом языке и тестирует его. Независимо от выбранного языка, инфраструктуры и платформы, в рамках этого рабочего процесса разработчик всегда разрабатывает и тестирует контейнеры Docker, но делает это локально.
В каждый контейнер (экземпляр образа Docker) входят следующие компоненты:
Выбранная операционная система (например, дистрибутив Linux, Windows Nano Server или Windows Server Core).
Файлы, добавленные во время разработки, например исходный код и двоичные файлы и приложения.
Сведения о конфигурации, например параметры среды и зависимости.
Рабочий процесс разработки приложений Docker на основе контейнера
В этом разделе описывается рабочий процесс внутреннего цикла разработки приложений на основе контейнера Docker. Рабочий процесс внутреннего цикла означает, что речь идет только о разработке, которая выполняется на компьютере разработчика, не касаясь более широкого рабочего процесса DevOps. Начальные этапы настройки среды здесь не рассматриваются, так как они выполняются только один раз.
Приложение состоит из ваших собственных служб и дополнительных библиотек (зависимостей). Ниже приведены основные шаги, которые обычно выполняются при сборке приложения Docker, как показано на рисунке 5-1.
Процесс разработки для приложений на основе Docker: 1) создайте код приложения; 2) напишите файлы Dockerfile; 3) создайте образы, определенные в файлах Dockerfile; 4) (необязательно) создайте службы в файле docker-compose.yml; 5) запустите контейнер или приложение docker-compose; 6) проведите тестирование приложений или микрослужб; 7) отправьте все в репозиторий и повторите.
Рис. 5-1. Пошаговый рабочий процесс разработки приложения на основе контейнера Docker
В этом разделе подробно описывается весь процесс, и каждый важный шаг объясняется с акцентом на среду Visual Studio.
Если разработка выполняется с помощью редактора и CLI (например, Visual Studio Code и Docker CLI на macOS или Windows), то необходимо знать каждый шаг и обычно более детально, чем при использовании Visual Studio. Дополнительные сведения о работе в среде CLI см. в электронной книге Жизненный цикл приложений в контейнерах Docker с платформами и средствами Майкрософт.
При использовании Visual Studio 2019 многие из этих шагов выполняются автоматически, что значительно повышает производительность. Это особенно справедливо в тех случаях, когда используется Visual Studio 2019 и планируется создание многоконтейнерных приложений. Например, всего лишь одним щелчком мыши Visual Studio добавляет Dockerfile и файл docker-compose.yml в проекты с конфигурацией для вашего приложения. При запуске приложения в Visual Studio он создает образ Docker и запускает многоконтейнерное приложение непосредственно в Docker; вы даже можете отлаживать несколько контейнеров одновременно. Эти возможности значительно повышают скорость разработки.
Однако то, что Visual Studio автоматизирует эти действия, не означает, что вам не нужно знать, что происходит внутри Docker. Таким образом, каждый шаг подробно описывается в следующих рекомендациях.
Шаг 1. Начало программирования и создание первого приложения или базовой службы
Разработка приложения Docker аналогична разработке приложения без Docker. Разница заключается в том, что при разработке для Docker развертывание и тестирование приложения или служб, работающих в контейнерах Docker, выполняется в локальной среде (в ВМ Linux или напрямую в Windows, если используются контейнеры Windows).
Настройка локальной среды с помощью Visual Studio
Перед началом работы убедитесь, что Docker Community Edition (CE) для Windows установлен, как описано в следующих инструкциях:
Дополнительные ресурсы
Dockerfile необходим для каждого пользовательского образа, который вы хотите создать; кроме того, Dockerfile потребуется для каждого контейнера, который будет развертываться автоматически из Visual Studio или вручную с помощью Docker CLI (с помощью команд docker run и docker-compose). Если в приложении имеется единственный экземпляр пользовательской службы, необходим один Dockerfile. Если в приложении имеется несколько служб (как в архитектуре на основе микрослужб), потребуется по одному Dockerfile для каждой службы.
В Visual Studio со средствами для Docker эта задача выполняется лишь несколькими щелчками мыши. При создании нового проекта в Visual Studio 2019 можно выбрать параметр Enable Docker Support (Включить поддержку Docker), как показано на рисунке 5-3.
Рис. 5-3. Включение поддержки Docker при создании нового проекта ASP.NET Core в Visual Studio 2019
Поддержку Docker в существующий проект веб-приложения ASP.NET Core можно также включить, щелкнув правой кнопкой мыши проект в обозревателе решений и выбрав Добавить > Поддержка Docker, как показано на рисунке 5-4.
Рис. 5-4. Включение поддержки Docker в существующем проекте Visual Studio 2019
Это действие добавляет Dockerfile в проект с необходимой конфигурацией и доступно только для проектов ASP.NET Core.
Аналогичным образом, Visual Studio также позволяет добавить файл docker-compose.yml для всего решения при помощи параметра Добавить > Поддержка оркестратора контейнеров. На шаге 4 мы рассмотрим этот параметр более подробно.
Ниже приведен пример Dockerfile для контейнера ASP.NET Core.
Дополнительные ресурсы
Создание собственного образа. В официальной документации Docker.
https://docs.docker.com/engine/tutorials/dockerimages/
Использование мультиархитектурных репозиториев
Можно указать тег, явно задающий платформу, как в следующих случаях:
Появилась возможность указывать одно и то же имя образа, даже с одинаковым тегом, и новые мультиархитектурные образы (например, образ aspnet ) будут использовать версию Windows или Linux в зависимости от развернутой базовой ОС Docker, как показано в следующем примере:
Таким образом, при запросе образа с узла Windows будет получен вариант для Windows, а при запросе образа с тем же именем с узла Linux будет получен вариант для Linux.
Многоэтапная сборка в файле Dockerfile
Dockerfile похож на пакетный сценарий. Он похож на действия в ситуации, если бы вам необходимо было установить что-то на компьютере из командной строки.
Он начинается с базового образа, который задает начальный контекст; это как начальная файловая система, которая надстраивается над базовой ОС. Это не ОС в строгом смысле, но можно представить его как «ОС внутри контейнера».
Выполнение каждой командной строки создает новый слой в файловой системе с изменениями от предыдущего таким образом, чтобы при их объединении создавалась результирующая файловая система.
Поскольку каждый новый уровень «накладывается» на предыдущий и итоговый размер образа увеличивается с каждой командой, образы могут становиться очень большими, если они включают, например, пакет SDK для сборки и публикации приложения.
Здесь в дело вступает многоэтапная сборка (в Docker 17.05 и более поздних версий), творя настоящие чудеса.
Основная ее идея в том, что можно разделить процесс выполнения Dockerfile на этапы; каждый этап — исходный образ, за которым следуют команды, а последний этап определяет размер окончательного образа.
Короче говоря, многоэтапная сборка позволяет разделить создание образа на этапы и затем собрать окончательный образ, используя только соответствующие каталоги из промежуточных этапов. Общая стратегия использования этой функции такова:
Использовать базовый образ пакета SDK (его размер не имеет значения), где есть все необходимое для сборки и публикации приложения в папке.
Затем использовать небольшой базовый образ времени выполнения и скопировать папку публикации из предыдущего этапа для создания небольшого окончательного образа.
Возможно, лучший способ понять, как работает многоэтапный процесс, — это пройти в файле Dockerfile по каждой строке; давайте начнем с базового файла Dockerfile, созданного с помощью Visual Studio при добавлении поддержки Docker в проект, чтобы позже внести некоторые оптимизации.
Исходный файл Dockerfile может выглядеть следующим образом:
И вот подробности, по одной строке:
Строка 1. Начнем этап с небольшого базового образа времени выполнения, назвав его base.
Строка 2. Создайте в образе каталог /app.
Строка 3. Откройте порт 80.
Строка 5. Начнем новый этап с крупного образа для сборки и публикации. Назовем его build.
Строка 6. Создайте в образе каталог /src.
Строка 7. Скопируйте указанные файлы проектов .csproj до строки 16, чтобы иметь возможность восстановить пакеты позже.
Строка 17. Восстановите пакеты для проекта Catalog.API и связанных проектов.
Строка 18. Скопируйте все дерево каталогов решения (за исключением файлов и каталогов, включенных в файл .dockerignore) в каталог /src в образе.
Строка 19. Укажите в качестве текущей папки проект Catalog.API.
Строка 20. Скомпилируйте проект (и другие зависимости проекта) и поместите его в каталог проекта /app в образе.
Строка 22. Начните новый этап, продолжая работу со сборкой. Назовем его publish.
Строка 23. Опубликуйте проект (и его зависимости), поместив его в каталог проекта /app в образе.
Строка 25. Начните новый этап, продолжая работу над образом base. Назовем его final.
Строка 26. Измените текущий каталог на /app.
Строка 27. Скопируйте каталог /app из этапа publish в текущий каталог.
Строка 28. Определите команду, которая будет выполняться при запуске контейнера.
Теперь давайте рассмотрим некоторые оптимизации для повышения производительности всего процесса; в случае eShopOnContainers сборка полного решения в контейнерах Linux занимает около 22 минут или более.
Вы используете преимущества многоуровневого кэша Docker, которая не представляет особых сложностей: если базовый образ и команды — такие же, как в некоторых ранее выполненных случаях, можно просто использовать полученный слой без необходимости повторного выполнения команд, что экономит время.
Таким образом, давайте сосредоточимся на этапе build; строки 5–6 практически одинаковы, но строки 7–17 отличаются для каждой службы из eShopOnContainers, поэтому они должны выполняться каждый раз, но если изменить строки 7–16 на следующие:
то они будет практически аналогичны для каждой службы; строка копирует все решение и создаст слой большего размера, но при этом
процесс копирования будет выполняться только в первый раз (и при перестроении в случае изменения файла); для всех других служб будет использоваться кэш.
Так как более крупный образ находится на промежуточном этапе, он не влияет на размер окончательного образа.
то она позволит восстановить пакеты для всего решения, что позволяет повторять ее только один раз вместо 15.
Тем не менее dotnet restore запускается, только если в папке есть лишь один файл проекта или решения, поэтому решения этой задачи немного сложнее. Если не вдаваться в подробности, все обстоит так:
Добавьте приведенные ниже строки в .dockerignore:
*.sln для игнорирования всех файлов решения в главном дереве папок
Для окончательной оптимизации отметим, что строка 20 является избыточной, так как строка 23 также собирает приложение и следует, по сути, сразу после строки 20, поэтому можно убрать еще одну времязатратную команду.
Полученный файл будет таким:
Создание базового образа с нуля
Вы можете создать собственный базовый образ Docker с нуля. Этот сценарий не рекомендуется для тех, кто только начинает работать с Docker, но если вы хотите задать определенные биты базового образа, это можно сделать.
Дополнительные ресурсы
Создание базового образа. Официальная документация Docker.
https://docs.docker.com/develop/develop-images/baseimages/
Шаг 3. Создание пользовательских образов Docker и внедрение в них собственных приложений или служб
Для каждой службы в приложении необходимо создать связанный образ. Если приложение состоит из одной службы или веб-приложения, достаточно одного образа.
Обратите внимание, что образы Docker в Visual Studio создаются автоматически. Следующие действия потребуются только в рабочем процессе с использованием редактора/CLI и подробно описываются, чтобы показать, что происходит внутри.
Разработчик должен выполнять разработку и тестирование локально до тех пор, пока не завершит и отправит компонент или пока не перейдет в систему управления версиями (например, в GitHub). Это означает, что необходимо создавать образы Docker и разворачивать контейнеры на локальном узле Docker (на виртуальной машине Windows или Linux), а затем выполнять запуск, тестирование и отладку этих локальных контейнеров.
Чтобы создать пользовательский образ в локальной среде с помощью Docker CLI и Dockerfile, можно использовать команду docker build, как показано на рисунке 5-5.
Рис. 5-5. Создание пользовательского образа Docker
Вы можете найти существующие в локальном репозитории образы с помощью команды docker images, как показано на рисунке 5-6.
Рис. 5-6. Просмотр существующих образов с помощью команды docker images
Создание образов Docker с помощью Visual Studio
При использовании Visual Studio для создания проекта с поддержкой Docker не требуется создавать образ явно. Этот образ создается автоматически, когда вы нажимаете клавиши F5 или Ctrl-F5 и запускаете приложение или службу, добавленную в Docker. Этот шаг выполняется в Visual Studio автоматически, и вы не увидите, как это происходит, но важно знать, что происходит внутри.
Шаг 4. Определение служб в файле docker-compose.yml при сборке многоконтейнерного приложения Docker
В файле docker-compose.yml можно задать ряд связанных служб для развертывания в качестве составного приложения с помощью команд развертывания. Он также настраивает отношения зависимости и конфигурацию среды выполнения.
Чтобы использовать файл docker-compose.yml, его необходимо создать в основной или корневой папке решения, и его содержимое должно быть аналогично приведенному в следующем примере.
Данный файл docker-compose.yml представляет собой упрощенную и объединенную версию. Он содержит статические данные конфигурации для каждого контейнера (такие как имя пользовательского образа), которые требуются всегда, а также сведения о конфигурации, которые могут зависеть от среды развертывания, такие как строка подключения. В следующих разделах вы узнаете, как можно разбить конфигурацию в файле docker-compose.yml на несколько файлов docker-compose и переопределить значения в зависимости от среды и типа выполнения (отладка или выпуск).
Инициализируются две переменные среды (CatalogUrl и OrderingUrl).
Предоставленный порт 80 в контейнере переадресуется на внешний порт 80 на хост-компьютере.
Веб-приложение связывается со службами catalog и ordering с помощью параметра depends_on. В результате данная служба будет ожидать запуска этих служб.
Мы вернемся к файлу docker-compose.yml в следующем разделе, когда будем рассматривать реализацию микрослужб и многоконтейнерных приложений.
Работа с файлом docker-compose.yml в Visual Studio 2019
Наряду с возможностью добавления Dockerfile в проект, как уже отмечалось, Visual Studio 2017 версии 15.8 и выше позволяет включить в решении поддержку оркестратора для Docker Compose.
Повторите эту операцию для каждого проекта, который вы хотите включить в файл docker-compose.yml.
На момент написания этой статьи Visual Studio поддерживает оркестраторы Docker Compose и Kubernetes/Helm.
Рис. 5-7. Добавление поддержки Docker в Visual Studio 2019 щелчком правой кнопки мыши на проекте ASP.NET Core
После добавления поддержки оркестратора в решение в Visual Studio вы также увидите новый узел в обозревателе решений (в файле проекта docker-compose.dcproj ), содержащий добавленные файлы docker-compose.yml, как показано на рисунке 5-8.
Рис. 5-8. Узел дерева docker-compose, добавленный в обозреватель решений Visual Studio 2019
Шаг 5. Сборка и запуск приложения Docker
Если в приложении имеется только один контейнер, его можно запустить путем развертывания на узле Docker (на виртуальной машине или физическом сервере). Но если приложение содержит несколько служб, его можно развернуть как составное приложение с помощью одной команды CLI ( docker-compose up) ) или в Visual Studio, в котором внутри будет выполняться эта же команда. Давайте рассмотрим разные варианты.
Вариант А. Запуск приложения в одном контейнере
Использование Docker CLI
Рис. 5-9. Запуск контейнера Docker с помощью команды docker run
В этом случае команда привязывает внутренний порт 5000 контейнера к порту 80 хост-компьютера. Это означает, что узел выполняет прослушивание порта 80 и переадресацию в порт 5000 в контейнере.
Использование Visual Studio
Если вы еще не добавили поддержку оркестратора контейнеров, запустите одноконтейнерное приложение в Visual Studio, нажав клавишу Ctrl-F5. Кроме того, клавиша F5 позволяет отлаживать приложение внутри контейнера. Контейнер запускается локально с помощью команды docker run.
Вариант Б. Запуск многоконтейнерного приложения
В большинстве корпоративных сценариев приложение Docker будет состоять из нескольких служб; это означает, что необходимо запускать многоконтейнерное приложение, как показано на рисунке 5-10.
Рис. 5-10. Виртуальная машина с развернутыми контейнерами Docker
Использование Docker CLI
Рис. 5-11. Пример результата выполнения команды docker-compose up
После выполнения команды docker-compose up приложение и связанные с ним контейнеры развертываются в узле Docker, как показано на рисунке 5-10.
Использование Visual Studio
Запуск многоконтейнерного приложения с помощью Visual Studio 2019 не может быть проще. Просто нажмите клавишу Ctrl-F5 для запуска или F5 для отладки, как обычно, настроив проект docker-compose как запускаемый. Visual Studio обрабатывает все необходимые настройки, чтобы можно было создать точки останова обычным образом и без особых усилий отлаживать наконец ставшие независимыми процессы, запущенные на «удаленных серверах» с уже подключенным отладчиком.
Как упоминалось ранее, каждый раз при добавлении поддержки решения Docker в проект в решении этот проект настраивается в глобальном (на уровне решения) файле docker-compose.yml, что позволяет запускать или отлаживать все решение сразу. Visual Studio будет запускать по одному контейнеру для каждого проекта с включенной поддержкой решения Docker и выполнять все внутренние шаги автоматически (dotnet publish, docker build и т. д.).
Если вы хотите оценить масштаб этой утомительной работы, взгляните на файл:
Здесь важно то, что, как показано на рисунке 5-12, в Visual Studio 2019 имеется дополнительная команда Docker для действия клавиши F5. Эта возможность позволяет запускать или отлаживать многоконтейнерное приложение путем запуска всех контейнеров, определенных в файлах docker-compose.yml на уровне решения. Возможность отладки многоконтейнерных решений означает, что можно установить несколько точек останова, чтобы все они были в разных проектах (контейнерах), и во время отладки из Visual Studio вы будете останавливаться в точках останова, заданных в разных проектах, и работать в разных контейнерах.
Рис. 5-12. Запуск многоконтейнерных приложений в Visual Studio 2019
Дополнительные ресурсы
Примечание о тестировании и развертывании с использованием оркестраторов
Команды docker-compose up и docker run (или запуск и отладка контейнеров в Visual Studio) подходят для тестирования контейнеров в вашей среде разработки. Но этот подход не следует использовать для развертывания в рабочей среде, где следует выбирать оркестраторы, например Kubernetes или Service Fabric. При работе с Kubernetes необходимо использовать модули для организации контейнеров и службы для их объединения в сеть. Можно также использовать развертывания для упорядочения создания и изменения модулей.
Шаг 6. Тестирование приложения Docker с помощью локального узла Docker
Рис. 5-13. Пример локального тестирования приложения Docker с помощью localhost
Если localhost не указывает на IP-адрес узла Docker (при использовании Docker CE это должно происходить по умолчанию), то для перехода к службе используйте IP-адрес сетевой карты вашего компьютера.
Этот URL-адрес в браузере использует порт 80 для рассматриваемого примера конкретного контейнера. Однако внутренние запросы перенаправляются на порт 5000, поскольку именно так было выполнено развертывание с помощью команды docker run, как описано в предыдущем шаге.
Вы также можете тестировать приложение с помощью команды curl с терминала, как показано на рисунке 5-14. В случае установки Docker в Windows по умолчанию всегда будет использоваться IP-адрес узла Docker 10.0.75.1 помимо фактического IP-адреса вашего компьютера.
Рис. 5-14. Пример локального тестирования приложения Docker с помощью curl
Тестирование и отладка контейнеров в Visual Studio 2019
Тестирование и отладка без Visual Studio
Если при разработке используется редактор или CLI, отлаживать контейнеры будет значительно труднее, и вы, возможно, захотите выполнять отладку путем создания трассировок.
Дополнительные ресурсы
Стив Ласкер (Steve Lasker). Сборка, отладка, развертывание приложений ASP.NET Core с помощью Docker. Видео.
https://channel9.msdn.com/Events/Visual-Studio/Visual-Studio-2017-Launch/T115
Упрощенный рабочий процесс при разработке контейнеров в Visual Studio
В сущности, при использовании Visual Studio рабочий процесс гораздо проще, чем при использовании редактора или CLI. Большинство шагов, необходимых для Docker и связанных с Dockerfile и docker-compose.yml, выполняются скрыто от пользователя или значительно упрощаются благодаря Visual Studio, как показано на рисунке 5-15.
Процесс разработки для приложений на основе Docker: 1) создайте код приложения; 2) напишите файлы Dockerfile; 3) создайте образы, определенные в файлах Dockerfile; 4) (необязательно) создайте службы в файле docker-compose.yml; 5) запустите контейнер или приложение docker-compose; 6) проведите тестирование приложений или микрослужб; 7) отправьте все в репозиторий и повторите.
Рис. 5-15. Упрощенный рабочий процесс при разработке в Visual Studio
Дополнительные ресурсы
Использование команд PowerShell в DockerFile для настройки контейнеров Windows
Контейнеры Windows позволяют преобразовывать существующие приложения Windows в образы Docker и развертывать их с помощью тех же средств, что и остальную часть экосистемы Docker. Чтобы использовать контейнеры Windows, выполните команды PowerShell в Dockerfile, как показано в следующем примере: