Configuración de ClickHouse para pruebas de integración en gitlab-ci

Teníamos un servicio en Golang, un tema separado kafka, clickhouse, gitlab-ci y una línea de pago que cae, una llave ssh podrida y eso es todo, junto con una temporada de vacaciones, lluvias terribles en la ciudad, una computadora portátil rota, alertas por la noche y una venta caliente . No es que todo esto fuera necesario para este artículo, pero una vez que muestres la vida cotidiana típica del probador, entonces ve en tu intención hasta el final. Lo único que me molestó fue p0. En el mundo no hay nada más desesperado, sombrío y deprimido que el probador que se lo perdió en la picadura. Pero sabía que muy pronto me lanzaría a ello.

¿Por qué todo esto?

Hay un paquete común de servicios, el servicio en sí mismo que hace algo, y una base de datos en la que se escriben estos resultados. a veces esto sucede directamente, es decir, "base de servicio". En mi caso, la grabación se realiza a través de un intermediario, es decir, "servicio - cola - base".

En total, hay varios elementos, y el borde de estos elementos, la salida de uno y la entrada del otro, es el lugar donde aparecen los problemas. Simplemente no pueden no aparecer allí.

Un ejemplo vívido: en el servicio, el campo de precio se trata como float32, en la base de datos está configurado como decimal (18, 5), alimentamos el valor máximo de float32 como un caso de prueba de la salida del servicio a la base de datos; oh, la base de datos no responde. O un ejemplo más triste: la base de datos no se bloquea, pero no hay ningún error en los registros de datos de la base de datos. es solo que la base de datos ya no se vierte. O la grabación continúa, pero con pérdida de datos o con distorsión: el campo sale del servicio como float64 y se graba como float32.

O, en el proceso del ciclo de vida del servicio, decidieron que era necesario cambiar el tipo de este o aquel campo. El campo se ha implementado durante mucho tiempo en el producto, pero aquí es necesario editarlo. Y, por supuesto, lo cambiamos en un solo lugar. Hoba, algo salió mal otra vez.

Desafío

No quiero hacer un seguimiento de todos estos cambios. Quiero que no se caiga. Quiero que la grabación salga bien.

Salir: pruebas de integración!

Implementación y dificultades

¿Dónde romper?

Hay un entorno de desarrollo: terriblemente inestable y los desarrolladores suelen utilizarlo como un entorno limitado. Hay caos y anarquía característicos de un backend duro.

Hay un entorno de prueba o soporte de qa: está mejor ajustado, incluso los devops lo están mirando, pero hasta que los patees, no pasará nada. y este entorno a menudo se actualiza. e incluso más a menudo, algo se rompe allí.

Y hay un pinchazo: el santo de los santos: es mejor no conducir algo así. Las pruebas de integración sugieren la posibilidad de un error que deben encontrar antes de que llegue al producto.

Entonces, ¿qué hacer con el medio ambiente cuando es inestable o combate? Así es, ¡crea el tuyo!

¿Qué hacer con la base?

La base de datos se puede iniciar de varias maneras.

Como discutimos anteriormente, no nos conectaremos a la base real de este o aquel entorno.

En primer lugar, puede elevar el servidor de clickhouse-cruttle con la configuración necesaria, implementar el sql necesario y comunicarse con él a través de clickhouse-client. En el primer intento exitoso de poner una base similar, ci estaba triste. Las pruebas parpadearon, el servidor no se apagó y continuó funcionando. Digamos que sigue siendo un misterio para mí por qué incluso comenzó. (en sí mismo, no tengo nada que ver con eso). No recomiendo esta opción

Una opción conveniente fuera de la caja es el uso de una imagen acoplable .
Descargue la versión deseada a su automóvil. Clickhouse necesita config.xml con la configuración para comenzar. Más detalles aquí
Para la imagen de clic reutilizada, debe crear el dockerfile correcto. Indicamos que queremos copiar config.xl en la carpeta, acoplamos las otras configuraciones requeridas. Asegúrese de copiar los scripts para implementar su base.

Dado que accederemos a la imagen desde el exterior, debemos abrir los puertos a través de los cuales nos comunicaremos con Clickhouse. Click funciona en 8123 en http y en 9000 en tcp.

Obtenemos el siguiente dockerfile:

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/ 

¿Cómo lanzar una imagen en ci?

Para trabajar de alguna manera con la imagen del acoplador en ci, debe llamarlo de alguna manera allí.

Puede confirmar y ejecutar la imagen en su repositorio y ejecutar Docker Run con los parámetros necesarios como parte de la ejecución de las pruebas. Solo aquí la imagen acoplable del clic pesa menos de 350mb. es indecente mantener esos archivos en git.

Además, si se necesita la misma imagen del acoplador en diferentes proyectos (por ejemplo, se escriben diferentes servicios en la misma base de datos), entonces aún más, no debe hacer esto. Puede usar el almacenamiento de imágenes de registro de Docker
Creemos que en nuestro proyecto ya existe y se utiliza. Por lo tanto, inicie sesión, recopile la imagen del acoplador y empújela allí.

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

Bajó y nuestra imagen voló al registro. ¡Asegúrese de especificar la etiqueta durante el montaje!

La base está lista.

Lea más sobre el registro aquí

¿Qué hacer con ci?

¿Cómo lanzar su servicio y su base de datos en un solo paso?

Todo depende de cómo comenzamos y usamos el servicio. Si trabaja con el servicio como con una imagen acoplable, y de hecho todo .gitlab-ci.yml solo funciona con ellos, entonces todo es simple.
Hay un callejón sin salida: docker-in-docker . Se indica como el servicio principal con el que trabaja ci, y le permite utilizar completamente la ventana acoplable y no forzar en absoluto.

Generamos la última imagen, agregamos el paso de prueba requerido a las etapas y describimos nuestra secuencia de acciones.

 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 

El docker oficial Docker afirma que no se recomienda usar dind , pero si realmente necesita ...

En mi proyecto, el servicio debe probarse mediante el lanzamiento del binario. Aquí es donde comienza la magia.
Para hacer esto, use la base de datos como un servicio. La documentación oficial de gitlab-ci cita el uso de un contenedor con una base como ejemplo del caso de uso más común para un contenedor acoplable en ci. Incluso se proporcionan ejemplos de configuraciones mysql, postress y redis. Pero no estamos buscando formas fáciles, necesitamos un clickhouse.

¡Conecta la base! Asegúrese de especificar el alias. Si no se especifica, a la base se le asignará un nombre aleatorio y una IP aleatoria. Es decir, no estará claro exactamente cómo acceder a él. No habrá tal problema con el alias: en el código de prueba, la llamada se verá, por ejemplo, en http://my_alias_name:8123 .

Para las pruebas, todavía se requiere una imagen de la base de datos, que colocamos cuidadosamente en el registro. Para descargar la imagen, debe hacer el inicio de sesión y la extracción de Docker, solo ci no sabe qué es Docker; debe instalarlo.

El código resultante para el paso en 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 

Ganancia

• Tengo un montón de base de servicio que funciona.
• Como parte de la prueba automática, es fácil acceder a la base de datos, simplemente por alias.
• Restablezco los registros y la configuración de la base de datos como parte de la prueba de configuración, llamo al servicio, escribe en la base de datos, me dirijo a la base de datos, veo que la base de datos no se ha caído, veo lo que ha llegado y valido. lanzar más pruebas
• ¡No puedes probar con bolígrafos!

Resultados

Parece que hay un par de líneas de configuración en gitlab-ci. Construir una imagen acoplable es fácil. Ejecutar localmente localmente es simple. Tuve integración con las primeras pruebas que encontraron problemas en un día. Pero los intentos de lanzarlo en ci se convirtieron en una semana de dolor y desesperanza. Y ahora, en las semanas de dolor y desesperanza de los desarrolladores que tienen que reparar todo lo que han programado allí.

¿Qué logramos hacer?

• Configuramos un contenedor con clickhouse.
• Comenzamos el contenedor en el almacenamiento local.
• Aprendimos a llevar esta imagen al paso ci.
• Lanzado en el corredor.

Envió datos fácilmente a la base de datos y accedió a ellos desde la prueba.

La automatización es una forma bastante simple de deshacerse de la rutina de la integración de perforación manual.

A qué es importante prestar atención: asegúrese de que los tipos de entrada de la base corresponden a los tipos de salida del enlace anterior. (y documentación , si la hay ).