¿Debo incluir pruebas en la imagen de Docker?

7

Cuando se trata de pruebas, puedo pensar en dos opciones:

  1. Coloque la prueba y la aplicación en una imagen.
  2. Incluir solo el código de la aplicación en la imagen. Cree un contenedor específico de prueba que se genere después de la imagen principal y le agregue algunas capas (código de prueba, dependencias, etc.).

Con la primera opción, puedo probar el contenedor y enviarlo exactamente como se probó. Un inconveniente obvio es que se incluirá un código innecesario (y potencialmente datos de prueba) en la imagen.

Con la segunda opción, la imagen que se envía no es exactamente la misma que se probó.

Ambas parecen malas estrategias. ¿Hay una tercera, mejor estrategia?

    
pregunta lfk 24.01.2018 - 03:19

2 respuestas

6

Hay una tercera forma, como dijiste. Creo que estás mezclando desarrollo, pruebas y despliegue. Propongo que todo el SDLC se considere como un todo, primero, para comprender qué es lo que está tratando de lograr. Este es un gran tema, pero haré mi mejor esfuerzo para resumir.

TL; DR;

En resumen, necesitas separar:

  • su código, desde
  • la configuración de la aplicación, desde
  • la configuración del entorno del sistema.

Cada uno debe ser independiente el uno del otro y de manera adecuada:

  • versión controlada
  • probado
  • desplegable

Versión más larga

Primero, tiene una aplicación compuesta de código y (conjuntos separados de) configuración. Esto debe probarse, tanto para la compilación como para la función intencional, lo que se denomina integración continua (IC). Hay muchos proveedores de este servicio tanto en línea como a nivel local, por ejemplo, CircleCI para un proveedor en la nube que se enlaza a su repositorio y crea y prueba cada vez que realiza una confirmación. Si su repositorio es local y no puede usar un proveedor en la nube, algo como Jenkins sería un equivalente. Si su aplicación es bastante estándar, es probable que haya una imagen de Docker existente que el servicio de CI pueda usar. Si no, tendrá que crear uno, o un grupo de ellos, para que se pueda implementar su código de aplicación y su configuración. Configurado correctamente, tendrá una gran cantidad de estadísticas sobre la calidad del código de su aplicación.

A continuación, una vez que esté satisfecho con la funcionalidad y la corrección de su aplicación, el código base debe estar adecuadamente etiquetado para una versión específica. Esta compilación debería implementarse en un entorno de prueba. Tenga en cuenta que el código será el mismo que se probó en su CI (probablemente, si lo ha hecho correctamente), pero su configuración puede diferir. Nuevamente, algunos proveedores de CI pueden ofrecer este paso para que pueda probar su implementación de una aplicación empaquetada y una configuración discreta. Esta etapa generalmente incluirá las pruebas funcionales del usuario (para la nueva funcionalidad), así como las pruebas automatizadas (para la funcionalidad conocida). Si la versión supera esta etapa, tiene una versión candidata para las pruebas de integración. Puede ejecutar las pruebas de automatización desde otro contenedor Docker, dependiendo de su aplicación, pueden ser tan grandes y elaboradas como su propia aplicación; de hecho, hay algunas métricas que indican que el esfuerzo de prueba es 1: 1 al esfuerzo de codificación (aunque yo mismo no estoy seguro de esto).

Sin embargo, el siguiente paso es construir el entorno (del sistema) como si fuera producción. Si está utilizando Docker en producción, aquí es donde pensará en el fortalecimiento de la seguridad, la red y la optimización del servidor, etc. Sus imágenes de Docker pueden basarse en las que usó en Desarrollo (idealmente), pero puede haber cambios en la escala y la seguridad. , como ya he dicho. En este momento, la prueba funcional de la aplicación debe estar completa, usted está más preocupado por la seguridad y el rendimiento. Según las pruebas funcionales, sus pruebas aquí se pueden desarrollar, implementar y ejecutar desde otras imágenes de Docker. Este paso solía ser terriblemente caro y rara vez se hacía para hacerlo, por lo que necesitaba un hardware dedicado en el lugar que reproducía la producción. Hoy en día, esto es completamente viable, ya que puede levantarse y demoler todo el entorno de casi cualquier escala a pedido.

Finalmente, tiene una versión que debería estar lista para la producción con solo un pequeño conjunto de deltas de configuración de la de las pruebas de integración (direcciones IP, URI de bases de datos, contraseñas, etc.) Su código base ha sido probado al menos en tres Los entornos en este punto y la mayoría de la configuración del sistema al menos una vez.

    
respondido por el avastmick 25.01.2018 - 05:35
4

Para ejecutar pruebas de tiempo de compilación, la forma preferida sería utilizar un varias etapas construir . Los Dockerfiles de múltiples etapas le permiten tener una etapa más grande con todas las dependencias para construir y probar, luego copiar los artefactos exactos que probó en otra etapa para obtener una imagen de tiempo de ejecución más pequeña.

También desea pruebas a nivel de sistema de múltiples contenedores, utilizando sus interfaces externas en lugar de ejecutarse dentro del contenedor. Dado que esas pruebas implican coordinación entre los servicios, requieren diferentes dependencias, como el acceso a su orquestación, no son tan completas como las pruebas de tiempo de compilación y, a menudo, están escritas en idiomas completamente diferentes, no es un gran problema ejecutarlas desde un Docker separado. contenedor dedicado solo a la prueba del sistema.

    
respondido por el Karl Bielefeldt 24.01.2018 - 19:56

Lea otras preguntas en las etiquetas