OCI image building

[nzhang-zh]

Investigate methods to build OCI images and management via Nix. Start with building something similar to dockerTools in nixpkgs.

---

Tasks:

• [x] Ability to build a new single layer image from scratch
• [x] Ability to build layered image from single layer images
• [x] Reference existing layers when building layered image instead of full copy
• [x] Copy runtime dependencies to image local nix store
• [ ] Handle whiteout files
• [ ] Support nested layered image building
• [ ] Option to flatten layered image
• [ ] Support extra commands
• [ ] Fetching image from registries
• [ ] Build new image on top of fetched image

[CMCDragonkai]

@n-zhang-hp please check these related issues:

• https://github.com/MatrixAI/Emergence/issues/37
• https://github.com/MatrixAI/Emergence/issues/23
• https://github.com/MatrixAI/Emergence/issues/22

If they are related, please assign yourself there, or associate them into the relevant project board.

[nzhang-zh]

An initial ociTools attempt can be found here. 891b92bbe5561035e504891a7da99e47f9d39582 Closes #23

Completed:

1. build single layer image
2. combine multiple layers into a new image

Still need to squash multi layered image created in 2 down so it can be composed again. Also can not build layer with root permission currently.

[nzhang-zh]

Update: Dynamic linking issue can be resolved by creating a Nix store in the layer containing required dependencies. as seen in dockerTools.

---

The initial ociTools simply fetches packages from nixpkgs and dump them into oci image spec compatible images. This works for oci-image-tool and runc.

However, relevant paths for dynamic linking inside a container are different from nix environment or even unavailable.

We could either do static linking for packages with gcc .... -static (need to bring in glibc.static in this case) or use patchelf to modify paths for required dynamic libraries.

Or alternatively, this could be operator's responsibility to create properly linked/formed binary/library files.

[nzhang-zh]

Here is a summary of the discussion with @CMCDragonkai addressing how an Artefact should be built, stored and run.

---

Glossary

• Image Archive refers to a tar archive of an OCI image
• Image Layout refers to unpacked Image Archive

  ./blobs/sha256/....
  ./index.json
  ./oci-layout

• Overlay refers to a directory structure of an unpacked Image Layout with an OCI runtime specification file

  ./rootfs/...
  ./config.json

• Blob refers to tar archive storing directory structure of a single layer

Storing Artefact

Image Archive is suitable for distribution of images therefore used by Docker. We should store Image Layouts instead to allow blobs sharing between different images. Overlays are also stored in the nix store.

Building Artefact

Blobs representing single layers should be linked in a composed Image Layout instead of copied.

Running Artefact

• Container based procedure: Unpack Nix closure with storage driver into a filesystem mount
• Nix based procedure: Run container in read only mode from Nix store
  • Can mount additional volumes according to State specification where storage and automatons have separate lifetimes.

[nzhang-zh]

Since running OCI compatible image is more of a compatibility feature, apart from building oci images from scratch and combining them, we also need to fetch existing images from registries and build new images on top of them.

[nzhang-zh]

For nix based artefacts, instead of copying runtime dependencies into image layers, we can mount host nix store inside an automaton. Containers built this way will be really lightweight comparing to shipping all dependencies around.

This does require a host nix store to be present and has the outputs the automaton depends on.

Also, when an automaton is transferred between nodes, its closure must also be serialised and delivered.

[nzhang-zh]

Closing this in favour of #51 since our main objective for now is running OCI image based and Nix based artefacts rather than building OCI image with nix.