Nuestras diversas herramientas de track se despliegan como imágenes de Docker.
Cada herramienta requiere un Dockerfile, que especifica cómo se construye la máquina.
Debe ubicarse en el directorio raíz de tu repositorio y debe llamarse Dockerfile.
El Dockerfile debe crear la imagen mínima necesaria para que la herramienta funcione de forma correcta y rápida.
Nuestra página de buenas prácticas tiene muchos consejos que te ayudarán a lograr este objetivo.
Ejecución
Tiempos de espera
El test runner recibe el 100% de la CPU con 3GB de memoria durante una ventana de 20 segundos por solución.
Después de 20 segundos, el proceso se detiene y reporta un tiempo de espera con un código de error 408.
Te recomendamos seguir nuestro documento de buenas prácticas de rendimiento para reducir la probabilidad de tiempos de espera.
Stdout/stderr
Una ejecución de herramienta puede producir un máximo de un megabyte de stdout y stderr.
Si produce más, se eliminará con un código de error 413.
El contenido de stdout y stderr de cada ejecución se almacenará en archivos.
Puedes escribir un archivo results.out en el directorio de salida, que contenga información de depuración.
En este momento, no es posible que los mantenedores vean el contenido de estos archivos.
Resultados
El archivo de resultados no puede ser mayor de 500 kilobytes (incluyendo cualquier traza de pila, etc.).
Si el archivo es más grande, la ejecución de herramienta se eliminará con un código de error 460.
Configuración
Cada solución recibe el 100% de los recursos de la máquina durante una ventana de veinte segundos.
Después de 20 segundos, el proceso se detiene y se reporta como un tiempo de espera.
Algunas herramientas requieren desviaciones (ligeras) de la configuración predeterminada.
Si es así, se configuran en el archivo tools.json del repositorio Tooling Invoker.
Red
Las herramientas se ejecutan sin acceso a internet. Hay dos configuraciones diferentes que puedes usar:
-
none. Esto desactiva el dispositivo de red dentro del contenedor.
-
internal. Esto agrega un dispositivo de red dentro del contenedor, pero la red no tiene acceso a nada externo.
Distintos lenguajes funcionan mejor o peor con distintas configuraciones (p. ej., Ruby es 2x más rápido con none. Elixir es 12x más rápido con internal.
Puedes experimentar localmente usando el flag --network cuando ejecutes tu docker. --network none se admite de forma predeterminada.
Para usar la red interna, primero ejecuta docker network create --internal internal para crear la red, luego usa --network internal cuando ejecutes el contenedor.
Memoria
Los lenguajes pueden establecer la memoria máxima que necesitan usar para ejecutar sus trabajos. Establecerla lo más baja posible significa que podemos ejecutar más trabajos en paralelo y más rápido. También significa que quienes intenten abusar de la memoria no podrán lograrlo. Distintos lenguajes necesitan usos máximos de memoria muy distintos. Se recomienda y agradece hacer un benchmark de la ejecución de un docker run para establecer la memoria máxima que usa.
La memoria debe especificarse usando el número con el sufijo b, k, m, g, para indicar bytes, kilobytes, megabytes o gigabytes.
Ejecutar Docker localmente
Puedes probar la configuración anterior con este comando:
docker container run -v /path/to/job:/mnt/exercism-iteration --network none -m 1GB exercism/ruby-test-runner lasagna /mnt/exercism-iteration/ /mnt/exercism-iteration/
Editar un Dockerfile
Todos los cambios en los Dockerfiles requieren una revisión de PR del equipo @exercism/maintainers-admin, para evitar la introducción de exploits de seguridad.
