Можно ли использовать Docker .Do tNet для программного запуска контейнера на Azure конвейерах? - PullRequest
Новая
       95

Можно ли использовать Docker .Do tNet для программного запуска контейнера на Azure конвейерах?

0 голосов
/ 29 мая 2020

У меня есть приложение для микросервисов, и я не хочу запускать весь стек для выполнения интеграционных тестов. Идея состоит в том, чтобы иметь возможность запускать тесты из обозревателя тестов в Visual Studio. Поэтому я не хочу создавать сценарий оболочки, чтобы выполнить sh это.

Идея состоит в том, чтобы запустить все внешние зависимости микросервисов в контейнерах, а затем запустить TestServer тестируемой системы для получения тестовые запросы, чтобы система могла вызывать другие микросервисы.

Я нашел эту библиотеку, и мне понравилась идея программного запуска контейнеров для достижения вышеупомянутого.

Что я не знаю, будет ли это работать на конвейере Azure. Каким будет правильный адрес docker двигателя на Azure для инициализации Docker .Do tNet? 

// Default Docker Engine on Windows
using Docker.DotNet;
DockerClient client = new DockerClientConfiguration(
    new Uri("npipe://./pipe/docker_engine"))
     .CreateClient();
// Default Docker Engine on Linux
using Docker.DotNet;
DockerClient client = new DockerClientConfiguration(
    new Uri("unix:///var/run/docker.sock"))
     .CreateClient();

Ответы [ 2 ]

1 голос
/ 02 июня 2020

Я не знаю, будет ли это работать на конвейере Azure. Каким будет правильный адрес docker двигателя на Azure для инициализации Docker .Do tNet?

Вы можете добавить задачу Powershell в свой конвейер, который выполняется в размещенном агенте windows с таким содержимым: 

[System.IO.Directory]::GetFiles("\\.\\pipe\\") | Select-String "docker"

Вот результат, если я использую размещенный агент windows2019:

enter image description here

Итак, я думаю, что это адрес \\.\\pipe\\docker_engine (не уверен, нужны ли ему какие-то изменения, такие как sla sh и backsla sh при использовании в вашем коде), надеюсь, это поможет.

0 голосов
/ 02 июня 2020

Я провел небольшое исследование и обнаружил, что образы Windows и Linux для агентов, размещенных на Ms, имеют предустановленные Docker и Docker -Compose, поэтому с помощью этих агентов можно запускать контейнеры.

Моя проблема заключалась в том, что я не понимал, что команда Ops настроила агента Linux. Я пытался выполнить, используя именованный канал Windows, а не сокет Unix.

Я соответствующим образом изменил адрес Docker Engine API, и он сработал.

Вот мой код на случай, если кто-то заинтересован в создании интеграционных тестов, запускающих контейнеры для зависимостей микросервисов: 

using Docker.DotNet;
using System;
using System.Runtime.InteropServices;

namespace Relationship.Promotion.Applier.IntegrationTest.Helpers
{
    public class DockerClientFactory
    {
        private static readonly Uri defaultWindowsDockerEngineUri = new Uri("npipe://./pipe/docker_engine");
        private static readonly Uri defaultLinuxDockerEngineUri = new Uri("unix:///var/run/docker.sock");

        public static DockerClient CreateInstance()
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
                return new DockerClientConfiguration(defaultWindowsDockerEngineUri).CreateClient();
            else
                return new DockerClientConfiguration(defaultLinuxDockerEngineUri).CreateClient();
        }
    }
}

namespace Relationship.Promotion.Applier.IntegrationTest
{
    public class CustomWebApplicationFactory<TStartup> : WebApplicationFactory<TStartup> where TStartup : class
    {
        private readonly DockerClient dockerClient;
        private readonly PromotionContainer promotionContainer;
        private readonly StoreContainer storeContainer;
        private readonly ConversionContainer conversionContainer;

        public CustomWebApplicationFactory()
        {
            try
            {
                // Alternative to Docker.DotNet
                // https://github.com/Deffiss/testenvironment-docker
                dockerClient = DockerClientFactory.CreateInstance();

                DockerContainerBase.CleanupOrphanedContainers(dockerClient).Wait(300.Seconds());

                if (!dockerClient.Networks.ListNetworksAsync().Result.Select(n => n.Name).Contains("boti-network"))
                {
                    var result = dockerClient.Networks.CreateNetworkAsync(new Docker.DotNet.Models.NetworksCreateParameters()
                    {
                        Name = "boti-network",
                        Driver = "bridge"
                    }).Result;
                }

                promotionContainer = new PromotionContainer(imageName: "promotion-engine-promotion-api");
                promotionContainer.Start(dockerClient).Wait(300.Seconds());

                conversionContainer = new ConversionContainer(imageName: "promotion-engine-conversion-api");
                conversionContainer.Start(dockerClient).Wait(300.Seconds());

                storeContainer = new StoreContainer("promotion-engine-store-api");
                storeContainer.Start(dockerClient).Wait(300.Seconds());
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);

                throw;
            }
        }

        protected override IWebHostBuilder CreateWebHostBuilder()
        {
            return base.CreateWebHostBuilder().UseEnvironment("Docker");
        }

        protected override void Dispose(bool itIsSafeToAlsoFreeManagedObjects)
        {
            if (!itIsSafeToAlsoFreeManagedObjects) return;

            promotionContainer.Remove(dockerClient).Wait(300.Seconds());
            conversionContainer.Remove(dockerClient).Wait(300.Seconds());
            storeContainer.Remove(dockerClient).Wait(300.Seconds());

            dockerClient.Dispose();

            base.Dispose(itIsSafeToAlsoFreeManagedObjects);
        }
    }
}
...