BuildKit: a xoia oculta de Docker que pode construír case calquera cousa

A maioría dos desenvolvedores coñecen a Docker como o tempo de execución do contedor que cambiou a forma en que se envía o software. Moitos menos saben sobre o motor que zumba silenciosamente baixo a superficie de cada versión moderna de Docker: BuildKit, o sistema de compilación de próxima xeración que se envía con Docker desde a versión 18.09 e converteuse no backend predeterminado en Docker 23.0. Mentres os enxeñeiros discuten sen parar sobre as configuracións de Kubernetes e os patróns de microservizos, BuildKit foi evolucionando constantemente nun dos sistemas de construción máis poderosos e flexibles do ecosistema DevOps. Se o trataches só como unha construción docker máis rápida, estás deixando unha enorme capacidade sobre a mesa. As empresas que executan canalizacións CI/CD de alto rendemento reduciron os tempos de construción nun 50-70 % simplemente por comprender o que realmente ofrece BuildKit, e iso é só o comezo.

O que fai que BuildKit sexa fundamentalmente diferente do Classic Builder

O motor de compilación de Docker orixinal executou as instrucións de Dockerfile de forma secuencial, unha capa á vez, sen ter coñecemento de que traballo podería suceder en paralelo con seguridade. BuildKit substitúe ese modelo de execución lineal por un gráfico acíclico dirixido (DAG), un gráfico de dependencia que comprende cales pasos de construción dependen uns dos outros e cales non. As fases independentes execútanse simultáneamente, as fases non utilizadas sáltanse por completo e a compilación enteira convértese nunha descrición declarativa do que queres en lugar dunha secuencia imperativa de pasos que tes que recitar na orde correcta.

Este cambio arquitectónico ten consecuencias prácticas que van máis alá da velocidade. Cando un Dockerfile de varias etapas compila un binario de Go nunha etapa, descarga as dependencias de Node.js noutra e monta unha imaxe de produción nunha terceira, BuildKit pode executar as dúas primeiras etapas simultaneamente. Unha construción que antes levaba catro minutos a un poderoso corredor de CI agora completa en menos de noventa segundos. Stripe, Shopify e moitos outros equipos de enxeñería a gran escala documentaron beneficios similares nas súas retrospectivas internas de ferramentas. O modelo DAG tamén significa que BuildKit pode xerar metadatos de compilación moi precisos: unha base para funcións como as certificacións de procedencia e a xeración de listas de materiais de software (SBOM) que importan enormemente para a seguridade da cadea de subministración.

Tamén hai un cambio conceptual no funcionamento da invalidación da caché. O constructor clásico invalidou todas as capas debaixo de calquera instrución modificada. BuildKit rastrexa os hash de contido en cada entrada, polo que cambiar un comentario nun ficheiro Docker non elimina unha entrada de caché que representa trinta minutos de compilación. Cando a túa caché de compilación é a diferenza entre un ciclo de comentarios de cinco minutos e un de corenta minutos para o teu equipo de enxeñería, esta precisión importa moito máis do que parecería inicialmente.

Compilacións multiplataforma: un comando, cada arquitectura

A bandeira --platform de

BuildKit e a integración QEMU transforman o que antes era un doloroso problema de coordinación de varios sistemas nun único comando. Executar docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 . produce tres imaxes listas para a produción en paralelo a partir dunha única invocación de compilación. Esta capacidade volveuse fundamental a medida que o sector cambia cara a ARM: as instancias de AWS Graviton3 ofrecen un 40 % de mellor rendemento en cargas de traballo como o servizo web e o procesamento de datos, e Apple Silicon converteu ARM na máquina de desenvolvemento predeterminada para millóns de enxeñeiros.

Antes de que o soporte multiplataforma de BuildKit madurase, manter canalizacións de construción separadas para diferentes arquitecturas era un verdadeiro centro de custos. Os equipos mantiveron varios Dockerfiles, executaron canalizacións CI separadas en corredores de arquitectura diferente ou simplemente enviaron imaxes x86 a todas partes e pagaron a penalización de rendemento na infraestrutura ARM. Con BuildKit, define a súa compilación unha vez e permite que o sistema xestione a compilación específica da arquitectura de forma transparente. Proxectos Rust que requiren compilación cruzada, proxectos Go con dependencias de CGO, paquetes Python con extensións C: BuildKit xestiona a capa de emulación sen esixir que comprendas os detalles de cada plataforma de destino.

O valor comercial práctico aquí é medible. Un equipo que executa 200 contedores en instancias de AWS Graviton a 0,04 USD por hora de vCPU fronte á instancia x86 equivalente a 0,056 USD por hora de vCPU aforra aproximadamente 11.520 USD ao ano por cada 100 vCPU, só por escoller a arquitectura correcta. Facer esa opción accesible sen un esforzo de re-enxeñería é exactamente o tipo de optimización da infraestrutura que se amortiza inmediatamente.

Xestión secreta sen filtrar nas capas de imaxe

Unha das funcións de BuildKit máis subestimadas é a súa API de segredos. O creador clásico de Docker non tiña un xeito limpo de pasar credenciais a unha compilación sen que esas credenciais puidesen acabar nunha capa de imaxe. Os desenvolvedores traballaron en torno a isto con compilacións en varias etapas, instrucións ARG e ordes coidadosas, pero o risco de incorporar accidentalmente unha clave API ou unha clave SSH privada nunha imaxe enviada seguía sendo incómodo. Os escáneres de seguranza atopan habitualmente credenciais codificadas nas imaxes de contedores publicadas en rexistros públicos, e moitas desas filtracións remóntanse directamente ao manexo torpe dos segredos durante as compilacións.

A marca --secret de

BuildKit monta datos confidenciais no ambiente de compilación como un camiño temporal do sistema de ficheiros que só existe durante a instrución específica RUN que o necesite e que nunca toca ningunha capa de imaxe. Unha instrución de Dockerfile como RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install dálle ao proceso de compilación acceso ás credenciais privadas de npm sen que esas credenciais aparezan nunca na imaxe final ou na capa intermedia. O mesmo patrón funciona para as credenciais de PyPI, a configuración de Maven, as claves SSH para repositorios privados de Git e calquera outro material sensible que precise o teu proceso de compilación.

Para equipos que crean software que afecta a industrias reguladas (plataformas sanitarias, produtos fintech, software de recursos humanos), a diferenza entre "as credenciais poden estar na imaxe" e "as credenciais non poden estar na imaxe" é a diferenza entre pasar unha auditoría de seguridade e pasar tres semanas corrixindo os descubrimentos. Plataformas como Mewayz, que impulsan as operacións comerciais de máis de 138.000 usuarios en sectores como a nómina, os recursos humanos e a facturación, dependen exactamente deste tipo de postura de seguridade comprobable nas súas canalizacións de creación e implantación para manter a confianza que estes clientes estenden aos seus datos financeiros e de persoal confidenciais.

Exportacións de caché: facer que os pipelines CI sexan realmente rápidos

Os pipelines de CI son onde máis importa o rendemento da compilación e onde a experiencia de compilación predeterminada de Docker foi historicamente máis dolorosa. Os corredores de CI novos normalmente comezan con cachés baleiros, o que significa que cada execución de pipeline recompila todo desde cero. Para un servizo Java con centos de dependencias de Maven, un proxecto Rust ou unha aplicación Python con extensións nativas pesadas, isto significa que os tempos de construción se miden en decenas de minutos en lugar de segundos. O custo empresarial do CI lento é enorme: a frecuencia de implantación reducida, os bucles de retroalimentación máis longos e os enxeñeiros están inactivos esperando a que se completen as canalizacións antes de poder fusionarse e seguir adiante.

A función de exportación de caché de BuildKit resolve isto cos manifestos de caché exportables. Usando --cache-to type=registry,ref=myregistry/myapp:cache e --cache-from type=registry,ref=myregistry/myapp:cache, BuildKit envía unha instantánea detallada da caché a un rexistro despois de cada compilación e extraea ao comezo da seguinte. A caché está dirixida ao contido, polo que só se recuperan as capas realmente modificadas. Os equipos que usan este padrón en GitHub Actions, GitLab CI e CircleCI reducen habitualmente os tempos de pipeline de quince minutos a menos de tres en execucións posteriores. A propia documentación de GitHub sobre fluxos de traballo de compilación avanzados de Docker recomenda encarecidamente este patrón precisamente por este motivo.

A compilación máis rápida é a que nunca tes que executar de novo. O sistema de caché en capas de BuildKit non só acelera as compilacións, senón que fai que todo o concepto de "construción" sexa máis intelixente, convertendo unha compilación repetida nunha diferenza incremental do que cambiou exactamente.

As exportacións de caché tamén se integran de forma limpa cos fluxos de traballo de desenvolvemento baseados en ramas. Podes configurar a túa canalización de CI para que retroceda desde unha caché específica da rama á caché da rama principal cando non exista ningunha caché da rama, o que significa que as novas ramas se benefician inmediatamente da caché quente acumulada pola túa liña de desenvolvemento principal. Os enxeñeiros reciben comentarios rápidos desde o seu primeiro compromiso nunha nova sucursal en lugar de esperar unha penalización por arranque en frío.

💡 DID YOU KNOW?

Mewayz replaces 8+ business tools in one platform

CRM · Invoicing · HR · Projects · Booking · eCommerce · POS · Analytics. Free forever plan available.

Start Free →

BuildKit Frontends: construción máis aló de Dockerfiles

Quizais a capacidade menos coñecida de BuildKit é que os Dockerfiles son só un formato de entrada posible, non o único. BuildKit ten unha arquitectura frontend conectable que permite linguaxes e formatos de definición de compilación totalmente personalizados. O frontend é especificado pola directiva # syntax= na parte superior do ficheiro de compilación, que lle indica a BuildKit que tire dunha imaxe de frontend en particular e que a use para analizar e executar o resto do ficheiro.

Esta arquitectura permitiu varios proxectos atractivos. A integración de Buildpacks permítelle a BuildKit construír imaxes de contedores a partir do código fonte da aplicación sen ningún Dockerfile: detecta o idioma, escolle imaxes base adecuadas e ensambla automaticamente un contedor listo para a produción. HPC e as comunidades de computación científica utilizaron frontends personalizados para describir compilacións en linguaxes específicas de dominio que se compilan ata a representación interna de LLB (Low Level Build) de BuildKit. A interface de sintaxe docker/dockerfile:labs experimenta con funcións como soporte heredoc, control de --network por instrución e consellos de caché mellorados antes de que aterren a sintaxe estable de Dockerfile.

A capacidade de definir a súa propia frontend tamén significa que as organizacións con requisitos de compilación pouco habituais non teñen que escoller entre "calzar todo na sintaxe Dockerfile" e "abandonar os contedores por completo". Un firmware FPGA de creación de equipos, imaxes de sistemas integrados ou contenedores de modelos de ML especializados poden describir a súa construción en termos que teñan sentido para o seu dominio mentres seguen producindo imaxes de contedores estándar compatibles con OCI que se despregan en calquera lugar onde se executen os contedores. Esta extensibilidade é unha auténtica vantaxe arquitectónica sobre os sistemas de construción que tratan o seu formato de entrada como fixo.

Provence and SBOM: Building for the Post-SolarWinds World

A seguridade da cadea de subministración de software pasou da preocupación teórica a unha prioridade a nivel do consello despois da violación de SolarWinds en 2020 e da vulnerabilidade de Log4Shell en 2021. A Orde Executiva 14028 do goberno dos Estados Unidos sobre ciberseguridade, emitida en maio de 2021, obrigaba aos contratistas federais de materiais de software. As certificacións de procedencia de BuildKit e as funcións de xeración de SBOM son unha resposta directa a este panorama normativo e de seguridade.

Con marcas --provenance=true e --sbom=true, BuildKit xera certificacións asinadas criptográficamente que describen exactamente o que entrou nunha imaxe de contedor: que imaxes de base se utilizaron, que instrucións de Dockerfile executadas, que ficheiros fonte estaban presentes e que dependencias externas se buscaron. Estas certificacións seguen o marco SLSA (Supply-chain Levels for Software Artifacts) e o formato de certificación integral, polo que os motores de políticas como Cosign de Sigstore e OPA (Open Policy Agent) poden verificar a máquina.

O fluxo de traballo práctico que permite isto ten o seguinte aspecto:

O programador empurra código; A canalización de CI activa unha compilación de BuildKit coa procedencia activada.
BuildKit xera un SBOM asinado que enumera todos os compoñentes e as súas versións.
O SBOM publícase no rexistro de contedores xunto co manifesto da imaxe.
Os controladores de admisión do clúster de Kubernetes verifican a procedencia antes de permitir a implantación.
Os escáneres de vulnerabilidade consultan o SBOM para identificar as imaxes afectadas cando se revelan novos CVE.

Os equipos que implementan esta canalización completa poden responder ás divulgacións de vulnerabilidades en horas en lugar de días, porque teñen un mapa preciso e lexible pola máquina de cada compoñente en cada contedor en execución. Para empresas como Mewayz que se integran profundamente nos fluxos de traballo operativos dos clientes (execución de nóminas, xestión de datos da flota, procesamento de facturas), a capacidade de demostrar unha cadea de subministración rigorosa e auditable é cada vez máis un requisito previo para as conversacións de vendas empresariais, non só un bo ter.

Comezar: dende as compilacións predeterminadas ata as canalizacións avanzadas

BuildKit xa se está a executar no teu ambiente Docker se estás a usar unha versión recente — Docker 23.0 e posterior actívao de forma predeterminada. O primeiro paso práctico para a maioría dos equipos é activar o complemento Docker Buildx, que expón o conxunto completo de funcións de BuildKit mediante o subcomando docker buildx. Ao executar docker buildx create --use configura unha instancia do constructor BuildKit con máis capacidade que o controlador predeterminado. A partir de aí, a adopción progresiva de funcións avanzadas ten sentido en lugar de tentar adoptar todo á vez.

Un camiño de adopción razoable para un equipo que actualmente realiza invocacións básicas de construción docker parece engadir primeiro exportacións de caché a CI; isto ofrece melloras de velocidade inmediatas e medibles cun cambio mínimo de configuración. As creacións multiplataforma fanse valiosas cando o equipo comeza a orientarse á infraestrutura ARM. Vale a pena adoptar o montaxe secreto cada vez que aparecen rexistros de paquetes privados ou claves SSH no contexto de compilación. As certificacións de procedencia teñen sentido activalas cando os requisitos de cumprimento ou as demandas dos clientes empresariais fan necesaria a documentación da cadea de subministración.

A lección máis profunda de BuildKit consiste en construír deliberadamente. Tanto se estás enviando un contedor para un microservizo, un punto final de inferencia de aprendizaxe automática ou unha plataforma complexa como a suite de 207 módulos empresariais de Mewayz, o proceso de creación non é unha formalidade que se apresura no camiño da implantación: é un artefacto de enxeñería que reflicte a calidade, a postura de seguridade e a madurez operativa de todo o que se envía. BuildKit ofrécelle as ferramentas para facer que ese artefacto sexa excelente. A pregunta é simplemente se tomas o tempo para usalos.

Preguntas máis frecuentes

Que é BuildKit e en que se diferencia do clásico sistema de compilación Docker?

BuildKit é o motor de compilación de próxima xeración de Docker, introducido en Docker 18.09 e predeterminado en Docker 23.0. A diferenza do creador clásico, BuildKit admite a execución de capas paralelas, estratexias avanzadas de almacenamento en caché, montaxe de segredos e compilacións multiplataforma. Trata o proceso de compilación como un gráfico acíclico dirixido (DAG), que permite unha resolución de dependencias máis intelixente e tempos de compilación drasticamente máis rápidos para ficheiros Dockerfile complexos de varias etapas.

Necesito instalar algo adicional para comezar a usar BuildKit con Docker?

Non se precisa instalación adicional se está a executar Docker 23.0 ou posterior: BuildKit está activado de forma predeterminada. Nas versións anteriores, pode activalo configurando a variable de ambiente DOCKER_BUILDKIT=1 antes de executar os seus comandos de compilación. Para casos de uso avanzado, como cachés de compilación remotas ou compilacións multiplataforma, pode querer configurar unha instancia de compilador Buildx dedicada mediante docker buildx create.

Pódese usar BuildKit para construír artefactos máis aló das imaxes de contedores estándar?

Si, e esta é unha das capacidades máis subestimadas de BuildKit. Usando frontends personalizados e a marca --output, BuildKit pode producir binarios en bruto, tarballs, sitios web estáticos e outros artefactos de ficheiros arbitrarios, non só imaxes OCI. Isto convérteo nun motor de compilación de propósito xeral que encaixa naturalmente en monorepos políglotas e en canalizacións CI complexas onde os distintos equipos necesitan formatos de saída diferentes dunha cadea de ferramentas unificada.

Como encaixa BuildKit nunha plataforma DevOps máis ampla xunto con ferramentas como Mewayz?

BuildKit xestiona a capa de compilación de baixo nivel, pero os equipos de desenvolvemento modernos tamén precisan xestionar os fluxos de traballo empresariais, a entrega dos clientes e os procesos operativos. Plataformas como Mewayz, un sistema operativo empresarial de 207 módulos a partir de 19 dólares ao mes, complementan as ferramentas de infraestrutura ao cubrir o lado operativo das empresas de software. A combinación de canalizacións de construción eficientes impulsadas por BuildKit cunha plataforma todo-en-un como Mewayz ofrece aos equipos unha pila completa desde o artefacto de código ata a entrega ao cliente.

BuildKit: a xoia oculta de Docker que pode construír case calquera cousa