Ich habe versucht, Unterstützung für das Aufrufen docker build
als docker buildx build
hinzuzufügen, aber ich fürchte, es könnte etwas komplizierter sein
Meine Absicht ist es, diese Art von Parametern hinzuzufügen:
Dann können wir Docker-Build-Layer effizienter zwischenspeichern. Wie auch immer, die Optionen --cache-to
und --cache-from
sind nur in Docker Buildx verfügbar, wie viele andere Optionen, die ich vielleicht verwenden möchte
In der Vergangenheit habe ich erfolgreich Cache-Volumes für Bundler innerhalb einer Dockerfile aktiviert, sodass Änderungen an Gemfile und Gemfile.lock nicht zu einer vollständigen Neuberechnung der Build-Time-Abhängigkeiten des Images führten, sondern stattdessen aus dem Cache erstellt wurden nur neue Abhängigkeiten wurden neu berechnet.
Während dies offensichtlich eine Nischenoptimierung ist, gibt es andere häufigere Anwendungsfälle, die nur mit buildx gut gehandhabt werden können. Das Buildkit-Toolset wird meiner Meinung nach mittlerweile zum Standard. Ich würde es lieben, wenn es möglich wäre, Kuby Build auf eine Weise aufzurufen, die buildx verwendet!
Ich könnte versuchen, dies später erneut zu implementieren, es könnte jetzt einfacher sein, da 0.15.0 solide veröffentlicht wurde. In der Zwischenzeit gibt es ein funktionierendes Beispiel für GitHub-Aktionen, das WIP ist, aber derzeit ziemlich gut aussieht, unter: https://github.com/kingdonb/kuby_test
Mit dem richtig konfigurierten Caching an dieser einen letzten Stelle und ein paar anderen Änderungen, denke ich, dass dies fast bereit ist, es zu taggen und ein Beispiel daraus zu machen, um einen Beitrag zurück zu kuby-core zu leisten oder irgendwo im getkuby-Projekt zu leben 👍
Hey!
Es ist jetzt möglich, buildx zu verwenden, wenn Sie es als Standard-Builder festlegen.
Hier ist ein Beispiel für eine Github-Aktion, die buildx und seine Caching-Funktionen verwendet: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44
Ich habe nur nach etwas wie dem --only
-Flag gesucht, da ich Probleme beim Einrichten des Cachings hatte! Ich hatte die Idee, dass ich Bereiche für jeden Build-Typ trennen musste, wie ich sehe, dass Sie es hier getan haben.
Vielen Dank für die praktischen Referenzen 👍 Ich folge jetzt mit, um zu sehen, ob sie mich über die Linie bringen!
I was definitely also missing the default builder feature of setup-buildx-action ( install: true
)
Es scheint jetzt zu funktionieren! Ich habe gerade gesehen, wie ein App-Image in weniger als 10 Sekunden erstellt wurde. Es gibt andere Probleme, die ich jetzt habe, möglicherweise eine Regression, die ich gefunden habe, wo RAILS_MASTER_KEY nicht richtig exportiert wird, aber ich werde gehen und die Quelle lesen, um es jetzt herauszufinden.
Wenn ich install: true
wie in diesem Commit verwende, dann ruft die Methode build
von lib/kuby/docker/cli.rb
buildx
, und ich kann buildx-Konstruktionen wie --cache-to
übergeben --
, um sie in das Array *docker-args
$ zu bekommen 👍 damit dies geschlossen werden kann, außer dass es für kuby-core nett sein könnte zu dokumentieren, wie es mit buildx verwendet werden kann, Es ist absolut nicht Kubys Problem
Mit dem Beispiel in:
https://github.com/kingdonb/kuby_test/commit/d74bf51e04253359b0d54aae7ddd6723ea6fd41d#diff -e2ad06bfd6b3aefc2d5f4fe8f60e0015b16947abc16764adef02e4339ac07a42R17-R20
Ich kann buildx verwenden, daher kann dieses Problem geschlossen werden.
Das ist wirklich cool, danke, dass du das buildx-Zeug herausgefunden hast! Ich hatte den Eindruck, Sie könnten eine Umgebungsvariable setzen und es würde einfach funktionieren™, ist es das, was diese docker/setup-buildx-action@v1
Aktion macht? Es scheint, dass buildx mit Docker Desktop und neueren Versionen geliefert wird, die über deb/rpm-Pakete installiert werden, also frage ich mich, ob Kuby es einfach standardmäßig verwenden könnte. Wenn es jedoch über env var konfigurierbar ist, ist das Aufrufen docker buildx build
vielleicht nicht erforderlich? Vielleicht kann Kuby es erkennen und auf den normalen docker build
zurückgreifen?
Ja, es ist möglich (und das macht install: true
in der GitHub-Aktion): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- Baumeister
Okay, wenn docker build
nur ein Alias für docker buildx
ist, dann sehe ich keine Notwendigkeit für Kuby, irgendetwas Besonderes zu tun. Es sollte dem Benutzer überlassen bleiben, den gewünschten Builder einzurichten.
Hilfreichster Kommentar
Okay, wenn
docker build
nur ein Alias fürdocker buildx
ist, dann sehe ich keine Notwendigkeit für Kuby, irgendetwas Besonderes zu tun. Es sollte dem Benutzer überlassen bleiben, den gewünschten Builder einzurichten.