I’ve been working on some stuff in nixpkgs that recently got merged (and will be in 19.09
!).
Because I’m clearly a cool kid, now here’s a blog post about it: fun memory violations
I’ve been working on some stuff in nixpkgs that recently got merged (and will be in 19.09
!).
Because I’m clearly a cool kid, now here’s a blog post about it: fun memory violations
Cool! Are you planning to build layered images just like dockerTools.buildLayeredImage
is doing?
Cool! Are you planning to build layered images just like
dockerTools.buildLayeredImage
is doing?
I’m not sure how useful that would be. The idea here is anyway to
rebuild containers when the host rebuilds so that applications in
containers are as up-to-date as the hosts. It’s more about having a
more convenient way of managing filesystem (and later) network
namespaces.
for sake of completeness:
build-support/oci-tools/default.nix = ociTools.buildContainer
build-support/docker/default.nix = dockerTools.buildImage
im trying to update dockerTools
from v1 to v2.2 manifest format
the v2.2 format is compatible with OCI
for what its worth: here is my messy draft, to generate OCI images from a baseImage, and add contents from nixpkgs
works with podman load < oci-image.tar
but surprisingly fails with docker load < oci-image.tar
, since docker cannot load OCI images
imho, the OCI format is better, cos sha256sum
(hash of tarfile) is much faster than tarsum
(hash of contents of tarfile)
this is “surprising”, cos docker and OCI differ only in file structure, so docker load < oci-image.tar
would be trivial to implement … see my rant here
related: docker2oci to convert docker image to oci image
related: nixos/modules/virtualisation/oci-containers uses podman