Configurando o ClickHouse para teste de integração no gitlab-ci

Tivemos um serviço em golang, um tópico separado kafka, clickhouse, gitlab-ci e uma linha de pagamento em queda, uma ssh key podre e isso é tudo, além de uma temporada de férias, chuvas terríveis na cidade, um laptop quebrado, alertas à noite e uma venda quente . Não que tudo isso fosse necessário para este artigo, mas depois que você mostrar a vida cotidiana típica do testador, prossiga com sua intenção até o fim. A única coisa que me incomodou foi p0. No mundo, não há nada mais desesperado, sombrio e deprimido do que o testador que perdeu o teste. Mas eu sabia que logo iria mergulhar nela.

Por que tudo isso?

Existe um pacote comum de serviços - o próprio serviço que faz alguma coisa - e um banco de dados no qual esses resultados são gravados. às vezes isso acontece diretamente, ou seja, "serviço - base". No meu caso, a gravação ocorre através de um intermediário, ou seja, "serviço - fila - base".

No total, existem vários elementos, e a borda desses elementos - a saída de um e a entrada do outro - é o local onde os problemas aparecem. Eles simplesmente não podem não aparecer lá.

Um exemplo vívido: no serviço, o campo de preço é processado como float32, no banco de dados é configurado como decimal (18, 5), alimentamos o valor máximo de float32 como um caso de teste da saída do serviço para o banco de dados - ah, o banco de dados não responde. Ou um exemplo mais triste - o banco de dados não falha, mas não há erro nos logs de dados no banco de dados. é só que o banco de dados não funciona mais. Ou a gravação continua, mas com perda de dados ou distorção: o campo sai do serviço como float64 e é gravado como float32.

Ou, no processo do ciclo de vida de serviço, eles decidiram que era necessário alterar o tipo deste ou daquele campo. O campo já foi implementado no produto, mas aqui é necessário editá-lo. E é claro que mudamos em apenas um lugar. Hoba, algo deu errado novamente.

Desafio

Não quero acompanhar todas essas mudanças. Eu quero que não caia. Eu quero que a gravação dê certo.

Saída: testes de integração!

Implementação e dificuldades

Onde quebrar?

Existe um ambiente de desenvolvimento: terrivelmente instável e geralmente é usado pelos desenvolvedores como uma caixa de areia. Há caos e anarquia característica de um back-end rígido.

Existe um ambiente de teste ou qa-stand: é melhor configurado, até os devops estão assistindo, mas até você chutá-los, nada acontecerá. e esse ambiente é frequentemente atualizado. e ainda mais frequentemente, algo está quebrado lá.

E há um estímulo - o santo dos santos: é melhor não dirigir algo assim sobre ele. testes de integração sugerem a possibilidade de um bug que eles devem encontrar antes de chegar ao produto.

Então, o que fazer com o meio ambiente quando é instável ou combate? É isso mesmo, crie o seu!

O que fazer com a base?

O banco de dados pode ser iniciado de várias maneiras.

Como discutimos acima, não nos conectaremos à base real deste ou daquele ambiente.

Primeiramente, você pode aumentar o servidor de cliques do cruttle com as configurações necessárias, aplicar o sql necessário e se comunicar com ele via cliente do clic. Na primeira tentativa bem-sucedida de colocar uma base semelhante, ci ficou triste. os testes piscaram, o servidor não saiu e continuou a trabalhar. Vamos apenas dizer, ainda permanece um mistério para mim por que começou. (por si só, não tenho nada a ver com isso). Eu não recomendo esta opção.

Uma opção conveniente imediata é o uso de uma imagem do docker .
Baixe a versão desejada para o seu carro. O Clickhouse precisa do config.xml com as configurações para iniciar. Mais detalhes aqui
Para a imagem de clique reutilizada, é necessário criar o arquivo docker correto. Nós indicamos que queremos copiar o config.xl para a pasta, encaixamos as outras configurações necessárias. Certifique-se de copiar os scripts para implantar sua base.

Como acessaremos a imagem de fora, precisamos abrir as portas pelas quais nos comunicaremos com a clickhouse. O clique funciona em 8123 em http e em 9000 em tcp.

Temos o seguinte arquivo docker:

From yandex/clickhouse-server Expose 8123 Expose 9000 Add config.xml /etc/clickhouse-server/config.xml Add my_init_script.sql /docker-entrypoint-initdb.d/ 

Como lançar uma imagem em ci?

Para trabalhar de alguma forma com a imagem da janela de encaixe em ci, é necessário chamá-la de alguma forma.

Você pode confirmar e executar a imagem em seu repositório e executar a janela de encaixe com os parâmetros necessários como parte da execução dos testes. Somente aqui a imagem do encaixe do clique pesa menos de 350mb. é indecente manter esses arquivos no git.

Além disso, se a mesma imagem de janela de encaixe for necessária em projetos diferentes (por exemplo, serviços diferentes são gravados no mesmo banco de dados), ainda mais, para que você não faça isso. Você pode usar o armazenamento de imagens do Registro do Docker
Acreditamos que em nosso projeto ele já existe e é usado. Portanto, efetue login, colete a imagem do docker e empurre-a para lá.

 docker build -t my_clickhouse_image . docker login my_registry_path.domain.com docker push my_clickhouse_image 

Desceu e nossa imagem voou para o registro. Certifique-se de especificar a etiqueta durante a montagem!

A base está pronta.

Leia mais sobre o registro aqui

O que fazer com ci?

Como iniciar o serviço e o banco de dados em uma única etapa?

Tudo depende de como iniciamos e usamos o serviço. Se você trabalha com o serviço como com uma imagem do docker e, de fato, o .gitlab-ci.yml trabalha apenas com eles, tudo é simples.
Há um dind stray - docker-in-docker . É indicado como o serviço principal com o qual a ci trabalha e permite que você use totalmente a janela de encaixe e sem sobrecarregar.

Distribuímos a imagem mais recente, adicionamos a etapa de teste necessária aos estágios e descrevemos nossa sequência de ações.

 image: docker:stable services: - docker:dind stages: - build … - test-click ... - test - release … test-click: variables: VERY_IMPORTANT_VARIABLE: “its value” before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - docker pull My_Service_Image - docker pull My_ClickHouse_Image - docker run -FLAGS My_ClickHouse_Image - docker run My_Service_Image /path/to/tests 

A janela de encaixe docker oficial afirma que não é recomendável usar dind , mas se você realmente precisar ...

No meu projeto, o serviço deve ser testado através do lançamento do binário. É aqui que a mágica começa.
Para fazer isso, use o banco de dados como um serviço. A documentação oficial do gitlab-ci cita o uso de um contêiner com base como um exemplo do caso de uso mais comum para um contêiner de docker no ci. Até exemplos de configurações mysql, postress e redis são fornecidos. Mas não estamos procurando maneiras fáceis, precisamos de uma casa de cliques.

Conecte a base! Certifique-se de especificar o alias. se não for especificado, será atribuído à base um nome aleatório e um ip aleatório. Ou seja, não ficará claro exatamente como acessá-lo. Não haverá esse problema com o alias - no código de teste, a chamada será semelhante, por exemplo, por http://my_alias_name:8123 .

Para os testes, ainda é necessária uma imagem do banco de dados, que colocamos cuidadosamente no registro. Para baixar a imagem, você precisa fazer o login e puxar o docker, apenas o ci não sabe o que é o docker - é necessário instalá-lo.

O código resultante para a etapa no gitlab-ci.yml:

 Integration tests: Services: - name: my_clickhouse:latest alias: clicktest Stage: tests Variables: Variables_for_my_service: “value” Before_script: - curl -ssl https://get.docker.com/ | sh - docker login -u gitlab-ci-token -p $ci_build_token my_registry_path.domain.com Script: - ./bin/my_service & - go test -v ./tests -tags=integration Dependencies: - build 

Lucro

• Eu tenho um monte de trabalho de base de serviço.
• Como parte do autoteste, é fácil acessar o banco de dados - simplesmente por meio de alias.
• Redefino os registros e configurações do banco de dados como parte do teste de instalação, ligo para o serviço, ele grava no banco de dados, ligo para o banco de dados, vejo que o banco de dados não caiu, vejo o que chegou, valido. faça mais testes.
• Você não pode testar com canetas!

Resultados

Parece que algumas linhas de configuração no gitlab-ci. Criar uma imagem do docker é fácil. Executar o local localmente é simples. Eu consegui integração com os primeiros testes que encontraram problemas em um dia. Mas as tentativas de lançá-lo no ci se transformaram em uma semana de dor e desesperança. E agora, nas semanas de dor e desesperança de desenvolvedores que precisam reparar tudo o que programaram lá.

O que conseguimos fazer?

• Montamos um contêiner com clickhouse.
• Iniciamos o contêiner no armazenamento local.
• Aprendemos a colocar essa imagem na etapa ci.
• Lançado no corredor.

Envie dados facilmente para o banco de dados e acesse-os a partir do teste.

A automação é uma maneira bastante simples de se livrar da rotina de integração manual de perfurações.

O que é importante prestar atenção: verifique se os tipos de entrada da base correspondem aos tipos de saída do link anterior. (e documentação , se houver ).