Zona de pruebas

Informar un problema . Ver fuente . . Por la noche · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

En este artículo, se describe la zona de pruebas en Bazel y cómo depurar tu zona de pruebas en un entorno de nube.

La zona de pruebas es una estrategia de restricción de permisos que aísla los procesos de entre sí o de recursos en un sistema. Para Bazel, esto significa restringir el acceso a archivos acceso al sistema.

La zona de pruebas del sistema de archivos de Bazel ejecuta procesos en un directorio de trabajo que solo contiene entradas conocidas, de modo que los compiladores y otras herramientas no vean el código fuente archivos a los que no deben acceder, a menos que conozcan la ruta de acceso absoluta a ellos.

La zona de pruebas no oculta el entorno de host de ninguna manera. Los procesos pueden acceder a todos los archivos en el sistema. Sin embargo, en las plataformas que admiten espacios de nombres, los procesos no pueden modificar ningún archivo fuera de su directorio de trabajo. Esto garantiza que el gráfico de compilación no tenga dependencias ocultas que podrían afectan la reproducibilidad de la compilación.

Más específicamente, Bazel construye un directorio execroot/ para cada acción. que actúa como directorio de trabajo de la acción al momento de la ejecución. execroot/ contiene todos los archivos de entrada a la acción y sirve como contenedor de cualquier en los resultados generados. Luego, Bazel usa una técnica proporcionada por el sistema operativo contenedores en Linux y sandbox-exec en macOS, para restringir la acción dentro execroot/

Motivos para usar la zona de pruebas

  • Sin la zona de pruebas de acciones, Bazel no sabe si una herramienta usa elementos no declarados. archivos de entrada (archivos que no se enumeran explícitamente en las dependencias de un acción). Cuando uno de los archivos de entrada no declarados cambia, Bazel sigue cree que la compilación está actualizada y no volverá a crear la acción. Esto puede den como resultado una compilación incremental incorrecta.

  • La reutilización incorrecta de entradas de caché crea problemas durante el almacenamiento en caché remoto. R una entrada de caché deficiente en una caché compartida afecta a todos los desarrolladores del proyecto y borrar toda la caché remota no es una solución viable.

  • La zona de pruebas imita el comportamiento de la ejecución remota (si una compilación funciona bien) con la zona de pruebas, es probable que también funcione con la ejecución remota. Al hacer ejecución remota sube todos los archivos necesarios (incluidas las herramientas locales), puedes a reducir de forma significativa los costos de mantenimiento de los clústeres de compilación tener que instalar las herramientas en cada máquina del clúster cada vez que si quieres probar un compilador nuevo o hacer un cambio en una herramienta existente.

Qué estrategia de zona de pruebas usar

Puedes elegir qué tipo de zona de pruebas usar, si corresponde, con el marcas de estrategia Usa sandboxed hace que Bazel elija una de las implementaciones de la zona de pruebas que se enumeran a continuación. preferir una zona de pruebas específica para el SO en lugar de la genérica menos hermética. Si pasas, los trabajadores persistentes se ejecutarán en una zona de pruebas genérica. la marca --worker_sandboxing.

La estrategia local (también conocida como standalone) no realiza ningún tipo de zona de pruebas. Simplemente ejecuta la línea de comandos de la acción con el directorio de trabajo configurado en el execroot de tu espacio de trabajo.

processwrapper-sandbox es una estrategia de zona de pruebas que no requiere ninguna “avanzado” debería funcionar en cualquier sistema POSIX listo para usar. Integra Compila un directorio de zona de pruebas compuesto por symlinks que apuntan a la versión original. archivos de origen, ejecuta la línea de comandos de la acción con el conjunto de directorios de trabajo a este directorio en lugar de execroot y, luego, traslada los artefactos de salida conocidos fuera de la zona de pruebas en execroot y borra la zona de pruebas. Esto evita que las acción de usar accidentalmente cualquier archivo de entrada no declarado y de desperdiciar el execroot con archivos de salida desconocidos.

linux-sandbox va un paso más allá y se basa en lo siguiente: processwrapper-sandbox De manera similar a lo que hace Docker, usa Espacios de nombres de Linux (espacios de nombres de usuario, activación, PID, IPC y red) para aislar el acción del host. Es decir, hace que todo el sistema de archivos sea de solo lectura, excepto para el directorio de la zona de pruebas, de modo que la acción no pueda modificar accidentalmente nada en el sistema de archivos del host. Esto evita situaciones como una prueba con errores y accidentalmente -rf a tu directorio $HOME. Si lo deseas, también puedes evitar que la acción antes de acceder a la red. linux-sandbox usa espacios de nombres PID para evitar la acción. de ver otros procesos y eliminarlos de forma confiable (incluso daemons generados por la acción) al final.

darwin-sandbox es similar, pero para macOS. Usa la herramienta sandbox-exec de Apple para lograr casi lo mismo que la zona de pruebas de Linux.

linux-sandbox y darwin-sandbox no funcionan en un entorno "anidado" debido a restricciones en los mecanismos que proporciona el sistema operativo, de la seguridad de la información. Debido a que Docker también usa espacios de nombres de Linux para el comando mágico de contenedor, no puede ejecutar linux-sandbox con facilidad dentro de un contenedor de Docker, a menos que uses docker run --privileged En macOS, no puedes ejecutar sandbox-exec dentro de un que ya está en zona de pruebas. Por eso, en estos casos, Bazel recurre automáticamente a processwrapper-sandbox.

Si prefieres recibir un error de compilación (por ejemplo, no crear accidentalmente con un estrategia de ejecución menos estricta: modificar explícitamente la lista de ejecuciones estrategias que Bazel intenta usar (por ejemplo, bazel build --spawn_strategy=worker,linux-sandbox)

Por lo general, la ejecución dinámica requiere una zona de pruebas para la ejecución local. Para inhabilitar esta opción, haz lo siguiente: pasa la marca --experimental_local_lockfree_output. Ejecución dinámica silenciosa trabajadores persistentes de zonas de pruebas.

Desventajas de la zona de pruebas

  • Las zonas de pruebas generan costos de configuración y desmontaje adicionales. Qué tan alto es este costo depende de muchos factores, incluida la forma de la construcción y el el rendimiento del SO del host. Para Linux, las compilaciones en zonas de pruebas rara vez son más que un poco más lenta. La configuración de --reuse_sandbox_directories puede mitigar los costos de configuración y desmontaje.

  • Las zonas de pruebas inhabilitan de manera eficaz cualquier caché que pueda tener la herramienta. Puedes mitigar esto con trabajadores persistentes, al el costo de garantías más débiles en la zona de pruebas.

  • Los trabajadores multiplex requieren compatibilidad explícita con trabajadores en una zona de pruebas. Los trabajadores que no admiten zonas de pruebas multiplex se ejecutan como Trabajadores de un soloplex en ejecución dinámica, lo que puede costar memoria adicional

Depuración

Sigue las estrategias que se indican a continuación para depurar problemas con la zona de pruebas.

Espacios de nombres desactivados

En algunas plataformas, como Google Kubernetes Engine los nodos del clúster o Debian, los espacios de nombres del usuario se desactivan de forma predeterminada debido a seguridad en la nube. Si el archivo /proc/sys/kernel/unprivileged_userns_clone existe y contiene un 0, puedes activar los espacios de nombres de usuario ejecutando el siguiente comando:

   sudo sysctl kernel.unprivileged_userns_clone=1

Fallas de ejecución de reglas

Es posible que la zona de pruebas no ejecute reglas debido a la configuración del sistema. Si ves un mensaje mensaje como namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory, intenta desactivar la zona de pruebas con --strategy=Genrule=local por genrules y --spawn_strategy=local para otras reglas.

Depuración detallada de errores de compilación

Si tu compilación falló, usa --verbose_failures y --sandbox_debug para hacer Bazel muestra el comando exacto que ejecutó cuando falló la compilación, incluida la parte. que configura la zona de pruebas.

Ejemplo de mensaje de error:

ERROR: path/to/your/project/BUILD:1:1: compilation of rule
'//path/to/your/project:all' failed:

Sandboxed execution failed, which may be legitimate (such as a compiler error),
or due to missing dependencies. To enter the sandbox environment for easier
debugging, run the following command in parentheses. On command failure, a bash
shell running inside the sandbox will then automatically be spawned

namespace-sandbox failed: error executing command
  (cd /some/path && \
  exec env - \
    LANG=en_US \
    PATH=/some/path/bin:/bin:/usr/bin \
    PYTHONPATH=/usr/local/some/path \
  /some/path/namespace-sandbox @/sandbox/root/path/this-sandbox-name.params --
  /some/path/to/your/some-compiler --some-params some-target)

Ahora puedes inspeccionar el directorio de la zona de pruebas generado y ver qué archivos Bazel creaste y vuelves a ejecutar el comando para ver cómo se comporta.

Ten en cuenta que Bazel no borra el directorio de la zona de pruebas cuando lo usas --sandbox_debug A menos que estés depurando activamente, debes inhabilitar --sandbox_debug porque llena el disco con el tiempo.