Archivo Command

¿Qué es un archivo?

Cuando la complejidad de una prueba en k6 va más allá de un solo archivo JS (Java Script), rápidamente se vuelve engorroso encontrar y agrupar todas las dependencias (JS, archivos de datos open()'ed, certificados de clientes TLS, etc.). Los archivos en k6 son una forma nativa de agrupar y distribuir, o compartir, una prueba.

Un archivo en k6 es simplemente un archivo tar con todos los archivos necesarios para ejecutar una prueba k6.

Cómo crear y ejecutar un archivo

Supongamos que normalmente ejecutamos una prueba utilizando:

1$ k6 run script.js

Ahora bien, si sustituye k6 run por k6 archive, k6 ejecutará la fase de inicio del código para determinar qué archivos JS se están importando y qué archivos de datos se están open() y agrupa todos los archivos en un archivo tar:

1$ k6 archive script.js

Esto crea un archivo tar en el disco llamado archive.tar (puede cambiar el nombre usando el comando -O filename.tar). También es fácil ejecutar un archivo, ya que k6 run es compatible con los archivos comprimidos que puede ejecutar:

⚠️ Anulación de opciones

Como siempre, puedes anular las opciones utilizando banderas de la CLI o variables de entorno al ejecutar un archivo.

1$ k6 run archive.tar

Casos de uso

Los archivos tienen una gran variedad de usos, pero todos comparten la necesidad de agrupar los archivos de una prueba en un único archivo para facilitar su distribución.

Compartir una prueba

Al agrupar una prueba en un archivo, es fácil compartir la prueba con tus compañeros de equipo, simplemente almacenando o enviando un único archivo tar. Como vimos en la sección anterior, sus compañeros de equipo pueden ejecutar el archivo ejecutando k6 run archive.tar.

Preparación de pruebas para CI

Si tienes un complejo CI pipeline y tus pruebas de carga están separadas del código de tu aplicación, podrías almacenar archivos k6 como artefactos de construcción cada vez que el código fuente de la prueba de carga se modifique, y luego tirar de esos archivos k6 desde el almacenamiento de artefactos para la ejecución de la prueba cuando sea necesario.

Ejecución en k6 Cloud

k6 ofrece un servicio comercial para ejecutar pruebas de carga a gran escala y distribuidas geográficamente en una infraestructura gestionada en la nube. Las pruebas ejecutadas en k6 Cloud se desencadenan desde la línea de comandos de k6 a través del comando k6 cloud script.js (similar a k6 run) que desencadenará una creación implícita de un archivo k6 que se carga y distribuye a los generadores de k6 Cloud para su ejecución.

Ejecución en clúster (futuro)

En el futuro (véase nuestro Roadmap) k6 soportará un modo de ejecución en clúster que permitirá la ejecución de pruebas en más de un nodo. Este modo de ejecución también es probable que haga uso de la funcionalidad de archivo para distribuir los archivos de prueba a todos los nodos participantes.

Contenido de un fichero de archivo

Un archivo contiene la fuente original del código JS, cualquier archivo de datos open()'ed, certificados de cliente SSL/TLS así como un metadata.json con todas las opciones (una cascada de las opciones establecidas en el CLI, a través de variables de entorno y opciones in-script (export let options = {...})).

Vamos a crear un archivo de la siguiente prueba de ejemplo. Aquí está la disposición en el sistema de archivos de los archivos:

1/home/johndoe/tests/api-test $ tree
2.
3├── utils
4|   └-- common.js
5├── endpoints
6|   ├── login.js
7|   └-- search.js
8├── node_modules
9|   └-- somelib
10|       └-- lib.js
11├── data
12|   └-- users.json
13└-- script.js

Ahora, si el directorio de trabajo actual es /home/johndoe/tests/api-test/ y ejecutamos k6 archive script.js obtendremos un archivo tar llamado archive.tar (puedes cambiar el nombre del archivo usando -O filename.tar). El contenido del fichero de archivo tendría un aspecto similar al siguiente:

1├-- data
2├-- files
3|   └-- home
4|       └-- nobody <-- the username has been anonymized (see section further down)
5|           └-- tests
6|               └-- api-test
7|                   └-- data
8|                       └-- users.json
9├-- metadata.json
10└-- scripts
11    └-- home
12        └-- nobody <-- the username has been anonymized (see section further down)
13            └-- tests
14                └-- api-test
15                    ├-- script.js
16                    ├-- utils
17                    |   └-- common.js
18                    ├-- endpoints
19                    |   ├-- login.js
20                    |   └-- search.js
21                    └-- node_modules
22                        └-- somelib
23                            └-- lib.js

Desglosando la estructura del archivo obtenemos

data contiene el código fuente del archivo JS principal (script.js en este ejemplo).

files contiene el árbol de directorios original completo de todos los archivos de datos open()'ed.

metadata.json Las opciones "por defecto" resueltas para esta prueba basadas en banderas CLI, variables de entorno y opciones in-script.

scripts contiene el árbol de directorios original completo de todas las dependencias JS importadas.

1{
2  "type": "js",
3  "options": {
4    "paused": null,
5    "vus": null,
6    "vusMax": null,
7    "duration": null,
8    "iterations": null,
9    "stages": null,
10    "setupTimeout": null,
11    "teardownTimeout": null,
12    "rps": null,
13    "maxRedirects": null,
14    "userAgent": null,
15    "batch": null,
16    "batchPerHost": null,
17    "httpDebug": null,
18    "insecureSkipTLSVerify": null,
19    "tlsCipherSuites": null,
20    "tlsVersion": {
21      "min": "",
22      "max": ""
23    },
24    "tlsAuth": null,
25    "throw": null,
26    "thresholds": null,
27    "blacklistIPs": null,
28    "hosts": null,
29    "noConnectionReuse": null,
30    "ext": null,
31    "summaryTrendStats": null,
32    "systemTags": [
33      "url",
34      "name",
35      "check",
36      "error",
37      "tls_version",
38      "method",
39      "subproto",
40      "status",
41      "group",
42      "proto"
43    ],
44    "tags": null
45  },
46  "filename": "/home/johndoe/tests/api-test/script.js",
47  "pwd": "/home/johndoe/tests/api-test/",
48  "env": {}
49}

Lo que no contiene un fichero de archive

Intentamos ser cautelosos con lo que incluimos en un fichero de archivo. Algunas cosas que hacemos con ese fin:

• Anonimizar el nombre de usuario que se encuentra en cualquier ruta de acceso a las dependencias de archivos JS y de datos.
• No incluimos variables de entorno del sistema en el archivo.