Определение многоконтейнерного приложения с помощью docker-compose.yml
Совет
Это содержимое является фрагментом из электронной книги, архитектуры микрослужб .NET для контейнерных приложений .NET, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно читать в автономном режиме.
В этом руководстве представлен файл docker-compose.yml в разделе 4. Определите службы в docker-compose.yml при создании многоконтейнерного приложения Docker. Тем не менее существуют дополнительные способы использования файлов docker-compose, которые стоит изучить более подробно.
Например, в файле docker-compose.yml вы можете явно описать, как следует развертывать ваше многоконтейнерное приложение. При необходимости также можно описать, как вы планируете собирать свои пользовательские образы Docker. (Пользовательские образы Docker можно также собрать с помощью Docker CLI.)
В сущности, вы определяете каждый из контейнеров, которые планируете развернуть, и конкретные характеристики для каждого развертывания контейнера. Создав файл описания многоконтейнерного развертывания, вы можете развернуть все решение в одном действии, управляемом командой CLI docker-compose up, или развернуть решение прозрачно из Visual Studio. В противном случае придется использовать Docker CLI, чтобы разворачивать контейнер за контейнером в несколько этапов с помощью команды docker run из командной строки. Таким образом, для каждой службы, определенной в файле docker-compose.yml, необходимо указать ровно один образ или сборку. Остальные ключи являются необязательными и соответствуют своим аналогам в командной строке docker run.
В следующем примере кода YAML представлено определение возможно глобального, но единственного файла docker-compose.yml для примера eShopOnContainers. Это ненастоящий файл docker-compose из eShopOnContainers. Это упрощенная и объединенная в один файл версия, представляющая не лучший способ работы с файлами docker-compose, как будет показано ниже.
version: '3.4'
services:
webmvc:
image: eshop/webmvc
environment:
- CatalogUrl=http://catalog-api
- OrderingUrl=http://ordering-api
- BasketUrl=http://basket-api
ports:
- "5100:80"
depends_on:
- catalog-api
- ordering-api
- basket-api
catalog-api:
image: eshop/catalog-api
environment:
- ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
expose:
- "80"
ports:
- "5101:80"
#extra hosts can be used for standalone SQL Server or services at the dev PC
extra_hosts:
- "CESARDLSURFBOOK:10.0.75.1"
depends_on:
- sqldata
ordering-api:
image: eshop/ordering-api
environment:
- ConnectionString=Server=sqldata;Database=Services.OrderingDb;User Id=sa;Password=[PLACEHOLDER]
ports:
- "5102:80"
#extra hosts can be used for standalone SQL Server or services at the dev PC
extra_hosts:
- "CESARDLSURFBOOK:10.0.75.1"
depends_on:
- sqldata
basket-api:
image: eshop/basket-api
environment:
- ConnectionString=sqldata
ports:
- "5103:80"
depends_on:
- sqldata
sqldata:
environment:
- SA_PASSWORD=[PLACEHOLDER]
- ACCEPT_EULA=Y
ports:
- "5434:1433"
basketdata:
image: redis
Корневой ключ в этом файле — services. Под этим ключом определяются службы, которые требуется развернуть и запустить при выполнении команды docker-compose up или при развертывании из Visual Studio с помощью этого файла docker-compose.yml. В данном случае в файле docker-compose.yml определено несколько служб, как показано в следующей таблице.
| Service name | Description |
|---|---|
| webmvc | Контейнер, включая приложение ASP.NET Core MVC, использующее микрослужбы на стороне сервера C# |
| catalog-api | Контейнер, включающий микрослужбу Catalog веб-API ASP.NET Core. |
| ordering-api | Контейнер, включающий микрослужбу Ordering веб-API ASP.NET Core. |
| sqldata | Контейнер, запускающий SQL Server для Linux, в котором содержатся базы данных микрослужб. |
| basket-api | Контейнер с микрослужбой Basket веб-API ASP.NET. |
| basketdata | Контейнер, запускающий службу кэша REDIS, с базой данных basket в качестве кэша REDIS. |
Простой контейнер API веб-службы
Рассмотрим один контейнер. Контейнер-микрослужба catalog-api имеет простое определение:
catalog-api:
image: eshop/catalog-api
environment:
- ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
expose:
- "80"
ports:
- "5101:80"
#extra hosts can be used for standalone SQL Server or services at the dev PC
extra_hosts:
- "CESARDLSURFBOOK:10.0.75.1"
depends_on:
- sqldata
Эта контейнерная служба имеет следующую базовую конфигурацию.
Она основывается на пользовательском образе eshop/catalog-api. Для простоты нет сборки: параметр ключа в файле. Это означает, что образ должен быть предварительно создан (с помощью команды docker build) или загружен (с помощью команды docker pull) из любого реестра Docker.
Она определяет переменную среды с именем ConnectionString со строкой подключения, которая должна использоваться Entity Framework для доступа к экземпляру SQL Server, содержащему модель данных каталога. В данном случае в одном контейнере SQL Server содержатся несколько баз данных. Поэтому на компьютере разработки потребуется меньше памяти для Docker. Однако можно было бы также развернуть по одному контейнеру SQL Server для каждой базы данных микрослужбы.
Имя SQL Server — sqldata. Это же имя используется для контейнера, в котором выполняется экземпляр SQL Server для Linux. Это удобно: благодаря данной возможности служба разрешения имен (внутренняя для узла Docker) разрешит сетевой адрес, так что вам не нужно знать внутренний IP-адрес для контейнеров при обращении к ним из других контейнеров.
Так как строка подключения определяется переменной среды, можно задавать эту переменную посредством другого механизма и в другое время. Например, можно задать другую строку подключения при развертывании в рабочей среде на финальных узлах или сделать это из конвейеров CI/CD в Azure DevOps Services или в другой предпочитаемой системе DevOps.
Она представляет порт 80 для внутреннего доступа к службе catalog-api в узле Docker. В данном случае этот узел является виртуальной машиной Linux, так как он основан на образе Docker для Linux, но можно настроить контейнер для запуска в образе Windows.
Она переадресует предоставленный порт 80 в порт 5101 на хост-компьютере Docker (виртуальной машине Linux).
Она связывает веб-службу со службой sqldata (экземпляром SQL Server для базы данных Linux, запущенным в контейнере). Если вы указываете эту зависимость, контейнер catalog-api не будет запускаться до запуска контейнера sqldata. Это важно, поскольку для catalog-api требуется уже запущенная база данных SQL Server. Тем не менее во многих случаях недостаточно использовать этот вид зависимости контейнера, так как Docker выполняет проверку только на уровне контейнера. Иногда служба (в данном случае SQL Server) может быть еще не готова, поэтому рекомендуется реализовать в клиентских микрослужбах логику повторов с экспоненциальным отходом. Таким образом, если контейнер зависимостей будет не готов в течение некоторого времени, приложение по-прежнему будет устойчивым.
Он настроен для предоставления доступа к внешним серверам: параметр extra_hosts позволяет получать доступ к внешним серверам или компьютерам за пределами узла Docker (то есть за пределами виртуальной машины Linux по умолчанию, которая является узлом Docker для разработки), например локальным экземпляром SQL Server на компьютере разработки.
В файле docker-compose.yml также есть другие, более сложные параметры, которые мы рассмотрим в следующих разделах.
Использование файлов docker-compose для нескольких сред
Файлы docker-compose.*.yml — это файлы определения. Они могут использоваться несколькими инфраструктурами, которые распознают этот формат. Самым простым средством является команда docker-compose.
Таким образом, используя команду docker-compose, вы можете реализовать следующие основные сценарии.
Среды разработки
При разработке приложений важно иметь возможность запускать приложение в изолированной среде разработки. Вы можете создать такую среду с помощью команды CLI docker-compose или использовать Visual Studio, в котором команда docker-compose применяется внутренним образом.
Файл docker-compose.yml позволяет настраивать и документировать все зависимости служб вашего приложения (другие службы, кэш, базы данных, очереди и т. п.). С помощью команды CLI docker-compose вы можете создавать и запускать один или несколько контейнеров для каждой зависимости одной командой (docker-compose up).
Файлы docker-compose.yml — это файлы конфигурации, интерпретированные подсистемой Docker, но они также служат в качестве удобных файлов документирования сведений о составе вашего многоконтейнерного приложения.
Тестовые среды
Важной частью любого процесса непрерывного развертывания (CD) или непрерывной интеграции (CI) являются модульные тесты и интеграционные тесты. Для этих автоматических тестов требуется изолированная среда, чтобы на них не влияли пользователи или какие-либо изменения данных в приложении.
Используя Docker Compose, можно очень просто создавать и уничтожать такую изолированную среду с помощью нескольких команд, выполненных в командной строке, или скриптов, например, с помощью следующих команд:
docker-compose -f docker-compose.yml -f docker-compose-test.override.yml up -d
./run_unit_tests
docker-compose -f docker-compose.yml -f docker-compose-test.override.yml down
Рабочие развертывания
Команду Compose можно также использовать для развертывания в удаленной подсистеме Docker. Типичный случай — развертывание на один экземпляр узла Docker (такой как рабочая виртуальная машина или сервер с установленной машиной Docker).
При использовании любых других оркестраторов (Azure Service Fabric, Kubernetes и т. п.) может потребоваться добавить параметры настройки и конфигурации метаданных, аналогичные имеющимся в файле docker-compose.yml, но в формате, необходимом для этого другого оркестратора.
В любом случае docker-compose является удобным инструментом и форматом метаданных для рабочих процессов развертывания, тестирования и работы, хотя рабочий процесс работы может отличаться в зависимости от используемого оркестратора.
Использование нескольких файлов docker-compose для обработки разных сред
Если планируются разные среды, необходимо использовать несколько файлов compose. Это позволяет создать несколько вариантов конфигурации в зависимости от среды.
Переопределение базового файла docker-compose
Вы можете использовать единственный файл docker-compose.yml, как показано в упрощенных примерах, приведенных в предыдущих разделах. Однако для большинства приложений это не рекомендуется.
По умолчанию Compose читает два файла, docker-compose.yml и дополнительный файл docker-compose.override.yml. Как показано на рисунке 6–11, при использовании Visual Studio и включении поддержки Docker Visual Studio также создает дополнительный файл docker-compose.vs.debug.g.yml для отладки приложения, вы можете просмотреть этот файл в папке obj\Docker\ в главной папке решения.
Рис. 6-11. Файлы docker-compose в Visual Studio 2019
Структура файлов проекта docker-compose:
- .dockerignore — используется для пропуска файлов.
- docker-compose.yml — используется для создания микрослужб.
- docker-compose.override.yml — используется для настройки среды микрослужб.
Файлы docker-compose можно изменить в любом редакторе, например в Visual Studio Code или Sublime, и запустить приложение с помощью команды docker-compose up.
По определению файл docker-compose.yml содержит базовую конфигурацию и другие статические параметры. Это означает, что конфигурация службы не должна изменяться в зависимости от целевой среды развертывания.
Файл docker-compose.override.yml, как следует из его имени, содержит параметры конфигурации, которые переопределяют базовую конфигурацию, например конфигурацию, зависящую от среды развертывания. У вас может быть несколько файлов переопределения с разными именами. Файлы переопределения обычно содержат дополнительные сведения, необходимые для приложения, но относящиеся к конкретной среде или развертыванию.
Планирование нескольких сред
Распространенный вариант использования заключается в том, что определяется несколько файлов compose, чтобы можно было планировать несколько сред, таких как рабочая среда, промежуточная среда, среда CI или среда разработки. Для поддержки этих разных сред можно разделить конфигурацию Compose на несколько файлов, как показано на рисунке 6-12.
Рис. 6-12. Несколько файлов docker-compose, переопределяющих значения в базовом файле docker-compose.yml
Вы можете использовать комбинацию нескольких файлов docker-compose*.yml для работы в разных средах. Вы начинаете с базового файла docker-compose.yml. Этот базовый файл содержит базовые или статические параметры конфигурации, которые не изменяются в зависимости от среды. Например, приложение eShopOnContainers имеет в качестве базового файла следующий файл docker-compose.yml (упрощен путем уменьшения числа служб).
#docker-compose.yml (Base)
version: '3.4'
services:
basket-api:
image: eshop/basket-api:${TAG:-latest}
build:
context: .
dockerfile: src/Services/Basket/Basket.API/Dockerfile
depends_on:
- basketdata
- identity-api
- rabbitmq
catalog-api:
image: eshop/catalog-api:${TAG:-latest}
build:
context: .
dockerfile: src/Services/Catalog/Catalog.API/Dockerfile
depends_on:
- sqldata
- rabbitmq
marketing-api:
image: eshop/marketing-api:${TAG:-latest}
build:
context: .
dockerfile: src/Services/Marketing/Marketing.API/Dockerfile
depends_on:
- sqldata
- nosqldata
- identity-api
- rabbitmq
webmvc:
image: eshop/webmvc:${TAG:-latest}
build:
context: .
dockerfile: src/Web/WebMVC/Dockerfile
depends_on:
- catalog-api
- ordering-api
- identity-api
- basket-api
- marketing-api
sqldata:
image: mcr.microsoft.com/mssql/server:2019-latest
nosqldata:
image: mongo
basketdata:
image: redis
rabbitmq:
image: rabbitmq:3-management
Значения в базовом файле docker-compose.yml не должны изменяться из-за разных целевых сред развертывания.
Если рассмотреть, например, определение службы webmvc, то можно увидеть, что эта информация большей частью одинакова независимо от планируемой среды. В этом определении содержится следующая информация.
Имя службы: webmvc.
Пользовательский образ контейнера: eshop/webmvc.
Команда для создания пользовательского образа Docker, указывающая, какой Dockerfile следует использовать.
Зависимости от других служб, чтобы данный контейнер не запускался до запуска других контейнеров зависимостей.
У вас могут быть дополнительные параметры конфигурации, но суть в том, что в базовом файле docker-compose.yml вы просто задаете ту информацию, которая является общей для всех сред. Затем в файле docker-compose.override.yml или в аналогичных файлах для рабочей или промежуточной среды необходимо указать конфигурацию, характерную для каждой среды.
Обычно файл docker-compose.override.yml используется для среды разработки, как в следующем примере из eShopOnContainers.
#docker-compose.override.yml (Extended config for DEVELOPMENT env.)
version: '3.4'
services:
# Simplified number of services here:
basket-api:
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://0.0.0.0:80
- ConnectionString=${ESHOP_AZURE_REDIS_BASKET_DB:-basketdata}
- identityUrl=http://identity-api
- IdentityUrlExternal=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5105
- EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
- EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
- EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
- AzureServiceBusEnabled=False
- ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
- OrchestratorType=${ORCHESTRATOR_TYPE}
- UseLoadTest=${USE_LOADTEST:-False}
ports:
- "5103:80"
catalog-api:
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://0.0.0.0:80
- ConnectionString=${ESHOP_AZURE_CATALOG_DB:-Server=sqldata;Database=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER]}
- PicBaseUrl=${ESHOP_AZURE_STORAGE_CATALOG_URL:-http://host.docker.internal:5202/api/v1/catalog/items/[0]/pic/}
- EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
- EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
- EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
- AzureStorageAccountName=${ESHOP_AZURE_STORAGE_CATALOG_NAME}
- AzureStorageAccountKey=${ESHOP_AZURE_STORAGE_CATALOG_KEY}
- UseCustomizationData=True
- AzureServiceBusEnabled=False
- AzureStorageEnabled=False
- ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
- OrchestratorType=${ORCHESTRATOR_TYPE}
ports:
- "5101:80"
marketing-api:
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://0.0.0.0:80
- ConnectionString=${ESHOP_AZURE_MARKETING_DB:-Server=sqldata;Database=Microsoft.eShopOnContainers.Services.MarketingDb;User Id=sa;Password=[PLACEHOLDER]}
- MongoConnectionString=${ESHOP_AZURE_COSMOSDB:-mongodb://nosqldata}
- MongoDatabase=MarketingDb
- EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
- EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
- EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
- identityUrl=http://identity-api
- IdentityUrlExternal=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5105
- CampaignDetailFunctionUri=${ESHOP_AZUREFUNC_CAMPAIGN_DETAILS_URI}
- PicBaseUrl=${ESHOP_AZURE_STORAGE_MARKETING_URL:-http://host.docker.internal:5110/api/v1/campaigns/[0]/pic/}
- AzureStorageAccountName=${ESHOP_AZURE_STORAGE_MARKETING_NAME}
- AzureStorageAccountKey=${ESHOP_AZURE_STORAGE_MARKETING_KEY}
- AzureServiceBusEnabled=False
- AzureStorageEnabled=False
- ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
- OrchestratorType=${ORCHESTRATOR_TYPE}
- UseLoadTest=${USE_LOADTEST:-False}
ports:
- "5110:80"
webmvc:
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://0.0.0.0:80
- PurchaseUrl=http://webshoppingapigw
- IdentityUrl=http://10.0.75.1:5105
- MarketingUrl=http://webmarketingapigw
- CatalogUrlHC=http://catalog-api/hc
- OrderingUrlHC=http://ordering-api/hc
- IdentityUrlHC=http://identity-api/hc
- BasketUrlHC=http://basket-api/hc
- MarketingUrlHC=http://marketing-api/hc
- PaymentUrlHC=http://payment-api/hc
- SignalrHubUrl=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5202
- UseCustomizationData=True
- ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
- OrchestratorType=${ORCHESTRATOR_TYPE}
- UseLoadTest=${USE_LOADTEST:-False}
ports:
- "5100:80"
sqldata:
environment:
- SA_PASSWORD=[PLACEHOLDER]
- ACCEPT_EULA=Y
ports:
- "5433:1433"
nosqldata:
ports:
- "27017:27017"
basketdata:
ports:
- "6379:6379"
rabbitmq:
ports:
- "15672:15672"
- "5672:5672"
В этом примере конфигурация переопределения для среды разработки представляет некоторые порты для узла, задает переменные среды с URL-адресами перенаправления, а также указывает строки подключения для среды разработки. Все эти параметры предназначены только для среды разработки.
При выполнении команды docker-compose up (или запуске ее из Visual Studio) эта команда считывает переопределения автоматически, как если бы оба файла были объединены.
Предположим, что требуется другой файл Compose для рабочей среды, с другими значениями конфигурации, портами или строками подключения. Вы можете создать другой файл переопределения, например с именем docker-compose.prod.yml, содержащий другие параметры и переменные среды. Этот файл может храниться в другом репозитории Git или управляться и защищаться другой группой.
Развертывание с помощью конкретного файла переопределения
Чтобы использовать несколько файлов переопределения или файл переопределения с другим именем, можно указать эти файлы с помощью параметра -f в команде docker-compose. Команда compose объединяет файлы в том порядке, в котором они указаны в командной строке. В следующем примере показано, как выполняется развертывание с файлами переопределения.
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d
Использование переменных среды в файлах docker-compose
Удобно, особенно в рабочих средах, иметь возможность получать сведения о конфигурации из переменных среды, как показано в предыдущих примерах. Вы можете ссылаться на переменную среды в файлах docker-compose с помощью синтаксиса ${MY_VAR}. Следующая строка из файла docker-compose.prod.yml показывает, как ссылаться на значение переменной среды.
IdentityUrl=http://${ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP}:5105
Переменные среды создаются и инициализируются разными способами в зависимости от среды узла (Linux, Windows, кластер Cloud и т. п.). Однако рекомендуется использовать ENV-файл. Файлы docker-compose поддерживает объявление переменных среды по умолчанию в ENV-файле. Эти значения для переменных среды являются значениями по умолчанию. Однако они могут быть переопределены значениями, которые, возможно, заданы в каждой из сред (ОС узла или переменные среды из кластера). Этот ENV-файл следует поместить в ту папку, из которой выполняется команда docker-compose.
В следующем примере показан ENV-файл, аналогичный ENV-файлу для приложения eShopOnContainers.
# .env file
ESHOP_EXTERNAL_DNS_NAME_OR_IP=host.docker.internal
ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP=10.121.122.92
Docker-compose ожидает, что каждая строка в env-файле будет находиться в переменной> формата<=<value>.
Значения, установленные в среде выполнения, всегда переопределяют значения, определенные в ENV-файле. Аналогичным образом значения, переданные с помощью аргументов командной строки, тоже переопределяют значения по умолчанию, заданные в ENV-файле.
Дополнительные ресурсы
Общие сведения о Docker Compose
https://docs.docker.com/compose/overview/Несколько файлов Compose
https://docs.docker.com/compose/multiple-compose-files/
Создание оптимизированных образов Docker ASP.NET Core
Если вы изучаете Docker и .NET по источникам в Интернете, вы обнаружите файлы Dockerfile, демонстрирующие простоту создания образа Docker путем копирования источника в контейнер. Эти примеры показывают, что, используя простую конфигурацию, можно получить образ Docker со средой, упакованной с приложением. В следующем примере показан такой простой Dockerfile.
FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /app
ENV ASPNETCORE_URLS http://+:80
EXPOSE 80
COPY . .
RUN dotnet restore
ENTRYPOINT ["dotnet", "run"]
Такой Dockerfile будет работать. Тем не менее вы можете существенно оптимизировать ваши образы, особенно образы рабочей среды.
В модели контейнера и микрослужб вы постоянно запускаете контейнеры. Обычно контейнеры используются таким образом, чтобы не перезапускать спящий контейнер, так как контейнер является одноразовым. Оркестраторы (такие как Kubernetes и Azure Service Fabric) создают экземпляры образов. Это означает, что вам нужно будет выполнить оптимизацию путем предварительной компиляции приложения во время его сборки, чтобы ускорить процесс создания экземпляра. Когда контейнер запускается, он должен быть готов к выполнению. Не следует выполнять восстановление и компиляцию во время выполнения с помощью команд dotnet restore и dotnet build CLI, как показано в записях блога о .NET и Docker.
Команда .NET выполняет важнейшую работу, чтобы сделать .NET и ASP.NET Core платформой, оптимизированной для работы с контейнерами. .NET является не только облегченной платформой с небольшим объемом памяти; команда разработчиков сконцентрировалась на оптимизированных образах Docker для трех основных сценариев и опубликовала их в реестре центра Docker по адресу dotnet/, начиная с версии 2.1:
Разработка: приоритет — это возможность быстро выполнять итерацию и отладку изменений и где размер является вторичным.
Сборка: приоритет компилируется приложение, а образ включает двоичные файлы и другие зависимости для оптимизации двоичных файлов.
Рабочая среда: фокус быстро развертывается и запускает контейнеры, поэтому эти образы ограничены двоичными файлами и содержимым, необходимыми для запуска приложения.
Команда разработчиков .NET предоставляет в dotnet/ (в Docker Hub) четыре основных варианта:
- sdk: для сценариев разработки и сборки;
- aspnet: для производственных сценариев ASP.NET;
- runtime: для производственных сценариев .NET;
- runtime-deps: для сценария рабочей среды у автономных приложений.
Для ускорения запуска образы среды выполнения также автоматически устанавливают aspnetcore_urls на порт 80 и используют Ngen для создания собственного кэша образов сборок.
Дополнительные ресурсы
Создание оптимизированных образов Docker в ASP.NET Corehttps://learn.microsoft.com/archive/blogs/stevelasker/building-optimized-docker-images-with-asp-net-core
Создание образов Docker для приложений .NEThttps://learn.microsoft.com/dotnet/core/docker/building-net-docker-images
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по