Estaba tratando de agregar soporte para invocar docker build como docker buildx build pero me temo que podría ser un poco más complicado que eso
Mi intención es agregar este tipo de parámetros:
Luego, podemos almacenar en caché las capas de compilación de Docker de una manera más eficiente. De todos modos, las opciones --cache-to y --cache-from solo están disponibles en Docker Buildx, como muchas otras opciones que tal vez me gustaría usar.
En el pasado, habilité con éxito los volúmenes de caché para el paquete dentro de un Dockerfile, por lo que los cambios en Gemfile y Gemfile.lock no darían como resultado un recálculo completo de las dependencias de tiempo de compilación de la imagen, sino que se compilarían desde el caché para que solo se recalcularon nuevas dependencias.
Si bien esto es obviamente una optimización de nicho, hay otros casos de uso más comunes que solo pueden manejarse bien con buildx. El conjunto de herramientas del kit de compilación se está volviendo bastante estándar ahora en mi humilde opinión. ¡Me encantaría si fuera posible invocar a Kuby build de una manera que use buildx!
Podría intentar implementar esto nuevamente más tarde, podría ser más fácil ahora que 0.15.0 se lanzó sólidamente. Mientras tanto, hay un ejemplo funcional de GitHub Actions que es WIP pero que actualmente se ve bastante bien en: https://github.com/kingdonb/kuby_test
Con el almacenamiento en caché correctamente configurado en este último lugar, y un par de otros cambios, creo que está casi listo para etiquetar y convertirlo en un ejemplo para contribuir de nuevo a kuby-core, o para vivir en algún lugar del proyecto getkuby 👍
kingdonb
Todos 6 comentarios
¡Oye!
Es posible usar buildx ahora mismo, si lo configura como un generador predeterminado .
Aquí hay un ejemplo de Github Action que usa buildx y sus capacidades de almacenamiento en caché: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44
Consulte también https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying -continuously-with-kuby-and-github-actions
palkan
en 14 dic. 2021
¡Estaba buscando algo como el indicador --only , ya que tenía problemas para configurar el almacenamiento en caché! Se me ocurrió la idea de que necesitaba separar los ámbitos para cada tipo de compilación, como veo que ha hecho aquí.
Muchas gracias por las útiles referencias 👍 ¡Les sigo ahora para ver si me ayudan a cruzar la línea!
Definitivamente también me faltaba la función de creación predeterminada de setup-buildx-action ( install: true )
¡Parece estar funcionando ahora! Acabo de ver la creación de una imagen de aplicación completa en menos de 10 segundos. Hay otros problemas que tengo ahora, posiblemente una regresión que encontré donde RAILS_MASTER_KEY no se exporta correctamente, pero voy a ir y leer la fuente para averiguarlo ahora.
Si uso install: true como en esta confirmación, entonces el método build de lib/kuby/docker/cli.rb invoca buildx , y puedo pasar construcciones buildx como --cache-to después de -- para colocarlos en la matriz *docker-args 👍 para que esto se pueda cerrar, excepto que sería bueno que kuby-core documentara cómo se puede usar con buildx, estrictamente no es problema de kuby
kingdonb
en 14 dic. 2021
Con el ejemplo en:
Puedo usar buildx, por lo que este problema se puede cerrar.
kingdonb
en 14 dic. 2021
¡Esto es realmente genial, gracias por descubrir las cosas de buildx! Tenía la impresión de que podías establecer una variable de entorno y funcionaría Just Work™, ¿es eso lo que está haciendo la acción docker/setup-buildx-action@v1 ? Parece que buildx viene con Docker Desktop y versiones más nuevas instaladas a través de paquetes deb/rpm, por lo que me pregunto si Kuby podría simplemente usarlo de forma predeterminada. Sin embargo, si es configurable a través de env var, ¿quizás no sea necesario invocar docker buildx build ? ¿Quizás Kuby pueda detectarlo y volver a la normalidad docker build ?
camertron
en 14 dic. 2021
Sí, es posible (y eso es lo que hace install: true en GitHub Action): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- constructor
palkan
en 14 dic. 2021
Muy bien, si docker build es solo un alias para docker buildx , entonces no veo la necesidad de que Kuby haga nada especial. El usuario debe configurar el constructor que desee.
camertron
en 15 dic. 2021
Temas relacionados
hovancik
·
5Comentarios
traels
·
13Comentarios
thibaudgg
·
3Comentarios
dibyajyoti
·
3Comentarios
alexcoplan
·
3Comentarios
Comentario más útil
Muy bien, si
docker buildes solo un alias paradocker buildx, entonces no veo la necesidad de que Kuby haga nada especial. El usuario debe configurar el constructor que desee.