Buenas tardes
Casi inmediatamente despu茅s de instalar y configurar CI / CD de acuerdo con las instrucciones de la publicaci贸n anterior , el equipo ten铆a una pregunta sobre c贸mo llevar a cabo las pruebas de integraci贸n correctamente. Ya ten铆amos experiencia en la ejecuci贸n de dependencias de prueba en los contenedores de docker, pero esto se ha vuelto problem谩tico desde que el ensamblaje se lanz贸 ahora en el contenedor. En este art铆culo, me gustar铆a describir dos posibles m茅todos de pruebas de integraci贸n dentro del contenedor que se adaptan a mi equipo.
Requisitos de prueba de integraci贸n
Por definici贸n, las pruebas de integraci贸n son pruebas que prueban el funcionamiento de una aplicaci贸n con sus componentes dependientes. Los ejemplos incluyen bases de datos, colas y otros servicios.
Como parte de la prueba, quer铆amos:
- ejecutar pruebas igualmente a nivel local y en jenkins
- Evite la preinstalaci贸n y configuraci贸n de aplicaciones dependientes
- declarar y ejecutar dependencias usando archivos en el repositorio del proyecto
- ser capaz de ejecutar m煤ltiples ensamblajes en paralelo
- es aconsejable poder agregar nuevas dependencias en el futuro
- Es recomendable poder probar con diferentes versiones de la misma dependencia
Con base en estos requisitos, de inmediato descartamos la idea de tener instalaciones comunes permanentes de bases de datos de prueba y colas debido a problemas con el intercambio de recursos entre ensamblados y la dificultad de mantener y cambiar esta infraestructura.
Opci贸n 1: soluciones integradas
Hay bastantes bibliotecas en el ecosistema de Java que ejecutan una dependencia para una prueba:
Este enfoque es lo m谩s simple posible y satisface la mayor铆a de los requisitos descritos anteriormente, pero no es universal en t茅rminos de agregar nuevas dependencias de prueba (mysql?) O usar versiones espec铆ficas o muchas de dependencias.
Muy adecuado para servicios simples con 1-2 dependencias.
Opci贸n 2: contenedores de prueba
Docker es una forma l贸gica de resolver las deficiencias del enfoque anterior: puede encontrar (o crear una imagen de Docker) para cualquier dependencia con cualquier versi贸n. Probablemente algunas de las dependencias en producci贸n se ejecutan con las mismas im谩genes.
Si el lanzamiento local de la imagen (o varias usando docker-compose) no es un problema, entonces habr谩 dificultades en el CI ya que el ensamblaje se realiza en el contenedor. Aunque es posible ejecutar docker en docker, el creador de dind no lo recomienda . La forma preferida de solucionar este problema es reutilizar el proceso de Docker que ya se est谩 ejecutando, que a menudo se llama Docker hermano. Para hacer esto, necesita el proceso de acoplador secundario para usar /var/run/docker.sock del padre. En una publicaci贸n anterior, esto ya se usaba para publicar im谩genes acoplables con una aplicaci贸n compilada.
Se decidi贸 utilizar la biblioteca testcontainers ya que:
- proporciona una buena API de gesti贸n de dependencias
- tiene integraciones con las bases de datos y colas m谩s populares
- utiliza el enfoque de acoplamiento de hermanos cuando se ejecuta en un contenedor
- funciona igual localmente y en ci
- detiene los contenedores despu茅s del montaje
Muy adecuado para servicios m谩s complejos o para servicios con requisitos especiales de dependencia.
Gesti贸n de recursos
A continuaci贸n, debe prestar atenci贸n al consumo de recursos por parte del ensamblaje del proyecto (que puede aumentar significativamente despu茅s de agregar pruebas de integraci贸n).
Por el momento, el ensamblado no indica la cantidad requerida de memoria y recursos compartidos de la CPU, que podr铆an ser dos problemas potenciales:
- El primero son demasiados conjuntos paralelos en la misma m谩quina, lo que dar谩 como resultado un alto factor de carga. Las asambleas probablemente pasar谩n, pero pasar谩n mucho m谩s tiempo en esto.
- El segundo es OOM kill. Kubernetis puede decidir que est谩 consumiendo demasiada memoria y simplemente matar谩 los ensamblados antes de que se completen.
Puede limitar los recursos del contenedor en el hogar utilizando la construcci贸n:
resources: requests: cpu: 1 memory: 512Mi limits: cpu: 1 memory: 512Mi
Jdk9 y superior ya tienen soporte para trabajar en un contenedor (-XX: + UseContainerSupport (habilitado por defecto), funciona en combinaci贸n con -XX: InitialRAMPercentage / -XX: MaxRAMPercentage)
Un ejemplo completo se puede encontrar aqu铆 .
Para que Jdk8 funcione correctamente, se requiere la actualizaci贸n 131 o superior con -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap para leer la memoria disponible desde cgroup y no desde la m谩quina host, o cada vez especifique el tama帽o de cadera disponible manualmente usando Xmx .
Un ejemplo est谩 disponible aqu铆 .
Vale la pena se帽alar que kubernetes no sabe nada sobre los recursos gastados en contenedores que se ejecutan utilizando testcontainers o sibling-docker. Para funcionar correctamente en esta situaci贸n, puede reservar recursos en el contenedor Maven, teniendo en cuenta todas las dependencias de prueba.
Conclusi贸n
Las pruebas de integraci贸n al iniciar una compilaci贸n en un contenedor son posibles y no una tarea dif铆cil.
Aqu铆 puede encontrar una aplicaci贸n de ejemplo con pruebas de integraci贸n que utiliza contenedores de prueba y la configuraci贸n para ejecutar Jenkins en kubernetes.