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

我希望DevOps CI / CD可以在容器中运行并可以在某些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指定了图像，做了映射端口等。但是我的测试失败了，因为它们无法连接到http://127.0.0.1:10000/devstoreaccount1/landing

我已经尝试在测试中命名容器并替换Uri，以尝试连接到http://azurite:10000/devstoreaccount1/landing

如果我将services部分放在stages之前的某个工作外，它将失败，因为它是无效的YML。

我不太了解如何实现与Azure DevOps的docker-compose相同的功能，以使测试通过CI / CD。希望您能发现问题或提供有关此工作原理的易于理解的解释。另外，如果有人知道如何在本地“调试”，我很乐于学习一些技巧。

更新1：我不知道为什么，但是现在它可以与127.0.0.1 Uri和上述yml（在运行集成测试的工作中定义的services一起使用）。不过问题仍然存在，任何有效的解释为何都行之有效，并使用名称为azurite的名字作为参考。

Answer 1

在您的评论中，您问“为什么127.0.0.1 Uri可用，但主机名azurite不可用”。那是因为您没有在容器内运行作业。请参阅documentation。

此管道启动最新的nginx和redis容器，然后将指定的端口发布到主机。由于作业不在容器中运行，因此没有自动名称解析。本示例说明了如何使用本地主机来访问服务。在上面的示例中，我们显式提供了端口（例如8080：80）。

如果要使主机名解析起作用，则需要在容器内运行测试。

无法在Azure DevOps的多阶段管道中使用其别名连接到容器

1 个答案: