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.