5 ms·
Dependcies are also for multiple stages, e.g.: So `COPY --from=<some stage>` and `FROM <other stage>` Also, a Dockerfile is just a frontend for buildkit. The
by cpuguy83 7y ago
Dependcies are also for multiple stages, e.g.:
So `COPY --from=<some stage>` and `FROM <other stage>`
Also, a Dockerfile is just a frontend for buildkit. The heart of buildkit is "LLB" (sort of like LLVM IR in usage) which is what the Dockerfile compiles into. Buildkit just executes LLB, doesn't have to be from a Dockerfile.
For that matter you can have a "Dockerfile" (in name only) that is not even really dockerfile since the format lets you specify frontend to use (which would be a container image reference) to process it.
There's even a buildkit frontend to build buildpacks: https://github.com/tonistiigi/buildkit-pack https://github.com/tonistiigi/buildkit-pack
Works with any buildkit enabled builder, even `docker build`.
- throwaway894345 7y agoYeah, there are a lot of workarounds when you leave the standard tooling. I like the idea of using something like Bazel to build Docker images (since modeling dependencies and caching build steps is its raison d'etre) and eschewing Dockerfiles altogether; however, I haven't tried it (and Bazel has its own costs). I'm not familiar with buildkit in particular, but it's cool that it has an internal representation. I'll have to dig around.
- cpuguy83 7y agoI'm not sure I understand what you mean by workarounds and "leavings standard tooling"
- weberc2 7y agoI’m guessing he meant roughly ”docker build”
- takeda 7y agoNix also can build efficient docker images and computes layers in a way to make them reusable among multiple projects.
- cpuguy83 7y agoYes! Check out https://nixery.dev/ https://nixery.dev/
- takeda 7y agoYeah, it is cool, but it feels more like a demo for nix. If you want to create docker image of your own app, you probably would use: https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools This will produce an exported docker image as tar file, which then you can import it using either docker, or tool like skopeo[1] (which is also included in nixpkgs). The nix-shell functionality is also quite nice, because it allows you to create common development environment, with all tooling available that one might need to work. [1] https://github.com/containers/skopeo https://github.com/containers/skopeo
- tazjin 7y ago> If you want to create docker image of your own app, you probably would use [...] Nixery can be pointed at your own package set, in fact I do this for deployments of my personal services[0]. This doesn't interfere with any of the local Nix functionality. I find it makes for a pleasing CI loop, where CI builds populate my Nix cache[1] and deployment manifests just need to be updated with the most recent git commit hash[2]. (I'm the author of Nixery) [0]: https://git.tazj.in/tree/ops/infra/kubernetes/nixery https://git.tazj.in/tree/ops/infra/kubernetes/nixery [1]: https://git.tazj.in/tree/ops/sync-gcsr/manifest.yaml#n17 https://git.tazj.in/tree/ops/sync-gcsr/manifest.yaml#n17 [2]: https://git.tazj.in/tree/ops/infra/kubernetes/tazblog/config.yaml#n20 https://git.tazj.in/tree/ops/infra/kubernetes/tazblog/config...