Поделиться через

Определение приложения с несколькими контейнерами с помощью docker-compose.yml

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Архитектура микросервисов .NET для приложений .NET в контейнерах, миниатюра обложки электронной книги.

В этом руководстве представлен файл docker-compose.yml в разделе 4. Определите службы в docker-compose.yml при создании многоконтейнерного приложения Docker. Однако существуют дополнительные способы использования файлов docker-compose, которые стоит подробно изучить.

Например, можно явно описать, как развернуть приложение с несколькими контейнерами в файле docker-compose.yml. Кроме того, вы можете описать, как создавать пользовательские образы Docker. (Пользовательские образы Docker также можно создавать с помощью Docker CLI.)

В основном вы определяете каждый из контейнеров, которые вы хотите развернуть, плюс определенные характеристики для каждого развертывания контейнера. Получив файл описания развертывания с несколькими контейнерами, вы можете развернуть все решение в одном действии, оркеструемом с помощью команды docker-compose up CLI или прозрачно развернуть его из Visual Studio. В противном случае, вам потребуется использовать интерфейс командной строки Docker для развертывания контейнеров по отдельности, выполняя несколько шагов с помощью команды 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

Корневой ключ в этом файле — службы. В этом разделе вы определяете службы, которые необходимо развернуть и запустить при выполнении docker-compose up команды или при развертывании из Visual Studio с помощью этого docker-compose.yml файла. В этом случае файл docker-compose.yml содержит несколько служб, как описано в следующей таблице.

Название сервиса Описание
webmvc Контейнер с приложением ASP.NET Core MVC, которое взаимодействует с микрослужбами на стороне сервера C#
catalog-api Контейнер, содержащий микрослужбу веб-API на основе ASP.NET Core для каталога.
API для заказов Контейнер, содержащий микросервис ASP.NET Core Web API для заказов
sqldata Контейнер под управлением SQL Server для Linux, содержащий базы данных микрослужб
API корзины Контейнер с микросервисом Web API "Корзина" на платформе ASP.NET Core
данные корзины Контейнер под управлением службы кэша REDIS с базой данных корзины в качестве кэша 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) или был скачан (с командой извлечения Docker) из любого реестра 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 для внутреннего доступа к службе api каталога в узле Docker. В настоящее время узел является виртуальной машиной Linux, так как он основан на образе Docker для Linux, но вместо этого можно настроить контейнер для запуска на образе Windows.

  • Он перенаправит открытый порт 80 на контейнере на порт 5101 хост-компьютера Docker (виртуальная машина Linux).

  • Он связывает веб-службу со службой sqldata (экземпляр SQL Server для базы данных Linux, работающей в контейнере). При указании этой зависимости контейнер catalog-api не будет запускаться до тех пор, пока контейнер sqldata уже не запущен; этот аспект важен, так как 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 можно использовать следующие основные сценарии.

Среды разработки

При разработке приложений важно иметь возможность запускать приложение в изолированной среде разработки. Чтобы создать эту среду, можно использовать команду docker-compose CLI или 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.

Если вы используете любой другой оркестратор (например, Azure Service Fabric или Kubernetes), может потребоваться добавить параметры настройки и метаданных, такие как в docker-compose.yml, но в формате, необходимом для другого оркестратора.

В любом случае docker-compose — это удобный инструмент и формат метаданных для разработки, тестирования и рабочих процессов, хотя рабочий процесс может отличаться в зависимости от используемого оркестратора.

Использование нескольких файлов docker-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\ в главной папке решения.

Файлы в проекте docker Compose.

Рис. 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 на несколько файлов, как показано на рис. 6-12.

Схема трех файлов docker-compose, установленных для переопределения базового файла.

Рис. 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, облачного кластера и т. д.). Однако удобный подход — использовать 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-файле будет в формате <переменная>=<значение>.

Значения, заданные в среде выполнения, всегда переопределяют значения, определенные внутри ENV-файла. Аналогичным образом значения, передаваемые через аргументы командной строки, также переопределяют значения по умолчанию, заданные в env-файле.

Дополнительные ресурсы

Создание оптимизированных образов Docker ASP.NET Core

Если вы изучаете Docker и .NET в источниках в Интернете, вы найдете Dockerfiles, которые демонстрируют простоту создания образа 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) создают новые экземпляры образов. Это означает, что необходимо оптимизировать путем предварительной компиляции приложения при его создании, чтобы процесс создания экземпляра был быстрее. Когда контейнер запущен, он должен быть готов к работе. Не выполняйте восстановление и компиляцию во время работы с помощью команд CLI dotnet restore и dotnet build, как можно прочитать в блогах о .NET и Docker.

Команда .NET выполняет важную работу, чтобы сделать .NET и ASP.NET Core платформой, оптимизированной для контейнеров. Не только платформа .NET является легковесной и потребляющей мало памяти, но и команда сосредоточилась на том, чтобы оптимизировать образы Docker для трех основных сценариев и опубликовала их в реестре Docker Hub в dotnet/, начиная с версии 2.1:

  • Разработка: приоритет — это возможность быстро выполнять итерацию и отладку изменений и где размер является вторичным.
  • Сборка: приоритет - компиляция приложения, а образ включает двоичные файлы и другие зависимости для оптимизации компиляции двоичных файлов.
  • Производство: фокус на быстром развертывании и запуске контейнеров, поэтому эти образы содержат только двоичные файлы и содержимое, необходимые для запуска приложения.

Команда .NET предоставляет некоторые основные варианты в dotnet/, например:

  • sdk: для сценариев разработки и сборки
  • aspnet: для сценариев ASP.NET рабочей среды
  • среда выполнения: для рабочих сценариев .NET
  • deps среды выполнения: для рабочих сценариев автономных приложений

Для ускорения запуска образы среды выполнения также автоматически устанавливают aspnetcore_urls на порт 80 и используют Ngen для создания собственного кэша образов сборок.

Дополнительные ресурсы

НазадДалее