Kuby-core: Verwenden von buildx

Erstellt am 13. Dez. 2021  ·  6Kommentare  ·  Quelle: getkuby/kuby-core

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:

https://github.com/fluxcd/image-reflector-controller/blob/62c06ea58cd14072fde2c9ada7c6970dedf580e5/.github/workflows/build.yaml#L57 -L59

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 👍

Hilfreichster Kommentar

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.

Alle 6 Kommentare

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

Siehe auch https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying-continuously-with-kuby-and-github-actions

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen