Невозможно подключиться к контейнеру, используя его псевдоним в многоступенчатом конвейере в Azure DevOps

Question

Я изо всех сил пытаюсь понять служебные контейнеры и у меня работает простой сценарий. Документация здесь: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/service-containers?view=azure-devops&tabs=yaml мне не очень понятна, и примеры даже не действительны (см. https://github.com/MicrosoftDocs/vsts-docs/issues/4187

Я хотел бы иметь CI / CD DevOps работает с моими тестами, когда контейнер работает и доступен в определенном Uri, поэтому мои тесты могут запускаться в DevOps, поскольку они выполняются локально.

Для этого примера я использую образ Azurite docker. Если я Запустите контейнер локально со следующим:

version: '3'
services:
    sqlserver:
        image: mcr.microsoft.com/azure-storage/azurite:3.6.0
        restart: always
        ports:
            - 10000:10000
            - 10001:10001
# Run
# docker-compose -f azurite.yml up -d 

Я могу подключиться из моих интеграционных тестов к этому контейнеру, чтобы выполнить тесты, используя следующий Uri: http://127.0.0.1:10000/devstoreaccount1/landing

В другом словами, мои тесты хорошо работают локально при доступе к 127.0.0.1:10000, потому что по этому адресу есть контейнер, прослушивающий.

Мне нужно, чтобы мои тесты работали также в Azure DevOps CI / CD, поэтому у меня есть следующие мульти -стадийные конвейеры:

trigger:
- master

pool:
  vmImage: ubuntu-18.04

variables:
  - group: nuget-variables
  - name: NUGET_FOLDER_NAME
    value: nupkgs
  - name: PIPELINE_ARTIFACT_NAME
    value: $(Build.BuildNumber)
  - name: PATH_PIPELINE_ARTIFACT_NAME
    value: $(Pipeline.Workspace)/$(PIPELINE_ARTIFACT_NAME)
  - name: NUGET_API_KEY
    value: $(nuget-api-key)
  - name: NUGET_FEED
    value: $(nuget-feed)
  - name: PRERELEASE_SUFFIX
    value: $(nuget-prerelease-suffix)

resources:
  containers:
    - container: azurite
      image: mcr.microsoft.com/azure-storage/azurite:3.6.0
      ports:
      - 10000:10000
      - 10001:10001

stages:
  - stage:
    displayName: 'Build'
    jobs:
      - job: 'Build'
        displayName: 'Build & Create nuGet Package'
        services:
            azurite: azurite
        steps:
          - task: UseDotNet@2
            displayName: 'Use .NET Core sdk 3.1'
            inputs:
              packageType: sdk
              version: 3.1.x
              includePreviewVersions: false
              installationPath: $(Agent.ToolsDirectory)/dotnet
          - task: NuGetAuthenticate@0
            displayName: 'Authenticate in NuGet feed'
          - script: dotnet restore --no-cache --force
            displayName: 'Restore dependencies'
          - script: dotnet build --configuration Release --no-restore
            displayName: 'Build with Release Configuration'
          - script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
            displayName: 'Run unit tests'
          - script: dotnet vstest test/*IntegrationTests/bin/Release/**/*IntegrationTests.dll
            displayName: 'Run integration tests'
          - script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME) --include-symbols -p:SymbolPackageFormat=snupkg
            condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
            displayName: 'Create release nuGet'
          - publish: $(System.DefaultWorkingDirectory)/$(NUGET_FOLDER_NAME)
            artifact: $(PIPELINE_ARTIFACT_NAME)
            displayName: 'Publish pipeline artifact'
  - stage:
    displayName: 'Release'
    condition: succeeded()
    jobs:
      - job: 'Publish'
        displayName: 'Publish nuGet Package'
        steps:
          - download: current
            artifact: $(PIPELINE_ARTIFACT_NAME)
            displayName: 'Download pipeline artifact'
          - script: echo More irrelevant things here

Как видите, я указываю образ для Azurite, выполняю порты сопоставления и т. д. c., но мои тесты не проходят, потому что они не могут подключиться к http://127.0.0.1:10000/devstoreaccount1/landing

Я пытался назвать содержимое и заменив Uri в моих тестах, чтобы попытаться подключиться к http://azurite:10000/devstoreaccount1/landing

Если я размещу раздел services вне задания незадолго до stages, он не будет работать как недействительный YML.

Я не совсем понимаю, как добиться эквивалента моей docker -композиции с Azure DevOps , чтобы мои тесты проходили в CI / CD. Надеюсь, вы заметите проблему или предоставите понятное объяснение того, как это работает. Кроме того, если кто-нибудь знает, как я могу «отладить» это локально, я был бы более чем счастлив узнать некоторые трюки.

---

ОБНОВЛЕНИЕ 1: я не знаю почему, но теперь это работало с 127.0.0.1 Uri и вышеприведенный yml (services, определенный для задания, в котором выполняются интеграционные тесты). Однако остается вопрос, и любое хорошее объяснение того, почему это работает, и ссылка на имя azurite не будет правильным ответом.

Answer 1

В своем комментарии вы спросили: «Почему доступен Uri 127.0.0.1, но не азурит имени узла». Это потому, что вы не выполняете работу внутри контейнера. См. Документацию .

. Этот конвейер запускает самые последние nginx и перенаправляет контейнеры, а затем публикует указанные порты на хосте. Поскольку задание не выполняется в контейнере, автоматическое разрешение имен c отсутствует. В этом примере показано, как вместо этого вы можете обращаться к сервисам с помощью localhost. В приведенном выше примере мы предоставляем порт в явном виде (например, 8080: 80).

Вам нужно запускать свои тесты внутри контейнера, если вы хотите, чтобы разрешение имен хостов работало.