Несколько дней назад я начал тестировать Docker с проектами, разработанными на .Net, и развертывать их в сервисах Azure, для чего обнаружил две ситуации: первая — отсутствие существующей или устаревшей документации; и вторая — то, что процесс относительно прост.
Поэтому я решил, что лучше всего будет поделиться своим опытом в этом процессе, так что давайте приступим к работе.
Сначала мы создадим проект ASP.NET Core Web App:
Мы помещаем название нашего проекта:
Выберите опцию Enable Docker и выберите ОС как Linux.
После завершения создания проекта мы можем заметить, что по умолчанию цель компиляции была изменена на Docker **😱. На данный момент давайте изменим эту цель на название нашего проекта; в моем случае **WebAppDocker.
Еще одно изменение, которое можно заметить, это то, что я добавляю Dockerfile в наш проект; он содержит конфигурацию для Docker, которую мы проанализируем позже. На данный момент мы проверяем, что наш проект работает корректно без использования Docker.
Когда мы убедились, что наше приложение работает правильно, давайте продолжим тестирование этой функциональности, но теперь уже внутри нашего контейнера Docker. Прежде чем мы продолжим, вы можете задаться вопросом, а если это существующий проект, как мне заставить его работать в контейнере Docker; с Visual Studio это сделать относительно просто: щелкните правой кнопкой мыши на имени проекта -> Add -> Docker Support
Выберите целевую ОС: Linux
Это создаст соответствующий Dockerfile для нашего проекта.
Теперь, если мы запустим проект с параметром Target: Docker
Как мы видим, внутри Visual Studio у нас есть инструмент для визуализации контейнеров, в котором есть та же функциональность, что и в Docker Desktop.
Когда мы запускаем наш проект в VS, мы можем наблюдать, что образ создан и в свою очередь контейнер выполняется, что в другом сценарии означало бы, что с этим образом мы уже можем поднять наш контейнер в Azure; к моему удивлению, это не так, потому что по какой-то странной причине при остановке процесса отладки в VS приложение больше не запускается корректно 🤔🤔🤔. Чтобы понять причину, по которой приложение, запущенное в контейнере, больше не работает, хотя процесс запущен в Docker и не отмечает никаких ошибок; проверьте шаги, выполняемые Visual Studio для компиляции, упаковки и публикации проекта. Эту информацию можно просмотреть в терминале VS Output.
При проверке команды docker build она получает только параметры Dockerfile для сборки, —force-rm -t для удаления существующего образа и метки, поэтому мы отбрасываем проблему при сборке образа Docker.
docker build -f "C:UsersvicosCursoDockerWebAppDockerWebAppDockerWebAppDockerDockerfile" --force-rm -t webappdocker --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=WebAppDocker" "C:UsersvicosCursoDockerWebAppDockerWebAppDocker"
Следующим шагом будет проверка конца журнала на наличие команды docker run.
docker run -dt -v "C:Usersvicosvsdbgvs2017u5:/remote_debugger:rw" -v "C:UsersvicosAppDataRoamingMicrosoftUserSecrets:/root/.microsoft/usersecrets:ro" -v "C:UsersvicosAppDataRoamingASP.NETHttps:/root/.aspnet/https:ro" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=https://+:443;http://+:80" -P --name WebAppDocker --entrypoint tail webappdocke1r -f /dev/null
В параметрах, которые получает эта команда, мы наблюдаем некоторые дополнительные параметры, начиная с параметра -v «C:UsersersVicosVsdbgVs2017u5:/remote_debugger:rw» этот параметр монтирует том для отладчика, который не нужен для продуктивного выполнения нашего WebApp в Docker.
Следующие два параметра используются веб-сервером для определения используемого сертификата https, как мы видим, они ссылаются на локальный путь команды разработчиков, а в производственной среде у нас не будет доступа к этим папкам. Чтобы добавить сертификат в контейнер, мы должны изменить наш проект.
В проводнике Windows находим папку %USERPROFILE% «AppData», в которой мы найдем сертификат для нашего проекта.
Мы копируем этот файл и помещаем его в наш проект.
Щелкните правой кнопкой мыши -&&> свойства (Alt + Enter)
В свойстве «Copy to Output Directory» выбираем опцию «Copy Always».
Откройте файл Appsettings.json и добавьте следующее
"Kestrel": {
"Certificates": {
"Default": {
"Path": "WebAppDocker.pfx",
"Password": "f9503e4f-0cd7-4630-b752-4d41df791f69"
}
}
}
После внесения этих изменений мы переходим к следующему параметру, который не нужно указывать команде docker run. -e «ASPNETCORE_LOGGING_CONSOLE_DISABLECOLORS=true» этот параметр необязателен, так как он отключает только цвета в журнале консоли.
Следующие два параметра ENVIRONMENT и URLS **не являются необходимыми, поэтому мы оставим их внутри нашего сценария запуска, наряду с параметром -P, который позволяет нам публиковать открытые порты на случайные порты; мы изменим его позже, когда будем публиковать наш образ docker в службу Azure.
Затем идет имя нашего контейнера, и теоретически это должно быть имя образа, который мы хотим запустить, но в команде, которую выполняет VS, она перегружает точку входа хвостом webappdocker:dev -f /dev/null**, что не нужно для нашей рабочей среды.
С этими изменениями наша команда docker run будет выглядеть следующим образом:
docker run -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=https://+:443;http://+:80" -P --name WebAppDocker webappdocker
Этим мы проверяем, что наше приложение действительно находится внутри контейнера.
Как мы видим, наш WebApp корректно работает в контейнере docker, и наше приложение готово к развертыванию в службе Azure.
В следующей части мы создадим конвейеры Azure Pipelines для компиляции и развертывания на сервисе Azure.
Жду следующей встречи, всего наилучшего, здоровья и успехов!