Integração Contínua usando o Docker

Question

Integração Contínua usando o Docker

#1 resposta do (1 votos)
#2 resposta do (0 votos)

5

Uma das principais vantagens do Docker é o ambiente isolado que ele traz, e quero aproveitar essa vantagem em meu fluxo de trabalho de integração contínua.

Um fluxo de trabalho de IC "normal" é mais ou menos assim:

Repositório de pesquisas para alterações
Puxar do repositório
Instalar dependências
Executar testes

Em um fluxo de trabalho de Dockerized, seria algo assim:

Repositório de pesquisas para alterações
Puxar do repositório
Criar imagem de encaixe
Executar a imagem do docker como contêiner
Executar testes
Mata o contêiner docker

Meu problema é com a etapa "executar testes": como o Docker é um ambiente isolado, intuitivamente, gostaria de tratá-lo como um; isso significa que o método preferido de comunicação são os soquetes. No entanto, isso só funciona bem em determinadas situações (uma aplicação web, por exemplo). Ao testar diferentes tipos de serviços (por exemplo, um serviço de segundo plano que apenas se comunicasse com um banco de dados), seria necessária uma abordagem diferente.

Qual é a melhor maneira de abordar esse problema? É um problema com o design do meu aplicativo, e eu deveria projetá-lo de uma maneira mais orientada a serviços, que sempre escuta em algum soquete? Ou eu deveria desistir do isolamento e fazer algo assim:

Repositório de pesquisas para alterações
Puxar do repositório
Criar imagem de encaixe
Executar a imagem do docker como contêiner
Abra a sessão SSH no contêiner
Executar testes
Mata o contêiner docker

O SSH para o contêiner parece uma solução feia para mim, já que requer profundo conhecimento do conteúdo do contêiner e, portanto, quebra o isolamento.

Eu adoraria ouvir as diferentes abordagens do SO para esse problema.

testing continuous-integration docker

por Leon Mergen 10.06.2014 / 06:06

fonte

2 respostas

Tags testing continuous-integration docker

Interface no nível de classe ou função? Licenciamento GPLv3 e aplicativos da Web Software-as-a-Service [duplicados]

score 1 · Answer 1

Você pode inverter a lógica movendo o executor de testes para a imagem do docker:

Os testes são executados na imagem do docker, portanto, eles acessam o aplicativo como em qualquer outro contexto, e a presença do docker não altera nada.
A agregação dos resultados do teste é onde a conexão se torna um problema. A tecnologia atual usada dependerá da sua infraestrutura atual. Pode ser também uma fila de mensagens, uma API personalizada ou um acesso direto ao banco de dados.
Como pertence ao processo executado dentro de uma imagem de encaixe para relatar os resultados do teste e não ao serviço central para extrair os resultados dos corredores de teste, isso significa que, novamente, a presença da imagem do docker não não faz diferença.

score 0 · Answer 2

Uma maneira bastante padrão de fazer testes com imagens do Docker é:

Crie uma imagem de teste, com base na imagem que você está testando, mas adicione o test runner e os testes. (Você não precisa fazer isso; você pode incluir todos os testes na imagem de base, mas é mais limpo separá-los).
A comunicação com imagens do Docker geralmente é feita de forma limpa com sobreposições do sistema de arquivos. Portanto, monte um diretório do host no contêiner (por exemplo, com -v /path/to/workspace/:/tests ou algo semelhante).
O executor de testes pode gerar um arquivo de resultado, por exemplo, junit.xml ou algo parecido. Se a saída for para a pasta / tests, seu ambiente de CI poderá obtê-la a partir daí.
invoque o executor de teste substituindo o ponto de entrada na linha docker run . Por exemplo. docker run container --entrypoint=/test-runner.py (ou o que for apropriado para sua aplicação). Isso funciona bem para testes de unidade.

Para testes de integração, você geralmente precisa orquestrar o lançamento de vários contêineres fora do Docker de qualquer maneira.