Sistemas de compilación basados en artefactos

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

Esta página abarca los sistemas de compilación basados en artefactos y la filosofía detrás de sus de la creación de cuentas de servicio. Bazel es un sistema de compilación basado en artefactos. Si bien los sistemas de compilación basados en tareas son un buen paso por encima de las secuencias de comandos de compilación, les otorgan demasiado poder a los ingenieros individuales, ya que les permiten definir sus propias tareas.

Los sistemas de compilación basados en artefactos tienen una pequeña cantidad de tareas definidas por el sistema. que los ingenieros pueden configurar de forma limitada. Los ingenieros siguen diciéndole al sistema qué compilar, pero el sistema de compilación determina cómo compilarlo. Al igual que con los sistemas de compilación basados en tareas, los sistemas de compilación basados en artefactos, como Bazel, aún tienen archivos de compilación, pero el contenido de esos archivos es muy diferente. Antes que que ser un conjunto imperativo de comandos en un lenguaje de programación completo de Turing. que describen cómo producir un resultado, los archivos de compilación en Bazel son una herramienta manifiesto que describe un conjunto de artefactos para compilar, sus dependencias y un un conjunto limitado de opciones que afectan la forma en que se crean. Cuando los ingenieros ejecutan bazel en la línea de comandos, especifican un conjunto de destinos para compilar (el qué) y Bazel es responsable de configurar, ejecutar y programar la compilación. pasos (el cómo). Debido a que el sistema de compilación ahora tiene control total sobre qué herramientas ejecutar y cuándo, puede ofrecer garantías mucho más sólidas que le permiten ser mucho más eficiente y, al mismo tiempo, garantizar la exactitud.

Una perspectiva funcional

Es fácil crear una analogía entre los sistemas de compilación basados en artefactos y los sistemas programación. Los lenguajes de programación imperativos tradicionales (como Java, C y Python) especifican listas de sentencias que se ejecutarán una tras otra, en el de la misma manera que los sistemas de compilación basados en tareas permiten a los programadores definir una serie de pasos ejecutar. Los lenguajes de programación funcionales (como Haskell y ML) en contrastan, se estructuran más como una serie de ecuaciones matemáticas. En lenguajes funcionales, el programador describe un cálculo a realizar, pero deja al equipo la información sobre cuándo y cómo se ejecuta ese cálculo compilador.

Esto se relaciona con la idea de declarar un manifiesto en un sistema de compilación basado en artefactos. y dejar que el sistema descubra la manera de ejecutar la compilación. Muchos problemas no pueden expresarse fácilmente mediante la programación funcional, pero los que sí se benefician en gran medida a partir de él: el lenguaje a menudo es capaz de paralelizar trivialmente ese tipo de programas y garantizar sólidas garantías sobre su precisión que serían imposibles en un lenguaje imperativo. Los problemas más fáciles de expresar mediante la programación funcional son las que simplemente implican transformar una pieza de datos en otro mediante una serie de reglas o funciones. Eso es exactamente Qué es un sistema de compilación: todo el sistema es efectivamente una función matemática. que toma archivos de origen (y herramientas como el compilador) como entradas y produce binarios como salidas. Por lo tanto, no es de extrañar que funcione bien basar un sistema de compilación en los principios de la programación funcional.

Información sobre los sistemas de compilación basados en artefactos

El sistema de compilación de Google, Blaze, fue el primer sistema de compilación basado en artefactos. Bazel es la versión de código abierto de Blaze.

Este es el aspecto de un archivo de compilación (normalmente llamado BUILD) en Bazel:

java_binary(
    name = "MyBinary",
    srcs = ["MyBinary.java"],
    deps = [
        ":mylib",
    ],
)
java_library(
    name = "mylib",
    srcs = ["MyLibrary.java", "MyHelper.java"],
    visibility = ["//java/com/example/myproduct:__subpackages__"],
    deps = [
        "//java/com/example/common",
        "//java/com/example/myproduct/otherlib",
    ],
)

En Bazel, los archivos BUILD definen destinos, los dos tipos de destinos aquí son java_binary y java_library. Cada destino corresponde a un artefacto que el sistema puede crear: los objetivos binarios producen objetos binarios que pueden se ejecutan directamente, y los destinos de las bibliotecas producen bibliotecas binarios u otras bibliotecas. Cada objetivo tiene lo siguiente:

name: Indica cómo se hace referencia al destino en la línea de comandos y en otras destinos
srcs: Son los archivos de origen que se compilarán para crear el artefacto del destino.
deps: Otros destinos que se deben compilar antes de este destino y vincularse a él.

Las dependencias pueden estar dentro del mismo paquete (como las de MyBinary dependencia en :mylib) o en un paquete diferente en la misma jerarquía de fuentes (como la dependencia de mylib en //java/com/example/common).

Al igual que con los sistemas de compilación basados en tareas, realizas compilaciones con la herramienta de línea de comandos de Bazel. Para compilar el destino MyBinary, ejecuta bazel build :MyBinary. Después del ingresando ese comando por primera vez en un repositorio limpio, Bazel:

Analiza cada archivo BUILD en el lugar de trabajo para crear un gráfico de dependencias entre los artefactos.
Usa el gráfico para determinar las dependencias transitivas de MyBinary. que cada objetivo del que depende MyBinary y cada uno de los objetivos de los que de la que dependen los objetivos, de forma recursiva.
Compila cada una de esas dependencias, en orden. Bazel comienza por compilar cada objetivo que no tiene otras dependencias y que realiza un seguimiento de qué dependencias que aún se deben crear para cada objetivo. En cuanto todas las solicitudes de las dependencias, Bazel comenzará a compilar ese destino. Este proceso continúa hasta que se compila cada una de las dependencias transitivas de MyBinary.
Compila MyBinary para producir un ejecutable binario final que vincula todas las dependencias que se compilaron en el paso 3.

En esencia, puede parecer que lo que sucede aquí no es muy diferente de lo que sucedía cuando se usaba un sistema de compilación basado en tareas. De hecho, resultado final es el mismo objeto binario, y el proceso para producirlo involucró analizar varios pasos para encontrar dependencias entre ellos y, luego, ejecutar los pasos en orden. Sin embargo, existen diferencias fundamentales. El primero aparece paso 3: como Bazel sabe que cada destino solo produce una biblioteca de Java, sabe que lo único que tiene que hacer es ejecutar el compilador de Java en lugar de una ejecución definida por el usuario, de modo que sepa que es seguro ejecutar estos pasos en paralelo. Esto puede producir una mejora de rendimiento de orden de magnitud en comparación con la compilación de objetivos uno a la vez en una máquina multinúcleo, y solo es posible porque el enfoque basado en artefactos deja al sistema de compilación a cargo de su propia estrategia de ejecución para que pueda ofrecer garantías más sólidas sobre el paralelismo.

Sin embargo, los beneficios se extienden más allá del paralelismo. Otra cosa que este Este enfoque se vuelve evidente cuando el desarrollador escribe bazel build :MyBinary por segunda vez sin hacer ningún cambio: Bazel sale en menos. de un segundo con un mensaje que dice que el destino está actualizado. Este es gracias al paradigma de programación funcional del que hablamos, antes: Bazel sabe que cada destino es el resultado únicamente de la ejecución de un compilador y sabe que el resultado del compilador de Java solo depende de sus entradas, de modo que las salidas se puedan volver a usar, siempre y cuando estas no hayan cambiado. Y este análisis funciona en todos los niveles; Si MyBinary.java cambia, Bazel sabrá para recompilar MyBinary, pero reutilizar mylib. Si cambia un archivo fuente para //java/com/example/common, Bazel sabe que debe volver a compilar esa biblioteca, mylib y MyBinary, pero reutiliza //java/com/example/myproduct/otherlib. Debido a que Bazel conoce las propiedades de las herramientas que ejecuta en cada paso, puede reconstruir solo el conjunto mínimo de artefactos cada vez, mientras lo que garantiza que no producirá compilaciones inactivas.

Reformular el proceso de compilación en términos de artefactos en lugar de tareas es sutil. pero poderosa. Al reducir la flexibilidad expuesta al programador, la creación puede saber más sobre lo que se hace en cada paso de la compilación. Puede usar estos conocimientos para que la compilación sea mucho más eficiente mediante la paralelización de la compilación procesos y reutilizar sus resultados. Pero en realidad este es solo el primer paso, y estos componentes básicos de paralelismo y reutilización son la base de un entorno altamente escalable y eficiente.

Otros trucos útiles de Bazel

Los sistemas de compilación basados en artefactos resuelven, en esencia, los problemas de paralelismo y reutilización que son inherentes a los sistemas de compilación basados en tareas. Pero todavía hay un algunos problemas que surgieron antes y que no hemos abordado. Bazel es inteligente de resolver cada una de ellas y deberíamos analizarlas antes de continuar.

Herramientas como dependencias

Un problema con el que nos encontramos antes fue que las compilaciones dependían de las herramientas instaladas en nuestra máquina, y podría ser difícil reproducir las compilaciones en todos los sistemas debido a en diferentes versiones o ubicaciones de las herramientas. El problema se vuelve aún más difícil cuando en tu proyecto se usan lenguajes que requieren herramientas distintas plataforma para la que se compilan o compilan (por ejemplo, Windows versus Linux), y cada una de esas plataformas requiere un conjunto de herramientas un poco diferente mismo trabajo.

Para resolver la primera parte de este problema, Bazel trata a las herramientas como dependencias para para cada objetivo. Cada java_library del espacio de trabajo depende implícitamente de un archivo que usa un compilador conocido de forma predeterminada. Cada vez que Bazel crea un java_library, comprueba que el compilador especificado esté disponible. en una ubicación conocida. Al igual que cualquier otra dependencia, si cambia el compilador de Java, se vuelve a compilar cada artefacto que depende de él.

Bazel resuelve la segunda parte del problema, la independencia de la plataforma, configurando parámetros de configuración de compilación. En lugar de que los objetivos dependan directamente de sus herramientas, dependen de los tipos de configuraciones:

Configuración del host: herramientas de compilación que se ejecutan durante la compilación
Configuración de destino: compila el objeto binario que solicitaste

Cómo extender el sistema de compilación

Bazel incluye objetivos para varios lenguajes de programación populares. pero los ingenieros siempre querrán hacer más, como parte del beneficio de los modelos es su flexibilidad para admitir cualquier tipo de proceso de compilación. sería mejor no renunciar a eso en un sistema de compilación basado en artefactos. Afortunadamente, Bazel permite que sus tipos de destinos admitidos se extiendan agregar reglas personalizadas.

Para definir una regla en Bazel, el autor de la regla declara las entradas que requiere (en forma de atributos pasados en el archivo BUILD) y el conjunto fijo de resultados que produce la regla. El autor también define las acciones que generará esa regla. Cada acción declara sus entradas y salidas, ejecuta un ejecutable en particular o escribe una cadena en un archivo, y se puede conectar a otras acciones a través de sus entradas y salidas. Esto significa que las acciones son la unidad componible de nivel más bajo en el sistema de compilación: una acción puede hacer lo que quiera, siempre y cuando use solo sus entradas y salidas declaradas, y Bazel se encarga de programar acciones y almacenar en caché sus resultados según corresponda.

El sistema no es infalible, ya que no hay forma de detener a un desarrollador de acciones. de hacer algo como introducir un proceso no determinista como parte de su acción. Sin embargo, esto no ocurre muy a menudo en la práctica, y se está impulsando las posibilidades de abuso, hasta el nivel de acción, disminuyen en gran medida oportunidades de errores. Las reglas que admiten muchos lenguajes y herramientas comunes son ampliamente disponibles en línea, y la mayoría de los proyectos nunca tendrán que definir su las reglas de firewall. Incluso para aquellos que sí lo hacen, las definiciones de reglas solo deben definirse en un lugar central del repositorio, lo que significa que la mayoría de los ingenieros podrán usar esas reglas sin tener que preocuparse por su implementación.

Cómo aislar el entorno

Parece que las acciones podrían tener los mismos problemas que las tareas en otros sistemas. ¿No es posible escribir acciones que escriban en el mismo archivo y que terminen en conflicto entre sí? En realidad, Bazel hace estas conflictos imposibles con la zona de pruebas En los sistemas compatibles, cada acción está aislada de todas las demás a través de una zona de pruebas del sistema de archivos. Efectivamente, cada acción solo puede ver una vista restringida del sistema de archivos que incluye las entradas que declaró y los resultados que produjo. Esto se aplica mediante sistemas como LXC en Linux, la misma tecnología que se usa en Docker. Esto significa que es imposible que las acciones entren en conflicto entre sí porque no pueden leer ningún archivo que no declaren, y los archivos que escriban, pero no declaren, se descartarán cuando finalice la acción. Bazel también usa zonas de pruebas para impedir que las acciones se comuniquen a través de la red.

Cómo hacer que las dependencias externas sean deterministas

Todavía queda un problema: los sistemas de compilación a menudo necesitan descargar dependencias (ya sean herramientas o bibliotecas) de fuentes externas en lugar de compilarlos directamente. Esto se puede ver en el ejemplo a través de la dependencia @com_google_common_guava_guava//jar, que descarga un archivo JAR de Maven.

El uso de archivos fuera del espacio de trabajo actual es riesgoso. Esos archivos podrían cambian en cualquier momento, lo que podría requerir que el sistema de compilación verifique constantemente si están actualizados. Si un archivo remoto cambia sin un cambio correspondiente en el código fuente del espacio de trabajo, también puede generar compilaciones irreproducibles. Una compilación puede funcionar un día y fallar al siguiente sin motivo aparente debido a un cambio de dependencia desapercibido. Por último, una dependencia externa puede introducir una gran seguridad cuando es propiedad de un tercero: si un atacante puede infiltrarse en ese servidor de terceros, pueden reemplazar el archivo de dependencia con algo como su propio diseño, lo que le da el control total de tu compilación entorno y su resultado.

El problema fundamental es que queremos que el sistema de compilación archivos sin tener que incluirlos en el control de código fuente. La actualización de una dependencia debe ser una elección consciente, pero esa elección debe realizarse una vez en un lugar central en lugar de que la administren ingenieros individuales o el sistema automáticamente. Esto se debe a que, incluso con un modelo "Live at Head", queremos que las compilaciones sean deterministas, lo que implica que, si revisas una confirmación de la semana pasada, deberías ver tus dependencias como estaban en ese momento, en lugar de como están ahora.

Bazel y algunos otros sistemas de compilación abordan este problema requiriendo un archivo de manifiesto para todo el lugar de trabajo que enumere un hash criptográfico para cada dependencia externa en el lugar de trabajo. El hash es una forma concisa de representar el archivo de forma única sin verificarlo en el control de código fuente. Cada vez que se hace referencia a una dependencia externa nueva desde un lugar de trabajo, el hash de esa dependencia se agrega al manifiesto, ya sea de forma manual o automática. Cuando Bazel ejecuta una compilación, verifica el hash real de su dependencia almacenada en caché en comparación con el hash esperado definido en el manifiesto y vuelve a descargar el archivo solo si el hash difiere.

Si el artefacto que descargamos tiene un hash diferente del declarado en el manifiesto, la compilación fallará, a menos que se actualice el hash en el manifiesto. Esto se puede hacer automáticamente, pero ese cambio debe aprobarse y registrarse en el control de código fuente antes de que la compilación acepte la nueva dependencia. Esto significa que siempre hay un registro de cuándo se actualizó una dependencia, y una dependencia externa no puede cambiar sin un cambio correspondiente en la fuente del espacio de trabajo. También significa que, cuando se obtiene una versión anterior del código fuente, se garantiza que la compilación use las mismas dependencias que usaba en el momento en que se revisó esa versión (de lo contrario, fallará si esas dependencias ya no están disponibles).

Por supuesto, puede ser un problema si un servidor remoto deja de estar disponible o comienza a entregar datos dañados, lo que puede provocar que todas tus compilaciones comiencen a fallar si no tienes otra copia de esa dependencia disponible. Para evitar esto, recomendamos que, para cualquier proyecto no trivial, dupliques todos sus dependencias en servidores o servicios confiables y controlados. De lo contrario, siempre estará a merced de un tercero por la seguridad del sistema de acceso, incluso si los hashes registrados garantizan su seguridad.